From ben@niven-jenkins.co.uk Sun Oct 2 01:30:25 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F21C21F8DA1 for ; Sun, 2 Oct 2011 01:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.409 X-Spam-Level: X-Spam-Status: No, score=-103.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1EhW2uw09DG for ; Sun, 2 Oct 2011 01:30:24 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 181E321F8DA0 for ; Sun, 2 Oct 2011 01:30:24 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RAHU9-0006kU-Cw; Sun, 02 Oct 2011 09:33:21 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B4FF230A@MAILR002.mail.lan> Date: Sun, 2 Oct 2011 09:33:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <291CC3F9E50E7641901A54E85D0977C651B4FF230A@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Oct 2011 08:30:25 -0000 Hi Kevin, Thanks for reading the draft, answers inline. On 30 Sep 2011, at 05:00, Kevin J Ma wrote: > Hi Ben, >=20 > I read through the draft and had a couple of questions: >=20 > - The Site has a list of DeliveryGlobs which identify a set of URIs = to > which Restrictions apply? Restrictions in the form of Selection & Delivery ACLs can also be = specified in the Site itself. The idea is that the Site lists the = default restrictions and then DeliveryGlobs can be used to apply further = DeliveryACL restrictions based on a pattern match against the URI. > Do all restrictions apply to all globs, > or can individual restrictions be associated with individual globs? The restrictions specified in the Site object apply to all URIs. = Restrictions in a particular DeliveryGlob only apply to URIs that match = that DeliveryGlob. The first DeliveryGlob in the list that matches the = URI is applied (i.e. the ordering of DeliveryGlobs is important). > - The SelectionACL seems to suggest Surrogate selection restrictions, > but is Surrogate information not intra-CDN information and outside > the scope of CDNI? Ultimately the selection of a specific Surrogate is an intra-CDN = function, however there is a need to be able to express surrogate = selection policy between CDNs based on CSP policy. For example the = ability to express a policy such as "content can be delivered to End = Users in country X but must not be delivered from Surrogates in country = X". I expect that SelectionACLs will not normally contain specific lists of = individual Surrogate IP addresses and will use Locations that reference = class 1b names (as defined in draft-jenkins-cdni-names-00). We have a = proposal for describing class 1b names in Locations which we will = include in a future version of the draft (we didn't include it in the = -00 version because we wanted folks to concentrate on feedback on the = base approach, data model & interface specification first). > - The origin parameters seem HTTP specific? The Introduction does state: Note: In order to make this document more accessible, it does not attempt to articulate all the CDNI Metadata that would be required to satisfy all CDNI use cases. Rather, a smaller set of properties are proposed. These should be sufficient to implement a minimal interconnect of basic HTTP delivery. :-) =20 > Should they be encapsulated > based on an origin protocol? I'm not sure exactly what you mean by "encapsulated" in this context, do = you just mean naming the properties appropriately, e.g. changing = origin.basic.active to origin.http.basic.active etc? > Would the origin protocol not be related > to the DeliveryProtocol in some way? In general it is not possible to infer the Origin protocol from the = Delivery protocol as a CDN may support the use of multiple different = origin protocols for a single delivery protocol. Specifically which = origin protocols are supported for which delivery protocols is down to = the specific capabilities of a particular CDN. > Could there also be support for > multiple origin protocols and DeliveryProtocols within a Site? For origin protocols that may be a possibility, although I am not sure = how realistic it is. I would expect that the choice of origin protocol = is selected when the origin is built/deployed and the service is = deployed. I'm not sure that offering multiple origin protocols for a = particular Site offers any kind of advantage over a single origin = protocol. =20 Having multiple DeliveryProtocols for a single Site will be problematic = when DNS based redirection is used because at Surrogate selection time = the Request Router does not have information on which DeliveryProtocol = the client is intending to use and therefore would not be able to make = an appropriate Surrogate selection because it is a common deployment = design for each individual Surrogate to only have a subset of the = available/supported (by that CDN) DeliveryProtocols enabled. HTH Ben > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >> Ben Niven-Jenkins >> Sent: Monday, September 12, 2011 10:08 AM >> To: cdni@ietf.org >> Subject: [CDNi] Proposal for a CDNI Metadata model & interface >>=20 >> Colleagues, >>=20 >> We just uploaded a proposal for a CDNI Metadata model and an = interface >> specification for distributing CDNI Metadata (see below). >>=20 >> This initial version does not attempt to articulate all the CDNI = Metadata >> that would be required to satisfy all CDNI use cases. Instead, we = have >> proposed a smaller set of properties that should be sufficient to >> implement a minimal interconnect of basic HTTP delivery. >>=20 >> This is because, at this stage the important thing in our opinion is = to >> focus any discussion on the overall structure of the interface rather = than >> on the details or omission of particular properties. >>=20 >> Our proposal is available here: >> http://tools.ietf.org/html/draft-jenkins-cdni-metadata-00 >>=20 >> Thanks >> Ben, David & Grant >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From swainner@cisco.com Mon Oct 3 06:31:13 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF4F21F8B31 for ; Mon, 3 Oct 2011 06:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcwxyqF5u+8X for ; Mon, 3 Oct 2011 06:31:08 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 97D5A21F8B32 for ; Mon, 3 Oct 2011 06:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=16348; q=dns/txt; s=iport; t=1317648851; x=1318858451; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=VchP0OyWGZZAgdirLH1AohcUtk8+l7WWuJqxlTYrX6o=; b=UCfBRsL1WB1Mvb9V3hUHreUWl1gA9SIu2KVokb5odjHT5Fq8YzWvfTai HIHB/cWrmU6eMGm8WBEILJHfSP5pACone9BVrJXLMGmNSYJ/prK9Gy9Rs 3s5G4/6R4uln7OqQo+2/iUPyyytoC4PM2QdYtioMX3BC0ruIeXmxkZrpN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqsAABS5iU6rRDoI/2dsb2JhbABBmG6PEoEFgVMBAQEDAQEBAQ8BGjoHBAYBBQcECxEEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBHodZBppEAZ0uA4chBJNgkVo X-IronPort-AV: E=Sophos;i="4.68,479,1312156800"; d="scan'208,217";a="5610956" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 03 Oct 2011 13:34:10 +0000 Received: from stealth-10-32-245-58.cisco.com (stealth-10-32-245-58.cisco.com [10.32.245.58]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p93DY9V6032383; Mon, 3 Oct 2011 13:34:10 GMT Message-ID: <4E89BA77.4050903@cisco.com> Date: Mon, 03 Oct 2011 09:36:55 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kevin J Ma References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B4FF2383@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B4FF2383@MAILR002.mail.lan> Content-Type: multipart/alternative; boundary="------------000706090206000505010007" Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 13:31:13 -0000 This is a multi-part message in MIME format. --------------000706090206000505010007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kevin, My comments in-line ... On 9/30/11 10:45 AM, Kevin J Ma wrote: > > Hi Scott, > > We are currently updating section 2.3. I think the nomadic use case > includes not only geographic extension, but more generically footprint > extension. A carrier CDN with only an in-network presense for specific > devices (e.g., mobile vs TV) may want to increase its device footprint > by interconnecting with another local carrier CDN that supports other > devices or subscribers. We are also looking at removing section 5.1.3. > Understood. > > > > As an example, the uCDN might use URL appended > > tokens for authentication while dCDN might use URL appended hashes. > ... > > Clearly, the choice of > > authentication method is determined by the respective CDN's. > > Content providers typically implement apps today with an > understanding that > the uCDN has a specific authentication method. If the uCDN delegates > delivery to a dCDN that the content provider has no relationship > with, the > app may have no ability to switch authentication methods. Would the > uCDN be > responsible for generating of the proper dCDN credentials for the user? > That is exactly my point. I don't have an answer. The CSP may accept the uCDN's approach to authentication; however, that method of authentication may not be supported on the dCDN which has the authority to choose its own method of authentication independent of the CSP. 1. Does the dCDN have to support multiple authentication methods - one for each uCDN it establishes a relationship? 2. Does the uCDN have to support (and get approval from the CSP) for multiple authentication methods - one for each dCDN for which it establishes a relationship? 3. Do we define a standard authentication method between the client and all CDN such that the CSP approves one method and all uCDN and dCDN support the standard method? 4. Do we define a proxy authentication method where the dCDN authenticates the client using their method of choice, the uCDN authenticates clients using their method of choice, AND CDNi defines a standard proxy method between the dCDN and uCDN? In this case, the CSP must accept that the methods used by dCDN and uCDN are equivalent but not necessarily the same. In what manner is the client informed of the appropriate method to authenticate their transaction with either the dCDN or uCDN? Scott > > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Scott Wainner > > Sent: Thursday, September 29, 2011 8:02 PM > > To: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Section 2.3 Nomadic Users > > This description falls under the category of Geographic Extension yet > > the third paragraph states the case where a different device is used in > > the same CDN coverage area. The intent of this use case needs to be > > clarified. Perhaps the use case is trying to address the scenario where > > a Nomadic User-A with an agreement allowing access to content from CSP-A > > via uCDN moves to a dCDN in a different region. The dCDN is allowed to > > distribute the content of CSP-A to User-A; however, not other users in > > the region of the dCDN are allowed to retrieve the content unless they > > too have such an agreement. > > > > Section 5.1.3 Content Encoding Restrictions > > Need to clarify if we're talking about the restrictions on the > > delivery of specific content or the restrictions on the ability of a CDN > > to deliver specific content. I certainly understand the case where a > > CSP will restrict the distribution of content to a "managed path" if > > such content is HD while allowing the content distribution via an > > un-managed path if such content is SD (same could apply to encryption > > methods, delivery methods, etc.). On the contrary, the dCDN may have > > its own restrictions of blocking the distribution of HD content while > > allowing the distribution of SD content. > > > > o first bullet makes sense if the dCDN can perform a subset of > > encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) > > o second bullet makes sense where the dCDN doesn't want to offer high > > bit-rate variants of the media > > o third bullet make sense if the policy addresses QoE but I don't > > think subscriber rights/authorizations apply. > > > > Section 10 Security Considerations > > > > Aside from the security considerations WITHIN the uCDN and dCDN, I think > > we can describe this in four contexts: > > > > a. The relationship between the CSP and the uCDN (the principle contract > > arrangement for distribution) > > b. The relationship between the uCDN and dCDN (the transitive trust > > relationship that extends the contract defined in (a) above) > > c. The relationship between the User and dCDN (the recognition of right > > to download predicated on (b) above) > > d. The relationship between the User and CSP (the contract authorizing > > the user access to the content) > > > > The user is not interested in the a-b nor the b-c relationship. The user > > is only interested in the transparency and interoperability of the > > security relationship between d-b or d-c to the point that the > > authorization granted in d-a is viable when the delivery is initiated > > via either d-b or d-c. As an example, the uCDN might use URL appended > > tokens for authentication while dCDN might use URL appended hashes. The > > user doesn't want to know about the distinct methods, but transparency > > is only afforded if the methods are interoperable clearly defined when > > the delegation for content delivery is executed. Clearly, the choice of > > authentication method is determined by the respective CDN's. > > > > Scott > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > --------------000706090206000505010007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Kevin,

    My comments in-line ...

On 9/30/11 10:45 AM, Kevin J Ma wrote:
RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Scott,

  We are currently updating section 2.3.  I think the nomadic use case
  includes not only geographic extension, but more generically footprint
  extension.  A carrier CDN with only an in-network presense for specific
  devices (e.g., mobile vs TV) may want to increase its device footprint
  by interconnecting with another local carrier CDN that supports other
  devices or subscribers.  We are also looking at removing section 5.1.3.

Understood.


  > As an example, the uCDN might use URL appended
  > tokens for authentication while dCDN might use URL appended hashes.
  ...
  > Clearly, the choice of
  > authentication method is determined by the respective CDN's.

  Content providers typically implement apps today with an understanding that
  the uCDN has a specific authentication method.  If the uCDN delegates
  delivery to a dCDN that the content provider has no relationship with, the
  app may have no ability to switch authentication methods.  Would the uCDN be
  responsible for generating of the proper dCDN credentials for the user?

That is exactly my point.  I don't have an answer.

The CSP may accept the uCDN's approach to authentication; however, that method of authentication may not be supported on the dCDN which has the authority to choose its own method of authentication independent of the CSP.

1. Does the dCDN have to support multiple authentication methods - one for each uCDN it establishes a relationship?

2. Does the uCDN have to support (and get approval from the CSP) for multiple authentication methods - one for each dCDN for which it establishes a relationship?

3. Do we define a standard authentication method between the client and all CDN such that the CSP approves one method and all uCDN and dCDN support the standard method?

4. Do we define a proxy authentication method where the dCDN authenticates the client using their method of choice, the uCDN authenticates clients using their method of choice, AND CDNi defines a standard proxy method between the dCDN and uCDN?  In this case, the CSP must accept that the methods used by dCDN and uCDN are equivalent but not necessarily the same.

In what manner is the client informed of the appropriate method to authenticate their transaction with either the dCDN or uCDN?

Scott


thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> Scott Wainner
> Sent: Thursday, September 29, 2011 8:02 PM
> To: cdni@ietf.org
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Section 2.3 Nomadic Users
>    This description falls under the category of Geographic Extension yet
> the third paragraph states the case where a different device is used in
> the same CDN coverage area.  The intent of this use case needs to be
> clarified.  Perhaps the use case is trying to address the scenario where
> a Nomadic User-A with an agreement allowing access to content from CSP-A
> via uCDN moves to a dCDN in a different region.  The dCDN is allowed to
> distribute the content of CSP-A to User-A; however, not other users in
> the region of the dCDN are allowed to retrieve the content unless they
> too have such an agreement.
>
> Section 5.1.3 Content Encoding Restrictions
>    Need to clarify if we're talking about the restrictions on the
> delivery of specific content or the restrictions on the ability of a CDN
> to deliver specific content.  I certainly understand the case where a
> CSP will restrict the distribution of content to a "managed path" if
> such content is HD while allowing the content distribution via an
> un-managed path if such content is SD (same could apply to encryption
> methods, delivery methods, etc.).  On the contrary, the dCDN may have
> its own restrictions of blocking the distribution of HD content while
> allowing the distribution of SD content.
>
>    o first bullet makes sense if the dCDN can perform a subset of
> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH)
>    o second bullet makes sense where the dCDN doesn't want to offer high
> bit-rate variants of the media
>    o third bullet make sense if the policy addresses QoE but I don't
> think subscriber rights/authorizations apply.
>
> Section 10 Security Considerations
>
> Aside from the security considerations WITHIN the uCDN and dCDN, I think
> we can describe this in four contexts:
>
> a. The relationship between the CSP and the uCDN (the principle contract
> arrangement for distribution)
> b. The relationship between the uCDN and dCDN (the transitive trust
> relationship that extends the contract defined in (a) above)
> c. The relationship between the User and dCDN (the recognition of right
> to download predicated on (b) above)
> d. The relationship between the User and CSP (the contract authorizing
> the user access to the content)
>
> The user is not interested in the a-b nor the b-c relationship. The user
> is only interested in the transparency and interoperability of the
> security relationship between d-b or d-c to the point that the
> authorization granted in d-a is viable when the delivery is initiated
> via either d-b or d-c.  As an example, the uCDN might use URL appended
> tokens for authentication while dCDN might use URL appended hashes.  The
> user doesn't want to know about the distinct methods, but transparency
> is only afforded if the methods are interoperable clearly defined when
> the delegation for content delivery is executed.  Clearly, the choice of
> authentication method is determined by the respective CDN's.
>
> Scott
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni


--------------000706090206000505010007-- From kevin.ma@azukisystems.com Mon Oct 3 11:24:51 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 358CD21F8B8B for ; Mon, 3 Oct 2011 11:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBFdQ7TKRKZC for ; Mon, 3 Oct 2011 11:24:50 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5E55A21F8C07 for ; Mon, 3 Oct 2011 11:24:47 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1966E8BF284; Mon, 3 Oct 2011 14:27:50 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 79FA38BF26F; Mon, 3 Oct 2011 14:27:49 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Mon, 3 Oct 2011 14:27:37 -0400 From: Kevin J Ma To: Ben Niven-Jenkins Date: Mon, 3 Oct 2011 14:27:46 -0400 Thread-Topic: [CDNi] Proposal for a CDNI Metadata model & interface Thread-Index: AcyA3fDiZOmRxL3MSl2ZhvqUg+Z4eABECqdg Message-ID: <291CC3F9E50E7641901A54E85D0977C651B50AEDA8@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C651B4FF230A@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:24:51 -0000 Hi Ben, Thanx for the clarifications. In response to your question: > I'm not sure exactly what you mean by "encapsulated" in this context, d= o > you just mean naming the properties appropriately, e.g. changing > origin.basic.active to origin.http.basic.active etc? This is pretty much what I meant, along with perhaps an origin.http.enabl= ed property for the case where there are multiple protocol options and only = a subset of protocols are supported. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Sunday, October 02, 2011 4:33 AM > To: Kevin J Ma > Cc: cdni@ietf.org > Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface >=20 > Hi Kevin, >=20 > Thanks for reading the draft, answers inline. >=20 > On 30 Sep 2011, at 05:00, Kevin J Ma wrote: >=20 > > Hi Ben, > > > > I read through the draft and had a couple of questions: > > > > - The Site has a list of DeliveryGlobs which identify a set of URIs to > > which Restrictions apply? >=20 > Restrictions in the form of Selection & Delivery ACLs can also be > specified in the Site itself. The idea is that the Site lists the default > restrictions and then DeliveryGlobs can be used to apply further > DeliveryACL restrictions based on a pattern match against the URI. >=20 > > Do all restrictions apply to all globs, > > or can individual restrictions be associated with individual globs? >=20 > The restrictions specified in the Site object apply to all URIs. > Restrictions in a particular DeliveryGlob only apply to URIs that match > that DeliveryGlob. The first DeliveryGlob in the list that matches the UR= I > is applied (i.e. the ordering of DeliveryGlobs is important). >=20 > > - The SelectionACL seems to suggest Surrogate selection restrictions, > > but is Surrogate information not intra-CDN information and outside > > the scope of CDNI? >=20 > Ultimately the selection of a specific Surrogate is an intra-CDN function= , > however there is a need to be able to express surrogate selection policy > between CDNs based on CSP policy. For example the ability to express a > policy such as "content can be delivered to End Users in country X but > must not be delivered from Surrogates in country X". >=20 > I expect that SelectionACLs will not normally contain specific lists of > individual Surrogate IP addresses and will use Locations that reference > class 1b names (as defined in draft-jenkins-cdni-names-00). We have a > proposal for describing class 1b names in Locations which we will include > in a future version of the draft (we didn't include it in the -00 version > because we wanted folks to concentrate on feedback on the base approach, > data model & interface specification first). >=20 > > - The origin parameters seem HTTP specific? >=20 > The Introduction does state: >=20 > Note: In order to make this document more accessible, it does not > attempt to articulate all the CDNI Metadata that would be required to > satisfy all CDNI use cases. Rather, a smaller set of properties are > proposed. These should be sufficient to implement a minimal > interconnect of basic HTTP delivery. >=20 > :-) >=20 > > Should they be encapsulated > > based on an origin protocol? >=20 > I'm not sure exactly what you mean by "encapsulated" in this context, do > you just mean naming the properties appropriately, e.g. changing > origin.basic.active to origin.http.basic.active etc? >=20 > > Would the origin protocol not be related > > to the DeliveryProtocol in some way? >=20 > In general it is not possible to infer the Origin protocol from the > Delivery protocol as a CDN may support the use of multiple different > origin protocols for a single delivery protocol. Specifically which origi= n > protocols are supported for which delivery protocols is down to the > specific capabilities of a particular CDN. >=20 > > Could there also be support for > > multiple origin protocols and DeliveryProtocols within a Site? >=20 > For origin protocols that may be a possibility, although I am not sure ho= w > realistic it is. I would expect that the choice of origin protocol is > selected when the origin is built/deployed and the service is deployed. > I'm not sure that offering multiple origin protocols for a particular Sit= e > offers any kind of advantage over a single origin protocol. >=20 > Having multiple DeliveryProtocols for a single Site will be problematic > when DNS based redirection is used because at Surrogate selection time th= e > Request Router does not have information on which DeliveryProtocol the > client is intending to use and therefore would not be able to make an > appropriate Surrogate selection because it is a common deployment design > for each individual Surrogate to only have a subset of the > available/supported (by that CDN) DeliveryProtocols enabled. >=20 > HTH > Ben >=20 > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > >> Ben Niven-Jenkins > >> Sent: Monday, September 12, 2011 10:08 AM > >> To: cdni@ietf.org > >> Subject: [CDNi] Proposal for a CDNI Metadata model & interface > >> > >> Colleagues, > >> > >> We just uploaded a proposal for a CDNI Metadata model and an interface > >> specification for distributing CDNI Metadata (see below). > >> > >> This initial version does not attempt to articulate all the CDNI > Metadata > >> that would be required to satisfy all CDNI use cases. Instead, we have > >> proposed a smaller set of properties that should be sufficient to > >> implement a minimal interconnect of basic HTTP delivery. > >> > >> This is because, at this stage the important thing in our opinion is t= o > >> focus any discussion on the overall structure of the interface rather > than > >> on the details or omission of particular properties. > >> > >> Our proposal is available here: > >> http://tools.ietf.org/html/draft-jenkins-cdni-metadata-00 > >> > >> Thanks > >> Ben, David & Grant > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Mon Oct 3 11:25:08 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F3521F8C87 for ; Mon, 3 Oct 2011 11:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOaKBI-HkHwH for ; Mon, 3 Oct 2011 11:25:06 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4DF21F8C07 for ; Mon, 3 Oct 2011 11:25:06 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DF44C79DCDE; Mon, 3 Oct 2011 14:27:56 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6C73279DCC4; Mon, 3 Oct 2011 14:27:52 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Mon, 3 Oct 2011 14:27:47 -0400 From: Kevin J Ma To: Scott Wainner Date: Mon, 3 Oct 2011 14:27:50 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyB0TyO1WS5QHX6TduO4PVrjpF4CAAIN5xg Message-ID: <291CC3F9E50E7641901A54E85D0977C651B50AEDAA@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B4FF2383@MAILR002.mail.lan> <4E89BA77.4050903@cisco.com> In-Reply-To: <4E89BA77.4050903@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C651B50AEDAAMAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 18:25:08 -0000 --_000_291CC3F9E50E7641901A54E85D0977C651B50AEDAAMAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Scott, One option is that CPs that want strict authentication do not allow deleg= ation. In a non-interconnected environment, the CP has to configure the authenti= cation method on each CDN? If the uCDN is going to delegate to a dCDN, the uCDN= would have to configure the dCDN on behalf of the CP (passwords, certs, etc.)? = That brings up other transative trust issues that this CP probably does not wan= t to deal with? For other CPs, imo, end user transparency is the most importan= t. That could mean options 1 or 3 as you describe them below, or possibly a = proxy where the dCDN sends the credentials to the uCDN for verification, so that= the client does not need to know anything about the dCDN? wrt the use case draft, do you feel that the security section needs expan= ded, or that additional use cases are required? thanx. -- Kevin J. Ma From: Scott Wainner [mailto:swainner@cisco.com] Sent: Monday, October 03, 2011 9:37 AM To: Kevin J Ma Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Kevin, My comments in-line ... On 9/30/11 10:45 AM, Kevin J Ma wrote: Hi Scott, We are currently updating section 2.3. I think the nomadic use case includes not only geographic extension, but more generically footprint extension. A carrier CDN with only an in-network presense for specific devices (e.g., mobile vs TV) may want to increase its device footprint by interconnecting with another local carrier CDN that supports other devices or subscribers. We are also looking at removing section 5.1.3. Understood. > As an example, the uCDN might use URL appended > tokens for authentication while dCDN might use URL appended hashes. ... > Clearly, the choice of > authentication method is determined by the respective CDN's. Content providers typically implement apps today with an understanding th= at the uCDN has a specific authentication method. If the uCDN delegates delivery to a dCDN that the content provider has no relationship with, th= e app may have no ability to switch authentication methods. Would the uCDN= be responsible for generating of the proper dCDN credentials for the user? That is exactly my point. I don't have an answer. The CSP may accept the uCDN's approach to authentication; however, that met= hod of authentication may not be supported on the dCDN which has the author= ity to choose its own method of authentication independent of the CSP. 1. Does the dCDN have to support multiple authentication methods - one for = each uCDN it establishes a relationship? 2. Does the uCDN have to support (and get approval from the CSP) for multip= le authentication methods - one for each dCDN for which it establishes a re= lationship? 3. Do we define a standard authentication method between the client and all= CDN such that the CSP approves one method and all uCDN and dCDN support th= e standard method? 4. Do we define a proxy authentication method where the dCDN authenticates = the client using their method of choice, the uCDN authenticates clients usi= ng their method of choice, AND CDNi defines a standard proxy method between= the dCDN and uCDN? In this case, the CSP must accept that the methods use= d by dCDN and uCDN are equivalent but not necessarily the same. In what manner is the client informed of the appropriate method to authenti= cate their transaction with either the dCDN or uCDN? Scott thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bo= unces@ietf.org] On Behalf Of > Scott Wainner > Sent: Thursday, September 29, 2011 8:02 PM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Section 2.3 Nomadic Users > This description falls under the category of Geographic Extension yet > the third paragraph states the case where a different device is used in > the same CDN coverage area. The intent of this use case needs to be > clarified. Perhaps the use case is trying to address the scenario where > a Nomadic User-A with an agreement allowing access to content from CSP-A > via uCDN moves to a dCDN in a different region. The dCDN is allowed to > distribute the content of CSP-A to User-A; however, not other users in > the region of the dCDN are allowed to retrieve the content unless they > too have such an agreement. > > Section 5.1.3 Content Encoding Restrictions > Need to clarify if we're talking about the restrictions on the > delivery of specific content or the restrictions on the ability of a CDN > to deliver specific content. I certainly understand the case where a > CSP will restrict the distribution of content to a "managed path" if > such content is HD while allowing the content distribution via an > un-managed path if such content is SD (same could apply to encryption > methods, delivery methods, etc.). On the contrary, the dCDN may have > its own restrictions of blocking the distribution of HD content while > allowing the distribution of SD content. > > o first bullet makes sense if the dCDN can perform a subset of > encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) > o second bullet makes sense where the dCDN doesn't want to offer high > bit-rate variants of the media > o third bullet make sense if the policy addresses QoE but I don't > think subscriber rights/authorizations apply. > > Section 10 Security Considerations > > Aside from the security considerations WITHIN the uCDN and dCDN, I think > we can describe this in four contexts: > > a. The relationship between the CSP and the uCDN (the principle contract > arrangement for distribution) > b. The relationship between the uCDN and dCDN (the transitive trust > relationship that extends the contract defined in (a) above) > c. The relationship between the User and dCDN (the recognition of right > to download predicated on (b) above) > d. The relationship between the User and CSP (the contract authorizing > the user access to the content) > > The user is not interested in the a-b nor the b-c relationship. The user > is only interested in the transparency and interoperability of the > security relationship between d-b or d-c to the point that the > authorization granted in d-a is viable when the delivery is initiated > via either d-b or d-c. As an example, the uCDN might use URL appended > tokens for authentication while dCDN might use URL appended hashes. The > user doesn't want to know about the distinct methods, but transparency > is only afforded if the methods are interoperable clearly defined when > the delegation for content delivery is executed. Clearly, the choice of > authentication method is determined by the respective CDN's. > > Scott > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --_000_291CC3F9E50E7641901A54E85D0977C651B50AEDAAMAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [CDNi] I-D Action: draft-ietf-cdn= i-use-cases-00.txt

= Hi Scott,

 

  One option is that CPs that want strict= authentication do not allow delegation.

  In a non-interconnected environment, the CP has to configur= e the authentication

  met= hod on each CDN?  If the uCDN is going to delegate to a dCDN, the uCDN= would

 have to configure = the dCDN on behalf of the CP (passwords, certs, etc.)?  That

 brings up other transative trust i= ssues that this CP probably does not want to

 deal with?  For other CPs, imo, end user transpar= ency is the most important.

&nbs= p; That could mean options 1 or 3 as you describe them below, or possibly a= proxy

 where the dCDN sen= ds the credentials to the uCDN for verification, so that the

 client does not need to know anything a= bout the dCDN?

 =

  wrt the use case draft, do you feel= that the security section needs expanded, or

  that additional use cases are required?

 

thanx.

 

--  Kevin J. Ma

 

From: Scott Wainner [mailto:sw= ainner@cisco.com]
Sent: Monday, October 03, 2011 9:37 AM
T= o: Kevin J Ma
Cc: cdni@ietf.org
Subject: Re: [CDNi]= I-D Action: draft-ietf-cdni-use-cases-00.txt

 

Kevin,
    My comments in-line ...

On 9/30/11 10:45 AM= , Kevin J Ma wrote:

Hi S= cott,

  We are currently updating section 2.3.  I think th= e nomadic use case
  includes not only geographic extension, but mo= re generically footprint
  extension.  A carrier CDN with only= an in-network presense for specific
  devices (e.g., mobile vs TV)= may want to increase its device footprint
  by interconnecting wit= h another local carrier CDN that supports other
  devices or subscr= ibers.  We are also looking at removing section 5.1.3.

Understood.


  > As an example, the uCDN might use URL= appended
  > tokens for authentication while dCDN might use URL= appended hashes.
  ...
  > Clearly, the choice of
&n= bsp; > authentication method is determined by the respective CDN's.
<= br>  Content providers typically implement apps today with an understa= nding that
  the uCDN has a specific authentication method.  I= f the uCDN delegates
  delivery to a dCDN that the content provider= has no relationship with, the
  app may have no ability to switch = authentication methods.  Would the uCDN be
  responsible for g= enerating of the proper dCDN credentials for the user?

That is exactly my point.  I don't have an answe= r.

The CSP may accept the uCDN's approach to authentication; however= , that method of authentication may not be supported on the dCDN which has = the authority to choose its own method of authentication independent of the= CSP.

1. Does the dCDN have to support multiple authentication metho= ds - one for each uCDN it establishes a relationship?

2. Does the uC= DN have to support (and get approval from the CSP) for multiple authenticat= ion methods - one for each dCDN for which it establishes a relationship?
3. Do we define a standard authentication method between the client an= d all CDN such that the CSP approves one method and all uCDN and dCDN suppo= rt the standard method?

4. Do we define a proxy authentication metho= d where the dCDN authenticates the client using their method of choice, the= uCDN authenticates clients using their method of choice, AND CDNi defines = a standard proxy method between the dCDN and uCDN?  In this case, the = CSP must accept that the methods used by dCDN and uCDN are equivalent but n= ot necessarily the same.

In what manner is the client informed of th= e appropriate method to authenticate their transaction with either the dCDN= or uCDN?

Scott


thanx.

--  Kevin J. Ma

> -----Original Mess= age-----
> From: cdni-bounce= s@ietf.org [mailto:cdni-bounce= s@ietf.org] On Behalf Of
> Scott Wainner
> Sent: Thursday, = September 29, 2011 8:02 PM
> To: cdn= i@ietf.org
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-= cases-00.txt
>
> Section 2.3 Nomadic Users
>  &= nbsp; This description falls under the category of Geographic Extension yet=
> the third paragraph states the case where a different device is us= ed in
> the same CDN coverage area.  The intent of this use case= needs to be
> clarified.  Perhaps the use case is trying to add= ress the scenario where
> a Nomadic User-A with an agreement allowing= access to content from CSP-A
> via uCDN moves to a dCDN in a differe= nt region.  The dCDN is allowed to
> distribute the content of C= SP-A to User-A; however, not other users in
> the region of the dCDN = are allowed to retrieve the content unless they
> too have such an ag= reement.
>
> Section 5.1.3 Content Encoding Restrictions
>= ;    Need to clarify if we're talking about the restrictions= on the
> delivery of specific content or the restrictions on the abi= lity of a CDN
> to deliver specific content.  I certainly unders= tand the case where a
> CSP will restrict the distribution of content= to a "managed path" if
> such content is HD while allowing= the content distribution via an
> un-managed path if such content is= SD (same could apply to encryption
> methods, delivery methods, etc.= ).  On the contrary, the dCDN may have
> its own restrictions of= blocking the distribution of HD content while
> allowing the distrib= ution of SD content.
>
>    o first bullet makes= sense if the dCDN can perform a subset of
> encapsulations for a ref= erence set of media (e.g. HLS, HSS, but not DASH)
>   = o second bullet makes sense where the dCDN doesn't want to offer high
&= gt; bit-rate variants of the media
>    o third bullet= make sense if the policy addresses QoE but I don't
> think subscribe= r rights/authorizations apply.
>
> Section 10 Security Consider= ations
>
> Aside from the security considerations WITHIN the uC= DN and dCDN, I think
> we can describe this in four contexts:
>=
> a. The relationship between the CSP and the uCDN (the principle co= ntract
> arrangement for distribution)
> b. The relationship be= tween the uCDN and dCDN (the transitive trust
> relationship that ext= ends the contract defined in (a) above)
> c. The relationship between= the User and dCDN (the recognition of right
> to download predicated= on (b) above)
> d. The relationship between the User and CSP (the co= ntract authorizing
> the user access to the content)
>
> = The user is not interested in the a-b nor the b-c relationship. The user> is only interested in the transparency and interoperability of the> security relationship between d-b or d-c to the point that the
>= ; authorization granted in d-a is viable when the delivery is initiated
= > via either d-b or d-c.  As an example, the uCDN might use URL app= ended
> tokens for authentication while dCDN might use URL appended h= ashes.  The
> user doesn't want to know about the distinct metho= ds, but transparency
> is only afforded if the methods are interopera= ble clearly defined when
> the delegation for content delivery is exe= cuted.  Clearly, the choice of
> authentication method is determ= ined by the respective CDN's.
>
> Scott
> _______________= ________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni<= /a>

 

= --_000_291CC3F9E50E7641901A54E85D0977C651B50AEDAAMAILR002maill_-- From swainner@cisco.com Mon Oct 3 12:21:51 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6454121F8DF2 for ; Mon, 3 Oct 2011 12:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.433 X-Spam-Level: X-Spam-Status: No, score=-2.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MXwltcbyu30 for ; Mon, 3 Oct 2011 12:21:49 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id BF03A21F8DCB for ; Mon, 3 Oct 2011 12:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=26445; q=dns/txt; s=iport; t=1317669892; x=1318879492; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=4Rp9PgEk6+4mLdgCv+6CbIq5BD5dfA3gN40hXT0Gy+8=; b=PbpLMqX6UgxTncWD+JmBB0ZiTmff21pGFBBraQJY9bIV34qOFYP5KToS zTncCXzqLbQYsTQZcmhfOMBWTwsZEJmOF36UCK8l+RMMoSkD+nVjxB4R0 PJq+HTgnz7XwPp3fRySjVfhV/KX+GcCFPjBQvADPmJSkGsaXZtTDl1uzf o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApgAAB0Lik6rRDoH/2dsb2JhbABDgk2WI48TgQWBUwEBAQMBAQEBDwEUBjoHBAYBBQcECxEEAQEBCRYBBwcJAwIBAgEVHwkIBg0BBQIBAR6HWQaaaQGdcQOHIQSTYJFa X-IronPort-AV: E=Sophos;i="4.68,481,1312156800"; d="scan'208,217";a="5679666" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 03 Oct 2011 19:24:51 +0000 Received: from stealth-10-32-245-58.cisco.com (stealth-10-32-245-58.cisco.com [10.32.245.58]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p93JOojn022958; Mon, 3 Oct 2011 19:24:50 GMT Message-ID: <4E8A0CA7.4040405@cisco.com> Date: Mon, 03 Oct 2011 15:27:35 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kevin J Ma References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B4FF2383@MAILR002.mail.lan> <4E89BA77.4050903@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B50AEDAA@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B50AEDAA@MAILR002.mail.lan> Content-Type: multipart/alternative; boundary="------------020904060407010702080309" Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Oct 2011 19:21:51 -0000 This is a multi-part message in MIME format. --------------020904060407010702080309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I think any of the uses presume that the security infrastructure facilitates interoperability as I previously described in options 1, 2, 3, and 4. In the absence of an interoperable security framework, you have no viable use case. Perhaps the use case documents simply need to call out the per-requisite for negotiating a security method between the 4 parties or a method for confirming authorization along the chain of trust (CSP -> uCDN -> dCDN -> client). A requirement for negotiating or confirming security of the download should be in the Requirements document. Scott On 10/3/11 2:27 PM, Kevin J Ma wrote: > > Hi Scott, > > One option is that CPs that want strict authentication do not allow > delegation. > > In a non-interconnected environment, the CP has to configure the > authentication > > method on each CDN? If the uCDN is going to delegate to a dCDN, the > uCDN would > > have to configure the dCDN on behalf of the CP (passwords, certs, > etc.)? That > > brings up other transative trust issues that this CP probably does > not want to > > deal with? For other CPs, imo, end user transparency is the most > important. > > That could mean options 1 or 3 as you describe them below, or > possibly a proxy > > where the dCDN sends the credentials to the uCDN for verification, so > that the > > client does not need to know anything about the dCDN? > > wrt the use case draft, do you feel that the security section needs > expanded, or > > that additional use cases are required? > > thanx. > > -- Kevin J. Ma > > *From:*Scott Wainner [mailto:swainner@cisco.com] > *Sent:* Monday, October 03, 2011 9:37 AM > *To:* Kevin J Ma > *Cc:* cdni@ietf.org > *Subject:* Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > My comments in-line ... > > On 9/30/11 10:45 AM, Kevin J Ma wrote: > > Hi Scott, > > We are currently updating section 2.3. I think the nomadic use case > includes not only geographic extension, but more generically footprint > extension. A carrier CDN with only an in-network presense for specific > devices (e.g., mobile vs TV) may want to increase its device footprint > by interconnecting with another local carrier CDN that supports other > devices or subscribers. We are also looking at removing section 5.1.3. > > Understood. > > > > As an example, the uCDN might use URL appended > > tokens for authentication while dCDN might use URL appended hashes. > ... > > Clearly, the choice of > > authentication method is determined by the respective CDN's. > > Content providers typically implement apps today with an > understanding that > the uCDN has a specific authentication method. If the uCDN delegates > delivery to a dCDN that the content provider has no relationship > with, the > app may have no ability to switch authentication methods. Would the > uCDN be > responsible for generating of the proper dCDN credentials for the user? > > That is exactly my point. I don't have an answer. > > The CSP may accept the uCDN's approach to authentication; however, > that method of authentication may not be supported on the dCDN which > has the authority to choose its own method of authentication > independent of the CSP. > > 1. Does the dCDN have to support multiple authentication methods - one > for each uCDN it establishes a relationship? > > 2. Does the uCDN have to support (and get approval from the CSP) for > multiple authentication methods - one for each dCDN for which it > establishes a relationship? > > 3. Do we define a standard authentication method between the client > and all CDN such that the CSP approves one method and all uCDN and > dCDN support the standard method? > > 4. Do we define a proxy authentication method where the dCDN > authenticates the client using their method of choice, the uCDN > authenticates clients using their method of choice, AND CDNi defines a > standard proxy method between the dCDN and uCDN? In this case, the > CSP must accept that the methods used by dCDN and uCDN are equivalent > but not necessarily the same. > > In what manner is the client informed of the appropriate method to > authenticate their transaction with either the dCDN or uCDN? > > Scott > > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org > [mailto:cdni-bounces@ietf.org] On Behalf Of > > Scott Wainner > > Sent: Thursday, September 29, 2011 8:02 PM > > To: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Section 2.3 Nomadic Users > > This description falls under the category of Geographic Extension yet > > the third paragraph states the case where a different device is used in > > the same CDN coverage area. The intent of this use case needs to be > > clarified. Perhaps the use case is trying to address the scenario where > > a Nomadic User-A with an agreement allowing access to content from CSP-A > > via uCDN moves to a dCDN in a different region. The dCDN is allowed to > > distribute the content of CSP-A to User-A; however, not other users in > > the region of the dCDN are allowed to retrieve the content unless they > > too have such an agreement. > > > > Section 5.1.3 Content Encoding Restrictions > > Need to clarify if we're talking about the restrictions on the > > delivery of specific content or the restrictions on the ability of a CDN > > to deliver specific content. I certainly understand the case where a > > CSP will restrict the distribution of content to a "managed path" if > > such content is HD while allowing the content distribution via an > > un-managed path if such content is SD (same could apply to encryption > > methods, delivery methods, etc.). On the contrary, the dCDN may have > > its own restrictions of blocking the distribution of HD content while > > allowing the distribution of SD content. > > > > o first bullet makes sense if the dCDN can perform a subset of > > encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) > > o second bullet makes sense where the dCDN doesn't want to offer high > > bit-rate variants of the media > > o third bullet make sense if the policy addresses QoE but I don't > > think subscriber rights/authorizations apply. > > > > Section 10 Security Considerations > > > > Aside from the security considerations WITHIN the uCDN and dCDN, I think > > we can describe this in four contexts: > > > > a. The relationship between the CSP and the uCDN (the principle contract > > arrangement for distribution) > > b. The relationship between the uCDN and dCDN (the transitive trust > > relationship that extends the contract defined in (a) above) > > c. The relationship between the User and dCDN (the recognition of right > > to download predicated on (b) above) > > d. The relationship between the User and CSP (the contract authorizing > > the user access to the content) > > > > The user is not interested in the a-b nor the b-c relationship. The user > > is only interested in the transparency and interoperability of the > > security relationship between d-b or d-c to the point that the > > authorization granted in d-a is viable when the delivery is initiated > > via either d-b or d-c. As an example, the uCDN might use URL appended > > tokens for authentication while dCDN might use URL appended hashes. The > > user doesn't want to know about the distinct methods, but transparency > > is only afforded if the methods are interoperable clearly defined when > > the delegation for content delivery is executed. Clearly, the choice of > > authentication method is determined by the respective CDN's. > > > > Scott > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > --------------020904060407010702080309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I think any of the uses presume that the security infrastructure facilitates interoperability as I previously described in options 1, 2, 3, and 4.  In the absence of an interoperable security framework, you have no viable use case.

Perhaps the use case documents simply need to call out the per-requisite for negotiating a security method between the 4 parties or a method for confirming authorization along the chain of trust (CSP -> uCDN -> dCDN -> client).

A requirement for negotiating or confirming security of the download should be in the Requirements document.

Scott

On 10/3/11 2:27 PM, Kevin J Ma wrote:
RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Hi Scott,

 

  One option is that CPs that want strict authentication do not allow delegation.

  In a non-interconnected environment, the CP has to configure the authentication

  method on each CDN?  If the uCDN is going to delegate to a dCDN, the uCDN would

 have to configure the dCDN on behalf of the CP (passwords, certs, etc.)?  That

 brings up other transative trust issues that this CP probably does not want to

 deal with?  For other CPs, imo, end user transparency is the most important.

  That could mean options 1 or 3 as you describe them below, or possibly a proxy

 where the dCDN sends the credentials to the uCDN for verification, so that the

 client does not need to know anything about the dCDN?

 

  wrt the use case draft, do you feel that the security section needs expanded, or

  that additional use cases are required?

 

thanx.

 

--  Kevin J. Ma

 

From: Scott Wainner [mailto:swainner@cisco.com]
Sent: Monday, October 03, 2011 9:37 AM
To: Kevin J Ma
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

 

Kevin,

    My comments in-line ...

On 9/30/11 10:45 AM, Kevin J Ma wrote:

Hi Scott,

  We are currently updating section 2.3.  I think the nomadic use case
  includes not only geographic extension, but more generically footprint
  extension.  A carrier CDN with only an in-network presense for specific
  devices (e.g., mobile vs TV) may want to increase its device footprint
  by interconnecting with another local carrier CDN that supports other
  devices or subscribers.  We are also looking at removing section 5.1.3.

Understood.


  > As an example, the uCDN might use URL appended
  > tokens for authentication while dCDN might use URL appended hashes.
  ...
  > Clearly, the choice of
  > authentication method is determined by the respective CDN's.

  Content providers typically implement apps today with an understanding that
  the uCDN has a specific authentication method.  If the uCDN delegates
  delivery to a dCDN that the content provider has no relationship with, the
  app may have no ability to switch authentication methods.  Would the uCDN be
  responsible for generating of the proper dCDN credentials for the user?

That is exactly my point.  I don't have an answer.

The CSP may accept the uCDN's approach to authentication; however, that method of authentication may not be supported on the dCDN which has the authority to choose its own method of authentication independent of the CSP.

1. Does the dCDN have to support multiple authentication methods - one for each uCDN it establishes a relationship?

2. Does the uCDN have to support (and get approval from the CSP) for multiple authentication methods - one for each dCDN for which it establishes a relationship?

3. Do we define a standard authentication method between the client and all CDN such that the CSP approves one method and all uCDN and dCDN support the standard method?

4. Do we define a proxy authentication method where the dCDN authenticates the client using their method of choice, the uCDN authenticates clients using their method of choice, AND CDNi defines a standard proxy method between the dCDN and uCDN?  In this case, the CSP must accept that the methods used by dCDN and uCDN are equivalent but not necessarily the same.

In what manner is the client informed of the appropriate method to authenticate their transaction with either the dCDN or uCDN?

Scott


thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> Scott Wainner
> Sent: Thursday, September 29, 2011 8:02 PM
> To: cdni@ietf.org
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Section 2.3 Nomadic Users
>    This description falls under the category of Geographic Extension yet
> the third paragraph states the case where a different device is used in
> the same CDN coverage area.  The intent of this use case needs to be
> clarified.  Perhaps the use case is trying to address the scenario where
> a Nomadic User-A with an agreement allowing access to content from CSP-A
> via uCDN moves to a dCDN in a different region.  The dCDN is allowed to
> distribute the content of CSP-A to User-A; however, not other users in
> the region of the dCDN are allowed to retrieve the content unless they
> too have such an agreement.
>
> Section 5.1.3 Content Encoding Restrictions
>    Need to clarify if we're talking about the restrictions on the
> delivery of specific content or the restrictions on the ability of a CDN
> to deliver specific content.  I certainly understand the case where a
> CSP will restrict the distribution of content to a "managed path" if
> such content is HD while allowing the content distribution via an
> un-managed path if such content is SD (same could apply to encryption
> methods, delivery methods, etc.).  On the contrary, the dCDN may have
> its own restrictions of blocking the distribution of HD content while
> allowing the distribution of SD content.
>
>    o first bullet makes sense if the dCDN can perform a subset of
> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH)
>    o second bullet makes sense where the dCDN doesn't want to offer high
> bit-rate variants of the media
>    o third bullet make sense if the policy addresses QoE but I don't
> think subscriber rights/authorizations apply.
>
> Section 10 Security Considerations
>
> Aside from the security considerations WITHIN the uCDN and dCDN, I think
> we can describe this in four contexts:
>
> a. The relationship between the CSP and the uCDN (the principle contract
> arrangement for distribution)
> b. The relationship between the uCDN and dCDN (the transitive trust
> relationship that extends the contract defined in (a) above)
> c. The relationship between the User and dCDN (the recognition of right
> to download predicated on (b) above)
> d. The relationship between the User and CSP (the contract authorizing
> the user access to the content)
>
> The user is not interested in the a-b nor the b-c relationship. The user
> is only interested in the transparency and interoperability of the
> security relationship between d-b or d-c to the point that the
> authorization granted in d-a is viable when the delivery is initiated
> via either d-b or d-c.  As an example, the uCDN might use URL appended
> tokens for authentication while dCDN might use URL appended hashes.  The
> user doesn't want to know about the distinct methods, but transparency
> is only afforded if the methods are interoperable clearly defined when
> the delegation for content delivery is executed.  Clearly, the choice of
> authentication method is determined by the respective CDN's.
>
> Scott
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni

 


--------------020904060407010702080309-- From gilles.bertrand@orange.com Tue Oct 4 02:44:45 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 449FA21F8CB0 for ; Tue, 4 Oct 2011 02:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0X8JtPmtEXc for ; Tue, 4 Oct 2011 02:44:44 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 51F7021F8CA2 for ; Tue, 4 Oct 2011 02:44:44 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B0B98B58003; Tue, 4 Oct 2011 11:57:17 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A9FE0B58001; Tue, 4 Oct 2011 11:57:17 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 4 Oct 2011 11:47:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Oct 2011 11:47:39 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF02BA8776@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4E8506FC.1020701@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: Acx/cFnPOY7SMjAqRhCz1624aR21qADCShpw References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> From: To: X-OriginalArrivalTime: 04 Oct 2011 09:47:48.0454 (UTC) FILETIME=[ACDAC060:01CC827A] Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 09:44:45 -0000 Hi Scott, Thanks for your review. - "Section 2.3 Nomadic Users" =3D> I fully agree, we will clarify this = section.=20 - "Section 5.1.3 Content Encoding Restrictions" =3D> we will most = probably remove this section, because it is not clear enough as you = highlighted and as Kent and Fran=E7ois previously noted in their review = of draft-bertrand-cdni-use-cases-02. - "Section 10 Security Considerations" =3D> I agree with your proposal = to express "the pre-requisite for negotiating a security method between = the 4 parties or a method for confirming authorization along the chain = of trust (CSP -> uCDN -> dCDN -> client).". I think it will clarify the = issues.=20 Cheers, Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Scott Wainner Envoy=E9=A0: vendredi 30 septembre 2011 02:02 =C0=A0: cdni@ietf.org Objet=A0: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet = the third paragraph states the case where a different device is used in = the same CDN coverage area. The intent of this use case needs to be = clarified. Perhaps the use case is trying to address the scenario where = a Nomadic User-A with an agreement allowing access to content from CSP-A = via uCDN moves to a dCDN in a different region. The dCDN is allowed to = distribute the content of CSP-A to User-A; however, not other users in = the region of the dCDN are allowed to retrieve the content unless they = too have such an agreement. Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the = delivery of specific content or the restrictions on the ability of a CDN = to deliver specific content. I certainly understand the case where a = CSP will restrict the distribution of content to a "managed path" if = such content is HD while allowing the content distribution via an = un-managed path if such content is SD (same could apply to encryption = methods, delivery methods, etc.). On the contrary, the dCDN may have = its own restrictions of blocking the distribution of HD content while = allowing the distribution of SD content. o first bullet makes sense if the dCDN can perform a subset of = encapsulations for a reference set of media (e.g. HLS, HSS, but not = DASH) o second bullet makes sense where the dCDN doesn't want to offer high = bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't = think subscriber rights/authorizations apply. Section 10 Security Considerations Aside from the security considerations WITHIN the uCDN and dCDN, I think = we can describe this in four contexts: a. The relationship between the CSP and the uCDN (the principle contract = arrangement for distribution) b. The relationship between the uCDN and = dCDN (the transitive trust relationship that extends the contract = defined in (a) above) c. The relationship between the User and dCDN (the = recognition of right to download predicated on (b) above) d. The = relationship between the User and CSP (the contract authorizing the user = access to the content) The user is not interested in the a-b nor the b-c relationship. The user = is only interested in the transparency and interoperability of the = security relationship between d-b or d-c to the point that the = authorization granted in d-a is viable when the delivery is initiated = via either d-b or d-c. As an example, the uCDN might use URL appended = tokens for authentication while dCDN might use URL appended hashes. The = user doesn't want to know about the distinct methods, but transparency = is only afforded if the methods are interoperable clearly defined when = the delegation for content delivery is executed. Clearly, the choice of = authentication method is determined by the respective CDN's. Scott _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From richard_woundy@cable.comcast.com Wed Oct 5 14:36:25 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23ADB11E8115 for ; Wed, 5 Oct 2011 14:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.328 X-Spam-Level: X-Spam-Status: No, score=-102.328 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TRAvX4DH4Aq for ; Wed, 5 Oct 2011 14:36:24 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 61DFF11E80C2 for ; Wed, 5 Oct 2011 14:36:24 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.55942845; Wed, 05 Oct 2011 15:46:24 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0289.001; Wed, 5 Oct 2011 17:39:27 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: Nomcom 2011-2012: Second Call for Nominations Thread-Index: Acx1p83SvuomhflHTD2ovtWk+fc/jgN/WS9gAACBK/A= Date: Wed, 5 Oct 2011 21:39:26 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD11369DF8B@PACDCEXMB05.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] FW: Nomcom 2011-2012: Second Call for Nominations X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 21:36:25 -0000 Please note this Nomcom request for nominations for open positions, as well= as feedback for current nominees. Thanks. -- Rich & Francois -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of NomCom Chair Sent: Saturday, September 17, 2011 10:06 PM To: IETF Announcement list Cc: ietf@ietf.org Subject: Nomcom 2011-2012: Second Call for Nominations=20 Hi All, We are halfway through the nomination period (it ends on October 2, 2011) a= nd we need more nominees than we have received so far. We appreciate the fo= lks that have taken the time to nominate people and those who have accepted= so far. But the fact remains that the number of nominations have been belo= w average and the acceptance rates of those nominated has also been low. We need **YOUR** input and participation! We cannot properly execute the ta= sk of selecting the best candidates for these positions with so few nominat= ions and acceptances. So, please consider making nominations for the open p= ositions, in particular those for which we have so few nominations it takes just a few minutes of your time. Right now, we just need the names/email addresses. Why do we need more nominations? Well, even if you think a willing incumbe= nt is doing a very good job and should be returned, his or her ability to s= erve again might be impacted by unforeseen circumstances between now and Ma= rch. NomCom needs to consider multiple nominees to be prepared in the event= one or more candidates is unable to serve come next March and to ensure we= have chosen the best candidate. There are several ways you can help the Nomcom - You can nominate yourself. - You can nominate someone you know whom you think would do a good job. Don't worry about whether they might already be nominated. We would much pr= efer to receive the same nomination several times rather than miss a good p= erson we should consider. How to submit Nominations: -------------------------- The list of positions we need to fill, and the provided Job Descriptions, a= nd forms for nominations, can be found in the call for nominations at: https://datatracker.ietf.org/ann/nomcom/3049/ You can enter a nomination by going to the following URL:=20 https://www.ietf.org/group/nomcom/2011/nominate You can also nominate someone by sending an email to nomcom11@ietf.org and = giving us their name, email address and the open position you are nominatin= g them for. We will take care of the rest. If you are asked for a user name and password, use an existing ietf login a= nd password. If you need a login and password, request one from the followi= ng URL: https://datatracker.ietf.org/accounts/create/ Open List: ---------- As you already know, NomCom 2011-2012 will follow the policy for "Open Disc= losure of Willing Nominees" described in RFC 5680. Feedback Collection: -------------------- The open list is currently available on the Nomcom page and the entire comm= unity is invited to provide feedback on all nominees. You can provide your comments on all willing nominees at the following URL: https://www.ietf.org/group/nomcom/2011/input/ Suresh Krishnan Chair, NomCom 2011-2012 nomcom-chair@ietf.org suresh.krishnan@ericsson.com From spencer@wonderhamster.org Thu Oct 6 10:04:33 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9513C21F8B63 for ; Thu, 6 Oct 2011 10:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.967 X-Spam-Level: X-Spam-Status: No, score=-100.967 tagged_above=-999 required=5 tests=[AWL=-0.969, BAYES_50=0.001, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gd0-vPGFiiJi for ; Thu, 6 Oct 2011 10:04:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 0350021F8B58 for ; Thu, 6 Oct 2011 10:04:33 -0700 (PDT) Received: from S73602b (cpe-76-182-230-135.tx.res.rr.com [76.182.230.135]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MdrW9-1RUFLF3J4n-00PqSj; Thu, 06 Oct 2011 13:07:43 -0400 Message-ID: <941019F76B914748AE9E703ADFE5E79E@china.huawei.com> From: "Spencer Dawkins" To: "Ben Niven-Jenkins" References: Date: Thu, 6 Oct 2011 12:07:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Provags-ID: V02:K0:JQlze3qeqeK/Gnbpfkl+5GfaaYkqRzzXaFoVXzFMoJv 1TEnGsrDFSIICWTyGlljCyvWScgwk3Pzx+fKVBQuxT1trG4grx hbrA/zuxQVc2LJpFg2VgaTWqCM7SJCNQqxF2ukwEUz3U43TDL7 xTpjK/vtzIt9m73Gehz56/kN104RoE461XKrBv/DJhbF7G0zjz zBYgKAX+EimhI3N4N+lEsUzo5Zx8qo6oxUapYfFMqMJlr3AXmR kjpAos41iAEVd6Honmgw37m0BmKfB4FNRrwZpq+WYHkykT1zeM torwvnA5Q6lHvdCPITyPAawLAIT3h/dVcpHR5geq3uUuCTu+SM TWqC9Otahik/Zc7Thu7ybttBSQFwN1aKjK/PiH81kkQFv9ZX6L U9YEcNr1MAvGQ== Cc: cdni@ietf.org Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 17:04:33 -0000 Hi, Ben, Just checking - would this draft be the place where text on handling of unknown metadata elements would be included? Thanks, Spencer > Colleagues, > > We just uploaded a proposal for a CDNI Metadata model and an interface > specification for distributing CDNI Metadata (see below). > > This initial version does not attempt to articulate all the CDNI Metadata > that would be required to satisfy all CDNI use cases. Instead, we have > proposed a smaller set of properties that should be sufficient to > implement a minimal interconnect of basic HTTP delivery. > > This is because, at this stage the important thing in our opinion is to > focus any discussion on the overall structure of the interface rather than > on the details or omission of particular properties. > > Our proposal is available here: > http://tools.ietf.org/html/draft-jenkins-cdni-metadata-00 > > Thanks > Ben, David & Grant > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > From kevin.ma@azukisystems.com Thu Oct 6 22:18:14 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CC621F8B33 for ; Thu, 6 Oct 2011 22:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.428 X-Spam-Level: X-Spam-Status: No, score=-2.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dndd1x88jfl for ; Thu, 6 Oct 2011 22:18:13 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id BE16D21F8A97 for ; Thu, 6 Oct 2011 22:18:13 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C251A416C10 for ; Fri, 7 Oct 2011 01:21:22 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7E23C416BD7 for ; Fri, 7 Oct 2011 01:21:22 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Fri, 7 Oct 2011 01:21:02 -0400 From: Kevin J Ma To: "cdni@ietf.org" Date: Fri, 7 Oct 2011 01:21:20 -0400 Thread-Topic: CDNI Metadata Interface Thread-Index: AcyErDmDceDqNX+AQtKwjumpTmgL9w== Message-ID: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 05:18:14 -0000 Hi all, Just uploaded a new I-D with a proposed metadata model and API: http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt The model takes a rather generic approach to metadata representation to support opaque metadata and addresses some of the security issues associated with metadata retrieval. Comments welcome. thanx. -- Kevin J. Ma From zhouzhipeng@huawei.com Sat Oct 8 00:17:40 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A89E21F84F9 for ; Sat, 8 Oct 2011 00:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[AWL=3.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eJOKAly-hRhu for ; Sat, 8 Oct 2011 00:17:39 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C4E5621F844F for ; Sat, 8 Oct 2011 00:17:38 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ0031TKERYB@szxga05-in.huawei.com> for cdni@ietf.org; Sat, 08 Oct 2011 15:20:51 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSQ00KI0KE8VJ@szxga05-in.huawei.com> for cdni@ietf.org; Sat, 08 Oct 2011 15:20:51 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEH74378; Sat, 08 Oct 2011 15:20:50 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 08 Oct 2011 15:20:40 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Sat, 08 Oct 2011 15:20:40 +0800 Date: Sat, 08 Oct 2011 07:20:39 +0000 From: ZhouZhipeng In-reply-to: <4E8506FC.1020701@cisco.com> X-Originating-IP: [10.138.73.38] To: Scott Wainner , "cdni@ietf.org" Message-id: <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 07:17:40 -0000 Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. If you have any more question or comments, pls share in this thread. Thanks. Zhipeng -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. Section 10 Security Considerations Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is determined by the respective CDN's. Scott From vishwas.ietf@gmail.com Sat Oct 8 13:58:26 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697FA21F8B09 for ; Sat, 8 Oct 2011 13:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Er4jnAcwRMg for ; Sat, 8 Oct 2011 13:58:24 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 937E121F8B08 for ; Sat, 8 Oct 2011 13:58:24 -0700 (PDT) Received: by qadb12 with SMTP id b12so4379511qad.31 for ; Sat, 08 Oct 2011 14:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=05n6CmveXXeG8ZWup5UfAgbvNxhkoWEZ4vOcus83hPc=; b=KhTucPoIWzMpuYeilh0oGxowUDhH9e6sTR8QoGJJi18z5owh/flGdrJZ5yNjgwBrtc 5WHZkk5m3o1hCqMoYBAkeboVkZ5RbaO0ajzgW+AjkNNdkbZdoxOV+P3dsfw5xiYQA+0v AmXn39MNXbgnn35HDW4nqNG6R22UlMa0kA6nc= MIME-Version: 1.0 Received: by 10.229.95.5 with SMTP id b5mr2592024qcn.263.1318107696824; Sat, 08 Oct 2011 14:01:36 -0700 (PDT) Received: by 10.229.91.131 with HTTP; Sat, 8 Oct 2011 14:01:36 -0700 (PDT) In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B50AEDAA@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B4FF2383@MAILR002.mail.lan> <4E89BA77.4050903@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B50AEDAA@MAILR002.mail.lan> Date: Sat, 8 Oct 2011 14:01:36 -0700 Message-ID: From: Vishwas Manral To: Kevin J Ma Content-Type: multipart/alternative; boundary=0016364270620b812c04aecfdd88 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 20:58:26 -0000 --0016364270620b812c04aecfdd88 Content-Type: text/plain; charset=ISO-8859-1 Hi Kevin, I think Scott has a point when he says that we need to define some base authentication method to be supported between the CDN's. Ofcourse in particular cases if a particular authentication method is required it could mean to disallow delegation to a dCDN. Thanks, Vishwas On Mon, Oct 3, 2011 at 11:27 AM, Kevin J Ma wrote: > Hi Scott,**** > > ** ** > > One option is that CPs that want strict authentication do not allow > delegation.**** > > In a non-interconnected environment, the CP has to configure the > authentication**** > > method on each CDN? If the uCDN is going to delegate to a dCDN, the uCDN > would**** > > have to configure the dCDN on behalf of the CP (passwords, certs, etc.)? > That**** > > brings up other transative trust issues that this CP probably does not > want to**** > > deal with? For other CPs, imo, end user transparency is the most > important.**** > > That could mean options 1 or 3 as you describe them below, or possibly a > proxy**** > > where the dCDN sends the credentials to the uCDN for verification, so that > the**** > > client does not need to know anything about the dCDN?**** > > ** ** > > wrt the use case draft, do you feel that the security section needs > expanded, or**** > > that additional use cases are required?**** > > ** ** > > thanx.**** > > ** ** > > -- Kevin J. Ma**** > > ** ** > > *From:* Scott Wainner [mailto:swainner@cisco.com] > *Sent:* Monday, October 03, 2011 9:37 AM > *To:* Kevin J Ma > *Cc:* cdni@ietf.org > > *Subject:* Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt**** > > ** ** > > Kevin, > > My comments in-line ... > > On 9/30/11 10:45 AM, Kevin J Ma wrote: **** > > Hi Scott, > > We are currently updating section 2.3. I think the nomadic use case > includes not only geographic extension, but more generically footprint > extension. A carrier CDN with only an in-network presense for specific > devices (e.g., mobile vs TV) may want to increase its device footprint > by interconnecting with another local carrier CDN that supports other > devices or subscribers. We are also looking at removing section 5.1.3.* > *** > > Understood. > > **** > > > > As an example, the uCDN might use URL appended > > tokens for authentication while dCDN might use URL appended hashes. > ... > > Clearly, the choice of > > authentication method is determined by the respective CDN's. > > Content providers typically implement apps today with an understanding > that > the uCDN has a specific authentication method. If the uCDN delegates > delivery to a dCDN that the content provider has no relationship with, > the > app may have no ability to switch authentication methods. Would the uCDN > be > responsible for generating of the proper dCDN credentials for the user?* > *** > > That is exactly my point. I don't have an answer. > > The CSP may accept the uCDN's approach to authentication; however, that > method of authentication may not be supported on the dCDN which has the > authority to choose its own method of authentication independent of the CSP. > > 1. Does the dCDN have to support multiple authentication methods - one for > each uCDN it establishes a relationship? > > 2. Does the uCDN have to support (and get approval from the CSP) for > multiple authentication methods - one for each dCDN for which it establishes > a relationship? > > 3. Do we define a standard authentication method between the client and all > CDN such that the CSP approves one method and all uCDN and dCDN support the > standard method? > > 4. Do we define a proxy authentication method where the dCDN authenticates > the client using their method of choice, the uCDN authenticates clients > using their method of choice, AND CDNi defines a standard proxy method > between the dCDN and uCDN? In this case, the CSP must accept that the > methods used by dCDN and uCDN are equivalent but not necessarily the same. > > In what manner is the client informed of the appropriate method to > authenticate their transaction with either the dCDN or uCDN? > > Scott > > **** > > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] > On Behalf Of > > Scott Wainner > > Sent: Thursday, September 29, 2011 8:02 PM > > To: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Section 2.3 Nomadic Users > > This description falls under the category of Geographic Extension yet > > the third paragraph states the case where a different device is used in > > the same CDN coverage area. The intent of this use case needs to be > > clarified. Perhaps the use case is trying to address the scenario where > > a Nomadic User-A with an agreement allowing access to content from CSP-A > > via uCDN moves to a dCDN in a different region. The dCDN is allowed to > > distribute the content of CSP-A to User-A; however, not other users in > > the region of the dCDN are allowed to retrieve the content unless they > > too have such an agreement. > > > > Section 5.1.3 Content Encoding Restrictions > > Need to clarify if we're talking about the restrictions on the > > delivery of specific content or the restrictions on the ability of a CDN > > to deliver specific content. I certainly understand the case where a > > CSP will restrict the distribution of content to a "managed path" if > > such content is HD while allowing the content distribution via an > > un-managed path if such content is SD (same could apply to encryption > > methods, delivery methods, etc.). On the contrary, the dCDN may have > > its own restrictions of blocking the distribution of HD content while > > allowing the distribution of SD content. > > > > o first bullet makes sense if the dCDN can perform a subset of > > encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) > > o second bullet makes sense where the dCDN doesn't want to offer high > > bit-rate variants of the media > > o third bullet make sense if the policy addresses QoE but I don't > > think subscriber rights/authorizations apply. > > > > Section 10 Security Considerations > > > > Aside from the security considerations WITHIN the uCDN and dCDN, I think > > we can describe this in four contexts: > > > > a. The relationship between the CSP and the uCDN (the principle contract > > arrangement for distribution) > > b. The relationship between the uCDN and dCDN (the transitive trust > > relationship that extends the contract defined in (a) above) > > c. The relationship between the User and dCDN (the recognition of right > > to download predicated on (b) above) > > d. The relationship between the User and CSP (the contract authorizing > > the user access to the content) > > > > The user is not interested in the a-b nor the b-c relationship. The user > > is only interested in the transparency and interoperability of the > > security relationship between d-b or d-c to the point that the > > authorization granted in d-a is viable when the delivery is initiated > > via either d-b or d-c. As an example, the uCDN might use URL appended > > tokens for authentication while dCDN might use URL appended hashes. The > > user doesn't want to know about the distinct methods, but transparency > > is only afforded if the methods are interoperable clearly defined when > > the delegation for content delivery is executed. Clearly, the choice of > > authentication method is determined by the respective CDN's. > > > > Scott > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni**** > > ** ** > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > --0016364270620b812c04aecfdd88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kevin,
=A0
I think Scott has a point when he says that we need to define some bas= e authentication method to be supported between the CDN's.
=A0
Ofcourse in particular cases if a particular authentication method is = required it could mean to disallow delegation to a dCDN.
=A0
Thanks,
Vishwas
On Mon, Oct 3, 2011 at 11:27 AM, Kevin J Ma <kevin.ma@azu= kisystems.com> wrote:

Hi Scott,

=A0

=A0 One option is that CPs that want str= ict authentication do not allow delegation.

=A0 In a non-interconnected environment,= the CP has to configure the authentication

=A0 method on each CDN?=A0 If the uCDN i= s going to delegate to a dCDN, the uCDN would

=A0have to configure the dCDN on behalf = of the CP (passwords, certs, etc.)?=A0 That

=A0brings up other transative trust issu= es that this CP probably does not want to

=A0deal with?=A0 For other CPs, imo, end= user transparency is the most important.

=A0 That could mean options 1 or 3 as yo= u describe them below, or possibly a proxy

=A0where the dCDN sends the credentials = to the uCDN for verification, so that the

=A0client does not need to know anything= about the dCDN?

=A0

=A0 wrt the use case draft, do you feel = that the security section needs expanded, or

=A0 that additional use cases are requir= ed?

=A0

thanx.

=A0

--=A0 Kevin J. Ma

=A0

Scott= Wainner [mailto:sw= ainner@cisco.com]
Sent: Monday, October 03, 2011 9:37 AM
To: Kevin J Ma
<= b>Cc: cdni@ietf.org<= /a>=20

=A0

Kevin,

=A0=A0=A0 My comments in-line ...
<= br>On 9/30/11 10:45 AM, Kevin J Ma wrote:

Hi Scott,

=A0 We are currently up= dating section 2.3.=A0 I think the nomadic use case
=A0 includes not onl= y geographic extension, but more generically footprint
=A0 extension.=A0= A carrier CDN with only an in-network presense for specific
=A0 devices (e.g., mobile vs TV) may want to increase its device footprint<= br>=A0 by interconnecting with another local carrier CDN that supports othe= r
=A0 devices or subscribers.=A0 We are also looking at removing section= 5.1.3.

Understood.


=A0 > As an example, the uCDN mig= ht use URL appended
=A0 > tokens for authentication while dCDN might = use URL appended hashes.
=A0 ...
=A0 > Clearly, the choice of
= =A0 > authentication method is determined by the respective CDN's.
=A0 Content providers typically implement apps today with an understand= ing that
=A0 the uCDN has a specific authentication method.=A0 If the uC= DN delegates
=A0 delivery to a dCDN that the content provider has no rel= ationship with, the
=A0 app may have no ability to switch authentication methods.=A0 Would the = uCDN be
=A0 responsible for generating of the proper dCDN credentials fo= r the user?

That is exactly my point.=A0 I don't have an ans= wer.

The CSP may accept the uCDN's approach to authentication; h= owever, that method of authentication may not be supported on the dCDN whic= h has the authority to choose its own method of authentication independent = of the CSP.

1. Does the dCDN have to support multiple authentication methods - one = for each uCDN it establishes a relationship?

2. Does the uCDN have t= o support (and get approval from the CSP) for multiple authentication metho= ds - one for each dCDN for which it establishes a relationship?

3. Do we define a standard authentication method between the client and= all CDN such that the CSP approves one method and all uCDN and dCDN suppor= t the standard method?

4. Do we define a proxy authentication method= where the dCDN authenticates the client using their method of choice, the = uCDN authenticates clients using their method of choice, AND CDNi defines a= standard proxy method between the dCDN and uCDN?=A0 In this case, the CSP = must accept that the methods used by dCDN and uCDN are equivalent but not n= ecessarily the same.

In what manner is the client informed of the appropriate method to auth= enticate their transaction with either the dCDN or uCDN?

Scott


thanx.

--=A0 Kevin J. Ma
<= br>> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> Scott Wainner
> Sent: Thursday, September 29, 2011 8:02 PM
&g= t; To: cdni@ietf.org=
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >
> Section 2.3 Nomadic Users
>=A0=A0=A0 This description fa= lls under the category of Geographic Extension yet
> the third paragr= aph states the case where a different device is used in
> the same CD= N coverage area.=A0 The intent of this use case needs to be
> clarified.=A0 Perhaps the use case is trying to address the scenario w= here
> a Nomadic User-A with an agreement allowing access to content = from CSP-A
> via uCDN moves to a dCDN in a different region.=A0 The d= CDN is allowed to
> distribute the content of CSP-A to User-A; however, not other users in=
> the region of the dCDN are allowed to retrieve the content unless = they
> too have such an agreement.
>
> Section 5.1.3 Cont= ent Encoding Restrictions
>=A0=A0=A0 Need to clarify if we're talking about the restrictions o= n the
> delivery of specific content or the restrictions on the abili= ty of a CDN
> to deliver specific content.=A0 I certainly understand = the case where a
> CSP will restrict the distribution of content to a "managed path&= quot; if
> such content is HD while allowing the content distribution= via an
> un-managed path if such content is SD (same could apply to = encryption
> methods, delivery methods, etc.).=A0 On the contrary, the dCDN may hav= e
> its own restrictions of blocking the distribution of HD content w= hile
> allowing the distribution of SD content.
>
>=A0=A0= =A0 o first bullet makes sense if the dCDN can perform a subset of
> encapsulations for a reference set of media (e.g. HLS, HSS, but not DA= SH)
>=A0=A0=A0 o second bullet makes sense where the dCDN doesn't= want to offer high
> bit-rate variants of the media
>=A0=A0=A0= o third bullet make sense if the policy addresses QoE but I don't
> think subscriber rights/authorizations apply.
>
> Section = 10 Security Considerations
>
> Aside from the security consider= ations WITHIN the uCDN and dCDN, I think
> we can describe this in fo= ur contexts:
>
> a. The relationship between the CSP and the uCDN (the principl= e contract
> arrangement for distribution)
> b. The relationshi= p between the uCDN and dCDN (the transitive trust
> relationship that= extends the contract defined in (a) above)
> c. The relationship between the User and dCDN (the recognition of righ= t
> to download predicated on (b) above)
> d. The relationship = between the User and CSP (the contract authorizing
> the user access = to the content)
>
> The user is not interested in the a-b nor the b-c relationship= . The user
> is only interested in the transparency and interoperabil= ity of the
> security relationship between d-b or d-c to the point th= at the
> authorization granted in d-a is viable when the delivery is initiated<= br>> via either d-b or d-c.=A0 As an example, the uCDN might use URL app= ended
> tokens for authentication while dCDN might use URL appended h= ashes.=A0 The
> user doesn't want to know about the distinct methods, but transpar= ency
> is only afforded if the methods are interoperable clearly defi= ned when
> the delegation for content delivery is executed.=A0 Clearl= y, the choice of
> authentication method is determined by the respective CDN's.
&g= t;
> Scott
> _______________________________________________> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni

=A0

<= br>_______________________________________________
CDNi mailing list
= CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni


--0016364270620b812c04aecfdd88-- From kevin.ma@azukisystems.com Sat Oct 8 15:42:40 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 843BD21F8A95 for ; Sat, 8 Oct 2011 15:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYulRy5D9Cqd for ; Sat, 8 Oct 2011 15:42:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2312921F8A7A for ; Sat, 8 Oct 2011 15:42:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 45B198BE0A2; Sat, 8 Oct 2011 18:45:53 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 8A3768BD77C; Sat, 8 Oct 2011 18:45:52 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Sat, 8 Oct 2011 18:45:36 -0400 From: Kevin J Ma To: Vishwas Manral Date: Sat, 8 Oct 2011 18:45:49 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyF/XaBr943UW6IQyy30eeDeruWhwABCaCg Message-ID: <291CC3F9E50E7641901A54E85D0977C651B50AFBF1@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B4FF2383@MAILR002.mail.lan> <4E89BA77.4050903@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B50AEDAA@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Oct 2011 22:42:40 -0000 Hi Vishwas, Just to clarify, when you say "between the CDNs", we are still taking about CDNs authenticating end users, as opposed to CDNs authenticating each other, correct? I do think that CDNs will need to be able to authenticate with each other, but with respect to CDNs authenticating end users, I agree that it would be best if the CDNs agreed upon a single authentication method, and that delegation be denied if a dCDN cannot support the method specified by the uCDN. IMO, the way to do that is through opaque metadata. I do not think I was disagreeing with Scott, I just raised two issues to consider: 1) If the CP configures the uCDN with an authentication method and credentials, the CP does not necessarily give that uCDN=20 permission to pass those credentials along to a dCDN. 2) The client app cannot be expected to support authentication methods that are not known to the CP; the dCDNs cannot just select a method that the CP is unaware of. Going with an opaque metadata approach we can certainly define metadata for advertising authentication, beyond that, however, the CDN to client interface seems to be out of scope of CDNI? thanx. -- Kevin J. Ma From: Vishwas Manral [mailto:vishwas.ietf@gmail.com]=20 Sent: Saturday, October 08, 2011 5:02 PM To: Kevin J Ma Cc: Scott Wainner; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Kevin, =A0 I think Scott has a point when he says that we need to define some base aut= hentication method to be supported between the CDN's.=20 =A0 Ofcourse in particular cases if a particular authentication method is requi= red it could mean to disallow delegation to a dCDN. =A0 Thanks, Vishwas On Mon, Oct 3, 2011 at 11:27 AM, Kevin J Ma wro= te: Hi Scott, =A0 =A0 One option is that CPs that want strict authentication do not allow del= egation. =A0 In a non-interconnected environment, the CP has to configure the authen= tication =A0 method on each CDN?=A0 If the uCDN is going to delegate to a dCDN, the = uCDN would =A0have to configure the dCDN on behalf of the CP (passwords, certs, etc.)?= =A0 That =A0brings up other transative trust issues that this CP probably does not w= ant to =A0deal with?=A0 For other CPs, imo, end user transparency is the most impo= rtant. =A0 That could mean options 1 or 3 as you describe them below, or possibly = a proxy =A0where the dCDN sends the credentials to the uCDN for verification, so th= at the =A0client does not need to know anything about the dCDN? =A0 =A0 wrt the use case draft, do you feel that the security section needs exp= anded, or =A0 that additional use cases are required? =A0 thanx. =A0 --=A0 Kevin J. Ma =A0 From: Scott Wainner [mailto:swainner@cisco.com]=20 Sent: Monday, October 03, 2011 9:37 AM To: Kevin J Ma Cc: cdni@ietf.org=20 Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =A0 Kevin, =A0=A0=A0 My comments in-line ... On 9/30/11 10:45 AM, Kevin J Ma wrote:=20 Hi Scott, =A0 We are currently updating section 2.3.=A0 I think the nomadic use case =A0 includes not only geographic extension, but more generically footprint =A0 extension.=A0 A carrier CDN with only an in-network presense for specif= ic =A0 devices (e.g., mobile vs TV) may want to increase its device footprint =A0 by interconnecting with another local carrier CDN that supports other =A0 devices or subscribers.=A0 We are also looking at removing section 5.1.= 3. Understood. =A0 > As an example, the uCDN might use URL appended =A0 > tokens for authentication while dCDN might use URL appended hashes. =A0 ... =A0 > Clearly, the choice of =A0 > authentication method is determined by the respective CDN's. =A0 Content providers typically implement apps today with an understanding = that =A0 the uCDN has a specific authentication method.=A0 If the uCDN delegates =A0 delivery to a dCDN that the content provider has no relationship with, = the =A0 app may have no ability to switch authentication methods.=A0 Would the = uCDN be =A0 responsible for generating of the proper dCDN credentials for the user? That is exactly my point.=A0 I don't have an answer. The CSP may accept the uCDN's approach to authentication; however, that met= hod of authentication may not be supported on the dCDN which has the author= ity to choose its own method of authentication independent of the CSP. 1. Does the dCDN have to support multiple authentication methods - one for = each uCDN it establishes a relationship? 2. Does the uCDN have to support (and get approval from the CSP) for multip= le authentication methods - one for each dCDN for which it establishes a re= lationship? 3. Do we define a standard authentication method between the client and all= CDN such that the CSP approves one method and all uCDN and dCDN support th= e standard method? 4. Do we define a proxy authentication method where the dCDN authenticates = the client using their method of choice, the uCDN authenticates clients usi= ng their method of choice, AND CDNi defines a standard proxy method between= the dCDN and uCDN?=A0 In this case, the CSP must accept that the methods u= sed by dCDN and uCDN are equivalent but not necessarily the same. In what manner is the client informed of the appropriate method to authenti= cate their transaction with either the dCDN or uCDN? Scott thanx. --=A0 Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Scott Wainner > Sent: Thursday, September 29, 2011 8:02 PM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Section 2.3 Nomadic Users >=A0=A0=A0 This description falls under the category of Geographic Extensio= n yet > the third paragraph states the case where a different device is used in > the same CDN coverage area.=A0 The intent of this use case needs to be > clarified.=A0 Perhaps the use case is trying to address the scenario wher= e > a Nomadic User-A with an agreement allowing access to content from CSP-A > via uCDN moves to a dCDN in a different region.=A0 The dCDN is allowed to > distribute the content of CSP-A to User-A; however, not other users in > the region of the dCDN are allowed to retrieve the content unless they > too have such an agreement. > > Section 5.1.3 Content Encoding Restrictions >=A0=A0=A0 Need to clarify if we're talking about the restrictions on the > delivery of specific content or the restrictions on the ability of a CDN > to deliver specific content.=A0 I certainly understand the case where a > CSP will restrict the distribution of content to a "managed path" if > such content is HD while allowing the content distribution via an > un-managed path if such content is SD (same could apply to encryption > methods, delivery methods, etc.).=A0 On the contrary, the dCDN may have > its own restrictions of blocking the distribution of HD content while > allowing the distribution of SD content. > >=A0=A0=A0 o first bullet makes sense if the dCDN can perform a subset of > encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) >=A0=A0=A0 o second bullet makes sense where the dCDN doesn't want to offer= high > bit-rate variants of the media >=A0=A0=A0 o third bullet make sense if the policy addresses QoE but I don'= t > think subscriber rights/authorizations apply. > > Section 10 Security Considerations > > Aside from the security considerations WITHIN the uCDN and dCDN, I think > we can describe this in four contexts: > > a. The relationship between the CSP and the uCDN (the principle contract > arrangement for distribution) > b. The relationship between the uCDN and dCDN (the transitive trust > relationship that extends the contract defined in (a) above) > c. The relationship between the User and dCDN (the recognition of right > to download predicated on (b) above) > d. The relationship between the User and CSP (the contract authorizing > the user access to the content) > > The user is not interested in the a-b nor the b-c relationship. The user > is only interested in the transparency and interoperability of the > security relationship between d-b or d-c to the point that the > authorization granted in d-a is viable when the delivery is initiated > via either d-b or d-c.=A0 As an example, the uCDN might use URL appended > tokens for authentication while dCDN might use URL appended hashes.=A0 Th= e > user doesn't want to know about the distinct methods, but transparency > is only afforded if the methods are interoperable clearly defined when > the delegation for content delivery is executed.=A0 Clearly, the choice o= f > authentication method is determined by the respective CDN's. > > Scott > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni =A0 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Mon Oct 10 04:04:33 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6402921F8B40 for ; Mon, 10 Oct 2011 04:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJZAkGBgCM5m for ; Mon, 10 Oct 2011 04:04:32 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 356BA21F8ABE for ; Mon, 10 Oct 2011 04:04:31 -0700 (PDT) Received: from cpc10-cmbg15-2-0-cust121.5-4.cable.virginmedia.com ([86.30.246.122] helo=[192.168.0.3]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDDen-0006K6-JG; Mon, 10 Oct 2011 12:04:30 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> Date: Mon, 10 Oct 2011 12:04:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> To: ZhouZhipeng X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 11:04:33 -0000 Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content = Adaptation (i.e. taking in a content item in one format and transforming = it to another format or representation) is not a "core" function of a = CDN which typically delivers the content that is requested without = explicit knowledge of what that content actually is. Let's not forget that in building an end to end content service the CDN = is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. The decision as to which version/copy/representation to offer and allow = to be delivered to a given device/user is implemented outside of the CDN = (e.g. by the "portal" where the user first makes their content selection = prior to the CDN becoming involved in the delivery of the selected = content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. > If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. >=20 > Here the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content adaptation. > In last month, I have contacted the Authors of this document and taken = some email exchanges with Grant and Philip (BT). > I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. > Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. >=20 > If you have any more question or comments, pls share in this thread. > Thanks. > Zhipeng >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com]=20 > Sent: Friday, September 30, 2011 8:02 AM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Section 2.3 Nomadic Users > This description falls under the category of Geographic Extension = yet=20 > the third paragraph states the case where a different device is used = in=20 > the same CDN coverage area. The intent of this use case needs to be=20= > clarified. Perhaps the use case is trying to address the scenario = where=20 > a Nomadic User-A with an agreement allowing access to content from = CSP-A=20 > via uCDN moves to a dCDN in a different region. The dCDN is allowed = to=20 > distribute the content of CSP-A to User-A; however, not other users in=20= > the region of the dCDN are allowed to retrieve the content unless they=20= > too have such an agreement. >=20 > Section 5.1.3 Content Encoding Restrictions > Need to clarify if we're talking about the restrictions on the=20 > delivery of specific content or the restrictions on the ability of a = CDN=20 > to deliver specific content. I certainly understand the case where a=20= > CSP will restrict the distribution of content to a "managed path" if=20= > such content is HD while allowing the content distribution via an=20 > un-managed path if such content is SD (same could apply to encryption=20= > methods, delivery methods, etc.). On the contrary, the dCDN may have=20= > its own restrictions of blocking the distribution of HD content while=20= > allowing the distribution of SD content. >=20 > o first bullet makes sense if the dCDN can perform a subset of=20 > encapsulations for a reference set of media (e.g. HLS, HSS, but not = DASH) > o second bullet makes sense where the dCDN doesn't want to offer = high=20 > bit-rate variants of the media > o third bullet make sense if the policy addresses QoE but I don't=20 > think subscriber rights/authorizations apply. >=20 > Section 10 Security Considerations >=20 > Aside from the security considerations WITHIN the uCDN and dCDN, I = think=20 > we can describe this in four contexts: >=20 > a. The relationship between the CSP and the uCDN (the principle = contract=20 > arrangement for distribution) > b. The relationship between the uCDN and dCDN (the transitive trust=20 > relationship that extends the contract defined in (a) above) > c. The relationship between the User and dCDN (the recognition of = right=20 > to download predicated on (b) above) > d. The relationship between the User and CSP (the contract authorizing=20= > the user access to the content) >=20 > The user is not interested in the a-b nor the b-c relationship. The = user=20 > is only interested in the transparency and interoperability of the=20 > security relationship between d-b or d-c to the point that the=20 > authorization granted in d-a is viable when the delivery is initiated=20= > via either d-b or d-c. As an example, the uCDN might use URL appended=20= > tokens for authentication while dCDN might use URL appended hashes. = The=20 > user doesn't want to know about the distinct methods, but transparency=20= > is only afforded if the methods are interoperable clearly defined when=20= > the delegation for content delivery is executed. Clearly, the choice = of=20 > authentication method is determined by the respective CDN's. >=20 > Scott >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From philip.eardley@bt.com Mon Oct 10 08:22:05 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9736D21F8C1F for ; Mon, 10 Oct 2011 08:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwJTGYE-OQkA for ; Mon, 10 Oct 2011 08:22:04 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id C8BFA21F8C1C for ; Mon, 10 Oct 2011 08:22:02 -0700 (PDT) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 10 Oct 2011 16:22:00 +0100 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.5]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Mon, 10 Oct 2011 16:22:01 +0100 From: To: , Date: Mon, 10 Oct 2011 16:21:59 +0100 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyHPGa+0EWVuwvERiKPhgty4A9sbgAGvERA Message-ID: <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> In-Reply-To: <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2011 15:22:05 -0000 Ben, Zhipeng, all,=20 I think that Content Adaptation is more an issue for the Requirements doc t= han for the Use cases draft.=20 The key question is whether we want the CDNI interfaces to be able to cope = with a scenario where (say) HD/SD conversion is done in the dCDN & to signa= l about this. I think that coping with this scenario is a second order requirement, ie we= should not worry about it in the initial standards-track work. I don't kno= w, did we ever decide whether the Use cases doc is restricted to "initial" = scenarios, or whether it's all-encompassing, ie covering "future" scenarios= as well?=20 Scott, Reading some of your examples, they seem to be valid even if content adapta= tion (HD/SD) is out of scope.=20 - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the= capabilities & preferences of the CDNs & CSP), rather than metadata associ= ated with a particular piece of content. In the discussion so far, I think = negotiation about static policy stuff is rather out of scope(?) On security considerations, an interesting question is whether trust is tra= nsitive. Don't think it need be - just because CSP trusts uCDN, and uCDN tr= usts dCDN doesn't mean that the CSP automatically trusts the dCDN. However,= i suspect this can get arbitrarily complex - so one possibility is to say = that we will only handle cases where the trust is transitive. Best wishes phil Philip Eardley=A0=A0=A0 Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adapt= ation (i.e. taking in a content item in one format and transforming it to a= nother format or representation) is not a "core" function of a CDN which ty= pically delivers the content that is requested without explicit knowledge o= f what that content actually is. Let's not forget that in building an end to end content service the CDN is = only one component and is the component tasked with executing the delivery = of a specific representation (version/copy/format etc.) of the selected con= tent not the component tasked with deciding (or applying policy) on which v= ersion/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to = be delivered to a given device/user is implemented outside of the CDN (e.g.= by the "portal" where the user first makes their content selection prior t= o the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > Following Scott's comments on section 5.1.3, I feel Scott's description o= n the use case of HD and SD is not exactly correct. > If one movie has two formats of HD and SD, then we have two content with = different identifier. In DRM scope, the basic unit is a content copy. >=20 > Here the first bullet "a subset of encodings deliverable to specific devi= ces," has listed the case of content adaptation. > In last month, I have contacted the Authors of this document and taken so= me email exchanges with Grant and Philip (BT). > I have shown BT with some information that I know in this case and area t= o explain the content flexibility is currently a basic requirement for CDN = service and related negotiation is needed in the CDN interconnection. > Meanwhile, I should also invite you in this group raising your comments o= r questions on this case since I hope my use case may be incorporated in th= e use case draft. >=20 > If you have any more question or comments, pls share in this thread. > Thanks. > Zhipeng >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com]=20 > Sent: Friday, September 30, 2011 8:02 AM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Section 2.3 Nomadic Users > This description falls under the category of Geographic Extension yet=20 > the third paragraph states the case where a different device is used in=20 > the same CDN coverage area. The intent of this use case needs to be=20 > clarified. Perhaps the use case is trying to address the scenario where= =20 > a Nomadic User-A with an agreement allowing access to content from CSP-A= =20 > via uCDN moves to a dCDN in a different region. The dCDN is allowed to=20 > distribute the content of CSP-A to User-A; however, not other users in=20 > the region of the dCDN are allowed to retrieve the content unless they=20 > too have such an agreement. >=20 > Section 5.1.3 Content Encoding Restrictions > Need to clarify if we're talking about the restrictions on the=20 > delivery of specific content or the restrictions on the ability of a CDN= =20 > to deliver specific content. I certainly understand the case where a=20 > CSP will restrict the distribution of content to a "managed path" if=20 > such content is HD while allowing the content distribution via an=20 > un-managed path if such content is SD (same could apply to encryption=20 > methods, delivery methods, etc.). On the contrary, the dCDN may have=20 > its own restrictions of blocking the distribution of HD content while=20 > allowing the distribution of SD content. >=20 > o first bullet makes sense if the dCDN can perform a subset of=20 > encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) > o second bullet makes sense where the dCDN doesn't want to offer high=20 > bit-rate variants of the media > o third bullet make sense if the policy addresses QoE but I don't=20 > think subscriber rights/authorizations apply. >=20 > Section 10 Security Considerations >=20 > Aside from the security considerations WITHIN the uCDN and dCDN, I think= =20 > we can describe this in four contexts: >=20 > a. The relationship between the CSP and the uCDN (the principle contract= =20 > arrangement for distribution)=09 > b. The relationship between the uCDN and dCDN (the transitive trust=20 > relationship that extends the contract defined in (a) above) > c. The relationship between the User and dCDN (the recognition of right=20 > to download predicated on (b) above) > d. The relationship between the User and CSP (the contract authorizing=20 > the user access to the content) >=20 > The user is not interested in the a-b nor the b-c relationship. The user= =20 > is only interested in the transparency and interoperability of the=20 > security relationship between d-b or d-c to the point that the=20 > authorization granted in d-a is viable when the delivery is initiated=20 > via either d-b or d-c. As an example, the uCDN might use URL appended=20 > tokens for authentication while dCDN might use URL appended hashes. The= =20 > user doesn't want to know about the distinct methods, but transparency=20 > is only afforded if the methods are interoperable clearly defined when=20 > the delegation for content delivery is executed. Clearly, the choice of= =20 > authentication method is determined by the respective CDN's. >=20 > Scott >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From zhouzhipeng@huawei.com Mon Oct 10 21:20:23 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA7821F87F0 for ; Mon, 10 Oct 2011 21:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5wFmcPDv9N5 for ; Mon, 10 Oct 2011 21:20:22 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id EEB3821F8726 for ; Mon, 10 Oct 2011 21:20:21 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV002Y6VW6YI@szxga04-in.huawei.com> for cdni@ietf.org; Tue, 11 Oct 2011 12:16:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSV00I3VVW5PC@szxga04-in.huawei.com> for cdni@ietf.org; Tue, 11 Oct 2011 12:16:54 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AED93156; Tue, 11 Oct 2011 12:16:51 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 12:16:49 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 11 Oct 2011 12:16:42 +0800 Date: Tue, 11 Oct 2011 04:16:40 +0000 From: ZhouZhipeng In-reply-to: <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> X-Originating-IP: [10.138.73.38] To: "philip.eardley@bt.com" , "ben@niven-jenkins.co.uk" Message-id: <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 04:20:23 -0000 Ben and Philip, I like to respond your concern in this one email: Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct that= the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media type", e= tc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether the i= ssues such as "logging" "geographic constraint" are the core of CDN. For "without explicit knowledge of what that content actually is ", I am no= t sure whether the wording is accurate since generally a CDN may claim it s= upport different medias. By this opportunity, I like to share a use case: a call from a GSM phone to= a PSTN telephone, the voice stream should be transformed from GSM voice to= G.711. For the user, he does not need to know what type of data has been transferr= ed, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to this c= ase above. As for you said selecting media by the "portal", you may see the way " uCDN= delivers multiple media streams to dCDN" is not good than "uCDN delivers o= ne media stream to dCDN and dCDN takes some adaptation to support multiple = media types".=20 A good question is "security" since I have done six years on the DRM and li= ke to promote the DRM all around the world:) If the content is needed to be protected, generally you may know all the sy= stems should be granted by the content owner. Here I also like to clarify that not only the media itself but the informat= ion related to service itself (such as the geographic constraint) should be= protected also. So, trust is not a problem for the media. Philip, Thank you that you feel Content Adaption is an issue for "Requirements" but= I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it may s= ave investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile se= rvice and another system for the FBB service. But the reality is all operators ask us to provide a system that may suppor= t different service systems. Frankly, Ben and Philip, I remember I have explained somewhere that to impl= ement this is rather simple . At least the Use case and Requirement are informational to be referred in f= uture work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ben, Zhipeng, all,=20 I think that Content Adaptation is more an issue for the Requirements doc t= han for the Use cases draft.=20 The key question is whether we want the CDNI interfaces to be able to cope = with a scenario where (say) HD/SD conversion is done in the dCDN & to signa= l about this. I think that coping with this scenario is a second order requirement, ie we= should not worry about it in the initial standards-track work. I don't kno= w, did we ever decide whether the Use cases doc is restricted to "initial" = scenarios, or whether it's all-encompassing, ie covering "future" scenarios= as well?=20 Scott, Reading some of your examples, they seem to be valid even if content adapta= tion (HD/SD) is out of scope.=20 - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the= capabilities & preferences of the CDNs & CSP), rather than metadata associ= ated with a particular piece of content. In the discussion so far, I think = negotiation about static policy stuff is rather out of scope(?) On security considerations, an interesting question is whether trust is tra= nsitive. Don't think it need be - just because CSP trusts uCDN, and uCDN tr= usts dCDN doesn't mean that the CSP automatically trusts the dCDN. However,= i suspect this can get arbitrarily complex - so one possibility is to say = that we will only handle cases where the trust is transitive. Best wishes phil Philip Eardley=A0=A0=A0 Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adapt= ation (i.e. taking in a content item in one format and transforming it to a= nother format or representation) is not a "core" function of a CDN which ty= pically delivers the content that is requested without explicit knowledge o= f what that content actually is. Let's not forget that in building an end to end content service the CDN is = only one component and is the component tasked with executing the delivery = of a specific representation (version/copy/format etc.) of the selected con= tent not the component tasked with deciding (or applying policy) on which v= ersion/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to = be delivered to a given device/user is implemented outside of the CDN (e.g.= by the "portal" where the user first makes their content selection prior t= o the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > Following Scott's comments on section 5.1.3, I feel Scott's description o= n the use case of HD and SD is not exactly correct. > If one movie has two formats of HD and SD, then we have two content with = different identifier. In DRM scope, the basic unit is a content copy. >=20 > Here the first bullet "a subset of encodings deliverable to specific devi= ces," has listed the case of content adaptation. > In last month, I have contacted the Authors of this document and taken so= me email exchanges with Grant and Philip (BT). > I have shown BT with some information that I know in this case and area t= o explain the content flexibility is currently a basic requirement for CDN = service and related negotiation is needed in the CDN interconnection. > Meanwhile, I should also invite you in this group raising your comments o= r questions on this case since I hope my use case may be incorporated in th= e use case draft. >=20 > If you have any more question or comments, pls share in this thread. > Thanks. > Zhipeng >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com]=20 > Sent: Friday, September 30, 2011 8:02 AM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Section 2.3 Nomadic Users > This description falls under the category of Geographic Extension yet=20 > the third paragraph states the case where a different device is used in=20 > the same CDN coverage area. The intent of this use case needs to be=20 > clarified. Perhaps the use case is trying to address the scenario where= =20 > a Nomadic User-A with an agreement allowing access to content from CSP-A= =20 > via uCDN moves to a dCDN in a different region. The dCDN is allowed to=20 > distribute the content of CSP-A to User-A; however, not other users in=20 > the region of the dCDN are allowed to retrieve the content unless they=20 > too have such an agreement. >=20 > Section 5.1.3 Content Encoding Restrictions > Need to clarify if we're talking about the restrictions on the=20 > delivery of specific content or the restrictions on the ability of a CDN= =20 > to deliver specific content. I certainly understand the case where a=20 > CSP will restrict the distribution of content to a "managed path" if=20 > such content is HD while allowing the content distribution via an=20 > un-managed path if such content is SD (same could apply to encryption=20 > methods, delivery methods, etc.). On the contrary, the dCDN may have=20 > its own restrictions of blocking the distribution of HD content while=20 > allowing the distribution of SD content. >=20 > o first bullet makes sense if the dCDN can perform a subset of=20 > encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) > o second bullet makes sense where the dCDN doesn't want to offer high=20 > bit-rate variants of the media > o third bullet make sense if the policy addresses QoE but I don't=20 > think subscriber rights/authorizations apply. >=20 > Section 10 Security Considerations >=20 > Aside from the security considerations WITHIN the uCDN and dCDN, I think= =20 > we can describe this in four contexts: >=20 > a. The relationship between the CSP and the uCDN (the principle contract= =20 > arrangement for distribution)=09 > b. The relationship between the uCDN and dCDN (the transitive trust=20 > relationship that extends the contract defined in (a) above) > c. The relationship between the User and dCDN (the recognition of right=20 > to download predicated on (b) above) > d. The relationship between the User and CSP (the contract authorizing=20 > the user access to the content) >=20 > The user is not interested in the a-b nor the b-c relationship. The user= =20 > is only interested in the transparency and interoperability of the=20 > security relationship between d-b or d-c to the point that the=20 > authorization granted in d-a is viable when the delivery is initiated=20 > via either d-b or d-c. As an example, the uCDN might use URL appended=20 > tokens for authentication while dCDN might use URL appended hashes. The= =20 > user doesn't want to know about the distinct methods, but transparency=20 > is only afforded if the methods are interoperable clearly defined when=20 > the delegation for content delivery is executed. Clearly, the choice of= =20 > authentication method is determined by the respective CDN's. >=20 > Scott >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From hexiaoyan@huawei.com Tue Oct 11 02:28:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34FB21F8C47 for ; Tue, 11 Oct 2011 02:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvzVhi-r9qI6 for ; Tue, 11 Oct 2011 02:28:57 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 46A1F21F8C83 for ; Tue, 11 Oct 2011 02:28:57 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSW00D0SAAYQS@szxga03-in.huawei.com> for cdni@ietf.org; Tue, 11 Oct 2011 17:28:10 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSW005QXAAYGV@szxga03-in.huawei.com> for cdni@ietf.org; Tue, 11 Oct 2011 17:28:10 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ16880; Tue, 11 Oct 2011 17:28:09 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 17:28:07 +0800 Received: from w36710x (10.144.242.117) by smtpscn.huawei.com (10.82.67.136) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 11 Oct 2011 17:28:00 +0800 Date: Tue, 11 Oct 2011 17:27:46 +0800 From: HeXiaoyan In-reply-to: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> X-Originating-IP: [10.144.242.117] To: 'Kevin J Ma' , cdni@ietf.org Message-id: <010d01cc87f8$10bc5940$32350bc0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcyErDmDceDqNX+AQtKwjumpTmgL9wDNgegQ X-CFilter-Loop: Reflected References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 09:28:58 -0000 Hi Kevin, Some quick questions and comments on this draft, >The Metadata objects are each associated with a URI within the Domain and accessible through any of the Hostnames... - Could you further explain or give an example how a metadata is accessed by a Hostname within the Domain? And a further question is how the data model works if a metadata is only associated with a specific Hostname within one Doman? - The relationship between Agent objects and Metadata objects is a one-to-one relationship, does this mean one agent can only access one Metadata within one Domain? > The association of each Metadata to an Agent allows different Agents to retrieve different Metadata values for a given URI in the given Domain. - Don't understand why each Metadata object needs to be bind with an Agent explicitly, IMO, whether to return different value to different Agents is an inside process of the upCDN, what downCDN needs to do is just transmit its identifier to the upCDN when retrieve a Metadata. - Which entity is responsible for creating the Agent objects within one Domain? Does the CP can 'see' the downCDNs and creates corresponding Agent objects and other CDNs on the way just transmitted it or each upCDN located in the cascaded path creates a Agent object for each its downCDN? Thanks. Best Regards Xiaoyan(Susan) He -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Friday, October 07, 2011 1:21 PM To: cdni@ietf.org Subject: [CDNi] CDNI Metadata Interface Hi all, Just uploaded a new I-D with a proposed metadata model and API: http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt The model takes a rather generic approach to metadata representation to support opaque metadata and addresses some of the security issues associated with metadata retrieval. Comments welcome. thanx. -- Kevin J. Ma _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Tue Oct 11 05:12:39 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BED6021F8D8A for ; Tue, 11 Oct 2011 05:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Wx5hzbrqKIq for ; Tue, 11 Oct 2011 05:12:38 -0700 (PDT) Received: from mailoutb.tno.nl (mailoutb.tno.nl [134.221.1.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1460A21F8D75 for ; Tue, 11 Oct 2011 05:12:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,523,1312149600"; d="scan'208";a="13442812" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 11 Oct 2011 14:12:30 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.01.0323.003; Tue, 11 Oct 2011 14:12:30 +0200 From: "Brandenburg, R. (Ray) van" To: Ben Niven-Jenkins , ZhouZhipeng Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMeV9XVExcRrnYVk25qolmOBlG5JVk9BkAgA0NMICAA2MzAIABwOGQ Date: Tue, 11 Oct 2011 12:12:28 +0000 Message-ID: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> In-Reply-To: <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 12:12:39 -0000 Hi all, While I am neutral to the Content Adaptation discussion, I would like to ma= ke sure that we do not throw out all features related to multiple represent= ations, which would happen if we would just remove section 5.1.3 completely= as suggested by Ben.=20 The previous version of the use case document (betrand-02) had a slightly d= ifferent wording in section 2.4 than is now being used in section 5.1 of t= he new WG-version. I think the concept of resolution-based constraints, tha= t was included in betrand-02, should remain in some form. While it is not t= he CDNs responsibility/decision whether to allow a specific representation = to be delivered, I think a use case in which some dCDN only offers a subset= of the representations available on the uCDN is quite valid (such as in a = dedicated mobile CDN).=20 Ray -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: maandag 10 oktober 2011 13:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adapt= ation (i.e. taking in a content item in one format and transforming it to a= nother format or representation) is not a "core" function of a CDN which ty= pically delivers the content that is requested without explicit knowledge o= f what that content actually is. Let's not forget that in building an end to end content service the CDN is = only one component and is the component tasked with executing the delivery = of a specific representation (version/copy/format etc.) of the selected con= tent not the component tasked with deciding (or applying policy) on which v= ersion/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to = be delivered to a given device/user is implemented outside of the CDN (e.g.= by the "portal" where the user first makes their content selection prior t= o the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > Following Scott's comments on section 5.1.3, I feel Scott's description o= n the use case of HD and SD is not exactly correct. > If one movie has two formats of HD and SD, then we have two content with = different identifier. In DRM scope, the basic unit is a content copy. >=20 > Here the first bullet "a subset of encodings deliverable to specific devi= ces," has listed the case of content adaptation. > In last month, I have contacted the Authors of this document and taken so= me email exchanges with Grant and Philip (BT). > I have shown BT with some information that I know in this case and area t= o explain the content flexibility is currently a basic requirement for CDN = service and related negotiation is needed in the CDN interconnection. > Meanwhile, I should also invite you in this group raising your comments o= r questions on this case since I hope my use case may be incorporated in th= e use case draft. >=20 > If you have any more question or comments, pls share in this thread. > Thanks. > Zhipeng >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com] > Sent: Friday, September 30, 2011 8:02 AM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Section 2.3 Nomadic Users > This description falls under the category of Geographic Extension=20 > yet the third paragraph states the case where a different device is=20 > used in the same CDN coverage area. The intent of this use case needs=20 > to be clarified. Perhaps the use case is trying to address the=20 > scenario where a Nomadic User-A with an agreement allowing access to=20 > content from CSP-A via uCDN moves to a dCDN in a different region. =20 > The dCDN is allowed to distribute the content of CSP-A to User-A;=20 > however, not other users in the region of the dCDN are allowed to=20 > retrieve the content unless they too have such an agreement. >=20 > Section 5.1.3 Content Encoding Restrictions > Need to clarify if we're talking about the restrictions on the=20 > delivery of specific content or the restrictions on the ability of a=20 > CDN to deliver specific content. I certainly understand the case=20 > where a CSP will restrict the distribution of content to a "managed=20 > path" if such content is HD while allowing the content distribution=20 > via an un-managed path if such content is SD (same could apply to=20 > encryption methods, delivery methods, etc.). On the contrary, the=20 > dCDN may have its own restrictions of blocking the distribution of HD=20 > content while allowing the distribution of SD content. >=20 > o first bullet makes sense if the dCDN can perform a subset of=20 > encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) > o second bullet makes sense where the dCDN doesn't want to offer=20 > high bit-rate variants of the media > o third bullet make sense if the policy addresses QoE but I don't=20 > think subscriber rights/authorizations apply. >=20 > Section 10 Security Considerations >=20 > Aside from the security considerations WITHIN the uCDN and dCDN, I=20 > think we can describe this in four contexts: >=20 > a. The relationship between the CSP and the uCDN (the principle=20 > contract arrangement for distribution) b. The relationship between the=20 > uCDN and dCDN (the transitive trust relationship that extends the=20 > contract defined in (a) above) c. The relationship between the User=20 > and dCDN (the recognition of right to download predicated on (b)=20 > above) d. The relationship between the User and CSP (the contract=20 > authorizing the user access to the content) >=20 > The user is not interested in the a-b nor the b-c relationship. The=20 > user is only interested in the transparency and interoperability of=20 > the security relationship between d-b or d-c to the point that the=20 > authorization granted in d-a is viable when the delivery is initiated=20 > via either d-b or d-c. As an example, the uCDN might use URL appended=20 > tokens for authentication while dCDN might use URL appended hashes. =20 > The user doesn't want to know about the distinct methods, but=20 > transparency is only afforded if the methods are interoperable clearly=20 > defined when the delegation for content delivery is executed. =20 > Clearly, the choice of authentication method is determined by the respect= ive CDN's. >=20 > Scott >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From ben@niven-jenkins.co.uk Tue Oct 11 06:26:15 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8811621F8B9B for ; Tue, 11 Oct 2011 06:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z64Wrlw74lcI for ; Tue, 11 Oct 2011 06:26:15 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC7821F8BAA for ; Tue, 11 Oct 2011 06:26:14 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDcLV-0005po-6P; Tue, 11 Oct 2011 14:26:13 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 11 Oct 2011 14:26:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 13:26:15 -0000 On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: > Hi all, >=20 > While I am neutral to the Content Adaptation discussion, I would like = to make sure that we do not throw out all features related to multiple = representations, which would happen if we would just remove section = 5.1.3 completely as suggested by Ben.=20 I'm not sure how you draw that conclusion as removing section 5.1.3 does = not throw out the ability to support multiple representations IMO. > The previous version of the use case document (betrand-02) had a = slightly different wording in section 2.4 than is now being used in = section 5.1 of the new WG-version. I think the concept of = resolution-based constraints, that was included in betrand-02, should = remain in some form. While it is not the CDNs responsibility/decision = whether to allow a specific representation to be delivered, I think a = use case in which some dCDN only offers a subset of the representations = available on the uCDN is quite valid (such as in a dedicated mobile = CDN).=20 I don't believe that dCDNs will only offer a subset of representations = in the way you describe. They may only deliver to a subset of users (and = maybe by implication a subset of possible devices) for example as a = consequence of them being a dedicated mobile CDN (as opposed to an = active decision they make). Let's look at how a content service is deployed. A Content Provider has = some content (let's say a video) that the Content Provider may produce = in a variety of representations (codecs, bit rates, resolutions, etc.). = They may do that encoding themselves or outsource it (although that's = not relevant to the point I'm making). A User will connect to the Content Provider's "portal" (which may be a = web portal, an application, an EPG etc.). The Content Provider (through = their portal) will offer the User the content in one or more of the = available representations (e.g. by device type but how that decision is = made is purely up to the Content Provider). The User selects a = representation and the Content Provider offloads the delivery of that = representation to the CDN (e.g. by returning the appropriate URI for = that representation within the CDN to the User's client). The User then = connects to the CDN and requests the representation they have selected = (from the choice of representations offered to them by the Content = Provider). At its essence a CDN maps incoming URIs (from User's clients) to = specific content files on an upstream source (e.g. on-net storage or a = Content Provider's Origin server) it has no explicit knowledge of what = actual content that specific URI maps to or that it is one of X possible = representations of the same content. At no point has the CDN been involved in the selection or restriction of = the representations offered to or delivered to the User. In a CDNI = scenario things are no different. A uCDN may select a dCDN based on some = capability (e.g. what Users it can deliver to, what delivery protocols = it can support) but I do not think that the specific representation of = the content will enter into the equation beyond those constraints. For example, the dCDN is not going to say "I can only deliver = representations with resolutions below AxB" and the uCDN often will not = even know what the resolution or a particular representation is.=20 What might happen is that a User on a particular network (or using a = particular client/device) connects to the Content Provider's portal and = is only offered a subset of the possible representations tailored (by = the Content Provider's policy implemented in the Content Provider's = portal) based on that User's Network/Client/Device. A dCDN may = subsequently be selected that can serve that Network/Client/Service and = that dCDN may only end up delivering to its Users a subset of all the = possible representations the Content Provider has produced. But that is = a consequence of the Network/Clients/Devices the dCDN is capable of = serving, not an explicit decision made by the dCDN and communicated to = the uCDN for that specific Content Provider's service. Ben =20= From swainner@cisco.com Tue Oct 11 07:25:30 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E448821F86D0 for ; Tue, 11 Oct 2011 07:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7C1YG0Ds9bC for ; Tue, 11 Oct 2011 07:25:29 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 39C6A21F8669 for ; Tue, 11 Oct 2011 07:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=10667; q=dns/txt; s=iport; t=1318343127; x=1319552727; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=TpilGFjb82yw/s+M+AI8DwGYeRKCrVRNfXU+S124IVw=; b=SGv+B9n+JhDA4BouN7XxxqPzeN9f5FJi0fWcSojM7kY80kSr257XuKwN Lw7FKpsI1teMp8f6o263dHmil01ln9SP4KUlGWqJ3qmc9jQBTQgBTANnl Ii98DaGWcYTp8lGvRi8iMPbs4hkC39/ubFBS0lninIrz8+cNjQfnrtzH1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkAAGFRlE6rRDoG/2dsb2JhbABDmQSPJIEFgVMBAQEEAQEBDwElLwcEBgEMBAsRBAEBAQkWCAcJAwIBAgEPBh8JCAYNAQUCAQEeh2OaWwGeVQOHTASTdYorh0M X-IronPort-AV: E=Sophos;i="4.68,523,1312156800"; d="scan'208";a="7184778" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 11 Oct 2011 14:25:26 +0000 Received: from swainner-mac.local (stealth-10-32-245-61.cisco.com [10.32.245.61]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9BEPP82023181; Tue, 11 Oct 2011 14:25:25 GMT Message-ID: <4E945281.5030001@cisco.com> Date: Tue, 11 Oct 2011 10:28:17 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Kevin J Ma References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B4FF2383@MAILR002.mail.lan> <4E89BA77.4050903@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B50AEDAA@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C651B50AFBF1@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B50AFBF1@MAILR002.mail.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:25:31 -0000 On 10/8/11 6:45 PM, Kevin J Ma wrote: > Hi Vishwas, > > Just to clarify, when you say "between the CDNs", we are still > taking about CDNs authenticating end users, as opposed to CDNs > authenticating each other, correct? That was my intent. Each CDN will (most likely) want to use some means of authenticating the user for permission to download content. Since the CDN's are operated independently, they will likely independently choose their method of authentication and authorization. The point being the use case could describe a scenario where there is no authentication and authorization (we're just trying to find a way to deliver content efficiently) AND a use case can be described where there is authentication and authorization (between the client and the CDN). In the later case, we need to coordinate the method of authentication and authorization. 1. Default / Standard method for all CDN's? 2. Set of methods with order preference? Does the CP dictate the minimum level of authentication / authorization acceptable by ANY CDN used for deliver? In that case, the uCDN may support a method and the dCDN may or may not. A decision has to be made prior to delegating the content request to the dCDN. > > I do think that CDNs will need to be able to authenticate with > each other, but with respect to CDNs authenticating end users, > I agree that it would be best if the CDNs agreed upon a single > authentication method, and that delegation be denied if a dCDN > cannot support the method specified by the uCDN. IMO, the way > to do that is through opaque metadata. > > I do not think I was disagreeing with Scott, I just raised two > issues to consider: > 1) If the CP configures the uCDN with an authentication method > and credentials, the CP does not necessarily give that uCDN > permission to pass those credentials along to a dCDN. > 2) The client app cannot be expected to support authentication > methods that are not known to the CP; the dCDNs cannot just > select a method that the CP is unaware of. > > Going with an opaque metadata approach we can certainly define > metadata for advertising authentication, beyond that, however, > the CDN to client interface seems to be out of scope of CDNI? If the authentication / authorization between the client and the dCDN is a viable use case in CDNi, then I don't see how you can avoid at least defining a requirement for specifying a compatible means of authentication/authorization in order for CDNi to work. > > thanx. > > -- Kevin J. Ma > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > Sent: Saturday, October 08, 2011 5:02 PM > To: Kevin J Ma > Cc: Scott Wainner; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Hi Kevin, > > I think Scott has a point when he says that we need to define some base authentication method to be supported between the CDN's. > > Ofcourse in particular cases if a particular authentication method is required it could mean to disallow delegation to a dCDN. > > Thanks, > Vishwas > On Mon, Oct 3, 2011 at 11:27 AM, Kevin J Ma wrote: > Hi Scott, > > One option is that CPs that want strict authentication do not allow delegation. > In a non-interconnected environment, the CP has to configure the authentication > method on each CDN? If the uCDN is going to delegate to a dCDN, the uCDN would > have to configure the dCDN on behalf of the CP (passwords, certs, etc.)? That > brings up other transative trust issues that this CP probably does not want to > deal with? For other CPs, imo, end user transparency is the most important. > That could mean options 1 or 3 as you describe them below, or possibly a proxy > where the dCDN sends the credentials to the uCDN for verification, so that the > client does not need to know anything about the dCDN? > > wrt the use case draft, do you feel that the security section needs expanded, or > that additional use cases are required? > > thanx. > > -- Kevin J. Ma > > From: Scott Wainner [mailto:swainner@cisco.com] > Sent: Monday, October 03, 2011 9:37 AM > To: Kevin J Ma > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > My comments in-line ... > > On 9/30/11 10:45 AM, Kevin J Ma wrote: > Hi Scott, > > We are currently updating section 2.3. I think the nomadic use case > includes not only geographic extension, but more generically footprint > extension. A carrier CDN with only an in-network presense for specific > devices (e.g., mobile vs TV) may want to increase its device footprint > by interconnecting with another local carrier CDN that supports other > devices or subscribers. We are also looking at removing section 5.1.3. > Understood. > > > As an example, the uCDN might use URL appended > > tokens for authentication while dCDN might use URL appended hashes. > ... > > Clearly, the choice of > > authentication method is determined by the respective CDN's. > > Content providers typically implement apps today with an understanding that > the uCDN has a specific authentication method. If the uCDN delegates > delivery to a dCDN that the content provider has no relationship with, the > app may have no ability to switch authentication methods. Would the uCDN be > responsible for generating of the proper dCDN credentials for the user? > That is exactly my point. I don't have an answer. > > The CSP may accept the uCDN's approach to authentication; however, that method of authentication may not be supported on the dCDN which has the authority to choose its own method of authentication independent of the CSP. > > 1. Does the dCDN have to support multiple authentication methods - one for each uCDN it establishes a relationship? > > 2. Does the uCDN have to support (and get approval from the CSP) for multiple authentication methods - one for each dCDN for which it establishes a relationship? > > 3. Do we define a standard authentication method between the client and all CDN such that the CSP approves one method and all uCDN and dCDN support the standard method? > > 4. Do we define a proxy authentication method where the dCDN authenticates the client using their method of choice, the uCDN authenticates clients using their method of choice, AND CDNi defines a standard proxy method between the dCDN and uCDN? In this case, the CSP must accept that the methods used by dCDN and uCDN are equivalent but not necessarily the same. > > In what manner is the client informed of the appropriate method to authenticate their transaction with either the dCDN or uCDN? > > Scott > > thanx. > > -- Kevin J. Ma > >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> Scott Wainner >> Sent: Thursday, September 29, 2011 8:02 PM >> To: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> >> Section 2.3 Nomadic Users >> This description falls under the category of Geographic Extension yet >> the third paragraph states the case where a different device is used in >> the same CDN coverage area. The intent of this use case needs to be >> clarified. Perhaps the use case is trying to address the scenario where >> a Nomadic User-A with an agreement allowing access to content from CSP-A >> via uCDN moves to a dCDN in a different region. The dCDN is allowed to >> distribute the content of CSP-A to User-A; however, not other users in >> the region of the dCDN are allowed to retrieve the content unless they >> too have such an agreement. >> >> Section 5.1.3 Content Encoding Restrictions >> Need to clarify if we're talking about the restrictions on the >> delivery of specific content or the restrictions on the ability of a CDN >> to deliver specific content. I certainly understand the case where a >> CSP will restrict the distribution of content to a "managed path" if >> such content is HD while allowing the content distribution via an >> un-managed path if such content is SD (same could apply to encryption >> methods, delivery methods, etc.). On the contrary, the dCDN may have >> its own restrictions of blocking the distribution of HD content while >> allowing the distribution of SD content. >> >> o first bullet makes sense if the dCDN can perform a subset of >> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) >> o second bullet makes sense where the dCDN doesn't want to offer high >> bit-rate variants of the media >> o third bullet make sense if the policy addresses QoE but I don't >> think subscriber rights/authorizations apply. >> >> Section 10 Security Considerations >> >> Aside from the security considerations WITHIN the uCDN and dCDN, I think >> we can describe this in four contexts: >> >> a. The relationship between the CSP and the uCDN (the principle contract >> arrangement for distribution) >> b. The relationship between the uCDN and dCDN (the transitive trust >> relationship that extends the contract defined in (a) above) >> c. The relationship between the User and dCDN (the recognition of right >> to download predicated on (b) above) >> d. The relationship between the User and CSP (the contract authorizing >> the user access to the content) >> >> The user is not interested in the a-b nor the b-c relationship. The user >> is only interested in the transparency and interoperability of the >> security relationship between d-b or d-c to the point that the >> authorization granted in d-a is viable when the delivery is initiated >> via either d-b or d-c. As an example, the uCDN might use URL appended >> tokens for authentication while dCDN might use URL appended hashes. The >> user doesn't want to know about the distinct methods, but transparency >> is only afforded if the methods are interoperable clearly defined when >> the delegation for content delivery is executed. Clearly, the choice of >> authentication method is determined by the respective CDN's. >> >> Scott >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > From swainner@cisco.com Tue Oct 11 07:39:39 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9EC21F8DCC for ; Tue, 11 Oct 2011 07:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gH6I+34Ovjn8 for ; Tue, 11 Oct 2011 07:39:37 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C7D5A21F8DCB for ; Tue, 11 Oct 2011 07:39:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=19156; q=dns/txt; s=iport; t=1318343977; x=1319553577; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Im7q7a927tZRnDnylg5lLLN9k+6CtstW7chS6T5sj1g=; b=PIoV+w1p22yvDGv9m4xj38QlDYd5Rp4S2CtOjTw7RKYGL+5QrLFHZBlX LHIvIUVLfpMP//0I3TfB9iCEDpjPkzahQdbvQcR3lRa6TPeOhfjNPnxoD rOseTDIMxduJECOCiu/bX/uLINJGnjXRZbX/sYlPGr1Yg+oit3HbAxY6l U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkAAINUlE6rRDoG/2dsb2JhbABDmQSPJIEFgVMBAQEDAQEBAQ8BGkEEBwUHBAsRBAEBAQkeBw8CFh8JCAYNAQUCAQEeh1wHmk4BnlcDh0wEk3WRbg X-IronPort-AV: E=Sophos;i="4.68,523,1312156800"; d="scan'208,217";a="7170726" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 11 Oct 2011 14:39:37 +0000 Received: from swainner-mac.local (stealth-10-32-245-61.cisco.com [10.32.245.61]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9BEdaTp031607; Tue, 11 Oct 2011 14:39:36 GMT Message-ID: <4E9455D5.50708@cisco.com> Date: Tue, 11 Oct 2011 10:42:29 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ben Niven-Jenkins References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> In-Reply-To: <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> Content-Type: multipart/alternative; boundary="------------050804060000040301060405" Cc: cdni@ietf.org, ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:39:39 -0000 This is a multi-part message in MIME format. --------------050804060000040301060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/10/11 7:04 AM, Ben Niven-Jenkins wrote: > > Colleagues, > > IMO Section 5.1.3 should be removed from the Use Cases draft. Content > Adaptation (i.e. taking in a content item in one format and > transforming it to another format or representation) is not a "core" > function of a CDN which typically delivers the content that is > requested without explicit knowledge of what that content actually is. > I tend to agree. Although content adaptation may be desirable, it's not clear that we could effectively bound the number permutations of content adaptation that may be possible (encryption, watermark, transrate, transcode, etc.) > > > Let's not forget that in building an end to end content service the > CDN is only one component and is the component tasked with executing > the delivery of a specific representation (version/copy/format etc.) > of the selected content not the component tasked with deciding (or > applying policy) on which version/copy/representation of content > should be delivered. > > The decision as to which version/copy/representation to offer and > allow to be delivered to a given device/user is implemented outside of > the CDN (e.g. by the "portal" where the user first makes their content > selection prior to the CDN becoming involved in the delivery of the > selected content). > Agreed. This means the portal makes a decision about the specific content object without regard to the capabilities of the CDN(s). There is a presumption that the set of CDN's can deliver the content. That assumption has a high probability of success with regards to the relationship between the uCDN and CP because there is an explicit business relationship. That assumption may not be valid when dealing with a dCDN that has a business relationship with the uCDN. So let's assume there is ONE URL that is provided by the CP (portal) for the asset. If that URL makes sense ONLY on the uCDN, then somewhere outside of the CP (portal) a decision must be made to re-write the URL such that it is appropriate for the dCDN. That can be a simple re-write (modified FQDN with same PATH) or a more complex re-write (modified FQDN and PATH). Are we bounding the use case ONLY those scenarios where the PATH structure remains unmodified and we're only changing the delivery point? In this case, the uCDN and every dCDN would understand how to handle the exact same PATH structure. If the use case is expanded to include the URL PATH re-write, where would this be done? If the CP (portal) does it, it needs to know information about which CDN will be used in order to pick the correct URL structure. Otherwise, the uCDN must do the re-write into the appropriate PATH structure for the dCDN. Is this in scope or not? Scott > > > Ben > > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > > Following Scott's comments on section 5.1.3, I feel Scott's > description on the use case of HD and SD is not exactly correct. > > If one movie has two formats of HD and SD, then we have two content > with different identifier. In DRM scope, the basic unit is a content copy. > > > > Here the first bullet "a subset of encodings deliverable to specific > devices," has listed the case of content adaptation. > > In last month, I have contacted the Authors of this document and > taken some email exchanges with Grant and Philip (BT). > > I have shown BT with some information that I know in this case and > area to explain the content flexibility is currently a basic > requirement for CDN service and related negotiation is needed in the > CDN interconnection. > > Meanwhile, I should also invite you in this group raising your > comments or questions on this case since I hope my use case may be > incorporated in the use case draft. > > > > If you have any more question or comments, pls share in this thread. > > Thanks. > > Zhipeng > > > > > > > > > > > > > > -----Original Message----- > > From: Scott Wainner [mailto:swainner@cisco.com] > > Sent: Friday, September 30, 2011 8:02 AM > > To: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Section 2.3 Nomadic Users > > This description falls under the category of Geographic Extension yet > > the third paragraph states the case where a different device is used in > > the same CDN coverage area. The intent of this use case needs to be > > clarified. Perhaps the use case is trying to address the scenario where > > a Nomadic User-A with an agreement allowing access to content from CSP-A > > via uCDN moves to a dCDN in a different region. The dCDN is allowed to > > distribute the content of CSP-A to User-A; however, not other users in > > the region of the dCDN are allowed to retrieve the content unless they > > too have such an agreement. > > > > Section 5.1.3 Content Encoding Restrictions > > Need to clarify if we're talking about the restrictions on the > > delivery of specific content or the restrictions on the ability of a CDN > > to deliver specific content. I certainly understand the case where a > > CSP will restrict the distribution of content to a "managed path" if > > such content is HD while allowing the content distribution via an > > un-managed path if such content is SD (same could apply to encryption > > methods, delivery methods, etc.). On the contrary, the dCDN may have > > its own restrictions of blocking the distribution of HD content while > > allowing the distribution of SD content. > > > > o first bullet makes sense if the dCDN can perform a subset of > > encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) > > o second bullet makes sense where the dCDN doesn't want to offer high > > bit-rate variants of the media > > o third bullet make sense if the policy addresses QoE but I don't > > think subscriber rights/authorizations apply. > > > > Section 10 Security Considerations > > > > Aside from the security considerations WITHIN the uCDN and dCDN, I think > > we can describe this in four contexts: > > > > a. The relationship between the CSP and the uCDN (the principle contract > > arrangement for distribution) > > b. The relationship between the uCDN and dCDN (the transitive trust > > relationship that extends the contract defined in (a) above) > > c. The relationship between the User and dCDN (the recognition of right > > to download predicated on (b) above) > > d. The relationship between the User and CSP (the contract authorizing > > the user access to the content) > > > > The user is not interested in the a-b nor the b-c relationship. The user > > is only interested in the transparency and interoperability of the > > security relationship between d-b or d-c to the point that the > > authorization granted in d-a is viable when the delivery is initiated > > via either d-b or d-c. As an example, the uCDN might use URL appended > > tokens for authentication while dCDN might use URL appended hashes. The > > user doesn't want to know about the distinct methods, but transparency > > is only afforded if the methods are interoperable clearly defined when > > the delegation for content delivery is executed. Clearly, the choice of > > authentication method is determined by the respective CDN's. > > > > Scott > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > --------------050804060000040301060405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/10/11 7:04 AM, Ben Niven-Jenkins wrote:
Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Colleagues,

IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is.

I tend to agree.  Although content adaptation may be desirable, it's not clear that we could effectively bound the number permutations of content adaptation that may be possible (encryption, watermark, transrate, transcode, etc.)


Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered.

The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content).

Agreed.  This means the portal makes a decision about the specific content object without regard to the capabilities of the CDN(s).  There is a presumption that the set of CDN's can deliver the content.  That assumption has a high probability of success with regards to the relationship between the uCDN and CP because there is an explicit business relationship.  That assumption may not be valid when dealing with a dCDN that has a business relationship with the uCDN.

So let's assume there is ONE URL that is provided by the CP (portal) for the asset.  If that URL makes sense ONLY on the uCDN, then somewhere outside of the CP (portal) a decision must be made to re-write the URL such that it is appropriate for the dCDN.  That can be a simple re-write (modified FQDN with same PATH) or a more complex re-write (modified FQDN and PATH).

Are we bounding the use case ONLY those scenarios where the PATH structure remains unmodified and we're only changing the delivery point?  In this case, the uCDN and every dCDN would understand how to handle the exact same PATH structure.

If the use case is expanded to include the URL PATH re-write, where would this be done?  If the CP (portal) does it, it needs to know information about which CDN will be used in order to pick the correct URL structure.  Otherwise, the uCDN must do the re-write into the appropriate PATH structure for the dCDN.  Is this in scope or not?

Scott


Ben

On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:

> Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct.
> If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy.
>
> Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation.
> In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT).
> I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection.
> Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft.
>
> If you have any more question or comments, pls share in this thread.
> Thanks.
> Zhipeng
>
>
>
>
>
>
> -----Original Message-----
> From: Scott Wainner [mailto:swainner@cisco.com]
> Sent: Friday, September 30, 2011 8:02 AM
> To: cdni@ietf.org
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Section 2.3 Nomadic Users
>   This description falls under the category of Geographic Extension yet
> the third paragraph states the case where a different device is used in
> the same CDN coverage area.  The intent of this use case needs to be
> clarified.  Perhaps the use case is trying to address the scenario where
> a Nomadic User-A with an agreement allowing access to content from CSP-A
> via uCDN moves to a dCDN in a different region.  The dCDN is allowed to
> distribute the content of CSP-A to User-A; however, not other users in
> the region of the dCDN are allowed to retrieve the content unless they
> too have such an agreement.
>
> Section 5.1.3 Content Encoding Restrictions
>   Need to clarify if we're talking about the restrictions on the
> delivery of specific content or the restrictions on the ability of a CDN
> to deliver specific content.  I certainly understand the case where a
> CSP will restrict the distribution of content to a "managed path" if
> such content is HD while allowing the content distribution via an
> un-managed path if such content is SD (same could apply to encryption
> methods, delivery methods, etc.).  On the contrary, the dCDN may have
> its own restrictions of blocking the distribution of HD content while
> allowing the distribution of SD content.
>
>   o first bullet makes sense if the dCDN can perform a subset of
> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH)
>   o second bullet makes sense where the dCDN doesn't want to offer high
> bit-rate variants of the media
>   o third bullet make sense if the policy addresses QoE but I don't
> think subscriber rights/authorizations apply.
>
> Section 10 Security Considerations
>
> Aside from the security considerations WITHIN the uCDN and dCDN, I think
> we can describe this in four contexts:
>
> a. The relationship between the CSP and the uCDN (the principle contract
> arrangement for distribution)
> b. The relationship between the uCDN and dCDN (the transitive trust
> relationship that extends the contract defined in (a) above)
> c. The relationship between the User and dCDN (the recognition of right
> to download predicated on (b) above)
> d. The relationship between the User and CSP (the contract authorizing
> the user access to the content)
>
> The user is not interested in the a-b nor the b-c relationship. The user
> is only interested in the transparency and interoperability of the
> security relationship between d-b or d-c to the point that the
> authorization granted in d-a is viable when the delivery is initiated
> via either d-b or d-c.  As an example, the uCDN might use URL appended
> tokens for authentication while dCDN might use URL appended hashes.  The
> user doesn't want to know about the distinct methods, but transparency
> is only afforded if the methods are interoperable clearly defined when
> the delegation for content delivery is executed.  Clearly, the choice of
> authentication method is determined by the respective CDN's.
>
> Scott
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni


--------------050804060000040301060405-- From swainner@cisco.com Tue Oct 11 07:47:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8A421F8DD3 for ; Tue, 11 Oct 2011 07:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 762w75BbGOxg for ; Tue, 11 Oct 2011 07:47:57 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0A74521F8C5D for ; Tue, 11 Oct 2011 07:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=25302; q=dns/txt; s=iport; t=1318344477; x=1319554077; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=wGjxJsecv5pJQOhB9/sKE/KYkASI1+/wZX7rcn6zjrA=; b=gEV7jKBDvXJeuZH3+XWZzxKAhoM3QQJVlVrB8BO8jlKm2oOGOD5MM5E4 2DIdlpohTIf2lIjyvKjSyHNpKIehEcZBOjkb5khRRatssxbP74bZzvNoV 9fUS0k7ugtQzYSCaUaLRPbqmAJ0DI8rUTUqCObT4De8AL8mOcyo2wn1Ax 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkAANdWlE6rRDoG/2dsb2JhbABDmQSPJIEFgVMBAQEDAQEBAQ8BGkEEBgYHAgILEQQBAQEJFggHCQMCAQIBBBEfCQgTBgIBAR6HXAeaUAGeVwMCh0oEk3WRbg X-IronPort-AV: E=Sophos;i="4.68,523,1312156800"; d="scan'208,217";a="7172295" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 11 Oct 2011 14:47:56 +0000 Received: from swainner-mac.local (stealth-10-32-245-61.cisco.com [10.32.245.61]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9BEltnR003511 for ; Tue, 11 Oct 2011 14:47:55 GMT Message-ID: <4E9457C8.9000705@cisco.com> Date: Tue, 11 Oct 2011 10:50:48 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: cdni@ietf.org References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com><4E8506FC.1020701@cisco.com><260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com><853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> Content-Type: multipart/alternative; boundary="------------090607050807080706000708" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:47:58 -0000 This is a multi-part message in MIME format. --------------090607050807080706000708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/10/11 11:21 AM, philip.eardley@bt.com wrote: > > Ben, Zhipeng, all, > > I think that Content Adaptation is more an issue for the Requirements > doc than for the Use cases draft. > > The key question is whether we want the CDNI interfaces to be able to > cope with a scenario where (say) HD/SD conversion is done in the dCDN > & to signal about this. > > I think that coping with this scenario is a second order requirement, > ie we should not worry about it in the initial standards-track work. I > don't know, did we ever decide whether the Use cases doc is restricted > to "initial" scenarios, or whether it's all-encompassing, ie covering > "future" scenarios as well? > > Scott, > Reading some of your examples, they seem to be valid even if content > adaptation (HD/SD) is out of scope. > - a dCDN might for some reason be unwilling to distribute HD? > Exactly my point. Lot's of policy constraints here some of which are defined by the CP and some of which are defined by the dCDN. Example: CP only allows content to be delivered over network infrastructure that uCDN owns (no delegation allowed) Example: dCDN doesn't want to allow HD streams over their low-bandwidth network infrastructure. Example: uCDN decides its more economical to deliver from their own network as opposed to a dCDN > > - a CSP might want to make sure the dCDN can use HLS encapsulation? > But these sorts of examples seem to be static policy things (to do > with the capabilities & preferences of the CDNs & CSP), rather than > metadata associated with a particular piece of content. In the > discussion so far, I think negotiation about static policy stuff is > rather out of scope(?) > Policy - communicated by people or by protocol. Certainly, the simple case is the communication by people with static configuration in which case we need no protocol. The question is what policy attributes are in scope and which ones are out of scope. > > > On security considerations, an interesting question is whether trust > is transitive. Don't think it need be - just because CSP trusts uCDN, > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > the dCDN. > I would think that this is the norm (the CSP does NOT implicitly trust a dCDN). With a well defined framework, the CSP may be persuaded to trust a dCDN under certain conditions. > > However, i suspect this can get arbitrarily complex - so one > possibility is to say that we will only handle cases where the trust > is transitive. > That is the fundamental question ... are we only dealing with cases where trust is transitive and there is presumably a common method of enforcing that transitive trust. Scott > > > Best wishes > phil > > > Philip Eardley > Research and Technology Strategy > > This email contains BT information, which may be privileged or > confidential. It's meant only for the individual(s) or entity named > above. If you're not the intended recipient, note that disclosing, > copying, distributing or using this information is prohibited. If > you've received this email in error, please let me know immediately on > the email address above. Thank you. We monitor our email system, and > may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: 10 October 2011 12:04 > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Colleagues, > > IMO Section 5.1.3 should be removed from the Use Cases draft. Content > Adaptation (i.e. taking in a content item in one format and > transforming it to another format or representation) is not a "core" > function of a CDN which typically delivers the content that is > requested without explicit knowledge of what that content actually is. > > Let's not forget that in building an end to end content service the > CDN is only one component and is the component tasked with executing > the delivery of a specific representation (version/copy/format etc.) > of the selected content not the component tasked with deciding (or > applying policy) on which version/copy/representation of content > should be delivered. > > The decision as to which version/copy/representation to offer and > allow to be delivered to a given device/user is implemented outside of > the CDN (e.g. by the "portal" where the user first makes their content > selection prior to the CDN becoming involved in the delivery of the > selected content). > > Ben > > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > > Following Scott's comments on section 5.1.3, I feel Scott's > description on the use case of HD and SD is not exactly correct. > > If one movie has two formats of HD and SD, then we have two content > with different identifier. In DRM scope, the basic unit is a content copy. > > > > Here the first bullet "a subset of encodings deliverable to specific > devices," has listed the case of content adaptation. > > In last month, I have contacted the Authors of this document and > taken some email exchanges with Grant and Philip (BT). > > I have shown BT with some information that I know in this case and > area to explain the content flexibility is currently a basic > requirement for CDN service and related negotiation is needed in the > CDN interconnection. > > Meanwhile, I should also invite you in this group raising your > comments or questions on this case since I hope my use case may be > incorporated in the use case draft. > > > > If you have any more question or comments, pls share in this thread. > > Thanks. > > Zhipeng > > > > > > > > > > > > > > -----Original Message----- > > From: Scott Wainner [mailto:swainner@cisco.com] > > Sent: Friday, September 30, 2011 8:02 AM > > To: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Section 2.3 Nomadic Users > > This description falls under the category of Geographic Extension yet > > the third paragraph states the case where a different device is used in > > the same CDN coverage area. The intent of this use case needs to be > > clarified. Perhaps the use case is trying to address the scenario where > > a Nomadic User-A with an agreement allowing access to content from CSP-A > > via uCDN moves to a dCDN in a different region. The dCDN is allowed to > > distribute the content of CSP-A to User-A; however, not other users in > > the region of the dCDN are allowed to retrieve the content unless they > > too have such an agreement. > > > > Section 5.1.3 Content Encoding Restrictions > > Need to clarify if we're talking about the restrictions on the > > delivery of specific content or the restrictions on the ability of a CDN > > to deliver specific content. I certainly understand the case where a > > CSP will restrict the distribution of content to a "managed path" if > > such content is HD while allowing the content distribution via an > > un-managed path if such content is SD (same could apply to encryption > > methods, delivery methods, etc.). On the contrary, the dCDN may have > > its own restrictions of blocking the distribution of HD content while > > allowing the distribution of SD content. > > > > o first bullet makes sense if the dCDN can perform a subset of > > encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) > > o second bullet makes sense where the dCDN doesn't want to offer high > > bit-rate variants of the media > > o third bullet make sense if the policy addresses QoE but I don't > > think subscriber rights/authorizations apply. > > > > Section 10 Security Considerations > > > > Aside from the security considerations WITHIN the uCDN and dCDN, I think > > we can describe this in four contexts: > > > > a. The relationship between the CSP and the uCDN (the principle contract > > arrangement for distribution) > > b. The relationship between the uCDN and dCDN (the transitive trust > > relationship that extends the contract defined in (a) above) > > c. The relationship between the User and dCDN (the recognition of right > > to download predicated on (b) above) > > d. The relationship between the User and CSP (the contract authorizing > > the user access to the content) > > > > The user is not interested in the a-b nor the b-c relationship. The user > > is only interested in the transparency and interoperability of the > > security relationship between d-b or d-c to the point that the > > authorization granted in d-a is viable when the delivery is initiated > > via either d-b or d-c. As an example, the uCDN might use URL appended > > tokens for authentication while dCDN might use URL appended hashes. The > > user doesn't want to know about the distinct methods, but transparency > > is only afforded if the methods are interoperable clearly defined when > > the delegation for content delivery is executed. Clearly, the choice of > > authentication method is determined by the respective CDN's. > > > > Scott > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --------------090607050807080706000708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/10/11 11:21 AM, philip.eardley@bt.com wrote:
Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft.

The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this.

I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well?

Scott,
Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope.
- a dCDN might for some reason be unwilling to distribute HD?

Exactly my point.  Lot's of policy constraints here some of which are defined by the CP and some of which are defined by the dCDN.
Example: CP only allows content to be delivered over network infrastructure that uCDN owns (no delegation allowed)
Example: dCDN doesn't want to allow HD streams over their low-bandwidth network infrastructure.
Example: uCDN decides its more economical to deliver from their own network as opposed to a dCDN

- a CSP might want to make sure the dCDN can use HLS encapsulation?
But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?)

Policy - communicated by people or by protocol.  Certainly, the simple case is the communication by people with static configuration in which case we need no protocol.  The question is what policy attributes are in scope and which ones are out of scope.


On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN.

I would think that this is the norm (the CSP does NOT implicitly trust a dCDN).  With a well defined framework, the CSP may be persuaded to trust a dCDN under certain conditions.

However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive.

That is the fundamental question ... are we only dealing with cases where trust is transitive and there is presumably a common method of enforcing that transitive trust.

Scott


Best wishes
phil


Philip Eardley   
Research and Technology Strategy

This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails.
British Telecommunications plc
Registered office: 81 Newgate Street London EC1A 7AJ
Registered in England no: 1800000


-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: 10 October 2011 12:04
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Colleagues,

IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is.

Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered.

The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content).

Ben

On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:

> Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct.
> If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy.
>
> Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation.
> In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT).
> I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection.
> Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft.
>
> If you have any more question or comments, pls share in this thread.
> Thanks.
> Zhipeng
>
>
>
>
>
>
> -----Original Message-----
> From: Scott Wainner [mailto:swainner@cisco.com]
> Sent: Friday, September 30, 2011 8:02 AM
> To: cdni@ietf.org
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Section 2.3 Nomadic Users
>   This description falls under the category of Geographic Extension yet
> the third paragraph states the case where a different device is used in
> the same CDN coverage area.  The intent of this use case needs to be
> clarified.  Perhaps the use case is trying to address the scenario where
> a Nomadic User-A with an agreement allowing access to content from CSP-A
> via uCDN moves to a dCDN in a different region.  The dCDN is allowed to
> distribute the content of CSP-A to User-A; however, not other users in
> the region of the dCDN are allowed to retrieve the content unless they
> too have such an agreement.
>
> Section 5.1.3 Content Encoding Restrictions
>   Need to clarify if we're talking about the restrictions on the
> delivery of specific content or the restrictions on the ability of a CDN
> to deliver specific content.  I certainly understand the case where a
> CSP will restrict the distribution of content to a "managed path" if
> such content is HD while allowing the content distribution via an
> un-managed path if such content is SD (same could apply to encryption
> methods, delivery methods, etc.).  On the contrary, the dCDN may have
> its own restrictions of blocking the distribution of HD content while
> allowing the distribution of SD content.
>
>   o first bullet makes sense if the dCDN can perform a subset of
> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH)
>   o second bullet makes sense where the dCDN doesn't want to offer high
> bit-rate variants of the media
>   o third bullet make sense if the policy addresses QoE but I don't
> think subscriber rights/authorizations apply.
>
> Section 10 Security Considerations
>
> Aside from the security considerations WITHIN the uCDN and dCDN, I think
> we can describe this in four contexts:
>
> a. The relationship between the CSP and the uCDN (the principle contract
> arrangement for distribution)
> b. The relationship between the uCDN and dCDN (the transitive trust
> relationship that extends the contract defined in (a) above)
> c. The relationship between the User and dCDN (the recognition of right
> to download predicated on (b) above)
> d. The relationship between the User and CSP (the contract authorizing
> the user access to the content)
>
> The user is not interested in the a-b nor the b-c relationship. The user
> is only interested in the transparency and interoperability of the
> security relationship between d-b or d-c to the point that the
> authorization granted in d-a is viable when the delivery is initiated
> via either d-b or d-c.  As an example, the uCDN might use URL appended
> tokens for authentication while dCDN might use URL appended hashes.  The
> user doesn't want to know about the distinct methods, but transparency
> is only afforded if the methods are interoperable clearly defined when
> the delegation for content delivery is executed.  Clearly, the choice of
> authentication method is determined by the respective CDN's.
>
> Scott
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni


--------------090607050807080706000708-- From kevin.ma@azukisystems.com Tue Oct 11 07:49:40 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68A721F8DDF for ; Tue, 11 Oct 2011 07:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSXJaJzfybMo for ; Tue, 11 Oct 2011 07:49:40 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 20A6D21F8DDB for ; Tue, 11 Oct 2011 07:49:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BA30C55308D; Tue, 11 Oct 2011 10:49:38 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8D6D2555003; Tue, 11 Oct 2011 10:49:05 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 11 Oct 2011 10:48:53 -0400 From: Kevin J Ma To: Ben Niven-Jenkins , "Brandenburg, R. (Ray) van" Date: Tue, 11 Oct 2011 10:48:56 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyIGWf4Tqq15vTsR5yFyQRr+fsl1wAAuAHg Message-ID: <291CC3F9E50E7641901A54E85D0977C651B5151768@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:49:40 -0000 Hi Ben, I do not disagree with the statements made below, however, I think that there is one point that is missing: in a non-interconnected world, CPs can (and do) put different representations into different CDNs, knowing that representation-A will not be accessible via CDN-B. It is true that the CDN did not make any decision, the CP did, however, the enforcement is based on the fact that those CDNs will not share with each other and are physically separated. With CDNI, if the uCDN has access to all representations but the CP needs to enforce that specific dCDNs only have access to subsets of representations (due to content licensing restrictions), enforcing that probably requires metadata to describe those delivery restrictions? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > Sent: Tuesday, October 11, 2011 9:26 AM > To: Brandenburg, R. (Ray) van > Cc: cdni@ietf.org; ZhouZhipeng > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 >=20 > On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: >=20 > > Hi all, > > > > While I am neutral to the Content Adaptation discussion, I would like t= o > make sure that we do not throw out all features related to multiple > representations, which would happen if we would just remove section 5.1.3 > completely as suggested by Ben. >=20 > I'm not sure how you draw that conclusion as removing section 5.1.3 does > not throw out the ability to support multiple representations IMO. >=20 > > The previous version of the use case document (betrand-02) had a > slightly different wording in section 2.4 than is now being used in > section 5.1 of the new WG-version. I think the concept of resolution- > based constraints, that was included in betrand-02, should remain in some > form. While it is not the CDNs responsibility/decision whether to allow a > specific representation to be delivered, I think a use case in which some > dCDN only offers a subset of the representations available on the uCDN is > quite valid (such as in a dedicated mobile CDN). >=20 > I don't believe that dCDNs will only offer a subset of representations in > the way you describe. They may only deliver to a subset of users (and > maybe by implication a subset of possible devices) for example as a > consequence of them being a dedicated mobile CDN (as opposed to an activ= e > decision they make). >=20 > Let's look at how a content service is deployed. A Content Provider has > some content (let's say a video) that the Content Provider may produce in > a variety of representations (codecs, bit rates, resolutions, etc.). They > may do that encoding themselves or outsource it (although that's not > relevant to the point I'm making). >=20 > A User will connect to the Content Provider's "portal" (which may be a we= b > portal, an application, an EPG etc.). The Content Provider (through their > portal) will offer the User the content in one or more of the available > representations (e.g. by device type but how that decision is made is > purely up to the Content Provider). The User selects a representation and > the Content Provider offloads the delivery of that representation to the > CDN (e.g. by returning the appropriate URI for that representation within > the CDN to the User's client). The User then connects to the CDN and > requests the representation they have selected (from the choice of > representations offered to them by the Content Provider). >=20 > At its essence a CDN maps incoming URIs (from User's clients) to specific > content files on an upstream source (e.g. on-net storage or a Content > Provider's Origin server) it has no explicit knowledge of what actual > content that specific URI maps to or that it is one of X possible > representations of the same content. >=20 > At no point has the CDN been involved in the selection or restriction of > the representations offered to or delivered to the User. In a CDNI > scenario things are no different. A uCDN may select a dCDN based on some > capability (e.g. what Users it can deliver to, what delivery protocols it > can support) but I do not think that the specific representation of the > content will enter into the equation beyond those constraints. >=20 > For example, the dCDN is not going to say "I can only deliver > representations with resolutions below AxB" and the uCDN often will not > even know what the resolution or a particular representation is. >=20 > What might happen is that a User on a particular network (or using a > particular client/device) connects to the Content Provider's portal and i= s > only offered a subset of the possible representations tailored (by the > Content Provider's policy implemented in the Content Provider's portal) > based on that User's Network/Client/Device. A dCDN may subsequently be > selected that can serve that Network/Client/Service and that dCDN may onl= y > end up delivering to its Users a subset of all the possible > representations the Content Provider has produced. But that is a > consequence of the Network/Clients/Devices the dCDN is capable of serving= , > not an explicit decision made by the dCDN and communicated to the uCDN fo= r > that specific Content Provider's service. >=20 > Ben >=20 >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Tue Oct 11 07:50:23 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D0E21F84AB for ; Tue, 11 Oct 2011 07:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ay-5xnjJqus3 for ; Tue, 11 Oct 2011 07:50:21 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDE421F8DDC for ; Tue, 11 Oct 2011 07:50:21 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A959A79E1F3; Tue, 11 Oct 2011 10:50:11 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 50ED179EF62; Tue, 11 Oct 2011 10:49:46 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Tue, 11 Oct 2011 10:49:39 -0400 From: Kevin J Ma To: Scott Wainner Date: Tue, 11 Oct 2011 10:49:44 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyIIbJEiGC+vcvPQhaxfD3IH//u1QAADlqA Message-ID: <291CC3F9E50E7641901A54E85D0977C651B515176B@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B4FF2383@MAILR002.mail.lan> <4E89BA77.4050903@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B50AEDAA@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C651B50AFBF1@MAILR002.mail.lan> <4E945281.5030001@cisco.com> In-Reply-To: <4E945281.5030001@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 14:50:23 -0000 Hi Scott, > 1. Default / Standard method for all CDN's? > 2. Set of methods with order preference? I think either is fine. I would just be concerned if we had requirements in CDNI that CDNs support specific protocols. Doing it through metadata does not require the CDNI interfaces to change every time a new protocol comes along, and does not dictate what protocols CDNs must support if the= y want to engage in just basic interconnection? > Does the CP dictate the minimum level of authentication / authorization > acceptable by ANY CDN used for deliver? In that case, the uCDN may > support a method and the dCDN may or may not. A decision has to be mad= e > prior to delegating the content request to the dCDN. I would think yes, the CP dictates, and delegation should be restricted. thanx. -- Kevin J. Ma > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com] > Sent: Tuesday, October 11, 2011 10:28 AM > To: Kevin J Ma > Cc: Vishwas Manral; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > On 10/8/11 6:45 PM, Kevin J Ma wrote: > > Hi Vishwas, > > > > Just to clarify, when you say "between the CDNs", we are still > > taking about CDNs authenticating end users, as opposed to CDNs > > authenticating each other, correct? > That was my intent. >=20 > Each CDN will (most likely) want to use some means of authenticating the > user for permission to download content. Since the CDN's are operated > independently, they will likely independently choose their method of > authentication and authorization. The point being the use case could > describe a scenario where there is no authentication and authorization > (we're just trying to find a way to deliver content efficiently) AND a > use case can be described where there is authentication and > authorization (between the client and the CDN). In the later case, we > need to coordinate the method of authentication and authorization. >=20 > 1. Default / Standard method for all CDN's? > 2. Set of methods with order preference? >=20 > Does the CP dictate the minimum level of authentication / authorization > acceptable by ANY CDN used for deliver? In that case, the uCDN may > support a method and the dCDN may or may not. A decision has to be made > prior to delegating the content request to the dCDN. > > > > I do think that CDNs will need to be able to authenticate with > > each other, but with respect to CDNs authenticating end users, > > I agree that it would be best if the CDNs agreed upon a single > > authentication method, and that delegation be denied if a dCDN > > cannot support the method specified by the uCDN. IMO, the way > > to do that is through opaque metadata. > > > > I do not think I was disagreeing with Scott, I just raised two > > issues to consider: > > 1) If the CP configures the uCDN with an authentication method > > and credentials, the CP does not necessarily give that uCDN > > permission to pass those credentials along to a dCDN. > > 2) The client app cannot be expected to support authentication > > methods that are not known to the CP; the dCDNs cannot just > > select a method that the CP is unaware of. > > > > Going with an opaque metadata approach we can certainly define > > metadata for advertising authentication, beyond that, however, > > the CDN to client interface seems to be out of scope of CDNI? > If the authentication / authorization between the client and the dCDN is > a viable use case in CDNi, then I don't see how you can avoid at least > defining a requirement for specifying a compatible means of > authentication/authorization in order for CDNi to work. > > > > thanx. > > > > -- Kevin J. Ma > > > > From: Vishwas Manral [mailto:vishwas.ietf@gmail.com] > > Sent: Saturday, October 08, 2011 5:02 PM > > To: Kevin J Ma > > Cc: Scott Wainner; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Hi Kevin, > > > > I think Scott has a point when he says that we need to define some base > authentication method to be supported between the CDN's. > > > > Ofcourse in particular cases if a particular authentication method is > required it could mean to disallow delegation to a dCDN. > > > > Thanks, > > Vishwas > > On Mon, Oct 3, 2011 at 11:27 AM, Kevin J Ma > wrote: > > Hi Scott, > > > > One option is that CPs that want strict authentication do not allow > delegation. > > In a non-interconnected environment, the CP has to configure the > authentication > > method on each CDN? If the uCDN is going to delegate to a dCDN, the > uCDN would > > have to configure the dCDN on behalf of the CP (passwords, certs, > etc.)? That > > brings up other transative trust issues that this CP probably does no= t > want to > > deal with? For other CPs, imo, end user transparency is the most > important. > > That could mean options 1 or 3 as you describe them below, or > possibly a proxy > > where the dCDN sends the credentials to the uCDN for verification, so > that the > > client does not need to know anything about the dCDN? > > > > wrt the use case draft, do you feel that the security section needs > expanded, or > > that additional use cases are required? > > > > thanx. > > > > -- Kevin J. Ma > > > > From: Scott Wainner [mailto:swainner@cisco.com] > > Sent: Monday, October 03, 2011 9:37 AM > > To: Kevin J Ma > > Cc: cdni@ietf.org > > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Kevin, > > > > My comments in-line ... > > > > On 9/30/11 10:45 AM, Kevin J Ma wrote: > > Hi Scott, > > > > We are currently updating section 2.3. I think the nomadic use case > > includes not only geographic extension, but more generically > footprint > > extension. A carrier CDN with only an in-network presense for > specific > > devices (e.g., mobile vs TV) may want to increase its device > footprint > > by interconnecting with another local carrier CDN that supports othe= r > > devices or subscribers. We are also looking at removing section > 5.1.3. > > Understood. > > > > > As an example, the uCDN might use URL appended > > > tokens for authentication while dCDN might use URL appended > hashes. > > ... > > > Clearly, the choice of > > > authentication method is determined by the respective CDN's. > > > > Content providers typically implement apps today with an > understanding that > > the uCDN has a specific authentication method. If the uCDN delegate= s > > delivery to a dCDN that the content provider has no relationship > with, the > > app may have no ability to switch authentication methods. Would the > uCDN be > > responsible for generating of the proper dCDN credentials for the > user? > > That is exactly my point. I don't have an answer. > > > > The CSP may accept the uCDN's approach to authentication; however, that > method of authentication may not be supported on the dCDN which has the > authority to choose its own method of authentication independent of the > CSP. > > > > 1. Does the dCDN have to support multiple authentication methods - one > for each uCDN it establishes a relationship? > > > > 2. Does the uCDN have to support (and get approval from the CSP) for > multiple authentication methods - one for each dCDN for which it > establishes a relationship? > > > > 3. Do we define a standard authentication method between the client and > all CDN such that the CSP approves one method and all uCDN and dCDN > support the standard method? > > > > 4. Do we define a proxy authentication method where the dCDN > authenticates the client using their method of choice, the uCDN > authenticates clients using their method of choice, AND CDNi defines a > standard proxy method between the dCDN and uCDN? In this case, the CSP > must accept that the methods used by dCDN and uCDN are equivalent but not > necessarily the same. > > > > In what manner is the client informed of the appropriate method to > authenticate their transaction with either the dCDN or uCDN? > > > > Scott > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > >> Scott Wainner > >> Sent: Thursday, September 29, 2011 8:02 PM > >> To: cdni@ietf.org > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> Section 2.3 Nomadic Users > >> This description falls under the category of Geographic Extension > yet > >> the third paragraph states the case where a different device is used i= n > >> the same CDN coverage area. The intent of this use case needs to be > >> clarified. Perhaps the use case is trying to address the scenario > where > >> a Nomadic User-A with an agreement allowing access to content from CSP= - > A > >> via uCDN moves to a dCDN in a different region. The dCDN is allowed t= o > >> distribute the content of CSP-A to User-A; however, not other users in > >> the region of the dCDN are allowed to retrieve the content unless they > >> too have such an agreement. > >> > >> Section 5.1.3 Content Encoding Restrictions > >> Need to clarify if we're talking about the restrictions on the > >> delivery of specific content or the restrictions on the ability of a > CDN > >> to deliver specific content. I certainly understand the case where a > >> CSP will restrict the distribution of content to a "managed path" if > >> such content is HD while allowing the content distribution via an > >> un-managed path if such content is SD (same could apply to encryption > >> methods, delivery methods, etc.). On the contrary, the dCDN may have > >> its own restrictions of blocking the distribution of HD content while > >> allowing the distribution of SD content. > >> > >> o first bullet makes sense if the dCDN can perform a subset of > >> encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) > >> o second bullet makes sense where the dCDN doesn't want to offer > high > >> bit-rate variants of the media > >> o third bullet make sense if the policy addresses QoE but I don't > >> think subscriber rights/authorizations apply. > >> > >> Section 10 Security Considerations > >> > >> Aside from the security considerations WITHIN the uCDN and dCDN, I > think > >> we can describe this in four contexts: > >> > >> a. The relationship between the CSP and the uCDN (the principle > contract > >> arrangement for distribution) > >> b. The relationship between the uCDN and dCDN (the transitive trust > >> relationship that extends the contract defined in (a) above) > >> c. The relationship between the User and dCDN (the recognition of righ= t > >> to download predicated on (b) above) > >> d. The relationship between the User and CSP (the contract authorizing > >> the user access to the content) > >> > >> The user is not interested in the a-b nor the b-c relationship. The > user > >> is only interested in the transparency and interoperability of the > >> security relationship between d-b or d-c to the point that the > >> authorization granted in d-a is viable when the delivery is initiated > >> via either d-b or d-c. As an example, the uCDN might use URL appended > >> tokens for authentication while dCDN might use URL appended hashes. > The > >> user doesn't want to know about the distinct methods, but transparency > >> is only afforded if the methods are interoperable clearly defined when > >> the delegation for content delivery is executed. Clearly, the choice > of > >> authentication method is determined by the respective CDN's. > >> > >> Scott > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > > > > From ray.vanbrandenburg@tno.nl Tue Oct 11 08:09:50 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D0E21F8E3D for ; Tue, 11 Oct 2011 08:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DykJGN9edH1o for ; Tue, 11 Oct 2011 08:09:49 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id 67B7E21F8E38 for ; Tue, 11 Oct 2011 08:09:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,523,1312149600"; d="scan'208";a="58707821" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 11 Oct 2011 17:09:34 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.01.0323.003; Tue, 11 Oct 2011 17:09:34 +0200 From: "Brandenburg, R. (Ray) van" To: Ben Niven-Jenkins Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMeV9XVExcRrnYVk25qolmOBlG5JVk9BkAgA0NMICAA2MzAIABwOGQ///5B4CAADuwYA== Date: Tue, 11 Oct 2011 15:09:32 +0000 Message-ID: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:09:50 -0000 Hi Ben, You make the assumption that selecting a specific representation is a consc= ious decision, made either by a user or the CP, before the actual content d= elivery commences. In this case, I agree with you completely.=20 However, there are situations imaginable in which there is a switch between= representations during content delivery. Let's take the HTTP Adaptive Stre= aming situation for example. A given video might be encoded in 10 different= qualities (representations), ranging from a 1080p stream all the way to 12= 8kbps stream meant for small-screen mobile devices. Depending on network co= nditions or user preferences, a device might switch between these represent= ation multiple times during video delivery. In your case it will only be po= ssible for a dCDN to host/deliver either all 10 of the representations, or = none at all. What I meant was that in some situations, a dedicated mobile d= CDN might want to host/deliver the content, but not in all 10 representati= ons since the highest quality representations (e.g. 1080p) are of no use to= mobile clients.=20 I understand that this would mean that a CDN is no longer agnostic to the c= ontent it delivers, but this is true for a lot of use cases that are includ= ed in the current draft.=20 Ray -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Sent: dinsdag 11 oktober 2011 15:26 To: Brandenburg, R. (Ray) van Cc: ZhouZhipeng; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: > Hi all, >=20 > While I am neutral to the Content Adaptation discussion, I would like to = make sure that we do not throw out all features related to multiple represe= ntations, which would happen if we would just remove section 5.1.3 complete= ly as suggested by Ben.=20 I'm not sure how you draw that conclusion as removing section 5.1.3 does no= t throw out the ability to support multiple representations IMO. > The previous version of the use case document (betrand-02) had a slightly= different wording in section 2.4 than is now being used in section 5.1 of= the new WG-version. I think the concept of resolution-based constraints, t= hat was included in betrand-02, should remain in some form. While it is not= the CDNs responsibility/decision whether to allow a specific representatio= n to be delivered, I think a use case in which some dCDN only offers a subs= et of the representations available on the uCDN is quite valid (such as in = a dedicated mobile CDN).=20 I don't believe that dCDNs will only offer a subset of representations in t= he way you describe. They may only deliver to a subset of users (and maybe = by implication a subset of possible devices) for example as a consequence o= f them being a dedicated mobile CDN (as opposed to an active decision they= make). Let's look at how a content service is deployed. A Content Provider has som= e content (let's say a video) that the Content Provider may produce in a va= riety of representations (codecs, bit rates, resolutions, etc.). They may d= o that encoding themselves or outsource it (although that's not relevant to= the point I'm making). A User will connect to the Content Provider's "portal" (which may be a web = portal, an application, an EPG etc.). The Content Provider (through their p= ortal) will offer the User the content in one or more of the available repr= esentations (e.g. by device type but how that decision is made is purely up= to the Content Provider). The User selects a representation and the Conten= t Provider offloads the delivery of that representation to the CDN (e.g. by= returning the appropriate URI for that representation within the CDN to th= e User's client). The User then connects to the CDN and requests the repres= entation they have selected (from the choice of representations offered to = them by the Content Provider). At its essence a CDN maps incoming URIs (from User's clients) to specific c= ontent files on an upstream source (e.g. on-net storage or a Content Provid= er's Origin server) it has no explicit knowledge of what actual content tha= t specific URI maps to or that it is one of X possible representations of t= he same content. At no point has the CDN been involved in the selection or restriction of th= e representations offered to or delivered to the User. In a CDNI scenario t= hings are no different. A uCDN may select a dCDN based on some capability (= e.g. what Users it can deliver to, what delivery protocols it can support) = but I do not think that the specific representation of the content will ent= er into the equation beyond those constraints. For example, the dCDN is not going to say "I can only deliver representatio= ns with resolutions below AxB" and the uCDN often will not even know what t= he resolution or a particular representation is.=20 What might happen is that a User on a particular network (or using a partic= ular client/device) connects to the Content Provider's portal and is only o= ffered a subset of the possible representations tailored (by the Content Pr= ovider's policy implemented in the Content Provider's portal) based on that= User's Network/Client/Device. A dCDN may subsequently be selected that can= serve that Network/Client/Service and that dCDN may only end up delivering= to its Users a subset of all the possible representations the Content Prov= ider has produced. But that is a consequence of the Network/Clients/Devices= the dCDN is capable of serving, not an explicit decision made by the dCDN = and communicated to the uCDN for that specific Content Provider's service. Ben =20 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From ben@niven-jenkins.co.uk Tue Oct 11 08:26:15 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1F121F8D16 for ; Tue, 11 Oct 2011 08:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHU79+MC6AYj for ; Tue, 11 Oct 2011 08:26:14 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB1621F8BAE for ; Tue, 11 Oct 2011 08:26:14 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDeDc-0006wA-VF; Tue, 11 Oct 2011 16:26:13 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <4E9455D5.50708@cisco.com> Date: Tue, 11 Oct 2011 16:26:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F4FFA63-9B4E-4FC9-9B62-B12659598A8D@niven-jenkins.co.uk> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <4E9455D5.50708@cisco.com> To: Scott Wainner X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org, ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:26:15 -0000 Scott, On 11 Oct 2011, at 15:42, Scott Wainner wrote: > On 10/10/11 7:04 AM, Ben Niven-Jenkins wrote: >>=20 >> Let's not forget that in building an end to end content service the = CDN is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. >>=20 >> The decision as to which version/copy/representation to offer and = allow to be delivered to a given device/user is implemented outside of = the CDN (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content). >>=20 > Agreed. This means the portal makes a decision about the specific = content object without regard to the capabilities of the CDN(s). There = is a presumption that the set of CDN's can deliver the content. That = assumption has a high probability of success with regards to the = relationship between the uCDN and CP because there is an explicit = business relationship. That assumption may not be valid when dealing = with a dCDN that has a business relationship with the uCDN. The CP will enter a business agreement with a uCDN for the delivery of = its content and will ensure that the uCDN is able to deliver both the = types of content the CP requires delivery of and to the geographic = regions that the CP requires delivery to. That is typically known in = advance as part of the RFP/contract negotiation between the CP & the = uCDN. The uCDN may decide to make use of dCDNs to assist in the delivery of = some or all of that content. The technical interconnect of the uCDN and = dCDN is not occurring in a vacuum. The uCDN better make sure that it can = cover its obligations to the CP either by itself or by ensuring that it = has one or more dCDNs that can meet those obligations for it. If the uCDN overcommits itself compared to its (or its dCDN's) = capabilities bad things will happen (from the point of view of the CSP = and the CSP's Users). The solution to that problem is not a technical = solution IMO. At the end of the day CPs will talk to their CPs about what they require = and configure policies in their platform appropriately. Likewise uCDNs = will talk with their dCDNs about what they require and configure = policies in their platform appropriately. There isn't any magical = protocol dust that means those conversations do not need to happen and = IMO if those conversations are happening there's no need for protocol = semantics to duplicate what is happening outside of the CDNI protocols = themselves as part of those conversations and the per-CP/per-CDN = configuration happening as a result. =20 > So let's assume there is ONE URL that is provided by the CP (portal) = for the asset. If that URL makes sense ONLY on the uCDN, then somewhere = outside of the CP (portal) a decision must be made to re-write the URL = such that it is appropriate for the dCDN. That can be a simple re-write = (modified FQDN with same PATH) or a more complex re-write (modified FQDN = and PATH). I don't see how URI rewriting applies to content adaptation. The URI a = client uses to access the same content representation may differ by CDN = and the URI may be transformed as part of CDNI request routing for = example but the content itself is not transformed - the different URIs = in each CDN still refer to the same specific content file. Ben >=20 > Are we bounding the use case ONLY those scenarios where the PATH = structure remains unmodified and we're only changing the delivery point? = In this case, the uCDN and every dCDN would understand how to handle = the exact same PATH structure. >=20 > If the use case is expanded to include the URL PATH re-write, where = would this be done? If the CP (portal) does it, it needs to know = information about which CDN will be used in order to pick the correct = URL structure. Otherwise, the uCDN must do the re-write into the = appropriate PATH structure for the dCDN. Is this in scope or not? >=20 > Scott >>=20 >> Ben >>=20 >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: >>=20 >> > Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. >> > If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. >> > >> > Here the first bullet "a subset of encodings deliverable to = specific devices," has listed the case of content adaptation. >> > In last month, I have contacted the Authors of this document and = taken some email exchanges with Grant and Philip (BT). >> > I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. >> > Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. >> > >> > If you have any more question or comments, pls share in this = thread. >> > Thanks. >> > Zhipeng >> > >> > >> > >> > >> > >> > >> > -----Original Message----- >> > From: Scott Wainner [mailto:swainner@cisco.com] >> > Sent: Friday, September 30, 2011 8:02 AM >> > To: cdni@ietf.org >> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> > >> > Section 2.3 Nomadic Users >> > This description falls under the category of Geographic Extension = yet >> > the third paragraph states the case where a different device is = used in >> > the same CDN coverage area. The intent of this use case needs to = be >> > clarified. Perhaps the use case is trying to address the scenario = where >> > a Nomadic User-A with an agreement allowing access to content from = CSP-A >> > via uCDN moves to a dCDN in a different region. The dCDN is = allowed to >> > distribute the content of CSP-A to User-A; however, not other users = in >> > the region of the dCDN are allowed to retrieve the content unless = they >> > too have such an agreement. >> > >> > Section 5.1.3 Content Encoding Restrictions >> > Need to clarify if we're talking about the restrictions on the >> > delivery of specific content or the restrictions on the ability of = a CDN >> > to deliver specific content. I certainly understand the case where = a >> > CSP will restrict the distribution of content to a "managed path" = if >> > such content is HD while allowing the content distribution via an >> > un-managed path if such content is SD (same could apply to = encryption >> > methods, delivery methods, etc.). On the contrary, the dCDN may = have >> > its own restrictions of blocking the distribution of HD content = while >> > allowing the distribution of SD content. >> > >> > o first bullet makes sense if the dCDN can perform a subset of >> > encapsulations for a reference set of media (e.g. HLS, HSS, but not = DASH) >> > o second bullet makes sense where the dCDN doesn't want to offer = high >> > bit-rate variants of the media >> > o third bullet make sense if the policy addresses QoE but I don't >> > think subscriber rights/authorizations apply. >> > >> > Section 10 Security Considerations >> > >> > Aside from the security considerations WITHIN the uCDN and dCDN, I = think >> > we can describe this in four contexts: >> > >> > a. The relationship between the CSP and the uCDN (the principle = contract >> > arrangement for distribution) >> > b. The relationship between the uCDN and dCDN (the transitive trust >> > relationship that extends the contract defined in (a) above) >> > c. The relationship between the User and dCDN (the recognition of = right >> > to download predicated on (b) above) >> > d. The relationship between the User and CSP (the contract = authorizing >> > the user access to the content) >> > >> > The user is not interested in the a-b nor the b-c relationship. The = user >> > is only interested in the transparency and interoperability of the >> > security relationship between d-b or d-c to the point that the >> > authorization granted in d-a is viable when the delivery is = initiated >> > via either d-b or d-c. As an example, the uCDN might use URL = appended >> > tokens for authentication while dCDN might use URL appended hashes. = The >> > user doesn't want to know about the distinct methods, but = transparency >> > is only afforded if the methods are interoperable clearly defined = when >> > the delegation for content delivery is executed. Clearly, the = choice of >> > authentication method is determined by the respective CDN's. >> > >> > Scott >> > >> > _______________________________________________ >> > CDNi mailing list >> > CDNi@ietf.org >> > https://www.ietf.org/mailman/listinfo/cdni >>=20 >>=20 >=20 From kevin.ma@azukisystems.com Tue Oct 11 08:29:39 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4ED21F8E4F for ; Tue, 11 Oct 2011 08:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysaB2qOL14SQ for ; Tue, 11 Oct 2011 08:29:36 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id E35C221F8E4D for ; Tue, 11 Oct 2011 08:29:35 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 79F275550B0; Tue, 11 Oct 2011 11:29:35 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CA556554EC5; Tue, 11 Oct 2011 11:29:33 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Tue, 11 Oct 2011 11:29:16 -0400 From: Kevin J Ma To: HeXiaoyan , "cdni@ietf.org" Date: Tue, 11 Oct 2011 11:29:31 -0400 Thread-Topic: [CDNi] CDNI Metadata Interface Thread-Index: AcyErDmDceDqNX+AQtKwjumpTmgL9wDNgegQABC/ZGA= Message-ID: <291CC3F9E50E7641901A54E85D0977C651B51517AD@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <010d01cc87f8$10bc5940$32350bc0$@com> In-Reply-To: <010d01cc87f8$10bc5940$32350bc0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:29:39 -0000 Hi Susan, thanx for the comments, responses inline: > -----Original Message----- > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > Sent: Tuesday, October 11, 2011 5:28 AM > To: Kevin J Ma; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface >=20 > Hi Kevin, > Some quick questions and comments on this draft, > >The Metadata objects are each associated with a URI within the Domain an= d > accessible through any of the Hostnames... > - Could you further explain or give an example how a metadata is accessed > by > a Hostname within the Domain? And a further question is how the data mode= l > works if a metadata is only associated with a specific Hostname within on= e > Doman? I was assuming that metadata would be valid for all hostnames. If a hostna= me needed separate metadata, a new domain would be required. I was thinking o= f hostname as a first level restriction. My implementation does something al= ong the lines of the following (where hostname is checked before metadata looku= p): domain =3D get_param_from_query_string(getenv("QUERY_STRING"), "domain") if (!db_verify_hostname_for_domain(getenv("SERVER_NAME"), domain)) return error metadata =3D db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"), domain, getenv("REMOTE_USE= R")) xml =3D generate_xml_for_metadata(metadata) return xml > - The relationship between Agent objects and Metadata objects is a > one-to-one relationship, does this mean one agent can only access one > Metadata within one Domain? That is a typo in the doc, good catch, thanx! It should be one to many. Each metadata must be associated with a single agent, but an agent can be associated with multiple metadata. Agent-1 could have metadatas A, B, and C, while agent-2 could have a separate value for metadatas A and B, and als= o have its own metadata D (that agent-1 does not have access to) > > The association of each Metadata to an Agent allows different Agents to > retrieve different Metadata values for a given URI in the given Domain. > - Don't understand why each Metadata object needs to be bind with an Agen= t > explicitly, IMO, whether to return different value to different Agents is > an > inside process of the upCDN, what downCDN needs to do is just transmit it= s > identifier to the upCDN when retrieve a Metadata. I think the fact that a uCDN would want/need to give out different values t= o different dCDNs requires that there be a way to represent and store that information. Having it explicitly in the model, i think, simplifies the implementation and guarantees that all implementation give this issue prope= r consideration. > - Which entity is responsible for creating the Agent objects within one > Domain? Does the CP can 'see' the downCDNs and creates corresponding Agen= t > objects and other CDNs on the way just transmitted it or each upCDN > located > in the cascaded path creates a Agent object for each its downCDN? This is a good question. Different agents would need to be create by diffe= rent entities, as you mention. I would expect each CDN to create agents to repr= esent those (outside that CDN) who need access to the metadata interface. thanx! -- Kevin J. Ma > Thanks. > Best Regards > Xiaoyan(Susan) He >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Kevin J Ma > Sent: Friday, October 07, 2011 1:21 PM > To: cdni@ietf.org > Subject: [CDNi] CDNI Metadata Interface >=20 > Hi all, >=20 > Just uploaded a new I-D with a proposed metadata model and API: >=20 > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt >=20 > The model takes a rather generic approach to metadata representation > to support opaque metadata and addresses some of the security issues > associated with metadata retrieval. Comments welcome. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Tue Oct 11 08:41:42 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7A921F8E55 for ; Tue, 11 Oct 2011 08:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk+YehZv+Sl9 for ; Tue, 11 Oct 2011 08:41:41 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4677F21F8E4A for ; Tue, 11 Oct 2011 08:41:41 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDeSZ-0007bU-TN; Tue, 11 Oct 2011 16:41:40 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 11 Oct 2011 16:41:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6972906B-FA42-4025-BDB9-FD8E60FB6CA0@niven-jenkins.co.uk> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:41:42 -0000 Ray, On 11 Oct 2011, at 16:09, Brandenburg, R. (Ray) van wrote: > Hi Ben, >=20 > You make the assumption that selecting a specific representation is a = conscious decision, made either by a user or the CP, before the actual = content delivery commences. In this case, I agree with you completely.=20= >=20 > However, there are situations imaginable in which there is a switch = between representations during content delivery. Let's take the HTTP = Adaptive Streaming situation for example. A given video might be encoded = in 10 different qualities (representations), ranging from a 1080p stream = all the way to 128kbps stream meant for small-screen mobile devices. = Depending on network conditions or user preferences, a device might = switch between these representation multiple times during video = delivery. In your case it will only be possible for a dCDN to = host/deliver either all 10 of the representations, or none at all. What = I meant was that in some situations, a dedicated mobile dCDN might want = to host/deliver the content, but not in all 10 representations since = the highest quality representations (e.g. 1080p) are of no use to mobile = clients.=20 Ultimately, even with adaptive streaming, the Content Provider chooses = what representations they make available. HTTP Adaptive streaming is no = different to my original example except instead of providing a URI for a = specific representation the Content Provider provides a "manifest" = containing URIs for one or more representations. At no point does the = CDN get to decide which representations the Content Provider includes in = their manifest. Typically, the CDN only caches those representations that are actually = requested from it. Therefore it is not a black & white "all 10" or = "none" as you suggest. The Content Provider has ownership of what service they offer and the = experience they want the User to experience, not the CDN. It is not = acceptable for a CDN to decide (outside of a business agreement) that it = doesn't want to support some subset of the representations the Content = Provider is offering and use "content adaptation" to modify the content = to what the CDN would prefer to deliver. Ben >=20 > I understand that this would mean that a CDN is no longer agnostic to = the content it delivers, but this is true for a lot of use cases that = are included in the current draft.=20 >=20 > Ray >=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Sent: dinsdag 11 oktober 2011 15:26 > To: Brandenburg, R. (Ray) van > Cc: ZhouZhipeng; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 >=20 > On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: >=20 >> Hi all, >>=20 >> While I am neutral to the Content Adaptation discussion, I would like = to make sure that we do not throw out all features related to multiple = representations, which would happen if we would just remove section = 5.1.3 completely as suggested by Ben.=20 >=20 > I'm not sure how you draw that conclusion as removing section 5.1.3 = does not throw out the ability to support multiple representations IMO. >=20 >> The previous version of the use case document (betrand-02) had a = slightly different wording in section 2.4 than is now being used in = section 5.1 of the new WG-version. I think the concept of = resolution-based constraints, that was included in betrand-02, should = remain in some form. While it is not the CDNs responsibility/decision = whether to allow a specific representation to be delivered, I think a = use case in which some dCDN only offers a subset of the representations = available on the uCDN is quite valid (such as in a dedicated mobile = CDN).=20 >=20 > I don't believe that dCDNs will only offer a subset of representations = in the way you describe. They may only deliver to a subset of users (and = maybe by implication a subset of possible devices) for example as a = consequence of them being a dedicated mobile CDN (as opposed to an = active decision they make). >=20 > Let's look at how a content service is deployed. A Content Provider = has some content (let's say a video) that the Content Provider may = produce in a variety of representations (codecs, bit rates, resolutions, = etc.). They may do that encoding themselves or outsource it (although = that's not relevant to the point I'm making). >=20 > A User will connect to the Content Provider's "portal" (which may be a = web portal, an application, an EPG etc.). The Content Provider (through = their portal) will offer the User the content in one or more of the = available representations (e.g. by device type but how that decision is = made is purely up to the Content Provider). The User selects a = representation and the Content Provider offloads the delivery of that = representation to the CDN (e.g. by returning the appropriate URI for = that representation within the CDN to the User's client). The User then = connects to the CDN and requests the representation they have selected = (from the choice of representations offered to them by the Content = Provider). >=20 > At its essence a CDN maps incoming URIs (from User's clients) to = specific content files on an upstream source (e.g. on-net storage or a = Content Provider's Origin server) it has no explicit knowledge of what = actual content that specific URI maps to or that it is one of X possible = representations of the same content. >=20 > At no point has the CDN been involved in the selection or restriction = of the representations offered to or delivered to the User. In a CDNI = scenario things are no different. A uCDN may select a dCDN based on some = capability (e.g. what Users it can deliver to, what delivery protocols = it can support) but I do not think that the specific representation of = the content will enter into the equation beyond those constraints. >=20 > For example, the dCDN is not going to say "I can only deliver = representations with resolutions below AxB" and the uCDN often will not = even know what the resolution or a particular representation is.=20 >=20 > What might happen is that a User on a particular network (or using a = particular client/device) connects to the Content Provider's portal and = is only offered a subset of the possible representations tailored (by = the Content Provider's policy implemented in the Content Provider's = portal) based on that User's Network/Client/Device. A dCDN may = subsequently be selected that can serve that Network/Client/Service and = that dCDN may only end up delivering to its Users a subset of all the = possible representations the Content Provider has produced. But that is = a consequence of the Network/Clients/Devices the dCDN is capable of = serving, not an explicit decision made by the dCDN and communicated to = the uCDN for that specific Content Provider's service. >=20 > Ben >=20 >=20 >=20 > This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >=20 From swainner@cisco.com Tue Oct 11 08:50:08 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E593F21F8EAE for ; Tue, 11 Oct 2011 08:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnGfDjR75ydq for ; Tue, 11 Oct 2011 08:50:07 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 556D021F8E38 for ; Tue, 11 Oct 2011 08:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=25048; q=dns/txt; s=iport; t=1318348207; x=1319557807; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=3PnPXTnDN1JJxRptujN0CA4sZoiiK27EWvEdBq4ZaZg=; b=bos6OZZn2CaWZpG5tCoQyE4zlAbori7Ktjwf9nR12Aa09dEpjYB0rmuJ GsZKkgHm2fDl2lLzjYdBsEhFIaqnThnT+sInvvbW4l9FPEjftF0AE20U4 aB9UK9ubxZwFddCXGIVnuBgIeoCrC8HN+vmmu1ohbxsKPpeACJgVNi35M Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnkAAA5llE6rRDoI/2dsb2JhbABDmQSPJIEFgVMBAQEDAQEBAQ8BGkEEBgEFBwQLEQQBAQEJFggHCQMCAQIBFR8JCAYNAQUCAQEXB4dcB5oXAZ5XA4dMBJN1kW4 X-IronPort-AV: E=Sophos;i="4.68,524,1312156800"; d="scan'208,217";a="7197221" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 11 Oct 2011 15:50:06 +0000 Received: from swainner-mac.local (stealth-10-32-245-61.cisco.com [10.32.245.61]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9BFo532024665; Tue, 11 Oct 2011 15:50:06 GMT Message-ID: <4E94665A.9090404@cisco.com> Date: Tue, 11 Oct 2011 11:52:58 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ben Niven-Jenkins References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <4E9455D5.50708@cisco.com> <0F4FFA63-9B4E-4FC9-9B62-B12659598A8D@niven-jenkins.co.uk> In-Reply-To: <0F4FFA63-9B4E-4FC9-9B62-B12659598A8D@niven-jenkins.co.uk> Content-Type: multipart/alternative; boundary="------------000805080409020309030704" Cc: cdni@ietf.org, ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:50:09 -0000 This is a multi-part message in MIME format. --------------000805080409020309030704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ben, I agree. Multiple client representations (i.e. unique URI) for the same content representation. I'm not suggesting content adaptation as a use case. My only point (which was made by others) is that a given representation MAY or MAY NOT be viable or advisable on a dCDN. That decision is presumably not made by the CSP. That decision is made by the uCDN. The input for that decision can be made statically (configured policy) or learned dynamically (conveyed via CDNi). I agree that we can use statically configured policy to make that decision. Scott On 10/11/11 11:26 AM, Ben Niven-Jenkins wrote: > > Scott, > > On 11 Oct 2011, at 15:42, Scott Wainner wrote: > > > On 10/10/11 7:04 AM, Ben Niven-Jenkins wrote: > >> > >> Let's not forget that in building an end to end content service the > CDN is only one component and is the component tasked with executing > the delivery of a specific representation (version/copy/format etc.) > of the selected content not the component tasked with deciding (or > applying policy) on which version/copy/representation of content > should be delivered. > >> > >> The decision as to which version/copy/representation to offer and > allow to be delivered to a given device/user is implemented outside of > the CDN (e.g. by the "portal" where the user first makes their content > selection prior to the CDN becoming involved in the delivery of the > selected content). > >> > > Agreed. This means the portal makes a decision about the specific > content object without regard to the capabilities of the CDN(s). > There is a presumption that the set of CDN's can deliver the content. > That assumption has a high probability of success with regards to the > relationship between the uCDN and CP because there is an explicit > business relationship. That assumption may not be valid when dealing > with a dCDN that has a business relationship with the uCDN. > > The CP will enter a business agreement with a uCDN for the delivery of > its content and will ensure that the uCDN is able to deliver both the > types of content the CP requires delivery of and to the geographic > regions that the CP requires delivery to. That is typically known in > advance as part of the RFP/contract negotiation between the CP & the uCDN. > > The uCDN may decide to make use of dCDNs to assist in the delivery of > some or all of that content. The technical interconnect of the uCDN > and dCDN is not occurring in a vacuum. The uCDN better make sure that > it can cover its obligations to the CP either by itself or by ensuring > that it has one or more dCDNs that can meet those obligations for it. > > If the uCDN overcommits itself compared to its (or its dCDN's) > capabilities bad things will happen (from the point of view of the CSP > and the CSP's Users). The solution to that problem is not a technical > solution IMO. > > At the end of the day CPs will talk to their CPs about what they > require and configure policies in their platform appropriately. > Likewise uCDNs will talk with their dCDNs about what they require and > configure policies in their platform appropriately. There isn't any > magical protocol dust that means those conversations do not need to > happen and IMO if those conversations are happening there's no need > for protocol semantics to duplicate what is happening outside of the > CDNI protocols themselves as part of those conversations and the > per-CP/per-CDN configuration happening as a result. > > > So let's assume there is ONE URL that is provided by the CP (portal) > for the asset. If that URL makes sense ONLY on the uCDN, then > somewhere outside of the CP (portal) a decision must be made to > re-write the URL such that it is appropriate for the dCDN. That can > be a simple re-write (modified FQDN with same PATH) or a more complex > re-write (modified FQDN and PATH). > > I don't see how URI rewriting applies to content adaptation. The URI a > client uses to access the same content representation may differ by > CDN and the URI may be transformed as part of CDNI request routing for > example but the content itself is not transformed - the different URIs > in each CDN still refer to the same specific content file. > > Ben > > > > > Are we bounding the use case ONLY those scenarios where the PATH > structure remains unmodified and we're only changing the delivery > point? In this case, the uCDN and every dCDN would understand how to > handle the exact same PATH structure. > > > > If the use case is expanded to include the URL PATH re-write, where > would this be done? If the CP (portal) does it, it needs to know > information about which CDN will be used in order to pick the correct > URL structure. Otherwise, the uCDN must do the re-write into the > appropriate PATH structure for the dCDN. Is this in scope or not? > > > > Scott > >> > >> Ben > >> > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > >> > >> > Following Scott's comments on section 5.1.3, I feel Scott's > description on the use case of HD and SD is not exactly correct. > >> > If one movie has two formats of HD and SD, then we have two > content with different identifier. In DRM scope, the basic unit is a > content copy. > >> > > >> > Here the first bullet "a subset of encodings deliverable to > specific devices," has listed the case of content adaptation. > >> > In last month, I have contacted the Authors of this document and > taken some email exchanges with Grant and Philip (BT). > >> > I have shown BT with some information that I know in this case > and area to explain the content flexibility is currently a basic > requirement for CDN service and related negotiation is needed in the > CDN interconnection. > >> > Meanwhile, I should also invite you in this group raising your > comments or questions on this case since I hope my use case may be > incorporated in the use case draft. > >> > > >> > If you have any more question or comments, pls share in this thread. > >> > Thanks. > >> > Zhipeng > >> > > >> > > >> > > >> > > >> > > >> > > >> > -----Original Message----- > >> > From: Scott Wainner [mailto:swainner@cisco.com] > >> > Sent: Friday, September 30, 2011 8:02 AM > >> > To: cdni@ietf.org > >> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > > >> > Section 2.3 Nomadic Users > >> > This description falls under the category of Geographic > Extension yet > >> > the third paragraph states the case where a different device is > used in > >> > the same CDN coverage area. The intent of this use case needs to be > >> > clarified. Perhaps the use case is trying to address the > scenario where > >> > a Nomadic User-A with an agreement allowing access to content > from CSP-A > >> > via uCDN moves to a dCDN in a different region. The dCDN is > allowed to > >> > distribute the content of CSP-A to User-A; however, not other > users in > >> > the region of the dCDN are allowed to retrieve the content unless > they > >> > too have such an agreement. > >> > > >> > Section 5.1.3 Content Encoding Restrictions > >> > Need to clarify if we're talking about the restrictions on the > >> > delivery of specific content or the restrictions on the ability > of a CDN > >> > to deliver specific content. I certainly understand the case where a > >> > CSP will restrict the distribution of content to a "managed path" if > >> > such content is HD while allowing the content distribution via an > >> > un-managed path if such content is SD (same could apply to encryption > >> > methods, delivery methods, etc.). On the contrary, the dCDN may have > >> > its own restrictions of blocking the distribution of HD content while > >> > allowing the distribution of SD content. > >> > > >> > o first bullet makes sense if the dCDN can perform a subset of > >> > encapsulations for a reference set of media (e.g. HLS, HSS, but > not DASH) > >> > o second bullet makes sense where the dCDN doesn't want to > offer high > >> > bit-rate variants of the media > >> > o third bullet make sense if the policy addresses QoE but I don't > >> > think subscriber rights/authorizations apply. > >> > > >> > Section 10 Security Considerations > >> > > >> > Aside from the security considerations WITHIN the uCDN and dCDN, > I think > >> > we can describe this in four contexts: > >> > > >> > a. The relationship between the CSP and the uCDN (the principle > contract > >> > arrangement for distribution) > >> > b. The relationship between the uCDN and dCDN (the transitive trust > >> > relationship that extends the contract defined in (a) above) > >> > c. The relationship between the User and dCDN (the recognition of > right > >> > to download predicated on (b) above) > >> > d. The relationship between the User and CSP (the contract > authorizing > >> > the user access to the content) > >> > > >> > The user is not interested in the a-b nor the b-c relationship. > The user > >> > is only interested in the transparency and interoperability of the > >> > security relationship between d-b or d-c to the point that the > >> > authorization granted in d-a is viable when the delivery is initiated > >> > via either d-b or d-c. As an example, the uCDN might use URL > appended > >> > tokens for authentication while dCDN might use URL appended > hashes. The > >> > user doesn't want to know about the distinct methods, but > transparency > >> > is only afforded if the methods are interoperable clearly defined > when > >> > the delegation for content delivery is executed. Clearly, the > choice of > >> > authentication method is determined by the respective CDN's. > >> > > >> > Scott > >> > > >> > _______________________________________________ > >> > CDNi mailing list > >> > CDNi@ietf.org > >> > https://www.ietf.org/mailman/listinfo/cdni > >> > >> > > > --------------000805080409020309030704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ben,

    I agree.  Multiple client representations (i.e. unique URI) for the same content representation.  I'm not suggesting content adaptation as a use case.  My only point (which was made by others) is that a given representation MAY or MAY NOT be viable or advisable on a dCDN.  That decision is presumably not made by the CSP.  That decision is made by the uCDN.  The input for that decision can be made statically (configured policy) or learned dynamically (conveyed via CDNi).

    I agree that we can use statically configured policy to make that decision. 

Scott

On 10/11/11 11:26 AM, Ben Niven-Jenkins wrote:
Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott,

On 11 Oct 2011, at 15:42, Scott Wainner wrote:

> On 10/10/11 7:04 AM, Ben Niven-Jenkins wrote:
>>
>> Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered.
>>
>> The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content).
>>
> Agreed.  This means the portal makes a decision about the specific content object without regard to the capabilities of the CDN(s).  There is a presumption that the set of CDN's can deliver the content.  That assumption has a high probability of success with regards to the relationship between the uCDN and CP because there is an explicit business relationship.  That assumption may not be valid when dealing with a dCDN that has a business relationship with the uCDN.

The CP will enter a business agreement with a uCDN for the delivery of its content and will ensure that the uCDN is able to deliver both the types of content the CP requires delivery of and to the geographic regions that the CP requires delivery to. That is typically known in advance as part of the RFP/contract negotiation between the CP & the uCDN.

The uCDN may decide to make use of dCDNs to assist in the delivery of some or all of that content. The technical interconnect of the uCDN and dCDN is not occurring in a vacuum. The uCDN better make sure that it can cover its obligations to the CP either by itself or by ensuring that it has one or more dCDNs that can meet those obligations for it.

If the uCDN overcommits itself compared to its (or its dCDN's) capabilities bad things will happen (from the point of view of the CSP and the CSP's Users). The solution to that problem is not a technical solution IMO.

At the end of the day CPs will talk to their CPs about what they require and configure policies in their platform appropriately. Likewise uCDNs will talk with their dCDNs about what they require and configure policies in their platform appropriately. There isn't any magical protocol dust that means those conversations do not need to happen and IMO if those conversations are happening there's no need for protocol semantics to duplicate what is happening outside of the CDNI protocols themselves as part of those conversations and the per-CP/per-CDN configuration happening as a result.

> So let's assume there is ONE URL that is provided by the CP (portal) for the asset.  If that URL makes sense ONLY on the uCDN, then somewhere outside of the CP (portal) a decision must be made to re-write the URL such that it is appropriate for the dCDN.  That can be a simple re-write (modified FQDN with same PATH) or a more complex re-write (modified FQDN and PATH).

I don't see how URI rewriting applies to content adaptation. The URI a client uses to access the same content representation may differ by CDN and the URI may be transformed as part of CDNI request routing for example but the content itself is not transformed - the different URIs in each CDN still refer to the same specific content file.

Ben

>
> Are we bounding the use case ONLY those scenarios where the PATH structure remains unmodified and we're only changing the delivery point?  In this case, the uCDN and every dCDN would understand how to handle the exact same PATH structure.
>
> If the use case is expanded to include the URL PATH re-write, where would this be done?  If the CP (portal) does it, it needs to know information about which CDN will be used in order to pick the correct URL structure.  Otherwise, the uCDN must do the re-write into the appropriate PATH structure for the dCDN.  Is this in scope or not?
>
> Scott
>>
>> Ben
>>
>> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:
>>
>> > Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct.
>> > If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy.
>> >
>> > Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation.
>> > In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT).
>> > I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection.
>> > Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft.
>> >
>> > If you have any more question or comments, pls share in this thread.
>> > Thanks.
>> > Zhipeng
>> >
>> >
>> >
>> >
>> >
>> >
>> > -----Original Message-----
>> > From: Scott Wainner [mailto:swainner@cisco.com]
>> > Sent: Friday, September 30, 2011 8:02 AM
>> > To: cdni@ietf.org
>> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>> >
>> > Section 2.3 Nomadic Users
>> >   This description falls under the category of Geographic Extension yet
>> > the third paragraph states the case where a different device is used in
>> > the same CDN coverage area.  The intent of this use case needs to be
>> > clarified.  Perhaps the use case is trying to address the scenario where
>> > a Nomadic User-A with an agreement allowing access to content from CSP-A
>> > via uCDN moves to a dCDN in a different region.  The dCDN is allowed to
>> > distribute the content of CSP-A to User-A; however, not other users in
>> > the region of the dCDN are allowed to retrieve the content unless they
>> > too have such an agreement.
>> >
>> > Section 5.1.3 Content Encoding Restrictions
>> >   Need to clarify if we're talking about the restrictions on the
>> > delivery of specific content or the restrictions on the ability of a CDN
>> > to deliver specific content.  I certainly understand the case where a
>> > CSP will restrict the distribution of content to a "managed path" if
>> > such content is HD while allowing the content distribution via an
>> > un-managed path if such content is SD (same could apply to encryption
>> > methods, delivery methods, etc.).  On the contrary, the dCDN may have
>> > its own restrictions of blocking the distribution of HD content while
>> > allowing the distribution of SD content.
>> >
>> >   o first bullet makes sense if the dCDN can perform a subset of
>> > encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH)
>> >   o second bullet makes sense where the dCDN doesn't want to offer high
>> > bit-rate variants of the media
>> >   o third bullet make sense if the policy addresses QoE but I don't
>> > think subscriber rights/authorizations apply.
>> >
>> > Section 10 Security Considerations
>> >
>> > Aside from the security considerations WITHIN the uCDN and dCDN, I think
>> > we can describe this in four contexts:
>> >
>> > a. The relationship between the CSP and the uCDN (the principle contract
>> > arrangement for distribution)
>> > b. The relationship between the uCDN and dCDN (the transitive trust
>> > relationship that extends the contract defined in (a) above)
>> > c. The relationship between the User and dCDN (the recognition of right
>> > to download predicated on (b) above)
>> > d. The relationship between the User and CSP (the contract authorizing
>> > the user access to the content)
>> >
>> > The user is not interested in the a-b nor the b-c relationship. The user
>> > is only interested in the transparency and interoperability of the
>> > security relationship between d-b or d-c to the point that the
>> > authorization granted in d-a is viable when the delivery is initiated
>> > via either d-b or d-c.  As an example, the uCDN might use URL appended
>> > tokens for authentication while dCDN might use URL appended hashes.  The
>> > user doesn't want to know about the distinct methods, but transparency
>> > is only afforded if the methods are interoperable clearly defined when
>> > the delegation for content delivery is executed.  Clearly, the choice of
>> > authentication method is determined by the respective CDN's.
>> >
>> > Scott
>> >
>> > _______________________________________________
>> > CDNi mailing list
>> > CDNi@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cdni
>>
>>
>


--------------000805080409020309030704-- From ben@niven-jenkins.co.uk Tue Oct 11 08:51:00 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F36F21F8DC9 for ; Tue, 11 Oct 2011 08:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L714qg7eD73V for ; Tue, 11 Oct 2011 08:50:59 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF7F21F8C59 for ; Tue, 11 Oct 2011 08:50:59 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDebZ-00049o-7s; Tue, 11 Oct 2011 16:50:57 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B5151768@MAILR002.mail.lan> Date: Tue, 11 Oct 2011 16:50:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B5151768@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: ZhouZhipeng , "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:51:00 -0000 Kevin, On 11 Oct 2011, at 15:48, Kevin J Ma wrote: > Hi Ben, >=20 > I do not disagree with the statements made below, however, I think > that there is one point that is missing: in a non-interconnected > world, CPs can (and do) put different representations into different > CDNs, knowing that representation-A will not be accessible via CDN-B. > It is true that the CDN did not make any decision, the CP did, = however, > the enforcement is based on the fact that those CDNs will not share > with each other and are physically separated. With CDNI, if the uCDN > has access to all representations but the CP needs to enforce that > specific dCDNs only have access to subsets of representations (due to > content licensing restrictions), enforcing that probably requires > metadata to describe those delivery restrictions? I'd like to understand these requirements better as I am aware of = Content Providers that choose to use different CDNs for different = representations based on business policy and I think that can be solved = at the business agreement level in the same way as dealing with what = delivery protocols or delivery footprint the Content Provider requires. I am aware of licensing agreements that restrict what geographies = content can be delivered from and what geographies content can be = delivered to. Such requirements are already handled by the metadata = proposal I co-authored through the use of SelectionACL & DeliveryACLs.=20= However, I've not heard of a licensing agreement that mandated that some = representations of a piece of content absolutely must be delivered by a = different CDN to other representations of the same content. Can you expand on the motivation and drivers behind that requirement? Thanks Ben >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >> Ben Niven-Jenkins >> Sent: Tuesday, October 11, 2011 9:26 AM >> To: Brandenburg, R. (Ray) van >> Cc: cdni@ietf.org; ZhouZhipeng >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >>=20 >> On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: >>=20 >>> Hi all, >>>=20 >>> While I am neutral to the Content Adaptation discussion, I would = like to >> make sure that we do not throw out all features related to multiple >> representations, which would happen if we would just remove section = 5.1.3 >> completely as suggested by Ben. >>=20 >> I'm not sure how you draw that conclusion as removing section 5.1.3 = does >> not throw out the ability to support multiple representations IMO. >>=20 >>> The previous version of the use case document (betrand-02) had a >> slightly different wording in section 2.4 than is now being used in >> section 5.1 of the new WG-version. I think the concept of = resolution- >> based constraints, that was included in betrand-02, should remain in = some >> form. While it is not the CDNs responsibility/decision whether to = allow a >> specific representation to be delivered, I think a use case in which = some >> dCDN only offers a subset of the representations available on the = uCDN is >> quite valid (such as in a dedicated mobile CDN). >>=20 >> I don't believe that dCDNs will only offer a subset of = representations in >> the way you describe. They may only deliver to a subset of users (and >> maybe by implication a subset of possible devices) for example as a >> consequence of them being a dedicated mobile CDN (as opposed to an = active >> decision they make). >>=20 >> Let's look at how a content service is deployed. A Content Provider = has >> some content (let's say a video) that the Content Provider may = produce in >> a variety of representations (codecs, bit rates, resolutions, etc.). = They >> may do that encoding themselves or outsource it (although that's not >> relevant to the point I'm making). >>=20 >> A User will connect to the Content Provider's "portal" (which may be = a web >> portal, an application, an EPG etc.). The Content Provider (through = their >> portal) will offer the User the content in one or more of the = available >> representations (e.g. by device type but how that decision is made is >> purely up to the Content Provider). The User selects a representation = and >> the Content Provider offloads the delivery of that representation to = the >> CDN (e.g. by returning the appropriate URI for that representation = within >> the CDN to the User's client). The User then connects to the CDN and >> requests the representation they have selected (from the choice of >> representations offered to them by the Content Provider). >>=20 >> At its essence a CDN maps incoming URIs (from User's clients) to = specific >> content files on an upstream source (e.g. on-net storage or a Content >> Provider's Origin server) it has no explicit knowledge of what actual >> content that specific URI maps to or that it is one of X possible >> representations of the same content. >>=20 >> At no point has the CDN been involved in the selection or restriction = of >> the representations offered to or delivered to the User. In a CDNI >> scenario things are no different. A uCDN may select a dCDN based on = some >> capability (e.g. what Users it can deliver to, what delivery = protocols it >> can support) but I do not think that the specific representation of = the >> content will enter into the equation beyond those constraints. >>=20 >> For example, the dCDN is not going to say "I can only deliver >> representations with resolutions below AxB" and the uCDN often will = not >> even know what the resolution or a particular representation is. >>=20 >> What might happen is that a User on a particular network (or using a >> particular client/device) connects to the Content Provider's portal = and is >> only offered a subset of the possible representations tailored (by = the >> Content Provider's policy implemented in the Content Provider's = portal) >> based on that User's Network/Client/Device. A dCDN may subsequently = be >> selected that can serve that Network/Client/Service and that dCDN may = only >> end up delivering to its Users a subset of all the possible >> representations the Content Provider has produced. But that is a >> consequence of the Network/Clients/Devices the dCDN is capable of = serving, >> not an explicit decision made by the dCDN and communicated to the = uCDN for >> that specific Content Provider's service. >>=20 >> Ben >>=20 >>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From ray.vanbrandenburg@tno.nl Tue Oct 11 08:51:21 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D89121F8E76 for ; Tue, 11 Oct 2011 08:51:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ql83R1rJLFh for ; Tue, 11 Oct 2011 08:51:20 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id 019E621F8E6C for ; Tue, 11 Oct 2011 08:51:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,524,1312149600"; d="scan'208";a="58710154" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 11 Oct 2011 17:51:17 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0323.003; Tue, 11 Oct 2011 17:51:16 +0200 From: "Brandenburg, R. (Ray) van" To: Ben Niven-Jenkins Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMeV9XVExcRrnYVk25qolmOBlG5JVk9BkAgA0NMICAA2MzAIABwOGQ///5B4CAADuwYP//6i6AgAAhxQA= Date: Tue, 11 Oct 2011 15:51:15 +0000 Message-ID: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <6972906B-FA42-4025-BDB9-FD8E60FB6CA0@niven-jenkins.co.uk> In-Reply-To: <6972906B-FA42-4025-BDB9-FD8E60FB6CA0@niven-jenkins.co.uk> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:51:21 -0000 Ben, > Ultimately, even with adaptive streaming, the Content Provider chooses wh= at representations they make available. HTTP Adaptive streaming is no diffe= rent to my original example except instead of providing a URI for a specifi= c representation the Content Provider provides a "manifest" containing URIs= for one or more representations. At no point does the CDN get to decide wh= ich representations the Content Provider includes in their manifest. The CDN does not get to decide which representations the Content Provider s= hould include, but maybe the uCDN may get to decide which representations i= t wants to 'outsource' to the dCDN and which to deliver himself. And yes, t= his may require changes to the manifest. However I would not want to call c= hanging the URLs embedded in the manifest file content adaptation. As long = as the client still has access to all content put in the manifest by the CP= , I don't see a problem.=20 Ray -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Sent: dinsdag 11 oktober 2011 17:42 To: Brandenburg, R. (Ray) van Cc: ZhouZhipeng; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ray, On 11 Oct 2011, at 16:09, Brandenburg, R. (Ray) van wrote: > Hi Ben, >=20 > You make the assumption that selecting a specific representation is a con= scious decision, made either by a user or the CP, before the actual content= delivery commences. In this case, I agree with you completely.=20 >=20 > However, there are situations imaginable in which there is a switch betwe= en representations during content delivery. Let's take the HTTP Adaptive St= reaming situation for example. A given video might be encoded in 10 differe= nt qualities (representations), ranging from a 1080p stream all the way to = 128kbps stream meant for small-screen mobile devices. Depending on network = conditions or user preferences, a device might switch between these represe= ntation multiple times during video delivery. In your case it will only be = possible for a dCDN to host/deliver either all 10 of the representations, o= r none at all. What I meant was that in some situations, a dedicated mobile= dCDN might want to host/deliver the content, but not in all 10 representa= tions since the highest quality representations (e.g. 1080p) are of no use = to mobile clients.=20 Ultimately, even with adaptive streaming, the Content Provider chooses what= representations they make available. HTTP Adaptive streaming is no differe= nt to my original example except instead of providing a URI for a specific = representation the Content Provider provides a "manifest" containing URIs f= or one or more representations. At no point does the CDN get to decide whic= h representations the Content Provider includes in their manifest. Typically, the CDN only caches those representations that are actually requ= ested from it. Therefore it is not a black & white "all 10" or "none" as yo= u suggest. The Content Provider has ownership of what service they offer and the exper= ience they want the User to experience, not the CDN. It is not acceptable f= or a CDN to decide (outside of a business agreement) that it doesn't want t= o support some subset of the representations the Content Provider is offeri= ng and use "content adaptation" to modify the content to what the CDN would= prefer to deliver. Ben >=20 > I understand that this would mean that a CDN is no longer agnostic to the= content it delivers, but this is true for a lot of use cases that are incl= uded in the current draft.=20 >=20 > Ray >=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Sent: dinsdag 11 oktober 2011 15:26 > To: Brandenburg, R. (Ray) van > Cc: ZhouZhipeng; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 >=20 > On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: >=20 >> Hi all, >>=20 >> While I am neutral to the Content Adaptation discussion, I would like to= make sure that we do not throw out all features related to multiple repres= entations, which would happen if we would just remove section 5.1.3 complet= ely as suggested by Ben.=20 >=20 > I'm not sure how you draw that conclusion as removing section 5.1.3 does = not throw out the ability to support multiple representations IMO. >=20 >> The previous version of the use case document (betrand-02) had a slightl= y different wording in section 2.4 than is now being used in section 5.1 o= f the new WG-version. I think the concept of resolution-based constraints, = that was included in betrand-02, should remain in some form. While it is no= t the CDNs responsibility/decision whether to allow a specific representati= on to be delivered, I think a use case in which some dCDN only offers a sub= set of the representations available on the uCDN is quite valid (such as in= a dedicated mobile CDN).=20 >=20 > I don't believe that dCDNs will only offer a subset of representations in= the way you describe. They may only deliver to a subset of users (and mayb= e by implication a subset of possible devices) for example as a consequence= of them being a dedicated mobile CDN (as opposed to an active decision th= ey make). >=20 > Let's look at how a content service is deployed. A Content Provider has s= ome content (let's say a video) that the Content Provider may produce in a = variety of representations (codecs, bit rates, resolutions, etc.). They may= do that encoding themselves or outsource it (although that's not relevant = to the point I'm making). >=20 > A User will connect to the Content Provider's "portal" (which may be a we= b portal, an application, an EPG etc.). The Content Provider (through their= portal) will offer the User the content in one or more of the available re= presentations (e.g. by device type but how that decision is made is purely = up to the Content Provider). The User selects a representation and the Cont= ent Provider offloads the delivery of that representation to the CDN (e.g. = by returning the appropriate URI for that representation within the CDN to = the User's client). The User then connects to the CDN and requests the repr= esentation they have selected (from the choice of representations offered t= o them by the Content Provider). >=20 > At its essence a CDN maps incoming URIs (from User's clients) to specific= content files on an upstream source (e.g. on-net storage or a Content Prov= ider's Origin server) it has no explicit knowledge of what actual content t= hat specific URI maps to or that it is one of X possible representations of= the same content. >=20 > At no point has the CDN been involved in the selection or restriction of = the representations offered to or delivered to the User. In a CDNI scenario= things are no different. A uCDN may select a dCDN based on some capability= (e.g. what Users it can deliver to, what delivery protocols it can support= ) but I do not think that the specific representation of the content will e= nter into the equation beyond those constraints. >=20 > For example, the dCDN is not going to say "I can only deliver representat= ions with resolutions below AxB" and the uCDN often will not even know what= the resolution or a particular representation is.=20 >=20 > What might happen is that a User on a particular network (or using a part= icular client/device) connects to the Content Provider's portal and is only= offered a subset of the possible representations tailored (by the Content = Provider's policy implemented in the Content Provider's portal) based on th= at User's Network/Client/Device. A dCDN may subsequently be selected that c= an serve that Network/Client/Service and that dCDN may only end up deliveri= ng to its Users a subset of all the possible representations the Content Pr= ovider has produced. But that is a consequence of the Network/Clients/Devic= es the dCDN is capable of serving, not an explicit decision made by the dCD= N and communicated to the uCDN for that specific Content Provider's service= . >=20 > Ben >=20 >=20 >=20 > This e-mail and its contents are subject to the DISCLAIMER at http://www.= tno.nl/emaildisclaimer >=20 From ben@niven-jenkins.co.uk Tue Oct 11 08:56:15 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4847A21F8E7C for ; Tue, 11 Oct 2011 08:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4Vg8b5zhSI3 for ; Tue, 11 Oct 2011 08:56:14 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id C4A2921F8E34 for ; Tue, 11 Oct 2011 08:56:13 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDege-0004RQ-GM; Tue, 11 Oct 2011 16:56:13 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 11 Oct 2011 16:56:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <6972906B-FA42-4025-BDB9-FD8E60FB6CA0@niven-jenkins.co.uk> To: "Brandenburg, R. (Ray) van" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 15:56:15 -0000 Ray, On 11 Oct 2011, at 16:51, Brandenburg, R. (Ray) van wrote: > Ben, >=20 >> Ultimately, even with adaptive streaming, the Content Provider = chooses what representations they make available. HTTP Adaptive = streaming is no different to my original example except instead of = providing a URI for a specific representation the Content Provider = provides a "manifest" containing URIs for one or more representations. = At no point does the CDN get to decide which representations the Content = Provider includes in their manifest. >=20 > The CDN does not get to decide which representations the Content = Provider should include, but maybe the uCDN may get to decide which = representations it wants to 'outsource' to the dCDN and which to deliver = himself. And yes, this may require changes to the manifest. However I = would not want to call changing the URLs embedded in the manifest file = content adaptation. As long as the client still has access to all = content put in the manifest by the CP, I don't see a problem.=20 Personally I believe uCDNs are unlikely to make choices of whether to = use a dCDN or not based on a subset of representations in a manifest. I = think the overriding factors will be things like which network the User = is on and what the delivery protocol is. In any case, even if a uCDN did want to split like that then there are = methods to achieve that without requiring rewriting the manifest. Ben >=20 > Ray >=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Sent: dinsdag 11 oktober 2011 17:42 > To: Brandenburg, R. (Ray) van > Cc: ZhouZhipeng; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Ray, >=20 > On 11 Oct 2011, at 16:09, Brandenburg, R. (Ray) van wrote: >=20 >> Hi Ben, >>=20 >> You make the assumption that selecting a specific representation is a = conscious decision, made either by a user or the CP, before the actual = content delivery commences. In this case, I agree with you completely.=20= >>=20 >> However, there are situations imaginable in which there is a switch = between representations during content delivery. Let's take the HTTP = Adaptive Streaming situation for example. A given video might be encoded = in 10 different qualities (representations), ranging from a 1080p stream = all the way to 128kbps stream meant for small-screen mobile devices. = Depending on network conditions or user preferences, a device might = switch between these representation multiple times during video = delivery. In your case it will only be possible for a dCDN to = host/deliver either all 10 of the representations, or none at all. What = I meant was that in some situations, a dedicated mobile dCDN might want = to host/deliver the content, but not in all 10 representations since = the highest quality representations (e.g. 1080p) are of no use to mobile = clients.=20 >=20 > Ultimately, even with adaptive streaming, the Content Provider chooses = what representations they make available. HTTP Adaptive streaming is no = different to my original example except instead of providing a URI for a = specific representation the Content Provider provides a "manifest" = containing URIs for one or more representations. At no point does the = CDN get to decide which representations the Content Provider includes in = their manifest. >=20 > Typically, the CDN only caches those representations that are actually = requested from it. Therefore it is not a black & white "all 10" or = "none" as you suggest. >=20 > The Content Provider has ownership of what service they offer and the = experience they want the User to experience, not the CDN. It is not = acceptable for a CDN to decide (outside of a business agreement) that it = doesn't want to support some subset of the representations the Content = Provider is offering and use "content adaptation" to modify the content = to what the CDN would prefer to deliver. >=20 > Ben >=20 >>=20 >> I understand that this would mean that a CDN is no longer agnostic to = the content it delivers, but this is true for a lot of use cases that = are included in the current draft.=20 >>=20 >> Ray >>=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 >> Sent: dinsdag 11 oktober 2011 15:26 >> To: Brandenburg, R. (Ray) van >> Cc: ZhouZhipeng; cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >>=20 >> On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: >>=20 >>> Hi all, >>>=20 >>> While I am neutral to the Content Adaptation discussion, I would = like to make sure that we do not throw out all features related to = multiple representations, which would happen if we would just remove = section 5.1.3 completely as suggested by Ben.=20 >>=20 >> I'm not sure how you draw that conclusion as removing section 5.1.3 = does not throw out the ability to support multiple representations IMO. >>=20 >>> The previous version of the use case document (betrand-02) had a = slightly different wording in section 2.4 than is now being used in = section 5.1 of the new WG-version. I think the concept of = resolution-based constraints, that was included in betrand-02, should = remain in some form. While it is not the CDNs responsibility/decision = whether to allow a specific representation to be delivered, I think a = use case in which some dCDN only offers a subset of the representations = available on the uCDN is quite valid (such as in a dedicated mobile = CDN).=20 >>=20 >> I don't believe that dCDNs will only offer a subset of = representations in the way you describe. They may only deliver to a = subset of users (and maybe by implication a subset of possible devices) = for example as a consequence of them being a dedicated mobile CDN (as = opposed to an active decision they make). >>=20 >> Let's look at how a content service is deployed. A Content Provider = has some content (let's say a video) that the Content Provider may = produce in a variety of representations (codecs, bit rates, resolutions, = etc.). They may do that encoding themselves or outsource it (although = that's not relevant to the point I'm making). >>=20 >> A User will connect to the Content Provider's "portal" (which may be = a web portal, an application, an EPG etc.). The Content Provider = (through their portal) will offer the User the content in one or more of = the available representations (e.g. by device type but how that decision = is made is purely up to the Content Provider). The User selects a = representation and the Content Provider offloads the delivery of that = representation to the CDN (e.g. by returning the appropriate URI for = that representation within the CDN to the User's client). The User then = connects to the CDN and requests the representation they have selected = (from the choice of representations offered to them by the Content = Provider). >>=20 >> At its essence a CDN maps incoming URIs (from User's clients) to = specific content files on an upstream source (e.g. on-net storage or a = Content Provider's Origin server) it has no explicit knowledge of what = actual content that specific URI maps to or that it is one of X possible = representations of the same content. >>=20 >> At no point has the CDN been involved in the selection or restriction = of the representations offered to or delivered to the User. In a CDNI = scenario things are no different. A uCDN may select a dCDN based on some = capability (e.g. what Users it can deliver to, what delivery protocols = it can support) but I do not think that the specific representation of = the content will enter into the equation beyond those constraints. >>=20 >> For example, the dCDN is not going to say "I can only deliver = representations with resolutions below AxB" and the uCDN often will not = even know what the resolution or a particular representation is.=20 >>=20 >> What might happen is that a User on a particular network (or using a = particular client/device) connects to the Content Provider's portal and = is only offered a subset of the possible representations tailored (by = the Content Provider's policy implemented in the Content Provider's = portal) based on that User's Network/Client/Device. A dCDN may = subsequently be selected that can serve that Network/Client/Service and = that dCDN may only end up delivering to its Users a subset of all the = possible representations the Content Provider has produced. But that is = a consequence of the Network/Clients/Devices the dCDN is capable of = serving, not an explicit decision made by the dCDN and communicated to = the uCDN for that specific Content Provider's service. >>=20 >> Ben >>=20 >>=20 >>=20 >> This e-mail and its contents are subject to the DISCLAIMER at = http://www.tno.nl/emaildisclaimer >>=20 >=20 From ray.vanbrandenburg@tno.nl Tue Oct 11 09:01:45 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D587C21F8EB3 for ; Tue, 11 Oct 2011 09:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFtIpc4hY24S for ; Tue, 11 Oct 2011 09:01:44 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id 4655421F8EE1 for ; Tue, 11 Oct 2011 09:01:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.68,524,1312149600"; d="scan'208";a="58710590" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 11 Oct 2011 18:01:38 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.01.0323.003; Tue, 11 Oct 2011 18:01:38 +0200 From: "Brandenburg, R. (Ray) van" To: Ben Niven-Jenkins Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMeV9XVExcRrnYVk25qolmOBlG5JVk9BkAgA0NMICAA2MzAIABwOGQ///5B4CAADuwYP//6i6AgAAhxQD//+JLgAAEO84A Date: Tue, 11 Oct 2011 16:01:37 +0000 Message-ID: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <6972906B-FA42-4025-BDB9-FD8E60FB6CA0@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:01:46 -0000 Ben, > Personally I believe uCDNs are unlikely to make choices of whether to use= a dCDN or not based on a subset of representations in a manifest. I think = the overriding factors will be things like which network the User is on and= what the delivery protocol is. I think there might be some situations (e.g. live or mobile CDNs) where thi= s is a valid situation. The question is whether we should allow or deny the= se kinds of situation within our CDNI work. My personal opinion is in favor= of allowing it, but if the consensus should point otherwise... Ray -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Sent: dinsdag 11 oktober 2011 17:56 To: Brandenburg, R. (Ray) van Cc: ZhouZhipeng; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ray, On 11 Oct 2011, at 16:51, Brandenburg, R. (Ray) van wrote: > Ben, >=20 >> Ultimately, even with adaptive streaming, the Content Provider chooses w= hat representations they make available. HTTP Adaptive streaming is no diff= erent to my original example except instead of providing a URI for a specif= ic representation the Content Provider provides a "manifest" containing URI= s for one or more representations. At no point does the CDN get to decide w= hich representations the Content Provider includes in their manifest. >=20 > The CDN does not get to decide which representations the Content Provider= should include, but maybe the uCDN may get to decide which representations= it wants to 'outsource' to the dCDN and which to deliver himself. And yes,= this may require changes to the manifest. However I would not want to call= changing the URLs embedded in the manifest file content adaptation. As lon= g as the client still has access to all content put in the manifest by the = CP, I don't see a problem.=20 Personally I believe uCDNs are unlikely to make choices of whether to use a= dCDN or not based on a subset of representations in a manifest. I think th= e overriding factors will be things like which network the User is on and w= hat the delivery protocol is. In any case, even if a uCDN did want to split like that then there are meth= ods to achieve that without requiring rewriting the manifest. Ben >=20 > Ray >=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Sent: dinsdag 11 oktober 2011 17:42 > To: Brandenburg, R. (Ray) van > Cc: ZhouZhipeng; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Ray, >=20 > On 11 Oct 2011, at 16:09, Brandenburg, R. (Ray) van wrote: >=20 >> Hi Ben, >>=20 >> You make the assumption that selecting a specific representation is a co= nscious decision, made either by a user or the CP, before the actual conten= t delivery commences. In this case, I agree with you completely.=20 >>=20 >> However, there are situations imaginable in which there is a switch betw= een representations during content delivery. Let's take the HTTP Adaptive S= treaming situation for example. A given video might be encoded in 10 differ= ent qualities (representations), ranging from a 1080p stream all the way to= 128kbps stream meant for small-screen mobile devices. Depending on network= conditions or user preferences, a device might switch between these repres= entation multiple times during video delivery. In your case it will only be= possible for a dCDN to host/deliver either all 10 of the representations, = or none at all. What I meant was that in some situations, a dedicated mobil= e dCDN might want to host/deliver the content, but not in all 10 represent= ations since the highest quality representations (e.g. 1080p) are of no use= to mobile clients.=20 >=20 > Ultimately, even with adaptive streaming, the Content Provider chooses wh= at representations they make available. HTTP Adaptive streaming is no diffe= rent to my original example except instead of providing a URI for a specifi= c representation the Content Provider provides a "manifest" containing URIs= for one or more representations. At no point does the CDN get to decide wh= ich representations the Content Provider includes in their manifest. >=20 > Typically, the CDN only caches those representations that are actually re= quested from it. Therefore it is not a black & white "all 10" or "none" as = you suggest. >=20 > The Content Provider has ownership of what service they offer and the exp= erience they want the User to experience, not the CDN. It is not acceptable= for a CDN to decide (outside of a business agreement) that it doesn't want= to support some subset of the representations the Content Provider is offe= ring and use "content adaptation" to modify the content to what the CDN wou= ld prefer to deliver. >=20 > Ben >=20 >>=20 >> I understand that this would mean that a CDN is no longer agnostic to th= e content it delivers, but this is true for a lot of use cases that are inc= luded in the current draft.=20 >>=20 >> Ray >>=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 >> Sent: dinsdag 11 oktober 2011 15:26 >> To: Brandenburg, R. (Ray) van >> Cc: ZhouZhipeng; cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >>=20 >> On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: >>=20 >>> Hi all, >>>=20 >>> While I am neutral to the Content Adaptation discussion, I would like t= o make sure that we do not throw out all features related to multiple repre= sentations, which would happen if we would just remove section 5.1.3 comple= tely as suggested by Ben.=20 >>=20 >> I'm not sure how you draw that conclusion as removing section 5.1.3 does= not throw out the ability to support multiple representations IMO. >>=20 >>> The previous version of the use case document (betrand-02) had a slight= ly different wording in section 2.4 than is now being used in section 5.1 = of the new WG-version. I think the concept of resolution-based constraints,= that was included in betrand-02, should remain in some form. While it is n= ot the CDNs responsibility/decision whether to allow a specific representat= ion to be delivered, I think a use case in which some dCDN only offers a su= bset of the representations available on the uCDN is quite valid (such as i= n a dedicated mobile CDN).=20 >>=20 >> I don't believe that dCDNs will only offer a subset of representations i= n the way you describe. They may only deliver to a subset of users (and may= be by implication a subset of possible devices) for example as a consequenc= e of them being a dedicated mobile CDN (as opposed to an active decision t= hey make). >>=20 >> Let's look at how a content service is deployed. A Content Provider has = some content (let's say a video) that the Content Provider may produce in a= variety of representations (codecs, bit rates, resolutions, etc.). They ma= y do that encoding themselves or outsource it (although that's not relevant= to the point I'm making). >>=20 >> A User will connect to the Content Provider's "portal" (which may be a w= eb portal, an application, an EPG etc.). The Content Provider (through thei= r portal) will offer the User the content in one or more of the available r= epresentations (e.g. by device type but how that decision is made is purely= up to the Content Provider). The User selects a representation and the Con= tent Provider offloads the delivery of that representation to the CDN (e.g.= by returning the appropriate URI for that representation within the CDN to= the User's client). The User then connects to the CDN and requests the rep= resentation they have selected (from the choice of representations offered = to them by the Content Provider). >>=20 >> At its essence a CDN maps incoming URIs (from User's clients) to specifi= c content files on an upstream source (e.g. on-net storage or a Content Pro= vider's Origin server) it has no explicit knowledge of what actual content = that specific URI maps to or that it is one of X possible representations o= f the same content. >>=20 >> At no point has the CDN been involved in the selection or restriction of= the representations offered to or delivered to the User. In a CDNI scenari= o things are no different. A uCDN may select a dCDN based on some capabilit= y (e.g. what Users it can deliver to, what delivery protocols it can suppor= t) but I do not think that the specific representation of the content will = enter into the equation beyond those constraints. >>=20 >> For example, the dCDN is not going to say "I can only deliver representa= tions with resolutions below AxB" and the uCDN often will not even know wha= t the resolution or a particular representation is.=20 >>=20 >> What might happen is that a User on a particular network (or using a par= ticular client/device) connects to the Content Provider's portal and is onl= y offered a subset of the possible representations tailored (by the Content= Provider's policy implemented in the Content Provider's portal) based on t= hat User's Network/Client/Device. A dCDN may subsequently be selected that = can serve that Network/Client/Service and that dCDN may only end up deliver= ing to its Users a subset of all the possible representations the Content P= rovider has produced. But that is a consequence of the Network/Clients/Devi= ces the dCDN is capable of serving, not an explicit decision made by the dC= DN and communicated to the uCDN for that specific Content Provider's servic= e. >>=20 >> Ben >>=20 >>=20 >>=20 >> This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer >>=20 >=20 From kevin.ma@azukisystems.com Tue Oct 11 09:04:50 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C05F21F8EED for ; Tue, 11 Oct 2011 09:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAAA+re6AC2Y for ; Tue, 11 Oct 2011 09:04:49 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id E68E821F8EB9 for ; Tue, 11 Oct 2011 09:04:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 4CC125552ED; Tue, 11 Oct 2011 12:04:48 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D84BC554E78; Tue, 11 Oct 2011 12:04:36 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Tue, 11 Oct 2011 12:04:15 -0400 From: Kevin J Ma To: Ben Niven-Jenkins Date: Tue, 11 Oct 2011 12:04:18 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyILaNxgfGmi71uTyS4A0eFwyx96wAAOmFA Message-ID: <291CC3F9E50E7641901A54E85D0977C651B515180A@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B5151768@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ZhouZhipeng , "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:04:50 -0000 Ben, The restriction is not that content "absolutely must be delivered by a different CDN", the restriction is that content should only be delivered in specific formats to specific end users, and certain users may only get access through specific CDNs. This can be (and is) enforced today by using different CDNs (e.g., separate CDNs for TV vs mobile). Once those two CDNs combine, it removes an inherent physical restriction, which some CPs may have been relying on. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Tuesday, October 11, 2011 11:51 AM > To: Kevin J Ma > Cc: Brandenburg, R. (Ray) van; cdni@ietf.org; ZhouZhipeng > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Kevin, >=20 > On 11 Oct 2011, at 15:48, Kevin J Ma wrote: >=20 > > Hi Ben, > > > > I do not disagree with the statements made below, however, I think > > that there is one point that is missing: in a non-interconnected > > world, CPs can (and do) put different representations into different > > CDNs, knowing that representation-A will not be accessible via CDN-B. > > It is true that the CDN did not make any decision, the CP did, however= , > > the enforcement is based on the fact that those CDNs will not share > > with each other and are physically separated. With CDNI, if the uCDN > > has access to all representations but the CP needs to enforce that > > specific dCDNs only have access to subsets of representations (due to > > content licensing restrictions), enforcing that probably requires > > metadata to describe those delivery restrictions? >=20 > I'd like to understand these requirements better as I am aware of Content > Providers that choose to use different CDNs for different representations > based on business policy and I think that can be solved at the business > agreement level in the same way as dealing with what delivery protocols o= r > delivery footprint the Content Provider requires. >=20 > I am aware of licensing agreements that restrict what geographies content > can be delivered from and what geographies content can be delivered to. > Such requirements are already handled by the metadata proposal I co- > authored through the use of SelectionACL & DeliveryACLs. >=20 > However, I've not heard of a licensing agreement that mandated that some > representations of a piece of content absolutely must be delivered by a > different CDN to other representations of the same content. >=20 > Can you expand on the motivation and drivers behind that requirement? >=20 > Thanks > Ben >=20 > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > >> Ben Niven-Jenkins > >> Sent: Tuesday, October 11, 2011 9:26 AM > >> To: Brandenburg, R. (Ray) van > >> Cc: cdni@ietf.org; ZhouZhipeng > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> > >> On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: > >> > >>> Hi all, > >>> > >>> While I am neutral to the Content Adaptation discussion, I would like > to > >> make sure that we do not throw out all features related to multiple > >> representations, which would happen if we would just remove section > 5.1.3 > >> completely as suggested by Ben. > >> > >> I'm not sure how you draw that conclusion as removing section 5.1.3 > does > >> not throw out the ability to support multiple representations IMO. > >> > >>> The previous version of the use case document (betrand-02) had a > >> slightly different wording in section 2.4 than is now being used in > >> section 5.1 of the new WG-version. I think the concept of resolution- > >> based constraints, that was included in betrand-02, should remain in > some > >> form. While it is not the CDNs responsibility/decision whether to allo= w > a > >> specific representation to be delivered, I think a use case in which > some > >> dCDN only offers a subset of the representations available on the uCDN > is > >> quite valid (such as in a dedicated mobile CDN). > >> > >> I don't believe that dCDNs will only offer a subset of representations > in > >> the way you describe. They may only deliver to a subset of users (and > >> maybe by implication a subset of possible devices) for example as a > >> consequence of them being a dedicated mobile CDN (as opposed to an > active > >> decision they make). > >> > >> Let's look at how a content service is deployed. A Content Provider ha= s > >> some content (let's say a video) that the Content Provider may produce > in > >> a variety of representations (codecs, bit rates, resolutions, etc.). > They > >> may do that encoding themselves or outsource it (although that's not > >> relevant to the point I'm making). > >> > >> A User will connect to the Content Provider's "portal" (which may be a > web > >> portal, an application, an EPG etc.). The Content Provider (through > their > >> portal) will offer the User the content in one or more of the availabl= e > >> representations (e.g. by device type but how that decision is made is > >> purely up to the Content Provider). The User selects a representation > and > >> the Content Provider offloads the delivery of that representation to > the > >> CDN (e.g. by returning the appropriate URI for that representation > within > >> the CDN to the User's client). The User then connects to the CDN and > >> requests the representation they have selected (from the choice of > >> representations offered to them by the Content Provider). > >> > >> At its essence a CDN maps incoming URIs (from User's clients) to > specific > >> content files on an upstream source (e.g. on-net storage or a Content > >> Provider's Origin server) it has no explicit knowledge of what actual > >> content that specific URI maps to or that it is one of X possible > >> representations of the same content. > >> > >> At no point has the CDN been involved in the selection or restriction > of > >> the representations offered to or delivered to the User. In a CDNI > >> scenario things are no different. A uCDN may select a dCDN based on > some > >> capability (e.g. what Users it can deliver to, what delivery protocols > it > >> can support) but I do not think that the specific representation of th= e > >> content will enter into the equation beyond those constraints. > >> > >> For example, the dCDN is not going to say "I can only deliver > >> representations with resolutions below AxB" and the uCDN often will no= t > >> even know what the resolution or a particular representation is. > >> > >> What might happen is that a User on a particular network (or using a > >> particular client/device) connects to the Content Provider's portal an= d > is > >> only offered a subset of the possible representations tailored (by the > >> Content Provider's policy implemented in the Content Provider's portal= ) > >> based on that User's Network/Client/Device. A dCDN may subsequently be > >> selected that can serve that Network/Client/Service and that dCDN may > only > >> end up delivering to its Users a subset of all the possible > >> representations the Content Provider has produced. But that is a > >> consequence of the Network/Clients/Devices the dCDN is capable of > serving, > >> not an explicit decision made by the dCDN and communicated to the uCDN > for > >> that specific Content Provider's service. > >> > >> Ben > >> > >> > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Tue Oct 11 09:19:33 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34021F8DF9 for ; Tue, 11 Oct 2011 09:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYsXFBRqI+AQ for ; Tue, 11 Oct 2011 09:19:32 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id C48B421F8DF5 for ; Tue, 11 Oct 2011 09:19:31 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDf3C-0000K5-Cl; Tue, 11 Oct 2011 17:19:31 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> Date: Tue, 11 Oct 2011 17:19:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> To: ZhouZhipeng X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:19:33 -0000 Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > Ben and Philip, > I like to respond your concern in this one email: >=20 > Ben, > I feel what we are now discussing is what is the "core" function of = CDN. > As you say, CDN is used to deliver content. That is absolutely correct = that the delivery capability is the core requirement for CDN system. > While CDN is used to provide the content delivery service. > What means service. It should include "time" "location" and "media = type", etc. These features are all the core feature for a service. > If we only concern "delivering one data block", I am not sure whether = the issues such as "logging" "geographic constraint" are the core of = CDN. >=20 > For "without explicit knowledge of what that content actually is ", I = am not sure whether the wording is accurate since generally a CDN may = claim it support different medias. > By this opportunity, I like to share a use case: a call from a GSM = phone to a PSTN telephone, the voice stream should be transformed from = GSM voice to G.711. > For the user, he does not need to know what type of data has been = transferred, but the operator has done some work to interconnect two = systems, right. > I like to know whether you may accept that my use case is similar to = this case above. I don't think your use case is similar to the analogy of mobile networks = being interconnected to PSTN networks. In the case of content delivery = the negotiation is done between the User/Client and the Content Provider = and the CDN is just used to execute/perform the delivery that has been = negotiated. The CDN is not involved in the decision making of what = representations the Content Provider decides to offer to the User/Client = or in what representations the User/Client decides to request. =20 > As for you said selecting media by the "portal", you may see the way " = uCDN delivers multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media types".=20 Now what you're talking about is an optimisation, not a core function = required to actually deliver the content (and report, bill, etc. for = that delivery).=20 My position is that we should focus on how to enable the interconnection = of the core CDN functionality offered by CDNs today (which is also my = interpretation of the scope of the CDNI working group as expressed in = its charter) because doing so is a significant piece of work in itself. = Let's not start trying to add in additional functionality beyond what = the majority of CDNs support today as that will just delay us getting = usable specifications into the market in a timely fashion IMO. Ben > A good question is "security" since I have done six years on the DRM = and like to promote the DRM all around the world:) > If the content is needed to be protected, generally you may know all = the systems should be granted by the content owner. > Here I also like to clarify that not only the media itself but the = information related to service itself (such as the geographic = constraint) should be protected also. > So, trust is not a problem for the media. >=20 > Philip, > Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use case. > I like to clarify to U that it is important for you operator since it = may save investment if the system may support different services. > For us vendor, we are happy operator may install a system for the = mobile service and another system for the FBB service. > But the reality is all operators ask us to provide a system that may = support different service systems. >=20 > Frankly, Ben and Philip, I remember I have explained somewhere that to = implement this is rather simple . > At least the Use case and Requirement are informational to be referred = in future work. So I do really feel you may accept it. > Of course I like to respond your more concern and comments. > Thanks. > Zhipeng >=20 >=20 >=20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 > Sent: Monday, October 10, 2011 11:22 PM > To: ben@niven-jenkins.co.uk; ZhouZhipeng > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Ben, Zhipeng, all,=20 >=20 > I think that Content Adaptation is more an issue for the Requirements = doc than for the Use cases draft.=20 >=20 > The key question is whether we want the CDNI interfaces to be able to = cope with a scenario where (say) HD/SD conversion is done in the dCDN & = to signal about this. >=20 > I think that coping with this scenario is a second order requirement, = ie we should not worry about it in the initial standards-track work. I = don't know, did we ever decide whether the Use cases doc is restricted = to "initial" scenarios, or whether it's all-encompassing, ie covering = "future" scenarios as well?=20 >=20 > Scott, > Reading some of your examples, they seem to be valid even if content = adaptation (HD/SD) is out of scope.=20 > - a dCDN might for some reason be unwilling to distribute HD? > - a CSP might want to make sure the dCDN can use HLS encapsulation? > But these sorts of examples seem to be static policy things (to do = with the capabilities & preferences of the CDNs & CSP), rather than = metadata associated with a particular piece of content. In the = discussion so far, I think negotiation about static policy stuff is = rather out of scope(?) >=20 > On security considerations, an interesting question is whether trust = is transitive. Don't think it need be - just because CSP trusts uCDN, = and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the = dCDN. However, i suspect this can get arbitrarily complex - so one = possibility is to say that we will only handle cases where the trust is = transitive. >=20 > Best wishes > phil >=20 >=20 > Philip Eardley =20 > Research and Technology Strategy >=20 > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 >=20 >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins > Sent: 10 October 2011 12:04 > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Colleagues, >=20 > IMO Section 5.1.3 should be removed from the Use Cases draft. Content = Adaptation (i.e. taking in a content item in one format and transforming = it to another format or representation) is not a "core" function of a = CDN which typically delivers the content that is requested without = explicit knowledge of what that content actually is. >=20 > Let's not forget that in building an end to end content service the = CDN is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. >=20 > The decision as to which version/copy/representation to offer and = allow to be delivered to a given device/user is implemented outside of = the CDN (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content). >=20 > Ben >=20 > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: >=20 >> Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. >> If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. >>=20 >> Here the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content adaptation. >> In last month, I have contacted the Authors of this document and = taken some email exchanges with Grant and Philip (BT). >> I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. >> Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. >>=20 >> If you have any more question or comments, pls share in this thread. >> Thanks. >> Zhipeng >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Scott Wainner [mailto:swainner@cisco.com]=20 >> Sent: Friday, September 30, 2011 8:02 AM >> To: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >> Section 2.3 Nomadic Users >> This description falls under the category of Geographic Extension = yet=20 >> the third paragraph states the case where a different device is used = in=20 >> the same CDN coverage area. The intent of this use case needs to be=20= >> clarified. Perhaps the use case is trying to address the scenario = where=20 >> a Nomadic User-A with an agreement allowing access to content from = CSP-A=20 >> via uCDN moves to a dCDN in a different region. The dCDN is allowed = to=20 >> distribute the content of CSP-A to User-A; however, not other users = in=20 >> the region of the dCDN are allowed to retrieve the content unless = they=20 >> too have such an agreement. >>=20 >> Section 5.1.3 Content Encoding Restrictions >> Need to clarify if we're talking about the restrictions on the=20 >> delivery of specific content or the restrictions on the ability of a = CDN=20 >> to deliver specific content. I certainly understand the case where a=20= >> CSP will restrict the distribution of content to a "managed path" if=20= >> such content is HD while allowing the content distribution via an=20 >> un-managed path if such content is SD (same could apply to encryption=20= >> methods, delivery methods, etc.). On the contrary, the dCDN may have=20= >> its own restrictions of blocking the distribution of HD content while=20= >> allowing the distribution of SD content. >>=20 >> o first bullet makes sense if the dCDN can perform a subset of=20 >> encapsulations for a reference set of media (e.g. HLS, HSS, but not = DASH) >> o second bullet makes sense where the dCDN doesn't want to offer = high=20 >> bit-rate variants of the media >> o third bullet make sense if the policy addresses QoE but I don't=20 >> think subscriber rights/authorizations apply. >>=20 >> Section 10 Security Considerations >>=20 >> Aside from the security considerations WITHIN the uCDN and dCDN, I = think=20 >> we can describe this in four contexts: >>=20 >> a. The relationship between the CSP and the uCDN (the principle = contract=20 >> arrangement for distribution)=09 >> b. The relationship between the uCDN and dCDN (the transitive trust=20= >> relationship that extends the contract defined in (a) above) >> c. The relationship between the User and dCDN (the recognition of = right=20 >> to download predicated on (b) above) >> d. The relationship between the User and CSP (the contract = authorizing=20 >> the user access to the content) >>=20 >> The user is not interested in the a-b nor the b-c relationship. The = user=20 >> is only interested in the transparency and interoperability of the=20 >> security relationship between d-b or d-c to the point that the=20 >> authorization granted in d-a is viable when the delivery is initiated=20= >> via either d-b or d-c. As an example, the uCDN might use URL = appended=20 >> tokens for authentication while dCDN might use URL appended hashes. = The=20 >> user doesn't want to know about the distinct methods, but = transparency=20 >> is only afforded if the methods are interoperable clearly defined = when=20 >> the delegation for content delivery is executed. Clearly, the choice = of=20 >> authentication method is determined by the respective CDN's. >>=20 >> Scott >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Tue Oct 11 09:30:10 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090C021F8EA4 for ; Tue, 11 Oct 2011 09:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVL+T2QDOQPg for ; Tue, 11 Oct 2011 09:30:09 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id DAD1C21F8E83 for ; Tue, 11 Oct 2011 09:30:08 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RDfDT-0000wS-MG; Tue, 11 Oct 2011 17:30:08 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B515180A@MAILR002.mail.lan> Date: Tue, 11 Oct 2011 17:30:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C91B87E-BEA1-4D34-9896-558DF0F39101@niven-jenkins.co.uk> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B5151768@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C651B515180A@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: ZhouZhipeng , "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:30:10 -0000 Kevin, On 11 Oct 2011, at 17:04, Kevin J Ma wrote: > Ben, >=20 > The restriction is not that content "absolutely must be delivered by = a > different CDN", the restriction is that content should only be = delivered > in specific formats to specific end users, and certain users may only > get access through specific CDNs. This can be (and is) enforced = today by > using different CDNs (e.g., separate CDNs for TV vs mobile). Once = those > two CDNs combine, it removes an inherent physical restriction, which = some > CPs may have been relying on. The services I am aware of enforce such restrictions by requiring = content delivery to be authenticated (e.g. through use of a = token/cookie) and the Content Provider's portal only handing out the = necessary tokens/cookies for certain content to the appropriate = users/clients. By doing so there is no need to rely on some inherent = physical separation of different CDNs in order to be able to enforce the = COntent Provider's policy and therefore no need to rely on the implicit = physical separation of different CDNs. After all the entire purpose of a CDN is to offer multiple independent = services off a single physical platform, so if a CDN is not capable of = meeting the separation needs of the services offered by a single Content = Provider, I'd suggest they have some pretty big issues that would mean = it is unlikely that a Content Provider would want to use them at all for = any kind of delivery. Ben >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> Sent: Tuesday, October 11, 2011 11:51 AM >> To: Kevin J Ma >> Cc: Brandenburg, R. (Ray) van; cdni@ietf.org; ZhouZhipeng >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >> Kevin, >>=20 >> On 11 Oct 2011, at 15:48, Kevin J Ma wrote: >>=20 >>> Hi Ben, >>>=20 >>> I do not disagree with the statements made below, however, I think >>> that there is one point that is missing: in a non-interconnected >>> world, CPs can (and do) put different representations into different >>> CDNs, knowing that representation-A will not be accessible via = CDN-B. >>> It is true that the CDN did not make any decision, the CP did, = however, >>> the enforcement is based on the fact that those CDNs will not share >>> with each other and are physically separated. With CDNI, if the = uCDN >>> has access to all representations but the CP needs to enforce that >>> specific dCDNs only have access to subsets of representations (due = to >>> content licensing restrictions), enforcing that probably requires >>> metadata to describe those delivery restrictions? >>=20 >> I'd like to understand these requirements better as I am aware of = Content >> Providers that choose to use different CDNs for different = representations >> based on business policy and I think that can be solved at the = business >> agreement level in the same way as dealing with what delivery = protocols or >> delivery footprint the Content Provider requires. >>=20 >> I am aware of licensing agreements that restrict what geographies = content >> can be delivered from and what geographies content can be delivered = to. >> Such requirements are already handled by the metadata proposal I co- >> authored through the use of SelectionACL & DeliveryACLs. >>=20 >> However, I've not heard of a licensing agreement that mandated that = some >> representations of a piece of content absolutely must be delivered by = a >> different CDN to other representations of the same content. >>=20 >> Can you expand on the motivation and drivers behind that requirement? >>=20 >> Thanks >> Ben >>=20 >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>>> -----Original Message----- >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On = Behalf Of >>>> Ben Niven-Jenkins >>>> Sent: Tuesday, October 11, 2011 9:26 AM >>>> To: Brandenburg, R. (Ray) van >>>> Cc: cdni@ietf.org; ZhouZhipeng >>>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>>=20 >>>>=20 >>>> On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: >>>>=20 >>>>> Hi all, >>>>>=20 >>>>> While I am neutral to the Content Adaptation discussion, I would = like >> to >>>> make sure that we do not throw out all features related to multiple >>>> representations, which would happen if we would just remove section >> 5.1.3 >>>> completely as suggested by Ben. >>>>=20 >>>> I'm not sure how you draw that conclusion as removing section 5.1.3 >> does >>>> not throw out the ability to support multiple representations IMO. >>>>=20 >>>>> The previous version of the use case document (betrand-02) had a >>>> slightly different wording in section 2.4 than is now being used in >>>> section 5.1 of the new WG-version. I think the concept of = resolution- >>>> based constraints, that was included in betrand-02, should remain = in >> some >>>> form. While it is not the CDNs responsibility/decision whether to = allow >> a >>>> specific representation to be delivered, I think a use case in = which >> some >>>> dCDN only offers a subset of the representations available on the = uCDN >> is >>>> quite valid (such as in a dedicated mobile CDN). >>>>=20 >>>> I don't believe that dCDNs will only offer a subset of = representations >> in >>>> the way you describe. They may only deliver to a subset of users = (and >>>> maybe by implication a subset of possible devices) for example as a >>>> consequence of them being a dedicated mobile CDN (as opposed to an >> active >>>> decision they make). >>>>=20 >>>> Let's look at how a content service is deployed. A Content Provider = has >>>> some content (let's say a video) that the Content Provider may = produce >> in >>>> a variety of representations (codecs, bit rates, resolutions, = etc.). >> They >>>> may do that encoding themselves or outsource it (although that's = not >>>> relevant to the point I'm making). >>>>=20 >>>> A User will connect to the Content Provider's "portal" (which may = be a >> web >>>> portal, an application, an EPG etc.). The Content Provider (through >> their >>>> portal) will offer the User the content in one or more of the = available >>>> representations (e.g. by device type but how that decision is made = is >>>> purely up to the Content Provider). The User selects a = representation >> and >>>> the Content Provider offloads the delivery of that representation = to >> the >>>> CDN (e.g. by returning the appropriate URI for that representation >> within >>>> the CDN to the User's client). The User then connects to the CDN = and >>>> requests the representation they have selected (from the choice of >>>> representations offered to them by the Content Provider). >>>>=20 >>>> At its essence a CDN maps incoming URIs (from User's clients) to >> specific >>>> content files on an upstream source (e.g. on-net storage or a = Content >>>> Provider's Origin server) it has no explicit knowledge of what = actual >>>> content that specific URI maps to or that it is one of X possible >>>> representations of the same content. >>>>=20 >>>> At no point has the CDN been involved in the selection or = restriction >> of >>>> the representations offered to or delivered to the User. In a CDNI >>>> scenario things are no different. A uCDN may select a dCDN based on >> some >>>> capability (e.g. what Users it can deliver to, what delivery = protocols >> it >>>> can support) but I do not think that the specific representation of = the >>>> content will enter into the equation beyond those constraints. >>>>=20 >>>> For example, the dCDN is not going to say "I can only deliver >>>> representations with resolutions below AxB" and the uCDN often will = not >>>> even know what the resolution or a particular representation is. >>>>=20 >>>> What might happen is that a User on a particular network (or using = a >>>> particular client/device) connects to the Content Provider's portal = and >> is >>>> only offered a subset of the possible representations tailored (by = the >>>> Content Provider's policy implemented in the Content Provider's = portal) >>>> based on that User's Network/Client/Device. A dCDN may subsequently = be >>>> selected that can serve that Network/Client/Service and that dCDN = may >> only >>>> end up delivering to its Users a subset of all the possible >>>> representations the Content Provider has produced. But that is a >>>> consequence of the Network/Clients/Devices the dCDN is capable of >> serving, >>>> not an explicit decision made by the dCDN and communicated to the = uCDN >> for >>>> that specific Content Provider's service. >>>>=20 >>>> Ben >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >=20 From zhouzhipeng@huawei.com Wed Oct 12 02:25:18 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22DC621F8C55 for ; Wed, 12 Oct 2011 02:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MUA4N3Si+qo for ; Wed, 12 Oct 2011 02:25:16 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8AA21F8C6C for ; Wed, 12 Oct 2011 02:25:16 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY005KJ4QJVR@szxga03-in.huawei.com> for cdni@ietf.org; Wed, 12 Oct 2011 17:23:08 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY00JSY4PWTR@szxga03-in.huawei.com> for cdni@ietf.org; Wed, 12 Oct 2011 17:23:07 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ73898; Wed, 12 Oct 2011 17:23:06 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 17:23:02 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 12 Oct 2011 17:22:58 +0800 Date: Wed, 12 Oct 2011 09:22:57 +0000 From: ZhouZhipeng In-reply-to: <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> X-Originating-IP: [10.138.73.38] To: Ben Niven-Jenkins Message-id: <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 09:25:18 -0000 Hello Ben, The UE may select the content format on the CP web. After that the user only desires to get his selected content. But how the content is transferred to the client is not worried by the user. The CP may create a special format as required by the user and ask the CDN to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select. In this case, it is nothing related to how the user select formats on CP website. So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion). As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look. I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media formats. One candidate is your company, another is CDN-X. The users are located in France. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > Ben and Philip, > I like to respond your concern in this one email: > > Ben, > I feel what we are now discussing is what is the "core" function of CDN. > As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system. > While CDN is used to provide the content delivery service. > What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service. > If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN. > > For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias. > By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711. > For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right. > I like to know whether you may accept that my use case is similar to this case above. I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request. > As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types". Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery). My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO. Ben > A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) > If the content is needed to be protected, generally you may know all the systems should be granted by the content owner. > Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also. > So, trust is not a problem for the media. > > Philip, > Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case. > I like to clarify to U that it is important for you operator since it may save investment if the system may support different services. > For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service. > But the reality is all operators ask us to provide a system that may support different service systems. > > Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple . > At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it. > Of course I like to respond your more concern and comments. > Thanks. > Zhipeng > > > > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Monday, October 10, 2011 11:22 PM > To: ben@niven-jenkins.co.uk; ZhouZhipeng > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Ben, Zhipeng, all, > > I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft. > > The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this. > > I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well? > > Scott, > Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. > - a dCDN might for some reason be unwilling to distribute HD? > - a CSP might want to make sure the dCDN can use HLS encapsulation? > But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) > > On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive. > > Best wishes > phil > > > Philip Eardley > Research and Technology Strategy > > This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > Sent: 10 October 2011 12:04 > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Colleagues, > > IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is. > > Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered. > > The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content). > > Ben > > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > >> Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. >> If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. >> >> Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. >> In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). >> I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. >> Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. >> >> If you have any more question or comments, pls share in this thread. >> Thanks. >> Zhipeng >> >> >> >> >> >> >> -----Original Message----- >> From: Scott Wainner [mailto:swainner@cisco.com] >> Sent: Friday, September 30, 2011 8:02 AM >> To: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> >> Section 2.3 Nomadic Users >> This description falls under the category of Geographic Extension yet >> the third paragraph states the case where a different device is used in >> the same CDN coverage area. The intent of this use case needs to be >> clarified. Perhaps the use case is trying to address the scenario where >> a Nomadic User-A with an agreement allowing access to content from CSP-A >> via uCDN moves to a dCDN in a different region. The dCDN is allowed to >> distribute the content of CSP-A to User-A; however, not other users in >> the region of the dCDN are allowed to retrieve the content unless they >> too have such an agreement. >> >> Section 5.1.3 Content Encoding Restrictions >> Need to clarify if we're talking about the restrictions on the >> delivery of specific content or the restrictions on the ability of a CDN >> to deliver specific content. I certainly understand the case where a >> CSP will restrict the distribution of content to a "managed path" if >> such content is HD while allowing the content distribution via an >> un-managed path if such content is SD (same could apply to encryption >> methods, delivery methods, etc.). On the contrary, the dCDN may have >> its own restrictions of blocking the distribution of HD content while >> allowing the distribution of SD content. >> >> o first bullet makes sense if the dCDN can perform a subset of >> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) >> o second bullet makes sense where the dCDN doesn't want to offer high >> bit-rate variants of the media >> o third bullet make sense if the policy addresses QoE but I don't >> think subscriber rights/authorizations apply. >> >> Section 10 Security Considerations >> >> Aside from the security considerations WITHIN the uCDN and dCDN, I think >> we can describe this in four contexts: >> >> a. The relationship between the CSP and the uCDN (the principle contract >> arrangement for distribution) >> b. The relationship between the uCDN and dCDN (the transitive trust >> relationship that extends the contract defined in (a) above) >> c. The relationship between the User and dCDN (the recognition of right >> to download predicated on (b) above) >> d. The relationship between the User and CSP (the contract authorizing >> the user access to the content) >> >> The user is not interested in the a-b nor the b-c relationship. The user >> is only interested in the transparency and interoperability of the >> security relationship between d-b or d-c to the point that the >> authorization granted in d-a is viable when the delivery is initiated >> via either d-b or d-c. As an example, the uCDN might use URL appended >> tokens for authentication while dCDN might use URL appended hashes. The >> user doesn't want to know about the distinct methods, but transparency >> is only afforded if the methods are interoperable clearly defined when >> the delegation for content delivery is executed. Clearly, the choice of >> authentication method is determined by the respective CDN's. >> >> Scott >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From zhouzhipeng@huawei.com Wed Oct 12 02:42:10 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC5021F8C6C for ; Wed, 12 Oct 2011 02:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVwdQ0tNXwXm for ; Wed, 12 Oct 2011 02:42:09 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C5AD421F8C65 for ; Wed, 12 Oct 2011 02:42:08 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY00JZZ5JRM0@szxga04-in.huawei.com> for cdni@ietf.org; Wed, 12 Oct 2011 17:40:39 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY002G45JMLX@szxga04-in.huawei.com> for cdni@ietf.org; Wed, 12 Oct 2011 17:40:39 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ75451; Wed, 12 Oct 2011 17:40:39 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 17:40:35 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Wed, 12 Oct 2011 17:40:32 +0800 Date: Wed, 12 Oct 2011 09:40:30 +0000 From: ZhouZhipeng X-Originating-IP: [10.138.73.38] To: Ben Niven-Jenkins Message-id: <260A32EFD5C9EB47AD504929D005DF6245AD7E@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAAFIOw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 09:42:10 -0000 Sorry a typo below : Which solution is more competitive. it is "not" Solution 1, right. -----Original Message----- From: ZhouZhipeng Sent: Wednesday, October 12, 2011 5:23 PM To: 'Ben Niven-Jenkins' Cc: philip.eardley@bt.com; cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hello Ben, The UE may select the content format on the CP web. After that the user only desires to get his selected content. But how the content is transferred to the client is not worried by the user. The CP may create a special format as required by the user and ask the CDN to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select. In this case, it is nothing related to how the user select formats on CP website. So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion). As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look. I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media formats. One candidate is your company, another is CDN-X. The users are located in France. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > Ben and Philip, > I like to respond your concern in this one email: > > Ben, > I feel what we are now discussing is what is the "core" function of CDN. > As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system. > While CDN is used to provide the content delivery service. > What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service. > If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN. > > For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias. > By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711. > For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right. > I like to know whether you may accept that my use case is similar to this case above. I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request. > As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types". Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery). My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO. Ben > A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) > If the content is needed to be protected, generally you may know all the systems should be granted by the content owner. > Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also. > So, trust is not a problem for the media. > > Philip, > Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case. > I like to clarify to U that it is important for you operator since it may save investment if the system may support different services. > For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service. > But the reality is all operators ask us to provide a system that may support different service systems. > > Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple . > At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it. > Of course I like to respond your more concern and comments. > Thanks. > Zhipeng > > > > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Monday, October 10, 2011 11:22 PM > To: ben@niven-jenkins.co.uk; ZhouZhipeng > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Ben, Zhipeng, all, > > I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft. > > The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this. > > I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well? > > Scott, > Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. > - a dCDN might for some reason be unwilling to distribute HD? > - a CSP might want to make sure the dCDN can use HLS encapsulation? > But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) > > On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive. > > Best wishes > phil > > > Philip Eardley > Research and Technology Strategy > > This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no: 1800000 > > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > Sent: 10 October 2011 12:04 > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Colleagues, > > IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is. > > Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered. > > The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content). > > Ben > > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > >> Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. >> If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. >> >> Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. >> In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). >> I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. >> Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. >> >> If you have any more question or comments, pls share in this thread. >> Thanks. >> Zhipeng >> >> >> >> >> >> >> -----Original Message----- >> From: Scott Wainner [mailto:swainner@cisco.com] >> Sent: Friday, September 30, 2011 8:02 AM >> To: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> >> Section 2.3 Nomadic Users >> This description falls under the category of Geographic Extension yet >> the third paragraph states the case where a different device is used in >> the same CDN coverage area. The intent of this use case needs to be >> clarified. Perhaps the use case is trying to address the scenario where >> a Nomadic User-A with an agreement allowing access to content from CSP-A >> via uCDN moves to a dCDN in a different region. The dCDN is allowed to >> distribute the content of CSP-A to User-A; however, not other users in >> the region of the dCDN are allowed to retrieve the content unless they >> too have such an agreement. >> >> Section 5.1.3 Content Encoding Restrictions >> Need to clarify if we're talking about the restrictions on the >> delivery of specific content or the restrictions on the ability of a CDN >> to deliver specific content. I certainly understand the case where a >> CSP will restrict the distribution of content to a "managed path" if >> such content is HD while allowing the content distribution via an >> un-managed path if such content is SD (same could apply to encryption >> methods, delivery methods, etc.). On the contrary, the dCDN may have >> its own restrictions of blocking the distribution of HD content while >> allowing the distribution of SD content. >> >> o first bullet makes sense if the dCDN can perform a subset of >> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) >> o second bullet makes sense where the dCDN doesn't want to offer high >> bit-rate variants of the media >> o third bullet make sense if the policy addresses QoE but I don't >> think subscriber rights/authorizations apply. >> >> Section 10 Security Considerations >> >> Aside from the security considerations WITHIN the uCDN and dCDN, I think >> we can describe this in four contexts: >> >> a. The relationship between the CSP and the uCDN (the principle contract >> arrangement for distribution) >> b. The relationship between the uCDN and dCDN (the transitive trust >> relationship that extends the contract defined in (a) above) >> c. The relationship between the User and dCDN (the recognition of right >> to download predicated on (b) above) >> d. The relationship between the User and CSP (the contract authorizing >> the user access to the content) >> >> The user is not interested in the a-b nor the b-c relationship. The user >> is only interested in the transparency and interoperability of the >> security relationship between d-b or d-c to the point that the >> authorization granted in d-a is viable when the delivery is initiated >> via either d-b or d-c. As an example, the uCDN might use URL appended >> tokens for authentication while dCDN might use URL appended hashes. The >> user doesn't want to know about the distinct methods, but transparency >> is only afforded if the methods are interoperable clearly defined when >> the delegation for content delivery is executed. Clearly, the choice of >> authentication method is determined by the respective CDN's. >> >> Scott >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From zhouzhipeng@huawei.com Wed Oct 12 02:42:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CBF521F8C65 for ; Wed, 12 Oct 2011 02:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGw76Q2WdAW6 for ; Wed, 12 Oct 2011 02:42:57 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 70D1121F8C55 for ; Wed, 12 Oct 2011 02:42:56 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY00L925NIPB@szxga03-in.huawei.com> for cdni@ietf.org; Wed, 12 Oct 2011 17:42:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSY00KE15N8EF@szxga03-in.huawei.com> for cdni@ietf.org; Wed, 12 Oct 2011 17:42:54 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEE72547; Wed, 12 Oct 2011 17:42:53 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 12 Oct 2011 17:42:49 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Wed, 12 Oct 2011 17:42:47 +0800 Date: Wed, 12 Oct 2011 09:42:46 +0000 From: ZhouZhipeng In-reply-to: <4E9455D5.50708@cisco.com> X-Originating-IP: [10.138.73.38] To: Scott Wainner , Ben Niven-Jenkins Message-id: <260A32EFD5C9EB47AD504929D005DF6245AD96@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_l/phVY7ZmrVhdZNwH0rjpA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAc8+gIABv1XQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <4E9455D5.50708@cisco.com> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 09:42:58 -0000 --Boundary_(ID_l/phVY7ZmrVhdZNwH0rjpA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Scott, >>I tend to agree. Although content adaptation may be desirable, it's not clear that we could effectively bound the number permutations of content adaptation that may be possible (encryption, watermark, transrate, transcode, etc.) it means you have felt the scenario is valuable, right. But you have some uncertainty (permutations of content adaptation). Perhaps the content protection(encryption, watermark) is a little professional, i may just give a short conclusion that the security risk is mainly on the client not the server. And the CDN use case has not brought new feature for the content protection. In fact the DRM work has done much complicated description of all possible scenarios. As for transrate, transcode, too simple for the current equipment capability. And the CDNs(not CDN interconnection) may support such functionalities. Zhipeng From: Scott Wainner [mailto:swainner@cisco.com] Sent: Tuesday, October 11, 2011 10:42 PM To: Ben Niven-Jenkins Cc: ZhouZhipeng; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt On 10/10/11 7:04 AM, Ben Niven-Jenkins wrote: Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is. I tend to agree. Although content adaptation may be desirable, it's not clear that we could effectively bound the number permutations of content adaptation that may be possible (encryption, watermark, transrate, transcode, etc.) Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content). Agreed. This means the portal makes a decision about the specific content object without regard to the capabilities of the CDN(s). There is a presumption that the set of CDN's can deliver the content. That assumption has a high probability of success with regards to the relationship between the uCDN and CP because there is an explicit business relationship. That assumption may not be valid when dealing with a dCDN that has a business relationship with the uCDN. So let's assume there is ONE URL that is provided by the CP (portal) for the asset. If that URL makes sense ONLY on the uCDN, then somewhere outside of the CP (portal) a decision must be made to re-write the URL such that it is appropriate for the dCDN. That can be a simple re-write (modified FQDN with same PATH) or a more complex re-write (modified FQDN and PATH). Are we bounding the use case ONLY those scenarios where the PATH structure remains unmodified and we're only changing the delivery point? In this case, the uCDN and every dCDN would understand how to handle the exact same PATH structure. If the use case is expanded to include the URL PATH re-write, where would this be done? If the CP (portal) does it, it needs to know information about which CDN will be used in order to pick the correct URL structure. Otherwise, the uCDN must do the re-write into the appropriate PATH structure for the dCDN. Is this in scope or not? Scott Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. > If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. > > Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. > In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). > I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. > Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. > > If you have any more question or comments, pls share in this thread. > Thanks. > Zhipeng > > > > > > > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com] > Sent: Friday, September 30, 2011 8:02 AM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Section 2.3 Nomadic Users > This description falls under the category of Geographic Extension yet > the third paragraph states the case where a different device is used in > the same CDN coverage area. The intent of this use case needs to be > clarified. Perhaps the use case is trying to address the scenario where > a Nomadic User-A with an agreement allowing access to content from CSP-A > via uCDN moves to a dCDN in a different region. The dCDN is allowed to > distribute the content of CSP-A to User-A; however, not other users in > the region of the dCDN are allowed to retrieve the content unless they > too have such an agreement. > > Section 5.1.3 Content Encoding Restrictions > Need to clarify if we're talking about the restrictions on the > delivery of specific content or the restrictions on the ability of a CDN > to deliver specific content. I certainly understand the case where a > CSP will restrict the distribution of content to a "managed path" if > such content is HD while allowing the content distribution via an > un-managed path if such content is SD (same could apply to encryption > methods, delivery methods, etc.). On the contrary, the dCDN may have > its own restrictions of blocking the distribution of HD content while > allowing the distribution of SD content. > > o first bullet makes sense if the dCDN can perform a subset of > encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) > o second bullet makes sense where the dCDN doesn't want to offer high > bit-rate variants of the media > o third bullet make sense if the policy addresses QoE but I don't > think subscriber rights/authorizations apply. > > Section 10 Security Considerations > > Aside from the security considerations WITHIN the uCDN and dCDN, I think > we can describe this in four contexts: > > a. The relationship between the CSP and the uCDN (the principle contract > arrangement for distribution) > b. The relationship between the uCDN and dCDN (the transitive trust > relationship that extends the contract defined in (a) above) > c. The relationship between the User and dCDN (the recognition of right > to download predicated on (b) above) > d. The relationship between the User and CSP (the contract authorizing > the user access to the content) > > The user is not interested in the a-b nor the b-c relationship. The user > is only interested in the transparency and interoperability of the > security relationship between d-b or d-c to the point that the > authorization granted in d-a is viable when the delivery is initiated > via either d-b or d-c. As an example, the uCDN might use URL appended > tokens for authentication while dCDN might use URL appended hashes. The > user doesn't want to know about the distinct methods, but transparency > is only afforded if the methods are interoperable clearly defined when > the delegation for content delivery is executed. Clearly, the choice of > authentication method is determined by the respective CDN's. > > Scott > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Boundary_(ID_l/phVY7ZmrVhdZNwH0rjpA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Scott,

>>I tend to agree.  Although content adaptation may be desirable, it's not clear that we could effectively bound the number permutations of content adaptation that may be possible (encryption, watermark, transrate, transcode, etc.)

it means you have felt the scenario is valuable, right.

But you have some uncertainty (permutations of content adaptation).

 

Perhaps the content protection(encryption, watermark) is a little professional, i may just give a short conclusion that the security risk is mainly on the client not the server.

And the CDN use case has not brought new feature for the content protection. In fact the DRM work has done much complicated description of all possible scenarios.

As for transrate, transcode, too simple for the current equipment capability. And the CDNs(not CDN interconnection) may support such functionalities.

 

 

Zhipeng

 

 

From: Scott Wainner [mailto:swainner@cisco.com]
Sent: Tuesday, October 11, 2011 10:42 PM
To: Ben Niven-Jenkins
Cc: ZhouZhipeng; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

 

On 10/10/11 7:04 AM, Ben Niven-Jenkins wrote:

Colleagues,

IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is.

I tend to agree.  Although content adaptation may be desirable, it's not clear that we could effectively bound the number permutations of content adaptation that may be possible (encryption, watermark, transrate, transcode, etc.)


Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered.

The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content).

Agreed.  This means the portal makes a decision about the specific content object without regard to the capabilities of the CDN(s).  There is a presumption that the set of CDN's can deliver the content.  That assumption has a high probability of success with regards to the relationship between the uCDN and CP because there is an explicit business relationship.  That assumption may not be valid when dealing with a dCDN that has a business relationship with the uCDN.

So let's assume there is ONE URL that is provided by the CP (portal) for the asset.  If that URL makes sense ONLY on the uCDN, then somewhere outside of the CP (portal) a decision must be made to re-write the URL such that it is appropriate for the dCDN.  That can be a simple re-write (modified FQDN with same PATH) or a more complex re-write (modified FQDN and PATH).

Are we bounding the use case ONLY those scenarios where the PATH structure remains unmodified and we're only changing the delivery point?  In this case, the uCDN and every dCDN would understand how to handle the exact same PATH structure.

If the use case is expanded to include the URL PATH re-write, where would this be done?  If the CP (portal) does it, it needs to know information about which CDN will be used in order to pick the correct URL structure.  Otherwise, the uCDN must do the re-write into the appropriate PATH structure for the dCDN.  Is this in scope or not?

Scott


Ben

On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:

> Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct.
> If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy.
>
> Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation.
> In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT).
> I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection.
> Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft.
>
> If you have any more question or comments, pls share in this thread.
> Thanks.
> Zhipeng
>
>
>
>
>
>
> -----Original Message-----
> From: Scott Wainner [mailto:swainner@cisco.com]
> Sent: Friday, September 30, 2011 8:02 AM
> To: cdni@ietf.org
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Section 2.3 Nomadic Users
>   This description falls under the category of Geographic Extension yet
> the third paragraph states the case where a different device is used in
> the same CDN coverage area.  The intent of this use case needs to be
> clarified.  Perhaps the use case is trying to address the scenario where
> a Nomadic User-A with an agreement allowing access to content from CSP-A
> via uCDN moves to a dCDN in a different region.  The dCDN is allowed to
> distribute the content of CSP-A to User-A; however, not other users in
> the region of the dCDN are allowed to retrieve the content unless they
> too have such an agreement.
>
> Section 5.1.3 Content Encoding Restrictions
>   Need to clarify if we're talking about the restrictions on the
> delivery of specific content or the restrictions on the ability of a CDN
> to deliver specific content.  I certainly understand the case where a
> CSP will restrict the distribution of content to a "managed path" if
> such content is HD while allowing the content distribution via an
> un-managed path if such content is SD (same could apply to encryption
> methods, delivery methods, etc.).  On the contrary, the dCDN may have
> its own restrictions of blocking the distribution of HD content while
> allowing the distribution of SD content.
>
>   o first bullet makes sense if the dCDN can perform a subset of
> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH)
>   o second bullet makes sense where the dCDN doesn't want to offer high
> bit-rate variants of the media
>   o third bullet make sense if the policy addresses QoE but I don't
> think subscriber rights/authorizations apply.
>
> Section 10 Security Considerations
>
> Aside from the security considerations WITHIN the uCDN and dCDN, I think
> we can describe this in four contexts:
>
> a. The relationship between the CSP and the uCDN (the principle contract
> arrangement for distribution)
> b. The relationship between the uCDN and dCDN (the transitive trust
> relationship that extends the contract defined in (a) above)
> c. The relationship between the User and dCDN (the recognition of right
> to download predicated on (b) above)
> d. The relationship between the User and CSP (the contract authorizing
> the user access to the content)
>
> The user is not interested in the a-b nor the b-c relationship. The user
> is only interested in the transparency and interoperability of the
> security relationship between d-b or d-c to the point that the
> authorization granted in d-a is viable when the delivery is initiated
> via either d-b or d-c.  As an example, the uCDN might use URL appended
> tokens for authentication while dCDN might use URL appended hashes.  The
> user doesn't want to know about the distinct methods, but transparency
> is only afforded if the methods are interoperable clearly defined when
> the delegation for content delivery is executed.  Clearly, the choice of
> authentication method is determined by the respective CDN's.
>
> Scott
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni

 

--Boundary_(ID_l/phVY7ZmrVhdZNwH0rjpA)-- From ben@niven-jenkins.co.uk Wed Oct 12 10:12:45 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A4B21F8B86 for ; Wed, 12 Oct 2011 10:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lbnBOsiVMEV for ; Wed, 12 Oct 2011 10:12:44 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id B977A21F8B82 for ; Wed, 12 Oct 2011 10:12:43 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp65-238.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RE2MD-0007A7-GK; Wed, 12 Oct 2011 18:12:42 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> Date: Wed, 12 Oct 2011 18:12:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> To: ZhouZhipeng X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 17:12:45 -0000 Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > Hello Ben, > The UE may select the content format on the CP web. After that the = user only desires to get his selected content.=20 > But how the content is transferred to the client is not worried by the = user. > The CP may create a special format as required by the user and ask the = CDN to deliver to user. > While CP may give a HD format content to uCDN and the dCDN may then = transform to the format as the user select. Lots of things may be possible to do and CDN providers offer many = additional services on top of the "core" service of content delivery. = However, our objective (based on my interpretation of the CDNI charter) = is to focus on what is necessary to interconnect CDNs to deliver content = from a CSP to an End User that is targeted and deployable within a short = time frame (18-24 months). Content transformation/adaptation is not an essential requirement in = order to achieve that aim (we can deliver content from CSPs to End Users = via multiple CDNs without needing or requiring any CDN supports content = adaptation). In my opinion we have enough work to do already without trying to expand = the scope of our work to include additional requirements that do not = help us address our core objectives as laid out in the CDNI charter. > In this case, it is nothing related to how the user select formats on = CP website. > So, it is the CP and user to decide the content format not the = CDN(your assert is not correct and seems you take that assert as your = base for the discussion). >=20 > As for "the core CDN functionality offered by CDNs today", I have ever = raised an email before that your company's webpage has claimed = supporting media transformation and multi-screen service. > Perhaps, I like asking you list some features that you feel are the = core functionalities by existing main stream CDNs. Thus we may compare = and take deep look. I think the core functionality maps pretty well to the CDNI interfaces, = namely: Request Routing, Metadata configuration, log production and = control plus content acquisition and content delivery. =20 > I guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in process. >=20 > Besides, I like raise a case: > Given currently BBC recruits CDN providers that may support 10 media = formats. > One candidate is your company, another is CDN-X. The users are located = in France. > So both your company and CDN-X should connect a France CDN = provider(CDN-Y). > If your company's solution is to send 10 streams of different format = of one content to CDN-Y; > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may = conduct some adaptation. > Comparing these two solutions, for your company and CDN-X, absolutely = the cost of CDN-X is much lower. > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while = in solution-2, it should only receive 1 stream but need to take = transformation to output 10 streams. >=20 > Which solution is more competitive. it is Solution 1, right. Remember = the price from BBC is same to both your company and CDN-X or BBC would = select one CDN provider with the lower price. > If a CDN provider may not get the contract from CP, how it may say it = is not a core functionality.=20 What you are describing is a possible optimization that a particular CDN = may wish to implement not a core functionality required to enable = content delivery between interconnected CDNs. I can think of many = optimizations that a CDN could implement to differentiate their service = but the internal workings of an individual CDN are out of scope of our = charter. So to repeat my position for a final time: Content adaptation is not a = core function required to enable content delivery between interconnected = CDNs and therefore given the workload we already have to specify = solutions that do address the core functionality required to = interconnect CDNs I do not think we should be trying to add more work = into that workload as it will only distract us from achieving our goal = of producing deployable solutions within the timeframe we are being told = by operators they needs solutions within. Ben =20 > So, if we all realize that currently the media type is rich, the CDN = providers should survive in the existing ecosystem and support the media = types as required by the market. >=20 > Back to the case of GSM/G.711, it just when concerning the = interconnection, the transformation should at once be solved. Otherwise = the interconnection may not be operated. >=20 > Br, > Zhipeng >=20 >=20 >=20 >=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Sent: Wednesday, October 12, 2011 12:19 AM > To: ZhouZhipeng > Cc: philip.eardley@bt.com; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Zhipeng, >=20 > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: >=20 >> Ben and Philip, >> I like to respond your concern in this one email: >>=20 >> Ben, >> I feel what we are now discussing is what is the "core" function of = CDN. >> As you say, CDN is used to deliver content. That is absolutely = correct that the delivery capability is the core requirement for CDN = system. >> While CDN is used to provide the content delivery service. >> What means service. It should include "time" "location" and "media = type", etc. These features are all the core feature for a service. >> If we only concern "delivering one data block", I am not sure whether = the issues such as "logging" "geographic constraint" are the core of = CDN. >>=20 >> For "without explicit knowledge of what that content actually is ", I = am not sure whether the wording is accurate since generally a CDN may = claim it support different medias. >> By this opportunity, I like to share a use case: a call from a GSM = phone to a PSTN telephone, the voice stream should be transformed from = GSM voice to G.711. >> For the user, he does not need to know what type of data has been = transferred, but the operator has done some work to interconnect two = systems, right. >> I like to know whether you may accept that my use case is similar to = this case above. >=20 > I don't think your use case is similar to the analogy of mobile = networks being interconnected to PSTN networks. In the case of content = delivery the negotiation is done between the User/Client and the Content = Provider and the CDN is just used to execute/perform the delivery that = has been negotiated. The CDN is not involved in the decision making of = what representations the Content Provider decides to offer to the = User/Client or in what representations the User/Client decides to = request. >=20 >> As for you said selecting media by the "portal", you may see the way = " uCDN delivers multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media types".=20 >=20 > Now what you're talking about is an optimisation, not a core function = required to actually deliver the content (and report, bill, etc. for = that delivery).=20 >=20 > My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO. >=20 > Ben >=20 >> A good question is "security" since I have done six years on the DRM = and like to promote the DRM all around the world:) >> If the content is needed to be protected, generally you may know all = the systems should be granted by the content owner. >> Here I also like to clarify that not only the media itself but the = information related to service itself (such as the geographic = constraint) should be protected also. >> So, trust is not a problem for the media. >>=20 >> Philip, >> Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use case. >> I like to clarify to U that it is important for you operator since it = may save investment if the system may support different services. >> For us vendor, we are happy operator may install a system for the = mobile service and another system for the FBB service. >> But the reality is all operators ask us to provide a system that may = support different service systems. >>=20 >> Frankly, Ben and Philip, I remember I have explained somewhere that = to implement this is rather simple . >> At least the Use case and Requirement are informational to be = referred in future work. So I do really feel you may accept it. >> Of course I like to respond your more concern and comments. >> Thanks. >> Zhipeng >>=20 >>=20 >>=20 >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]=20 >> Sent: Monday, October 10, 2011 11:22 PM >> To: ben@niven-jenkins.co.uk; ZhouZhipeng >> Cc: cdni@ietf.org >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >> Ben, Zhipeng, all,=20 >>=20 >> I think that Content Adaptation is more an issue for the Requirements = doc than for the Use cases draft.=20 >>=20 >> The key question is whether we want the CDNI interfaces to be able to = cope with a scenario where (say) HD/SD conversion is done in the dCDN & = to signal about this. >>=20 >> I think that coping with this scenario is a second order requirement, = ie we should not worry about it in the initial standards-track work. I = don't know, did we ever decide whether the Use cases doc is restricted = to "initial" scenarios, or whether it's all-encompassing, ie covering = "future" scenarios as well?=20 >>=20 >> Scott, >> Reading some of your examples, they seem to be valid even if content = adaptation (HD/SD) is out of scope.=20 >> - a dCDN might for some reason be unwilling to distribute HD? >> - a CSP might want to make sure the dCDN can use HLS encapsulation? >> But these sorts of examples seem to be static policy things (to do = with the capabilities & preferences of the CDNs & CSP), rather than = metadata associated with a particular piece of content. In the = discussion so far, I think negotiation about static policy stuff is = rather out of scope(?) >>=20 >> On security considerations, an interesting question is whether trust = is transitive. Don't think it need be - just because CSP trusts uCDN, = and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the = dCDN. However, i suspect this can get arbitrarily complex - so one = possibility is to say that we will only handle cases where the trust is = transitive. >>=20 >> Best wishes >> phil >>=20 >>=20 >> Philip Eardley =20 >> Research and Technology Strategy >>=20 >> This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. >> British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ >> Registered in England no: 1800000 >>=20 >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins >> Sent: 10 October 2011 12:04 >> To: ZhouZhipeng >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >> Colleagues, >>=20 >> IMO Section 5.1.3 should be removed from the Use Cases draft. Content = Adaptation (i.e. taking in a content item in one format and transforming = it to another format or representation) is not a "core" function of a = CDN which typically delivers the content that is requested without = explicit knowledge of what that content actually is. >>=20 >> Let's not forget that in building an end to end content service the = CDN is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. >>=20 >> The decision as to which version/copy/representation to offer and = allow to be delivered to a given device/user is implemented outside of = the CDN (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content). >>=20 >> Ben >>=20 >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: >>=20 >>> Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. >>> If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. >>>=20 >>> Here the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content adaptation. >>> In last month, I have contacted the Authors of this document and = taken some email exchanges with Grant and Philip (BT). >>> I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. >>> Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. >>>=20 >>> If you have any more question or comments, pls share in this thread. >>> Thanks. >>> Zhipeng >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Scott Wainner [mailto:swainner@cisco.com]=20 >>> Sent: Friday, September 30, 2011 8:02 AM >>> To: cdni@ietf.org >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>=20 >>> Section 2.3 Nomadic Users >>> This description falls under the category of Geographic Extension = yet=20 >>> the third paragraph states the case where a different device is used = in=20 >>> the same CDN coverage area. The intent of this use case needs to be=20= >>> clarified. Perhaps the use case is trying to address the scenario = where=20 >>> a Nomadic User-A with an agreement allowing access to content from = CSP-A=20 >>> via uCDN moves to a dCDN in a different region. The dCDN is allowed = to=20 >>> distribute the content of CSP-A to User-A; however, not other users = in=20 >>> the region of the dCDN are allowed to retrieve the content unless = they=20 >>> too have such an agreement. >>>=20 >>> Section 5.1.3 Content Encoding Restrictions >>> Need to clarify if we're talking about the restrictions on the=20 >>> delivery of specific content or the restrictions on the ability of a = CDN=20 >>> to deliver specific content. I certainly understand the case where = a=20 >>> CSP will restrict the distribution of content to a "managed path" if=20= >>> such content is HD while allowing the content distribution via an=20 >>> un-managed path if such content is SD (same could apply to = encryption=20 >>> methods, delivery methods, etc.). On the contrary, the dCDN may = have=20 >>> its own restrictions of blocking the distribution of HD content = while=20 >>> allowing the distribution of SD content. >>>=20 >>> o first bullet makes sense if the dCDN can perform a subset of=20 >>> encapsulations for a reference set of media (e.g. HLS, HSS, but not = DASH) >>> o second bullet makes sense where the dCDN doesn't want to offer = high=20 >>> bit-rate variants of the media >>> o third bullet make sense if the policy addresses QoE but I don't=20 >>> think subscriber rights/authorizations apply. >>>=20 >>> Section 10 Security Considerations >>>=20 >>> Aside from the security considerations WITHIN the uCDN and dCDN, I = think=20 >>> we can describe this in four contexts: >>>=20 >>> a. The relationship between the CSP and the uCDN (the principle = contract=20 >>> arrangement for distribution)=09 >>> b. The relationship between the uCDN and dCDN (the transitive trust=20= >>> relationship that extends the contract defined in (a) above) >>> c. The relationship between the User and dCDN (the recognition of = right=20 >>> to download predicated on (b) above) >>> d. The relationship between the User and CSP (the contract = authorizing=20 >>> the user access to the content) >>>=20 >>> The user is not interested in the a-b nor the b-c relationship. The = user=20 >>> is only interested in the transparency and interoperability of the=20= >>> security relationship between d-b or d-c to the point that the=20 >>> authorization granted in d-a is viable when the delivery is = initiated=20 >>> via either d-b or d-c. As an example, the uCDN might use URL = appended=20 >>> tokens for authentication while dCDN might use URL appended hashes. = The=20 >>> user doesn't want to know about the distinct methods, but = transparency=20 >>> is only afforded if the methods are interoperable clearly defined = when=20 >>> the delegation for content delivery is executed. Clearly, the = choice of=20 >>> authentication method is determined by the respective CDN's. >>>=20 >>> Scott >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From kevin.ma@azukisystems.com Wed Oct 12 16:41:29 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E2421F8B98 for ; Wed, 12 Oct 2011 16:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ak4194ka9Rly for ; Wed, 12 Oct 2011 16:41:28 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3E81F21F8500 for ; Wed, 12 Oct 2011 16:41:28 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 83F528BE0A1; Wed, 12 Oct 2011 19:41:27 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 93A168BE0F8; Wed, 12 Oct 2011 19:41:26 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Wed, 12 Oct 2011 19:41:03 -0400 From: Kevin J Ma To: Ben Niven-Jenkins Date: Wed, 12 Oct 2011 19:41:24 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyIPP+o09+GKyYcRQyFRZpa4NvXNwA39NdA Message-ID: <291CC3F9E50E7641901A54E85D0977C651B5151F30@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B5151768@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C651B515180A@MAILR002.mail.lan> <2C91B87E-BEA1-4D34-9896-558DF0F39101@niven-jenkins.co.uk> In-Reply-To: <2C91B87E-BEA1-4D34-9896-558DF0F39101@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: ZhouZhipeng , "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 23:41:29 -0000 Hi Ben, While I agree that authentication is also a good feature, it is not exactly the same as preventing delegation. Having users never ask for content-A over CDN-B, is not the same as preventing content-A from ever being delivered over CDN-B, where a less than lawful user could still possibly get to content-A via CDN-B. There will always be prevention measures, but the ability to blacklist/whitelist dCDNs for specific content seems like a reasonable thing to do, and should be achievable via metadata? thanx. -- Kevin J. Ma > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Tuesday, October 11, 2011 12:30 PM > To: Kevin J Ma > Cc: Brandenburg, R. (Ray) van; cdni@ietf.org; ZhouZhipeng > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Kevin, >=20 > On 11 Oct 2011, at 17:04, Kevin J Ma wrote: >=20 > > Ben, > > > > The restriction is not that content "absolutely must be delivered by a > > different CDN", the restriction is that content should only be > delivered > > in specific formats to specific end users, and certain users may only > > get access through specific CDNs. This can be (and is) enforced today > by > > using different CDNs (e.g., separate CDNs for TV vs mobile). Once > those > > two CDNs combine, it removes an inherent physical restriction, which > some > > CPs may have been relying on. >=20 > The services I am aware of enforce such restrictions by requiring content > delivery to be authenticated (e.g. through use of a token/cookie) and the > Content Provider's portal only handing out the necessary tokens/cookies > for certain content to the appropriate users/clients. By doing so there i= s > no need to rely on some inherent physical separation of different CDNs in > order to be able to enforce the COntent Provider's policy and therefore n= o > need to rely on the implicit physical separation of different CDNs. >=20 >=20 > After all the entire purpose of a CDN is to offer multiple independent > services off a single physical platform, so if a CDN is not capable of > meeting the separation needs of the services offered by a single Content > Provider, I'd suggest they have some pretty big issues that would mean it > is unlikely that a Content Provider would want to use them at all for any > kind of delivery. >=20 > Ben >=20 >=20 >=20 > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > >> Sent: Tuesday, October 11, 2011 11:51 AM > >> To: Kevin J Ma > >> Cc: Brandenburg, R. (Ray) van; cdni@ietf.org; ZhouZhipeng > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> Kevin, > >> > >> On 11 Oct 2011, at 15:48, Kevin J Ma wrote: > >> > >>> Hi Ben, > >>> > >>> I do not disagree with the statements made below, however, I think > >>> that there is one point that is missing: in a non-interconnected > >>> world, CPs can (and do) put different representations into different > >>> CDNs, knowing that representation-A will not be accessible via CDN-B. > >>> It is true that the CDN did not make any decision, the CP did, > however, > >>> the enforcement is based on the fact that those CDNs will not share > >>> with each other and are physically separated. With CDNI, if the uCDN > >>> has access to all representations but the CP needs to enforce that > >>> specific dCDNs only have access to subsets of representations (due to > >>> content licensing restrictions), enforcing that probably requires > >>> metadata to describe those delivery restrictions? > >> > >> I'd like to understand these requirements better as I am aware of > Content > >> Providers that choose to use different CDNs for different > representations > >> based on business policy and I think that can be solved at the busines= s > >> agreement level in the same way as dealing with what delivery protocol= s > or > >> delivery footprint the Content Provider requires. > >> > >> I am aware of licensing agreements that restrict what geographies > content > >> can be delivered from and what geographies content can be delivered to= . > >> Such requirements are already handled by the metadata proposal I co- > >> authored through the use of SelectionACL & DeliveryACLs. > >> > >> However, I've not heard of a licensing agreement that mandated that > some > >> representations of a piece of content absolutely must be delivered by = a > >> different CDN to other representations of the same content. > >> > >> Can you expand on the motivation and drivers behind that requirement? > >> > >> Thanks > >> Ben > >> > >>> > >>> thanx. > >>> > >>> -- Kevin J. Ma > >>> > >>>> -----Original Message----- > >>>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > >>>> Ben Niven-Jenkins > >>>> Sent: Tuesday, October 11, 2011 9:26 AM > >>>> To: Brandenburg, R. (Ray) van > >>>> Cc: cdni@ietf.org; ZhouZhipeng > >>>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >>>> > >>>> > >>>> On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: > >>>> > >>>>> Hi all, > >>>>> > >>>>> While I am neutral to the Content Adaptation discussion, I would > like > >> to > >>>> make sure that we do not throw out all features related to multiple > >>>> representations, which would happen if we would just remove section > >> 5.1.3 > >>>> completely as suggested by Ben. > >>>> > >>>> I'm not sure how you draw that conclusion as removing section 5.1.3 > >> does > >>>> not throw out the ability to support multiple representations IMO. > >>>> > >>>>> The previous version of the use case document (betrand-02) had a > >>>> slightly different wording in section 2.4 than is now being used in > >>>> section 5.1 of the new WG-version. I think the concept of > resolution- > >>>> based constraints, that was included in betrand-02, should remain in > >> some > >>>> form. While it is not the CDNs responsibility/decision whether to > allow > >> a > >>>> specific representation to be delivered, I think a use case in which > >> some > >>>> dCDN only offers a subset of the representations available on the > uCDN > >> is > >>>> quite valid (such as in a dedicated mobile CDN). > >>>> > >>>> I don't believe that dCDNs will only offer a subset of > representations > >> in > >>>> the way you describe. They may only deliver to a subset of users (an= d > >>>> maybe by implication a subset of possible devices) for example as a > >>>> consequence of them being a dedicated mobile CDN (as opposed to an > >> active > >>>> decision they make). > >>>> > >>>> Let's look at how a content service is deployed. A Content Provider > has > >>>> some content (let's say a video) that the Content Provider may > produce > >> in > >>>> a variety of representations (codecs, bit rates, resolutions, etc.). > >> They > >>>> may do that encoding themselves or outsource it (although that's not > >>>> relevant to the point I'm making). > >>>> > >>>> A User will connect to the Content Provider's "portal" (which may be > a > >> web > >>>> portal, an application, an EPG etc.). The Content Provider (through > >> their > >>>> portal) will offer the User the content in one or more of the > available > >>>> representations (e.g. by device type but how that decision is made i= s > >>>> purely up to the Content Provider). The User selects a representatio= n > >> and > >>>> the Content Provider offloads the delivery of that representation to > >> the > >>>> CDN (e.g. by returning the appropriate URI for that representation > >> within > >>>> the CDN to the User's client). The User then connects to the CDN and > >>>> requests the representation they have selected (from the choice of > >>>> representations offered to them by the Content Provider). > >>>> > >>>> At its essence a CDN maps incoming URIs (from User's clients) to > >> specific > >>>> content files on an upstream source (e.g. on-net storage or a Conten= t > >>>> Provider's Origin server) it has no explicit knowledge of what actua= l > >>>> content that specific URI maps to or that it is one of X possible > >>>> representations of the same content. > >>>> > >>>> At no point has the CDN been involved in the selection or restrictio= n > >> of > >>>> the representations offered to or delivered to the User. In a CDNI > >>>> scenario things are no different. A uCDN may select a dCDN based on > >> some > >>>> capability (e.g. what Users it can deliver to, what delivery > protocols > >> it > >>>> can support) but I do not think that the specific representation of > the > >>>> content will enter into the equation beyond those constraints. > >>>> > >>>> For example, the dCDN is not going to say "I can only deliver > >>>> representations with resolutions below AxB" and the uCDN often will > not > >>>> even know what the resolution or a particular representation is. > >>>> > >>>> What might happen is that a User on a particular network (or using a > >>>> particular client/device) connects to the Content Provider's portal > and > >> is > >>>> only offered a subset of the possible representations tailored (by > the > >>>> Content Provider's policy implemented in the Content Provider's > portal) > >>>> based on that User's Network/Client/Device. A dCDN may subsequently > be > >>>> selected that can serve that Network/Client/Service and that dCDN ma= y > >> only > >>>> end up delivering to its Users a subset of all the possible > >>>> representations the Content Provider has produced. But that is a > >>>> consequence of the Network/Clients/Devices the dCDN is capable of > >> serving, > >>>> not an explicit decision made by the dCDN and communicated to the > uCDN > >> for > >>>> that specific Content Provider's service. > >>>> > >>>> Ben > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> CDNi mailing list > >>>> CDNi@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/cdni > > From kevin.ma@azukisystems.com Wed Oct 12 16:41:42 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0047521F8BA6 for ; Wed, 12 Oct 2011 16:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaATw4xUk0md for ; Wed, 12 Oct 2011 16:41:40 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4808A21F8BA2 for ; Wed, 12 Oct 2011 16:41:40 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E01D3416F8E; Wed, 12 Oct 2011 19:41:38 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6DA35416DC2; Wed, 12 Oct 2011 19:41:37 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Wed, 12 Oct 2011 19:41:19 -0400 From: Kevin J Ma To: Ben Niven-Jenkins , ZhouZhipeng Date: Wed, 12 Oct 2011 19:41:35 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyJAjnND+G3vQOORzC4OLjUbr0NnQAG1jgQ Message-ID: <291CC3F9E50E7641901A54E85D0977C651B5151F31@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> In-Reply-To: <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 23:41:42 -0000 Hi all, Just wanted to get back to the point that Phil raised earlier: > did we ever decide whether the Use cases doc is restricted to > "initial" scenarios, or whether it's all-encompassing, ie covering > "future" scenarios as well? Are we saying that only "initial" scenarios should be documented? Many of the "future" scenarios seem as though opaque metadata would be sufficient? If so, does defining optional metadata significantly increase our workload? e.g.: Given two pieces of metadata: "format" and "allow transform", are they sufficient to support a content transformation use case? The latter can by default prevent transformation, and the former provides the information necessary to do transformation, assuming transformation is allowed? Beyond that, CDNI should be indifferent, and the dCDN is either empowered to optimize or not, as determined by the content provider who set the metadata? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > Sent: Wednesday, October 12, 2011 1:13 PM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > Hello Ben, > > The UE may select the content format on the CP web. After that the user > only desires to get his selected content. > > But how the content is transferred to the client is not worried by the > user. > > The CP may create a special format as required by the user and ask the > CDN to deliver to user. > > While CP may give a HD format content to uCDN and the dCDN may then > transform to the format as the user select. > > Lots of things may be possible to do and CDN providers offer many > additional services on top of the "core" service of content delivery. > However, our objective (based on my interpretation of the CDNI charter) i= s > to focus on what is necessary to interconnect CDNs to deliver content fro= m > a CSP to an End User that is targeted and deployable within a short time > frame (18-24 months). > > Content transformation/adaptation is not an essential requirement in orde= r > to achieve that aim (we can deliver content from CSPs to End Users via > multiple CDNs without needing or requiring any CDN supports content > adaptation). > > In my opinion we have enough work to do already without trying to expand > the scope of our work to include additional requirements that do not help > us address our core objectives as laid out in the CDNI charter. > > > In this case, it is nothing related to how the user select formats on C= P > website. > > So, it is the CP and user to decide the content format not the CDN(your > assert is not correct and seems you take that assert as your base for the > discussion). > > > > As for "the core CDN functionality offered by CDNs today", I have ever > raised an email before that your company's webpage has claimed supporting > media transformation and multi-screen service. > > Perhaps, I like asking you list some features that you feel are the cor= e > functionalities by existing main stream CDNs. Thus we may compare and tak= e > deep look. > > I think the core functionality maps pretty well to the CDNI interfaces, > namely: Request Routing, Metadata configuration, log production and > control plus content acquisition and content delivery. > > > I guess many people have the experience/knowledge of content related > service. The user and CP only care whether the CDN providers may satisfy > their requirement while not care the internal process. Just as GSM/PSTN > interconnection, the user only care successful interconnection while not > care how the voice is transformed in process. > > > > Besides, I like raise a case: > > Given currently BBC recruits CDN providers that may support 10 media > formats. > > One candidate is your company, another is CDN-X. The users are located > in France. > > So both your company and CDN-X should connect a France CDN provider(CDN= - > Y). > > If your company's solution is to send 10 streams of different format of > one content to CDN-Y; > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may > conduct some adaptation. > > Comparing these two solutions, for your company and CDN-X, absolutely > the cost of CDN-X is much lower. > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while > in solution-2, it should only receive 1 stream but need to take > transformation to output 10 streams. > > > > Which solution is more competitive. it is Solution 1, right. Remember > the price from BBC is same to both your company and CDN-X or BBC would > select one CDN provider with the lower price. > > If a CDN provider may not get the contract from CP, how it may say it i= s > not a core functionality. > > What you are describing is a possible optimization that a particular CDN > may wish to implement not a core functionality required to enable content > delivery between interconnected CDNs. I can think of many optimizations > that a CDN could implement to differentiate their service but the interna= l > workings of an individual CDN are out of scope of our charter. > > So to repeat my position for a final time: Content adaptation is not a > core function required to enable content delivery between interconnected > CDNs and therefore given the workload we already have to specify solution= s > that do address the core functionality required to interconnect CDNs I do > not think we should be trying to add more work into that workload as it > will only distract us from achieving our goal of producing deployable > solutions within the timeframe we are being told by operators they needs > solutions within. > > Ben > > > So, if we all realize that currently the media type is rich, the CDN > providers should survive in the existing ecosystem and support the media > types as required by the market. > > > > Back to the case of GSM/G.711, it just when concerning the > interconnection, the transformation should at once be solved. Otherwise > the interconnection may not be operated. > > > > Br, > > Zhipeng > > > > > > > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Wednesday, October 12, 2011 12:19 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > >> Ben and Philip, > >> I like to respond your concern in this one email: > >> > >> Ben, > >> I feel what we are now discussing is what is the "core" function of > CDN. > >> As you say, CDN is used to deliver content. That is absolutely correct > that the delivery capability is the core requirement for CDN system. > >> While CDN is used to provide the content delivery service. > >> What means service. It should include "time" "location" and "media > type", etc. These features are all the core feature for a service. > >> If we only concern "delivering one data block", I am not sure whether > the issues such as "logging" "geographic constraint" are the core of CDN. > >> > >> For "without explicit knowledge of what that content actually is ", I > am not sure whether the wording is accurate since generally a CDN may > claim it support different medias. > >> By this opportunity, I like to share a use case: a call from a GSM > phone to a PSTN telephone, the voice stream should be transformed from GS= M > voice to G.711. > >> For the user, he does not need to know what type of data has been > transferred, but the operator has done some work to interconnect two > systems, right. > >> I like to know whether you may accept that my use case is similar to > this case above. > > > > I don't think your use case is similar to the analogy of mobile network= s > being interconnected to PSTN networks. In the case of content delivery th= e > negotiation is done between the User/Client and the Content Provider and > the CDN is just used to execute/perform the delivery that has been > negotiated. The CDN is not involved in the decision making of what > representations the Content Provider decides to offer to the User/Client > or in what representations the User/Client decides to request. > > > >> As for you said selecting media by the "portal", you may see the way " > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > delivers one media stream to dCDN and dCDN takes some adaptation to > support multiple media types". > > > > Now what you're talking about is an optimisation, not a core function > required to actually deliver the content (and report, bill, etc. for that > delivery). > > > > My position is that we should focus on how to enable the interconnectio= n > of the core CDN functionality offered by CDNs today (which is also my > interpretation of the scope of the CDNI working group as expressed in its > charter) because doing so is a significant piece of work in itself. Let's > not start trying to add in additional functionality beyond what the > majority of CDNs support today as that will just delay us getting usable > specifications into the market in a timely fashion IMO. > > > > Ben > > > >> A good question is "security" since I have done six years on the DRM > and like to promote the DRM all around the world:) > >> If the content is needed to be protected, generally you may know all > the systems should be granted by the content owner. > >> Here I also like to clarify that not only the media itself but the > information related to service itself (such as the geographic constraint) > should be protected also. > >> So, trust is not a problem for the media. > >> > >> Philip, > >> Thank you that you feel Content Adaption is an issue for "Requirements= " > but I do not know why it is not for Use case. > >> I like to clarify to U that it is important for you operator since it > may save investment if the system may support different services. > >> For us vendor, we are happy operator may install a system for the > mobile service and another system for the FBB service. > >> But the reality is all operators ask us to provide a system that may > support different service systems. > >> > >> Frankly, Ben and Philip, I remember I have explained somewhere that to > implement this is rather simple . > >> At least the Use case and Requirement are informational to be referred > in future work. So I do really feel you may accept it. > >> Of course I like to respond your more concern and comments. > >> Thanks. > >> Zhipeng > >> > >> > >> > >> -----Original Message----- > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >> Sent: Monday, October 10, 2011 11:22 PM > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > >> Cc: cdni@ietf.org > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> Ben, Zhipeng, all, > >> > >> I think that Content Adaptation is more an issue for the Requirements > doc than for the Use cases draft. > >> > >> The key question is whether we want the CDNI interfaces to be able to > cope with a scenario where (say) HD/SD conversion is done in the dCDN & t= o > signal about this. > >> > >> I think that coping with this scenario is a second order requirement, > ie we should not worry about it in the initial standards-track work. I > don't know, did we ever decide whether the Use cases doc is restricted to > "initial" scenarios, or whether it's all-encompassing, ie covering > "future" scenarios as well? > >> > >> Scott, > >> Reading some of your examples, they seem to be valid even if content > adaptation (HD/SD) is out of scope. > >> - a dCDN might for some reason be unwilling to distribute HD? > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > >> But these sorts of examples seem to be static policy things (to do wit= h > the capabilities & preferences of the CDNs & CSP), rather than metadata > associated with a particular piece of content. In the discussion so far, = I > think negotiation about static policy stuff is rather out of scope(?) > >> > >> On security considerations, an interesting question is whether trust i= s > transitive. Don't think it need be - just because CSP trusts uCDN, and > uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. > However, i suspect this can get arbitrarily complex - so one possibility > is to say that we will only handle cases where the trust is transitive. > >> > >> Best wishes > >> phil > >> > >> > >> Philip Eardley > >> Research and Technology Strategy > >> > >> This email contains BT information, which may be privileged or > confidential. It's meant only for the individual(s) or entity named above= . > If you're not the intended recipient, note that disclosing, copying, > distributing or using this information is prohibited. If you've received > this email in error, please let me know immediately on the email address > above. Thank you. We monitor our email system, and may record your emails= . > >> British Telecommunications plc > >> Registered office: 81 Newgate Street London EC1A 7AJ > >> Registered in England no: 1800000 > >> > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > Ben Niven-Jenkins > >> Sent: 10 October 2011 12:04 > >> To: ZhouZhipeng > >> Cc: cdni@ietf.org > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> Colleagues, > >> > >> IMO Section 5.1.3 should be removed from the Use Cases draft. Content > Adaptation (i.e. taking in a content item in one format and transforming > it to another format or representation) is not a "core" function of a CDN > which typically delivers the content that is requested without explicit > knowledge of what that content actually is. > >> > >> Let's not forget that in building an end to end content service the CD= N > is only one component and is the component tasked with executing the > delivery of a specific representation (version/copy/format etc.) of the > selected content not the component tasked with deciding (or applying > policy) on which version/copy/representation of content should be > delivered. > >> > >> The decision as to which version/copy/representation to offer and allo= w > to be delivered to a given device/user is implemented outside of the CDN > (e.g. by the "portal" where the user first makes their content selection > prior to the CDN becoming involved in the delivery of the selected > content). > >> > >> Ben > >> > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > >> > >>> Following Scott's comments on section 5.1.3, I feel Scott's > description on the use case of HD and SD is not exactly correct. > >>> If one movie has two formats of HD and SD, then we have two content > with different identifier. In DRM scope, the basic unit is a content copy= . > >>> > >>> Here the first bullet "a subset of encodings deliverable to specific > devices," has listed the case of content adaptation. > >>> In last month, I have contacted the Authors of this document and take= n > some email exchanges with Grant and Philip (BT). > >>> I have shown BT with some information that I know in this case and > area to explain the content flexibility is currently a basic requirement > for CDN service and related negotiation is needed in the CDN > interconnection. > >>> Meanwhile, I should also invite you in this group raising your > comments or questions on this case since I hope my use case may be > incorporated in the use case draft. > >>> > >>> If you have any more question or comments, pls share in this thread. > >>> Thanks. > >>> Zhipeng > >>> > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Scott Wainner [mailto:swainner@cisco.com] > >>> Sent: Friday, September 30, 2011 8:02 AM > >>> To: cdni@ietf.org > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >>> > >>> Section 2.3 Nomadic Users > >>> This description falls under the category of Geographic Extension yet > >>> the third paragraph states the case where a different device is used > in > >>> the same CDN coverage area. The intent of this use case needs to be > >>> clarified. Perhaps the use case is trying to address the scenario > where > >>> a Nomadic User-A with an agreement allowing access to content from > CSP-A > >>> via uCDN moves to a dCDN in a different region. The dCDN is allowed > to > >>> distribute the content of CSP-A to User-A; however, not other users i= n > >>> the region of the dCDN are allowed to retrieve the content unless the= y > >>> too have such an agreement. > >>> > >>> Section 5.1.3 Content Encoding Restrictions > >>> Need to clarify if we're talking about the restrictions on the > >>> delivery of specific content or the restrictions on the ability of a > CDN > >>> to deliver specific content. I certainly understand the case where a > >>> CSP will restrict the distribution of content to a "managed path" if > >>> such content is HD while allowing the content distribution via an > >>> un-managed path if such content is SD (same could apply to encryption > >>> methods, delivery methods, etc.). On the contrary, the dCDN may have > >>> its own restrictions of blocking the distribution of HD content while > >>> allowing the distribution of SD content. > >>> > >>> o first bullet makes sense if the dCDN can perform a subset of > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) > >>> o second bullet makes sense where the dCDN doesn't want to offer high > >>> bit-rate variants of the media > >>> o third bullet make sense if the policy addresses QoE but I don't > >>> think subscriber rights/authorizations apply. > >>> > >>> Section 10 Security Considerations > >>> > >>> Aside from the security considerations WITHIN the uCDN and dCDN, I > think > >>> we can describe this in four contexts: > >>> > >>> a. The relationship between the CSP and the uCDN (the principle > contract > >>> arrangement for distribution) > >>> b. The relationship between the uCDN and dCDN (the transitive trust > >>> relationship that extends the contract defined in (a) above) > >>> c. The relationship between the User and dCDN (the recognition of > right > >>> to download predicated on (b) above) > >>> d. The relationship between the User and CSP (the contract authorizin= g > >>> the user access to the content) > >>> > >>> The user is not interested in the a-b nor the b-c relationship. The > user > >>> is only interested in the transparency and interoperability of the > >>> security relationship between d-b or d-c to the point that the > >>> authorization granted in d-a is viable when the delivery is initiated > >>> via either d-b or d-c. As an example, the uCDN might use URL appende= d > >>> tokens for authentication while dCDN might use URL appended hashes. > The > >>> user doesn't want to know about the distinct methods, but transparenc= y > >>> is only afforded if the methods are interoperable clearly defined whe= n > >>> the delegation for content delivery is executed. Clearly, the choice > of > >>> authentication method is determined by the respective CDN's. > >>> > >>> Scott > >>> > >>> _______________________________________________ > >>> CDNi mailing list > >>> CDNi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cdni > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From zhouzhipeng@huawei.com Wed Oct 12 18:51:28 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C47C121F8A97 for ; Wed, 12 Oct 2011 18:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igjS3h3pnBvF for ; Wed, 12 Oct 2011 18:51:27 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C475321F8A7B for ; Wed, 12 Oct 2011 18:51:26 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ008KIEHOGN@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 09:51:24 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ005KDEHI5A@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 09:51:24 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ98179; Thu, 13 Oct 2011 09:51:23 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 09:51:16 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 09:51:10 +0800 Date: Thu, 13 Oct 2011 01:51:10 +0000 From: ZhouZhipeng In-reply-to: <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> X-Originating-IP: [10.138.73.38] To: Ben Niven-Jenkins Message-id: <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 01:51:28 -0000 Ben, I respect your personal standpoint while seems you are only repeating your personal conclusion without new reason/evidence. In my case, I have explained the uCDN may deliver 10 streams to the dCDN. But in our reality, we should consider whether it is a proper solution that will be used by the market. If the standard may not support the market requirements, it is just the problem for its deployment. Meanwhile in my feeling you have not carefully thought about how it will bring to the standard. I have repeated it is very simple in fact and I do not know whether you have any special concern that will make you feel it would not be able to be done within 18-24 months. Ben, as I repeat, if you have any question, I like respond via reflector or to you individually. Thanks. Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Thursday, October 13, 2011 1:13 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > Hello Ben, > The UE may select the content format on the CP web. After that the user only desires to get his selected content. > But how the content is transferred to the client is not worried by the user. > The CP may create a special format as required by the user and ask the CDN to deliver to user. > While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select. Lots of things may be possible to do and CDN providers offer many additional services on top of the "core" service of content delivery. However, our objective (based on my interpretation of the CDNI charter) is to focus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and deployable within a short time frame (18-24 months). Content transformation/adaptation is not an essential requirement in order to achieve that aim (we can deliver content from CSPs to End Users via multiple CDNs without needing or requiring any CDN supports content adaptation). In my opinion we have enough work to do already without trying to expand the scope of our work to include additional requirements that do not help us address our core objectives as laid out in the CDNI charter. > In this case, it is nothing related to how the user select formats on CP website. > So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion). > > As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service. > Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look. I think the core functionality maps pretty well to the CDNI interfaces, namely: Request Routing, Metadata configuration, log production and control plus content acquisition and content delivery. > I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process. > > Besides, I like raise a case: > Given currently BBC recruits CDN providers that may support 10 media formats. > One candidate is your company, another is CDN-X. The users are located in France. > So both your company and CDN-X should connect a France CDN provider(CDN-Y). > If your company's solution is to send 10 streams of different format of one content to CDN-Y; > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation. > Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower. > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams. > > Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price. > If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. What you are describing is a possible optimization that a particular CDN may wish to implement not a core functionality required to enable content delivery between interconnected CDNs. I can think of many optimizations that a CDN could implement to differentiate their service but the internal workings of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core function required to enable content delivery between interconnected CDNs and therefore given the workload we already have to specify solutions that do address the core functionality required to interconnect CDNs I do not think we should be trying to add more work into that workload as it will only distract us from achieving our goal of producing deployable solutions within the timeframe we are being told by operators they needs solutions within. Ben > So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market. > > Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated. > > Br, > Zhipeng > > > > > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Wednesday, October 12, 2011 12:19 AM > To: ZhouZhipeng > Cc: philip.eardley@bt.com; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > >> Ben and Philip, >> I like to respond your concern in this one email: >> >> Ben, >> I feel what we are now discussing is what is the "core" function of CDN. >> As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system. >> While CDN is used to provide the content delivery service. >> What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service. >> If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN. >> >> For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias. >> By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711. >> For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right. >> I like to know whether you may accept that my use case is similar to this case above. > > I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request. > >> As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types". > > Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery). > > My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO. > > Ben > >> A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) >> If the content is needed to be protected, generally you may know all the systems should be granted by the content owner. >> Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also. >> So, trust is not a problem for the media. >> >> Philip, >> Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case. >> I like to clarify to U that it is important for you operator since it may save investment if the system may support different services. >> For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service. >> But the reality is all operators ask us to provide a system that may support different service systems. >> >> Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple . >> At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it. >> Of course I like to respond your more concern and comments. >> Thanks. >> Zhipeng >> >> >> >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: Monday, October 10, 2011 11:22 PM >> To: ben@niven-jenkins.co.uk; ZhouZhipeng >> Cc: cdni@ietf.org >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> >> Ben, Zhipeng, all, >> >> I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft. >> >> The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this. >> >> I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well? >> >> Scott, >> Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. >> - a dCDN might for some reason be unwilling to distribute HD? >> - a CSP might want to make sure the dCDN can use HLS encapsulation? >> But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) >> >> On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive. >> >> Best wishes >> phil >> >> >> Philip Eardley >> Research and Technology Strategy >> >> This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. >> British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ >> Registered in England no: 1800000 >> >> >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins >> Sent: 10 October 2011 12:04 >> To: ZhouZhipeng >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> >> Colleagues, >> >> IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is. >> >> Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered. >> >> The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content). >> >> Ben >> >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: >> >>> Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. >>> If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. >>> >>> Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. >>> In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). >>> I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. >>> Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. >>> >>> If you have any more question or comments, pls share in this thread. >>> Thanks. >>> Zhipeng >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Scott Wainner [mailto:swainner@cisco.com] >>> Sent: Friday, September 30, 2011 8:02 AM >>> To: cdni@ietf.org >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>> >>> Section 2.3 Nomadic Users >>> This description falls under the category of Geographic Extension yet >>> the third paragraph states the case where a different device is used in >>> the same CDN coverage area. The intent of this use case needs to be >>> clarified. Perhaps the use case is trying to address the scenario where >>> a Nomadic User-A with an agreement allowing access to content from CSP-A >>> via uCDN moves to a dCDN in a different region. The dCDN is allowed to >>> distribute the content of CSP-A to User-A; however, not other users in >>> the region of the dCDN are allowed to retrieve the content unless they >>> too have such an agreement. >>> >>> Section 5.1.3 Content Encoding Restrictions >>> Need to clarify if we're talking about the restrictions on the >>> delivery of specific content or the restrictions on the ability of a CDN >>> to deliver specific content. I certainly understand the case where a >>> CSP will restrict the distribution of content to a "managed path" if >>> such content is HD while allowing the content distribution via an >>> un-managed path if such content is SD (same could apply to encryption >>> methods, delivery methods, etc.). On the contrary, the dCDN may have >>> its own restrictions of blocking the distribution of HD content while >>> allowing the distribution of SD content. >>> >>> o first bullet makes sense if the dCDN can perform a subset of >>> encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) >>> o second bullet makes sense where the dCDN doesn't want to offer high >>> bit-rate variants of the media >>> o third bullet make sense if the policy addresses QoE but I don't >>> think subscriber rights/authorizations apply. >>> >>> Section 10 Security Considerations >>> >>> Aside from the security considerations WITHIN the uCDN and dCDN, I think >>> we can describe this in four contexts: >>> >>> a. The relationship between the CSP and the uCDN (the principle contract >>> arrangement for distribution) >>> b. The relationship between the uCDN and dCDN (the transitive trust >>> relationship that extends the contract defined in (a) above) >>> c. The relationship between the User and dCDN (the recognition of right >>> to download predicated on (b) above) >>> d. The relationship between the User and CSP (the contract authorizing >>> the user access to the content) >>> >>> The user is not interested in the a-b nor the b-c relationship. The user >>> is only interested in the transparency and interoperability of the >>> security relationship between d-b or d-c to the point that the >>> authorization granted in d-a is viable when the delivery is initiated >>> via either d-b or d-c. As an example, the uCDN might use URL appended >>> tokens for authentication while dCDN might use URL appended hashes. The >>> user doesn't want to know about the distinct methods, but transparency >>> is only afforded if the methods are interoperable clearly defined when >>> the delegation for content delivery is executed. Clearly, the choice of >>> authentication method is determined by the respective CDN's. >>> >>> Scott >>> >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > From kevin.ma@azukisystems.com Wed Oct 12 19:44:52 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9DC21F8B68 for ; Wed, 12 Oct 2011 19:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlmvJq+vcjl7 for ; Wed, 12 Oct 2011 19:44:51 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id ADF8E21F8B4F for ; Wed, 12 Oct 2011 19:44:50 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5745A79E7D2; Wed, 12 Oct 2011 22:44:50 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E937879E6A8; Wed, 12 Oct 2011 22:44:48 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Wed, 12 Oct 2011 22:44:49 -0400 From: Kevin J Ma To: ZhouZhipeng , Ben Niven-Jenkins Date: Wed, 12 Oct 2011 22:44:46 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QA== Message-ID: <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 02:44:52 -0000 Zhipeng, One practical concern to consider with the use case of downloading one (as opposed to ten) streams is that premium content providers generally are very concerned with quality control and are unlikely to trust dCDNs to modify the content, and most likely, the content will be encrypted? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > ZhouZhipeng > Sent: Wednesday, October 12, 2011 9:51 PM > To: Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Ben, > I respect your personal standpoint while seems you are only repeating you= r > personal conclusion without new reason/evidence. > In my case, I have explained the uCDN may deliver 10 streams to the dCDN. > But in our reality, we should consider whether it is a proper solution > that will be used by the market. > If the standard may not support the market requirements, it is just the > problem for its deployment. > > Meanwhile in my feeling you have not carefully thought about how it will > bring to the standard. I have repeated it is very simple in fact and I do > not know whether you have any special concern that will make you feel it > would not be able to be done within 18-24 months. > Ben, as I repeat, if you have any question, I like respond via reflector > or to you individually. > Thanks. > Zhipeng > > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Thursday, October 13, 2011 1:13 AM > To: ZhouZhipeng > Cc: philip.eardley@bt.com; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > Hello Ben, > > The UE may select the content format on the CP web. After that the user > only desires to get his selected content. > > But how the content is transferred to the client is not worried by the > user. > > The CP may create a special format as required by the user and ask the > CDN to deliver to user. > > While CP may give a HD format content to uCDN and the dCDN may then > transform to the format as the user select. > > Lots of things may be possible to do and CDN providers offer many > additional services on top of the "core" service of content delivery. > However, our objective (based on my interpretation of the CDNI charter) i= s > to focus on what is necessary to interconnect CDNs to deliver content fro= m > a CSP to an End User that is targeted and deployable within a short time > frame (18-24 months). > > Content transformation/adaptation is not an essential requirement in orde= r > to achieve that aim (we can deliver content from CSPs to End Users via > multiple CDNs without needing or requiring any CDN supports content > adaptation). > > In my opinion we have enough work to do already without trying to expand > the scope of our work to include additional requirements that do not help > us address our core objectives as laid out in the CDNI charter. > > > In this case, it is nothing related to how the user select formats on C= P > website. > > So, it is the CP and user to decide the content format not the CDN(your > assert is not correct and seems you take that assert as your base for the > discussion). > > > > As for "the core CDN functionality offered by CDNs today", I have ever > raised an email before that your company's webpage has claimed supporting > media transformation and multi-screen service. > > Perhaps, I like asking you list some features that you feel are the cor= e > functionalities by existing main stream CDNs. Thus we may compare and tak= e > deep look. > > I think the core functionality maps pretty well to the CDNI interfaces, > namely: Request Routing, Metadata configuration, log production and > control plus content acquisition and content delivery. > > > I guess many people have the experience/knowledge of content related > service. The user and CP only care whether the CDN providers may satisfy > their requirement while not care the internal process. Just as GSM/PSTN > interconnection, the user only care successful interconnection while not > care how the voice is transformed in process. > > > > Besides, I like raise a case: > > Given currently BBC recruits CDN providers that may support 10 media > formats. > > One candidate is your company, another is CDN-X. The users are located > in France. > > So both your company and CDN-X should connect a France CDN provider(CDN= - > Y). > > If your company's solution is to send 10 streams of different format of > one content to CDN-Y; > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may > conduct some adaptation. > > Comparing these two solutions, for your company and CDN-X, absolutely > the cost of CDN-X is much lower. > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while > in solution-2, it should only receive 1 stream but need to take > transformation to output 10 streams. > > > > Which solution is more competitive. it is Solution 1, right. Remember > the price from BBC is same to both your company and CDN-X or BBC would > select one CDN provider with the lower price. > > If a CDN provider may not get the contract from CP, how it may say it i= s > not a core functionality. > > What you are describing is a possible optimization that a particular CDN > may wish to implement not a core functionality required to enable content > delivery between interconnected CDNs. I can think of many optimizations > that a CDN could implement to differentiate their service but the interna= l > workings of an individual CDN are out of scope of our charter. > > So to repeat my position for a final time: Content adaptation is not a > core function required to enable content delivery between interconnected > CDNs and therefore given the workload we already have to specify solution= s > that do address the core functionality required to interconnect CDNs I do > not think we should be trying to add more work into that workload as it > will only distract us from achieving our goal of producing deployable > solutions within the timeframe we are being told by operators they needs > solutions within. > > Ben > > > So, if we all realize that currently the media type is rich, the CDN > providers should survive in the existing ecosystem and support the media > types as required by the market. > > > > Back to the case of GSM/G.711, it just when concerning the > interconnection, the transformation should at once be solved. Otherwise > the interconnection may not be operated. > > > > Br, > > Zhipeng > > > > > > > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Wednesday, October 12, 2011 12:19 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > >> Ben and Philip, > >> I like to respond your concern in this one email: > >> > >> Ben, > >> I feel what we are now discussing is what is the "core" function of > CDN. > >> As you say, CDN is used to deliver content. That is absolutely correct > that the delivery capability is the core requirement for CDN system. > >> While CDN is used to provide the content delivery service. > >> What means service. It should include "time" "location" and "media > type", etc. These features are all the core feature for a service. > >> If we only concern "delivering one data block", I am not sure whether > the issues such as "logging" "geographic constraint" are the core of CDN. > >> > >> For "without explicit knowledge of what that content actually is ", I > am not sure whether the wording is accurate since generally a CDN may > claim it support different medias. > >> By this opportunity, I like to share a use case: a call from a GSM > phone to a PSTN telephone, the voice stream should be transformed from GS= M > voice to G.711. > >> For the user, he does not need to know what type of data has been > transferred, but the operator has done some work to interconnect two > systems, right. > >> I like to know whether you may accept that my use case is similar to > this case above. > > > > I don't think your use case is similar to the analogy of mobile network= s > being interconnected to PSTN networks. In the case of content delivery th= e > negotiation is done between the User/Client and the Content Provider and > the CDN is just used to execute/perform the delivery that has been > negotiated. The CDN is not involved in the decision making of what > representations the Content Provider decides to offer to the User/Client > or in what representations the User/Client decides to request. > > > >> As for you said selecting media by the "portal", you may see the way " > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > delivers one media stream to dCDN and dCDN takes some adaptation to > support multiple media types". > > > > Now what you're talking about is an optimisation, not a core function > required to actually deliver the content (and report, bill, etc. for that > delivery). > > > > My position is that we should focus on how to enable the interconnectio= n > of the core CDN functionality offered by CDNs today (which is also my > interpretation of the scope of the CDNI working group as expressed in its > charter) because doing so is a significant piece of work in itself. Let's > not start trying to add in additional functionality beyond what the > majority of CDNs support today as that will just delay us getting usable > specifications into the market in a timely fashion IMO. > > > > Ben > > > >> A good question is "security" since I have done six years on the DRM > and like to promote the DRM all around the world:) > >> If the content is needed to be protected, generally you may know all > the systems should be granted by the content owner. > >> Here I also like to clarify that not only the media itself but the > information related to service itself (such as the geographic constraint) > should be protected also. > >> So, trust is not a problem for the media. > >> > >> Philip, > >> Thank you that you feel Content Adaption is an issue for "Requirements= " > but I do not know why it is not for Use case. > >> I like to clarify to U that it is important for you operator since it > may save investment if the system may support different services. > >> For us vendor, we are happy operator may install a system for the > mobile service and another system for the FBB service. > >> But the reality is all operators ask us to provide a system that may > support different service systems. > >> > >> Frankly, Ben and Philip, I remember I have explained somewhere that to > implement this is rather simple . > >> At least the Use case and Requirement are informational to be referred > in future work. So I do really feel you may accept it. > >> Of course I like to respond your more concern and comments. > >> Thanks. > >> Zhipeng > >> > >> > >> > >> -----Original Message----- > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >> Sent: Monday, October 10, 2011 11:22 PM > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > >> Cc: cdni@ietf.org > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> Ben, Zhipeng, all, > >> > >> I think that Content Adaptation is more an issue for the Requirements > doc than for the Use cases draft. > >> > >> The key question is whether we want the CDNI interfaces to be able to > cope with a scenario where (say) HD/SD conversion is done in the dCDN & t= o > signal about this. > >> > >> I think that coping with this scenario is a second order requirement, > ie we should not worry about it in the initial standards-track work. I > don't know, did we ever decide whether the Use cases doc is restricted to > "initial" scenarios, or whether it's all-encompassing, ie covering > "future" scenarios as well? > >> > >> Scott, > >> Reading some of your examples, they seem to be valid even if content > adaptation (HD/SD) is out of scope. > >> - a dCDN might for some reason be unwilling to distribute HD? > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > >> But these sorts of examples seem to be static policy things (to do wit= h > the capabilities & preferences of the CDNs & CSP), rather than metadata > associated with a particular piece of content. In the discussion so far, = I > think negotiation about static policy stuff is rather out of scope(?) > >> > >> On security considerations, an interesting question is whether trust i= s > transitive. Don't think it need be - just because CSP trusts uCDN, and > uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. > However, i suspect this can get arbitrarily complex - so one possibility > is to say that we will only handle cases where the trust is transitive. > >> > >> Best wishes > >> phil > >> > >> > >> Philip Eardley > >> Research and Technology Strategy > >> > >> This email contains BT information, which may be privileged or > confidential. It's meant only for the individual(s) or entity named above= . > If you're not the intended recipient, note that disclosing, copying, > distributing or using this information is prohibited. If you've received > this email in error, please let me know immediately on the email address > above. Thank you. We monitor our email system, and may record your emails= . > >> British Telecommunications plc > >> Registered office: 81 Newgate Street London EC1A 7AJ > >> Registered in England no: 1800000 > >> > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > Ben Niven-Jenkins > >> Sent: 10 October 2011 12:04 > >> To: ZhouZhipeng > >> Cc: cdni@ietf.org > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> Colleagues, > >> > >> IMO Section 5.1.3 should be removed from the Use Cases draft. Content > Adaptation (i.e. taking in a content item in one format and transforming > it to another format or representation) is not a "core" function of a CDN > which typically delivers the content that is requested without explicit > knowledge of what that content actually is. > >> > >> Let's not forget that in building an end to end content service the CD= N > is only one component and is the component tasked with executing the > delivery of a specific representation (version/copy/format etc.) of the > selected content not the component tasked with deciding (or applying > policy) on which version/copy/representation of content should be > delivered. > >> > >> The decision as to which version/copy/representation to offer and allo= w > to be delivered to a given device/user is implemented outside of the CDN > (e.g. by the "portal" where the user first makes their content selection > prior to the CDN becoming involved in the delivery of the selected > content). > >> > >> Ben > >> > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > >> > >>> Following Scott's comments on section 5.1.3, I feel Scott's > description on the use case of HD and SD is not exactly correct. > >>> If one movie has two formats of HD and SD, then we have two content > with different identifier. In DRM scope, the basic unit is a content copy= . > >>> > >>> Here the first bullet "a subset of encodings deliverable to specific > devices," has listed the case of content adaptation. > >>> In last month, I have contacted the Authors of this document and take= n > some email exchanges with Grant and Philip (BT). > >>> I have shown BT with some information that I know in this case and > area to explain the content flexibility is currently a basic requirement > for CDN service and related negotiation is needed in the CDN > interconnection. > >>> Meanwhile, I should also invite you in this group raising your > comments or questions on this case since I hope my use case may be > incorporated in the use case draft. > >>> > >>> If you have any more question or comments, pls share in this thread. > >>> Thanks. > >>> Zhipeng > >>> > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Scott Wainner [mailto:swainner@cisco.com] > >>> Sent: Friday, September 30, 2011 8:02 AM > >>> To: cdni@ietf.org > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >>> > >>> Section 2.3 Nomadic Users > >>> This description falls under the category of Geographic Extension yet > >>> the third paragraph states the case where a different device is used > in > >>> the same CDN coverage area. The intent of this use case needs to be > >>> clarified. Perhaps the use case is trying to address the scenario > where > >>> a Nomadic User-A with an agreement allowing access to content from > CSP-A > >>> via uCDN moves to a dCDN in a different region. The dCDN is allowed > to > >>> distribute the content of CSP-A to User-A; however, not other users i= n > >>> the region of the dCDN are allowed to retrieve the content unless the= y > >>> too have such an agreement. > >>> > >>> Section 5.1.3 Content Encoding Restrictions > >>> Need to clarify if we're talking about the restrictions on the > >>> delivery of specific content or the restrictions on the ability of a > CDN > >>> to deliver specific content. I certainly understand the case where a > >>> CSP will restrict the distribution of content to a "managed path" if > >>> such content is HD while allowing the content distribution via an > >>> un-managed path if such content is SD (same could apply to encryption > >>> methods, delivery methods, etc.). On the contrary, the dCDN may have > >>> its own restrictions of blocking the distribution of HD content while > >>> allowing the distribution of SD content. > >>> > >>> o first bullet makes sense if the dCDN can perform a subset of > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) > >>> o second bullet makes sense where the dCDN doesn't want to offer high > >>> bit-rate variants of the media > >>> o third bullet make sense if the policy addresses QoE but I don't > >>> think subscriber rights/authorizations apply. > >>> > >>> Section 10 Security Considerations > >>> > >>> Aside from the security considerations WITHIN the uCDN and dCDN, I > think > >>> we can describe this in four contexts: > >>> > >>> a. The relationship between the CSP and the uCDN (the principle > contract > >>> arrangement for distribution) > >>> b. The relationship between the uCDN and dCDN (the transitive trust > >>> relationship that extends the contract defined in (a) above) > >>> c. The relationship between the User and dCDN (the recognition of > right > >>> to download predicated on (b) above) > >>> d. The relationship between the User and CSP (the contract authorizin= g > >>> the user access to the content) > >>> > >>> The user is not interested in the a-b nor the b-c relationship. The > user > >>> is only interested in the transparency and interoperability of the > >>> security relationship between d-b or d-c to the point that the > >>> authorization granted in d-a is viable when the delivery is initiated > >>> via either d-b or d-c. As an example, the uCDN might use URL appende= d > >>> tokens for authentication while dCDN might use URL appended hashes. > The > >>> user doesn't want to know about the distinct methods, but transparenc= y > >>> is only afforded if the methods are interoperable clearly defined whe= n > >>> the delegation for content delivery is executed. Clearly, the choice > of > >>> authentication method is determined by the respective CDN's. > >>> > >>> Scott > >>> > >>> _______________________________________________ > >>> CDNi mailing list > >>> CDNi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cdni > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From zhouzhipeng@huawei.com Wed Oct 12 20:26:20 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70B221F85AE for ; Wed, 12 Oct 2011 20:26:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.519 X-Spam-Level: X-Spam-Status: No, score=-5.519 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeUzLScmauzx for ; Wed, 12 Oct 2011 20:26:19 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9D45821F85B5 for ; Wed, 12 Oct 2011 20:26:18 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ00E76IV3RN@szxga04-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 11:25:52 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ004DPIV2Q7@szxga04-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 11:25:51 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEF01241; Thu, 13 Oct 2011 11:25:21 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 11:25:15 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 11:25:11 +0800 Date: Thu, 13 Oct 2011 03:25:09 +0000 From: ZhouZhipeng In-reply-to: <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> X-Originating-IP: [10.138.73.38] To: Kevin J Ma , Ben Niven-Jenkins Message-id: <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QIAAAyQA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 03:26:21 -0000 Kevin, As we ever discussed in previous email that the content format in fact is decided by the CP. Only under the permission, the HD video may be transformed to the mobile video. i.e. if the CP support both IPTV and mobile video service, then it may require the CDN to support multiple video formats. The multi-screen service means the content source is from the same CP while the target devices/clients include different groups. All content businesses are under the permission of the content owner. For the content protection, I like talk a little more in this email for reference: Given there are two areas: London and Paris. And in these two areas, each has deployed the DRM. Generally each DRM implementation is independent. If the content is delivered from London to Paris, absolutely the whole process should be granted by the CP. For the DRM standard, it mainly concern the security on the terminal and the interface between the SP/Client. You may see that the servers that are granted by the CP is secure and we do not need to worry that secure server would be the hacker. Hence, if the content is delivered from one server to another server( these servers are the equipments granted by CP that may handle and encrypt the content), the content is safe. Whether decrypt/re-encrypt or just deliver unencrypted content between these two servers are secure. Also, we may see such security issue for content distribution is a general scenario that is not related to whether taking content adaptation. Thanks. Zhipeng -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Thursday, October 13, 2011 10:45 AM To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, One practical concern to consider with the use case of downloading one (as opposed to ten) streams is that premium content providers generally are very concerned with quality control and are unlikely to trust dCDNs to modify the content, and most likely, the content will be encrypted? thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > ZhouZhipeng > Sent: Wednesday, October 12, 2011 9:51 PM > To: Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Ben, > I respect your personal standpoint while seems you are only repeating your > personal conclusion without new reason/evidence. > In my case, I have explained the uCDN may deliver 10 streams to the dCDN. > But in our reality, we should consider whether it is a proper solution > that will be used by the market. > If the standard may not support the market requirements, it is just the > problem for its deployment. > > Meanwhile in my feeling you have not carefully thought about how it will > bring to the standard. I have repeated it is very simple in fact and I do > not know whether you have any special concern that will make you feel it > would not be able to be done within 18-24 months. > Ben, as I repeat, if you have any question, I like respond via reflector > or to you individually. > Thanks. > Zhipeng > > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Thursday, October 13, 2011 1:13 AM > To: ZhouZhipeng > Cc: philip.eardley@bt.com; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > Hello Ben, > > The UE may select the content format on the CP web. After that the user > only desires to get his selected content. > > But how the content is transferred to the client is not worried by the > user. > > The CP may create a special format as required by the user and ask the > CDN to deliver to user. > > While CP may give a HD format content to uCDN and the dCDN may then > transform to the format as the user select. > > Lots of things may be possible to do and CDN providers offer many > additional services on top of the "core" service of content delivery. > However, our objective (based on my interpretation of the CDNI charter) is > to focus on what is necessary to interconnect CDNs to deliver content from > a CSP to an End User that is targeted and deployable within a short time > frame (18-24 months). > > Content transformation/adaptation is not an essential requirement in order > to achieve that aim (we can deliver content from CSPs to End Users via > multiple CDNs without needing or requiring any CDN supports content > adaptation). > > In my opinion we have enough work to do already without trying to expand > the scope of our work to include additional requirements that do not help > us address our core objectives as laid out in the CDNI charter. > > > In this case, it is nothing related to how the user select formats on CP > website. > > So, it is the CP and user to decide the content format not the CDN(your > assert is not correct and seems you take that assert as your base for the > discussion). > > > > As for "the core CDN functionality offered by CDNs today", I have ever > raised an email before that your company's webpage has claimed supporting > media transformation and multi-screen service. > > Perhaps, I like asking you list some features that you feel are the core > functionalities by existing main stream CDNs. Thus we may compare and take > deep look. > > I think the core functionality maps pretty well to the CDNI interfaces, > namely: Request Routing, Metadata configuration, log production and > control plus content acquisition and content delivery. > > > I guess many people have the experience/knowledge of content related > service. The user and CP only care whether the CDN providers may satisfy > their requirement while not care the internal process. Just as GSM/PSTN > interconnection, the user only care successful interconnection while not > care how the voice is transformed in process. > > > > Besides, I like raise a case: > > Given currently BBC recruits CDN providers that may support 10 media > formats. > > One candidate is your company, another is CDN-X. The users are located > in France. > > So both your company and CDN-X should connect a France CDN provider(CDN- > Y). > > If your company's solution is to send 10 streams of different format of > one content to CDN-Y; > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may > conduct some adaptation. > > Comparing these two solutions, for your company and CDN-X, absolutely > the cost of CDN-X is much lower. > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while > in solution-2, it should only receive 1 stream but need to take > transformation to output 10 streams. > > > > Which solution is more competitive. it is Solution 1, right. Remember > the price from BBC is same to both your company and CDN-X or BBC would > select one CDN provider with the lower price. > > If a CDN provider may not get the contract from CP, how it may say it is > not a core functionality. > > What you are describing is a possible optimization that a particular CDN > may wish to implement not a core functionality required to enable content > delivery between interconnected CDNs. I can think of many optimizations > that a CDN could implement to differentiate their service but the internal > workings of an individual CDN are out of scope of our charter. > > So to repeat my position for a final time: Content adaptation is not a > core function required to enable content delivery between interconnected > CDNs and therefore given the workload we already have to specify solutions > that do address the core functionality required to interconnect CDNs I do > not think we should be trying to add more work into that workload as it > will only distract us from achieving our goal of producing deployable > solutions within the timeframe we are being told by operators they needs > solutions within. > > Ben > > > So, if we all realize that currently the media type is rich, the CDN > providers should survive in the existing ecosystem and support the media > types as required by the market. > > > > Back to the case of GSM/G.711, it just when concerning the > interconnection, the transformation should at once be solved. Otherwise > the interconnection may not be operated. > > > > Br, > > Zhipeng > > > > > > > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Wednesday, October 12, 2011 12:19 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > >> Ben and Philip, > >> I like to respond your concern in this one email: > >> > >> Ben, > >> I feel what we are now discussing is what is the "core" function of > CDN. > >> As you say, CDN is used to deliver content. That is absolutely correct > that the delivery capability is the core requirement for CDN system. > >> While CDN is used to provide the content delivery service. > >> What means service. It should include "time" "location" and "media > type", etc. These features are all the core feature for a service. > >> If we only concern "delivering one data block", I am not sure whether > the issues such as "logging" "geographic constraint" are the core of CDN. > >> > >> For "without explicit knowledge of what that content actually is ", I > am not sure whether the wording is accurate since generally a CDN may > claim it support different medias. > >> By this opportunity, I like to share a use case: a call from a GSM > phone to a PSTN telephone, the voice stream should be transformed from GSM > voice to G.711. > >> For the user, he does not need to know what type of data has been > transferred, but the operator has done some work to interconnect two > systems, right. > >> I like to know whether you may accept that my use case is similar to > this case above. > > > > I don't think your use case is similar to the analogy of mobile networks > being interconnected to PSTN networks. In the case of content delivery the > negotiation is done between the User/Client and the Content Provider and > the CDN is just used to execute/perform the delivery that has been > negotiated. The CDN is not involved in the decision making of what > representations the Content Provider decides to offer to the User/Client > or in what representations the User/Client decides to request. > > > >> As for you said selecting media by the "portal", you may see the way " > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > delivers one media stream to dCDN and dCDN takes some adaptation to > support multiple media types". > > > > Now what you're talking about is an optimisation, not a core function > required to actually deliver the content (and report, bill, etc. for that > delivery). > > > > My position is that we should focus on how to enable the interconnection > of the core CDN functionality offered by CDNs today (which is also my > interpretation of the scope of the CDNI working group as expressed in its > charter) because doing so is a significant piece of work in itself. Let's > not start trying to add in additional functionality beyond what the > majority of CDNs support today as that will just delay us getting usable > specifications into the market in a timely fashion IMO. > > > > Ben > > > >> A good question is "security" since I have done six years on the DRM > and like to promote the DRM all around the world:) > >> If the content is needed to be protected, generally you may know all > the systems should be granted by the content owner. > >> Here I also like to clarify that not only the media itself but the > information related to service itself (such as the geographic constraint) > should be protected also. > >> So, trust is not a problem for the media. > >> > >> Philip, > >> Thank you that you feel Content Adaption is an issue for "Requirements" > but I do not know why it is not for Use case. > >> I like to clarify to U that it is important for you operator since it > may save investment if the system may support different services. > >> For us vendor, we are happy operator may install a system for the > mobile service and another system for the FBB service. > >> But the reality is all operators ask us to provide a system that may > support different service systems. > >> > >> Frankly, Ben and Philip, I remember I have explained somewhere that to > implement this is rather simple . > >> At least the Use case and Requirement are informational to be referred > in future work. So I do really feel you may accept it. > >> Of course I like to respond your more concern and comments. > >> Thanks. > >> Zhipeng > >> > >> > >> > >> -----Original Message----- > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > >> Sent: Monday, October 10, 2011 11:22 PM > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > >> Cc: cdni@ietf.org > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> Ben, Zhipeng, all, > >> > >> I think that Content Adaptation is more an issue for the Requirements > doc than for the Use cases draft. > >> > >> The key question is whether we want the CDNI interfaces to be able to > cope with a scenario where (say) HD/SD conversion is done in the dCDN & to > signal about this. > >> > >> I think that coping with this scenario is a second order requirement, > ie we should not worry about it in the initial standards-track work. I > don't know, did we ever decide whether the Use cases doc is restricted to > "initial" scenarios, or whether it's all-encompassing, ie covering > "future" scenarios as well? > >> > >> Scott, > >> Reading some of your examples, they seem to be valid even if content > adaptation (HD/SD) is out of scope. > >> - a dCDN might for some reason be unwilling to distribute HD? > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > >> But these sorts of examples seem to be static policy things (to do with > the capabilities & preferences of the CDNs & CSP), rather than metadata > associated with a particular piece of content. In the discussion so far, I > think negotiation about static policy stuff is rather out of scope(?) > >> > >> On security considerations, an interesting question is whether trust is > transitive. Don't think it need be - just because CSP trusts uCDN, and > uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. > However, i suspect this can get arbitrarily complex - so one possibility > is to say that we will only handle cases where the trust is transitive. > >> > >> Best wishes > >> phil > >> > >> > >> Philip Eardley > >> Research and Technology Strategy > >> > >> This email contains BT information, which may be privileged or > confidential. It's meant only for the individual(s) or entity named above. > If you're not the intended recipient, note that disclosing, copying, > distributing or using this information is prohibited. If you've received > this email in error, please let me know immediately on the email address > above. Thank you. We monitor our email system, and may record your emails. > >> British Telecommunications plc > >> Registered office: 81 Newgate Street London EC1A 7AJ > >> Registered in England no: 1800000 > >> > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > >> Sent: 10 October 2011 12:04 > >> To: ZhouZhipeng > >> Cc: cdni@ietf.org > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> Colleagues, > >> > >> IMO Section 5.1.3 should be removed from the Use Cases draft. Content > Adaptation (i.e. taking in a content item in one format and transforming > it to another format or representation) is not a "core" function of a CDN > which typically delivers the content that is requested without explicit > knowledge of what that content actually is. > >> > >> Let's not forget that in building an end to end content service the CDN > is only one component and is the component tasked with executing the > delivery of a specific representation (version/copy/format etc.) of the > selected content not the component tasked with deciding (or applying > policy) on which version/copy/representation of content should be > delivered. > >> > >> The decision as to which version/copy/representation to offer and allow > to be delivered to a given device/user is implemented outside of the CDN > (e.g. by the "portal" where the user first makes their content selection > prior to the CDN becoming involved in the delivery of the selected > content). > >> > >> Ben > >> > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > >> > >>> Following Scott's comments on section 5.1.3, I feel Scott's > description on the use case of HD and SD is not exactly correct. > >>> If one movie has two formats of HD and SD, then we have two content > with different identifier. In DRM scope, the basic unit is a content copy. > >>> > >>> Here the first bullet "a subset of encodings deliverable to specific > devices," has listed the case of content adaptation. > >>> In last month, I have contacted the Authors of this document and taken > some email exchanges with Grant and Philip (BT). > >>> I have shown BT with some information that I know in this case and > area to explain the content flexibility is currently a basic requirement > for CDN service and related negotiation is needed in the CDN > interconnection. > >>> Meanwhile, I should also invite you in this group raising your > comments or questions on this case since I hope my use case may be > incorporated in the use case draft. > >>> > >>> If you have any more question or comments, pls share in this thread. > >>> Thanks. > >>> Zhipeng > >>> > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Scott Wainner [mailto:swainner@cisco.com] > >>> Sent: Friday, September 30, 2011 8:02 AM > >>> To: cdni@ietf.org > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >>> > >>> Section 2.3 Nomadic Users > >>> This description falls under the category of Geographic Extension yet > >>> the third paragraph states the case where a different device is used > in > >>> the same CDN coverage area. The intent of this use case needs to be > >>> clarified. Perhaps the use case is trying to address the scenario > where > >>> a Nomadic User-A with an agreement allowing access to content from > CSP-A > >>> via uCDN moves to a dCDN in a different region. The dCDN is allowed > to > >>> distribute the content of CSP-A to User-A; however, not other users in > >>> the region of the dCDN are allowed to retrieve the content unless they > >>> too have such an agreement. > >>> > >>> Section 5.1.3 Content Encoding Restrictions > >>> Need to clarify if we're talking about the restrictions on the > >>> delivery of specific content or the restrictions on the ability of a > CDN > >>> to deliver specific content. I certainly understand the case where a > >>> CSP will restrict the distribution of content to a "managed path" if > >>> such content is HD while allowing the content distribution via an > >>> un-managed path if such content is SD (same could apply to encryption > >>> methods, delivery methods, etc.). On the contrary, the dCDN may have > >>> its own restrictions of blocking the distribution of HD content while > >>> allowing the distribution of SD content. > >>> > >>> o first bullet makes sense if the dCDN can perform a subset of > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) > >>> o second bullet makes sense where the dCDN doesn't want to offer high > >>> bit-rate variants of the media > >>> o third bullet make sense if the policy addresses QoE but I don't > >>> think subscriber rights/authorizations apply. > >>> > >>> Section 10 Security Considerations > >>> > >>> Aside from the security considerations WITHIN the uCDN and dCDN, I > think > >>> we can describe this in four contexts: > >>> > >>> a. The relationship between the CSP and the uCDN (the principle > contract > >>> arrangement for distribution) > >>> b. The relationship between the uCDN and dCDN (the transitive trust > >>> relationship that extends the contract defined in (a) above) > >>> c. The relationship between the User and dCDN (the recognition of > right > >>> to download predicated on (b) above) > >>> d. The relationship between the User and CSP (the contract authorizing > >>> the user access to the content) > >>> > >>> The user is not interested in the a-b nor the b-c relationship. The > user > >>> is only interested in the transparency and interoperability of the > >>> security relationship between d-b or d-c to the point that the > >>> authorization granted in d-a is viable when the delivery is initiated > >>> via either d-b or d-c. As an example, the uCDN might use URL appended > >>> tokens for authentication while dCDN might use URL appended hashes. > The > >>> user doesn't want to know about the distinct methods, but transparency > >>> is only afforded if the methods are interoperable clearly defined when > >>> the delegation for content delivery is executed. Clearly, the choice > of > >>> authentication method is determined by the respective CDN's. > >>> > >>> Scott > >>> > >>> _______________________________________________ > >>> CDNi mailing list > >>> CDNi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cdni > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Wed Oct 12 21:01:43 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CD921F86A4 for ; Wed, 12 Oct 2011 21:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.828 X-Spam-Level: X-Spam-Status: No, score=-1.828 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arKLQm1Q-64w for ; Wed, 12 Oct 2011 21:01:41 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 53C3F21F85DB for ; Wed, 12 Oct 2011 21:01:41 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id EB9BB5539B3; Thu, 13 Oct 2011 00:01:40 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 3D53D553419; Thu, 13 Oct 2011 00:01:39 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Thu, 13 Oct 2011 00:01:32 -0400 From: Kevin J Ma To: ZhouZhipeng , Ben Niven-Jenkins Date: Thu, 13 Oct 2011 00:01:36 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QIAAAyQAgAAMvHA= Message-ID: <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 04:01:43 -0000 Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact is > decided by the CP. > Only under the permission, the HD video may be transformed to the mobile > video. i.e. if the CP support both IPTV and mobile video service, then it > may require the CDN to support multiple video formats. The multi-screen > service means the content source is from the same CP while the target > devices/clients include different groups. All content businesses are unde= r > the permission of the content owner. > > For the content protection, I like talk a little more in this email for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal and > the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and we > do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and encryp= t > the content), the content is safe. Whether decrypt/re-encrypt or just > deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a genera= l > scenario that is not related to whether taking content adaptation. > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper solution > > that will be used by the market. > > If the standard may not support the market requirements, it is just the > > problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it wil= l > > bring to the standard. I have repeated it is very simple in fact and I > do > > not know whether you have any special concern that will make you feel i= t > > would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via reflecto= r > > or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by th= e > > user. > > > The CP may create a special format as required by the user and ask th= e > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI charter) > is > > to focus on what is necessary to interconnect CDNs to deliver content > from > > a CSP to an End User that is targeted and deployable within a short tim= e > > frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users via > > multiple CDNs without needing or requiring any CDN supports content > > adaptation). > > > > In my opinion we have enough work to do already without trying to expan= d > > the scope of our work to include additional requirements that do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have eve= r > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are the > core > > functionalities by existing main stream CDNs. Thus we may compare and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content related > > service. The user and CP only care whether the CDN providers may satisf= y > > their requirement while not care the internal process. Just as GSM/PSTN > > interconnection, the user only care successful interconnection while no= t > > care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 media > > formats. > > > One candidate is your company, another is CDN-X. The users are locate= d > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; whil= e > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. Remember > > the price from BBC is same to both your company and CDN-X or BBC would > > select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular CD= N > > may wish to implement not a core functionality required to enable > content > > delivery between interconnected CDNs. I can think of many optimizations > > that a CDN could implement to differentiate their service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not a > > core function required to enable content delivery between interconnecte= d > > CDNs and therefore given the workload we already have to specify > solutions > > that do address the core functionality required to interconnect CDNs I > do > > not think we should be trying to add more work into that workload as it > > will only distract us from achieving our goal of producing deployable > > solutions within the timeframe we are being told by operators they need= s > > solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the CDN > > providers should survive in the existing ecosystem and support the medi= a > > types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. Otherwise > > the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure whethe= r > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is ", = I > > am not sure whether the wording is accurate since generally a CDN may > > claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a GSM > > phone to a PSTN telephone, the voice stream should be transformed from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content delivery > the > > negotiation is done between the User/Client and the Content Provider an= d > > the CDN is just used to execute/perform the delivery that has been > > negotiated. The CDN is not involved in the decision making of what > > representations the Content Provider decides to offer to the User/Clien= t > > or in what representations the User/Client decides to request. > > > > > >> As for you said selecting media by the "portal", you may see the way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also my > > interpretation of the scope of the CDNI working group as expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting usabl= e > > specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator since i= t > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the Requirement= s > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be able t= o > > cope with a scenario where (say) HD/SD conversion is done in the dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order requirement= , > > ie we should not worry about it in the initial standards-track work. I > > don't know, did we ever decide whether the Use cases doc is restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to do > with > > the capabilities & preferences of the CDNs & CSP), rather than metadata > > associated with a particular piece of content. In the discussion so far= , > I > > think negotiation about static policy stuff is rather out of scope(?) > > >> > > >> On security considerations, an interesting question is whether trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, and > > uCDN trusts dCDN doesn't mean that the CSP automatically trusts the > dCDN. > > However, i suspect this can get arbitrarily complex - so one possibilit= y > > is to say that we will only handle cases where the trust is transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've receive= d > > this email in error, please let me know immediately on the email addres= s > > above. Thank you. We monitor our email system, and may record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ > > >> Registered in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. Conten= t > > Adaptation (i.e. taking in a content item in one format and transformin= g > > it to another format or representation) is not a "core" function of a > CDN > > which typically delivers the content that is requested without explicit > > knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of the > > selected content not the component tasked with deciding (or applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the CD= N > > (e.g. by the "portal" where the user first makes their content selectio= n > > prior to the CDN becoming involved in the delivery of the selected > > content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to specifi= c > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case and > > area to explain the content flexibility is currently a basic requiremen= t > > for CDN service and related negotiation is needed in the CDN > > interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread= . > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic Extension > yet > > >>> the third paragraph states the case where a different device is use= d > > in > > >>> the same CDN coverage area. The intent of this use case needs to b= e > > >>> clarified. Perhaps the use case is trying to address the scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is allowe= d > > to > > >>> distribute the content of CSP-A to User-A; however, not other users > in > > >>> the region of the dCDN are allowed to retrieve the content unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions > > >>> Need to clarify if we're talking about the restrictions on the > > >>> delivery of specific content or the restrictions on the ability of = a > > CDN > > >>> to deliver specific content. I certainly understand the case where > a > > >>> CSP will restrict the distribution of content to a "managed path" i= f > > >>> such content is HD while allowing the content distribution via an > > >>> un-managed path if such content is SD (same could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I don't > > >>> think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive trust > > >>> relationship that extends the contract defined in (a) above) > > >>> c. The relationship between the User and dCDN (the recognition of > > right > > >>> to download predicated on (b) above) > > >>> d. The relationship between the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. The > > user > > >>> is only interested in the transparency and interoperability of the > > >>> security relationship between d-b or d-c to the point that the > > >>> authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From zhouzhipeng@huawei.com Wed Oct 12 22:27:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACEC21F8AF9 for ; Wed, 12 Oct 2011 22:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.499 X-Spam-Level: X-Spam-Status: No, score=-5.499 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oOn0t8xOuWix for ; Wed, 12 Oct 2011 22:27:56 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id C9F1B21F8AF7 for ; Wed, 12 Oct 2011 22:27:55 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ00HVFOGVN2@szxga03-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 13:26:56 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSZ0096JOGVAG@szxga03-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 13:26:55 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEK10726; Thu, 13 Oct 2011 13:26:55 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 13:26:51 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 13:26:46 +0800 Date: Thu, 13 Oct 2011 05:26:44 +0000 From: ZhouZhipeng In-reply-to: <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> X-Originating-IP: [10.138.73.38] To: Kevin J Ma , Ben Niven-Jenkins Message-id: <260A32EFD5C9EB47AD504929D005DF6245AFEE@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QIAAAyQAgAAMvHCAAAz2kA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 05:27:58 -0000 Kevin, For the content distribution scenario, I like share the real case of Olypic games. The NBC sells to CCTV the copy right of Olypic game content including all kinds of media channel within China Mainland. CCTV may use the content in its own TV system meanwhile it resell the copy right to specific channel including MTV and internet video channels. You may see in this business, the original content has been transformed for different target consumers and each channel has its own DRM solutions(Cable TV uses CA, others use OMA DRM,etc.) As for the content quality, as I know for example the IPTV, the USA content producer only provides the HD format to the IPTV operator, but the IPTV operator may provide both HD and SD channel. The content encryption/transcoding/delivery are all done by iptv operator while the CP should has grant that. The CP only provide the source content while the equipments are all belonged to the operators. CDN is a channel while it is a business channel. Even the content is not encrypted, the CDN would not attack the content. For example the content with advertisement, the CDN would not replace the original advertisement for its own advertisement. Otherwise the CDN may not continue its own business. In fact your question is to analyze what job/role is done by CP and operators. I check that azuki platform includes the DRM capabilities. Of course I like to know your more information on this issue. Thanks. Zhipeng -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Thursday, October 13, 2011 12:02 PM To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact is > decided by the CP. > Only under the permission, the HD video may be transformed to the mobile > video. i.e. if the CP support both IPTV and mobile video service, then it > may require the CDN to support multiple video formats. The multi-screen > service means the content source is from the same CP while the target > devices/clients include different groups. All content businesses are under > the permission of the content owner. > > For the content protection, I like talk a little more in this email for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal and > the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and we > do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and encrypt > the content), the content is safe. Whether decrypt/re-encrypt or just > deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a general > scenario that is not related to whether taking content adaptation. > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper solution > > that will be used by the market. > > If the standard may not support the market requirements, it is just the > > problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it will > > bring to the standard. I have repeated it is very simple in fact and I > do > > not know whether you have any special concern that will make you feel it > > would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via reflector > > or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by the > > user. > > > The CP may create a special format as required by the user and ask the > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI charter) > is > > to focus on what is necessary to interconnect CDNs to deliver content > from > > a CSP to an End User that is targeted and deployable within a short time > > frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users via > > multiple CDNs without needing or requiring any CDN supports content > > adaptation). > > > > In my opinion we have enough work to do already without trying to expand > > the scope of our work to include additional requirements that do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have ever > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are the > core > > functionalities by existing main stream CDNs. Thus we may compare and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content related > > service. The user and CP only care whether the CDN providers may satisfy > > their requirement while not care the internal process. Just as GSM/PSTN > > interconnection, the user only care successful interconnection while not > > care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 media > > formats. > > > One candidate is your company, another is CDN-X. The users are located > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. Remember > > the price from BBC is same to both your company and CDN-X or BBC would > > select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular CDN > > may wish to implement not a core functionality required to enable > content > > delivery between interconnected CDNs. I can think of many optimizations > > that a CDN could implement to differentiate their service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not a > > core function required to enable content delivery between interconnected > > CDNs and therefore given the workload we already have to specify > solutions > > that do address the core functionality required to interconnect CDNs I > do > > not think we should be trying to add more work into that workload as it > > will only distract us from achieving our goal of producing deployable > > solutions within the timeframe we are being told by operators they needs > > solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the CDN > > providers should survive in the existing ecosystem and support the media > > types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. Otherwise > > the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure whether > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is ", I > > am not sure whether the wording is accurate since generally a CDN may > > claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a GSM > > phone to a PSTN telephone, the voice stream should be transformed from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content delivery > the > > negotiation is done between the User/Client and the Content Provider and > > the CDN is just used to execute/perform the delivery that has been > > negotiated. The CDN is not involved in the decision making of what > > representations the Content Provider decides to offer to the User/Client > > or in what representations the User/Client decides to request. > > > > > >> As for you said selecting media by the "portal", you may see the way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also my > > interpretation of the scope of the CDNI working group as expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting usable > > specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator since it > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the Requirements > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be able to > > cope with a scenario where (say) HD/SD conversion is done in the dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order requirement, > > ie we should not worry about it in the initial standards-track work. I > > don't know, did we ever decide whether the Use cases doc is restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to do > with > > the capabilities & preferences of the CDNs & CSP), rather than metadata > > associated with a particular piece of content. In the discussion so far, > I > > think negotiation about static policy stuff is rather out of scope(?) > > >> > > >> On security considerations, an interesting question is whether trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, and > > uCDN trusts dCDN doesn't mean that the CSP automatically trusts the > dCDN. > > However, i suspect this can get arbitrarily complex - so one possibility > > is to say that we will only handle cases where the trust is transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've received > > this email in error, please let me know immediately on the email address > > above. Thank you. We monitor our email system, and may record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ > > >> Registered in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. Content > > Adaptation (i.e. taking in a content item in one format and transforming > > it to another format or representation) is not a "core" function of a > CDN > > which typically delivers the content that is requested without explicit > > knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of the > > selected content not the component tasked with deciding (or applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the CDN > > (e.g. by the "portal" where the user first makes their content selection > > prior to the CDN becoming involved in the delivery of the selected > > content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to specific > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case and > > area to explain the content flexibility is currently a basic requirement > > for CDN service and related negotiation is needed in the CDN > > interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread. > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic Extension > yet > > >>> the third paragraph states the case where a different device is used > > in > > >>> the same CDN coverage area. The intent of this use case needs to be > > >>> clarified. Perhaps the use case is trying to address the scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is allowed > > to > > >>> distribute the content of CSP-A to User-A; however, not other users > in > > >>> the region of the dCDN are allowed to retrieve the content unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions > > >>> Need to clarify if we're talking about the restrictions on the > > >>> delivery of specific content or the restrictions on the ability of a > > CDN > > >>> to deliver specific content. I certainly understand the case where > a > > >>> CSP will restrict the distribution of content to a "managed path" if > > >>> such content is HD while allowing the content distribution via an > > >>> un-managed path if such content is SD (same could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I don't > > >>> think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive trust > > >>> relationship that extends the contract defined in (a) above) > > >>> c. The relationship between the User and dCDN (the recognition of > > right > > >>> to download predicated on (b) above) > > >>> d. The relationship between the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. The > > user > > >>> is only interested in the transparency and interoperability of the > > >>> security relationship between d-b or d-c to the point that the > > >>> authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From grant.watson@bt.com Thu Oct 13 03:34:18 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5656D21F8BAA for ; Thu, 13 Oct 2011 03:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUT7KEDNTtbS for ; Thu, 13 Oct 2011 03:34:16 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id DF3B621F8B86 for ; Thu, 13 Oct 2011 03:34:15 -0700 (PDT) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 13 Oct 2011 11:34:07 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.13]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Thu, 13 Oct 2011 11:34:07 +0100 From: To: , , Date: Thu, 13 Oct 2011 11:34:05 +0100 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QIAAAyQAgAAMvHCAAGgN4A== Message-ID: <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 10:34:18 -0000 I'd support that perspective. Today CPs, in my experience, sometimes even a= ctively seeks assurances that the content will NOT be modified by the CDN o= r by other downstream processes. So to envisage a CP allowing/wanting that = to happen in a dCDN (that is likely out of their control, perhaps in anothe= r geography and with no quality feedback) feels like a very, very unlikely = scenario. In general the content arrives encrypted and is shipped transpare= ntly, in my experience. Indeed the CPs desire to ship to different devices = / screens etc. is also transparent to the CDN, they're just different objec= ts requested by logic that is out-of-band to the CDN. I know of cases where content is transcoded/modified for mobile access by t= ransparent caching, for example. But TC is not relevant to CDNI. IMHO content adaption/modification/transcoding is not a fundamental issue f= or CDNI. The issues around solving the fundamentals of how to Interconnect = CDN are challenging enough. So I feel we should focus the scope on widely d= eployed use-cases / features and very likely new use-cases that are created= by CDNI. g- -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kev= in J Ma Sent: 13 October 2011 05:02 To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact > is decided by the CP. > Only under the permission, the HD video may be transformed to the > mobile video. i.e. if the CP support both IPTV and mobile video > service, then it may require the CDN to support multiple video > formats. The multi-screen service means the content source is from the > same CP while the target devices/clients include different groups. All > content businesses are under the permission of the content owner. > > For the content protection, I like talk a little more in this email > for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal > and the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and > we do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and > encrypt the content), the content is safe. Whether decrypt/re-encrypt > or just deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a > general scenario that is not related to whether taking content adaptation= . > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only > > repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper > > solution that will be used by the market. > > If the standard may not support the market requirements, it is just > > the problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it > > will bring to the standard. I have repeated it is very simple in > > fact and I > do > > not know whether you have any special concern that will make you > > feel it would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via > > reflector or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by > > > the > > user. > > > The CP may create a special format as required by the user and ask > > > the > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may > > > then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI > > charter) > is > > to focus on what is necessary to interconnect CDNs to deliver > > content > from > > a CSP to an End User that is targeted and deployable within a short > > time frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users > > via multiple CDNs without needing or requiring any CDN supports > > content adaptation). > > > > In my opinion we have enough work to do already without trying to > > expand the scope of our work to include additional requirements that > > do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats > > > on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base > > for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have > > > ever > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are > > > the > core > > functionalities by existing main stream CDNs. Thus we may compare > > and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI > > interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content > > > related > > service. The user and CP only care whether the CDN providers may > > satisfy their requirement while not care the internal process. Just > > as GSM/PSTN interconnection, the user only care successful > > interconnection while not care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 > > > media > > formats. > > > One candidate is your company, another is CDN-X. The users are > > > located > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different > > > format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y > > > may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, > > > absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > > > while > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. > > > Remember > > the price from BBC is same to both your company and CDN-X or BBC > > would select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say > > > it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular > > CDN may wish to implement not a core functionality required to > > enable > content > > delivery between interconnected CDNs. I can think of many > > optimizations that a CDN could implement to differentiate their > > service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not > > a core function required to enable content delivery between > > interconnected CDNs and therefore given the workload we already have > > to specify > solutions > > that do address the core functionality required to interconnect CDNs > > I > do > > not think we should be trying to add more work into that workload as > > it will only distract us from achieving our goal of producing > > deployable solutions within the timeframe we are being told by > > operators they needs solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the > > > CDN > > providers should survive in the existing ecosystem and support the > > media types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. > > Otherwise the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function > > >> of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and > > >> "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure > > >> whether > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is > > >> ", I > > am not sure whether the wording is accurate since generally a CDN > > may claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a > > >> GSM > > phone to a PSTN telephone, the voice stream should be transformed > > from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar > > >> to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content > > delivery > the > > negotiation is done between the User/Client and the Content Provider > > and the CDN is just used to execute/perform the delivery that has > > been negotiated. The CDN is not involved in the decision making of > > what representations the Content Provider decides to offer to the > > User/Client or in what representations the User/Client decides to reque= st. > > > > > >> As for you said selecting media by the "portal", you may see the > > >> way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core > > > function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also > > my interpretation of the scope of the CDNI working group as > > expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting > > usable specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the > > >> DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know > > >> all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but > > >> the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator > > >> since it > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that > > >> may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere > > >> that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the > > >> Requirements > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be > > >> able to > > cope with a scenario where (say) HD/SD conversion is done in the > > dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order > > >> requirement, > > ie we should not worry about it in the initial standards-track work. > > I don't know, did we ever decide whether the Use cases doc is > > restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if > > >> content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to > > >> do > with > > the capabilities & preferences of the CDNs & CSP), rather than > > metadata associated with a particular piece of content. In the > > discussion so far, > I > > think negotiation about static policy stuff is rather out of > > scope(?) > > >> > > >> On security considerations, an interesting question is whether > > >> trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, > > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > > the > dCDN. > > However, i suspect this can get arbitrarily complex - so one > > possibility is to say that we will only handle cases where the trust is= transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > > email address above. Thank you. We monitor our email system, and may > > record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered > > >> in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > > >> Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > > >> Content > > Adaptation (i.e. taking in a content item in one format and > > transforming it to another format or representation) is not a "core" > > function of a > CDN > > which typically delivers the content that is requested without > > explicit knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service > > >> the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of > > the selected content not the component tasked with deciding (or > > applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the > > CDN (e.g. by the "portal" where the user first makes their content > > selection prior to the CDN becoming involved in the delivery of the > > selected content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two > > >>> content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to > > >>> specific > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case > > >>> and > > area to explain the content flexibility is currently a basic > > requirement for CDN service and related negotiation is needed in the > > CDN interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread= . > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic > > >>> Extension > yet > > >>> the third paragraph states the case where a different device is > > >>> used > > in > > >>> the same CDN coverage area. The intent of this use case needs > > >>> to be clarified. Perhaps the use case is trying to address the > > >>> scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content > > >>> from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > > >>> allowed > > to > > >>> distribute the content of CSP-A to User-A; however, not other > > >>> users > in > > >>> the region of the dCDN are allowed to retrieve the content > > >>> unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if > > >>> we're talking about the restrictions on the delivery of specific > > >>> content or the restrictions on the ability of a > > CDN > > >>> to deliver specific content. I certainly understand the case > > >>> where > a > > >>> CSP will restrict the distribution of content to a "managed > > >>> path" if such content is HD while allowing the content > > >>> distribution via an un-managed path if such content is SD (same > > >>> could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but > > >>> not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I > > >>> don't think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, > > >>> I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive > > >>> trust relationship that extends the contract defined in (a) > > >>> above) c. The relationship between the User and dCDN (the > > >>> recognition of > > right > > >>> to download predicated on (b) above) d. The relationship between > > >>> the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. > > >>> The > > user > > >>> is only interested in the transparency and interoperability of > > >>> the security relationship between d-b or d-c to the point that > > >>> the authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly > > >>> defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From hexiaoyan@huawei.com Thu Oct 13 04:29:34 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1FA21F8BEF for ; Thu, 13 Oct 2011 04:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQn11WRbZoyM for ; Thu, 13 Oct 2011 04:29:34 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 60E4321F8B2E for ; Thu, 13 Oct 2011 04:29:34 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT00039E5918C@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 19:29:25 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT000C4G590YK@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 19:29:25 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEF33717; Thu, 13 Oct 2011 19:29:24 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 19:29:18 +0800 Received: from w36710x (10.144.242.117) by smtpscn.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 19:29:18 +0800 Date: Thu, 13 Oct 2011 19:29:18 +0800 From: HeXiaoyan X-Originating-IP: [10.144.242.117] To: cdni@ietf.org Message-id: <01c101cc899b$58f15950$0ad40bf0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=utf-8 Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcyJmr+iMdF6ZudYQFmoj8AjFUREoAAAFJlg X-CFilter-Loop: Reflected Subject: [CDNi] FW: New Version Notification for draft-xiaoyan-cdni-request-routing-protocol-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 11:29:35 -0000 Dera all, I've submitted a new I-D on CDNI Request Routing Protocol, your comments are welcome. http://www.ietf.org/id/draft-xiaoyan-cdni-request-routing-protocol-00.txt Best Regards Xiaoyan(Susan) He -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Thursday, October 13, 2011 7:25 PM To: hexiaoyan@huawei.com Cc: cheng@gsta.com; hexiaoyan@huawei.com; lijincheng@huawei.com; spencer.dawkins@huawei.com Subject: New Version Notification for draft-xiaoyan-cdni-request-routing-protocol-00.txt A new version of I-D, draft-xiaoyan-cdni-request-routing-protocol-00.txt has been successfully submitted by Xiaoyan He and posted to the IETF repository. Filename: draft-xiaoyan-cdni-request-routing-protocol Revision: 00 Title: Request Routing Protocol for CDN Interconnection Creation date: 2011-10-13 WG ID: Individual Submission Number of pages: 22 Abstract: The Request Routing Protocol allows the Request Routing system in interconnected Content Delivery Network(CDNs) to communicate to ensure that an end user request can be (re)directed from an upstream CDN to a surrogate in the downstream CDN. This document describes the details of the protocol used to provide this mechanism. The IETF Secretariat From swainner@cisco.com Thu Oct 13 04:51:22 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61FE21F8B47 for ; Thu, 13 Oct 2011 04:51:22 -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=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFB0-j7TTq9o for ; Thu, 13 Oct 2011 04:51:19 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DD80721F8B2B for ; Thu, 13 Oct 2011 04:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=73701; q=dns/txt; s=iport; t=1318506679; x=1319716279; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=qNwfnT+nsvkChWsXgVdwtrD6GjxrBl8HEBmchm4XiA0=; b=VQSLBwsUFlROVTMOT1Odb0WicpCcg13HtPvzVF/bAwUy7jv7cZRi8rtg zZKIm4Lwz6cqMeS/hXjMc10bUt69KiupCkZU9Kc5JAtA8u84cTVhhv79g AFtXhcULl1UOn20qQhWE0ExB5Zz+XgcbllRwjtHPnZtIhRUZkEh14WXRb A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4AAFvPlk6tJV2Y/2dsb2JhbABDmTCPIYEFgVMBAQEDAQEBAQ8BBwEMBkECAQEMBwICCxEEAQEBCRcBBgcPAgURHwkIEAMGAgEBFweHXAiZPgGeKQMCh2sEk3iRcQ X-IronPort-AV: E=Sophos;i="4.69,340,1315180800"; d="scan'208,217";a="28132222" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 13 Oct 2011 11:51:17 +0000 Received: from rtp-vpn3-818.cisco.com (rtp-vpn3-818.cisco.com [10.82.219.54]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9DBpE4I013804 for ; Thu, 13 Oct 2011 11:51:14 GMT Message-ID: <4E96D166.10701@cisco.com> Date: Thu, 13 Oct 2011 07:54:14 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: cdni@ietf.org References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com><4E8506FC.1020701@cisco.com><260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com><853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk><9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net><260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com><1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk><260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com><166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk><260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com><291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan><260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> Content-Type: multipart/alternative; boundary="------------020109070908050309000802" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 11:51:23 -0000 This is a multi-part message in MIME format. --------------020109070908050309000802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Seems there are potentially two classes of use cases: 1) Premium Content - CSP specifies available formats, encrypts, establishes relationship with client, agrees upon the available formats, and provides the client with a URL of their authorized delivery partner (uCDN) with permission to delegate delivery (assuming no content modification). The uCDN needs to qualify the dCDN via CDNi; however, the dCDN will merely be a transparent transfer point. The URL provided by the CSP needs to be modified somehow to point to the dCDN delivery node as opposed to the uCDN delivery node. The selected format (by the client) may NOT be viable for delivery over the dCDN; therefore, the uCDN should not delegate the delivery. That is the point of CDNi. NOTE: I still think there needs to be some basic elements covered by CDNi that addresses client <-> CDN authentication methods. CDN's use different authentication methods that ALLOW the client to even talk to the delivery nodes. 2) Public Content - CSP provides content in a specified format, unencrypted, doesn't specify the potential alternative formats, but provides the client with a URL of their preferred delivery partner (uCDN) with implicit permission to delegate delivery. No assumption or assertion is made about content modification. From the uCDN's perspective, they are simply looking for the dCDN's ability to delivery the content as presented by the CSP. The dCDN may indicate that it can deliver the content in which case the uCDN delegates the delivery. At this point, the dCDN is at liberty to transcode / transrate the content to optimize their transport resources. What knowledge does the dCDN have that the client can actually receive the modified content? The only way I can see (2) being resolved is if the dCDN had knowledge (metadata) about the capabilities / limitations of the client or a bounded set of viable adaptations of the content itself. Scott On 10/13/11 12:01 AM, Kevin J Ma wrote: > > Zhipeng, > > If the CP has tight integration with both CDN providers as you describe > below, I do not see why they would need CDNI at all? What would be the > benefit if they already have custom servers and security? > > Premium content providers that I am familiar with pregenerate content > encodings, run them through rigorous quality control tests, and do > not allow any modifications after that, to guarantee quality. To do > that in a CDN, let alone across CDNs, seems unlikely. Content is > processed in a secure facility and never released unencrypted to the > CDN. The CDN just acts a transparent delivery medium. > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > > Sent: Wednesday, October 12, 2011 11:25 PM > > To: Kevin J Ma; Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Kevin, > > > > As we ever discussed in previous email that the content format in > fact is > > decided by the CP. > > Only under the permission, the HD video may be transformed to the mobile > > video. i.e. if the CP support both IPTV and mobile video service, > then it > > may require the CDN to support multiple video formats. The multi-screen > > service means the content source is from the same CP while the target > > devices/clients include different groups. All content businesses are > under > > the permission of the content owner. > > > > For the content protection, I like talk a little more in this email for > > reference: > > Given there are two areas: London and Paris. > > And in these two areas, each has deployed the DRM. Generally each DRM > > implementation is independent. > > If the content is delivered from London to Paris, absolutely the whole > > process should be granted by the CP. > > For the DRM standard, it mainly concern the security on the terminal and > > the interface between the SP/Client. > > You may see that the servers that are granted by the CP is secure and we > > do not need to worry that secure server would be the hacker. > > Hence, if the content is delivered from one server to another server( > > these servers are the equipments granted by CP that may handle and > encrypt > > the content), the content is safe. Whether decrypt/re-encrypt or just > > deliver unencrypted content between these two servers are secure. > > > > Also, we may see such security issue for content distribution is a > general > > scenario that is not related to whether taking content adaptation. > > > > Thanks. > > Zhipeng > > > > > > > > -----Original Message----- > > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > > Sent: Thursday, October 13, 2011 10:45 AM > > To: ZhouZhipeng; Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > One practical concern to consider with the use case of downloading one > > (as opposed to ten) streams is that premium content providers > generally > > are very concerned with quality control and are unlikely to trust > dCDNs > > to modify the content, and most likely, the content will be encrypted? > > > > thanx. > > > > -- Kevin J. Ma > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > Behalf Of > > > ZhouZhipeng > > > Sent: Wednesday, October 12, 2011 9:51 PM > > > To: Ben Niven-Jenkins > > > Cc: cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Ben, > > > I respect your personal standpoint while seems you are only repeating > > your > > > personal conclusion without new reason/evidence. > > > In my case, I have explained the uCDN may deliver 10 streams to the > > dCDN. > > > But in our reality, we should consider whether it is a proper solution > > > that will be used by the market. > > > If the standard may not support the market requirements, it is > just the > > > problem for its deployment. > > > > > > Meanwhile in my feeling you have not carefully thought about how > it will > > > bring to the standard. I have repeated it is very simple in fact and I > > do > > > not know whether you have any special concern that will make you > feel it > > > would not be able to be done within 18-24 months. > > > Ben, as I repeat, if you have any question, I like respond via > reflector > > > or to you individually. > > > Thanks. > > > Zhipeng > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Thursday, October 13, 2011 1:13 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > > > Hello Ben, > > > > The UE may select the content format on the CP web. After that the > > user > > > only desires to get his selected content. > > > > But how the content is transferred to the client is not worried > by the > > > user. > > > > The CP may create a special format as required by the user and > ask the > > > CDN to deliver to user. > > > > While CP may give a HD format content to uCDN and the dCDN may then > > > transform to the format as the user select. > > > > > > Lots of things may be possible to do and CDN providers offer many > > > additional services on top of the "core" service of content delivery. > > > However, our objective (based on my interpretation of the CDNI > charter) > > is > > > to focus on what is necessary to interconnect CDNs to deliver content > > from > > > a CSP to an End User that is targeted and deployable within a > short time > > > frame (18-24 months). > > > > > > Content transformation/adaptation is not an essential requirement in > > order > > > to achieve that aim (we can deliver content from CSPs to End Users via > > > multiple CDNs without needing or requiring any CDN supports content > > > adaptation). > > > > > > In my opinion we have enough work to do already without trying to > expand > > > the scope of our work to include additional requirements that do not > > help > > > us address our core objectives as laid out in the CDNI charter. > > > > > > > In this case, it is nothing related to how the user select > formats on > > CP > > > website. > > > > So, it is the CP and user to decide the content format not the > > CDN(your > > > assert is not correct and seems you take that assert as your base for > > the > > > discussion). > > > > > > > > As for "the core CDN functionality offered by CDNs today", I > have ever > > > raised an email before that your company's webpage has claimed > > supporting > > > media transformation and multi-screen service. > > > > Perhaps, I like asking you list some features that you feel are the > > core > > > functionalities by existing main stream CDNs. Thus we may compare and > > take > > > deep look. > > > > > > I think the core functionality maps pretty well to the CDNI > interfaces, > > > namely: Request Routing, Metadata configuration, log production and > > > control plus content acquisition and content delivery. > > > > > > > I guess many people have the experience/knowledge of content related > > > service. The user and CP only care whether the CDN providers may > satisfy > > > their requirement while not care the internal process. Just as > GSM/PSTN > > > interconnection, the user only care successful interconnection > while not > > > care how the voice is transformed in process. > > > > > > > > Besides, I like raise a case: > > > > Given currently BBC recruits CDN providers that may support 10 media > > > formats. > > > > One candidate is your company, another is CDN-X. The users are > located > > > in France. > > > > So both your company and CDN-X should connect a France CDN > > provider(CDN- > > > Y). > > > > If your company's solution is to send 10 streams of different format > > of > > > one content to CDN-Y; > > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may > > > conduct some adaptation. > > > > Comparing these two solutions, for your company and CDN-X, > absolutely > > > the cost of CDN-X is much lower. > > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > while > > > in solution-2, it should only receive 1 stream but need to take > > > transformation to output 10 streams. > > > > > > > > Which solution is more competitive. it is Solution 1, right. > Remember > > > the price from BBC is same to both your company and CDN-X or BBC would > > > select one CDN provider with the lower price. > > > > If a CDN provider may not get the contract from CP, how it may > say it > > is > > > not a core functionality. > > > > > > What you are describing is a possible optimization that a > particular CDN > > > may wish to implement not a core functionality required to enable > > content > > > delivery between interconnected CDNs. I can think of many > optimizations > > > that a CDN could implement to differentiate their service but the > > internal > > > workings of an individual CDN are out of scope of our charter. > > > > > > So to repeat my position for a final time: Content adaptation is not a > > > core function required to enable content delivery between > interconnected > > > CDNs and therefore given the workload we already have to specify > > solutions > > > that do address the core functionality required to interconnect CDNs I > > do > > > not think we should be trying to add more work into that workload > as it > > > will only distract us from achieving our goal of producing deployable > > > solutions within the timeframe we are being told by operators they > needs > > > solutions within. > > > > > > Ben > > > > > > > So, if we all realize that currently the media type is rich, the CDN > > > providers should survive in the existing ecosystem and support the > media > > > types as required by the market. > > > > > > > > Back to the case of GSM/G.711, it just when concerning the > > > interconnection, the transformation should at once be solved. > Otherwise > > > the interconnection may not be operated. > > > > > > > > Br, > > > > Zhipeng > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > > To: ZhouZhipeng > > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > > > Zhipeng, > > > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > > > >> Ben and Philip, > > > >> I like to respond your concern in this one email: > > > >> > > > >> Ben, > > > >> I feel what we are now discussing is what is the "core" function of > > > CDN. > > > >> As you say, CDN is used to deliver content. That is absolutely > > correct > > > that the delivery capability is the core requirement for CDN system. > > > >> While CDN is used to provide the content delivery service. > > > >> What means service. It should include "time" "location" and "media > > > type", etc. These features are all the core feature for a service. > > > >> If we only concern "delivering one data block", I am not sure > whether > > > the issues such as "logging" "geographic constraint" are the core of > > CDN. > > > >> > > > >> For "without explicit knowledge of what that content actually > is ", I > > > am not sure whether the wording is accurate since generally a CDN may > > > claim it support different medias. > > > >> By this opportunity, I like to share a use case: a call from a GSM > > > phone to a PSTN telephone, the voice stream should be transformed from > > GSM > > > voice to G.711. > > > >> For the user, he does not need to know what type of data has been > > > transferred, but the operator has done some work to interconnect two > > > systems, right. > > > >> I like to know whether you may accept that my use case is > similar to > > > this case above. > > > > > > > > I don't think your use case is similar to the analogy of mobile > > networks > > > being interconnected to PSTN networks. In the case of content delivery > > the > > > negotiation is done between the User/Client and the Content > Provider and > > > the CDN is just used to execute/perform the delivery that has been > > > negotiated. The CDN is not involved in the decision making of what > > > representations the Content Provider decides to offer to the > User/Client > > > or in what representations the User/Client decides to request. > > > > > > > >> As for you said selecting media by the "portal", you may see > the way > > " > > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > > delivers one media stream to dCDN and dCDN takes some adaptation to > > > support multiple media types". > > > > > > > > Now what you're talking about is an optimisation, not a core > function > > > required to actually deliver the content (and report, bill, etc. for > > that > > > delivery). > > > > > > > > My position is that we should focus on how to enable the > > interconnection > > > of the core CDN functionality offered by CDNs today (which is also my > > > interpretation of the scope of the CDNI working group as expressed in > > its > > > charter) because doing so is a significant piece of work in itself. > > Let's > > > not start trying to add in additional functionality beyond what the > > > majority of CDNs support today as that will just delay us getting > usable > > > specifications into the market in a timely fashion IMO. > > > > > > > > Ben > > > > > > > >> A good question is "security" since I have done six years on > the DRM > > > and like to promote the DRM all around the world:) > > > >> If the content is needed to be protected, generally you may > know all > > > the systems should be granted by the content owner. > > > >> Here I also like to clarify that not only the media itself but the > > > information related to service itself (such as the geographic > > constraint) > > > should be protected also. > > > >> So, trust is not a problem for the media. > > > >> > > > >> Philip, > > > >> Thank you that you feel Content Adaption is an issue for > > "Requirements" > > > but I do not know why it is not for Use case. > > > >> I like to clarify to U that it is important for you operator > since it > > > may save investment if the system may support different services. > > > >> For us vendor, we are happy operator may install a system for the > > > mobile service and another system for the FBB service. > > > >> But the reality is all operators ask us to provide a system > that may > > > support different service systems. > > > >> > > > >> Frankly, Ben and Philip, I remember I have explained somewhere that > > to > > > implement this is rather simple . > > > >> At least the Use case and Requirement are informational to be > > referred > > > in future work. So I do really feel you may accept it. > > > >> Of course I like to respond your more concern and comments. > > > >> Thanks. > > > >> Zhipeng > > > >> > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > >> Sent: Monday, October 10, 2011 11:22 PM > > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > > >> Cc: cdni@ietf.org > > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > >> > > > >> Ben, Zhipeng, all, > > > >> > > > >> I think that Content Adaptation is more an issue for the > Requirements > > > doc than for the Use cases draft. > > > >> > > > >> The key question is whether we want the CDNI interfaces to be > able to > > > cope with a scenario where (say) HD/SD conversion is done in the > dCDN & > > to > > > signal about this. > > > >> > > > >> I think that coping with this scenario is a second order > requirement, > > > ie we should not worry about it in the initial standards-track work. I > > > don't know, did we ever decide whether the Use cases doc is restricted > > to > > > "initial" scenarios, or whether it's all-encompassing, ie covering > > > "future" scenarios as well? > > > >> > > > >> Scott, > > > >> Reading some of your examples, they seem to be valid even if > content > > > adaptation (HD/SD) is out of scope. > > > >> - a dCDN might for some reason be unwilling to distribute HD? > > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > > >> But these sorts of examples seem to be static policy things (to do > > with > > > the capabilities & preferences of the CDNs & CSP), rather than > metadata > > > associated with a particular piece of content. In the discussion > so far, > > I > > > think negotiation about static policy stuff is rather out of scope(?) > > > >> > > > >> On security considerations, an interesting question is whether > trust > > is > > > transitive. Don't think it need be - just because CSP trusts uCDN, and > > > uCDN trusts dCDN doesn't mean that the CSP automatically trusts the > > dCDN. > > > However, i suspect this can get arbitrarily complex - so one > possibility > > > is to say that we will only handle cases where the trust is > transitive. > > > >> > > > >> Best wishes > > > >> phil > > > >> > > > >> > > > >> Philip Eardley > > > >> Research and Technology Strategy > > > >> > > > >> This email contains BT information, which may be privileged or > > > confidential. It's meant only for the individual(s) or entity named > > above. > > > If you're not the intended recipient, note that disclosing, copying, > > > distributing or using this information is prohibited. If you've > received > > > this email in error, please let me know immediately on the email > address > > > above. Thank you. We monitor our email system, and may record your > > emails. > > > >> British Telecommunications plc > > > >> Registered office: 81 Newgate Street London EC1A 7AJ > > > >> Registered in England no: 1800000 > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > Behalf > > Of > > > Ben Niven-Jenkins > > > >> Sent: 10 October 2011 12:04 > > > >> To: ZhouZhipeng > > > >> Cc: cdni@ietf.org > > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > >> > > > >> Colleagues, > > > >> > > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > Content > > > Adaptation (i.e. taking in a content item in one format and > transforming > > > it to another format or representation) is not a "core" function of a > > CDN > > > which typically delivers the content that is requested without > explicit > > > knowledge of what that content actually is. > > > >> > > > >> Let's not forget that in building an end to end content service the > > CDN > > > is only one component and is the component tasked with executing the > > > delivery of a specific representation (version/copy/format etc.) > of the > > > selected content not the component tasked with deciding (or applying > > > policy) on which version/copy/representation of content should be > > > delivered. > > > >> > > > >> The decision as to which version/copy/representation to offer and > > allow > > > to be delivered to a given device/user is implemented outside of > the CDN > > > (e.g. by the "portal" where the user first makes their content > selection > > > prior to the CDN becoming involved in the delivery of the selected > > > content). > > > >> > > > >> Ben > > > >> > > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > > >> > > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > > description on the use case of HD and SD is not exactly correct. > > > >>> If one movie has two formats of HD and SD, then we have two > content > > > with different identifier. In DRM scope, the basic unit is a content > > copy. > > > >>> > > > >>> Here the first bullet "a subset of encodings deliverable to > specific > > > devices," has listed the case of content adaptation. > > > >>> In last month, I have contacted the Authors of this document and > > taken > > > some email exchanges with Grant and Philip (BT). > > > >>> I have shown BT with some information that I know in this case and > > > area to explain the content flexibility is currently a basic > requirement > > > for CDN service and related negotiation is needed in the CDN > > > interconnection. > > > >>> Meanwhile, I should also invite you in this group raising your > > > comments or questions on this case since I hope my use case may be > > > incorporated in the use case draft. > > > >>> > > > >>> If you have any more question or comments, pls share in this > thread. > > > >>> Thanks. > > > >>> Zhipeng > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -----Original Message----- > > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > > >>> Sent: Friday, September 30, 2011 8:02 AM > > > >>> To: cdni@ietf.org > > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > >>> > > > >>> Section 2.3 Nomadic Users > > > >>> This description falls under the category of Geographic Extension > > yet > > > >>> the third paragraph states the case where a different device > is used > > > in > > > >>> the same CDN coverage area. The intent of this use case needs > to be > > > >>> clarified. Perhaps the use case is trying to address the scenario > > > where > > > >>> a Nomadic User-A with an agreement allowing access to content from > > > CSP-A > > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > allowed > > > to > > > >>> distribute the content of CSP-A to User-A; however, not other > users > > in > > > >>> the region of the dCDN are allowed to retrieve the content unless > > they > > > >>> too have such an agreement. > > > >>> > > > >>> Section 5.1.3 Content Encoding Restrictions > > > >>> Need to clarify if we're talking about the restrictions on the > > > >>> delivery of specific content or the restrictions on the > ability of a > > > CDN > > > >>> to deliver specific content. I certainly understand the case > where > > a > > > >>> CSP will restrict the distribution of content to a "managed > path" if > > > >>> such content is HD while allowing the content distribution via an > > > >>> un-managed path if such content is SD (same could apply to > > encryption > > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > > have > > > >>> its own restrictions of blocking the distribution of HD content > > while > > > >>> allowing the distribution of SD content. > > > >>> > > > >>> o first bullet makes sense if the dCDN can perform a subset of > > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, > but not > > > DASH) > > > >>> o second bullet makes sense where the dCDN doesn't want to offer > > high > > > >>> bit-rate variants of the media > > > >>> o third bullet make sense if the policy addresses QoE but I don't > > > >>> think subscriber rights/authorizations apply. > > > >>> > > > >>> Section 10 Security Considerations > > > >>> > > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, I > > > think > > > >>> we can describe this in four contexts: > > > >>> > > > >>> a. The relationship between the CSP and the uCDN (the principle > > > contract > > > >>> arrangement for distribution) > > > >>> b. The relationship between the uCDN and dCDN (the transitive > trust > > > >>> relationship that extends the contract defined in (a) above) > > > >>> c. The relationship between the User and dCDN (the recognition of > > > right > > > >>> to download predicated on (b) above) > > > >>> d. The relationship between the User and CSP (the contract > > authorizing > > > >>> the user access to the content) > > > >>> > > > >>> The user is not interested in the a-b nor the b-c > relationship. The > > > user > > > >>> is only interested in the transparency and interoperability of the > > > >>> security relationship between d-b or d-c to the point that the > > > >>> authorization granted in d-a is viable when the delivery is > > initiated > > > >>> via either d-b or d-c. As an example, the uCDN might use URL > > appended > > > >>> tokens for authentication while dCDN might use URL appended > hashes. > > > The > > > >>> user doesn't want to know about the distinct methods, but > > transparency > > > >>> is only afforded if the methods are interoperable clearly defined > > when > > > >>> the delegation for content delivery is executed. Clearly, the > > choice > > > of > > > >>> authentication method is determined by the respective CDN's. > > > >>> > > > >>> Scott > > > >>> > > > >>> _______________________________________________ > > > >>> CDNi mailing list > > > >>> CDNi@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/cdni > > > >> > > > >> _______________________________________________ > > > >> CDNi mailing list > > > >> CDNi@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --------------020109070908050309000802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Seems there are potentially two classes of use cases:

1) Premium Content - CSP specifies available formats, encrypts, establishes relationship with client, agrees upon the available formats, and provides the client with a URL of their authorized delivery partner (uCDN) with permission to delegate delivery (assuming no content modification).  The uCDN needs to qualify the dCDN via CDNi; however, the dCDN will merely be a transparent transfer point.  The URL provided by the CSP needs to be modified somehow to point to the dCDN delivery node as opposed to the uCDN delivery node.   The selected format (by the client) may NOT be viable for delivery over the dCDN; therefore, the uCDN should not delegate the delivery.  That is the point of CDNi.

NOTE: I still think there needs to be some basic elements covered by CDNi that addresses client <-> CDN authentication methods.  CDN's use different authentication methods that ALLOW the client to even talk to the delivery nodes. 

2) Public Content - CSP provides content in a specified format, unencrypted, doesn't specify the potential alternative formats, but provides the client with a URL of their preferred delivery partner (uCDN) with implicit permission to delegate delivery.  No assumption or assertion is made about content modification.  From the uCDN's perspective, they are simply looking for the dCDN's ability to delivery the content as presented by the CSP.  The dCDN may indicate that it can deliver the content in which case the uCDN delegates the delivery.  At this point, the dCDN is at liberty to transcode / transrate the content to optimize their transport resources.  What knowledge does the dCDN have that the client can actually receive the modified content?

The only way I can see (2) being resolved is if the dCDN had knowledge (metadata) about the capabilities / limitations of the client or a bounded set of viable adaptations of the content itself.

Scott

On 10/13/11 12:01 AM, Kevin J Ma wrote:
Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

  If the CP has tight integration with both CDN providers as you describe
  below, I do not see why they would need CDNI at all?  What would be the
  benefit if they already have custom servers and security?

  Premium content providers that I am familiar with pregenerate content
  encodings, run them through rigorous quality control tests, and do
  not allow any modifications after that, to guarantee quality.  To do
  that in a CDN, let alone across CDNs, seems unlikely.  Content is
  processed in a secure facility and never released unencrypted to the
  CDN.  The CDN just acts a transparent delivery medium.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com]
> Sent: Wednesday, October 12, 2011 11:25 PM
> To: Kevin J Ma; Ben Niven-Jenkins
> Cc: cdni@ietf.org
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Kevin,
>
> As we ever discussed in previous email that the content format in fact is
> decided by the CP.
> Only under the permission, the HD video may be transformed to the mobile
> video. i.e. if the CP support both IPTV and mobile video service, then it
> may require the CDN to support multiple video formats. The multi-screen
> service means the content source is from the same CP while the target
> devices/clients include different groups. All content businesses are under
> the permission of the content owner.
>
> For the content protection, I like talk a little more in this email for
> reference:
> Given there are two areas: London and Paris.
> And in these two areas, each has deployed the DRM. Generally each DRM
> implementation is independent.
> If the content is delivered from London to Paris, absolutely the whole
> process should be granted by the CP.
> For the DRM standard, it mainly concern the security on the terminal and
> the interface between the SP/Client.
> You may see that the servers that are granted by the CP is secure and we
> do not need to worry that secure server would be the hacker.
> Hence, if the content is delivered from one server to another server(
> these servers are the equipments granted by CP that may handle and encrypt
> the content), the content is safe. Whether decrypt/re-encrypt or just
> deliver unencrypted content between these two servers are secure.
>
> Also, we may see such security issue for content distribution is a general
> scenario that is not related to whether taking content adaptation.
>
> Thanks.
> Zhipeng
>
>
>
> -----Original Message-----
> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]
> Sent: Thursday, October 13, 2011 10:45 AM
> To: ZhouZhipeng; Ben Niven-Jenkins
> Cc: cdni@ietf.org
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Zhipeng,
>
>   One practical concern to consider with the use case of downloading one
>   (as opposed to ten) streams is that premium content providers generally
>   are very concerned with quality control and are unlikely to trust dCDNs
>   to modify the content, and most likely, the content will be encrypted?
>
> thanx.
>
> --  Kevin J. Ma
>
> > -----Original Message-----
> > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> > ZhouZhipeng
> > Sent: Wednesday, October 12, 2011 9:51 PM
> > To: Ben Niven-Jenkins
> > Cc: cdni@ietf.org
> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> >
> > Ben,
> > I respect your personal standpoint while seems you are only repeating
> your
> > personal conclusion without new reason/evidence.
> > In my case, I have explained the uCDN may deliver 10 streams to the
> dCDN.
> > But in our reality, we should consider whether it is a proper solution
> > that will be used by the market.
> > If the standard may not support the market requirements, it is just the
> > problem for its deployment.
> >
> > Meanwhile in my feeling you have not carefully thought about how it will
> > bring to the standard. I have repeated it is very simple in fact and I
> do
> > not know whether you have any special concern that will make you feel it
> > would not be able to be done within 18-24 months.
> > Ben, as I repeat, if you have any question, I like respond via reflector
> > or to you individually.
> > Thanks.
> > Zhipeng
> >
> > -----Original Message-----
> > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> > Sent: Thursday, October 13, 2011 1:13 AM
> > To: ZhouZhipeng
> > Cc: philip.eardley@bt.com; cdni@ietf.org
> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> >
> > Zhipeng,
> >
> > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote:
> >
> > > Hello Ben,
> > > The UE may select the content format on the CP web. After that the
> user
> > only desires to get his selected content.
> > > But how the content is transferred to the client is not worried by the
> > user.
> > > The CP may create a special format as required by the user and ask the
> > CDN to deliver to user.
> > > While CP may give a HD format content to uCDN and the dCDN may then
> > transform to the format as the user select.
> >
> > Lots of things may be possible to do and CDN providers offer many
> > additional services on top of the "core" service of content delivery.
> > However, our objective (based on my interpretation of the CDNI charter)
> is
> > to focus on what is necessary to interconnect CDNs to deliver content
> from
> > a CSP to an End User that is targeted and deployable within a short time
> > frame (18-24 months).
> >
> > Content transformation/adaptation is not an essential requirement in
> order
> > to achieve that aim (we can deliver content from CSPs to End Users via
> > multiple CDNs without needing or requiring any CDN supports content
> > adaptation).
> >
> > In my opinion we have enough work to do already without trying to expand
> > the scope of our work to include additional requirements that do not
> help
> > us address our core objectives as laid out in the CDNI charter.
> >
> > > In this case, it is nothing related to how the user select formats on
> CP
> > website.
> > > So, it is the CP and user to decide the content format not the
> CDN(your
> > assert is not correct and seems you take that assert as your base for
> the
> > discussion).
> > >
> > > As for "the core CDN functionality offered by CDNs today", I have ever
> > raised an email before that your company's webpage has claimed
> supporting
> > media transformation and multi-screen service.
> > > Perhaps, I like asking you list some features that you feel are the
> core
> > functionalities by existing main stream CDNs. Thus we may compare and
> take
> > deep look.
> >
> > I think the core functionality maps pretty well to the CDNI interfaces,
> > namely: Request Routing, Metadata configuration, log production and
> > control plus content acquisition and content delivery.
> >
> > > I guess many people have the experience/knowledge of content related
> > service. The user and CP only care whether the CDN providers may satisfy
> > their requirement while not care the internal process. Just as GSM/PSTN
> > interconnection, the user only care successful interconnection while not
> > care how the voice is transformed in process.
> > >
> > > Besides, I like raise a case:
> > > Given currently BBC recruits CDN providers that may support 10 media
> > formats.
> > > One candidate is your company, another is CDN-X. The users are located
> > in France.
> > > So both your company and CDN-X should connect a France CDN
> provider(CDN-
> > Y).
> > > If your company's solution is to send 10 streams of different format
> of
> > one content to CDN-Y;
> > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may
> > conduct some adaptation.
> > > Comparing these two solutions, for your company and CDN-X, absolutely
> > the cost of CDN-X is much lower.
> > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while
> > in solution-2, it should only receive 1 stream but need to take
> > transformation to output 10 streams.
> > >
> > > Which solution is more competitive. it is Solution 1, right. Remember
> > the price from BBC is same to both your company and CDN-X or BBC would
> > select one CDN provider with the lower price.
> > > If a CDN provider may not get the contract from CP, how it may say it
> is
> > not a core functionality.
> >
> > What you are describing is a possible optimization that a particular CDN
> > may wish to implement not a core functionality required to enable
> content
> > delivery between interconnected CDNs. I can think of many optimizations
> > that a CDN could implement to differentiate their service but the
> internal
> > workings of an individual CDN are out of scope of our charter.
> >
> > So to repeat my position for a final time: Content adaptation is not a
> > core function required to enable content delivery between interconnected
> > CDNs and therefore given the workload we already have to specify
> solutions
> > that do address the core functionality required to interconnect CDNs I
> do
> > not think we should be trying to add more work into that workload as it
> > will only distract us from achieving our goal of producing deployable
> > solutions within the timeframe we are being told by operators they needs
> > solutions within.
> >
> > Ben
> >
> > > So, if we all realize that currently the media type is rich, the CDN
> > providers should survive in the existing ecosystem and support the media
> > types as required by the market.
> > >
> > > Back to the case of GSM/G.711, it just when concerning the
> > interconnection, the transformation should at once be solved. Otherwise
> > the interconnection may not be operated.
> > >
> > > Br,
> > > Zhipeng
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> > > Sent: Wednesday, October 12, 2011 12:19 AM
> > > To: ZhouZhipeng
> > > Cc: philip.eardley@bt.com; cdni@ietf.org
> > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >
> > > Zhipeng,
> > >
> > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote:
> > >
> > >> Ben and Philip,
> > >> I like to respond your concern in this one email:
> > >>
> > >> Ben,
> > >> I feel what we are now discussing is what is the "core" function of
> > CDN.
> > >> As you say, CDN is used to deliver content. That is absolutely
> correct
> > that the delivery capability is the core requirement for CDN system.
> > >> While CDN is used to provide the content delivery service.
> > >> What means service. It should include "time" "location" and "media
> > type", etc. These features are all the core feature for a service.
> > >> If we only concern "delivering one data block", I am not sure whether
> > the issues such as "logging" "geographic constraint" are the core of
> CDN.
> > >>
> > >> For "without explicit knowledge of what that content actually is ", I
> > am not sure whether the wording is accurate since generally a CDN may
> > claim it support different medias.
> > >> By this opportunity, I like to share a use case: a call from a GSM
> > phone to a PSTN telephone, the voice stream should be transformed from
> GSM
> > voice to G.711.
> > >> For the user, he does not need to know what type of data has been
> > transferred, but the operator has done some work to interconnect two
> > systems, right.
> > >> I like to know whether you may accept that my use case is similar to
> > this case above.
> > >
> > > I don't think your use case is similar to the analogy of mobile
> networks
> > being interconnected to PSTN networks. In the case of content delivery
> the
> > negotiation is done between the User/Client and the Content Provider and
> > the CDN is just used to execute/perform the delivery that has been
> > negotiated. The CDN is not involved in the decision making of what
> > representations the Content Provider decides to offer to the User/Client
> > or in what representations the User/Client decides to request.
> > >
> > >> As for you said selecting media by the "portal", you may see the way
> "
> > uCDN delivers multiple media streams to dCDN" is not good than "uCDN
> > delivers one media stream to dCDN and dCDN takes some adaptation to
> > support multiple media types".
> > >
> > > Now what you're talking about is an optimisation, not a core function
> > required to actually deliver the content (and report, bill, etc. for
> that
> > delivery).
> > >
> > > My position is that we should focus on how to enable the
> interconnection
> > of the core CDN functionality offered by CDNs today (which is also my
> > interpretation of the scope of the CDNI working group as expressed in
> its
> > charter) because doing so is a significant piece of work in itself.
> Let's
> > not start trying to add in additional functionality beyond what the
> > majority of CDNs support today as that will just delay us getting usable
> > specifications into the market in a timely fashion IMO.
> > >
> > > Ben
> > >
> > >> A good question is "security" since I have done six years on the DRM
> > and like to promote the DRM all around the world:)
> > >> If the content is needed to be protected, generally you may know all
> > the systems should be granted by the content owner.
> > >> Here I also like to clarify that not only the media itself but the
> > information related to service itself (such as the geographic
> constraint)
> > should be protected also.
> > >> So, trust is not a problem for the media.
> > >>
> > >> Philip,
> > >> Thank you that you feel Content Adaption is an issue for
> "Requirements"
> > but I do not know why it is not for Use case.
> > >> I like to clarify to U that it is important for you operator since it
> > may save investment if the system may support different services.
> > >> For us vendor, we are happy operator may install a system for the
> > mobile service and another system for the FBB service.
> > >> But the reality is all operators ask us to provide a system that may
> > support different service systems.
> > >>
> > >> Frankly, Ben and Philip, I remember I have explained somewhere that
> to
> > implement this is rather simple .
> > >> At least the Use case and Requirement are informational to be
> referred
> > in future work. So I do really feel you may accept it.
> > >> Of course I like to respond your more concern and comments.
> > >> Thanks.
> > >> Zhipeng
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
> > >> Sent: Monday, October 10, 2011 11:22 PM
> > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng
> > >> Cc: cdni@ietf.org
> > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >>
> > >> Ben, Zhipeng, all,
> > >>
> > >> I think that Content Adaptation is more an issue for the Requirements
> > doc than for the Use cases draft.
> > >>
> > >> The key question is whether we want the CDNI interfaces to be able to
> > cope with a scenario where (say) HD/SD conversion is done in the dCDN &
> to
> > signal about this.
> > >>
> > >> I think that coping with this scenario is a second order requirement,
> > ie we should not worry about it in the initial standards-track work. I
> > don't know, did we ever decide whether the Use cases doc is restricted
> to
> > "initial" scenarios, or whether it's all-encompassing, ie covering
> > "future" scenarios as well?
> > >>
> > >> Scott,
> > >> Reading some of your examples, they seem to be valid even if content
> > adaptation (HD/SD) is out of scope.
> > >> - a dCDN might for some reason be unwilling to distribute HD?
> > >> - a CSP might want to make sure the dCDN can use HLS encapsulation?
> > >> But these sorts of examples seem to be static policy things (to do
> with
> > the capabilities & preferences of the CDNs & CSP), rather than metadata
> > associated with a particular piece of content. In the discussion so far,
> I
> > think negotiation about static policy stuff is rather out of scope(?)
> > >>
> > >> On security considerations, an interesting question is whether trust
> is
> > transitive. Don't think it need be - just because CSP trusts uCDN, and
> > uCDN trusts dCDN doesn't mean that the CSP automatically trusts the
> dCDN.
> > However, i suspect this can get arbitrarily complex - so one possibility
> > is to say that we will only handle cases where the trust is transitive.
> > >>
> > >> Best wishes
> > >> phil
> > >>
> > >>
> > >> Philip Eardley
> > >> Research and Technology Strategy
> > >>
> > >> This email contains BT information, which may be privileged or
> > confidential. It's meant only for the individual(s) or entity named
> above.
> > If you're not the intended recipient, note that disclosing, copying,
> > distributing or using this information is prohibited. If you've received
> > this email in error, please let me know immediately on the email address
> > above. Thank you. We monitor our email system, and may record your
> emails.
> > >> British Telecommunications plc
> > >> Registered office: 81 Newgate Street London EC1A 7AJ
> > >> Registered in England no: 1800000
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf
> Of
> > Ben Niven-Jenkins
> > >> Sent: 10 October 2011 12:04
> > >> To: ZhouZhipeng
> > >> Cc: cdni@ietf.org
> > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >>
> > >> Colleagues,
> > >>
> > >> IMO Section 5.1.3 should be removed from the Use Cases draft. Content
> > Adaptation (i.e. taking in a content item in one format and transforming
> > it to another format or representation) is not a "core" function of a
> CDN
> > which typically delivers the content that is requested without explicit
> > knowledge of what that content actually is.
> > >>
> > >> Let's not forget that in building an end to end content service the
> CDN
> > is only one component and is the component tasked with executing the
> > delivery of a specific representation (version/copy/format etc.) of the
> > selected content not the component tasked with deciding (or applying
> > policy) on which version/copy/representation of content should be
> > delivered.
> > >>
> > >> The decision as to which version/copy/representation to offer and
> allow
> > to be delivered to a given device/user is implemented outside of the CDN
> > (e.g. by the "portal" where the user first makes their content selection
> > prior to the CDN becoming involved in the delivery of the selected
> > content).
> > >>
> > >> Ben
> > >>
> > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:
> > >>
> > >>> Following Scott's comments on section 5.1.3, I feel Scott's
> > description on the use case of HD and SD is not exactly correct.
> > >>> If one movie has two formats of HD and SD, then we have two content
> > with different identifier. In DRM scope, the basic unit is a content
> copy.
> > >>>
> > >>> Here the first bullet "a subset of encodings deliverable to specific
> > devices," has listed the case of content adaptation.
> > >>> In last month, I have contacted the Authors of this document and
> taken
> > some email exchanges with Grant and Philip (BT).
> > >>> I have shown BT with some information that I know in this case and
> > area to explain the content flexibility is currently a basic requirement
> > for CDN service and related negotiation is needed in the CDN
> > interconnection.
> > >>> Meanwhile, I should also invite you in this group raising your
> > comments or questions on this case since I hope my use case may be
> > incorporated in the use case draft.
> > >>>
> > >>> If you have any more question or comments, pls share in this thread.
> > >>> Thanks.
> > >>> Zhipeng
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: Scott Wainner [mailto:swainner@cisco.com]
> > >>> Sent: Friday, September 30, 2011 8:02 AM
> > >>> To: cdni@ietf.org
> > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >>>
> > >>> Section 2.3 Nomadic Users
> > >>> This description falls under the category of Geographic Extension
> yet
> > >>> the third paragraph states the case where a different device is used
> > in
> > >>> the same CDN coverage area.  The intent of this use case needs to be
> > >>> clarified.  Perhaps the use case is trying to address the scenario
> > where
> > >>> a Nomadic User-A with an agreement allowing access to content from
> > CSP-A
> > >>> via uCDN moves to a dCDN in a different region.  The dCDN is allowed
> > to
> > >>> distribute the content of CSP-A to User-A; however, not other users
> in
> > >>> the region of the dCDN are allowed to retrieve the content unless
> they
> > >>> too have such an agreement.
> > >>>
> > >>> Section 5.1.3 Content Encoding Restrictions
> > >>> Need to clarify if we're talking about the restrictions on the
> > >>> delivery of specific content or the restrictions on the ability of a
> > CDN
> > >>> to deliver specific content.  I certainly understand the case where
> a
> > >>> CSP will restrict the distribution of content to a "managed path" if
> > >>> such content is HD while allowing the content distribution via an
> > >>> un-managed path if such content is SD (same could apply to
> encryption
> > >>> methods, delivery methods, etc.).  On the contrary, the dCDN may
> have
> > >>> its own restrictions of blocking the distribution of HD content
> while
> > >>> allowing the distribution of SD content.
> > >>>
> > >>> o first bullet makes sense if the dCDN can perform a subset of
> > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but not
> > DASH)
> > >>> o second bullet makes sense where the dCDN doesn't want to offer
> high
> > >>> bit-rate variants of the media
> > >>> o third bullet make sense if the policy addresses QoE but I don't
> > >>> think subscriber rights/authorizations apply.
> > >>>
> > >>> Section 10 Security Considerations
> > >>>
> > >>> Aside from the security considerations WITHIN the uCDN and dCDN, I
> > think
> > >>> we can describe this in four contexts:
> > >>>
> > >>> a. The relationship between the CSP and the uCDN (the principle
> > contract
> > >>> arrangement for distribution)
> > >>> b. The relationship between the uCDN and dCDN (the transitive trust
> > >>> relationship that extends the contract defined in (a) above)
> > >>> c. The relationship between the User and dCDN (the recognition of
> > right
> > >>> to download predicated on (b) above)
> > >>> d. The relationship between the User and CSP (the contract
> authorizing
> > >>> the user access to the content)
> > >>>
> > >>> The user is not interested in the a-b nor the b-c relationship. The
> > user
> > >>> is only interested in the transparency and interoperability of the
> > >>> security relationship between d-b or d-c to the point that the
> > >>> authorization granted in d-a is viable when the delivery is
> initiated
> > >>> via either d-b or d-c.  As an example, the uCDN might use URL
> appended
> > >>> tokens for authentication while dCDN might use URL appended hashes.
> > The
> > >>> user doesn't want to know about the distinct methods, but
> transparency
> > >>> is only afforded if the methods are interoperable clearly defined
> when
> > >>> the delegation for content delivery is executed.  Clearly, the
> choice
> > of
> > >>> authentication method is determined by the respective CDN's.
> > >>>
> > >>> Scott
> > >>>
> > >>> _______________________________________________
> > >>> CDNi mailing list
> > >>> CDNi@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/cdni
> > >>
> > >> _______________________________________________
> > >> CDNi mailing list
> > >> CDNi@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/cdni
> > >
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni


--------------020109070908050309000802-- From zhouzhipeng@huawei.com Thu Oct 13 05:12:03 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7D321F8B4F for ; Thu, 13 Oct 2011 05:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.485 X-Spam-Level: X-Spam-Status: No, score=-5.485 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8Nh2ljQ-yj5 for ; Thu, 13 Oct 2011 05:12:01 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E887C21F8B30 for ; Thu, 13 Oct 2011 05:12:00 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT000N8177H15@szxga03-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 20:11:41 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT000K0E77HS6@szxga03-in.huawei.com> for cdni@ietf.org; Thu, 13 Oct 2011 20:11:41 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEF35516; Thu, 13 Oct 2011 20:11:41 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 13 Oct 2011 20:11:35 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Thu, 13 Oct 2011 20:11:32 +0800 Date: Thu, 13 Oct 2011 12:11:31 +0000 From: ZhouZhipeng In-reply-to: <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> X-Originating-IP: [10.138.73.38] To: "grant.watson@bt.com" , "kevin.ma@azukisystems.com" , "ben@niven-jenkins.co.uk" Message-id: <260A32EFD5C9EB47AD504929D005DF6245B154@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QIAAAyQAgAAMvHCAAGgN4IAAG0Dg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 12:12:04 -0000 Grant, Nice to see your comment. May I conclude that by now the core issue for the content adaptation is " content protection". As a DRM people for years, I fully understand this concern. In fact the DRM circle have fully understood this concern since DRM should consider both the protection and the service implementation. May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI. It is not related to the content transcoding while you still face the issue for the protection transformation. For example, how your company's IPTV may connect the FT's terminals. Even in the internet that the PCs in different area may install the same soft DRM client, it may still has the problem of the content's duplication and content's verification(integrity protection). Take the OMA DRM DCF as an example, each content copy has its unique identifier(contentId) and each content copy has its unique Hash value. Hence in OMA DRM system, you( the device) may not duplicate a protected content copy that may be verified successfully by the device. Only the CP that encrypt the content may create a new copy of the content with another identifier. While in CDN system, we all know for the load balancing the CDN should be able to duplicate the hot content when needed. How it may be realized if the CDN may not create a new content copy that comply with the DRM solution. So you may see, there should be a secure facility within the CDN that may create/encrypt the content which may be accepted by the DRM client. Above is my analysis on this issue. Hope you may take a look at the OMA DRM specification to check the reason. For any question, I would like to respond as long as I know. Also note that the analysis is not specific to the content adaptation. I mean only general functionality of CDN. Thanks. Zhipeng -----Original Message----- From: grant.watson@bt.com [mailto:grant.watson@bt.com] Sent: Thursday, October 13, 2011 6:34 PM To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I'd support that perspective. Today CPs, in my experience, sometimes even actively seeks assurances that the content will NOT be modified by the CDN or by other downstream processes. So to envisage a CP allowing/wanting that to happen in a dCDN (that is likely out of their control, perhaps in another geography and with no quality feedback) feels like a very, very unlikely scenario. In general the content arrives encrypted and is shipped transparently, in my experience. Indeed the CPs desire to ship to different devices / screens etc. is also transparent to the CDN, they're just different objects requested by logic that is out-of-band to the CDN. I know of cases where content is transcoded/modified for mobile access by transparent caching, for example. But TC is not relevant to CDNI. IMHO content adaption/modification/transcoding is not a fundamental issue for CDNI. The issues around solving the fundamentals of how to Interconnect CDN are challenging enough. So I feel we should focus the scope on widely deployed use-cases / features and very likely new use-cases that are created by CDNI. g- -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: 13 October 2011 05:02 To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact > is decided by the CP. > Only under the permission, the HD video may be transformed to the > mobile video. i.e. if the CP support both IPTV and mobile video > service, then it may require the CDN to support multiple video > formats. The multi-screen service means the content source is from the > same CP while the target devices/clients include different groups. All > content businesses are under the permission of the content owner. > > For the content protection, I like talk a little more in this email > for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal > and the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and > we do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and > encrypt the content), the content is safe. Whether decrypt/re-encrypt > or just deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a > general scenario that is not related to whether taking content adaptation. > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only > > repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper > > solution that will be used by the market. > > If the standard may not support the market requirements, it is just > > the problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it > > will bring to the standard. I have repeated it is very simple in > > fact and I > do > > not know whether you have any special concern that will make you > > feel it would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via > > reflector or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by > > > the > > user. > > > The CP may create a special format as required by the user and ask > > > the > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may > > > then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI > > charter) > is > > to focus on what is necessary to interconnect CDNs to deliver > > content > from > > a CSP to an End User that is targeted and deployable within a short > > time frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users > > via multiple CDNs without needing or requiring any CDN supports > > content adaptation). > > > > In my opinion we have enough work to do already without trying to > > expand the scope of our work to include additional requirements that > > do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats > > > on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base > > for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have > > > ever > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are > > > the > core > > functionalities by existing main stream CDNs. Thus we may compare > > and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI > > interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content > > > related > > service. The user and CP only care whether the CDN providers may > > satisfy their requirement while not care the internal process. Just > > as GSM/PSTN interconnection, the user only care successful > > interconnection while not care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 > > > media > > formats. > > > One candidate is your company, another is CDN-X. The users are > > > located > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different > > > format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y > > > may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, > > > absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > > > while > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. > > > Remember > > the price from BBC is same to both your company and CDN-X or BBC > > would select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say > > > it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular > > CDN may wish to implement not a core functionality required to > > enable > content > > delivery between interconnected CDNs. I can think of many > > optimizations that a CDN could implement to differentiate their > > service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not > > a core function required to enable content delivery between > > interconnected CDNs and therefore given the workload we already have > > to specify > solutions > > that do address the core functionality required to interconnect CDNs > > I > do > > not think we should be trying to add more work into that workload as > > it will only distract us from achieving our goal of producing > > deployable solutions within the timeframe we are being told by > > operators they needs solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the > > > CDN > > providers should survive in the existing ecosystem and support the > > media types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. > > Otherwise the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function > > >> of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and > > >> "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure > > >> whether > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is > > >> ", I > > am not sure whether the wording is accurate since generally a CDN > > may claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a > > >> GSM > > phone to a PSTN telephone, the voice stream should be transformed > > from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar > > >> to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content > > delivery > the > > negotiation is done between the User/Client and the Content Provider > > and the CDN is just used to execute/perform the delivery that has > > been negotiated. The CDN is not involved in the decision making of > > what representations the Content Provider decides to offer to the > > User/Client or in what representations the User/Client decides to request. > > > > > >> As for you said selecting media by the "portal", you may see the > > >> way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core > > > function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also > > my interpretation of the scope of the CDNI working group as > > expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting > > usable specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the > > >> DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know > > >> all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but > > >> the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator > > >> since it > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that > > >> may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere > > >> that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the > > >> Requirements > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be > > >> able to > > cope with a scenario where (say) HD/SD conversion is done in the > > dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order > > >> requirement, > > ie we should not worry about it in the initial standards-track work. > > I don't know, did we ever decide whether the Use cases doc is > > restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if > > >> content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to > > >> do > with > > the capabilities & preferences of the CDNs & CSP), rather than > > metadata associated with a particular piece of content. In the > > discussion so far, > I > > think negotiation about static policy stuff is rather out of > > scope(?) > > >> > > >> On security considerations, an interesting question is whether > > >> trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, > > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > > the > dCDN. > > However, i suspect this can get arbitrarily complex - so one > > possibility is to say that we will only handle cases where the trust is transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > > email address above. Thank you. We monitor our email system, and may > > record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered > > >> in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > > >> Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > > >> Content > > Adaptation (i.e. taking in a content item in one format and > > transforming it to another format or representation) is not a "core" > > function of a > CDN > > which typically delivers the content that is requested without > > explicit knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service > > >> the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of > > the selected content not the component tasked with deciding (or > > applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the > > CDN (e.g. by the "portal" where the user first makes their content > > selection prior to the CDN becoming involved in the delivery of the > > selected content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two > > >>> content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to > > >>> specific > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case > > >>> and > > area to explain the content flexibility is currently a basic > > requirement for CDN service and related negotiation is needed in the > > CDN interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread. > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic > > >>> Extension > yet > > >>> the third paragraph states the case where a different device is > > >>> used > > in > > >>> the same CDN coverage area. The intent of this use case needs > > >>> to be clarified. Perhaps the use case is trying to address the > > >>> scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content > > >>> from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > > >>> allowed > > to > > >>> distribute the content of CSP-A to User-A; however, not other > > >>> users > in > > >>> the region of the dCDN are allowed to retrieve the content > > >>> unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if > > >>> we're talking about the restrictions on the delivery of specific > > >>> content or the restrictions on the ability of a > > CDN > > >>> to deliver specific content. I certainly understand the case > > >>> where > a > > >>> CSP will restrict the distribution of content to a "managed > > >>> path" if such content is HD while allowing the content > > >>> distribution via an un-managed path if such content is SD (same > > >>> could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but > > >>> not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I > > >>> don't think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, > > >>> I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive > > >>> trust relationship that extends the contract defined in (a) > > >>> above) c. The relationship between the User and dCDN (the > > >>> recognition of > > right > > >>> to download predicated on (b) above) d. The relationship between > > >>> the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. > > >>> The > > user > > >>> is only interested in the transparency and interoperability of > > >>> the security relationship between d-b or d-c to the point that > > >>> the authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly > > >>> defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From grant.watson@bt.com Thu Oct 13 05:40:51 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F88F21F8531 for ; Thu, 13 Oct 2011 05:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcFabUEUsuVK for ; Thu, 13 Oct 2011 05:40:49 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.com [62.239.224.234]) by ietfa.amsl.com (Postfix) with ESMTP id 8628D21F8509 for ; Thu, 13 Oct 2011 05:40:48 -0700 (PDT) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 13 Oct 2011 13:40:47 +0100 Received: from EMV64-UKRD.domain1.systemhost.net ([169.254.1.13]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Thu, 13 Oct 2011 13:40:46 +0100 From: To: , , Date: Thu, 13 Oct 2011 13:40:44 +0100 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QIAAAyQAgAAMvHCAAGgN4IAAG0DggAAPupA= Message-ID: <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245B154@SZXEML519-MBS.china.huawei.com> In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6245B154@SZXEML519-MBS.china.huawei.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 12:40:51 -0000 Hi, "May I ask a question, if the content has been encrypted and would not be m= odified in the CDNI process, but the devices in two areas have deployed dif= ferent DRM system, how it will be for the CDNI." Just like it works right now: If objects are encrypted differently or use d= ifferent DRMs generally it translates as separate objects in the CDN, Inter= connected or otherwise. DRM is implemented by the CP, in the knowledge of w= hat end devices and DRM platforms they are delivering to. IMHO that works r= ight now and would work in a CDNI scenario. Frankly, I am even more convinced that this is best left out of scope now. = IMHO duplication of content assets inside the CDN to facilitate cross DRM d= elivery is not a CDNI issue. I can see how this may be optimised perhaps, t= o reduce the amount of assets for example, but again that is not a CDNI iss= ue - the issue exists for both CDN today and Interconnected CDN. g- -----Original Message----- From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] Sent: 13 October 2011 13:12 To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; ben@niven-jenkins.co.= uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Grant, Nice to see your comment. May I conclude that by now the core issue for the content adaptation is " c= ontent protection". As a DRM people for years, I fully understand this concern. In fact the DRM circle have fully understood this concern since DRM should = consider both the protection and the service implementation. May I ask a question, if the content has been encrypted and would not be mo= dified in the CDNI process, but the devices in two areas have deployed diff= erent DRM system, how it will be for the CDNI. It is not related to the content transcoding while you still face the issue= for the protection transformation. For example, how your company's IPTV ma= y connect the FT's terminals. Even in the internet that the PCs in different area may install the same so= ft DRM client, it may still has the problem of the content's duplication an= d content's verification(integrity protection). Take the OMA DRM DCF as an example, each content copy has its unique identi= fier(contentId) and each content copy has its unique Hash value. Hence in OMA DRM system, you( the device) may not duplicate a protected con= tent copy that may be verified successfully by the device. Only the CP that encrypt the content may create a new copy of the content w= ith another identifier. While in CDN system, we all know for the load balancing the CDN should be a= ble to duplicate the hot content when needed. How it may be realized if the= CDN may not create a new content copy that comply with the DRM solution. So you may see, there should be a secure facility within the CDN that may c= reate/encrypt the content which may be accepted by the DRM client. Above is my analysis on this issue. Hope you may take a look at the OMA DRM= specification to check the reason. For any question, I would like to respond as long as I know. Also note that the analysis is not specific to the content adaptation. I me= an only general functionality of CDN. Thanks. Zhipeng -----Original Message----- From: grant.watson@bt.com [mailto:grant.watson@bt.com] Sent: Thursday, October 13, 2011 6:34 PM To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I'd support that perspective. Today CPs, in my experience, sometimes even a= ctively seeks assurances that the content will NOT be modified by the CDN o= r by other downstream processes. So to envisage a CP allowing/wanting that = to happen in a dCDN (that is likely out of their control, perhaps in anothe= r geography and with no quality feedback) feels like a very, very unlikely = scenario. In general the content arrives encrypted and is shipped transpare= ntly, in my experience. Indeed the CPs desire to ship to different devices = / screens etc. is also transparent to the CDN, they're just different objec= ts requested by logic that is out-of-band to the CDN. I know of cases where content is transcoded/modified for mobile access by t= ransparent caching, for example. But TC is not relevant to CDNI. IMHO content adaption/modification/transcoding is not a fundamental issue f= or CDNI. The issues around solving the fundamentals of how to Interconnect = CDN are challenging enough. So I feel we should focus the scope on widely d= eployed use-cases / features and very likely new use-cases that are created= by CDNI. g- -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kev= in J Ma Sent: 13 October 2011 05:02 To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact > is decided by the CP. > Only under the permission, the HD video may be transformed to the > mobile video. i.e. if the CP support both IPTV and mobile video > service, then it may require the CDN to support multiple video > formats. The multi-screen service means the content source is from the > same CP while the target devices/clients include different groups. All > content businesses are under the permission of the content owner. > > For the content protection, I like talk a little more in this email > for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal > and the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and > we do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and > encrypt the content), the content is safe. Whether decrypt/re-encrypt > or just deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a > general scenario that is not related to whether taking content adaptation= . > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only > > repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper > > solution that will be used by the market. > > If the standard may not support the market requirements, it is just > > the problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it > > will bring to the standard. I have repeated it is very simple in > > fact and I > do > > not know whether you have any special concern that will make you > > feel it would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via > > reflector or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by > > > the > > user. > > > The CP may create a special format as required by the user and ask > > > the > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may > > > then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI > > charter) > is > > to focus on what is necessary to interconnect CDNs to deliver > > content > from > > a CSP to an End User that is targeted and deployable within a short > > time frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users > > via multiple CDNs without needing or requiring any CDN supports > > content adaptation). > > > > In my opinion we have enough work to do already without trying to > > expand the scope of our work to include additional requirements that > > do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats > > > on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base > > for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have > > > ever > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are > > > the > core > > functionalities by existing main stream CDNs. Thus we may compare > > and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI > > interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content > > > related > > service. The user and CP only care whether the CDN providers may > > satisfy their requirement while not care the internal process. Just > > as GSM/PSTN interconnection, the user only care successful > > interconnection while not care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 > > > media > > formats. > > > One candidate is your company, another is CDN-X. The users are > > > located > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different > > > format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y > > > may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, > > > absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > > > while > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. > > > Remember > > the price from BBC is same to both your company and CDN-X or BBC > > would select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say > > > it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular > > CDN may wish to implement not a core functionality required to > > enable > content > > delivery between interconnected CDNs. I can think of many > > optimizations that a CDN could implement to differentiate their > > service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not > > a core function required to enable content delivery between > > interconnected CDNs and therefore given the workload we already have > > to specify > solutions > > that do address the core functionality required to interconnect CDNs > > I > do > > not think we should be trying to add more work into that workload as > > it will only distract us from achieving our goal of producing > > deployable solutions within the timeframe we are being told by > > operators they needs solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the > > > CDN > > providers should survive in the existing ecosystem and support the > > media types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. > > Otherwise the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function > > >> of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and > > >> "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure > > >> whether > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is > > >> ", I > > am not sure whether the wording is accurate since generally a CDN > > may claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a > > >> GSM > > phone to a PSTN telephone, the voice stream should be transformed > > from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar > > >> to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content > > delivery > the > > negotiation is done between the User/Client and the Content Provider > > and the CDN is just used to execute/perform the delivery that has > > been negotiated. The CDN is not involved in the decision making of > > what representations the Content Provider decides to offer to the > > User/Client or in what representations the User/Client decides to reque= st. > > > > > >> As for you said selecting media by the "portal", you may see the > > >> way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core > > > function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also > > my interpretation of the scope of the CDNI working group as > > expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting > > usable specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the > > >> DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know > > >> all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but > > >> the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator > > >> since it > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that > > >> may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere > > >> that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the > > >> Requirements > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be > > >> able to > > cope with a scenario where (say) HD/SD conversion is done in the > > dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order > > >> requirement, > > ie we should not worry about it in the initial standards-track work. > > I don't know, did we ever decide whether the Use cases doc is > > restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if > > >> content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to > > >> do > with > > the capabilities & preferences of the CDNs & CSP), rather than > > metadata associated with a particular piece of content. In the > > discussion so far, > I > > think negotiation about static policy stuff is rather out of > > scope(?) > > >> > > >> On security considerations, an interesting question is whether > > >> trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, > > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > > the > dCDN. > > However, i suspect this can get arbitrarily complex - so one > > possibility is to say that we will only handle cases where the trust is= transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > > email address above. Thank you. We monitor our email system, and may > > record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered > > >> in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > > >> Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > > >> Content > > Adaptation (i.e. taking in a content item in one format and > > transforming it to another format or representation) is not a "core" > > function of a > CDN > > which typically delivers the content that is requested without > > explicit knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service > > >> the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of > > the selected content not the component tasked with deciding (or > > applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the > > CDN (e.g. by the "portal" where the user first makes their content > > selection prior to the CDN becoming involved in the delivery of the > > selected content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two > > >>> content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to > > >>> specific > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case > > >>> and > > area to explain the content flexibility is currently a basic > > requirement for CDN service and related negotiation is needed in the > > CDN interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread= . > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic > > >>> Extension > yet > > >>> the third paragraph states the case where a different device is > > >>> used > > in > > >>> the same CDN coverage area. The intent of this use case needs > > >>> to be clarified. Perhaps the use case is trying to address the > > >>> scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content > > >>> from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > > >>> allowed > > to > > >>> distribute the content of CSP-A to User-A; however, not other > > >>> users > in > > >>> the region of the dCDN are allowed to retrieve the content > > >>> unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if > > >>> we're talking about the restrictions on the delivery of specific > > >>> content or the restrictions on the ability of a > > CDN > > >>> to deliver specific content. I certainly understand the case > > >>> where > a > > >>> CSP will restrict the distribution of content to a "managed > > >>> path" if such content is HD while allowing the content > > >>> distribution via an un-managed path if such content is SD (same > > >>> could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but > > >>> not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I > > >>> don't think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, > > >>> I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive > > >>> trust relationship that extends the contract defined in (a) > > >>> above) c. The relationship between the User and dCDN (the > > >>> recognition of > > right > > >>> to download predicated on (b) above) d. The relationship between > > >>> the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. > > >>> The > > user > > >>> is only interested in the transparency and interoperability of > > >>> the security relationship between d-b or d-c to the point that > > >>> the authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly > > >>> defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From richard_woundy@cable.comcast.com Thu Oct 13 08:35:23 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB6C21F8B22 for ; Thu, 13 Oct 2011 08:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.935 X-Spam-Level: X-Spam-Status: No, score=-99.935 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_61=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5cG1DKUA1E6 for ; Thu, 13 Oct 2011 08:35:21 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4E46821F8B1A for ; Thu, 13 Oct 2011 08:35:21 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.57017710; Thu, 13 Oct 2011 09:42:16 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by pacdcexhub03.cable.comcast.com ([fe80::d1dd:b302:b617:3755%11]) with mapi id 14.01.0289.001; Thu, 13 Oct 2011 11:35:04 -0400 From: "Woundy, Richard" To: "grant.watson@bt.com" , "zhouzhipeng@huawei.com" , "kevin.ma@azukisystems.com" , "ben@niven-jenkins.co.uk" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMf6O209+GKyYcRQyFRZpa4NvXN5VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAAF4EAIAAC0mAgAAKLwCAAG2ogIAAGzmAgAAIKgD//+qOkA== Date: Thu, 13 Oct 2011 15:35:04 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136B0DCE@PACDCEXMB05.cable.comcast.com> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245B154@SZXEML519-MBS.china.huawei.com> <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> In-Reply-To: <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.36.134.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 15:35:23 -0000 (Not speaking as working group co-chair) I would agree with Grant's comments below. I believe that CDNI can usefully focus on centralized content adaptation fo= r now, eg encoding, fragmenting, and encryption. Two items that make sense = to push to the edge (and therefore be a consideration for CDNI interfaces) = are session-based encryption and watermarking. There is a technical paper "Unified Content Packaging Architectures for Man= aged Video Content Delivery" for an upcoming SCTE conference that does a go= od job of discussing and analyzing the centralized vs edge topic. Unfortuna= tely, the conference is the same week as IETF 82, and SCTE may charge to ge= t a copy of the paper and presentation. If that does not deter you, see . -- Rich -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of gra= nt.watson@bt.com Sent: Thursday, October 13, 2011 8:41 AM To: zhouzhipeng@huawei.com; kevin.ma@azukisystems.com; ben@niven-jenkins.co= .uk Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi, "May I ask a question, if the content has been encrypted and would not be m= odified in the CDNI process, but the devices in two areas have deployed dif= ferent DRM system, how it will be for the CDNI." Just like it works right now: If objects are encrypted differently or use d= ifferent DRMs generally it translates as separate objects in the CDN, Inter= connected or otherwise. DRM is implemented by the CP, in the knowledge of w= hat end devices and DRM platforms they are delivering to. IMHO that works r= ight now and would work in a CDNI scenario. Frankly, I am even more convinced that this is best left out of scope now. = IMHO duplication of content assets inside the CDN to facilitate cross DRM d= elivery is not a CDNI issue. I can see how this may be optimised perhaps, t= o reduce the amount of assets for example, but again that is not a CDNI iss= ue - the issue exists for both CDN today and Interconnected CDN. g- -----Original Message----- From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] Sent: 13 October 2011 13:12 To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; ben@niven-jenkins.co.= uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Grant, Nice to see your comment. May I conclude that by now the core issue for the content adaptation is " c= ontent protection". As a DRM people for years, I fully understand this concern. In fact the DRM circle have fully understood this concern since DRM should = consider both the protection and the service implementation. May I ask a question, if the content has been encrypted and would not be mo= dified in the CDNI process, but the devices in two areas have deployed diff= erent DRM system, how it will be for the CDNI. It is not related to the content transcoding while you still face the issue= for the protection transformation. For example, how your company's IPTV ma= y connect the FT's terminals. Even in the internet that the PCs in different area may install the same so= ft DRM client, it may still has the problem of the content's duplication an= d content's verification(integrity protection). Take the OMA DRM DCF as an example, each content copy has its unique identi= fier(contentId) and each content copy has its unique Hash value. Hence in OMA DRM system, you( the device) may not duplicate a protected con= tent copy that may be verified successfully by the device. Only the CP that encrypt the content may create a new copy of the content w= ith another identifier. While in CDN system, we all know for the load balancing the CDN should be a= ble to duplicate the hot content when needed. How it may be realized if the= CDN may not create a new content copy that comply with the DRM solution. So you may see, there should be a secure facility within the CDN that may c= reate/encrypt the content which may be accepted by the DRM client. Above is my analysis on this issue. Hope you may take a look at the OMA DRM= specification to check the reason. For any question, I would like to respond as long as I know. Also note that the analysis is not specific to the content adaptation. I me= an only general functionality of CDN. Thanks. Zhipeng -----Original Message----- From: grant.watson@bt.com [mailto:grant.watson@bt.com] Sent: Thursday, October 13, 2011 6:34 PM To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I'd support that perspective. Today CPs, in my experience, sometimes even a= ctively seeks assurances that the content will NOT be modified by the CDN o= r by other downstream processes. So to envisage a CP allowing/wanting that = to happen in a dCDN (that is likely out of their control, perhaps in anothe= r geography and with no quality feedback) feels like a very, very unlikely = scenario. In general the content arrives encrypted and is shipped transpare= ntly, in my experience. Indeed the CPs desire to ship to different devices = / screens etc. is also transparent to the CDN, they're just different objec= ts requested by logic that is out-of-band to the CDN. I know of cases where content is transcoded/modified for mobile access by t= ransparent caching, for example. But TC is not relevant to CDNI. IMHO content adaption/modification/transcoding is not a fundamental issue f= or CDNI. The issues around solving the fundamentals of how to Interconnect = CDN are challenging enough. So I feel we should focus the scope on widely d= eployed use-cases / features and very likely new use-cases that are created= by CDNI. g- -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kev= in J Ma Sent: 13 October 2011 05:02 To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact > is decided by the CP. > Only under the permission, the HD video may be transformed to the > mobile video. i.e. if the CP support both IPTV and mobile video > service, then it may require the CDN to support multiple video > formats. The multi-screen service means the content source is from the > same CP while the target devices/clients include different groups. All > content businesses are under the permission of the content owner. > > For the content protection, I like talk a little more in this email > for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal > and the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and > we do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and > encrypt the content), the content is safe. Whether decrypt/re-encrypt > or just deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a > general scenario that is not related to whether taking content adaptation= . > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only > > repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper > > solution that will be used by the market. > > If the standard may not support the market requirements, it is just > > the problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it > > will bring to the standard. I have repeated it is very simple in > > fact and I > do > > not know whether you have any special concern that will make you > > feel it would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via > > reflector or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by > > > the > > user. > > > The CP may create a special format as required by the user and ask > > > the > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may > > > then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI > > charter) > is > > to focus on what is necessary to interconnect CDNs to deliver > > content > from > > a CSP to an End User that is targeted and deployable within a short > > time frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users > > via multiple CDNs without needing or requiring any CDN supports > > content adaptation). > > > > In my opinion we have enough work to do already without trying to > > expand the scope of our work to include additional requirements that > > do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats > > > on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base > > for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have > > > ever > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are > > > the > core > > functionalities by existing main stream CDNs. Thus we may compare > > and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI > > interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content > > > related > > service. The user and CP only care whether the CDN providers may > > satisfy their requirement while not care the internal process. Just > > as GSM/PSTN interconnection, the user only care successful > > interconnection while not care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 > > > media > > formats. > > > One candidate is your company, another is CDN-X. The users are > > > located > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different > > > format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y > > > may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, > > > absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > > > while > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. > > > Remember > > the price from BBC is same to both your company and CDN-X or BBC > > would select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say > > > it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular > > CDN may wish to implement not a core functionality required to > > enable > content > > delivery between interconnected CDNs. I can think of many > > optimizations that a CDN could implement to differentiate their > > service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not > > a core function required to enable content delivery between > > interconnected CDNs and therefore given the workload we already have > > to specify > solutions > > that do address the core functionality required to interconnect CDNs > > I > do > > not think we should be trying to add more work into that workload as > > it will only distract us from achieving our goal of producing > > deployable solutions within the timeframe we are being told by > > operators they needs solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the > > > CDN > > providers should survive in the existing ecosystem and support the > > media types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. > > Otherwise the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function > > >> of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and > > >> "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure > > >> whether > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is > > >> ", I > > am not sure whether the wording is accurate since generally a CDN > > may claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a > > >> GSM > > phone to a PSTN telephone, the voice stream should be transformed > > from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar > > >> to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content > > delivery > the > > negotiation is done between the User/Client and the Content Provider > > and the CDN is just used to execute/perform the delivery that has > > been negotiated. The CDN is not involved in the decision making of > > what representations the Content Provider decides to offer to the > > User/Client or in what representations the User/Client decides to reque= st. > > > > > >> As for you said selecting media by the "portal", you may see the > > >> way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core > > > function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also > > my interpretation of the scope of the CDNI working group as > > expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting > > usable specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the > > >> DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know > > >> all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but > > >> the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator > > >> since it > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that > > >> may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere > > >> that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the > > >> Requirements > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be > > >> able to > > cope with a scenario where (say) HD/SD conversion is done in the > > dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order > > >> requirement, > > ie we should not worry about it in the initial standards-track work. > > I don't know, did we ever decide whether the Use cases doc is > > restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if > > >> content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to > > >> do > with > > the capabilities & preferences of the CDNs & CSP), rather than > > metadata associated with a particular piece of content. In the > > discussion so far, > I > > think negotiation about static policy stuff is rather out of > > scope(?) > > >> > > >> On security considerations, an interesting question is whether > > >> trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, > > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > > the > dCDN. > > However, i suspect this can get arbitrarily complex - so one > > possibility is to say that we will only handle cases where the trust is= transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > > email address above. Thank you. We monitor our email system, and may > > record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered > > >> in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > > >> Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > > >> Content > > Adaptation (i.e. taking in a content item in one format and > > transforming it to another format or representation) is not a "core" > > function of a > CDN > > which typically delivers the content that is requested without > > explicit knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service > > >> the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of > > the selected content not the component tasked with deciding (or > > applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the > > CDN (e.g. by the "portal" where the user first makes their content > > selection prior to the CDN becoming involved in the delivery of the > > selected content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two > > >>> content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to > > >>> specific > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case > > >>> and > > area to explain the content flexibility is currently a basic > > requirement for CDN service and related negotiation is needed in the > > CDN interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread= . > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic > > >>> Extension > yet > > >>> the third paragraph states the case where a different device is > > >>> used > > in > > >>> the same CDN coverage area. The intent of this use case needs > > >>> to be clarified. Perhaps the use case is trying to address the > > >>> scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content > > >>> from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > > >>> allowed > > to > > >>> distribute the content of CSP-A to User-A; however, not other > > >>> users > in > > >>> the region of the dCDN are allowed to retrieve the content > > >>> unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if > > >>> we're talking about the restrictions on the delivery of specific > > >>> content or the restrictions on the ability of a > > CDN > > >>> to deliver specific content. I certainly understand the case > > >>> where > a > > >>> CSP will restrict the distribution of content to a "managed > > >>> path" if such content is HD while allowing the content > > >>> distribution via an un-managed path if such content is SD (same > > >>> could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but > > >>> not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I > > >>> don't think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, > > >>> I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive > > >>> trust relationship that extends the contract defined in (a) > > >>> above) c. The relationship between the User and dCDN (the > > >>> recognition of > > right > > >>> to download predicated on (b) above) d. The relationship between > > >>> the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. > > >>> The > > user > > >>> is only interested in the transparency and interoperability of > > >>> the security relationship between d-b or d-c to the point that > > >>> the authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly > > >>> defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From saurabh.sdo@gmail.com Thu Oct 13 10:31:10 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EAB21F851A for ; Thu, 13 Oct 2011 10:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KPI0U-6W+cS for ; Thu, 13 Oct 2011 10:31:07 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B486B21F8512 for ; Thu, 13 Oct 2011 10:31:06 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so322347vcb.31 for ; Thu, 13 Oct 2011 10:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ifuhKyLQbHYWZLju72A3wDXDWNYDFkK3IdwVEg0WD/U=; b=jah4lgSPVLBhLUo20mWxFr0BXblAIuO+5b3L2UYan2Ln5mwsO329SvGTIoo+FVGZQz INhRBuCCvvhp+ds0I7ipnVhks+77fE/quBBFAEcJ2kJst9+xxC8C8qbB9vuFwOm8knd8 cIy1la7adJ4E0Oie0+5GrDZl+lSgsBummjIfk= MIME-Version: 1.0 Received: by 10.52.22.9 with SMTP id z9mr4820292vde.59.1318527065948; Thu, 13 Oct 2011 10:31:05 -0700 (PDT) Received: by 10.52.183.39 with HTTP; Thu, 13 Oct 2011 10:31:05 -0700 (PDT) In-Reply-To: <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245B154@SZXEML519-MBS.china.huawei.com> <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> Date: Thu, 13 Oct 2011 23:01:05 +0530 Message-ID: From: Saurabh Chattopadhyay To: grant.watson@bt.com Content-Type: multipart/alternative; boundary=bcaec5014dd764812d04af3181ac Cc: cdni@ietf.org, zhouzhipeng@huawei.com Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 17:31:11 -0000 --bcaec5014dd764812d04af3181ac Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Colleagues, While I=92m also of the opinion that the particular case is best left out o= f scope for now, I think the scoping shall get defined/refined in a more appropriate place, possibly in CDN-I problem statement draft. Following is a relevant part from =91draft-ietf-cdni-problem-statement=92 = =96 =93NSPs have often deployed CDNs as specialized cost-reduction projects within the context of a particular service or environment, some NSPs operate separate CDNs for separate services. For example, there may be a CDN for managed IPTV service delivery, a CDN for web-TV delivery and a CDN for video delivery to Mobile terminals. As NSPs integrate their service portfolio, there is a need for interconnecting these CDNs. Again, NSPs face the problem of lack of open interfaces for CDN interconnection. =94 Unquestionably, primary responsibility of CDN-I is to standardize open interfaces for core content delivery function, however, while the CDNs adop= t the particular Service Profiles, the scope of CDN-I gets naturally extended to interconnect the different service profiles. To clarify, a CDN for Video Delivery to Mobile Terminals, to me is a CDN adopting Service Profile of =91Video Delivery to Mobile Terminals=92. And current discussion on Content Adaptation appears as a particular case for interconnecting CDNs of different Service Profiles. To that end, many aspects of ongoing work will get questioned to realize th= e extent of the interconnection use cases supporting Service Portfolio transformations and whether to be considered part of the current scope or not. IMHO the overall work needs to be staged in a manner that core Content Delivery Function gets the immediate attention, and subsequently the work group shall decide on the relevant part of service profile interconnection to standardize till required extent. Regards, Saurabh On Thu, Oct 13, 2011 at 6:10 PM, wrote: > Hi, > > "May I ask a question, if the content has been encrypted and would not be > modified in the CDNI process, but the devices in two areas have deployed > different DRM system, how it will be for the CDNI." > > Just like it works right now: If objects are encrypted differently or use > different DRMs generally it translates as separate objects in the CDN, > Interconnected or otherwise. DRM is implemented by the CP, in the knowled= ge > of what end devices and DRM platforms they are delivering to. IMHO that > works right now and would work in a CDNI scenario. > > Frankly, I am even more convinced that this is best left out of scope now= . > IMHO duplication of content assets inside the CDN to facilitate cross DRM > delivery is not a CDNI issue. I can see how this may be optimised perhaps= , > to reduce the amount of assets for example, but again that is not a CDNI > issue - the issue exists for both CDN today and Interconnected CDN. > > g- > > > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: 13 October 2011 13:12 > To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; > ben@niven-jenkins.co.uk > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Grant, > Nice to see your comment. > May I conclude that by now the core issue for the content adaptation is " > content protection". > As a DRM people for years, I fully understand this concern. > In fact the DRM circle have fully understood this concern since DRM shoul= d > consider both the protection and the service implementation. > > May I ask a question, if the content has been encrypted and would not be > modified in the CDNI process, but the devices in two areas have deployed > different DRM system, how it will be for the CDNI. > It is not related to the content transcoding while you still face the iss= ue > for the protection transformation. For example, how your company's IPTV m= ay > connect the FT's terminals. > > Even in the internet that the PCs in different area may install the same > soft DRM client, it may still has the problem of the content's duplicatio= n > and content's verification(integrity protection). > Take the OMA DRM DCF as an example, each content copy has its unique > identifier(contentId) and each content copy has its unique Hash value. > Hence in OMA DRM system, you( the device) may not duplicate a protected > content copy that may be verified successfully by the device. > Only the CP that encrypt the content may create a new copy of the content > with another identifier. > > While in CDN system, we all know for the load balancing the CDN should be > able to duplicate the hot content when needed. How it may be realized if = the > CDN may not create a new content copy that comply with the DRM solution. > > So you may see, there should be a secure facility within the CDN that may > create/encrypt the content which may be accepted by the DRM client. > > Above is my analysis on this issue. Hope you may take a look at the OMA D= RM > specification to check the reason. > For any question, I would like to respond as long as I know. > Also note that the analysis is not specific to the content adaptation. I > mean only general functionality of CDN. > Thanks. > Zhipeng > > -----Original Message----- > From: grant.watson@bt.com [mailto:grant.watson@bt.com] > Sent: Thursday, October 13, 2011 6:34 PM > To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > I'd support that perspective. Today CPs, in my experience, sometimes even > actively seeks assurances that the content will NOT be modified by the CD= N > or by other downstream processes. So to envisage a CP allowing/wanting th= at > to happen in a dCDN (that is likely out of their control, perhaps in anot= her > geography and with no quality feedback) feels like a very, very unlikely > scenario. In general the content arrives encrypted and is shipped > transparently, in my experience. Indeed the CPs desire to ship to differe= nt > devices / screens etc. is also transparent to the CDN, they're just > different objects requested by logic that is out-of-band to the CDN. > > I know of cases where content is transcoded/modified for mobile access by > transparent caching, for example. But TC is not relevant to CDNI. > > IMHO content adaption/modification/transcoding is not a fundamental issue > for CDNI. The issues around solving the fundamentals of how to Interconne= ct > CDN are challenging enough. So I feel we should focus the scope on widely > deployed use-cases / features and very likely new use-cases that are crea= ted > by CDNI. > > g- > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Kevin J Ma > Sent: 13 October 2011 05:02 > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > If the CP has tight integration with both CDN providers as you describe > below, I do not see why they would need CDNI at all? What would be the > benefit if they already have custom servers and security? > > Premium content providers that I am familiar with pregenerate content > encodings, run them through rigorous quality control tests, and do > not allow any modifications after that, to guarantee quality. To do > that in a CDN, let alone across CDNs, seems unlikely. Content is > processed in a secure facility and never released unencrypted to the > CDN. The CDN just acts a transparent delivery medium. > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > > Sent: Wednesday, October 12, 2011 11:25 PM > > To: Kevin J Ma; Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Kevin, > > > > As we ever discussed in previous email that the content format in fact > > is decided by the CP. > > Only under the permission, the HD video may be transformed to the > > mobile video. i.e. if the CP support both IPTV and mobile video > > service, then it may require the CDN to support multiple video > > formats. The multi-screen service means the content source is from the > > same CP while the target devices/clients include different groups. All > > content businesses are under the permission of the content owner. > > > > For the content protection, I like talk a little more in this email > > for > > reference: > > Given there are two areas: London and Paris. > > And in these two areas, each has deployed the DRM. Generally each DRM > > implementation is independent. > > If the content is delivered from London to Paris, absolutely the whole > > process should be granted by the CP. > > For the DRM standard, it mainly concern the security on the terminal > > and the interface between the SP/Client. > > You may see that the servers that are granted by the CP is secure and > > we do not need to worry that secure server would be the hacker. > > Hence, if the content is delivered from one server to another server( > > these servers are the equipments granted by CP that may handle and > > encrypt the content), the content is safe. Whether decrypt/re-encrypt > > or just deliver unencrypted content between these two servers are secur= e. > > > > Also, we may see such security issue for content distribution is a > > general scenario that is not related to whether taking content > adaptation. > > > > Thanks. > > Zhipeng > > > > > > > > -----Original Message----- > > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > > Sent: Thursday, October 13, 2011 10:45 AM > > To: ZhouZhipeng; Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > One practical concern to consider with the use case of downloading on= e > > (as opposed to ten) streams is that premium content providers general= ly > > are very concerned with quality control and are unlikely to trust dCD= Ns > > to modify the content, and most likely, the content will be encrypted= ? > > > > thanx. > > > > -- Kevin J. Ma > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > > Of ZhouZhipeng > > > Sent: Wednesday, October 12, 2011 9:51 PM > > > To: Ben Niven-Jenkins > > > Cc: cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Ben, > > > I respect your personal standpoint while seems you are only > > > repeating > > your > > > personal conclusion without new reason/evidence. > > > In my case, I have explained the uCDN may deliver 10 streams to the > > dCDN. > > > But in our reality, we should consider whether it is a proper > > > solution that will be used by the market. > > > If the standard may not support the market requirements, it is just > > > the problem for its deployment. > > > > > > Meanwhile in my feeling you have not carefully thought about how it > > > will bring to the standard. I have repeated it is very simple in > > > fact and I > > do > > > not know whether you have any special concern that will make you > > > feel it would not be able to be done within 18-24 months. > > > Ben, as I repeat, if you have any question, I like respond via > > > reflector or to you individually. > > > Thanks. > > > Zhipeng > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Thursday, October 13, 2011 1:13 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > > > Hello Ben, > > > > The UE may select the content format on the CP web. After that the > > user > > > only desires to get his selected content. > > > > But how the content is transferred to the client is not worried by > > > > the > > > user. > > > > The CP may create a special format as required by the user and ask > > > > the > > > CDN to deliver to user. > > > > While CP may give a HD format content to uCDN and the dCDN may > > > > then > > > transform to the format as the user select. > > > > > > Lots of things may be possible to do and CDN providers offer many > > > additional services on top of the "core" service of content delivery. > > > However, our objective (based on my interpretation of the CDNI > > > charter) > > is > > > to focus on what is necessary to interconnect CDNs to deliver > > > content > > from > > > a CSP to an End User that is targeted and deployable within a short > > > time frame (18-24 months). > > > > > > Content transformation/adaptation is not an essential requirement in > > order > > > to achieve that aim (we can deliver content from CSPs to End Users > > > via multiple CDNs without needing or requiring any CDN supports > > > content adaptation). > > > > > > In my opinion we have enough work to do already without trying to > > > expand the scope of our work to include additional requirements that > > > do not > > help > > > us address our core objectives as laid out in the CDNI charter. > > > > > > > In this case, it is nothing related to how the user select formats > > > > on > > CP > > > website. > > > > So, it is the CP and user to decide the content format not the > > CDN(your > > > assert is not correct and seems you take that assert as your base > > > for > > the > > > discussion). > > > > > > > > As for "the core CDN functionality offered by CDNs today", I have > > > > ever > > > raised an email before that your company's webpage has claimed > > supporting > > > media transformation and multi-screen service. > > > > Perhaps, I like asking you list some features that you feel are > > > > the > > core > > > functionalities by existing main stream CDNs. Thus we may compare > > > and > > take > > > deep look. > > > > > > I think the core functionality maps pretty well to the CDNI > > > interfaces, > > > namely: Request Routing, Metadata configuration, log production and > > > control plus content acquisition and content delivery. > > > > > > > I guess many people have the experience/knowledge of content > > > > related > > > service. The user and CP only care whether the CDN providers may > > > satisfy their requirement while not care the internal process. Just > > > as GSM/PSTN interconnection, the user only care successful > > > interconnection while not care how the voice is transformed in proces= s. > > > > > > > > Besides, I like raise a case: > > > > Given currently BBC recruits CDN providers that may support 10 > > > > media > > > formats. > > > > One candidate is your company, another is CDN-X. The users are > > > > located > > > in France. > > > > So both your company and CDN-X should connect a France CDN > > provider(CDN- > > > Y). > > > > If your company's solution is to send 10 streams of different > > > > format > > of > > > one content to CDN-Y; > > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y > > > > may > > > conduct some adaptation. > > > > Comparing these two solutions, for your company and CDN-X, > > > > absolutely > > > the cost of CDN-X is much lower. > > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > > > > while > > > in solution-2, it should only receive 1 stream but need to take > > > transformation to output 10 streams. > > > > > > > > Which solution is more competitive. it is Solution 1, right. > > > > Remember > > > the price from BBC is same to both your company and CDN-X or BBC > > > would select one CDN provider with the lower price. > > > > If a CDN provider may not get the contract from CP, how it may say > > > > it > > is > > > not a core functionality. > > > > > > What you are describing is a possible optimization that a particular > > > CDN may wish to implement not a core functionality required to > > > enable > > content > > > delivery between interconnected CDNs. I can think of many > > > optimizations that a CDN could implement to differentiate their > > > service but the > > internal > > > workings of an individual CDN are out of scope of our charter. > > > > > > So to repeat my position for a final time: Content adaptation is not > > > a core function required to enable content delivery between > > > interconnected CDNs and therefore given the workload we already have > > > to specify > > solutions > > > that do address the core functionality required to interconnect CDNs > > > I > > do > > > not think we should be trying to add more work into that workload as > > > it will only distract us from achieving our goal of producing > > > deployable solutions within the timeframe we are being told by > > > operators they needs solutions within. > > > > > > Ben > > > > > > > So, if we all realize that currently the media type is rich, the > > > > CDN > > > providers should survive in the existing ecosystem and support the > > > media types as required by the market. > > > > > > > > Back to the case of GSM/G.711, it just when concerning the > > > interconnection, the transformation should at once be solved. > > > Otherwise the interconnection may not be operated. > > > > > > > > Br, > > > > Zhipeng > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > > To: ZhouZhipeng > > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > > > Zhipeng, > > > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > > > >> Ben and Philip, > > > >> I like to respond your concern in this one email: > > > >> > > > >> Ben, > > > >> I feel what we are now discussing is what is the "core" function > > > >> of > > > CDN. > > > >> As you say, CDN is used to deliver content. That is absolutely > > correct > > > that the delivery capability is the core requirement for CDN system. > > > >> While CDN is used to provide the content delivery service. > > > >> What means service. It should include "time" "location" and > > > >> "media > > > type", etc. These features are all the core feature for a service. > > > >> If we only concern "delivering one data block", I am not sure > > > >> whether > > > the issues such as "logging" "geographic constraint" are the core of > > CDN. > > > >> > > > >> For "without explicit knowledge of what that content actually is > > > >> ", I > > > am not sure whether the wording is accurate since generally a CDN > > > may claim it support different medias. > > > >> By this opportunity, I like to share a use case: a call from a > > > >> GSM > > > phone to a PSTN telephone, the voice stream should be transformed > > > from > > GSM > > > voice to G.711. > > > >> For the user, he does not need to know what type of data has been > > > transferred, but the operator has done some work to interconnect two > > > systems, right. > > > >> I like to know whether you may accept that my use case is similar > > > >> to > > > this case above. > > > > > > > > I don't think your use case is similar to the analogy of mobile > > networks > > > being interconnected to PSTN networks. In the case of content > > > delivery > > the > > > negotiation is done between the User/Client and the Content Provider > > > and the CDN is just used to execute/perform the delivery that has > > > been negotiated. The CDN is not involved in the decision making of > > > what representations the Content Provider decides to offer to the > > > User/Client or in what representations the User/Client decides to > request. > > > > > > > >> As for you said selecting media by the "portal", you may see the > > > >> way > > " > > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > > delivers one media stream to dCDN and dCDN takes some adaptation to > > > support multiple media types". > > > > > > > > Now what you're talking about is an optimisation, not a core > > > > function > > > required to actually deliver the content (and report, bill, etc. for > > that > > > delivery). > > > > > > > > My position is that we should focus on how to enable the > > interconnection > > > of the core CDN functionality offered by CDNs today (which is also > > > my interpretation of the scope of the CDNI working group as > > > expressed in > > its > > > charter) because doing so is a significant piece of work in itself. > > Let's > > > not start trying to add in additional functionality beyond what the > > > majority of CDNs support today as that will just delay us getting > > > usable specifications into the market in a timely fashion IMO. > > > > > > > > Ben > > > > > > > >> A good question is "security" since I have done six years on the > > > >> DRM > > > and like to promote the DRM all around the world:) > > > >> If the content is needed to be protected, generally you may know > > > >> all > > > the systems should be granted by the content owner. > > > >> Here I also like to clarify that not only the media itself but > > > >> the > > > information related to service itself (such as the geographic > > constraint) > > > should be protected also. > > > >> So, trust is not a problem for the media. > > > >> > > > >> Philip, > > > >> Thank you that you feel Content Adaption is an issue for > > "Requirements" > > > but I do not know why it is not for Use case. > > > >> I like to clarify to U that it is important for you operator > > > >> since it > > > may save investment if the system may support different services. > > > >> For us vendor, we are happy operator may install a system for the > > > mobile service and another system for the FBB service. > > > >> But the reality is all operators ask us to provide a system that > > > >> may > > > support different service systems. > > > >> > > > >> Frankly, Ben and Philip, I remember I have explained somewhere > > > >> that > > to > > > implement this is rather simple . > > > >> At least the Use case and Requirement are informational to be > > referred > > > in future work. So I do really feel you may accept it. > > > >> Of course I like to respond your more concern and comments. > > > >> Thanks. > > > >> Zhipeng > > > >> > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > > >> Sent: Monday, October 10, 2011 11:22 PM > > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > > >> Cc: cdni@ietf.org > > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > >> > > > >> Ben, Zhipeng, all, > > > >> > > > >> I think that Content Adaptation is more an issue for the > > > >> Requirements > > > doc than for the Use cases draft. > > > >> > > > >> The key question is whether we want the CDNI interfaces to be > > > >> able to > > > cope with a scenario where (say) HD/SD conversion is done in the > > > dCDN & > > to > > > signal about this. > > > >> > > > >> I think that coping with this scenario is a second order > > > >> requirement, > > > ie we should not worry about it in the initial standards-track work. > > > I don't know, did we ever decide whether the Use cases doc is > > > restricted > > to > > > "initial" scenarios, or whether it's all-encompassing, ie covering > > > "future" scenarios as well? > > > >> > > > >> Scott, > > > >> Reading some of your examples, they seem to be valid even if > > > >> content > > > adaptation (HD/SD) is out of scope. > > > >> - a dCDN might for some reason be unwilling to distribute HD? > > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation= ? > > > >> But these sorts of examples seem to be static policy things (to > > > >> do > > with > > > the capabilities & preferences of the CDNs & CSP), rather than > > > metadata associated with a particular piece of content. In the > > > discussion so far, > > I > > > think negotiation about static policy stuff is rather out of > > > scope(?) > > > >> > > > >> On security considerations, an interesting question is whether > > > >> trust > > is > > > transitive. Don't think it need be - just because CSP trusts uCDN, > > > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > > > the > > dCDN. > > > However, i suspect this can get arbitrarily complex - so one > > > possibility is to say that we will only handle cases where the trust = is > transitive. > > > >> > > > >> Best wishes > > > >> phil > > > >> > > > >> > > > >> Philip Eardley > > > >> Research and Technology Strategy > > > >> > > > >> This email contains BT information, which may be privileged or > > > confidential. It's meant only for the individual(s) or entity named > > above. > > > If you're not the intended recipient, note that disclosing, copying, > > > distributing or using this information is prohibited. If you've > > > received this email in error, please let me know immediately on the > > > email address above. Thank you. We monitor our email system, and may > > > record your > > emails. > > > >> British Telecommunications plc > > > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered > > > >> in England no: 1800000 > > > >> > > > >> > > > >> -----Original Message----- > > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > > > >> Behalf > > Of > > > Ben Niven-Jenkins > > > >> Sent: 10 October 2011 12:04 > > > >> To: ZhouZhipeng > > > >> Cc: cdni@ietf.org > > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > >> > > > >> Colleagues, > > > >> > > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > > > >> Content > > > Adaptation (i.e. taking in a content item in one format and > > > transforming it to another format or representation) is not a "core" > > > function of a > > CDN > > > which typically delivers the content that is requested without > > > explicit knowledge of what that content actually is. > > > >> > > > >> Let's not forget that in building an end to end content service > > > >> the > > CDN > > > is only one component and is the component tasked with executing the > > > delivery of a specific representation (version/copy/format etc.) of > > > the selected content not the component tasked with deciding (or > > > applying > > > policy) on which version/copy/representation of content should be > > > delivered. > > > >> > > > >> The decision as to which version/copy/representation to offer and > > allow > > > to be delivered to a given device/user is implemented outside of the > > > CDN (e.g. by the "portal" where the user first makes their content > > > selection prior to the CDN becoming involved in the delivery of the > > > selected content). > > > >> > > > >> Ben > > > >> > > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > > >> > > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > > description on the use case of HD and SD is not exactly correct. > > > >>> If one movie has two formats of HD and SD, then we have two > > > >>> content > > > with different identifier. In DRM scope, the basic unit is a content > > copy. > > > >>> > > > >>> Here the first bullet "a subset of encodings deliverable to > > > >>> specific > > > devices," has listed the case of content adaptation. > > > >>> In last month, I have contacted the Authors of this document and > > taken > > > some email exchanges with Grant and Philip (BT). > > > >>> I have shown BT with some information that I know in this case > > > >>> and > > > area to explain the content flexibility is currently a basic > > > requirement for CDN service and related negotiation is needed in the > > > CDN interconnection. > > > >>> Meanwhile, I should also invite you in this group raising your > > > comments or questions on this case since I hope my use case may be > > > incorporated in the use case draft. > > > >>> > > > >>> If you have any more question or comments, pls share in this > thread. > > > >>> Thanks. > > > >>> Zhipeng > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> -----Original Message----- > > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > > >>> Sent: Friday, September 30, 2011 8:02 AM > > > >>> To: cdni@ietf.org > > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > >>> > > > >>> Section 2.3 Nomadic Users > > > >>> This description falls under the category of Geographic > > > >>> Extension > > yet > > > >>> the third paragraph states the case where a different device is > > > >>> used > > > in > > > >>> the same CDN coverage area. The intent of this use case needs > > > >>> to be clarified. Perhaps the use case is trying to address the > > > >>> scenario > > > where > > > >>> a Nomadic User-A with an agreement allowing access to content > > > >>> from > > > CSP-A > > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > > > >>> allowed > > > to > > > >>> distribute the content of CSP-A to User-A; however, not other > > > >>> users > > in > > > >>> the region of the dCDN are allowed to retrieve the content > > > >>> unless > > they > > > >>> too have such an agreement. > > > >>> > > > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if > > > >>> we're talking about the restrictions on the delivery of specific > > > >>> content or the restrictions on the ability of a > > > CDN > > > >>> to deliver specific content. I certainly understand the case > > > >>> where > > a > > > >>> CSP will restrict the distribution of content to a "managed > > > >>> path" if such content is HD while allowing the content > > > >>> distribution via an un-managed path if such content is SD (same > > > >>> could apply to > > encryption > > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > > have > > > >>> its own restrictions of blocking the distribution of HD content > > while > > > >>> allowing the distribution of SD content. > > > >>> > > > >>> o first bullet makes sense if the dCDN can perform a subset of > > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but > > > >>> not > > > DASH) > > > >>> o second bullet makes sense where the dCDN doesn't want to offer > > high > > > >>> bit-rate variants of the media > > > >>> o third bullet make sense if the policy addresses QoE but I > > > >>> don't think subscriber rights/authorizations apply. > > > >>> > > > >>> Section 10 Security Considerations > > > >>> > > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, > > > >>> I > > > think > > > >>> we can describe this in four contexts: > > > >>> > > > >>> a. The relationship between the CSP and the uCDN (the principle > > > contract > > > >>> arrangement for distribution) > > > >>> b. The relationship between the uCDN and dCDN (the transitive > > > >>> trust relationship that extends the contract defined in (a) > > > >>> above) c. The relationship between the User and dCDN (the > > > >>> recognition of > > > right > > > >>> to download predicated on (b) above) d. The relationship between > > > >>> the User and CSP (the contract > > authorizing > > > >>> the user access to the content) > > > >>> > > > >>> The user is not interested in the a-b nor the b-c relationship. > > > >>> The > > > user > > > >>> is only interested in the transparency and interoperability of > > > >>> the security relationship between d-b or d-c to the point that > > > >>> the authorization granted in d-a is viable when the delivery is > > initiated > > > >>> via either d-b or d-c. As an example, the uCDN might use URL > > appended > > > >>> tokens for authentication while dCDN might use URL appended hashe= s. > > > The > > > >>> user doesn't want to know about the distinct methods, but > > transparency > > > >>> is only afforded if the methods are interoperable clearly > > > >>> defined > > when > > > >>> the delegation for content delivery is executed. Clearly, the > > choice > > > of > > > >>> authentication method is determined by the respective CDN's. > > > >>> > > > >>> Scott > > > >>> > > > >>> _______________________________________________ > > > >>> CDNi mailing list > > > >>> CDNi@ietf.org > > > >>> https://www.ietf.org/mailman/listinfo/cdni > > > >> > > > >> _______________________________________________ > > > >> CDNi mailing list > > > >> CDNi@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --bcaec5014dd764812d04af3181ac Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Colleagues,

While I=92m also of the opinion that the particular case is be= st left out of scope for now, I think the scoping shall get defined/refined= in a more appropriate place, possibly in CDN-I problem statement draft.

Following is a relevant part from =91draft-ietf-cdni-problem-s= tatement=92 =96

=93NSPs have often deployed CDNs as specialized cost-reduction projects

=A0=A0 = within the context of a particular service or environment, some NSPs=

=A0=A0 = operate separate CDNs for separate services.=A0 For example, there may

=A0=A0 = be a CDN for managed IPTV service delivery, a CDN for web-TV deliver= y

=A0=A0 = and a CDN for video delivery to Mobile terminals.=A0 As NSPs integrate

=A0=A0 = their service portfolio, there is a need for interconnecting these

=A0=A0 = CDNs.=A0 Again, NSPs face t= he problem of lack of open interfaces for

=A0=A0 = CDN interconnection.

=94

Unquestionably, primary responsibility of CDN-I is to standard= ize open interfaces for core content delivery function, however, while the = CDNs adopt the particular Service Profiles, the scope of CDN-I gets natural= ly extended to interconnect the different service profiles. To clarify, a C= DN for=A0Video Delivery to Mobile Terminals, to me is a CDN adopting Servic= e Profile of =91Video Delivery to Mobile Terminals=92. And current discussi= on on Content Adaptation appears as a particular case for interconnecting C= DNs of different Service Profiles.

To that end, many aspects of ongoing work will get questioned = to realize the extent of the interconnection use cases supporting Service P= ortfolio transformations and whether to be considered part of the current s= cope or not.

IMHO the overall work needs to be staged in a manner that core= Content Delivery Function gets the immediate attention, and subsequently t= he work group shall decide on the relevant part of service profile intercon= nection to standardize till required extent.

Regards,

Saurabh


=A0
On Thu, Oct 13, 2011 at 6:10 PM, <grant.watson@bt.com> wrote:
Hi,

"May I ask a question, if the content has been e= ncrypted and would not be modified in the CDNI process, but the devices in = two areas have deployed different DRM system, how it will be for the CDNI.&= quot;

Just like it works right now: If objects are encrypted differentl= y or use different DRMs generally it translates as separate objects in the = CDN, Interconnected or otherwise. DRM is implemented by the CP, in the know= ledge of what end devices and DRM platforms they are delivering to. IMHO th= at works right now and would work in a CDNI scenario.

Frankly, I am even more convinced that this is best left out of scope n= ow. IMHO duplication of content assets inside the CDN to facilitate cross D= RM delivery is not a CDNI issue. I can see how this may be optimised perhap= s, to reduce the amount of assets for example, but again that is not a CDNI= issue - the issue exists for both CDN today and Interconnected CDN.

g-


-----Original Message-----
From: ZhouZhipeng [= mailto:zhouzhipeng@huawei.com= ]
Sent: 13 October 2011 13:12
To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk
Cc: cdni@ietf.org
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Gra= nt,
Nice to see your comment.
May I conclude that by now the core iss= ue for the content adaptation is " content protection".
As a D= RM people for years, I fully understand this concern.
In fact the DRM circle have fully understood this concern since DRM should = consider both the protection and the service implementation.

May I a= sk a question, if the content has been encrypted and would not be modified = in the CDNI process, but the devices in two areas have deployed different D= RM system, how it will be for the CDNI.
It is not related to the content transcoding while you still face the issue= for the protection transformation. For example, how your company's IPT= V may connect the FT's terminals.

Even in the internet that the = PCs in different area may install the same soft DRM client, it may still ha= s the problem of the content's duplication and content's verificati= on(integrity protection).
Take the OMA DRM DCF as an example, each content copy has its unique identi= fier(contentId) and each content copy has its unique Hash value.
Hence i= n OMA DRM system, you( the device) may not duplicate a protected content co= py that may be verified successfully by the device.
Only the CP that encrypt the content may create a new copy of the content w= ith another identifier.

While in CDN system, we all know for the loa= d balancing the CDN should be able to duplicate the hot content when needed= . How it may be realized if the CDN may not create a new content copy that = comply with the DRM solution.

So you may see, there should be a secure facility within the CDN that m= ay create/encrypt the content which may be accepted by the DRM client.
<= br>Above is my analysis on this issue. Hope you may take a look at the OMA = DRM specification to check the reason.
For any question, I would like to respond as long as I know.
Also note t= hat the analysis is not specific to the content adaptation. I mean only gen= eral functionality of CDN.
Thanks.
Zhipeng

-----Original Messa= ge-----
From: grant.watson@bt.com [mailt= o:grant.watson@bt.com]
Sent: = Thursday, October 13, 2011 6:34 PM
To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk
Cc: cdni@ietf.org
Subject: RE: [CDN= i] I-D Action: draft-ietf-cdni-use-cases-00.txt

I'd support that= perspective. Today CPs, in my experience, sometimes even actively seeks as= surances that the content will NOT be modified by the CDN or by other downs= tream processes. So to envisage a CP allowing/wanting that to happen in a d= CDN (that is likely out of their control, perhaps in another geography and = with no quality feedback) feels like a very, very unlikely scenario. In gen= eral the content arrives encrypted and is shipped transparently, in my expe= rience. Indeed the CPs desire to ship to different devices / screens etc. i= s also transparent to the CDN, they're just different objects requested= by logic that is out-of-band to the CDN.

I know of cases where content is transcoded/modified for mobile access = by transparent caching, for example. But TC is not relevant to CDNI.
IMHO content adaption/modification/transcoding is not a fundamental issue = for CDNI. The issues around solving the fundamentals of how to Interconnect= CDN are challenging enough. So I feel we should focus the scope on widely = deployed use-cases / features and very likely new use-cases that are create= d by CDNI.

g-

-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma
Sent:= 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: = cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-ca= ses-00.txt

Zhipeng,

=A0If the CP has tight integration with b= oth CDN providers as you describe
=A0below, I do not see why they would need CDNI at all? =A0What would be th= e
=A0benefit if they already have custom servers and security?

= =A0Premium content providers that I am familiar with pregenerate content=A0encodings, run them through rigorous quality control tests, and do
=A0not allow any modifications after that, to guarantee quality. =A0To do=A0that in a CDN, let alone across CDNs, seems unlikely. =A0Content is=A0processed in a secure facility and never released unencrypted to the=A0CDN. =A0The CDN just acts a transparent delivery medium.

thanx.

-- =A0Kevin J. Ma

> -----Original Message-----<= br>> From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com]
> Sent: Wednesday, October 12, 2011 11:2= 5 PM
> To: Kevin J Ma; Ben Niven-Jenkins
> Cc: cdni@ietf.org
> Subject: RE: [CDNi] I-D Action: draft-ie= tf-cdni-use-cases-00.txt
>
> Kevin,
>
> As we ever = discussed in previous email that the content format in fact
> is decided by the CP.
> Only under the permission, the HD video = may be transformed to the
> mobile video. i.e. if the CP support both= IPTV and mobile video
> service, then it may require the CDN to supp= ort multiple video
> formats. The multi-screen service means the content source is from the=
> same CP while the target devices/clients include different groups.= All
> content businesses are under the permission of the content own= er.
>
> For the content protection, I like talk a little more in this = email
> for
> reference:
> Given there are two areas: Lon= don and Paris.
> And in these two areas, each has deployed the DRM. G= enerally each DRM
> implementation is independent.
> If the content is delivered fro= m London to Paris, absolutely the whole
> process should be granted b= y the CP.
> For the DRM standard, it mainly concern the security on t= he terminal
> and the interface between the SP/Client.
> You may see that the = servers that are granted by the CP is secure and
> we do not need to = worry that secure server would be the hacker.
> Hence, if the content= is delivered from one server to another server(
> these servers are the equipments granted by CP that may handle and
= > encrypt the content), the content is safe. Whether decrypt/re-encrypt<= br>> or just deliver unencrypted content between these two servers are s= ecure.
>
> Also, we may see such security issue for content distribution = is a
> general scenario that is not related to whether taking content= adaptation.
>
> Thanks.
> Zhipeng
>
>
>
> -----Original Message-----
> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]> Sent: Thursday, October 13, 2011 10:45 AM
> To: ZhouZhipeng; B= en Niven-Jenkins
> Cc: cdni@ietf.org
> Subject= : RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Z= hipeng,
>
> =A0 One practical concern to consider with the use = case of downloading one
> =A0 (as opposed to ten) streams is that premium content providers gene= rally
> =A0 are very concerned with quality control and are unlikely = to trust dCDNs
> =A0 to modify the content, and most likely, the cont= ent will be encrypted?
>
> thanx.
>
> -- =A0Kevin J. Ma
>
> > = -----Original Message-----
> > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf
> > Of ZhouZhipeng
> > Sent: Wednesday, October 12, 2011 9:5= 1 PM
> > To: Ben Niven-Jenkins
> > Cc: cdni@ietf.org
> > Subject: Re: [CDNi] I-D Actio= n: draft-ietf-cdni-use-cases-00.txt
> >
> > Ben,
> > I respect your personal standpoint= while seems you are only
> > repeating
> your
> > = personal conclusion without new reason/evidence.
> > In my case, I= have explained the uCDN may deliver 10 streams to the
> dCDN.
> > But in our reality, we should consider whether it i= s a proper
> > solution that will be used by the market.
> &= gt; If the standard may not support the market requirements, it is just
> > the problem for its deployment.
> >
> > Meanwhi= le in my feeling you have not carefully thought about how it
> > w= ill bring to the standard. I have repeated it is very simple in
> >= ; fact and I
> do
> > not know whether you have any special concern that wil= l make you
> > feel it would not be able to be done within 18-24 m= onths.
> > Ben, as I repeat, if you have any question, I like resp= ond via
> > reflector or to you individually.
> > Thanks.
> &g= t; Zhipeng
> >
> > -----Original Message-----
> >= ; From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> > Sent: Thursday, October 13, 2011 1:13 AM
> > To: ZhouZhi= peng
> > Cc: philip.eardl= ey@bt.com; cdni@ietf.org
> &= gt; Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> >
> > Zhipeng,
> >
> > On 12 Oct 2011, a= t 10:22, ZhouZhipeng wrote:
> >
> > > Hello Ben,
&g= t; > > The UE may select the content format on the CP web. After that= the
> user
> > only desires to get his selected content.
> &g= t; > But how the content is transferred to the client is not worried by<= br>> > > the
> > user.
> > > The CP may creat= e a special format as required by the user and ask
> > > the
> > CDN to deliver to user.
> > > W= hile CP may give a HD format content to uCDN and the dCDN may
> > = > then
> > transform to the format as the user select.
> = >
> > Lots of things may be possible to do and CDN providers offer many=
> > additional services on top of the "core" service of= content delivery.
> > However, our objective (based on my interpr= etation of the CDNI
> > charter)
> is
> > to focus on what is necessary to= interconnect CDNs to deliver
> > content
> from
> >= ; a CSP to an End User that is targeted and deployable within a short
> > time frame (18-24 months).
> >
> > Content tran= sformation/adaptation is not an essential requirement in
> order
&= gt; > to achieve that aim (we can deliver content from CSPs to End Users=
> > via multiple CDNs without needing or requiring any CDN supports> > content adaptation).
> >
> > In my opinion we= have enough work to do already without trying to
> > expand the s= cope of our work to include additional requirements that
> > do not
> help
> > us address our core objectives a= s laid out in the CDNI charter.
> >
> > > In this case= , it is nothing related to how the user select formats
> > > on=
> CP
> > website.
> > > So, it is the CP and user t= o decide the content format not the
> CDN(your
> > assert is= not correct and seems you take that assert as your base
> > for > the
> > discussion).
> > >
> > > As f= or "the core CDN functionality offered by CDNs today", I have
= > > > ever
> > raised an email before that your company&#= 39;s webpage has claimed
> supporting
> > media transformation and multi-screen service.=
> > > Perhaps, I like asking you list some features that you f= eel are
> > > the
> core
> > functionalities by = existing main stream CDNs. Thus we may compare
> > and
> take
> > deep look.
> >
> >= ; I think the core functionality maps pretty well to the CDNI
> > = interfaces,
> > namely: Request Routing, Metadata configuration, l= og production and
> > control plus content acquisition and content delivery.
> &g= t;
> > > I guess many people have the experience/knowledge of c= ontent
> > > related
> > service. The user and CP only= care whether the CDN providers may
> > satisfy their requirement while not care the internal process. Ju= st
> > as GSM/PSTN interconnection, the user only care successful<= br>> > interconnection while not care how the voice is transformed in= process.
> > >
> > > Besides, I like raise a case:
> >= > Given currently BBC recruits CDN providers that may support 10
>= ; > > media
> > formats.
> > > One candidate is = your company, another is CDN-X. The users are
> > > located
> > in France.
> > > So both yo= ur company and CDN-X should connect a France CDN
> provider(CDN-
&= gt; > Y).
> > > If your company's solution is to send 10= streams of different
> > > format
> of
> > one content to CDN-Y;
>= > > While CDN-X's solution is to send 1 stream to CDN-Y while CD= N-Y
> > > may
> > conduct some adaptation.
> >= ; > Comparing these two solutions, for your company and CDN-X,
> > > absolutely
> > the cost of CDN-X is much lower.
= > > > For CDN-Y, in solution-1, it should receive/forward 10 strea= ms ;
> > > while
> > in solution-2, it should only rec= eive 1 stream but need to take
> > transformation to output 10 streams.
> > >
> &g= t; > Which solution is more competitive. it is Solution 1, right.
>= ; > > Remember
> > the price from BBC is same to both your c= ompany and CDN-X or BBC
> > would select one CDN provider with the lower price.
> > = > If a CDN provider may not get the contract from CP, how it may say
= > > > it
> is
> > not a core functionality.
> >
> > What you are describing is a possible optimization t= hat a particular
> > CDN may wish to implement not a core function= ality required to
> > enable
> content
> > delivery= between interconnected CDNs. I can think of many
> > optimizations that a CDN could implement to differentiate their> > service but the
> internal
> > workings of an in= dividual CDN are out of scope of our charter.
> >
> > So = to repeat my position for a final time: Content adaptation is not
> > a core function required to enable content delivery between
&g= t; > interconnected CDNs and therefore given the workload we already hav= e
> > to specify
> solutions
> > that do address th= e core functionality required to interconnect CDNs
> > I
> do
> > not think we should be trying to add mo= re work into that workload as
> > it will only distract us from ac= hieving our goal of producing
> > deployable solutions within the = timeframe we are being told by
> > operators they needs solutions within.
> >
> > = Ben
> >
> > > So, if we all realize that currently the= media type is rich, the
> > > CDN
> > providers shoul= d survive in the existing ecosystem and support the
> > media types as required by the market.
> > >
> = > > Back to the case of GSM/G.711, it just when concerning the
>= ; > interconnection, the transformation should at once be solved.
> > Otherwise the interconnection may not be operated.
> > &= gt;
> > > Br,
> > > Zhipeng
> > >
&g= t; > >
> > >
> > >
> > > -----Ori= ginal Message-----
> > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> > > Sent: Wednesd= ay, October 12, 2011 12:19 AM
> > > To: ZhouZhipeng
> >= ; > Cc: philip.eardley@bt.com; cdni@ietf.org
> > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00= .txt
> > >
> > > Zhipeng,
> > >
>= > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote:
> > > > > >> Ben and Philip,
> > >> I like to respond = your concern in this one email:
> > >>
> > >>= Ben,
> > >> I feel what we are now discussing is what is th= e "core" function
> > >> of
> > CDN.
> > >> As you say, C= DN is used to deliver content. That is absolutely
> correct
> &= gt; that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery servic= e.
> > >> What means service. It should include "time&q= uot; "location" and
> > >> "media
> >= ; type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block"= , I am not sure
> > >> whether
> > the issues such = as "logging" "geographic constraint" are the core of > CDN.
> > >>
> > >> For "without exp= licit knowledge of what that content actually is
> > >> &quo= t;, I
> > am not sure whether the wording is accurate since genera= lly a CDN
> > may claim it support different medias.
> > >> By t= his opportunity, I like to share a use case: a call from a
> > >= ;> GSM
> > phone to a PSTN telephone, the voice stream should b= e transformed
> > from
> GSM
> > voice to G.711.
> > >&g= t; For the user, he does not need to know what type of data has been
>= ; > transferred, but the operator has done some work to interconnect two=
> > systems, right.
> > >> I like to know whether you = may accept that my use case is similar
> > >> to
> >= ; this case above.
> > >
> > > I don't think yo= ur use case is similar to the analogy of mobile
> networks
> > being interconnected to PSTN networks. In the ca= se of content
> > delivery
> the
> > negotiation is= done between the User/Client and the Content Provider
> > and the= CDN is just used to execute/perform the delivery that has
> > been negotiated. The CDN is not involved in the decision making o= f
> > what representations the Content Provider decides to offer t= o the
> > User/Client or in what representations the User/Client d= ecides to request.
> > >
> > >> As for you said selecting media by the= "portal", you may see the
> > >> way
> &quo= t;
> > uCDN delivers multiple media streams to dCDN" is not g= ood than "uCDN
> > delivers one media stream to dCDN and dCDN takes some adaptation = to
> > support multiple media types".
> > >
&g= t; > > Now what you're talking about is an optimisation, not a co= re
> > > function
> > required to actually deliver the conte= nt (and report, bill, etc. for
> that
> > delivery).
>= > >
> > > My position is that we should focus on how to = enable the
> interconnection
> > of the core CDN functionality offered by = CDNs today (which is also
> > my interpretation of the scope of th= e CDNI working group as
> > expressed in
> its
> > = charter) because doing so is a significant piece of work in itself.
> Let's
> > not start trying to add in additional functiona= lity beyond what the
> > majority of CDNs support today as that wi= ll just delay us getting
> > usable specifications into the market= in a timely fashion IMO.
> > >
> > > Ben
> > >
> > >>= ; A good question is "security" since I have done six years on th= e
> > >> DRM
> > and like to promote the DRM all ar= ound the world:)
> > >> If the content is needed to be protected, generally you = may know
> > >> all
> > the systems should be grant= ed by the content owner.
> > >> Here I also like to clarify = that not only the media itself but
> > >> the
> > information related to service itself (= such as the geographic
> constraint)
> > should be protected= also.
> > >> So, trust is not a problem for the media.
> > >>
> > >> Philip,
> > >> Than= k you that you feel Content Adaption is an issue for
> "Requirem= ents"
> > but I do not know why it is not for Use case.
> > >> I like to clarify to U that it is important for you oper= ator
> > >> since it
> > may save investment if the= system may support different services.
> > >> For us vendor= , we are happy operator may install a system for the
> > mobile service and another system for the FBB service.
> &g= t; >> But the reality is all operators ask us to provide a system tha= t
> > >> may
> > support different service systems.=
> > >>
> > >> Frankly, Ben and Philip, I remembe= r I have explained somewhere
> > >> that
> to
> = > implement this is rather simple .
> > >> At least the U= se case and Requirement are informational to be
> referred
> > in future work. So I do really feel you may acce= pt it.
> > >> Of course I like to respond your more concern = and comments.
> > >> Thanks.
> > >> Zhipeng > > >>
> > >>
> > >>
> >= >> -----Original Message-----
> > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
> > >> Sent: Monday, October 10, 2011 11:22 PM
> > >= ;> To: ben@niven-jenkins.co.u= k; ZhouZhipeng
> > >> Cc: cdni@ietf.org
> > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-case= s-00.txt
> > >>
> > >> Ben, Zhipeng, all,
= > > >>
> > >> I think that Content Adaptation is= more an issue for the
> > >> Requirements
> > doc than for the Use cases dra= ft.
> > >>
> > >> The key question is whether= we want the CDNI interfaces to be
> > >> able to
> &g= t; cope with a scenario where (say) HD/SD conversion is done in the
> > dCDN &
> to
> > signal about this.
> >= ; >>
> > >> I think that coping with this scenario is = a second order
> > >> requirement,
> > ie we should= not worry about it in the initial standards-track work.
> > I don't know, did we ever decide whether the Use cases doc is=
> > restricted
> to
> > "initial" scenar= ios, or whether it's all-encompassing, ie covering
> > "f= uture" scenarios as well?
> > >>
> > >> Scott,
> > >> Readi= ng some of your examples, they seem to be valid even if
> > >&g= t; content
> > adaptation (HD/SD) is out of scope.
> > &g= t;> - a dCDN might for some reason be unwilling to distribute HD?
> > >> - a CSP might want to make sure the dCDN can use HLS enc= apsulation?
> > >> But these sorts of examples seem to be st= atic policy things (to
> > >> do
> with
> > t= he capabilities & preferences of the CDNs & CSP), rather than
> > metadata associated with a particular piece of content. In the> > discussion so far,
> I
> > think negotiation abou= t static policy stuff is rather out of
> > scope(?)
> > &= gt;>
> > >> On security considerations, an interesting question is w= hether
> > >> trust
> is
> > transitive. Don&= #39;t think it need be - just because CSP trusts uCDN,
> > and uCD= N trusts dCDN doesn't mean that the CSP automatically trusts
> > the
> dCDN.
> > However, i suspect this can get ar= bitrarily complex - so one
> > possibility is to say that we will = only handle cases where the trust is transitive.
> > >>
> > >> Best wishes
> > >> phil
> > >= >
> > >>
> > >> Philip Eardley
> >= ; >> Research and Technology Strategy
> > >>
> &= gt; >> This email contains BT information, which may be privileged or=
> > confidential. It's meant only for the individual(s) or entity= named
> above.
> > If you're not the intended recipient= , note that disclosing, copying,
> > distributing or using this in= formation is prohibited. If you've
> > received this email in error, please let me know immediately on t= he
> > email address above. Thank you. We monitor our email system= , and may
> > record your
> emails.
> > >> Br= itish Telecommunications plc
> > >> Registered office: 81 Newgate Street London EC1A 7AJ Reg= istered
> > >> in England no: 1800000
> > >><= br>> > >>
> > >> -----Original Message-----
> > >> From: cdni-boun= ces@ietf.org [mailto:cdni-boun= ces@ietf.org] On
> > >> Behalf
> Of
> > B= en Niven-Jenkins
> > >> Sent: 10 October 2011 12:04
> > >> To: Zh= ouZhipeng
> > >> Cc: cdni@i= etf.org
> > >> Subject: Re: [CDNi] I-D Action: draft-iet= f-cdni-use-cases-00.txt
> > >>
> > >> Colleagues,
> > >><= br>> > >> IMO Section 5.1.3 should be removed from the Use Case= s draft.
> > >> Content
> > Adaptation (i.e. taking= in a content item in one format and
> > transforming it to another format or representation) is not a &qu= ot;core"
> > function of a
> CDN
> > which typ= ically delivers the content that is requested without
> > explicit= knowledge of what that content actually is.
> > >>
> > >> Let's not forget that in build= ing an end to end content service
> > >> the
> CDN
= > > is only one component and is the component tasked with executing = the
> > delivery of a specific representation (version/copy/format etc.) = of
> > the selected content not the component tasked with deciding= (or
> > applying
> > policy) on which version/copy/repre= sentation of content should be
> > delivered.
> > >>
> > >> The decisi= on as to which version/copy/representation to offer and
> allow
&g= t; > to be delivered to a given device/user is implemented outside of th= e
> > CDN (e.g. by the "portal" where the user first makes th= eir content
> > selection prior to the CDN becoming involved in th= e delivery of the
> > selected content).
> > >>
> > >> Ben
> > >>
> > >> On 8 Oct= 2011, at 08:20, ZhouZhipeng wrote:
> > >>
> > >= >> Following Scott's comments on section 5.1.3, I feel Scott'= s
> > description on the use case of HD and SD is not exactly correct.<= br>> > >>> If one movie has two formats of HD and SD, then w= e have two
> > >>> content
> > with different id= entifier. In DRM scope, the basic unit is a content
> copy.
> > >>>
> > >>> Here the fir= st bullet "a subset of encodings deliverable to
> > >>&= gt; specific
> > devices," has listed the case of content ada= ptation.
> > >>> In last month, I have contacted the Authors of this = document and
> taken
> > some email exchanges with Grant and= Philip (BT).
> > >>> I have shown BT with some informati= on that I know in this case
> > >>> and
> > area to explain the content flexibi= lity is currently a basic
> > requirement for CDN service and rela= ted negotiation is needed in the
> > CDN interconnection.
> = > >>> Meanwhile, I should also invite you in this group raising= your
> > comments or questions on this case since I hope my use case may b= e
> > incorporated in the use case draft.
> > >>>= ;
> > >>> If you have any more question or comments, pls = share in this thread.
> > >>> Thanks.
> > >>> Zhipeng
> &g= t; >>>
> > >>>
> > >>>
>= > >>>
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>>= From: Scott Wainner [mailto:swainner= @cisco.com]
> > >>> Sent: Friday, September 30, 2011 = 8:02 AM
> > >>> To: cdni@ietf.org
> > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdn= i-use-cases-00.txt
> > >>>
> > >>> Sect= ion 2.3 Nomadic Users
> > >>> This description falls under the category of Geograp= hic
> > >>> Extension
> yet
> > >>&g= t; the third paragraph states the case where a different device is
> = > >>> used
> > in
> > >>> the same CDN coverage area. =A0The i= ntent of this use case needs
> > >>> to be clarified. =A0= Perhaps the use case is trying to address the
> > >>> sce= nario
> > where
> > >>> a Nomadic User-A with an agreemen= t allowing access to content
> > >>> from
> > CS= P-A
> > >>> via uCDN moves to a dCDN in a different regio= n. =A0The dCDN is
> > >>> allowed
> > to
> > >>> di= stribute the content of CSP-A to User-A; however, not other
> > &g= t;>> users
> in
> > >>> the region of the dCD= N are allowed to retrieve the content
> > >>> unless
> they
> > >>> too ha= ve such an agreement.
> > >>>
> > >>> S= ection 5.1.3 Content Encoding Restrictions Need to clarify if
> > = >>> we're talking about the restrictions on the delivery of sp= ecific
> > >>> content or the restrictions on the ability of a
&= gt; > CDN
> > >>> to deliver specific content. =A0I ce= rtainly understand the case
> > >>> where
> a
> > >>> CSP will restrict the distribution of content to a &= quot;managed
> > >>> path" if such content is HD whi= le allowing the content
> > >>> distribution via an un-ma= naged path if such content is SD (same
> > >>> could apply to
> encryption
> > >&= gt;> methods, delivery methods, etc.). =A0On the contrary, the dCDN may<= br>> have
> > >>> its own restrictions of blocking the= distribution of HD content
> while
> > >>> allowing the distribution of SD conten= t.
> > >>>
> > >>> o first bullet makes= sense if the dCDN can perform a subset of
> > >>> encaps= ulations for a reference set of media (e.g. HLS, HSS, but
> > >>> not
> > DASH)
> > >>> o s= econd bullet makes sense where the dCDN doesn't want to offer
> h= igh
> > >>> bit-rate variants of the media
> > &= gt;>> o third bullet make sense if the policy addresses QoE but I
> > >>> don't think subscriber rights/authorizations app= ly.
> > >>>
> > >>> Section 10 Security= Considerations
> > >>>
> > >>> Aside f= rom the security considerations WITHIN the uCDN and dCDN,
> > >>> I
> > think
> > >>> we ca= n describe this in four contexts:
> > >>>
> > &g= t;>> a. The relationship between the CSP and the uCDN (the principle<= br> > > contract
> > >>> arrangement for distribution)<= br>> > >>> b. The relationship between the uCDN and dCDN (th= e transitive
> > >>> trust relationship that extends the = contract defined in (a)
> > >>> above) c. The relationship between the User and dCDN= (the
> > >>> recognition of
> > right
> &= gt; >>> to download predicated on (b) above) d. The relationship b= etween
> > >>> the User and CSP (the contract
> authorizing> > >>> the user access to the content)
> > >&= gt;>
> > >>> The user is not interested in the a-b nor= the b-c relationship.
> > >>> The
> > user
> > >>> is o= nly interested in the transparency and interoperability of
> > >= ;>> the security relationship between d-b or d-c to the point that > > >>> the authorization granted in d-a is viable when the = delivery is
> initiated
> > >>> via either d-b or d= -c. =A0As an example, the uCDN might use URL
> appended
> > = >>> tokens for authentication while dCDN might use URL appended ha= shes.
> > The
> > >>> user doesn't want to know about= the distinct methods, but
> transparency
> > >>> i= s only afforded if the methods are interoperable clearly
> > >&= gt;> defined
> when
> > >>> the delegation for content delivery is = executed. =A0Clearly, the
> choice
> > of
> > >&= gt;> authentication method is determined by the respective CDN's. > > >>>
> > >>> Scott
> > >>= ;>
> > >>> ___________________________________________= ____
> > >>> CDNi mailing list
> > >>> = CDNi@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/cdni
>= > >>
> > >> ______________________________________= _________
> > >> CDNi mailing list
> > >> CDNi@ietf.org
> > >> https://www.ietf.org= /mailman/listinfo/cdni
> > >
> >
> > __________________________________= _____________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/l= istinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailm= an/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailm= an/listinfo/cdni

--bcaec5014dd764812d04af3181ac-- From zhouzhipeng@huawei.com Thu Oct 13 19:02:49 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075AC21F8BD5 for ; Thu, 13 Oct 2011 19:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.174 X-Spam-Level: X-Spam-Status: No, score=-5.174 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqVyzuGSsR+V for ; Thu, 13 Oct 2011 19:02:46 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 49AE321F8BA0 for ; Thu, 13 Oct 2011 19:02:46 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT100HL59MPW1@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 14 Oct 2011 10:01:37 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT1008Z09M4DK@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 14 Oct 2011 10:01:37 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEF51530; Fri, 14 Oct 2011 10:01:37 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 14 Oct 2011 10:01:25 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 10:01:28 +0800 Date: Fri, 14 Oct 2011 02:01:28 +0000 From: ZhouZhipeng In-reply-to: <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> X-Originating-IP: [10.138.73.38] To: "grant.watson@bt.com" , "kevin.ma@azukisystems.com" , "ben@niven-jenkins.co.uk" Message-id: <260A32EFD5C9EB47AD504929D005DF6245B284@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QIAAAyQAgAAMvHCAAGgN4IAAG0DggAAPupCAAOHGcA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245B154@SZXEML519-MBS.china.huawei.com> <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 02:02:49 -0000 Grant, I am not sure whether you mean that DRM is not a problem for the CDNI scenario as I suggested since initiation. Philip and you have the concern of DRM, therefore several emails have been given clarifying this issue. And as I explain the content adaptation does not bring new protection requirement to the CDNi. i.e. that works right now. >>"IMHO duplication of content assets inside the CDN to facilitate cross DRM delivery is not a CDNI issue." I guess you have not caught the core meaning of my explanation. It means in a single CDN, since the content duplication is needed while DRM protection requires that the entity that may duplicate the content should be secure to handle that. So totally my conclusion is DRM is mature enough for the scenarios we discussed and has no special to the content adaptation. Pls kindly check my conclusion. Thanks. Zhipeng -----Original Message----- From: grant.watson@bt.com [mailto:grant.watson@bt.com] Sent: Thursday, October 13, 2011 8:41 PM To: ZhouZhipeng; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi, "May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI." Just like it works right now: If objects are encrypted differently or use different DRMs generally it translates as separate objects in the CDN, Interconnected or otherwise. DRM is implemented by the CP, in the knowledge of what end devices and DRM platforms they are delivering to. IMHO that works right now and would work in a CDNI scenario. Frankly, I am even more convinced that this is best left out of scope now. IMHO duplication of content assets inside the CDN to facilitate cross DRM delivery is not a CDNI issue. I can see how this may be optimised perhaps, to reduce the amount of assets for example, but again that is not a CDNI issue - the issue exists for both CDN today and Interconnected CDN. g- -----Original Message----- From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] Sent: 13 October 2011 13:12 To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Grant, Nice to see your comment. May I conclude that by now the core issue for the content adaptation is " content protection". As a DRM people for years, I fully understand this concern. In fact the DRM circle have fully understood this concern since DRM should consider both the protection and the service implementation. May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI. It is not related to the content transcoding while you still face the issue for the protection transformation. For example, how your company's IPTV may connect the FT's terminals. Even in the internet that the PCs in different area may install the same soft DRM client, it may still has the problem of the content's duplication and content's verification(integrity protection). Take the OMA DRM DCF as an example, each content copy has its unique identifier(contentId) and each content copy has its unique Hash value. Hence in OMA DRM system, you( the device) may not duplicate a protected content copy that may be verified successfully by the device. Only the CP that encrypt the content may create a new copy of the content with another identifier. While in CDN system, we all know for the load balancing the CDN should be able to duplicate the hot content when needed. How it may be realized if the CDN may not create a new content copy that comply with the DRM solution. So you may see, there should be a secure facility within the CDN that may create/encrypt the content which may be accepted by the DRM client. Above is my analysis on this issue. Hope you may take a look at the OMA DRM specification to check the reason. For any question, I would like to respond as long as I know. Also note that the analysis is not specific to the content adaptation. I mean only general functionality of CDN. Thanks. Zhipeng -----Original Message----- From: grant.watson@bt.com [mailto:grant.watson@bt.com] Sent: Thursday, October 13, 2011 6:34 PM To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I'd support that perspective. Today CPs, in my experience, sometimes even actively seeks assurances that the content will NOT be modified by the CDN or by other downstream processes. So to envisage a CP allowing/wanting that to happen in a dCDN (that is likely out of their control, perhaps in another geography and with no quality feedback) feels like a very, very unlikely scenario. In general the content arrives encrypted and is shipped transparently, in my experience. Indeed the CPs desire to ship to different devices / screens etc. is also transparent to the CDN, they're just different objects requested by logic that is out-of-band to the CDN. I know of cases where content is transcoded/modified for mobile access by transparent caching, for example. But TC is not relevant to CDNI. IMHO content adaption/modification/transcoding is not a fundamental issue for CDNI. The issues around solving the fundamentals of how to Interconnect CDN are challenging enough. So I feel we should focus the scope on widely deployed use-cases / features and very likely new use-cases that are created by CDNI. g- -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: 13 October 2011 05:02 To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact > is decided by the CP. > Only under the permission, the HD video may be transformed to the > mobile video. i.e. if the CP support both IPTV and mobile video > service, then it may require the CDN to support multiple video > formats. The multi-screen service means the content source is from the > same CP while the target devices/clients include different groups. All > content businesses are under the permission of the content owner. > > For the content protection, I like talk a little more in this email > for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal > and the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and > we do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and > encrypt the content), the content is safe. Whether decrypt/re-encrypt > or just deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a > general scenario that is not related to whether taking content adaptation. > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only > > repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper > > solution that will be used by the market. > > If the standard may not support the market requirements, it is just > > the problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it > > will bring to the standard. I have repeated it is very simple in > > fact and I > do > > not know whether you have any special concern that will make you > > feel it would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via > > reflector or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by > > > the > > user. > > > The CP may create a special format as required by the user and ask > > > the > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may > > > then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI > > charter) > is > > to focus on what is necessary to interconnect CDNs to deliver > > content > from > > a CSP to an End User that is targeted and deployable within a short > > time frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users > > via multiple CDNs without needing or requiring any CDN supports > > content adaptation). > > > > In my opinion we have enough work to do already without trying to > > expand the scope of our work to include additional requirements that > > do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats > > > on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base > > for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have > > > ever > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are > > > the > core > > functionalities by existing main stream CDNs. Thus we may compare > > and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI > > interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content > > > related > > service. The user and CP only care whether the CDN providers may > > satisfy their requirement while not care the internal process. Just > > as GSM/PSTN interconnection, the user only care successful > > interconnection while not care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 > > > media > > formats. > > > One candidate is your company, another is CDN-X. The users are > > > located > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different > > > format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y > > > may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, > > > absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > > > while > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. > > > Remember > > the price from BBC is same to both your company and CDN-X or BBC > > would select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say > > > it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular > > CDN may wish to implement not a core functionality required to > > enable > content > > delivery between interconnected CDNs. I can think of many > > optimizations that a CDN could implement to differentiate their > > service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not > > a core function required to enable content delivery between > > interconnected CDNs and therefore given the workload we already have > > to specify > solutions > > that do address the core functionality required to interconnect CDNs > > I > do > > not think we should be trying to add more work into that workload as > > it will only distract us from achieving our goal of producing > > deployable solutions within the timeframe we are being told by > > operators they needs solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the > > > CDN > > providers should survive in the existing ecosystem and support the > > media types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. > > Otherwise the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function > > >> of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and > > >> "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure > > >> whether > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is > > >> ", I > > am not sure whether the wording is accurate since generally a CDN > > may claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a > > >> GSM > > phone to a PSTN telephone, the voice stream should be transformed > > from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar > > >> to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content > > delivery > the > > negotiation is done between the User/Client and the Content Provider > > and the CDN is just used to execute/perform the delivery that has > > been negotiated. The CDN is not involved in the decision making of > > what representations the Content Provider decides to offer to the > > User/Client or in what representations the User/Client decides to request. > > > > > >> As for you said selecting media by the "portal", you may see the > > >> way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core > > > function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also > > my interpretation of the scope of the CDNI working group as > > expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting > > usable specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the > > >> DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know > > >> all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but > > >> the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator > > >> since it > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that > > >> may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere > > >> that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the > > >> Requirements > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be > > >> able to > > cope with a scenario where (say) HD/SD conversion is done in the > > dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order > > >> requirement, > > ie we should not worry about it in the initial standards-track work. > > I don't know, did we ever decide whether the Use cases doc is > > restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if > > >> content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to > > >> do > with > > the capabilities & preferences of the CDNs & CSP), rather than > > metadata associated with a particular piece of content. In the > > discussion so far, > I > > think negotiation about static policy stuff is rather out of > > scope(?) > > >> > > >> On security considerations, an interesting question is whether > > >> trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, > > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > > the > dCDN. > > However, i suspect this can get arbitrarily complex - so one > > possibility is to say that we will only handle cases where the trust is transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > > email address above. Thank you. We monitor our email system, and may > > record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered > > >> in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > > >> Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > > >> Content > > Adaptation (i.e. taking in a content item in one format and > > transforming it to another format or representation) is not a "core" > > function of a > CDN > > which typically delivers the content that is requested without > > explicit knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service > > >> the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of > > the selected content not the component tasked with deciding (or > > applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the > > CDN (e.g. by the "portal" where the user first makes their content > > selection prior to the CDN becoming involved in the delivery of the > > selected content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two > > >>> content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to > > >>> specific > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case > > >>> and > > area to explain the content flexibility is currently a basic > > requirement for CDN service and related negotiation is needed in the > > CDN interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread. > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic > > >>> Extension > yet > > >>> the third paragraph states the case where a different device is > > >>> used > > in > > >>> the same CDN coverage area. The intent of this use case needs > > >>> to be clarified. Perhaps the use case is trying to address the > > >>> scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content > > >>> from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > > >>> allowed > > to > > >>> distribute the content of CSP-A to User-A; however, not other > > >>> users > in > > >>> the region of the dCDN are allowed to retrieve the content > > >>> unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if > > >>> we're talking about the restrictions on the delivery of specific > > >>> content or the restrictions on the ability of a > > CDN > > >>> to deliver specific content. I certainly understand the case > > >>> where > a > > >>> CSP will restrict the distribution of content to a "managed > > >>> path" if such content is HD while allowing the content > > >>> distribution via an un-managed path if such content is SD (same > > >>> could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but > > >>> not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I > > >>> don't think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, > > >>> I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive > > >>> trust relationship that extends the contract defined in (a) > > >>> above) c. The relationship between the User and dCDN (the > > >>> recognition of > > right > > >>> to download predicated on (b) above) d. The relationship between > > >>> the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. > > >>> The > > user > > >>> is only interested in the transparency and interoperability of > > >>> the security relationship between d-b or d-c to the point that > > >>> the authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly > > >>> defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From zhouzhipeng@huawei.com Thu Oct 13 19:37:01 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5921F8B16 for ; Thu, 13 Oct 2011 19:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.132 X-Spam-Level: X-Spam-Status: No, score=-5.132 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JtLIi2UEpVY for ; Thu, 13 Oct 2011 19:36:59 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1F69621F8AFD for ; Thu, 13 Oct 2011 19:36:59 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT100I3AB9L6K@szxga04-in.huawei.com> for cdni@ietf.org; Fri, 14 Oct 2011 10:36:58 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT1003JNB9LMJ@szxga04-in.huawei.com> for cdni@ietf.org; Fri, 14 Oct 2011 10:36:57 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEF54007; Fri, 14 Oct 2011 10:36:57 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 14 Oct 2011 10:36:50 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 10:36:46 +0800 Date: Fri, 14 Oct 2011 02:36:46 +0000 From: ZhouZhipeng In-reply-to: <1CA25301D2219F40B3AA37201F0EACD1136B0DCE@PACDCEXMB05.cable.comcast.com> X-Originating-IP: [10.138.73.38] To: "Woundy, Richard" , "grant.watson@bt.com" , "kevin.ma@azukisystems.com" , "ben@niven-jenkins.co.uk" Message-id: <260A32EFD5C9EB47AD504929D005DF6245B331@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QIAAAyQAgAAMvHCAAGgN4IAAG0DggAAPupD//7DtAIABNedQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245B154@SZXEML519-MBS.china.huawei.com> <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> <1CA25301D2219F40B3AA37201F0EACD1136B0DCE@PACDCEXMB05.cable.comcast.com> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 02:37:01 -0000 Woundy, Nice for your sharing the information below. I am also happy to see there is a session on related issue. As for CDNI, may I suggest we may have a use case first since it does not bring problem for other issues. Thanks. Zhipeng -----Original Message----- From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Thursday, October 13, 2011 11:35 PM To: grant.watson@bt.com; ZhouZhipeng; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt (Not speaking as working group co-chair) I would agree with Grant's comments below. I believe that CDNI can usefully focus on centralized content adaptation for now, eg encoding, fragmenting, and encryption. Two items that make sense to push to the edge (and therefore be a consideration for CDNI interfaces) are session-based encryption and watermarking. There is a technical paper "Unified Content Packaging Architectures for Managed Video Content Delivery" for an upcoming SCTE conference that does a good job of discussing and analyzing the centralized vs edge topic. Unfortunately, the conference is the same week as IETF 82, and SCTE may charge to get a copy of the paper and presentation. If that does not deter you, see . -- Rich -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of grant.watson@bt.com Sent: Thursday, October 13, 2011 8:41 AM To: zhouzhipeng@huawei.com; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi, "May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI." Just like it works right now: If objects are encrypted differently or use different DRMs generally it translates as separate objects in the CDN, Interconnected or otherwise. DRM is implemented by the CP, in the knowledge of what end devices and DRM platforms they are delivering to. IMHO that works right now and would work in a CDNI scenario. Frankly, I am even more convinced that this is best left out of scope now. IMHO duplication of content assets inside the CDN to facilitate cross DRM delivery is not a CDNI issue. I can see how this may be optimised perhaps, to reduce the amount of assets for example, but again that is not a CDNI issue - the issue exists for both CDN today and Interconnected CDN. g- -----Original Message----- From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] Sent: 13 October 2011 13:12 To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Grant, Nice to see your comment. May I conclude that by now the core issue for the content adaptation is " content protection". As a DRM people for years, I fully understand this concern. In fact the DRM circle have fully understood this concern since DRM should consider both the protection and the service implementation. May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI. It is not related to the content transcoding while you still face the issue for the protection transformation. For example, how your company's IPTV may connect the FT's terminals. Even in the internet that the PCs in different area may install the same soft DRM client, it may still has the problem of the content's duplication and content's verification(integrity protection). Take the OMA DRM DCF as an example, each content copy has its unique identifier(contentId) and each content copy has its unique Hash value. Hence in OMA DRM system, you( the device) may not duplicate a protected content copy that may be verified successfully by the device. Only the CP that encrypt the content may create a new copy of the content with another identifier. While in CDN system, we all know for the load balancing the CDN should be able to duplicate the hot content when needed. How it may be realized if the CDN may not create a new content copy that comply with the DRM solution. So you may see, there should be a secure facility within the CDN that may create/encrypt the content which may be accepted by the DRM client. Above is my analysis on this issue. Hope you may take a look at the OMA DRM specification to check the reason. For any question, I would like to respond as long as I know. Also note that the analysis is not specific to the content adaptation. I mean only general functionality of CDN. Thanks. Zhipeng -----Original Message----- From: grant.watson@bt.com [mailto:grant.watson@bt.com] Sent: Thursday, October 13, 2011 6:34 PM To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I'd support that perspective. Today CPs, in my experience, sometimes even actively seeks assurances that the content will NOT be modified by the CDN or by other downstream processes. So to envisage a CP allowing/wanting that to happen in a dCDN (that is likely out of their control, perhaps in another geography and with no quality feedback) feels like a very, very unlikely scenario. In general the content arrives encrypted and is shipped transparently, in my experience. Indeed the CPs desire to ship to different devices / screens etc. is also transparent to the CDN, they're just different objects requested by logic that is out-of-band to the CDN. I know of cases where content is transcoded/modified for mobile access by transparent caching, for example. But TC is not relevant to CDNI. IMHO content adaption/modification/transcoding is not a fundamental issue for CDNI. The issues around solving the fundamentals of how to Interconnect CDN are challenging enough. So I feel we should focus the scope on widely deployed use-cases / features and very likely new use-cases that are created by CDNI. g- -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: 13 October 2011 05:02 To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact > is decided by the CP. > Only under the permission, the HD video may be transformed to the > mobile video. i.e. if the CP support both IPTV and mobile video > service, then it may require the CDN to support multiple video > formats. The multi-screen service means the content source is from the > same CP while the target devices/clients include different groups. All > content businesses are under the permission of the content owner. > > For the content protection, I like talk a little more in this email > for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal > and the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and > we do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and > encrypt the content), the content is safe. Whether decrypt/re-encrypt > or just deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a > general scenario that is not related to whether taking content adaptation. > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only > > repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper > > solution that will be used by the market. > > If the standard may not support the market requirements, it is just > > the problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it > > will bring to the standard. I have repeated it is very simple in > > fact and I > do > > not know whether you have any special concern that will make you > > feel it would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via > > reflector or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by > > > the > > user. > > > The CP may create a special format as required by the user and ask > > > the > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may > > > then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI > > charter) > is > > to focus on what is necessary to interconnect CDNs to deliver > > content > from > > a CSP to an End User that is targeted and deployable within a short > > time frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users > > via multiple CDNs without needing or requiring any CDN supports > > content adaptation). > > > > In my opinion we have enough work to do already without trying to > > expand the scope of our work to include additional requirements that > > do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats > > > on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base > > for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have > > > ever > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are > > > the > core > > functionalities by existing main stream CDNs. Thus we may compare > > and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI > > interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content > > > related > > service. The user and CP only care whether the CDN providers may > > satisfy their requirement while not care the internal process. Just > > as GSM/PSTN interconnection, the user only care successful > > interconnection while not care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 > > > media > > formats. > > > One candidate is your company, another is CDN-X. The users are > > > located > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different > > > format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y > > > may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, > > > absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > > > while > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. > > > Remember > > the price from BBC is same to both your company and CDN-X or BBC > > would select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say > > > it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular > > CDN may wish to implement not a core functionality required to > > enable > content > > delivery between interconnected CDNs. I can think of many > > optimizations that a CDN could implement to differentiate their > > service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not > > a core function required to enable content delivery between > > interconnected CDNs and therefore given the workload we already have > > to specify > solutions > > that do address the core functionality required to interconnect CDNs > > I > do > > not think we should be trying to add more work into that workload as > > it will only distract us from achieving our goal of producing > > deployable solutions within the timeframe we are being told by > > operators they needs solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the > > > CDN > > providers should survive in the existing ecosystem and support the > > media types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. > > Otherwise the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function > > >> of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and > > >> "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure > > >> whether > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is > > >> ", I > > am not sure whether the wording is accurate since generally a CDN > > may claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a > > >> GSM > > phone to a PSTN telephone, the voice stream should be transformed > > from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar > > >> to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content > > delivery > the > > negotiation is done between the User/Client and the Content Provider > > and the CDN is just used to execute/perform the delivery that has > > been negotiated. The CDN is not involved in the decision making of > > what representations the Content Provider decides to offer to the > > User/Client or in what representations the User/Client decides to request. > > > > > >> As for you said selecting media by the "portal", you may see the > > >> way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core > > > function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also > > my interpretation of the scope of the CDNI working group as > > expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting > > usable specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the > > >> DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know > > >> all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but > > >> the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator > > >> since it > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that > > >> may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere > > >> that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the > > >> Requirements > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be > > >> able to > > cope with a scenario where (say) HD/SD conversion is done in the > > dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order > > >> requirement, > > ie we should not worry about it in the initial standards-track work. > > I don't know, did we ever decide whether the Use cases doc is > > restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if > > >> content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to > > >> do > with > > the capabilities & preferences of the CDNs & CSP), rather than > > metadata associated with a particular piece of content. In the > > discussion so far, > I > > think negotiation about static policy stuff is rather out of > > scope(?) > > >> > > >> On security considerations, an interesting question is whether > > >> trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, > > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > > the > dCDN. > > However, i suspect this can get arbitrarily complex - so one > > possibility is to say that we will only handle cases where the trust is transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > > email address above. Thank you. We monitor our email system, and may > > record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered > > >> in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > > >> Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > > >> Content > > Adaptation (i.e. taking in a content item in one format and > > transforming it to another format or representation) is not a "core" > > function of a > CDN > > which typically delivers the content that is requested without > > explicit knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service > > >> the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of > > the selected content not the component tasked with deciding (or > > applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the > > CDN (e.g. by the "portal" where the user first makes their content > > selection prior to the CDN becoming involved in the delivery of the > > selected content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two > > >>> content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to > > >>> specific > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case > > >>> and > > area to explain the content flexibility is currently a basic > > requirement for CDN service and related negotiation is needed in the > > CDN interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread. > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic > > >>> Extension > yet > > >>> the third paragraph states the case where a different device is > > >>> used > > in > > >>> the same CDN coverage area. The intent of this use case needs > > >>> to be clarified. Perhaps the use case is trying to address the > > >>> scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content > > >>> from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > > >>> allowed > > to > > >>> distribute the content of CSP-A to User-A; however, not other > > >>> users > in > > >>> the region of the dCDN are allowed to retrieve the content > > >>> unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if > > >>> we're talking about the restrictions on the delivery of specific > > >>> content or the restrictions on the ability of a > > CDN > > >>> to deliver specific content. I certainly understand the case > > >>> where > a > > >>> CSP will restrict the distribution of content to a "managed > > >>> path" if such content is HD while allowing the content > > >>> distribution via an un-managed path if such content is SD (same > > >>> could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but > > >>> not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I > > >>> don't think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, > > >>> I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive > > >>> trust relationship that extends the contract defined in (a) > > >>> above) c. The relationship between the User and dCDN (the > > >>> recognition of > > right > > >>> to download predicated on (b) above) d. The relationship between > > >>> the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. > > >>> The > > user > > >>> is only interested in the transparency and interoperability of > > >>> the security relationship between d-b or d-c to the point that > > >>> the authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly > > >>> defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From zhouzhipeng@huawei.com Thu Oct 13 20:10:40 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5516121F8C1C for ; Thu, 13 Oct 2011 20:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqU--wqOVU3o for ; Thu, 13 Oct 2011 20:10:24 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F221521F8B49 for ; Thu, 13 Oct 2011 20:10:23 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT100069CT38U@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 14 Oct 2011 11:10:15 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT100IUBCT3K9@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 14 Oct 2011 11:10:15 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEL27129; Fri, 14 Oct 2011 11:10:14 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 14 Oct 2011 11:10:09 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.172]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 14 Oct 2011 11:10:07 +0800 Date: Fri, 14 Oct 2011 03:10:07 +0000 From: ZhouZhipeng In-reply-to: X-Originating-IP: [10.138.73.38] To: Saurabh Chattopadhyay , "grant.watson@bt.com" Message-id: <260A32EFD5C9EB47AD504929D005DF6245B351@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gOGWIWgUxLeAHBpWqJm9vQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgAELA7CAABg+QIAAAyQAgAAMvHCAAGgN4IAAG0DggAAPupD//9FXgIABIFdA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245B154@SZXEML519-MBS.china.huawei.com> <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 03:10:40 -0000 --Boundary_(ID_gOGWIWgUxLeAHBpWqJm9vQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Saurabh, On the core functionality as always. Right now across the world, the convergence of mobile/internet/fixed system is the key requirement for the industry. Generally CDN is not restricted to a special service. A CDN may support either web-TV delivery or managed IPTV service delivery. The multi-screen service, means the CDN may deliver content to TV, PAD, PHONE, PC... any screen. Because the PC may display HD while PHONE may only display small video, the content adaptation may be used before the CDN deliver content to each terminal. This thread is raised from the concern: whether the protection will be a problem for the content adaptation. If the people may know that content adaption has no impact for existing DRM, our discussion has achieved good effect. Thanks. Zhipeng From: Saurabh Chattopadhyay [mailto:saurabh.sdo@gmail.com] Sent: Friday, October 14, 2011 1:31 AM To: grant.watson@bt.com Cc: ZhouZhipeng; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, While I'm also of the opinion that the particular case is best left out of scope for now, I think the scoping shall get defined/refined in a more appropriate place, possibly in CDN-I problem statement draft. Following is a relevant part from 'draft-ietf-cdni-problem-statement' - "NSPs have often deployed CDNs as specialized cost-reduction projects within the context of a particular service or environment, some NSPs operate separate CDNs for separate services. For example, there may be a CDN for managed IPTV service delivery, a CDN for web-TV delivery and a CDN for video delivery to Mobile terminals. As NSPs integrate their service portfolio, there is a need for interconnecting these CDNs. Again, NSPs face the problem of lack of open interfaces for CDN interconnection. " Unquestionably, primary responsibility of CDN-I is to standardize open interfaces for core content delivery function, however, while the CDNs adopt the particular Service Profiles, the scope of CDN-I gets naturally extended to interconnect the different service profiles. To clarify, a CDN for Video Delivery to Mobile Terminals, to me is a CDN adopting Service Profile of 'Video Delivery to Mobile Terminals'. And current discussion on Content Adaptation appears as a particular case for interconnecting CDNs of different Service Profiles. To that end, many aspects of ongoing work will get questioned to realize the extent of the interconnection use cases supporting Service Portfolio transformations and whether to be considered part of the current scope or not. IMHO the overall work needs to be staged in a manner that core Content Delivery Function gets the immediate attention, and subsequently the work group shall decide on the relevant part of service profile interconnection to standardize till required extent. Regards, Saurabh On Thu, Oct 13, 2011 at 6:10 PM, > wrote: Hi, "May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI." Just like it works right now: If objects are encrypted differently or use different DRMs generally it translates as separate objects in the CDN, Interconnected or otherwise. DRM is implemented by the CP, in the knowledge of what end devices and DRM platforms they are delivering to. IMHO that works right now and would work in a CDNI scenario. Frankly, I am even more convinced that this is best left out of scope now. IMHO duplication of content assets inside the CDN to facilitate cross DRM delivery is not a CDNI issue. I can see how this may be optimised perhaps, to reduce the amount of assets for example, but again that is not a CDNI issue - the issue exists for both CDN today and Interconnected CDN. g- -----Original Message----- From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] Sent: 13 October 2011 13:12 To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Grant, Nice to see your comment. May I conclude that by now the core issue for the content adaptation is " content protection". As a DRM people for years, I fully understand this concern. In fact the DRM circle have fully understood this concern since DRM should consider both the protection and the service implementation. May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI. It is not related to the content transcoding while you still face the issue for the protection transformation. For example, how your company's IPTV may connect the FT's terminals. Even in the internet that the PCs in different area may install the same soft DRM client, it may still has the problem of the content's duplication and content's verification(integrity protection). Take the OMA DRM DCF as an example, each content copy has its unique identifier(contentId) and each content copy has its unique Hash value. Hence in OMA DRM system, you( the device) may not duplicate a protected content copy that may be verified successfully by the device. Only the CP that encrypt the content may create a new copy of the content with another identifier. While in CDN system, we all know for the load balancing the CDN should be able to duplicate the hot content when needed. How it may be realized if the CDN may not create a new content copy that comply with the DRM solution. So you may see, there should be a secure facility within the CDN that may create/encrypt the content which may be accepted by the DRM client. Above is my analysis on this issue. Hope you may take a look at the OMA DRM specification to check the reason. For any question, I would like to respond as long as I know. Also note that the analysis is not specific to the content adaptation. I mean only general functionality of CDN. Thanks. Zhipeng -----Original Message----- From: grant.watson@bt.com [mailto:grant.watson@bt.com] Sent: Thursday, October 13, 2011 6:34 PM To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I'd support that perspective. Today CPs, in my experience, sometimes even actively seeks assurances that the content will NOT be modified by the CDN or by other downstream processes. So to envisage a CP allowing/wanting that to happen in a dCDN (that is likely out of their control, perhaps in another geography and with no quality feedback) feels like a very, very unlikely scenario. In general the content arrives encrypted and is shipped transparently, in my experience. Indeed the CPs desire to ship to different devices / screens etc. is also transparent to the CDN, they're just different objects requested by logic that is out-of-band to the CDN. I know of cases where content is transcoded/modified for mobile access by transparent caching, for example. But TC is not relevant to CDNI. IMHO content adaption/modification/transcoding is not a fundamental issue for CDNI. The issues around solving the fundamentals of how to Interconnect CDN are challenging enough. So I feel we should focus the scope on widely deployed use-cases / features and very likely new use-cases that are created by CDNI. g- -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: 13 October 2011 05:02 To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact > is decided by the CP. > Only under the permission, the HD video may be transformed to the > mobile video. i.e. if the CP support both IPTV and mobile video > service, then it may require the CDN to support multiple video > formats. The multi-screen service means the content source is from the > same CP while the target devices/clients include different groups. All > content businesses are under the permission of the content owner. > > For the content protection, I like talk a little more in this email > for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal > and the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and > we do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and > encrypt the content), the content is safe. Whether decrypt/re-encrypt > or just deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a > general scenario that is not related to whether taking content adaptation. > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only > > repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper > > solution that will be used by the market. > > If the standard may not support the market requirements, it is just > > the problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it > > will bring to the standard. I have repeated it is very simple in > > fact and I > do > > not know whether you have any special concern that will make you > > feel it would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via > > reflector or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by > > > the > > user. > > > The CP may create a special format as required by the user and ask > > > the > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may > > > then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI > > charter) > is > > to focus on what is necessary to interconnect CDNs to deliver > > content > from > > a CSP to an End User that is targeted and deployable within a short > > time frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users > > via multiple CDNs without needing or requiring any CDN supports > > content adaptation). > > > > In my opinion we have enough work to do already without trying to > > expand the scope of our work to include additional requirements that > > do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats > > > on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base > > for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have > > > ever > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are > > > the > core > > functionalities by existing main stream CDNs. Thus we may compare > > and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI > > interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content > > > related > > service. The user and CP only care whether the CDN providers may > > satisfy their requirement while not care the internal process. Just > > as GSM/PSTN interconnection, the user only care successful > > interconnection while not care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 > > > media > > formats. > > > One candidate is your company, another is CDN-X. The users are > > > located > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different > > > format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y > > > may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, > > > absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > > > while > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. > > > Remember > > the price from BBC is same to both your company and CDN-X or BBC > > would select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say > > > it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular > > CDN may wish to implement not a core functionality required to > > enable > content > > delivery between interconnected CDNs. I can think of many > > optimizations that a CDN could implement to differentiate their > > service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not > > a core function required to enable content delivery between > > interconnected CDNs and therefore given the workload we already have > > to specify > solutions > > that do address the core functionality required to interconnect CDNs > > I > do > > not think we should be trying to add more work into that workload as > > it will only distract us from achieving our goal of producing > > deployable solutions within the timeframe we are being told by > > operators they needs solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the > > > CDN > > providers should survive in the existing ecosystem and support the > > media types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. > > Otherwise the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function > > >> of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and > > >> "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure > > >> whether > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is > > >> ", I > > am not sure whether the wording is accurate since generally a CDN > > may claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a > > >> GSM > > phone to a PSTN telephone, the voice stream should be transformed > > from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar > > >> to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content > > delivery > the > > negotiation is done between the User/Client and the Content Provider > > and the CDN is just used to execute/perform the delivery that has > > been negotiated. The CDN is not involved in the decision making of > > what representations the Content Provider decides to offer to the > > User/Client or in what representations the User/Client decides to request. > > > > > >> As for you said selecting media by the "portal", you may see the > > >> way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core > > > function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also > > my interpretation of the scope of the CDNI working group as > > expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting > > usable specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the > > >> DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know > > >> all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but > > >> the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator > > >> since it > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that > > >> may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere > > >> that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the > > >> Requirements > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be > > >> able to > > cope with a scenario where (say) HD/SD conversion is done in the > > dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order > > >> requirement, > > ie we should not worry about it in the initial standards-track work. > > I don't know, did we ever decide whether the Use cases doc is > > restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if > > >> content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to > > >> do > with > > the capabilities & preferences of the CDNs & CSP), rather than > > metadata associated with a particular piece of content. In the > > discussion so far, > I > > think negotiation about static policy stuff is rather out of > > scope(?) > > >> > > >> On security considerations, an interesting question is whether > > >> trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, > > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > > the > dCDN. > > However, i suspect this can get arbitrarily complex - so one > > possibility is to say that we will only handle cases where the trust is transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > > email address above. Thank you. We monitor our email system, and may > > record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered > > >> in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > > >> Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > > >> Content > > Adaptation (i.e. taking in a content item in one format and > > transforming it to another format or representation) is not a "core" > > function of a > CDN > > which typically delivers the content that is requested without > > explicit knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service > > >> the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of > > the selected content not the component tasked with deciding (or > > applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the > > CDN (e.g. by the "portal" where the user first makes their content > > selection prior to the CDN becoming involved in the delivery of the > > selected content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two > > >>> content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to > > >>> specific > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case > > >>> and > > area to explain the content flexibility is currently a basic > > requirement for CDN service and related negotiation is needed in the > > CDN interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread. > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic > > >>> Extension > yet > > >>> the third paragraph states the case where a different device is > > >>> used > > in > > >>> the same CDN coverage area. The intent of this use case needs > > >>> to be clarified. Perhaps the use case is trying to address the > > >>> scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content > > >>> from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > > >>> allowed > > to > > >>> distribute the content of CSP-A to User-A; however, not other > > >>> users > in > > >>> the region of the dCDN are allowed to retrieve the content > > >>> unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if > > >>> we're talking about the restrictions on the delivery of specific > > >>> content or the restrictions on the ability of a > > CDN > > >>> to deliver specific content. I certainly understand the case > > >>> where > a > > >>> CSP will restrict the distribution of content to a "managed > > >>> path" if such content is HD while allowing the content > > >>> distribution via an un-managed path if such content is SD (same > > >>> could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but > > >>> not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I > > >>> don't think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, > > >>> I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive > > >>> trust relationship that extends the contract defined in (a) > > >>> above) c. The relationship between the User and dCDN (the > > >>> recognition of > > right > > >>> to download predicated on (b) above) d. The relationship between > > >>> the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. > > >>> The > > user > > >>> is only interested in the transparency and interoperability of > > >>> the security relationship between d-b or d-c to the point that > > >>> the authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly > > >>> defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --Boundary_(ID_gOGWIWgUxLeAHBpWqJm9vQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Saurabh,

 

On the core functionality as always.

Right now across the world, the convergence of mobile/internet/fixed system is the key requirement for the industry.

Generally CDN is not restricted to a special service. A CDN may support either web-TV delivery or managed IPTV service delivery.

 

The multi-screen service, means the CDN may deliver content to TV, PAD, PHONE, PC… any screen.

Because the PC may display HD while PHONE may only display small video, the content adaptation may be used before the CDN deliver content to each terminal.

 

This thread is raised from the concern: whether the protection will be a problem for the content adaptation.

If the people may know that content adaption has no impact for existing DRM,  our discussion has achieved good effect.

 

Thanks.

Zhipeng

 

 

From: Saurabh Chattopadhyay [mailto:saurabh.sdo@gmail.com]
Sent: Friday, October 14, 2011 1:31 AM
To: grant.watson@bt.com
Cc: ZhouZhipeng; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

 

Colleagues,

While I’m also of the opinion that the particular case is best left out of scope for now, I think the scoping shall get defined/refined in a more appropriate place, possibly in CDN-I problem statement draft.

Following is a relevant part from ‘draft-ietf-cdni-problem-statement’ –

“NSPs have often deployed CDNs as specialized cost-reduction projects

   within the context of a particular service or environment, some NSPs

   operate separate CDNs for separate services.  For example, there may

   be a CDN for managed IPTV service delivery, a CDN for web-TV delivery

   and a CDN for video delivery to Mobile terminals.  As NSPs integrate

   their service portfolio, there is a need for interconnecting these

   CDNs.  Again, NSPs face the problem of lack of open interfaces for

   CDN interconnection.

”

Unquestionably, primary responsibility of CDN-I is to standardize open interfaces for core content delivery function, however, while the CDNs adopt the particular Service Profiles, the scope of CDN-I gets naturally extended to interconnect the different service profiles. To clarify, a CDN for Video Delivery to Mobile Terminals, to me is a CDN adopting Service Profile of ‘Video Delivery to Mobile Terminals’. And current discussion on Content Adaptation appears as a particular case for interconnecting CDNs of different Service Profiles.

To that end, many aspects of ongoing work will get questioned to realize the extent of the interconnection use cases supporting Service Portfolio transformations and whether to be considered part of the current scope or not.

IMHO the overall work needs to be staged in a manner that core Content Delivery Function gets the immediate attention, and subsequently the work group shall decide on the relevant part of service profile interconnection to standardize till required extent.

Regards,

Saurabh



 

On Thu, Oct 13, 2011 at 6:10 PM, <grant.watson@bt.com> wrote:

Hi,


"May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI."

Just like it works right now: If objects are encrypted differently or use different DRMs generally it translates as separate objects in the CDN, Interconnected or otherwise. DRM is implemented by the CP, in the knowledge of what end devices and DRM platforms they are delivering to. IMHO that works right now and would work in a CDNI scenario.

Frankly, I am even more convinced that this is best left out of scope now. IMHO duplication of content assets inside the CDN to facilitate cross DRM delivery is not a CDNI issue. I can see how this may be optimised perhaps, to reduce the amount of assets for example, but again that is not a CDNI issue - the issue exists for both CDN today and Interconnected CDN.

g-



-----Original Message-----
From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com]

Sent: 13 October 2011 13:12

To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk
Cc: cdni@ietf.org
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Grant,
Nice to see your comment.
May I conclude that by now the core issue for the content adaptation is " content protection".
As a DRM people for years, I fully understand this concern.
In fact the DRM circle have fully understood this concern since DRM should consider both the protection and the service implementation.

May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI.
It is not related to the content transcoding while you still face the issue for the protection transformation. For example, how your company's IPTV may connect the FT's terminals.

Even in the internet that the PCs in different area may install the same soft DRM client, it may still has the problem of the content's duplication and content's verification(integrity protection).
Take the OMA DRM DCF as an example, each content copy has its unique identifier(contentId) and each content copy has its unique Hash value.
Hence in OMA DRM system, you( the device) may not duplicate a protected content copy that may be verified successfully by the device.
Only the CP that encrypt the content may create a new copy of the content with another identifier.

While in CDN system, we all know for the load balancing the CDN should be able to duplicate the hot content when needed. How it may be realized if the CDN may not create a new content copy that comply with the DRM solution.

So you may see, there should be a secure facility within the CDN that may create/encrypt the content which may be accepted by the DRM client.

Above is my analysis on this issue. Hope you may take a look at the OMA DRM specification to check the reason.
For any question, I would like to respond as long as I know.
Also note that the analysis is not specific to the content adaptation. I mean only general functionality of CDN.
Thanks.
Zhipeng

-----Original Message-----
From: grant.watson@bt.com [mailto:grant.watson@bt.com]
Sent: Thursday, October 13, 2011 6:34 PM
To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk
Cc: cdni@ietf.org
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

I'd support that perspective. Today CPs, in my experience, sometimes even actively seeks assurances that the content will NOT be modified by the CDN or by other downstream processes. So to envisage a CP allowing/wanting that to happen in a dCDN (that is likely out of their control, perhaps in another geography and with no quality feedback) feels like a very, very unlikely scenario. In general the content arrives encrypted and is shipped transparently, in my experience. Indeed the CPs desire to ship to different devices / screens etc. is also transparent to the CDN, they're just different objects requested by logic that is out-of-band to the CDN.

I know of cases where content is transcoded/modified for mobile access by transparent caching, for example. But TC is not relevant to CDNI.

IMHO content adaption/modification/transcoding is not a fundamental issue for CDNI. The issues around solving the fundamentals of how to Interconnect CDN are challenging enough. So I feel we should focus the scope on widely deployed use-cases / features and very likely new use-cases that are created by CDNI.

g-

-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

 If the CP has tight integration with both CDN providers as you describe
 below, I do not see why they would need CDNI at all?  What would be the
 benefit if they already have custom servers and security?

 Premium content providers that I am familiar with pregenerate content
 encodings, run them through rigorous quality control tests, and do
 not allow any modifications after that, to guarantee quality.  To do
 that in a CDN, let alone across CDNs, seems unlikely.  Content is
 processed in a secure facility and never released unencrypted to the
 CDN.  The CDN just acts a transparent delivery medium.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com]
> Sent: Wednesday, October 12, 2011 11:25 PM
> To: Kevin J Ma; Ben Niven-Jenkins
> Cc: cdni@ietf.org
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Kevin,
>
> As we ever discussed in previous email that the content format in fact
> is decided by the CP.
> Only under the permission, the HD video may be transformed to the
> mobile video. i.e. if the CP support both IPTV and mobile video
> service, then it may require the CDN to support multiple video
> formats. The multi-screen service means the content source is from the
> same CP while the target devices/clients include different groups. All
> content businesses are under the permission of the content owner.
>
> For the content protection, I like talk a little more in this email
> for
> reference:
> Given there are two areas: London and Paris.
> And in these two areas, each has deployed the DRM. Generally each DRM
> implementation is independent.
> If the content is delivered from London to Paris, absolutely the whole
> process should be granted by the CP.
> For the DRM standard, it mainly concern the security on the terminal
> and the interface between the SP/Client.
> You may see that the servers that are granted by the CP is secure and
> we do not need to worry that secure server would be the hacker.
> Hence, if the content is delivered from one server to another server(
> these servers are the equipments granted by CP that may handle and
> encrypt the content), the content is safe. Whether decrypt/re-encrypt
> or just deliver unencrypted content between these two servers are secure.
>
> Also, we may see such security issue for content distribution is a
> general scenario that is not related to whether taking content adaptation.
>
> Thanks.
> Zhipeng
>
>
>
> -----Original Message-----
> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]
> Sent: Thursday, October 13, 2011 10:45 AM
> To: ZhouZhipeng; Ben Niven-Jenkins
> Cc: cdni@ietf.org
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Zhipeng,
>
>   One practical concern to consider with the use case of downloading one
>   (as opposed to ten) streams is that premium content providers generally
>   are very concerned with quality control and are unlikely to trust dCDNs
>   to modify the content, and most likely, the content will be encrypted?
>
> thanx.
>
> --  Kevin J. Ma
>
> > -----Original Message-----
> > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf
> > Of ZhouZhipeng
> > Sent: Wednesday, October 12, 2011 9:51 PM
> > To: Ben Niven-Jenkins
> > Cc: cdni@ietf.org
> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> >
> > Ben,
> > I respect your personal standpoint while seems you are only
> > repeating
> your
> > personal conclusion without new reason/evidence.
> > In my case, I have explained the uCDN may deliver 10 streams to the
> dCDN.
> > But in our reality, we should consider whether it is a proper
> > solution that will be used by the market.
> > If the standard may not support the market requirements, it is just
> > the problem for its deployment.
> >
> > Meanwhile in my feeling you have not carefully thought about how it
> > will bring to the standard. I have repeated it is very simple in
> > fact and I
> do
> > not know whether you have any special concern that will make you
> > feel it would not be able to be done within 18-24 months.
> > Ben, as I repeat, if you have any question, I like respond via
> > reflector or to you individually.
> > Thanks.
> > Zhipeng
> >
> > -----Original Message-----
> > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> > Sent: Thursday, October 13, 2011 1:13 AM
> > To: ZhouZhipeng
> > Cc: philip.eardley@bt.com; cdni@ietf.org
> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> >
> > Zhipeng,
> >
> > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote:
> >
> > > Hello Ben,
> > > The UE may select the content format on the CP web. After that the
> user
> > only desires to get his selected content.
> > > But how the content is transferred to the client is not worried by
> > > the
> > user.
> > > The CP may create a special format as required by the user and ask
> > > the
> > CDN to deliver to user.
> > > While CP may give a HD format content to uCDN and the dCDN may
> > > then
> > transform to the format as the user select.
> >
> > Lots of things may be possible to do and CDN providers offer many
> > additional services on top of the "core" service of content delivery.
> > However, our objective (based on my interpretation of the CDNI
> > charter)
> is
> > to focus on what is necessary to interconnect CDNs to deliver
> > content
> from
> > a CSP to an End User that is targeted and deployable within a short
> > time frame (18-24 months).
> >
> > Content transformation/adaptation is not an essential requirement in
> order
> > to achieve that aim (we can deliver content from CSPs to End Users
> > via multiple CDNs without needing or requiring any CDN supports
> > content adaptation).
> >
> > In my opinion we have enough work to do already without trying to
> > expand the scope of our work to include additional requirements that
> > do not
> help
> > us address our core objectives as laid out in the CDNI charter.
> >
> > > In this case, it is nothing related to how the user select formats
> > > on
> CP
> > website.
> > > So, it is the CP and user to decide the content format not the
> CDN(your
> > assert is not correct and seems you take that assert as your base
> > for
> the
> > discussion).
> > >
> > > As for "the core CDN functionality offered by CDNs today", I have
> > > ever
> > raised an email before that your company's webpage has claimed
> supporting
> > media transformation and multi-screen service.
> > > Perhaps, I like asking you list some features that you feel are
> > > the
> core
> > functionalities by existing main stream CDNs. Thus we may compare
> > and
> take
> > deep look.
> >
> > I think the core functionality maps pretty well to the CDNI
> > interfaces,
> > namely: Request Routing, Metadata configuration, log production and
> > control plus content acquisition and content delivery.
> >
> > > I guess many people have the experience/knowledge of content
> > > related
> > service. The user and CP only care whether the CDN providers may
> > satisfy their requirement while not care the internal process. Just
> > as GSM/PSTN interconnection, the user only care successful
> > interconnection while not care how the voice is transformed in process.
> > >
> > > Besides, I like raise a case:
> > > Given currently BBC recruits CDN providers that may support 10
> > > media
> > formats.
> > > One candidate is your company, another is CDN-X. The users are
> > > located
> > in France.
> > > So both your company and CDN-X should connect a France CDN
> provider(CDN-
> > Y).
> > > If your company's solution is to send 10 streams of different
> > > format
> of
> > one content to CDN-Y;
> > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y
> > > may
> > conduct some adaptation.
> > > Comparing these two solutions, for your company and CDN-X,
> > > absolutely
> > the cost of CDN-X is much lower.
> > > For CDN-Y, in solution-1, it should receive/forward 10 streams ;
> > > while
> > in solution-2, it should only receive 1 stream but need to take
> > transformation to output 10 streams.
> > >
> > > Which solution is more competitive. it is Solution 1, right.
> > > Remember
> > the price from BBC is same to both your company and CDN-X or BBC
> > would select one CDN provider with the lower price.
> > > If a CDN provider may not get the contract from CP, how it may say
> > > it
> is
> > not a core functionality.
> >
> > What you are describing is a possible optimization that a particular
> > CDN may wish to implement not a core functionality required to
> > enable
> content
> > delivery between interconnected CDNs. I can think of many
> > optimizations that a CDN could implement to differentiate their
> > service but the
> internal
> > workings of an individual CDN are out of scope of our charter.
> >
> > So to repeat my position for a final time: Content adaptation is not
> > a core function required to enable content delivery between
> > interconnected CDNs and therefore given the workload we already have
> > to specify
> solutions
> > that do address the core functionality required to interconnect CDNs
> > I
> do
> > not think we should be trying to add more work into that workload as
> > it will only distract us from achieving our goal of producing
> > deployable solutions within the timeframe we are being told by
> > operators they needs solutions within.
> >
> > Ben
> >
> > > So, if we all realize that currently the media type is rich, the
> > > CDN
> > providers should survive in the existing ecosystem and support the
> > media types as required by the market.
> > >
> > > Back to the case of GSM/G.711, it just when concerning the
> > interconnection, the transformation should at once be solved.
> > Otherwise the interconnection may not be operated.
> > >
> > > Br,
> > > Zhipeng
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> > > Sent: Wednesday, October 12, 2011 12:19 AM
> > > To: ZhouZhipeng
> > > Cc: philip.eardley@bt.com; cdni@ietf.org
> > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >
> > > Zhipeng,
> > >
> > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote:
> > >
> > >> Ben and Philip,
> > >> I like to respond your concern in this one email:
> > >>
> > >> Ben,
> > >> I feel what we are now discussing is what is the "core" function
> > >> of
> > CDN.
> > >> As you say, CDN is used to deliver content. That is absolutely
> correct
> > that the delivery capability is the core requirement for CDN system.
> > >> While CDN is used to provide the content delivery service.
> > >> What means service. It should include "time" "location" and
> > >> "media
> > type", etc. These features are all the core feature for a service.
> > >> If we only concern "delivering one data block", I am not sure
> > >> whether
> > the issues such as "logging" "geographic constraint" are the core of
> CDN.
> > >>
> > >> For "without explicit knowledge of what that content actually is
> > >> ", I
> > am not sure whether the wording is accurate since generally a CDN
> > may claim it support different medias.
> > >> By this opportunity, I like to share a use case: a call from a
> > >> GSM
> > phone to a PSTN telephone, the voice stream should be transformed
> > from
> GSM
> > voice to G.711.
> > >> For the user, he does not need to know what type of data has been
> > transferred, but the operator has done some work to interconnect two
> > systems, right.
> > >> I like to know whether you may accept that my use case is similar
> > >> to
> > this case above.
> > >
> > > I don't think your use case is similar to the analogy of mobile
> networks
> > being interconnected to PSTN networks. In the case of content
> > delivery
> the
> > negotiation is done between the User/Client and the Content Provider
> > and the CDN is just used to execute/perform the delivery that has
> > been negotiated. The CDN is not involved in the decision making of
> > what representations the Content Provider decides to offer to the
> > User/Client or in what representations the User/Client decides to request.
> > >
> > >> As for you said selecting media by the "portal", you may see the
> > >> way
> "
> > uCDN delivers multiple media streams to dCDN" is not good than "uCDN
> > delivers one media stream to dCDN and dCDN takes some adaptation to
> > support multiple media types".
> > >
> > > Now what you're talking about is an optimisation, not a core
> > > function
> > required to actually deliver the content (and report, bill, etc. for
> that
> > delivery).
> > >
> > > My position is that we should focus on how to enable the
> interconnection
> > of the core CDN functionality offered by CDNs today (which is also
> > my interpretation of the scope of the CDNI working group as
> > expressed in
> its
> > charter) because doing so is a significant piece of work in itself.
> Let's
> > not start trying to add in additional functionality beyond what the
> > majority of CDNs support today as that will just delay us getting
> > usable specifications into the market in a timely fashion IMO.
> > >
> > > Ben
> > >
> > >> A good question is "security" since I have done six years on the
> > >> DRM
> > and like to promote the DRM all around the world:)
> > >> If the content is needed to be protected, generally you may know
> > >> all
> > the systems should be granted by the content owner.
> > >> Here I also like to clarify that not only the media itself but
> > >> the
> > information related to service itself (such as the geographic
> constraint)
> > should be protected also.
> > >> So, trust is not a problem for the media.
> > >>
> > >> Philip,
> > >> Thank you that you feel Content Adaption is an issue for
> "Requirements"
> > but I do not know why it is not for Use case.
> > >> I like to clarify to U that it is important for you operator
> > >> since it
> > may save investment if the system may support different services.
> > >> For us vendor, we are happy operator may install a system for the
> > mobile service and another system for the FBB service.
> > >> But the reality is all operators ask us to provide a system that
> > >> may
> > support different service systems.
> > >>
> > >> Frankly, Ben and Philip, I remember I have explained somewhere
> > >> that
> to
> > implement this is rather simple .
> > >> At least the Use case and Requirement are informational to be
> referred
> > in future work. So I do really feel you may accept it.
> > >> Of course I like to respond your more concern and comments.
> > >> Thanks.
> > >> Zhipeng
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
> > >> Sent: Monday, October 10, 2011 11:22 PM
> > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng
> > >> Cc: cdni@ietf.org
> > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >>
> > >> Ben, Zhipeng, all,
> > >>
> > >> I think that Content Adaptation is more an issue for the
> > >> Requirements
> > doc than for the Use cases draft.
> > >>
> > >> The key question is whether we want the CDNI interfaces to be
> > >> able to
> > cope with a scenario where (say) HD/SD conversion is done in the
> > dCDN &
> to
> > signal about this.
> > >>
> > >> I think that coping with this scenario is a second order
> > >> requirement,
> > ie we should not worry about it in the initial standards-track work.
> > I don't know, did we ever decide whether the Use cases doc is
> > restricted
> to
> > "initial" scenarios, or whether it's all-encompassing, ie covering
> > "future" scenarios as well?
> > >>
> > >> Scott,
> > >> Reading some of your examples, they seem to be valid even if
> > >> content
> > adaptation (HD/SD) is out of scope.
> > >> - a dCDN might for some reason be unwilling to distribute HD?
> > >> - a CSP might want to make sure the dCDN can use HLS encapsulation?
> > >> But these sorts of examples seem to be static policy things (to
> > >> do
> with
> > the capabilities & preferences of the CDNs & CSP), rather than
> > metadata associated with a particular piece of content. In the
> > discussion so far,
> I
> > think negotiation about static policy stuff is rather out of
> > scope(?)
> > >>
> > >> On security considerations, an interesting question is whether
> > >> trust
> is
> > transitive. Don't think it need be - just because CSP trusts uCDN,
> > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts
> > the
> dCDN.
> > However, i suspect this can get arbitrarily complex - so one
> > possibility is to say that we will only handle cases where the trust is transitive.
> > >>
> > >> Best wishes
> > >> phil
> > >>
> > >>
> > >> Philip Eardley
> > >> Research and Technology Strategy
> > >>
> > >> This email contains BT information, which may be privileged or
> > confidential. It's meant only for the individual(s) or entity named
> above.
> > If you're not the intended recipient, note that disclosing, copying,
> > distributing or using this information is prohibited. If you've
> > received this email in error, please let me know immediately on the
> > email address above. Thank you. We monitor our email system, and may
> > record your
> emails.
> > >> British Telecommunications plc
> > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered
> > >> in England no: 1800000
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On
> > >> Behalf
> Of
> > Ben Niven-Jenkins
> > >> Sent: 10 October 2011 12:04
> > >> To: ZhouZhipeng
> > >> Cc: cdni@ietf.org
> > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >>
> > >> Colleagues,
> > >>
> > >> IMO Section 5.1.3 should be removed from the Use Cases draft.
> > >> Content
> > Adaptation (i.e. taking in a content item in one format and
> > transforming it to another format or representation) is not a "core"
> > function of a
> CDN
> > which typically delivers the content that is requested without
> > explicit knowledge of what that content actually is.
> > >>
> > >> Let's not forget that in building an end to end content service
> > >> the
> CDN
> > is only one component and is the component tasked with executing the
> > delivery of a specific representation (version/copy/format etc.) of
> > the selected content not the component tasked with deciding (or
> > applying
> > policy) on which version/copy/representation of content should be
> > delivered.
> > >>
> > >> The decision as to which version/copy/representation to offer and
> allow
> > to be delivered to a given device/user is implemented outside of the
> > CDN (e.g. by the "portal" where the user first makes their content
> > selection prior to the CDN becoming involved in the delivery of the
> > selected content).
> > >>
> > >> Ben
> > >>
> > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:
> > >>
> > >>> Following Scott's comments on section 5.1.3, I feel Scott's
> > description on the use case of HD and SD is not exactly correct.
> > >>> If one movie has two formats of HD and SD, then we have two
> > >>> content
> > with different identifier. In DRM scope, the basic unit is a content
> copy.
> > >>>
> > >>> Here the first bullet "a subset of encodings deliverable to
> > >>> specific
> > devices," has listed the case of content adaptation.
> > >>> In last month, I have contacted the Authors of this document and
> taken
> > some email exchanges with Grant and Philip (BT).
> > >>> I have shown BT with some information that I know in this case
> > >>> and
> > area to explain the content flexibility is currently a basic
> > requirement for CDN service and related negotiation is needed in the
> > CDN interconnection.
> > >>> Meanwhile, I should also invite you in this group raising your
> > comments or questions on this case since I hope my use case may be
> > incorporated in the use case draft.
> > >>>
> > >>> If you have any more question or comments, pls share in this thread.
> > >>> Thanks.
> > >>> Zhipeng
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: Scott Wainner [mailto:swainner@cisco.com]
> > >>> Sent: Friday, September 30, 2011 8:02 AM
> > >>> To: cdni@ietf.org
> > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >>>
> > >>> Section 2.3 Nomadic Users
> > >>> This description falls under the category of Geographic
> > >>> Extension
> yet
> > >>> the third paragraph states the case where a different device is
> > >>> used
> > in
> > >>> the same CDN coverage area.  The intent of this use case needs
> > >>> to be clarified.  Perhaps the use case is trying to address the
> > >>> scenario
> > where
> > >>> a Nomadic User-A with an agreement allowing access to content
> > >>> from
> > CSP-A
> > >>> via uCDN moves to a dCDN in a different region.  The dCDN is
> > >>> allowed
> > to
> > >>> distribute the content of CSP-A to User-A; however, not other
> > >>> users
> in
> > >>> the region of the dCDN are allowed to retrieve the content
> > >>> unless
> they
> > >>> too have such an agreement.
> > >>>
> > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if
> > >>> we're talking about the restrictions on the delivery of specific
> > >>> content or the restrictions on the ability of a
> > CDN
> > >>> to deliver specific content.  I certainly understand the case
> > >>> where
> a
> > >>> CSP will restrict the distribution of content to a "managed
> > >>> path" if such content is HD while allowing the content
> > >>> distribution via an un-managed path if such content is SD (same
> > >>> could apply to
> encryption
> > >>> methods, delivery methods, etc.).  On the contrary, the dCDN may
> have
> > >>> its own restrictions of blocking the distribution of HD content
> while
> > >>> allowing the distribution of SD content.
> > >>>
> > >>> o first bullet makes sense if the dCDN can perform a subset of
> > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but
> > >>> not
> > DASH)
> > >>> o second bullet makes sense where the dCDN doesn't want to offer
> high
> > >>> bit-rate variants of the media
> > >>> o third bullet make sense if the policy addresses QoE but I
> > >>> don't think subscriber rights/authorizations apply.
> > >>>
> > >>> Section 10 Security Considerations
> > >>>
> > >>> Aside from the security considerations WITHIN the uCDN and dCDN,
> > >>> I
> > think
> > >>> we can describe this in four contexts:
> > >>>
> > >>> a. The relationship between the CSP and the uCDN (the principle
> > contract
> > >>> arrangement for distribution)
> > >>> b. The relationship between the uCDN and dCDN (the transitive
> > >>> trust relationship that extends the contract defined in (a)
> > >>> above) c. The relationship between the User and dCDN (the
> > >>> recognition of
> > right
> > >>> to download predicated on (b) above) d. The relationship between
> > >>> the User and CSP (the contract
> authorizing
> > >>> the user access to the content)
> > >>>
> > >>> The user is not interested in the a-b nor the b-c relationship.
> > >>> The
> > user
> > >>> is only interested in the transparency and interoperability of
> > >>> the security relationship between d-b or d-c to the point that
> > >>> the authorization granted in d-a is viable when the delivery is
> initiated
> > >>> via either d-b or d-c.  As an example, the uCDN might use URL
> appended
> > >>> tokens for authentication while dCDN might use URL appended hashes.
> > The
> > >>> user doesn't want to know about the distinct methods, but
> transparency
> > >>> is only afforded if the methods are interoperable clearly
> > >>> defined
> when
> > >>> the delegation for content delivery is executed.  Clearly, the
> choice
> > of
> > >>> authentication method is determined by the respective CDN's.
> > >>>
> > >>> Scott
> > >>>
> > >>> _______________________________________________
> > >>> CDNi mailing list
> > >>> CDNi@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/cdni
> > >>
> > >> _______________________________________________
> > >> CDNi mailing list
> > >> CDNi@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/cdni
> > >
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

 

--Boundary_(ID_gOGWIWgUxLeAHBpWqJm9vQ)-- From hexiaoyan@huawei.com Fri Oct 14 02:36:00 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C9321F8487 for ; Fri, 14 Oct 2011 02:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PhXvckLB+E4B for ; Fri, 14 Oct 2011 02:35:56 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 02F7021F847D for ; Fri, 14 Oct 2011 02:35:56 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT100F3WUMZTX@szxga04-in.huawei.com> for cdni@ietf.org; Fri, 14 Oct 2011 17:35:23 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT100AITUMITG@szxga04-in.huawei.com> for cdni@ietf.org; Fri, 14 Oct 2011 17:35:23 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEL53273; Fri, 14 Oct 2011 17:35:22 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 14 Oct 2011 17:35:15 +0800 Received: from w36710x (10.144.242.117) by smtpscn.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 14 Oct 2011 17:35:12 +0800 Date: Fri, 14 Oct 2011 17:35:10 +0800 From: HeXiaoyan In-reply-to: <291CC3F9E50E7641901A54E85D0977C651B51517AD@MAILR002.mail.lan> X-Originating-IP: [10.144.242.117] To: 'Kevin J Ma' , cdni@ietf.org Message-id: <000501cc8a54$921298c0$b637ca40$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcyErDmDceDqNX+AQtKwjumpTmgL9wDNgegQABC/ZGAAiOeZgA== X-CFilter-Loop: Reflected References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <010d01cc87f8$10bc5940$32350bc0$@com> <291CC3F9E50E7641901A54E85D0977C651B51517AD@MAILR002.mail.lan> Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 09:36:00 -0000 Hi Kevin, Thanks for the response. Some further concern, - I don't quite understand the restriction that require metadata of all hostnames in one Domain have same value. The case exist that for a specific metadata different hostnames often have different value. Compare with creating multiple Domains with less hostname sharing the same metadata, I think link metadata to hostname not Domain is more simpler. -I interpret the role of the Agent object is to identify entities communicated (correct me if I'm wrong), other interfaces in CDNI e.g. Logging interface needs such an parameter as well, a universal solution for that would be good, do you think the Agent object introduced in your draft could also be applicable for other interfaces? Best Regards Xiaoyan(Susan) He -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Tuesday, October 11, 2011 11:30 PM To: HeXiaoyan; cdni@ietf.org Subject: RE: [CDNi] CDNI Metadata Interface Hi Susan, thanx for the comments, responses inline: > -----Original Message----- > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > Sent: Tuesday, October 11, 2011 5:28 AM > To: Kevin J Ma; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface > > Hi Kevin, > Some quick questions and comments on this draft, > >The Metadata objects are each associated with a URI within the Domain and > accessible through any of the Hostnames... > - Could you further explain or give an example how a metadata is accessed > by > a Hostname within the Domain? And a further question is how the data model > works if a metadata is only associated with a specific Hostname within one > Doman? I was assuming that metadata would be valid for all hostnames. If a hostname needed separate metadata, a new domain would be required. I was thinking of hostname as a first level restriction. My implementation does something along the lines of the following (where hostname is checked before metadata lookup): domain = get_param_from_query_string(getenv("QUERY_STRING"), "domain") if (!db_verify_hostname_for_domain(getenv("SERVER_NAME"), domain)) return error metadata = db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"), domain, getenv("REMOTE_USER")) xml = generate_xml_for_metadata(metadata) return xml > - The relationship between Agent objects and Metadata objects is a > one-to-one relationship, does this mean one agent can only access one > Metadata within one Domain? That is a typo in the doc, good catch, thanx! It should be one to many. Each metadata must be associated with a single agent, but an agent can be associated with multiple metadata. Agent-1 could have metadatas A, B, and C, while agent-2 could have a separate value for metadatas A and B, and also have its own metadata D (that agent-1 does not have access to) > > The association of each Metadata to an Agent allows different Agents to > retrieve different Metadata values for a given URI in the given Domain. > - Don't understand why each Metadata object needs to be bind with an Agent > explicitly, IMO, whether to return different value to different Agents is > an > inside process of the upCDN, what downCDN needs to do is just transmit its > identifier to the upCDN when retrieve a Metadata. I think the fact that a uCDN would want/need to give out different values to different dCDNs requires that there be a way to represent and store that information. Having it explicitly in the model, i think, simplifies the implementation and guarantees that all implementation give this issue proper consideration. > - Which entity is responsible for creating the Agent objects within one > Domain? Does the CP can 'see' the downCDNs and creates corresponding Agent > objects and other CDNs on the way just transmitted it or each upCDN > located > in the cascaded path creates a Agent object for each its downCDN? This is a good question. Different agents would need to be create by different entities, as you mention. I would expect each CDN to create agents to represent those (outside that CDN) who need access to the metadata interface. thanx! -- Kevin J. Ma > Thanks. > Best Regards > Xiaoyan(Susan) He > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Kevin J Ma > Sent: Friday, October 07, 2011 1:21 PM > To: cdni@ietf.org > Subject: [CDNi] CDNI Metadata Interface > > Hi all, > > Just uploaded a new I-D with a proposed metadata model and API: > > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt > > The model takes a rather generic approach to metadata representation > to support opaque metadata and addresses some of the security issues > associated with metadata retrieval. Comments welcome. > > thanx. > > -- Kevin J. Ma > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Fri Oct 14 04:29:31 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016A621F8B16 for ; Fri, 14 Oct 2011 04:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFWK2S3wTknC for ; Fri, 14 Oct 2011 04:29:30 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5204B21F8B07 for ; Fri, 14 Oct 2011 04:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=263; q=dns/txt; s=iport; t=1318591770; x=1319801370; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=5+Q7OrryDNMibtFfq5qPTE8Un/rsOLnuoR2OLWyjbGo=; b=VQ0iRP/CcE6i4qeB9oC309RhRgCUbuh3T71zX03DePIiAUT9gE60kjqY WSa5LAJg0te7eKnhPgpXKyG1TqB8bpU75YHsQj9I9vIrPPTr+jQxPxdX0 T8diFvLvo4rvMDWOxh6oA5EOnKR/lEqjiV7GBtRw9qsPs6iYEwTRfnXpa E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0AANocmE6Q/khM/2dsb2JhbABDmTpDjmGBBYFsASeCModkl0CBJgGeOQOHDGEEk3eRVw X-IronPort-AV: E=Sophos;i="4.69,346,1315180800"; d="scan'208";a="57804525" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 14 Oct 2011 11:29:29 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9EBTTUF011397 for ; Fri, 14 Oct 2011 11:29:29 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 14 Oct 2011 13:30:56 +0200 Message-Id: To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] CDNI Slot at IETF-82 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 11:29:31 -0000 Hi, Note that as per the _draft_ agenda = (https://datatracker.ietf.org/meeting/82/agenda.html), the CDNI WG = session is tentatively scheduled: THURSDAY, November 17, 2011 15:20-17:20 This is still subject to potential change. Cheers Francois From kevin.ma@azukisystems.com Fri Oct 14 07:25:44 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF9A21F8669 for ; Fri, 14 Oct 2011 07:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvOiSwe1EYUH for ; Fri, 14 Oct 2011 07:25:43 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 82B1A21F8548 for ; Fri, 14 Oct 2011 07:25:43 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DB1878BDCD2; Fri, 14 Oct 2011 10:25:42 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id E96F58BD240; Fri, 14 Oct 2011 10:25:41 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Fri, 14 Oct 2011 10:25:42 -0400 From: Kevin J Ma To: HeXiaoyan , "cdni@ietf.org" Date: Fri, 14 Oct 2011 10:25:38 -0400 Thread-Topic: [CDNi] CDNI Metadata Interface Thread-Index: AcyErDmDceDqNX+AQtKwjumpTmgL9wDNgegQABC/ZGAAiOeZgAAMTEwg Message-ID: <291CC3F9E50E7641901A54E85D0977C651B523F27E@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <010d01cc87f8$10bc5940$32350bc0$@com> <291CC3F9E50E7641901A54E85D0977C651B51517AD@MAILR002.mail.lan> <000501cc8a54$921298c0$b637ca40$@com> In-Reply-To: <000501cc8a54$921298c0$b637ca40$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Oct 2011 14:25:44 -0000 Hi Susan, responses inline: > -----Original Message----- > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > Sent: Friday, October 14, 2011 5:35 AM > To: Kevin J Ma; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface >=20 > Hi Kevin, > Thanks for the response. Some further concern, > - I don't quite understand the restriction that require metadata of all > hostnames in one Domain have same value. The case exist that for a > specific > metadata different hostnames often have different value. Compare with > creating multiple Domains with less hostname sharing the same metadata, I > think link metadata to hostname not Domain is more simpler. >From a conceptual perspective, it could be argued that the domain object is extraneous. As an implementation detail, however, the multi-table joins, imo, were simplified by having a central object to define the domain, so I added one. From an operator perspective, having a way to group multiple hostnames also seems useful, even though, in the degenerate case, you could just have one hostname per domain. If there is a concensus view that the domain is unnecessary, it could be removed. > -I interpret the role of the Agent object is to identify entities > communicated (correct me if I'm wrong), other interfaces in CDNI e.g. > Logging interface needs such an parameter as well, a universal solution > for > that would be good, do you think the Agent object introduced in your draf= t > could also be applicable for other interfaces? I agree that the other interfaces (control/logging) will require some type of authentication and security. The agent concept could certainly be extended to other interfaces, and I agree that it would be good to have the same solution for all interfaces thanx. -- Kevin J. Ma > Best Regards > Xiaoyan(Susan) He >=20 > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Tuesday, October 11, 2011 11:30 PM > To: HeXiaoyan; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface >=20 > Hi Susan, >=20 > thanx for the comments, responses inline: >=20 > > -----Original Message----- > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > Sent: Tuesday, October 11, 2011 5:28 AM > > To: Kevin J Ma; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Kevin, > > Some quick questions and comments on this draft, > > >The Metadata objects are each associated with a URI within the Domain > and > > accessible through any of the Hostnames... > > - Could you further explain or give an example how a metadata is > accessed > > by > > a Hostname within the Domain? And a further question is how the data > model > > works if a metadata is only associated with a specific Hostname within > one > > Doman? >=20 > I was assuming that metadata would be valid for all hostnames. If a > hostname > needed separate metadata, a new domain would be required. I was thinking > of > hostname as a first level restriction. My implementation does something > along > the lines of the following (where hostname is checked before metadata > lookup): >=20 > domain =3D get_param_from_query_string(getenv("QUERY_STRING"), "domain"= ) > if (!db_verify_hostname_for_domain(getenv("SERVER_NAME"), domain)) > return error > metadata =3D db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"), > domain, > getenv("REMOTE_USER")) > xml =3D generate_xml_for_metadata(metadata) > return xml >=20 > > - The relationship between Agent objects and Metadata objects is a > > one-to-one relationship, does this mean one agent can only access one > > Metadata within one Domain? >=20 > That is a typo in the doc, good catch, thanx! It should be one to many. > Each metadata must be associated with a single agent, but an agent can be > associated with multiple metadata. Agent-1 could have metadatas A, B, an= d > C, while agent-2 could have a separate value for metadatas A and B, and > also > have its own metadata D (that agent-1 does not have access to) >=20 > > > The association of each Metadata to an Agent allows different Agents > to > > retrieve different Metadata values for a given URI in the given Domain. > > - Don't understand why each Metadata object needs to be bind with an > Agent > > explicitly, IMO, whether to return different value to different Agents > is > > an > > inside process of the upCDN, what downCDN needs to do is just transmit > its > > identifier to the upCDN when retrieve a Metadata. >=20 > I think the fact that a uCDN would want/need to give out different values > to > different dCDNs requires that there be a way to represent and store that > information. Having it explicitly in the model, i think, simplifies the > implementation and guarantees that all implementation give this issue > proper > consideration. >=20 > > - Which entity is responsible for creating the Agent objects within one > > Domain? Does the CP can 'see' the downCDNs and creates corresponding > Agent > > objects and other CDNs on the way just transmitted it or each upCDN > > located > > in the cascaded path creates a Agent object for each its downCDN? >=20 > This is a good question. Different agents would need to be create by > different > entities, as you mention. I would expect each CDN to create agents to > represent > those (outside that CDN) who need access to the metadata interface. >=20 > thanx! >=20 > -- Kevin J. Ma >=20 > > Thanks. > > Best Regards > > Xiaoyan(Susan) He > > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Kevin J Ma > > Sent: Friday, October 07, 2011 1:21 PM > > To: cdni@ietf.org > > Subject: [CDNi] CDNI Metadata Interface > > > > Hi all, > > > > Just uploaded a new I-D with a proposed metadata model and API: > > > > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt > > > > The model takes a rather generic approach to metadata representation > > to support opaque metadata and addresses some of the security issues > > associated with metadata retrieval. Comments welcome. > > > > thanx. > > > > -- Kevin J. Ma > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From hexiaoyan@huawei.com Mon Oct 17 00:15:13 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3754411E8082 for ; Mon, 17 Oct 2011 00:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 469lWUE9gnrB for ; Mon, 17 Oct 2011 00:15:12 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B923F21F8540 for ; Mon, 17 Oct 2011 00:15:11 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT700K0M83TI7@szxga03-in.huawei.com> for cdni@ietf.org; Mon, 17 Oct 2011 15:14:17 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT700481837XT@szxga03-in.huawei.com> for cdni@ietf.org; Mon, 17 Oct 2011 15:14:17 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEM28901; Mon, 17 Oct 2011 15:14:15 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 17 Oct 2011 15:14:14 +0800 Received: from w36710x (10.144.242.117) by smtpscn.huawei.com (10.82.67.31) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 17 Oct 2011 15:14:08 +0800 Date: Mon, 17 Oct 2011 15:14:08 +0800 From: HeXiaoyan In-reply-to: <291CC3F9E50E7641901A54E85D0977C651B523F27E@MAILR002.mail.lan> X-Originating-IP: [10.144.242.117] To: 'Kevin J Ma' , cdni@ietf.org Message-id: <000201cc8c9c$5d426180$17c72480$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcyErDmDceDqNX+AQtKwjumpTmgL9wDNgegQABC/ZGAAiOeZgAAMTEwgAIdhgUA= X-CFilter-Loop: Reflected References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <010d01cc87f8$10bc5940$32350bc0$@com> <291CC3F9E50E7641901A54E85D0977C651B51517AD@MAILR002.mail.lan> <000501cc8a54$921298c0$b637ca40$@com> <291CC3F9E50E7641901A54E85D0977C651B523F27E@MAILR002.mail.lan> Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 07:15:13 -0000 Hi Kevin, I share the view that the concept of Domain is useful, my suggestion is linking metadata to Hostname and keep the Domain, i.e. something like the figure below. Benefit is metadata associated with one custormer can be grouped even different Hostnames belong the Domain has different metadata value. +----------+ | | 1 | Agent +---------------------------+ | | | +----+-----+ | | 1..* | | | | 1 | 1 +----+-----+ +----+-----+ | | | | | Domain | | Metadata | | | | | +----+-----+ +-----+----+ | 1 | | | | 1..* | +----+-----+ | | | 1 0..* | | Hostname +----------------------------+ | | +----------+ Thanks. Best Regards Xiaoyan(Susan) He -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Friday, October 14, 2011 10:26 PM To: HeXiaoyan; cdni@ietf.org Subject: RE: [CDNi] CDNI Metadata Interface Hi Susan, responses inline: > -----Original Message----- > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > Sent: Friday, October 14, 2011 5:35 AM > To: Kevin J Ma; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface > > Hi Kevin, > Thanks for the response. Some further concern, > - I don't quite understand the restriction that require metadata of all > hostnames in one Domain have same value. The case exist that for a > specific > metadata different hostnames often have different value. Compare with > creating multiple Domains with less hostname sharing the same metadata, I > think link metadata to hostname not Domain is more simpler. >From a conceptual perspective, it could be argued that the domain object is extraneous. As an implementation detail, however, the multi-table joins, imo, were simplified by having a central object to define the domain, so I added one. From an operator perspective, having a way to group multiple hostnames also seems useful, even though, in the degenerate case, you could just have one hostname per domain. If there is a concensus view that the domain is unnecessary, it could be removed. > -I interpret the role of the Agent object is to identify entities > communicated (correct me if I'm wrong), other interfaces in CDNI e.g. > Logging interface needs such an parameter as well, a universal solution > for > that would be good, do you think the Agent object introduced in your draft > could also be applicable for other interfaces? I agree that the other interfaces (control/logging) will require some type of authentication and security. The agent concept could certainly be extended to other interfaces, and I agree that it would be good to have the same solution for all interfaces thanx. -- Kevin J. Ma > Best Regards > Xiaoyan(Susan) He > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Tuesday, October 11, 2011 11:30 PM > To: HeXiaoyan; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface > > Hi Susan, > > thanx for the comments, responses inline: > > > -----Original Message----- > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > Sent: Tuesday, October 11, 2011 5:28 AM > > To: Kevin J Ma; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Kevin, > > Some quick questions and comments on this draft, > > >The Metadata objects are each associated with a URI within the Domain > and > > accessible through any of the Hostnames... > > - Could you further explain or give an example how a metadata is > accessed > > by > > a Hostname within the Domain? And a further question is how the data > model > > works if a metadata is only associated with a specific Hostname within > one > > Doman? > > I was assuming that metadata would be valid for all hostnames. If a > hostname > needed separate metadata, a new domain would be required. I was thinking > of > hostname as a first level restriction. My implementation does something > along > the lines of the following (where hostname is checked before metadata > lookup): > > domain = get_param_from_query_string(getenv("QUERY_STRING"), "domain") > if (!db_verify_hostname_for_domain(getenv("SERVER_NAME"), domain)) > return error > metadata = db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"), > domain, > getenv("REMOTE_USER")) > xml = generate_xml_for_metadata(metadata) > return xml > > > - The relationship between Agent objects and Metadata objects is a > > one-to-one relationship, does this mean one agent can only access one > > Metadata within one Domain? > > That is a typo in the doc, good catch, thanx! It should be one to many. > Each metadata must be associated with a single agent, but an agent can be > associated with multiple metadata. Agent-1 could have metadatas A, B, and > C, while agent-2 could have a separate value for metadatas A and B, and > also > have its own metadata D (that agent-1 does not have access to) > > > > The association of each Metadata to an Agent allows different Agents > to > > retrieve different Metadata values for a given URI in the given Domain. > > - Don't understand why each Metadata object needs to be bind with an > Agent > > explicitly, IMO, whether to return different value to different Agents > is > > an > > inside process of the upCDN, what downCDN needs to do is just transmit > its > > identifier to the upCDN when retrieve a Metadata. > > I think the fact that a uCDN would want/need to give out different values > to > different dCDNs requires that there be a way to represent and store that > information. Having it explicitly in the model, i think, simplifies the > implementation and guarantees that all implementation give this issue > proper > consideration. > > > - Which entity is responsible for creating the Agent objects within one > > Domain? Does the CP can 'see' the downCDNs and creates corresponding > Agent > > objects and other CDNs on the way just transmitted it or each upCDN > > located > > in the cascaded path creates a Agent object for each its downCDN? > > This is a good question. Different agents would need to be create by > different > entities, as you mention. I would expect each CDN to create agents to > represent > those (outside that CDN) who need access to the metadata interface. > > thanx! > > -- Kevin J. Ma > > > Thanks. > > Best Regards > > Xiaoyan(Susan) He > > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Kevin J Ma > > Sent: Friday, October 07, 2011 1:21 PM > > To: cdni@ietf.org > > Subject: [CDNi] CDNI Metadata Interface > > > > Hi all, > > > > Just uploaded a new I-D with a proposed metadata model and API: > > > > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt > > > > The model takes a rather generic approach to metadata representation > > to support opaque metadata and addresses some of the security issues > > associated with metadata retrieval. Comments welcome. > > > > thanx. > > > > -- Kevin J. Ma > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Mon Oct 17 04:07:44 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE6D21F8B32 for ; Mon, 17 Oct 2011 04:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBjmU01qhQ0u for ; Mon, 17 Oct 2011 04:07:43 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC5E21F8B2A for ; Mon, 17 Oct 2011 04:07:42 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RFl2j-00078D-Jo for cdni@ietf.org; Mon, 17 Oct 2011 12:07:42 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2011 12:07:40 +0100 Message-Id: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:07:44 -0000 Colleagues, At the last IETF I said I would try to prepare a version of the CDNI = problem Statement (draft-ietf-cdni-problem-statement) that is ready for = WG Last Call before IETF82 in Taipei. As part of that I have reviewed the complete draft and made some minor = editorial clean-ups to my working copy. However, there were a number of = other areas where I think changes need to be made to the document that I = think warrant wider WG review/consensus and I have listed them below = along with the changes I am proposing. Could you please provide your feedback on the areas/proposed text I have = highlighted below as well as any other areas of the document that you = think require additional work/cleanup before you consider the document = is ready for a WG Last Call. 1) Section 2: Update the last paragraph to reference the WG draft for = CDNI use cases and remove reference to draft-watson-cdni-use-cases, i.e. OLD: Use cases for CDN Interconnection are further discussed in [I-D.bertrand-cdni-use-cases] (which contains a merged set of use cases previously presented in [I-D.watson-cdni-use-cases] and [I-D.bertrand-cdni-use-cases-00]). NEW: Use cases for CDN Interconnection are further discussed in [I-D.ietf-cdni-use-cases]. 2) Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) = that are each just a couple of sentences, so I propose merging them into = a single section and changing the first two sentences of section 4 = appropriately, i.e. OLD: This section expands on how CDNI interfaces can reuse and leverage existing protocols. First the "reuse instead of reinvent" design principle is restated, then each inetrface is discussed individually with example candidate protocols that can be considered for reuse or leverage.=20 NEW: This section expands on how CDNI interfaces can reuse and leverage existing protocols before describing each CDNI interface individually and highlighting example candidate protocols that could considered = for reuse or leveraging to implement the CDNI interfaces. =20 3) Section 5 is currently title "Gap Analysis of relevant = Standardisation and Research Activities" but following the agreement at = the last IETF to move the generic descriptions of other activities into = an appendix Section 5 no longer references any research activities so I = propose changing the title to" Gap Analysis of relevant Standardisation = activities". 4) After the general introduction in Section 5 there are only sections = that outline other research activities for Content Acquisition (section = 5.1) and CDNI Metadata (Section 5.2) but there are not sections for the = other CDNI interfaces (Control, Logging, Request Routing). The reason for the lack of text is IMO because there is no current or = past standardisation activity addressing those areas but the document = currently does not mention that and therefore gives the impression of = being incomplete. I therefore propose making the following change to the last sentence in = Section 5: OLD: The following sections will summarize the existing work of the standard bodies above against the CDNI problem space. NEW: The following sections will summarize the existing work of the standard bodies above against the CDNI problem space. Section 5.1 summarises existing interfaces that could be leveraged for content acquisition between CDNs and Section 5.2 summarises existing metadata=20= specifications that may be applicable to CDNI. To date there is no existing standardisation activities in the areas of the remaining CDNI interfaces (CDNI Request Routing, CDNI Control and CDNI = Logging). 5) I also propose using the following text for the third bullet in = Section 5 unless someone can suggest more appropriate text to summarise = in a sentence or two any CDN metadata related work in other standards = bodies. OLD: o NEW: o CableLabs, SNIA and ITU have defined (or are working on) definitions for content related metadata definitions and = specification for its distribution. However, they do not include metadata = specific to the distribution of content within a CDN or between = interconnected CDNs. 6) Section 10.1 lists a number of "normative references", if we adopt = the proposed changes above it will end up containing "normative" = references to: - draft-ietf-cdni-use-cases - draft-bertrand-cdni-experiements - draft-jenkins-cdni-names - RFC2119 After reading through the text of the Problem Statement again, I am not = convinced that the Problem Statement references any of those documents = normatively as the 3 CDNI related drafts are referenced in a context = where they are for further information and the Problem Statement does = not make use of any of the capitalised terms defined in RFC2119. Therefore, unless anyone objects I will move the references for the = three CDNI related drafts to the "Informative References" section and = remove the reference for RFC2119. Thanks Ben From ben@niven-jenkins.co.uk Mon Oct 17 08:28:10 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B679D21F8C4C for ; Mon, 17 Oct 2011 08:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.419 X-Spam-Level: X-Spam-Status: No, score=-103.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y+DCHNbjUTmN for ; Mon, 17 Oct 2011 08:28:09 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id A28B721F8C4B for ; Mon, 17 Oct 2011 08:28:09 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RFp6m-0003tB-2b for cdni@ietf.org; Mon, 17 Oct 2011 16:28:08 +0100 From: Ben Niven-Jenkins Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 17 Oct 2011 16:28:07 +0100 Message-Id: <842E1148-9AFD-4A39-BBB3-89CAAB9E833A@niven-jenkins.co.uk> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [CDNi] Some questions regarding draft-ma-cdni-metadata X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:28:10 -0000 Kevin, I read draft-ma-cdni-metadata but I am struggling a little to understand = how it fits into the overall framework of CDNI. When I read the draft it appeared to me to be aimed more at a Content = Provider or CDN Provider configuring the authoritative CDN rather that = for Metadata exchange between CDNs because of its use of Agents, the = fact it keeps all metadata opaque and because a lot of the protocol = description is about how to create and modify metadata records which = only seems to apply to the authoritative CDN. Agents: The draft states that "The Agent object contains basic information for = authenticating entities which require access to Metadata." However it is = not clear to me how the concept of the Agent object fits within the = framework of CDNI as the details of the different Agents that may be = able to access metadata for a Content Service will be specific the to = CDN distributing that CDNI metadata. In other words I can't see why one = would need to distribute Agent details between CDNs over CDNI because = the Agents that are relevant for an uCDN are likely different to the = Agents that a relevant to a dCDN. Later on the draft states: The association of each Metadata to an Agent allows different Agents to retrieve different Metadata values for a given URI in the given Domain. This is intended to allow CDNs to separate upstream Metadata from downstream Metadata (e.g., a uCDN content acquisition URL may point to a CP origin, however the content acquisition URL that the dCDN retrieves from the uCDN may point at a surrogate in the uCDN). This implies that the specification of Agents is really for imposing a = specific implementation on CDNs in how they manage metadata received = from a uCDN and how they expose that metadata to dCDNs. As the scope of = CDNI does not cover the internal workings or operation of a particular = CDN it would appear to me that imposing a particular internal mechanism = for a single CDN to manage & distribute CDNI metadata is inappropriate = for the CDNI WG.=20 Metadata: I am a little confused about the desire to keep the actual specification = of metadata opaque. In order for a CDN to do anything useful with the = CDNI metadata it receives it needs to understand the syntax and = semantics of the metadata it receives, however the draft intentionally = keeps both the syntax and semantics for the metadata properties as well = as any associated values opaque to any CDN that receives or distributes = the associated metadata and says the associated "functionality SHOULD be = agreed upon a priori by CDN operators, however, these negotiations are = beyond the scope of CDNI." Of course, the syntax and semantics of the CDNI metadata could be agreed = out of band between the operators of the interconnected CDNs but doing = that for all metadata properties that would be needed to meet the = objectives of CDNI does not IMO provide any real advantage over what one = could do today by configuring individual services in different CDNs and = using CDNI request routing to redirect requests between those services = in each CDN. I can see that the meaning of the value for a specific metadata property = might need to be opaque because the value may be applied differently by = different CDNs (e.g. a more general "QoS" value that each CDN maps to an = appropriate DSCP value depending on how the underlying network has been = configured/deployed) but those are more likely to be exceptions rather = than the general rule and in any case the property itself would still = need to be specified & defined, so even with that in mind I'm struggling = to see the value in keeping all metadata opaque. Ben= From kevin.ma@azukisystems.com Mon Oct 17 11:26:21 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2644021F85A4 for ; Mon, 17 Oct 2011 11:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JdhWn7AwNe0V for ; Mon, 17 Oct 2011 11:26:20 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 136F121F8593 for ; Mon, 17 Oct 2011 11:26:19 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6B72A79F8B4; Mon, 17 Oct 2011 14:26:19 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E00C979F878; Mon, 17 Oct 2011 14:26:16 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Mon, 17 Oct 2011 14:26:16 -0400 From: Kevin J Ma To: HeXiaoyan , "cdni@ietf.org" Date: Mon, 17 Oct 2011 14:26:14 -0400 Thread-Topic: [CDNi] CDNI Metadata Interface Thread-Index: AcyErDmDceDqNX+AQtKwjumpTmgL9wDNgegQABC/ZGAAiOeZgAAMTEwgAIdhgUAAENsBMA== Message-ID: <291CC3F9E50E7641901A54E85D0977C651B668260B@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <010d01cc87f8$10bc5940$32350bc0$@com> <291CC3F9E50E7641901A54E85D0977C651B51517AD@MAILR002.mail.lan> <000501cc8a54$921298c0$b637ca40$@com> <291CC3F9E50E7641901A54E85D0977C651B523F27E@MAILR002.mail.lan> <000201cc8c9c$5d426180$17c72480$@com> In-Reply-To: <000201cc8c9c$5d426180$17c72480$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 18:26:21 -0000 Hi Susan, ok, I think I understand now. In writing the draft, I was not sure if=20 this would be a typical use case. Adding the one-to-many relationship between the hostname and metadata tables would cause duplicate entries in the metadata table (one per hostname)? One alternative would be to use a many-to-many relationship instead, though verification of domain constraints on creation becomes more complex. In general, if we think that this flexibility is required, I have no issue with making changes to the model, however, if it is unlikely to be used, I would favor the simpler approach. Is a one-to-many relationship between the hostname and metadata tables that much better than removing the hostname table completely (and just adding a hostname field to the domain, i.e., the degenerate case where each domain only has one hostname)? That is essentially what it would be doing? =20 thanx. -- Kevin J. Ma > -----Original Message----- > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > Sent: Monday, October 17, 2011 3:14 AM > To: Kevin J Ma; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface >=20 > Hi Kevin, > I share the view that the concept of Domain is useful, my suggestion is > linking metadata to Hostname and keep the Domain, > i.e. something like the figure below. Benefit is metadata associated with > one custormer can be grouped even different > Hostnames belong the Domain has different metadata value. >=20 >=20 > +----------+ > | | 1 > | Agent +---------------------------+ > | | | > +----+-----+ | > | 1..* | > | | > | 1 | 1 > +----+-----+ +----+-----+ > | | | | > | Domain | | Metadata | > | | | | > +----+-----+ +-----+----+ > | 1 | > | | > | 1..* | > +----+-----+ | > | | 1 0..* | > | Hostname +----------------------------+ > | | > +----------+ >=20 > Thanks. >=20 > Best Regards > Xiaoyan(Susan) He > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Friday, October 14, 2011 10:26 PM > To: HeXiaoyan; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface >=20 > Hi Susan, >=20 > responses inline: >=20 > > -----Original Message----- > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > Sent: Friday, October 14, 2011 5:35 AM > > To: Kevin J Ma; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Kevin, > > Thanks for the response. Some further concern, > > - I don't quite understand the restriction that require metadata of all > > hostnames in one Domain have same value. The case exist that for a > > specific > > metadata different hostnames often have different value. Compare with > > creating multiple Domains with less hostname sharing the same metadata, > I > > think link metadata to hostname not Domain is more simpler. >=20 > From a conceptual perspective, it could be argued that the domain > object is extraneous. As an implementation detail, however, the > multi-table joins, imo, were simplified by having a central object > to define the domain, so I added one. From an operator perspective, > having a way to group multiple hostnames also seems useful, even > though, in the degenerate case, you could just have one hostname per > domain. If there is a concensus view that the domain is unnecessary, > it could be removed. >=20 > > -I interpret the role of the Agent object is to identify entities > > communicated (correct me if I'm wrong), other interfaces in CDNI e.g. > > Logging interface needs such an parameter as well, a universal solution > > for > > that would be good, do you think the Agent object introduced in your > draft > > could also be applicable for other interfaces? >=20 > I agree that the other interfaces (control/logging) will require some > type of authentication and security. The agent concept could certainly > be extended to other interfaces, and I agree that it would be good to > have the same solution for all interfaces >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > Best Regards > > Xiaoyan(Susan) He > > > > -----Original Message----- > > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > > Sent: Tuesday, October 11, 2011 11:30 PM > > To: HeXiaoyan; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Susan, > > > > thanx for the comments, responses inline: > > > > > -----Original Message----- > > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > > Sent: Tuesday, October 11, 2011 5:28 AM > > > To: Kevin J Ma; cdni@ietf.org > > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > > > Hi Kevin, > > > Some quick questions and comments on this draft, > > > >The Metadata objects are each associated with a URI within the Domai= n > > and > > > accessible through any of the Hostnames... > > > - Could you further explain or give an example how a metadata is > > accessed > > > by > > > a Hostname within the Domain? And a further question is how the data > > model > > > works if a metadata is only associated with a specific Hostname withi= n > > one > > > Doman? > > > > I was assuming that metadata would be valid for all hostnames. If a > > hostname > > needed separate metadata, a new domain would be required. I was > thinking > > of > > hostname as a first level restriction. My implementation does somethin= g > > along > > the lines of the following (where hostname is checked before metadata > > lookup): > > > > domain =3D get_param_from_query_string(getenv("QUERY_STRING"), "domai= n") > > if (!db_verify_hostname_for_domain(getenv("SERVER_NAME"), domain)) > > return error > > metadata =3D db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"= ), > > domain, > > getenv("REMOTE_USER")) > > xml =3D generate_xml_for_metadata(metadata) > > return xml > > > > > - The relationship between Agent objects and Metadata objects is a > > > one-to-one relationship, does this mean one agent can only access one > > > Metadata within one Domain? > > > > That is a typo in the doc, good catch, thanx! It should be one to many= . > > Each metadata must be associated with a single agent, but an agent can > be > > associated with multiple metadata. Agent-1 could have metadatas A, B, > and > > C, while agent-2 could have a separate value for metadatas A and B, and > > also > > have its own metadata D (that agent-1 does not have access to) > > > > > > The association of each Metadata to an Agent allows different Agent= s > > to > > > retrieve different Metadata values for a given URI in the given > Domain. > > > - Don't understand why each Metadata object needs to be bind with an > > Agent > > > explicitly, IMO, whether to return different value to different Agent= s > > is > > > an > > > inside process of the upCDN, what downCDN needs to do is just transmi= t > > its > > > identifier to the upCDN when retrieve a Metadata. > > > > I think the fact that a uCDN would want/need to give out different > values > > to > > different dCDNs requires that there be a way to represent and store tha= t > > information. Having it explicitly in the model, i think, simplifies th= e > > implementation and guarantees that all implementation give this issue > > proper > > consideration. > > > > > - Which entity is responsible for creating the Agent objects within > one > > > Domain? Does the CP can 'see' the downCDNs and creates corresponding > > Agent > > > objects and other CDNs on the way just transmitted it or each upCDN > > > located > > > in the cascaded path creates a Agent object for each its downCDN? > > > > This is a good question. Different agents would need to be create by > > different > > entities, as you mention. I would expect each CDN to create agents to > > represent > > those (outside that CDN) who need access to the metadata interface. > > > > thanx! > > > > -- Kevin J. Ma > > > > > Thanks. > > > Best Regards > > > Xiaoyan(Susan) He > > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > > > Kevin J Ma > > > Sent: Friday, October 07, 2011 1:21 PM > > > To: cdni@ietf.org > > > Subject: [CDNi] CDNI Metadata Interface > > > > > > Hi all, > > > > > > Just uploaded a new I-D with a proposed metadata model and API: > > > > > > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt > > > > > > The model takes a rather generic approach to metadata representatio= n > > > to support opaque metadata and addresses some of the security issue= s > > > associated with metadata retrieval. Comments welcome. > > > > > > thanx. > > > > > > -- Kevin J. Ma > > > > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Mon Oct 17 11:26:50 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7D21F8AAC for ; Mon, 17 Oct 2011 11:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8V6pi2h8y0Q for ; Mon, 17 Oct 2011 11:26:49 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1837121F899F for ; Mon, 17 Oct 2011 11:26:49 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B96AC554BF2; Mon, 17 Oct 2011 14:26:48 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id A564D55499D; Mon, 17 Oct 2011 14:26:22 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Mon, 17 Oct 2011 14:26:19 -0400 From: Kevin J Ma To: Ben Niven-Jenkins , "cdni@ietf.org" Date: Mon, 17 Oct 2011 14:26:17 -0400 Thread-Topic: [CDNi] Some questions regarding draft-ma-cdni-metadata Thread-Index: AcyM4Wv/0Dd+zOSkR0ijE6I9BuWQ1wADCH7Q Message-ID: <291CC3F9E50E7641901A54E85D0977C651B668260C@MAILR002.mail.lan> References: <842E1148-9AFD-4A39-BBB3-89CAAB9E833A@niven-jenkins.co.uk> In-Reply-To: <842E1148-9AFD-4A39-BBB3-89CAAB9E833A@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Some questions regarding draft-ma-cdni-metadata X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 18:26:50 -0000 Hi Ben, responses inline: > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Ben Niven-Jenkins > Sent: Monday, October 17, 2011 11:28 AM > To: cdni@ietf.org > Subject: [CDNi] Some questions regarding draft-ma-cdni-metadata >=20 > Kevin, >=20 > I read draft-ma-cdni-metadata but I am struggling a little to understand > how it fits into the overall framework of CDNI. >=20 > When I read the draft it appeared to me to be aimed more at a Content > Provider or CDN Provider configuring the authoritative CDN rather that fo= r > Metadata exchange between CDNs because of its use of Agents, the fact it > keeps all metadata opaque and because a lot of the protocol description i= s > about how to create and modify metadata records which only seems to apply > to the authoritative CDN. I attempted to create an extensible representation for metadata and a complete protocol for manipulating metadata, though, not all users of the interface will need all aspects. Do you feel that the protocol is deficient for non-authoritative CDN use, or that authoritative CDNs do not need the metadata interface? > Agents: > The draft states that "The Agent object contains basic information for > authenticating entities which require access to Metadata." However it is > not clear to me how the concept of the Agent object fits within the > framework of CDNI as the details of the different Agents that may be able > to access metadata for a Content Service will be specific the to CDN > distributing that CDNI metadata. In other words I can't see why one would > need to distribute Agent details between CDNs over CDNI because the Agent= s > that are relevant for an uCDN are likely different to the Agents that a > relevant to a dCDN. It was not intended that agent information be distributed between CDNs, that was what I tried to convery with the text stating:=20 "Domains and Agents MAY be created as a part of an off-line business negotiation process or as a part of the CDNI bootstrapping process." Susan had a similar question about who would be responsible for the creation of agents. I will clarify that in the next version.=20 > Later on the draft states: > The association of each Metadata to an Agent allows different Agents > to retrieve different Metadata values for a given URI in the given > Domain. This is intended to allow CDNs to separate upstream Metadata > from downstream Metadata (e.g., a uCDN content acquisition URL may > point to a CP origin, however the content acquisition URL that the > dCDN retrieves from the uCDN may point at a surrogate in the uCDN). >=20 > This implies that the specification of Agents is really for imposing a > specific implementation on CDNs in how they manage metadata received from > a uCDN and how they expose that metadata to dCDNs. As the scope of CDNI > does not cover the internal workings or operation of a particular CDN it > would appear to me that imposing a particular internal mechanism for a > single CDN to manage & distribute CDNI metadata is inappropriate for the > CDNI WG. The point was that different consumers of the metadata interface may require different responses (or they may not). Could that be left up to individual implementations? Perhaps. I am not sure what internal mechanism this imposes? Are you saying that CDNI should only define the metadata semantics, and not the storage representation? My goal was to define a generic representation, that could adapt to any=20 semantics? The agent is a part of that, though, in the degenerate case of a single agent, nothing is lost? > Metadata: > I am a little confused about the desire to keep the actual specification > of metadata opaque. In order for a CDN to do anything useful with the CDN= I > metadata it receives it needs to understand the syntax and semantics of > the metadata it receives, however the draft intentionally keeps both the > syntax and semantics for the metadata properties as well as any associate= d > values opaque to any CDN that receives or distributes the associated > metadata and says the associated "functionality SHOULD be agreed upon a > priori by CDN operators, however, these negotiations are beyond the scope > of CDNI." >=20 > Of course, the syntax and semantics of the CDNI metadata could be agreed > out of band between the operators of the interconnected CDNs but doing > that for all metadata properties that would be needed to meet the > objectives of CDNI does not IMO provide any real advantage over what one > could do today by configuring individual services in different CDNs and > using CDNI request routing to redirect requests between those services in > each CDN. >=20 > I can see that the meaning of the value for a specific metadata property > might need to be opaque because the value may be applied differently by > different CDNs (e.g. a more general "QoS" value that each CDN maps to an > appropriate DSCP value depending on how the underlying network has been > configured/deployed) but those are more likely to be exceptions rather > than the general rule and in any case the property itself would still nee= d > to be specified & defined, so even with that in mind I'm struggling to se= e > the value in keeping all metadata opaque. My concern with defining all the semantics of metadata and designing a protocol around that, is you typically end up with a less extensible design. I would not want to have to update the metadata interface rfc just to support a new piece of metadata in the future. I am not saying that we should not define metadata, I just think it should be separate from the data model and the protocol, so I concentrated on those first. I definitely feel that we should define a base set of metadata that all CDNs should support. I do not think the draft prevents that. thanx. -- Kevin J. Ma > Ben > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Oct 17 18:08:04 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF04721F8B62 for ; Mon, 17 Oct 2011 18:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.555 X-Spam-Level: X-Spam-Status: No, score=-6.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7PgokWudiZC for ; Mon, 17 Oct 2011 18:08:04 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 351EC21F8B5E for ; Mon, 17 Oct 2011 18:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=2085; q=dns/txt; s=iport; t=1318900084; x=1320109684; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=rtotAvjKfxumbLD3zbdtcswWFFSbpI8UDZ8wl6PPdVw=; b=Wtf2+nqlUZ8YvAT5Ia9heCVu9mByzhtRAtZ4T+uNpU/Y/0T5YbsqcOFG QzVZNkhZgifVHS1NouTw1tOmd3zKceARaLAEsgHOvHRKw9mBLixskWzSA O7M9Vhe/X1mE5OE5i5QMf15Y6JbWbF8n3mdKoNSbQCV1YxZVI6hrKlM68 Y=; X-IronPort-AV: E=Sophos;i="4.69,362,1315180800"; d="scan'208";a="8452320" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2011 01:08:04 +0000 Received: from sjc-vpn3-1006.cisco.com (sjc-vpn3-1006.cisco.com [10.21.67.238]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9I183J9025034; Tue, 18 Oct 2011 01:08:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: Date: Mon, 17 Oct 2011 13:10:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9041A3C5-056C-4ED3-A697-FF6A49E1F3F3@cisco.com> References: To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 01:08:04 -0000 Hi Ben, David, Grant, [Individual hat on] One quick question: " The CDNI Metadata interface specified in this document is a read-only interface. Therefore support for other HTTP methods such as PUT, POST and DELETE etc. is not specified. Server implementations of this interface SHOULD reject all methods other than GET and HEAD. " So to deal with metadata changes/invalidation reactively, the uCDN/dCDN = would play with TTL and conditional gets. So we end up with deployment trade-offs requiring tuning between = reactivity and revalidation load. Support of update/removal in the CDNI interface would allow to ensure = high reactivity for the important changes (eg immediately stop serving = content to a given region) while setting TTLs higher to ensure low = revalidation load. Is your motivation to exclude support for update/removal to keep things = as simple as possible so the group can define a minimum solution asap, = or do you think update/removal won't be needed at all even if we picture = large scale deployments. Cheers Francois On 12 Sep 2011, at 07:07, Ben Niven-Jenkins wrote: > Colleagues, >=20 > We just uploaded a proposal for a CDNI Metadata model and an interface = specification for distributing CDNI Metadata (see below). >=20 > This initial version does not attempt to articulate all the CDNI = Metadata that would be required to satisfy all CDNI use cases. Instead, = we have proposed a smaller set of properties that should be sufficient = to implement a minimal interconnect of basic HTTP delivery. >=20 > This is because, at this stage the important thing in our opinion is = to focus any discussion on the overall structure of the interface rather = than on the details or omission of particular properties. >=20 > Our proposal is available here: > http://tools.ietf.org/html/draft-jenkins-cdni-metadata-00 >=20 > Thanks > Ben, David & Grant >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Oct 17 18:08:04 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E07B521F8B5E for ; Mon, 17 Oct 2011 18:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.554 X-Spam-Level: X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKV82i8sZM8i for ; Mon, 17 Oct 2011 18:08:04 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDE821F8B5C for ; Mon, 17 Oct 2011 18:08:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=7018; q=dns/txt; s=iport; t=1318900084; x=1320109684; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=US9SBrUo5p3aGR620d+U64+Jie8+gMX3S6IyIsYZfTg=; b=H91HEHlvS4PUdNz9P5lqRit6QI9XdHJ5tlgZ93jGrake6ehYuMKeeR5K ObqKNQTgp5XJ/rjGZmKEDN7sjkHX+T/p4BQDC56gu8E0YZc7IQLPkNngh UolnMN3Kjcwjvbng7IDm1NwSruqmPkPRmZDczxjZNeEAGfGDnvoGR+wez A=; X-IronPort-AV: E=Sophos;i="4.69,362,1315180800"; d="scan'208,217";a="8452319" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 18 Oct 2011 01:08:04 +0000 Received: from sjc-vpn3-1006.cisco.com (sjc-vpn3-1006.cisco.com [10.21.67.238]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9I183J8025034; Tue, 18 Oct 2011 01:08:03 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-658--876546383 From: Francois Le Faucheur In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> Date: Mon, 17 Oct 2011 12:42:33 -0700 Message-Id: References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 01:08:05 -0000 --Apple-Mail-658--876546383 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Kevin, [with Individual hat on] A first set of high level questions: * directionality of metadata creation/retrieval/removal/update = mechanism: Could you clarify which of the above operation you see possibly = happening in which direction? For example, regarding update/removal, do you see: *a) the POST possibly being issued towards the uCDN to = update/remove some metadata in the uCDN repository? *b) the POST possibly being issued by the uCDN towards the dCDN = to update/remove some metadata in the dCDN repository (after some = out-of-date metadata had been retrieved by dCDN from uCDN). For example, regarding retrieval, clearly we want the dCDN to issue a = GET towards the uCDN to acquire metadata. Now do you see that the GET = could possibly be also issued by the uCDN to check metadata stored by = the dCDN? * in your CDNI metadata model, a "domain" is directly associated with a = set of "hostnames". So this assumes that the same set of unmodified = hostnames is used unmodified everywhere in all the potential dCDNs. That = can be the case in some deployment, but that may not always be the case. = For example, when HTTP redirection is used across CDNs, an upstream CDN = may want to modify (possibly hide) the actual content provider hostnames = (and possibly part of the URI path) when redirecting to a dCDN (I = believe this is mentioned in the framework).=20 Would you consider modifying your proposed CDNI model to allow for the = fact that a domain may be "referenced" differently by some dCDNs than by = the uCDN? I think it means: * the concept of "hostnames" should be made more flexible so it = matches not just on hostnames but on pattern match over hostname/path. = Let's call this "resource sets". * "resource sets" should be dependent on "Agents". So perhaps it = shoudl be folded inside your "Metadata" so it can be defined on a per = "dCDN" basis. Would that work for you? * in section 3.3.3, you have a couple of examples showing = "/CDNI/MI/domain". Should those not say "/CDNI/MI/metadata"? Cheers Francois =09 On 6 Oct 2011, at 22:21, Kevin J Ma wrote: > Hi all, >=20 > Just uploaded a new I-D with a proposed metadata model and API: >=20 > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt >=20 > The model takes a rather generic approach to metadata representation > to support opaque metadata and addresses some of the security issues > associated with metadata retrieval. Comments welcome. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-658--876546383 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Kevin,

[with Individual hat = on]

A first set of high level = questions:

* directionality of metadata = creation/retrieval/removal/update mechanism:
Could you clarify = which of the above operation you see possibly happening in which = direction?
For example, regarding update/removal, do you = see:
= *a)  the POST possibly being issued towards the uCDN to = update/remove some metadata in the uCDN repository?
*b) the = POST possibly being issued by the uCDN towards the dCDN to update/remove = some metadata in the dCDN repository (after some out-of-date metadata = had been retrieved by dCDN from uCDN).
For example, regarding = retrieval, clearly we want the dCDN to issue a GET towards the uCDN to = acquire metadata. Now do you see that the GET could possibly be also = issued by the uCDN to check metadata stored by the = dCDN?

* in your CDNI metadata model, a "domain" = is directly associated with a set of "hostnames". So this assumes that = the same set of unmodified hostnames is used unmodified everywhere in = all the potential dCDNs. That can be the case in some deployment, but = that may not always be the case. For example, when HTTP redirection is = used across CDNs, an upstream CDN may want to modify (possibly hide) the = actual content provider hostnames (and possibly part of the URI path) = when redirecting to a dCDN (I believe this is mentioned in the = framework). 
Would you consider modifying your proposed = CDNI model to allow for the fact that a domain may be "referenced" = differently by some dCDNs than by the uCDN?
I think it = means:
= * the concept of "hostnames" should be made more flexible = so it matches not just on hostnames but on pattern match over = hostname/path. Let's call this "resource sets".
* = "resource sets" should be dependent on "Agents". So perhaps it shoudl be = folded inside your "Metadata" so it can be defined on a per "dCDN" = basis.
Would that work for you?

* in = section 3.3.3, you have a couple of examples showing = "/CDNI/MI/domain". Should those not say = "/CDNI/MI/metadata"?


Cheers
<= div>
Francois

=


On 6 Oct 2011, at 22:21, = Kevin J Ma wrote:

Hi all,

 Just uploaded a new I-D with a = proposed metadata model and API:

   http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt
=
 The model takes a rather generic approach to metadata = representation
 to support opaque metadata and addresses some = of the security issues
 associated with metadata retrieval. =  Comments welcome.

thanx.

--  Kevin J. = Ma

_______________________________________________
CDNi = mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni

List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 08:00:10 -0000 Francois, Good question, see below. On 17 Oct 2011, at 21:10, Francois Le Faucheur wrote: > So to deal with metadata changes/invalidation reactively, the = uCDN/dCDN would play with TTL and conditional gets. > So we end up with deployment trade-offs requiring tuning between = reactivity and revalidation load. > Support of update/removal in the CDNI interface would allow to ensure = high reactivity for the important changes (eg immediately stop serving = content to a given region) while setting TTLs higher to ensure low = revalidation load. > Is your motivation to exclude support for update/removal to keep = things as simple as possible so the group can define a minimum solution = asap, or do you think update/removal won't be needed at all even if we = picture large scale deployments. Neither. Although we don't say so explicitly in the draft our thinking = was to model explicit CDNI Metadata invalidation/removal in the same = manner as explicit invalidation/removal of actual content and have that = performed via a request over the CDNI Control interface rather than = having two separate approaches - one for CDNI metadata and a different = one for the content itself. Ben From hexiaoyan@huawei.com Tue Oct 18 02:29:09 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D9521F8C58 for ; Tue, 18 Oct 2011 02:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TO8+83famIed for ; Tue, 18 Oct 2011 02:29:08 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 0B25B21F8B36 for ; Tue, 18 Oct 2011 02:29:07 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT900FVY8Y32X@szxga05-in.huawei.com> for cdni@ietf.org; Tue, 18 Oct 2011 17:27:39 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT900DG48XTPB@szxga05-in.huawei.com> for cdni@ietf.org; Tue, 18 Oct 2011 17:27:39 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEH25934; Tue, 18 Oct 2011 17:27:38 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 17:27:33 +0800 Received: from w36710x (10.144.242.117) by smtpscn.huawei.com (10.82.67.137) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 17:27:27 +0800 Date: Tue, 18 Oct 2011 17:27:26 +0800 From: HeXiaoyan In-reply-to: <291CC3F9E50E7641901A54E85D0977C651B668260B@MAILR002.mail.lan> X-Originating-IP: [10.144.242.117] To: 'Kevin J Ma' , cdni@ietf.org Message-id: <003101cc8d78$27379dd0$75a6d970$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: zh-cn Content-transfer-encoding: 7BIT Thread-index: AcyErDmDceDqNX+AQtKwjumpTmgL9wDNgegQABC/ZGAAiOeZgAAMTEwgAIdhgUAAENsBMAAiGgtw X-CFilter-Loop: Reflected References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <010d01cc87f8$10bc5940$32350bc0$@com> <291CC3F9E50E7641901A54E85D0977C651B51517AD@MAILR002.mail.lan> <000501cc8a54$921298c0$b637ca40$@com> <291CC3F9E50E7641901A54E85D0977C651B523F27E@MAILR002.mail.lan> <000201cc8c9c$5d426180$17c72480$@com> <291CC3F9E50E7641901A54E85D0977C651B668260B@MAILR002.mail.lan> Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 09:29:09 -0000 Kevin, > Adding the one-to-many relationship > between the hostname and metadata tables would cause duplicate entries > in the metadata table (one per hostname)? Sorry, after reading the draft again, I have to say my intention was that the relationship between the Hostname and Metadata object should be a one-to-zero or one-to-one relation like the figure below. All metadata associated with one hostname or one url prefix which at least containing a hostname should be grouped in one Metadata object (i.e. explicitly define all the properties of each hostname in one Metadata object). I think this is more straight-forward and consistent with the existing today CDN metadata model. Is it possible for you to consider modifying your proposal on this? +----------+ | | 1 | Agent +---------------------------+ | | | +----+-----+ | | 1..* | | | | 1 | 1 +----+-----+ +----+-----+ | | | | | Domain | | Metadata | | | | | +----+-----+ +-----+----+ | 1 | | | | 1..* | +----+-----+ | | | 1 0..1 | | Hostname +----------------------------+ | | +----------+ When reading through the examples in section 3.3.3, I found no agent id/name is conveyed in the metadata retrieval message, I remember we discussed that for different agent the upCDN may response with different value of a metadata, would you double check that? Thanks. Best Regards Xiaoyan(Susan) He -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] Sent: Tuesday, October 18, 2011 2:26 AM To: HeXiaoyan; cdni@ietf.org Subject: RE: [CDNi] CDNI Metadata Interface Hi Susan, ok, I think I understand now. In writing the draft, I was not sure if this would be a typical use case. Adding the one-to-many relationship between the hostname and metadata tables would cause duplicate entries in the metadata table (one per hostname)? One alternative would be to use a many-to-many relationship instead, though verification of domain constraints on creation becomes more complex. In general, if we think that this flexibility is required, I have no issue with making changes to the model, however, if it is unlikely to be used, I would favor the simpler approach. Is a one-to-many relationship between the hostname and metadata tables that much better than removing the hostname table completely (and just adding a hostname field to the domain, i.e., the degenerate case where each domain only has one hostname)? That is essentially what it would be doing? thanx. -- Kevin J. Ma > -----Original Message----- > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > Sent: Monday, October 17, 2011 3:14 AM > To: Kevin J Ma; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface > > Hi Kevin, > I share the view that the concept of Domain is useful, my suggestion is > linking metadata to Hostname and keep the Domain, > i.e. something like the figure below. Benefit is metadata associated with > one custormer can be grouped even different > Hostnames belong the Domain has different metadata value. > > > +----------+ > | | 1 > | Agent +---------------------------+ > | | | > +----+-----+ | > | 1..* | > | | > | 1 | 1 > +----+-----+ +----+-----+ > | | | | > | Domain | | Metadata | > | | | | > +----+-----+ +-----+----+ > | 1 | > | | > | 1..* | > +----+-----+ | > | | 1 0..* | > | Hostname +----------------------------+ > | | > +----------+ > > Thanks. > > Best Regards > Xiaoyan(Susan) He > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Friday, October 14, 2011 10:26 PM > To: HeXiaoyan; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface > > Hi Susan, > > responses inline: > > > -----Original Message----- > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > Sent: Friday, October 14, 2011 5:35 AM > > To: Kevin J Ma; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Kevin, > > Thanks for the response. Some further concern, > > - I don't quite understand the restriction that require metadata of all > > hostnames in one Domain have same value. The case exist that for a > > specific > > metadata different hostnames often have different value. Compare with > > creating multiple Domains with less hostname sharing the same metadata, > I > > think link metadata to hostname not Domain is more simpler. > > From a conceptual perspective, it could be argued that the domain > object is extraneous. As an implementation detail, however, the > multi-table joins, imo, were simplified by having a central object > to define the domain, so I added one. From an operator perspective, > having a way to group multiple hostnames also seems useful, even > though, in the degenerate case, you could just have one hostname per > domain. If there is a concensus view that the domain is unnecessary, > it could be removed. > > > -I interpret the role of the Agent object is to identify entities > > communicated (correct me if I'm wrong), other interfaces in CDNI e.g. > > Logging interface needs such an parameter as well, a universal solution > > for > > that would be good, do you think the Agent object introduced in your > draft > > could also be applicable for other interfaces? > > I agree that the other interfaces (control/logging) will require some > type of authentication and security. The agent concept could certainly > be extended to other interfaces, and I agree that it would be good to > have the same solution for all interfaces > > thanx. > > -- Kevin J. Ma > > > Best Regards > > Xiaoyan(Susan) He > > > > -----Original Message----- > > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > > Sent: Tuesday, October 11, 2011 11:30 PM > > To: HeXiaoyan; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Susan, > > > > thanx for the comments, responses inline: > > > > > -----Original Message----- > > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > > Sent: Tuesday, October 11, 2011 5:28 AM > > > To: Kevin J Ma; cdni@ietf.org > > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > > > Hi Kevin, > > > Some quick questions and comments on this draft, > > > >The Metadata objects are each associated with a URI within the Domain > > and > > > accessible through any of the Hostnames... > > > - Could you further explain or give an example how a metadata is > > accessed > > > by > > > a Hostname within the Domain? And a further question is how the data > > model > > > works if a metadata is only associated with a specific Hostname within > > one > > > Doman? > > > > I was assuming that metadata would be valid for all hostnames. If a > > hostname > > needed separate metadata, a new domain would be required. I was > thinking > > of > > hostname as a first level restriction. My implementation does something > > along > > the lines of the following (where hostname is checked before metadata > > lookup): > > > > domain = get_param_from_query_string(getenv("QUERY_STRING"), "domain") > > if (!db_verify_hostname_for_domain(getenv("SERVER_NAME"), domain)) > > return error > > metadata = db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"), > > domain, > > getenv("REMOTE_USER")) > > xml = generate_xml_for_metadata(metadata) > > return xml > > > > > - The relationship between Agent objects and Metadata objects is a > > > one-to-one relationship, does this mean one agent can only access one > > > Metadata within one Domain? > > > > That is a typo in the doc, good catch, thanx! It should be one to many. > > Each metadata must be associated with a single agent, but an agent can > be > > associated with multiple metadata. Agent-1 could have metadatas A, B, > and > > C, while agent-2 could have a separate value for metadatas A and B, and > > also > > have its own metadata D (that agent-1 does not have access to) > > > > > > The association of each Metadata to an Agent allows different Agents > > to > > > retrieve different Metadata values for a given URI in the given > Domain. > > > - Don't understand why each Metadata object needs to be bind with an > > Agent > > > explicitly, IMO, whether to return different value to different Agents > > is > > > an > > > inside process of the upCDN, what downCDN needs to do is just transmit > > its > > > identifier to the upCDN when retrieve a Metadata. > > > > I think the fact that a uCDN would want/need to give out different > values > > to > > different dCDNs requires that there be a way to represent and store that > > information. Having it explicitly in the model, i think, simplifies the > > implementation and guarantees that all implementation give this issue > > proper > > consideration. > > > > > - Which entity is responsible for creating the Agent objects within > one > > > Domain? Does the CP can 'see' the downCDNs and creates corresponding > > Agent > > > objects and other CDNs on the way just transmitted it or each upCDN > > > located > > > in the cascaded path creates a Agent object for each its downCDN? > > > > This is a good question. Different agents would need to be create by > > different > > entities, as you mention. I would expect each CDN to create agents to > > represent > > those (outside that CDN) who need access to the metadata interface. > > > > thanx! > > > > -- Kevin J. Ma > > > > > Thanks. > > > Best Regards > > > Xiaoyan(Susan) He > > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > > > Kevin J Ma > > > Sent: Friday, October 07, 2011 1:21 PM > > > To: cdni@ietf.org > > > Subject: [CDNi] CDNI Metadata Interface > > > > > > Hi all, > > > > > > Just uploaded a new I-D with a proposed metadata model and API: > > > > > > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt > > > > > > The model takes a rather generic approach to metadata representation > > > to support opaque metadata and addresses some of the security issues > > > associated with metadata retrieval. Comments welcome. > > > > > > thanx. > > > > > > -- Kevin J. Ma > > > > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni From haibin.song@huawei.com Tue Oct 18 02:47:22 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2202721F8B07 for ; Tue, 18 Oct 2011 02:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-vkKaGJAIlr for ; Tue, 18 Oct 2011 02:47:13 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 87B3A21F8B5C for ; Tue, 18 Oct 2011 02:47:12 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT900JSQ9UMYK@szxga04-in.huawei.com> for cdni@ietf.org; Tue, 18 Oct 2011 17:47:10 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT900M6B9U73Q@szxga04-in.huawei.com> for cdni@ietf.org; Tue, 18 Oct 2011 17:47:10 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEH27633; Tue, 18 Oct 2011 17:47:09 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 17:47:06 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.75]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Tue, 18 Oct 2011 17:46:56 +0800 Date: Tue, 18 Oct 2011 09:46:55 +0000 From: Songhaibin In-reply-to: <260A32EFD5C9EB47AD504929D005DF6245B351@SZXEML519-MBS.china.huawei.com> X-Originating-IP: [10.138.41.129] To: ZhouZhipeng , Saurabh Chattopadhyay , "grant.watson@bt.com" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_8tLGd+ZC/uZamYUGFdBHSA)" Content-language: zh-CN Accept-Language: en-US, zh-CN Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMeV9TWL60nB7GRUWiIz6JD/m+M5Vkj4QAgA0NMICAA2MyAIAAR/OAgADYcgCAAMn0gIABHfSAgACDOACAAJDjAIAADvkAgAALSYCAAAovAIAAbamAgAAbOYCAAAgpAIAAUSCAgAChx4CABzk8AA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AF39@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F61@MAILR002.mail.lan> <260A32EFD5C9EB47AD504929D005DF6245AFB5@SZXEML519-MBS.china.huawei.com> <291CC3F9E50E7641901A54E85D0977C651B5151F66@MAILR002.mail.lan> <1F3DE948AD28CB4D905D51039D081AF626600913ED@EMV64-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245B154@SZXEML519-MBS.china.huawei.com> <1F3DE948AD28CB4D905D51039D081AF6266009156C@EMV64-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245B351@SZXEML519-MBS.china.huawei.com> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 09:47:22 -0000 --Boundary_(ID_8tLGd+ZC/uZamYUGFdBHSA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Following this discussion, I think there are two basic questions for the WG to answer: 1. Whether a capability negotiation is needed for an upstream CDN to select one eligible downstream CDN (assume that business is out of scope), provided that different CDNs have different "service profiles". 2. Whether content is transparent to current CDNs. If yes, there is NO transcoding/transrating kind of content adaptation in CDNs, and of course there will be NO parameter related to such kind of capability in CDNI scope. If content is NOT transparent to current CDNs, then IMO CDNI has interoperability concerns to use the content adaptation parameters. BR, -Haibin From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of ZhouZhipeng Sent: Friday, October 14, 2011 11:10 AM To: Saurabh Chattopadhyay; grant.watson@bt.com Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Saurabh, On the core functionality as always. Right now across the world, the convergence of mobile/internet/fixed system is the key requirement for the industry. Generally CDN is not restricted to a special service. A CDN may support either web-TV delivery or managed IPTV service delivery. The multi-screen service, means the CDN may deliver content to TV, PAD, PHONE, PC... any screen. Because the PC may display HD while PHONE may only display small video, the content adaptation may be used before the CDN deliver content to each terminal. This thread is raised from the concern: whether the protection will be a problem for the content adaptation. If the people may know that content adaption has no impact for existing DRM, our discussion has achieved good effect. Thanks. Zhipeng From: Saurabh Chattopadhyay [mailto:saurabh.sdo@gmail.com] Sent: Friday, October 14, 2011 1:31 AM To: grant.watson@bt.com Cc: ZhouZhipeng; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, While I'm also of the opinion that the particular case is best left out of scope for now, I think the scoping shall get defined/refined in a more appropriate place, possibly in CDN-I problem statement draft. Following is a relevant part from 'draft-ietf-cdni-problem-statement' - "NSPs have often deployed CDNs as specialized cost-reduction projects within the context of a particular service or environment, some NSPs operate separate CDNs for separate services. For example, there may be a CDN for managed IPTV service delivery, a CDN for web-TV delivery and a CDN for video delivery to Mobile terminals. As NSPs integrate their service portfolio, there is a need for interconnecting these CDNs. Again, NSPs face the problem of lack of open interfaces for CDN interconnection. " Unquestionably, primary responsibility of CDN-I is to standardize open interfaces for core content delivery function, however, while the CDNs adopt the particular Service Profiles, the scope of CDN-I gets naturally extended to interconnect the different service profiles. To clarify, a CDN for Video Delivery to Mobile Terminals, to me is a CDN adopting Service Profile of 'Video Delivery to Mobile Terminals'. And current discussion on Content Adaptation appears as a particular case for interconnecting CDNs of different Service Profiles. To that end, many aspects of ongoing work will get questioned to realize the extent of the interconnection use cases supporting Service Portfolio transformations and whether to be considered part of the current scope or not. IMHO the overall work needs to be staged in a manner that core Content Delivery Function gets the immediate attention, and subsequently the work group shall decide on the relevant part of service profile interconnection to standardize till required extent. Regards, Saurabh On Thu, Oct 13, 2011 at 6:10 PM, > wrote: Hi, "May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI." Just like it works right now: If objects are encrypted differently or use different DRMs generally it translates as separate objects in the CDN, Interconnected or otherwise. DRM is implemented by the CP, in the knowledge of what end devices and DRM platforms they are delivering to. IMHO that works right now and would work in a CDNI scenario. Frankly, I am even more convinced that this is best left out of scope now. IMHO duplication of content assets inside the CDN to facilitate cross DRM delivery is not a CDNI issue. I can see how this may be optimised perhaps, to reduce the amount of assets for example, but again that is not a CDNI issue - the issue exists for both CDN today and Interconnected CDN. g- -----Original Message----- From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] Sent: 13 October 2011 13:12 To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Grant, Nice to see your comment. May I conclude that by now the core issue for the content adaptation is " content protection". As a DRM people for years, I fully understand this concern. In fact the DRM circle have fully understood this concern since DRM should consider both the protection and the service implementation. May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI. It is not related to the content transcoding while you still face the issue for the protection transformation. For example, how your company's IPTV may connect the FT's terminals. Even in the internet that the PCs in different area may install the same soft DRM client, it may still has the problem of the content's duplication and content's verification(integrity protection). Take the OMA DRM DCF as an example, each content copy has its unique identifier(contentId) and each content copy has its unique Hash value. Hence in OMA DRM system, you( the device) may not duplicate a protected content copy that may be verified successfully by the device. Only the CP that encrypt the content may create a new copy of the content with another identifier. While in CDN system, we all know for the load balancing the CDN should be able to duplicate the hot content when needed. How it may be realized if the CDN may not create a new content copy that comply with the DRM solution. So you may see, there should be a secure facility within the CDN that may create/encrypt the content which may be accepted by the DRM client. Above is my analysis on this issue. Hope you may take a look at the OMA DRM specification to check the reason. For any question, I would like to respond as long as I know. Also note that the analysis is not specific to the content adaptation. I mean only general functionality of CDN. Thanks. Zhipeng -----Original Message----- From: grant.watson@bt.com [mailto:grant.watson@bt.com] Sent: Thursday, October 13, 2011 6:34 PM To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I'd support that perspective. Today CPs, in my experience, sometimes even actively seeks assurances that the content will NOT be modified by the CDN or by other downstream processes. So to envisage a CP allowing/wanting that to happen in a dCDN (that is likely out of their control, perhaps in another geography and with no quality feedback) feels like a very, very unlikely scenario. In general the content arrives encrypted and is shipped transparently, in my experience. Indeed the CPs desire to ship to different devices / screens etc. is also transparent to the CDN, they're just different objects requested by logic that is out-of-band to the CDN. I know of cases where content is transcoded/modified for mobile access by transparent caching, for example. But TC is not relevant to CDNI. IMHO content adaption/modification/transcoding is not a fundamental issue for CDNI. The issues around solving the fundamentals of how to Interconnect CDN are challenging enough. So I feel we should focus the scope on widely deployed use-cases / features and very likely new use-cases that are created by CDNI. g- -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: 13 October 2011 05:02 To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, If the CP has tight integration with both CDN providers as you describe below, I do not see why they would need CDNI at all? What would be the benefit if they already have custom servers and security? Premium content providers that I am familiar with pregenerate content encodings, run them through rigorous quality control tests, and do not allow any modifications after that, to guarantee quality. To do that in a CDN, let alone across CDNs, seems unlikely. Content is processed in a secure facility and never released unencrypted to the CDN. The CDN just acts a transparent delivery medium. thanx. -- Kevin J. Ma > -----Original Message----- > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com] > Sent: Wednesday, October 12, 2011 11:25 PM > To: Kevin J Ma; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Kevin, > > As we ever discussed in previous email that the content format in fact > is decided by the CP. > Only under the permission, the HD video may be transformed to the > mobile video. i.e. if the CP support both IPTV and mobile video > service, then it may require the CDN to support multiple video > formats. The multi-screen service means the content source is from the > same CP while the target devices/clients include different groups. All > content businesses are under the permission of the content owner. > > For the content protection, I like talk a little more in this email > for > reference: > Given there are two areas: London and Paris. > And in these two areas, each has deployed the DRM. Generally each DRM > implementation is independent. > If the content is delivered from London to Paris, absolutely the whole > process should be granted by the CP. > For the DRM standard, it mainly concern the security on the terminal > and the interface between the SP/Client. > You may see that the servers that are granted by the CP is secure and > we do not need to worry that secure server would be the hacker. > Hence, if the content is delivered from one server to another server( > these servers are the equipments granted by CP that may handle and > encrypt the content), the content is safe. Whether decrypt/re-encrypt > or just deliver unencrypted content between these two servers are secure. > > Also, we may see such security issue for content distribution is a > general scenario that is not related to whether taking content adaptation. > > Thanks. > Zhipeng > > > > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Thursday, October 13, 2011 10:45 AM > To: ZhouZhipeng; Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > One practical concern to consider with the use case of downloading one > (as opposed to ten) streams is that premium content providers generally > are very concerned with quality control and are unlikely to trust dCDNs > to modify the content, and most likely, the content will be encrypted? > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > > Of ZhouZhipeng > > Sent: Wednesday, October 12, 2011 9:51 PM > > To: Ben Niven-Jenkins > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Ben, > > I respect your personal standpoint while seems you are only > > repeating > your > > personal conclusion without new reason/evidence. > > In my case, I have explained the uCDN may deliver 10 streams to the > dCDN. > > But in our reality, we should consider whether it is a proper > > solution that will be used by the market. > > If the standard may not support the market requirements, it is just > > the problem for its deployment. > > > > Meanwhile in my feeling you have not carefully thought about how it > > will bring to the standard. I have repeated it is very simple in > > fact and I > do > > not know whether you have any special concern that will make you > > feel it would not be able to be done within 18-24 months. > > Ben, as I repeat, if you have any question, I like respond via > > reflector or to you individually. > > Thanks. > > Zhipeng > > > > -----Original Message----- > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Sent: Thursday, October 13, 2011 1:13 AM > > To: ZhouZhipeng > > Cc: philip.eardley@bt.com; cdni@ietf.org > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > Zhipeng, > > > > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > > > > > Hello Ben, > > > The UE may select the content format on the CP web. After that the > user > > only desires to get his selected content. > > > But how the content is transferred to the client is not worried by > > > the > > user. > > > The CP may create a special format as required by the user and ask > > > the > > CDN to deliver to user. > > > While CP may give a HD format content to uCDN and the dCDN may > > > then > > transform to the format as the user select. > > > > Lots of things may be possible to do and CDN providers offer many > > additional services on top of the "core" service of content delivery. > > However, our objective (based on my interpretation of the CDNI > > charter) > is > > to focus on what is necessary to interconnect CDNs to deliver > > content > from > > a CSP to an End User that is targeted and deployable within a short > > time frame (18-24 months). > > > > Content transformation/adaptation is not an essential requirement in > order > > to achieve that aim (we can deliver content from CSPs to End Users > > via multiple CDNs without needing or requiring any CDN supports > > content adaptation). > > > > In my opinion we have enough work to do already without trying to > > expand the scope of our work to include additional requirements that > > do not > help > > us address our core objectives as laid out in the CDNI charter. > > > > > In this case, it is nothing related to how the user select formats > > > on > CP > > website. > > > So, it is the CP and user to decide the content format not the > CDN(your > > assert is not correct and seems you take that assert as your base > > for > the > > discussion). > > > > > > As for "the core CDN functionality offered by CDNs today", I have > > > ever > > raised an email before that your company's webpage has claimed > supporting > > media transformation and multi-screen service. > > > Perhaps, I like asking you list some features that you feel are > > > the > core > > functionalities by existing main stream CDNs. Thus we may compare > > and > take > > deep look. > > > > I think the core functionality maps pretty well to the CDNI > > interfaces, > > namely: Request Routing, Metadata configuration, log production and > > control plus content acquisition and content delivery. > > > > > I guess many people have the experience/knowledge of content > > > related > > service. The user and CP only care whether the CDN providers may > > satisfy their requirement while not care the internal process. Just > > as GSM/PSTN interconnection, the user only care successful > > interconnection while not care how the voice is transformed in process. > > > > > > Besides, I like raise a case: > > > Given currently BBC recruits CDN providers that may support 10 > > > media > > formats. > > > One candidate is your company, another is CDN-X. The users are > > > located > > in France. > > > So both your company and CDN-X should connect a France CDN > provider(CDN- > > Y). > > > If your company's solution is to send 10 streams of different > > > format > of > > one content to CDN-Y; > > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y > > > may > > conduct some adaptation. > > > Comparing these two solutions, for your company and CDN-X, > > > absolutely > > the cost of CDN-X is much lower. > > > For CDN-Y, in solution-1, it should receive/forward 10 streams ; > > > while > > in solution-2, it should only receive 1 stream but need to take > > transformation to output 10 streams. > > > > > > Which solution is more competitive. it is Solution 1, right. > > > Remember > > the price from BBC is same to both your company and CDN-X or BBC > > would select one CDN provider with the lower price. > > > If a CDN provider may not get the contract from CP, how it may say > > > it > is > > not a core functionality. > > > > What you are describing is a possible optimization that a particular > > CDN may wish to implement not a core functionality required to > > enable > content > > delivery between interconnected CDNs. I can think of many > > optimizations that a CDN could implement to differentiate their > > service but the > internal > > workings of an individual CDN are out of scope of our charter. > > > > So to repeat my position for a final time: Content adaptation is not > > a core function required to enable content delivery between > > interconnected CDNs and therefore given the workload we already have > > to specify > solutions > > that do address the core functionality required to interconnect CDNs > > I > do > > not think we should be trying to add more work into that workload as > > it will only distract us from achieving our goal of producing > > deployable solutions within the timeframe we are being told by > > operators they needs solutions within. > > > > Ben > > > > > So, if we all realize that currently the media type is rich, the > > > CDN > > providers should survive in the existing ecosystem and support the > > media types as required by the market. > > > > > > Back to the case of GSM/G.711, it just when concerning the > > interconnection, the transformation should at once be solved. > > Otherwise the interconnection may not be operated. > > > > > > Br, > > > Zhipeng > > > > > > > > > > > > > > > -----Original Message----- > > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > > Sent: Wednesday, October 12, 2011 12:19 AM > > > To: ZhouZhipeng > > > Cc: philip.eardley@bt.com; cdni@ietf.org > > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > > > > > Zhipeng, > > > > > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > > > > > >> Ben and Philip, > > >> I like to respond your concern in this one email: > > >> > > >> Ben, > > >> I feel what we are now discussing is what is the "core" function > > >> of > > CDN. > > >> As you say, CDN is used to deliver content. That is absolutely > correct > > that the delivery capability is the core requirement for CDN system. > > >> While CDN is used to provide the content delivery service. > > >> What means service. It should include "time" "location" and > > >> "media > > type", etc. These features are all the core feature for a service. > > >> If we only concern "delivering one data block", I am not sure > > >> whether > > the issues such as "logging" "geographic constraint" are the core of > CDN. > > >> > > >> For "without explicit knowledge of what that content actually is > > >> ", I > > am not sure whether the wording is accurate since generally a CDN > > may claim it support different medias. > > >> By this opportunity, I like to share a use case: a call from a > > >> GSM > > phone to a PSTN telephone, the voice stream should be transformed > > from > GSM > > voice to G.711. > > >> For the user, he does not need to know what type of data has been > > transferred, but the operator has done some work to interconnect two > > systems, right. > > >> I like to know whether you may accept that my use case is similar > > >> to > > this case above. > > > > > > I don't think your use case is similar to the analogy of mobile > networks > > being interconnected to PSTN networks. In the case of content > > delivery > the > > negotiation is done between the User/Client and the Content Provider > > and the CDN is just used to execute/perform the delivery that has > > been negotiated. The CDN is not involved in the decision making of > > what representations the Content Provider decides to offer to the > > User/Client or in what representations the User/Client decides to request. > > > > > >> As for you said selecting media by the "portal", you may see the > > >> way > " > > uCDN delivers multiple media streams to dCDN" is not good than "uCDN > > delivers one media stream to dCDN and dCDN takes some adaptation to > > support multiple media types". > > > > > > Now what you're talking about is an optimisation, not a core > > > function > > required to actually deliver the content (and report, bill, etc. for > that > > delivery). > > > > > > My position is that we should focus on how to enable the > interconnection > > of the core CDN functionality offered by CDNs today (which is also > > my interpretation of the scope of the CDNI working group as > > expressed in > its > > charter) because doing so is a significant piece of work in itself. > Let's > > not start trying to add in additional functionality beyond what the > > majority of CDNs support today as that will just delay us getting > > usable specifications into the market in a timely fashion IMO. > > > > > > Ben > > > > > >> A good question is "security" since I have done six years on the > > >> DRM > > and like to promote the DRM all around the world:) > > >> If the content is needed to be protected, generally you may know > > >> all > > the systems should be granted by the content owner. > > >> Here I also like to clarify that not only the media itself but > > >> the > > information related to service itself (such as the geographic > constraint) > > should be protected also. > > >> So, trust is not a problem for the media. > > >> > > >> Philip, > > >> Thank you that you feel Content Adaption is an issue for > "Requirements" > > but I do not know why it is not for Use case. > > >> I like to clarify to U that it is important for you operator > > >> since it > > may save investment if the system may support different services. > > >> For us vendor, we are happy operator may install a system for the > > mobile service and another system for the FBB service. > > >> But the reality is all operators ask us to provide a system that > > >> may > > support different service systems. > > >> > > >> Frankly, Ben and Philip, I remember I have explained somewhere > > >> that > to > > implement this is rather simple . > > >> At least the Use case and Requirement are informational to be > referred > > in future work. So I do really feel you may accept it. > > >> Of course I like to respond your more concern and comments. > > >> Thanks. > > >> Zhipeng > > >> > > >> > > >> > > >> -----Original Message----- > > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > > >> Sent: Monday, October 10, 2011 11:22 PM > > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Ben, Zhipeng, all, > > >> > > >> I think that Content Adaptation is more an issue for the > > >> Requirements > > doc than for the Use cases draft. > > >> > > >> The key question is whether we want the CDNI interfaces to be > > >> able to > > cope with a scenario where (say) HD/SD conversion is done in the > > dCDN & > to > > signal about this. > > >> > > >> I think that coping with this scenario is a second order > > >> requirement, > > ie we should not worry about it in the initial standards-track work. > > I don't know, did we ever decide whether the Use cases doc is > > restricted > to > > "initial" scenarios, or whether it's all-encompassing, ie covering > > "future" scenarios as well? > > >> > > >> Scott, > > >> Reading some of your examples, they seem to be valid even if > > >> content > > adaptation (HD/SD) is out of scope. > > >> - a dCDN might for some reason be unwilling to distribute HD? > > >> - a CSP might want to make sure the dCDN can use HLS encapsulation? > > >> But these sorts of examples seem to be static policy things (to > > >> do > with > > the capabilities & preferences of the CDNs & CSP), rather than > > metadata associated with a particular piece of content. In the > > discussion so far, > I > > think negotiation about static policy stuff is rather out of > > scope(?) > > >> > > >> On security considerations, an interesting question is whether > > >> trust > is > > transitive. Don't think it need be - just because CSP trusts uCDN, > > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts > > the > dCDN. > > However, i suspect this can get arbitrarily complex - so one > > possibility is to say that we will only handle cases where the trust is transitive. > > >> > > >> Best wishes > > >> phil > > >> > > >> > > >> Philip Eardley > > >> Research and Technology Strategy > > >> > > >> This email contains BT information, which may be privileged or > > confidential. It's meant only for the individual(s) or entity named > above. > > If you're not the intended recipient, note that disclosing, copying, > > distributing or using this information is prohibited. If you've > > received this email in error, please let me know immediately on the > > email address above. Thank you. We monitor our email system, and may > > record your > emails. > > >> British Telecommunications plc > > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered > > >> in England no: 1800000 > > >> > > >> > > >> -----Original Message----- > > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On > > >> Behalf > Of > > Ben Niven-Jenkins > > >> Sent: 10 October 2011 12:04 > > >> To: ZhouZhipeng > > >> Cc: cdni@ietf.org > > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >> > > >> Colleagues, > > >> > > >> IMO Section 5.1.3 should be removed from the Use Cases draft. > > >> Content > > Adaptation (i.e. taking in a content item in one format and > > transforming it to another format or representation) is not a "core" > > function of a > CDN > > which typically delivers the content that is requested without > > explicit knowledge of what that content actually is. > > >> > > >> Let's not forget that in building an end to end content service > > >> the > CDN > > is only one component and is the component tasked with executing the > > delivery of a specific representation (version/copy/format etc.) of > > the selected content not the component tasked with deciding (or > > applying > > policy) on which version/copy/representation of content should be > > delivered. > > >> > > >> The decision as to which version/copy/representation to offer and > allow > > to be delivered to a given device/user is implemented outside of the > > CDN (e.g. by the "portal" where the user first makes their content > > selection prior to the CDN becoming involved in the delivery of the > > selected content). > > >> > > >> Ben > > >> > > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > > >> > > >>> Following Scott's comments on section 5.1.3, I feel Scott's > > description on the use case of HD and SD is not exactly correct. > > >>> If one movie has two formats of HD and SD, then we have two > > >>> content > > with different identifier. In DRM scope, the basic unit is a content > copy. > > >>> > > >>> Here the first bullet "a subset of encodings deliverable to > > >>> specific > > devices," has listed the case of content adaptation. > > >>> In last month, I have contacted the Authors of this document and > taken > > some email exchanges with Grant and Philip (BT). > > >>> I have shown BT with some information that I know in this case > > >>> and > > area to explain the content flexibility is currently a basic > > requirement for CDN service and related negotiation is needed in the > > CDN interconnection. > > >>> Meanwhile, I should also invite you in this group raising your > > comments or questions on this case since I hope my use case may be > > incorporated in the use case draft. > > >>> > > >>> If you have any more question or comments, pls share in this thread. > > >>> Thanks. > > >>> Zhipeng > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -----Original Message----- > > >>> From: Scott Wainner [mailto:swainner@cisco.com] > > >>> Sent: Friday, September 30, 2011 8:02 AM > > >>> To: cdni@ietf.org > > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > >>> > > >>> Section 2.3 Nomadic Users > > >>> This description falls under the category of Geographic > > >>> Extension > yet > > >>> the third paragraph states the case where a different device is > > >>> used > > in > > >>> the same CDN coverage area. The intent of this use case needs > > >>> to be clarified. Perhaps the use case is trying to address the > > >>> scenario > > where > > >>> a Nomadic User-A with an agreement allowing access to content > > >>> from > > CSP-A > > >>> via uCDN moves to a dCDN in a different region. The dCDN is > > >>> allowed > > to > > >>> distribute the content of CSP-A to User-A; however, not other > > >>> users > in > > >>> the region of the dCDN are allowed to retrieve the content > > >>> unless > they > > >>> too have such an agreement. > > >>> > > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if > > >>> we're talking about the restrictions on the delivery of specific > > >>> content or the restrictions on the ability of a > > CDN > > >>> to deliver specific content. I certainly understand the case > > >>> where > a > > >>> CSP will restrict the distribution of content to a "managed > > >>> path" if such content is HD while allowing the content > > >>> distribution via an un-managed path if such content is SD (same > > >>> could apply to > encryption > > >>> methods, delivery methods, etc.). On the contrary, the dCDN may > have > > >>> its own restrictions of blocking the distribution of HD content > while > > >>> allowing the distribution of SD content. > > >>> > > >>> o first bullet makes sense if the dCDN can perform a subset of > > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but > > >>> not > > DASH) > > >>> o second bullet makes sense where the dCDN doesn't want to offer > high > > >>> bit-rate variants of the media > > >>> o third bullet make sense if the policy addresses QoE but I > > >>> don't think subscriber rights/authorizations apply. > > >>> > > >>> Section 10 Security Considerations > > >>> > > >>> Aside from the security considerations WITHIN the uCDN and dCDN, > > >>> I > > think > > >>> we can describe this in four contexts: > > >>> > > >>> a. The relationship between the CSP and the uCDN (the principle > > contract > > >>> arrangement for distribution) > > >>> b. The relationship between the uCDN and dCDN (the transitive > > >>> trust relationship that extends the contract defined in (a) > > >>> above) c. The relationship between the User and dCDN (the > > >>> recognition of > > right > > >>> to download predicated on (b) above) d. The relationship between > > >>> the User and CSP (the contract > authorizing > > >>> the user access to the content) > > >>> > > >>> The user is not interested in the a-b nor the b-c relationship. > > >>> The > > user > > >>> is only interested in the transparency and interoperability of > > >>> the security relationship between d-b or d-c to the point that > > >>> the authorization granted in d-a is viable when the delivery is > initiated > > >>> via either d-b or d-c. As an example, the uCDN might use URL > appended > > >>> tokens for authentication while dCDN might use URL appended hashes. > > The > > >>> user doesn't want to know about the distinct methods, but > transparency > > >>> is only afforded if the methods are interoperable clearly > > >>> defined > when > > >>> the delegation for content delivery is executed. Clearly, the > choice > > of > > >>> authentication method is determined by the respective CDN's. > > >>> > > >>> Scott > > >>> > > >>> _______________________________________________ > > >>> CDNi mailing list > > >>> CDNi@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/cdni > > >> > > >> _______________________________________________ > > >> CDNi mailing list > > >> CDNi@ietf.org > > >> https://www.ietf.org/mailman/listinfo/cdni > > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --Boundary_(ID_8tLGd+ZC/uZamYUGFdBHSA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Following this discussion, I think there are two basic questions for the WG to answer:

 

1.       Whether a capability negotiation is needed for an upstream CDN to select one eligible downstream CDN (assume that business is out of scope), provided that different CDNs have different “service profiles”.

 

2.       Whether content is transparent to current CDNs. If yes, there is NO transcoding/transrating kind of content adaptation in CDNs, and of course there will be NO parameter related to such kind of capability in CDNI scope.  If content is NOT transparent to current CDNs, then IMO CDNI has interoperability concerns to use the content adaptation parameters.

 

BR,

-Haibin

 

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of ZhouZhipeng
Sent: Friday, October 14, 2011 11:10 AM
To: Saurabh Chattopadhyay; grant.watson@bt.com
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

 

Saurabh,

 

On the core functionality as always.

Right now across the world, the convergence of mobile/internet/fixed system is the key requirement for the industry.

Generally CDN is not restricted to a special service. A CDN may support either web-TV delivery or managed IPTV service delivery.

 

The multi-screen service, means the CDN may deliver content to TV, PAD, PHONE, PC… any screen.

Because the PC may display HD while PHONE may only display small video, the content adaptation may be used before the CDN deliver content to each terminal.

 

This thread is raised from the concern: whether the protection will be a problem for the content adaptation.

If the people may know that content adaption has no impact for existing DRM,  our discussion has achieved good effect.

 

Thanks.

Zhipeng

 

 

From: Saurabh Chattopadhyay [mailto:saurabh.sdo@gmail.com]
Sent: Friday, October 14, 2011 1:31 AM
To: grant.watson@bt.com
Cc: ZhouZhipeng; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

 

Colleagues,

While I’m also of the opinion that the particular case is best left out of scope for now, I think the scoping shall get defined/refined in a more appropriate place, possibly in CDN-I problem statement draft.

Following is a relevant part from ‘draft-ietf-cdni-problem-statement’ –

“NSPs have often deployed CDNs as specialized cost-reduction projects

   within the context of a particular service or environment, some NSPs

   operate separate CDNs for separate services.  For example, there may

   be a CDN for managed IPTV service delivery, a CDN for web-TV delivery

   and a CDN for video delivery to Mobile terminals.  As NSPs integrate

   their service portfolio, there is a need for interconnecting these

   CDNs.  Again, NSPs face the problem of lack of open interfaces for

   CDN interconnection.

”

Unquestionably, primary responsibility of CDN-I is to standardize open interfaces for core content delivery function, however, while the CDNs adopt the particular Service Profiles, the scope of CDN-I gets naturally extended to interconnect the different service profiles. To clarify, a CDN for Video Delivery to Mobile Terminals, to me is a CDN adopting Service Profile of ‘Video Delivery to Mobile Terminals’. And current discussion on Content Adaptation appears as a particular case for interconnecting CDNs of different Service Profiles.

To that end, many aspects of ongoing work will get questioned to realize the extent of the interconnection use cases supporting Service Portfolio transformations and whether to be considered part of the current scope or not.

IMHO the overall work needs to be staged in a manner that core Content Delivery Function gets the immediate attention, and subsequently the work group shall decide on the relevant part of service profile interconnection to standardize till required extent.

Regards,

Saurabh



 

On Thu, Oct 13, 2011 at 6:10 PM, <grant.watson@bt.com> wrote:

Hi,


"May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI."

Just like it works right now: If objects are encrypted differently or use different DRMs generally it translates as separate objects in the CDN, Interconnected or otherwise. DRM is implemented by the CP, in the knowledge of what end devices and DRM platforms they are delivering to. IMHO that works right now and would work in a CDNI scenario.

Frankly, I am even more convinced that this is best left out of scope now. IMHO duplication of content assets inside the CDN to facilitate cross DRM delivery is not a CDNI issue. I can see how this may be optimised perhaps, to reduce the amount of assets for example, but again that is not a CDNI issue - the issue exists for both CDN today and Interconnected CDN.

g-



-----Original Message-----
From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com]

Sent: 13 October 2011 13:12

To: Watson,G,Grant,DMK5 R; kevin.ma@azukisystems.com; ben@niven-jenkins.co.uk
Cc: cdni@ietf.org
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Grant,
Nice to see your comment.
May I conclude that by now the core issue for the content adaptation is " content protection".
As a DRM people for years, I fully understand this concern.
In fact the DRM circle have fully understood this concern since DRM should consider both the protection and the service implementation.

May I ask a question, if the content has been encrypted and would not be modified in the CDNI process, but the devices in two areas have deployed different DRM system, how it will be for the CDNI.
It is not related to the content transcoding while you still face the issue for the protection transformation. For example, how your company's IPTV may connect the FT's terminals.

Even in the internet that the PCs in different area may install the same soft DRM client, it may still has the problem of the content's duplication and content's verification(integrity protection).
Take the OMA DRM DCF as an example, each content copy has its unique identifier(contentId) and each content copy has its unique Hash value.
Hence in OMA DRM system, you( the device) may not duplicate a protected content copy that may be verified successfully by the device.
Only the CP that encrypt the content may create a new copy of the content with another identifier.

While in CDN system, we all know for the load balancing the CDN should be able to duplicate the hot content when needed. How it may be realized if the CDN may not create a new content copy that comply with the DRM solution.

So you may see, there should be a secure facility within the CDN that may create/encrypt the content which may be accepted by the DRM client.

Above is my analysis on this issue. Hope you may take a look at the OMA DRM specification to check the reason.
For any question, I would like to respond as long as I know.
Also note that the analysis is not specific to the content adaptation. I mean only general functionality of CDN.
Thanks.
Zhipeng

-----Original Message-----
From: grant.watson@bt.com [mailto:grant.watson@bt.com]
Sent: Thursday, October 13, 2011 6:34 PM
To: kevin.ma@azukisystems.com; ZhouZhipeng; ben@niven-jenkins.co.uk
Cc: cdni@ietf.org
Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

I'd support that perspective. Today CPs, in my experience, sometimes even actively seeks assurances that the content will NOT be modified by the CDN or by other downstream processes. So to envisage a CP allowing/wanting that to happen in a dCDN (that is likely out of their control, perhaps in another geography and with no quality feedback) feels like a very, very unlikely scenario. In general the content arrives encrypted and is shipped transparently, in my experience. Indeed the CPs desire to ship to different devices / screens etc. is also transparent to the CDN, they're just different objects requested by logic that is out-of-band to the CDN.

I know of cases where content is transcoded/modified for mobile access by transparent caching, for example. But TC is not relevant to CDNI.

IMHO content adaption/modification/transcoding is not a fundamental issue for CDNI. The issues around solving the fundamentals of how to Interconnect CDN are challenging enough. So I feel we should focus the scope on widely deployed use-cases / features and very likely new use-cases that are created by CDNI.

g-

-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma
Sent: 13 October 2011 05:02
To: ZhouZhipeng; Ben Niven-Jenkins
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

 If the CP has tight integration with both CDN providers as you describe
 below, I do not see why they would need CDNI at all?  What would be the
 benefit if they already have custom servers and security?

 Premium content providers that I am familiar with pregenerate content
 encodings, run them through rigorous quality control tests, and do
 not allow any modifications after that, to guarantee quality.  To do
 that in a CDN, let alone across CDNs, seems unlikely.  Content is
 processed in a secure facility and never released unencrypted to the
 CDN.  The CDN just acts a transparent delivery medium.

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com]
> Sent: Wednesday, October 12, 2011 11:25 PM
> To: Kevin J Ma; Ben Niven-Jenkins
> Cc: cdni@ietf.org
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Kevin,
>
> As we ever discussed in previous email that the content format in fact
> is decided by the CP.
> Only under the permission, the HD video may be transformed to the
> mobile video. i.e. if the CP support both IPTV and mobile video
> service, then it may require the CDN to support multiple video
> formats. The multi-screen service means the content source is from the
> same CP while the target devices/clients include different groups. All
> content businesses are under the permission of the content owner.
>
> For the content protection, I like talk a little more in this email
> for
> reference:
> Given there are two areas: London and Paris.
> And in these two areas, each has deployed the DRM. Generally each DRM
> implementation is independent.
> If the content is delivered from London to Paris, absolutely the whole
> process should be granted by the CP.
> For the DRM standard, it mainly concern the security on the terminal
> and the interface between the SP/Client.
> You may see that the servers that are granted by the CP is secure and
> we do not need to worry that secure server would be the hacker.
> Hence, if the content is delivered from one server to another server(
> these servers are the equipments granted by CP that may handle and
> encrypt the content), the content is safe. Whether decrypt/re-encrypt
> or just deliver unencrypted content between these two servers are secure.
>
> Also, we may see such security issue for content distribution is a
> general scenario that is not related to whether taking content adaptation.
>
> Thanks.
> Zhipeng
>
>
>
> -----Original Message-----
> From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]
> Sent: Thursday, October 13, 2011 10:45 AM
> To: ZhouZhipeng; Ben Niven-Jenkins
> Cc: cdni@ietf.org
> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
>
> Zhipeng,
>
>   One practical concern to consider with the use case of downloading one
>   (as opposed to ten) streams is that premium content providers generally
>   are very concerned with quality control and are unlikely to trust dCDNs
>   to modify the content, and most likely, the content will be encrypted?
>
> thanx.
>
> --  Kevin J. Ma
>
> > -----Original Message-----
> > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf
> > Of ZhouZhipeng
> > Sent: Wednesday, October 12, 2011 9:51 PM
> > To: Ben Niven-Jenkins
> > Cc: cdni@ietf.org
> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> >
> > Ben,
> > I respect your personal standpoint while seems you are only
> > repeating
> your
> > personal conclusion without new reason/evidence.
> > In my case, I have explained the uCDN may deliver 10 streams to the
> dCDN.
> > But in our reality, we should consider whether it is a proper
> > solution that will be used by the market.
> > If the standard may not support the market requirements, it is just
> > the problem for its deployment.
> >
> > Meanwhile in my feeling you have not carefully thought about how it
> > will bring to the standard. I have repeated it is very simple in
> > fact and I
> do
> > not know whether you have any special concern that will make you
> > feel it would not be able to be done within 18-24 months.
> > Ben, as I repeat, if you have any question, I like respond via
> > reflector or to you individually.
> > Thanks.
> > Zhipeng
> >
> > -----Original Message-----
> > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> > Sent: Thursday, October 13, 2011 1:13 AM
> > To: ZhouZhipeng
> > Cc: philip.eardley@bt.com; cdni@ietf.org
> > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> >
> > Zhipeng,
> >
> > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote:
> >
> > > Hello Ben,
> > > The UE may select the content format on the CP web. After that the
> user
> > only desires to get his selected content.
> > > But how the content is transferred to the client is not worried by
> > > the
> > user.
> > > The CP may create a special format as required by the user and ask
> > > the
> > CDN to deliver to user.
> > > While CP may give a HD format content to uCDN and the dCDN may
> > > then
> > transform to the format as the user select.
> >
> > Lots of things may be possible to do and CDN providers offer many
> > additional services on top of the "core" service of content delivery.
> > However, our objective (based on my interpretation of the CDNI
> > charter)
> is
> > to focus on what is necessary to interconnect CDNs to deliver
> > content
> from
> > a CSP to an End User that is targeted and deployable within a short
> > time frame (18-24 months).
> >
> > Content transformation/adaptation is not an essential requirement in
> order
> > to achieve that aim (we can deliver content from CSPs to End Users
> > via multiple CDNs without needing or requiring any CDN supports
> > content adaptation).
> >
> > In my opinion we have enough work to do already without trying to
> > expand the scope of our work to include additional requirements that
> > do not
> help
> > us address our core objectives as laid out in the CDNI charter.
> >
> > > In this case, it is nothing related to how the user select formats
> > > on
> CP
> > website.
> > > So, it is the CP and user to decide the content format not the
> CDN(your
> > assert is not correct and seems you take that assert as your base
> > for
> the
> > discussion).
> > >
> > > As for "the core CDN functionality offered by CDNs today", I have
> > > ever
> > raised an email before that your company's webpage has claimed
> supporting
> > media transformation and multi-screen service.
> > > Perhaps, I like asking you list some features that you feel are
> > > the
> core
> > functionalities by existing main stream CDNs. Thus we may compare
> > and
> take
> > deep look.
> >
> > I think the core functionality maps pretty well to the CDNI
> > interfaces,
> > namely: Request Routing, Metadata configuration, log production and
> > control plus content acquisition and content delivery.
> >
> > > I guess many people have the experience/knowledge of content
> > > related
> > service. The user and CP only care whether the CDN providers may
> > satisfy their requirement while not care the internal process. Just
> > as GSM/PSTN interconnection, the user only care successful
> > interconnection while not care how the voice is transformed in process.
> > >
> > > Besides, I like raise a case:
> > > Given currently BBC recruits CDN providers that may support 10
> > > media
> > formats.
> > > One candidate is your company, another is CDN-X. The users are
> > > located
> > in France.
> > > So both your company and CDN-X should connect a France CDN
> provider(CDN-
> > Y).
> > > If your company's solution is to send 10 streams of different
> > > format
> of
> > one content to CDN-Y;
> > > While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y
> > > may
> > conduct some adaptation.
> > > Comparing these two solutions, for your company and CDN-X,
> > > absolutely
> > the cost of CDN-X is much lower.
> > > For CDN-Y, in solution-1, it should receive/forward 10 streams ;
> > > while
> > in solution-2, it should only receive 1 stream but need to take
> > transformation to output 10 streams.
> > >
> > > Which solution is more competitive. it is Solution 1, right.
> > > Remember
> > the price from BBC is same to both your company and CDN-X or BBC
> > would select one CDN provider with the lower price.
> > > If a CDN provider may not get the contract from CP, how it may say
> > > it
> is
> > not a core functionality.
> >
> > What you are describing is a possible optimization that a particular
> > CDN may wish to implement not a core functionality required to
> > enable
> content
> > delivery between interconnected CDNs. I can think of many
> > optimizations that a CDN could implement to differentiate their
> > service but the
> internal
> > workings of an individual CDN are out of scope of our charter.
> >
> > So to repeat my position for a final time: Content adaptation is not
> > a core function required to enable content delivery between
> > interconnected CDNs and therefore given the workload we already have
> > to specify
> solutions
> > that do address the core functionality required to interconnect CDNs
> > I
> do
> > not think we should be trying to add more work into that workload as
> > it will only distract us from achieving our goal of producing
> > deployable solutions within the timeframe we are being told by
> > operators they needs solutions within.
> >
> > Ben
> >
> > > So, if we all realize that currently the media type is rich, the
> > > CDN
> > providers should survive in the existing ecosystem and support the
> > media types as required by the market.
> > >
> > > Back to the case of GSM/G.711, it just when concerning the
> > interconnection, the transformation should at once be solved.
> > Otherwise the interconnection may not be operated.
> > >
> > > Br,
> > > Zhipeng
> > >
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]
> > > Sent: Wednesday, October 12, 2011 12:19 AM
> > > To: ZhouZhipeng
> > > Cc: philip.eardley@bt.com; cdni@ietf.org
> > > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >
> > > Zhipeng,
> > >
> > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote:
> > >
> > >> Ben and Philip,
> > >> I like to respond your concern in this one email:
> > >>
> > >> Ben,
> > >> I feel what we are now discussing is what is the "core" function
> > >> of
> > CDN.
> > >> As you say, CDN is used to deliver content. That is absolutely
> correct
> > that the delivery capability is the core requirement for CDN system.
> > >> While CDN is used to provide the content delivery service.
> > >> What means service. It should include "time" "location" and
> > >> "media
> > type", etc. These features are all the core feature for a service.
> > >> If we only concern "delivering one data block", I am not sure
> > >> whether
> > the issues such as "logging" "geographic constraint" are the core of
> CDN.
> > >>
> > >> For "without explicit knowledge of what that content actually is
> > >> ", I
> > am not sure whether the wording is accurate since generally a CDN
> > may claim it support different medias.
> > >> By this opportunity, I like to share a use case: a call from a
> > >> GSM
> > phone to a PSTN telephone, the voice stream should be transformed
> > from
> GSM
> > voice to G.711.
> > >> For the user, he does not need to know what type of data has been
> > transferred, but the operator has done some work to interconnect two
> > systems, right.
> > >> I like to know whether you may accept that my use case is similar
> > >> to
> > this case above.
> > >
> > > I don't think your use case is similar to the analogy of mobile
> networks
> > being interconnected to PSTN networks. In the case of content
> > delivery
> the
> > negotiation is done between the User/Client and the Content Provider
> > and the CDN is just used to execute/perform the delivery that has
> > been negotiated. The CDN is not involved in the decision making of
> > what representations the Content Provider decides to offer to the
> > User/Client or in what representations the User/Client decides to request.
> > >
> > >> As for you said selecting media by the "portal", you may see the
> > >> way
> "
> > uCDN delivers multiple media streams to dCDN" is not good than "uCDN
> > delivers one media stream to dCDN and dCDN takes some adaptation to
> > support multiple media types".
> > >
> > > Now what you're talking about is an optimisation, not a core
> > > function
> > required to actually deliver the content (and report, bill, etc. for
> that
> > delivery).
> > >
> > > My position is that we should focus on how to enable the
> interconnection
> > of the core CDN functionality offered by CDNs today (which is also
> > my interpretation of the scope of the CDNI working group as
> > expressed in
> its
> > charter) because doing so is a significant piece of work in itself.
> Let's
> > not start trying to add in additional functionality beyond what the
> > majority of CDNs support today as that will just delay us getting
> > usable specifications into the market in a timely fashion IMO.
> > >
> > > Ben
> > >
> > >> A good question is "security" since I have done six years on the
> > >> DRM
> > and like to promote the DRM all around the world:)
> > >> If the content is needed to be protected, generally you may know
> > >> all
> > the systems should be granted by the content owner.
> > >> Here I also like to clarify that not only the media itself but
> > >> the
> > information related to service itself (such as the geographic
> constraint)
> > should be protected also.
> > >> So, trust is not a problem for the media.
> > >>
> > >> Philip,
> > >> Thank you that you feel Content Adaption is an issue for
> "Requirements"
> > but I do not know why it is not for Use case.
> > >> I like to clarify to U that it is important for you operator
> > >> since it
> > may save investment if the system may support different services.
> > >> For us vendor, we are happy operator may install a system for the
> > mobile service and another system for the FBB service.
> > >> But the reality is all operators ask us to provide a system that
> > >> may
> > support different service systems.
> > >>
> > >> Frankly, Ben and Philip, I remember I have explained somewhere
> > >> that
> to
> > implement this is rather simple .
> > >> At least the Use case and Requirement are informational to be
> referred
> > in future work. So I do really feel you may accept it.
> > >> Of course I like to respond your more concern and comments.
> > >> Thanks.
> > >> Zhipeng
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]
> > >> Sent: Monday, October 10, 2011 11:22 PM
> > >> To: ben@niven-jenkins.co.uk; ZhouZhipeng
> > >> Cc: cdni@ietf.org
> > >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >>
> > >> Ben, Zhipeng, all,
> > >>
> > >> I think that Content Adaptation is more an issue for the
> > >> Requirements
> > doc than for the Use cases draft.
> > >>
> > >> The key question is whether we want the CDNI interfaces to be
> > >> able to
> > cope with a scenario where (say) HD/SD conversion is done in the
> > dCDN &
> to
> > signal about this.
> > >>
> > >> I think that coping with this scenario is a second order
> > >> requirement,
> > ie we should not worry about it in the initial standards-track work.
> > I don't know, did we ever decide whether the Use cases doc is
> > restricted
> to
> > "initial" scenarios, or whether it's all-encompassing, ie covering
> > "future" scenarios as well?
> > >>
> > >> Scott,
> > >> Reading some of your examples, they seem to be valid even if
> > >> content
> > adaptation (HD/SD) is out of scope.
> > >> - a dCDN might for some reason be unwilling to distribute HD?
> > >> - a CSP might want to make sure the dCDN can use HLS encapsulation?
> > >> But these sorts of examples seem to be static policy things (to
> > >> do
> with
> > the capabilities & preferences of the CDNs & CSP), rather than
> > metadata associated with a particular piece of content. In the
> > discussion so far,
> I
> > think negotiation about static policy stuff is rather out of
> > scope(?)
> > >>
> > >> On security considerations, an interesting question is whether
> > >> trust
> is
> > transitive. Don't think it need be - just because CSP trusts uCDN,
> > and uCDN trusts dCDN doesn't mean that the CSP automatically trusts
> > the
> dCDN.
> > However, i suspect this can get arbitrarily complex - so one
> > possibility is to say that we will only handle cases where the trust is transitive.
> > >>
> > >> Best wishes
> > >> phil
> > >>
> > >>
> > >> Philip Eardley
> > >> Research and Technology Strategy
> > >>
> > >> This email contains BT information, which may be privileged or
> > confidential. It's meant only for the individual(s) or entity named
> above.
> > If you're not the intended recipient, note that disclosing, copying,
> > distributing or using this information is prohibited. If you've
> > received this email in error, please let me know immediately on the
> > email address above. Thank you. We monitor our email system, and may
> > record your
> emails.
> > >> British Telecommunications plc
> > >> Registered office: 81 Newgate Street London EC1A 7AJ Registered
> > >> in England no: 1800000
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On
> > >> Behalf
> Of
> > Ben Niven-Jenkins
> > >> Sent: 10 October 2011 12:04
> > >> To: ZhouZhipeng
> > >> Cc: cdni@ietf.org
> > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >>
> > >> Colleagues,
> > >>
> > >> IMO Section 5.1.3 should be removed from the Use Cases draft.
> > >> Content
> > Adaptation (i.e. taking in a content item in one format and
> > transforming it to another format or representation) is not a "core"
> > function of a
> CDN
> > which typically delivers the content that is requested without
> > explicit knowledge of what that content actually is.
> > >>
> > >> Let's not forget that in building an end to end content service
> > >> the
> CDN
> > is only one component and is the component tasked with executing the
> > delivery of a specific representation (version/copy/format etc.) of
> > the selected content not the component tasked with deciding (or
> > applying
> > policy) on which version/copy/representation of content should be
> > delivered.
> > >>
> > >> The decision as to which version/copy/representation to offer and
> allow
> > to be delivered to a given device/user is implemented outside of the
> > CDN (e.g. by the "portal" where the user first makes their content
> > selection prior to the CDN becoming involved in the delivery of the
> > selected content).
> > >>
> > >> Ben
> > >>
> > >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote:
> > >>
> > >>> Following Scott's comments on section 5.1.3, I feel Scott's
> > description on the use case of HD and SD is not exactly correct.
> > >>> If one movie has two formats of HD and SD, then we have two
> > >>> content
> > with different identifier. In DRM scope, the basic unit is a content
> copy.
> > >>>
> > >>> Here the first bullet "a subset of encodings deliverable to
> > >>> specific
> > devices," has listed the case of content adaptation.
> > >>> In last month, I have contacted the Authors of this document and
> taken
> > some email exchanges with Grant and Philip (BT).
> > >>> I have shown BT with some information that I know in this case
> > >>> and
> > area to explain the content flexibility is currently a basic
> > requirement for CDN service and related negotiation is needed in the
> > CDN interconnection.
> > >>> Meanwhile, I should also invite you in this group raising your
> > comments or questions on this case since I hope my use case may be
> > incorporated in the use case draft.
> > >>>
> > >>> If you have any more question or comments, pls share in this thread.
> > >>> Thanks.
> > >>> Zhipeng
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>> -----Original Message-----
> > >>> From: Scott Wainner [mailto:swainner@cisco.com]
> > >>> Sent: Friday, September 30, 2011 8:02 AM
> > >>> To: cdni@ietf.org
> > >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt
> > >>>
> > >>> Section 2.3 Nomadic Users
> > >>> This description falls under the category of Geographic
> > >>> Extension
> yet
> > >>> the third paragraph states the case where a different device is
> > >>> used
> > in
> > >>> the same CDN coverage area.  The intent of this use case needs
> > >>> to be clarified.  Perhaps the use case is trying to address the
> > >>> scenario
> > where
> > >>> a Nomadic User-A with an agreement allowing access to content
> > >>> from
> > CSP-A
> > >>> via uCDN moves to a dCDN in a different region.  The dCDN is
> > >>> allowed
> > to
> > >>> distribute the content of CSP-A to User-A; however, not other
> > >>> users
> in
> > >>> the region of the dCDN are allowed to retrieve the content
> > >>> unless
> they
> > >>> too have such an agreement.
> > >>>
> > >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if
> > >>> we're talking about the restrictions on the delivery of specific
> > >>> content or the restrictions on the ability of a
> > CDN
> > >>> to deliver specific content.  I certainly understand the case
> > >>> where
> a
> > >>> CSP will restrict the distribution of content to a "managed
> > >>> path" if such content is HD while allowing the content
> > >>> distribution via an un-managed path if such content is SD (same
> > >>> could apply to
> encryption
> > >>> methods, delivery methods, etc.).  On the contrary, the dCDN may
> have
> > >>> its own restrictions of blocking the distribution of HD content
> while
> > >>> allowing the distribution of SD content.
> > >>>
> > >>> o first bullet makes sense if the dCDN can perform a subset of
> > >>> encapsulations for a reference set of media (e.g. HLS, HSS, but
> > >>> not
> > DASH)
> > >>> o second bullet makes sense where the dCDN doesn't want to offer
> high
> > >>> bit-rate variants of the media
> > >>> o third bullet make sense if the policy addresses QoE but I
> > >>> don't think subscriber rights/authorizations apply.
> > >>>
> > >>> Section 10 Security Considerations
> > >>>
> > >>> Aside from the security considerations WITHIN the uCDN and dCDN,
> > >>> I
> > think
> > >>> we can describe this in four contexts:
> > >>>
> > >>> a. The relationship between the CSP and the uCDN (the principle
> > contract
> > >>> arrangement for distribution)
> > >>> b. The relationship between the uCDN and dCDN (the transitive
> > >>> trust relationship that extends the contract defined in (a)
> > >>> above) c. The relationship between the User and dCDN (the
> > >>> recognition of
> > right
> > >>> to download predicated on (b) above) d. The relationship between
> > >>> the User and CSP (the contract
> authorizing
> > >>> the user access to the content)
> > >>>
> > >>> The user is not interested in the a-b nor the b-c relationship.
> > >>> The
> > user
> > >>> is only interested in the transparency and interoperability of
> > >>> the security relationship between d-b or d-c to the point that
> > >>> the authorization granted in d-a is viable when the delivery is
> initiated
> > >>> via either d-b or d-c.  As an example, the uCDN might use URL
> appended
> > >>> tokens for authentication while dCDN might use URL appended hashes.
> > The
> > >>> user doesn't want to know about the distinct methods, but
> transparency
> > >>> is only afforded if the methods are interoperable clearly
> > >>> defined
> when
> > >>> the delegation for content delivery is executed.  Clearly, the
> choice
> > of
> > >>> authentication method is determined by the respective CDN's.
> > >>>
> > >>> Scott
> > >>>
> > >>> _______________________________________________
> > >>> CDNi mailing list
> > >>> CDNi@ietf.org
> > >>> https://www.ietf.org/mailman/listinfo/cdni
> > >>
> > >> _______________________________________________
> > >> CDNi mailing list
> > >> CDNi@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/cdni
> > >
> >
> > _______________________________________________
> > CDNi mailing list
> > CDNi@ietf.org
> > https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

 

--Boundary_(ID_8tLGd+ZC/uZamYUGFdBHSA)-- From hexiaoyan@huawei.com Tue Oct 18 02:47:50 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E537321F8B07 for ; Tue, 18 Oct 2011 02:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFY0hCcTMjKt for ; Tue, 18 Oct 2011 02:47:46 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id C698921F8B5C for ; Tue, 18 Oct 2011 02:47:45 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT900F089QB2X@szxga05-in.huawei.com> for cdni@ietf.org; Tue, 18 Oct 2011 17:44:36 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LT900D159Q4PB@szxga05-in.huawei.com> for cdni@ietf.org; Tue, 18 Oct 2011 17:44:35 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEH27448; Tue, 18 Oct 2011 17:44:34 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 17:44:30 +0800 Received: from w36710x (10.144.242.117) by smtpscn.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 18 Oct 2011 17:44:26 +0800 Date: Tue, 18 Oct 2011 17:44:26 +0800 From: HeXiaoyan In-reply-to: X-Originating-IP: [10.144.242.117] To: 'Francois Le Faucheur' , 'Kevin J Ma' Message-id: <003201cc8d7a$86a15bb0$93e41310$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_9eUhh7iTg29vNGkWGK4JOA)" Content-language: zh-cn Thread-index: AcyNMnW7+MtMAHGyQXqMUt0VRIe37gARimQQ X-CFilter-Loop: Reflected References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 09:47:51 -0000 --Boundary_(ID_9eUhh7iTg29vNGkWGK4JOA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Francois, > * the concept of "hostnames" should be made more flexible so it matches not just on hostnames but on pattern match over hostname/path. Let's call this "resource sets". * "resource sets" should be dependent on "Agents". So perhaps it shoudl be folded inside your "Metadata" so it can be defined on a per "dCDN" basis. Are you proposing remove the "hostname" object or keep it and adding "resource sets" to "Metadata"? I think the "hostname" object should be kept as sometimes the customer would possibly deploy a enforcement policy associated to a hostname , e.g. for hostname associated with a set of web pages, CP may prefer DNS routing as HTTP redirection will cause cookie issues among others. Keeping hostname level can provide cp with this flexibility. Best Regards Xiaoyan(Susan) He From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur Sent: Tuesday, October 18, 2011 3:43 AM To: Kevin J Ma Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Metadata Interface Hello Kevin, [with Individual hat on] A first set of high level questions: * directionality of metadata creation/retrieval/removal/update mechanism: Could you clarify which of the above operation you see possibly happening in which direction? For example, regarding update/removal, do you see: *a) the POST possibly being issued towards the uCDN to update/remove some metadata in the uCDN repository? *b) the POST possibly being issued by the uCDN towards the dCDN to update/remove some metadata in the dCDN repository (after some out-of-date metadata had been retrieved by dCDN from uCDN). For example, regarding retrieval, clearly we want the dCDN to issue a GET towards the uCDN to acquire metadata. Now do you see that the GET could possibly be also issued by the uCDN to check metadata stored by the dCDN? * in your CDNI metadata model, a "domain" is directly associated with a set of "hostnames". So this assumes that the same set of unmodified hostnames is used unmodified everywhere in all the potential dCDNs. That can be the case in some deployment, but that may not always be the case. For example, when HTTP redirection is used across CDNs, an upstream CDN may want to modify (possibly hide) the actual content provider hostnames (and possibly part of the URI path) when redirecting to a dCDN (I believe this is mentioned in the framework). Would you consider modifying your proposed CDNI model to allow for the fact that a domain may be "referenced" differently by some dCDNs than by the uCDN? I think it means: * the concept of "hostnames" should be made more flexible so it matches not just on hostnames but on pattern match over hostname/path. Let's call this "resource sets". * "resource sets" should be dependent on "Agents". So perhaps it shoudl be folded inside your "Metadata" so it can be defined on a per "dCDN" basis. Would that work for you? * in section 3.3.3, you have a couple of examples showing "/CDNI/MI/domain". Should those not say "/CDNI/MI/metadata"? Cheers Francois On 6 Oct 2011, at 22:21, Kevin J Ma wrote: Hi all, Just uploaded a new I-D with a proposed metadata model and API: http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt The model takes a rather generic approach to metadata representation to support opaque metadata and addresses some of the security issues associated with metadata retrieval. Comments welcome. thanx. -- Kevin J. Ma _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --Boundary_(ID_9eUhh7iTg29vNGkWGK4JOA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Francois,

>     * the concept of "hostnames" should be made more flexible so it matches not just on hostnames but on pattern match over hostname/path. Let's call this "resource sets".

       * "resource sets" should be dependent on "Agents". So perhaps it shoudl be folded inside your "Metadata" so it can be defined on a per "dCDN" basis.

 

Are you proposing remove the “hostname” object or keep it and adding “resource sets” to “Metadata”?

I think the “hostname” object should be kept as sometimes the customer would possibly deploy a enforcement policy associated to a hostname , e.g. for hostname associated with  a set of web pages, CP may prefer DNS routing as HTTP redirection will cause cookie issues among others. Keeping hostname level can provide cp with this flexibility.  

 

Best Regards

Xiaoyan(Susan) He

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur
Sent: Tuesday, October 18, 2011 3:43 AM
To: Kevin J Ma
Cc: cdni@ietf.org
Subject: Re: [CDNi] CDNI Metadata Interface

 

Hello Kevin,

 

[with Individual hat on]

 

A first set of high level questions:

 

* directionality of metadata creation/retrieval/removal/update mechanism:

Could you clarify which of the above operation you see possibly happening in which direction?

For example, regarding update/removal, do you see:

       *a)  the POST possibly being issued towards the uCDN to update/remove some metadata in the uCDN repository?

       *b) the POST possibly being issued by the uCDN towards the dCDN to update/remove some metadata in the dCDN repository (after some out-of-date metadata had been retrieved by dCDN from uCDN).

For example, regarding retrieval, clearly we want the dCDN to issue a GET towards the uCDN to acquire metadata. Now do you see that the GET could possibly be also issued by the uCDN to check metadata stored by the dCDN?

 

* in your CDNI metadata model, a "domain" is directly associated with a set of "hostnames". So this assumes that the same set of unmodified hostnames is used unmodified everywhere in all the potential dCDNs. That can be the case in some deployment, but that may not always be the case. For example, when HTTP redirection is used across CDNs, an upstream CDN may want to modify (possibly hide) the actual content provider hostnames (and possibly part of the URI path) when redirecting to a dCDN (I believe this is mentioned in the framework). 

Would you consider modifying your proposed CDNI model to allow for the fact that a domain may be "referenced" differently by some dCDNs than by the uCDN?

I think it means:

       * the concept of "hostnames" should be made more flexible so it matches not just on hostnames but on pattern match over hostname/path. Let's call this "resource sets".

       * "resource sets" should be dependent on "Agents". So perhaps it shoudl be folded inside your "Metadata" so it can be defined on a per "dCDN" basis.

Would that work for you?

 

* in section 3.3.3, you have a couple of examples showing "/CDNI/MI/domain". Should those not say "/CDNI/MI/metadata"?

 

 

Cheers

 

Francois

 

      

 

 

On 6 Oct 2011, at 22:21, Kevin J Ma wrote:



Hi all,

 Just uploaded a new I-D with a proposed metadata model and API:

   http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt

 The model takes a rather generic approach to metadata representation
 to support opaque metadata and addresses some of the security issues
 associated with metadata retrieval.  Comments welcome.

thanx.

--  Kevin J. Ma

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

 

 

--Boundary_(ID_9eUhh7iTg29vNGkWGK4JOA)-- From ben@niven-jenkins.co.uk Tue Oct 18 03:36:40 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EC321F88A0 for ; Tue, 18 Oct 2011 03:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.435 X-Spam-Level: X-Spam-Status: No, score=-103.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0TdSV1dKgRZ for ; Tue, 18 Oct 2011 03:36:40 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 164D721F889A for ; Tue, 18 Oct 2011 03:36:40 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RG72E-0001EC-NS; Tue, 18 Oct 2011 11:36:39 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins X-Priority: 3 In-Reply-To: <941019F76B914748AE9E703ADFE5E79E@china.huawei.com> Date: Tue, 18 Oct 2011 11:36:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <941019F76B914748AE9E703ADFE5E79E@china.huawei.com> To: Spencer Dawkins X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 10:36:41 -0000 Spencer, Apologies for the delay in responding, your mail got buried in my inbox. On 6 Oct 2011, at 18:07, Spencer Dawkins wrote: > Hi, Ben, >=20 > Just checking - would this draft be the place where text on handling = of unknown metadata elements would be included? Good question. It depends what you mean by "unknown". I think our draft is definitely the place to specify handling of = malformed responses. The actual properties associated with the metadata can be split into two = parts: 1) Delivery protocol independent properties (e.g. ACLs/Locations/Origin = properties) 2) Delivery protocol dependent properties (e.g. specific features = associated with a particular delivery protocol or version of a delivery = protocol) Currently the draft defines some protocol independent properties but = doesn't really define any protocol dependent properties. The metadata draft uses a well-known (i.e. has to be registered in a = registry somewhere) URI to identify the Delivery Protocol where the URI = is really just a different form of codepoint. The metadata draft assumes = that a sister specification defines the interoperable feature set (for = CDNI) associated with that URI. That sister specification could be for = example the RFC that defines the Delivery Protocol (e..g RFC2616 for = HTTP/1.1) and a separate specification could define the CDNI Metadata = properties used to describe the protocol features, or a single = specification could for example define a profile of the Delivery = protocol along with the associated CDNI metadata properties. If by "unknown" you mean "does not support the underlying protocol = feature but does recognise the property name" then the specification = that defines the profile/properties for that protocol (either the = metadata draft itself or the sister draft specifying the metadata = properties for a particular protocol) should define which features are = mandatory and must be applied and which features are left to the dCDN as = to whether they enforce them or not. Therefore whether a dCDN can ignore = a feature it doesn't support and still deliver the content or whether it = must reject request routing/delivery for that content is defined in the = appropriate delivery protocol profile/specification document. If by "unknown" you mean "does not recognise the property name" then I = don't think the dCDN can do anything but reject request routing/delivery = because it can not determine if the property that it doesn't recognise = is a mandatory feature to be applied or not. One caveat to the case of "does not recognise the property name" is if = for a given delivery protocol, the property that is not recognised is = not defined in the the associated profile/property specification for = that Delivery Protocol, which could be considered a form of malformed = response. In that case it would probably be reasonable to apply Postel's = law and just ignore that property. We're happy to try and add some text to the next revision that = articulates the expected behaviour for malformed responses and the = expected behaviour for properties defined in the metadata draft itself. Ben=20 >=20 > Thanks, >=20 > Spencer >=20 >> Colleagues, >>=20 >> We just uploaded a proposal for a CDNI Metadata model and an = interface specification for distributing CDNI Metadata (see below). >>=20 >> This initial version does not attempt to articulate all the CDNI = Metadata that would be required to satisfy all CDNI use cases. Instead, = we have proposed a smaller set of properties that should be sufficient = to implement a minimal interconnect of basic HTTP delivery. >>=20 >> This is because, at this stage the important thing in our opinion is = to focus any discussion on the overall structure of the interface rather = than on the details or omission of particular properties. >>=20 >> Our proposal is available here: >> http://tools.ietf.org/html/draft-jenkins-cdni-metadata-00 >>=20 >> Thanks >> Ben, David & Grant >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From ben@niven-jenkins.co.uk Tue Oct 18 05:49:39 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AFE21F8B98 for ; Tue, 18 Oct 2011 05:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bp5rccpL9pzH for ; Tue, 18 Oct 2011 05:49:38 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1F521F8B7E for ; Tue, 18 Oct 2011 05:49:37 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RG96t-0000oN-R3; Tue, 18 Oct 2011 13:49:36 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B668260C@MAILR002.mail.lan> Date: Tue, 18 Oct 2011 13:49:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <30D279D6-3F64-4E1F-A221-D293EE0261D7@niven-jenkins.co.uk> References: <842E1148-9AFD-4A39-BBB3-89CAAB9E833A@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B668260C@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Some questions regarding draft-ma-cdni-metadata X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 12:49:39 -0000 Kevin, Please see inline. On 17 Oct 2011, at 19:26, Kevin J Ma wrote: >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of >> Ben Niven-Jenkins >> I read draft-ma-cdni-metadata but I am struggling a little to = understand >> how it fits into the overall framework of CDNI. >>=20 >> When I read the draft it appeared to me to be aimed more at a Content >> Provider or CDN Provider configuring the authoritative CDN rather = that for >> Metadata exchange between CDNs because of its use of Agents, the fact = it >> keeps all metadata opaque and because a lot of the protocol = description is >> about how to create and modify metadata records which only seems to = apply >> to the authoritative CDN. >=20 > I attempted to create an extensible representation for metadata and a > complete protocol for manipulating metadata, though, not all users of > the interface will need all aspects. Do you feel that the protocol is > deficient for non-authoritative CDN use, or that authoritative CDNs do > not need the metadata interface? I think that we should stick to the scope of work we have been chartered = to address, in the case of CDNI Metadata that is an interface that "will=20= allow the CDNs to exchange content distribution metadata of inter-CDN=20 scope". If the interface we specify is also usable in other scenarios then = that's great but I don't think we should be actively looking to design = an interface that is usable across a multitude of scenarios that are not = in scope of CDNI because it's a distraction and likely to defocus our = efforts. Our charter is not to define a new CP->CDN provisioning = interface (they already exist) so we shouldn't be burning cycles working = on things that are out of charter. >> Agents: >> The draft states that "The Agent object contains basic information = for >> authenticating entities which require access to Metadata." However it = is >> not clear to me how the concept of the Agent object fits within the >> framework of CDNI as the details of the different Agents that may be = able >> to access metadata for a Content Service will be specific the to CDN >> distributing that CDNI metadata. In other words I can't see why one = would >> need to distribute Agent details between CDNs over CDNI because the = Agents >> that are relevant for an uCDN are likely different to the Agents that = a >> relevant to a dCDN. >=20 > It was not intended that agent information be distributed between > CDNs, that was what I tried to convery with the text stating:=20 > "Domains and Agents MAY be created as a part of an > off-line business negotiation process or as a part of the CDNI > bootstrapping process." > Susan had a similar question about who would be responsible for the > creation of agents. I will clarify that in the next version.=20 If Agent information is not supposed to be distributed between CDNs then = it is not of inter-CDN scope, is out of charter and therefore has no = place in the context of CDNI IMO. >> Later on the draft states: >> The association of each Metadata to an Agent allows different = Agents >> to retrieve different Metadata values for a given URI in the given >> Domain. This is intended to allow CDNs to separate upstream = Metadata >> from downstream Metadata (e.g., a uCDN content acquisition URL may >> point to a CP origin, however the content acquisition URL that the >> dCDN retrieves from the uCDN may point at a surrogate in the uCDN). >>=20 >> This implies that the specification of Agents is really for imposing = a >> specific implementation on CDNs in how they manage metadata received = from >> a uCDN and how they expose that metadata to dCDNs. As the scope of = CDNI >> does not cover the internal workings or operation of a particular CDN = it >> would appear to me that imposing a particular internal mechanism for = a >> single CDN to manage & distribute CDNI metadata is inappropriate for = the >> CDNI WG. >=20 > The point was that different consumers of the metadata interface may > require different responses (or they may not). Could that be left up > to individual implementations? Perhaps. I am not sure what internal > mechanism this imposes? Are you saying that CDNI should only define > the metadata semantics, and not the storage representation? My goal > was to define a generic representation, that could adapt to any=20 > semantics? The agent is a part of that, though, in the degenerate > case of a single agent, nothing is lost? We should not be imposing storage representations. We don't need to = include Agents in CDNI Metadata as they're not distributed between CDNs. = If CDNs want to expose different Metadata to different dCDNs they can do = that without the concept of an Agent. >> Metadata: >> I am a little confused about the desire to keep the actual = specification >> of metadata opaque. In order for a CDN to do anything useful with the = CDNI >> metadata it receives it needs to understand the syntax and semantics = of >> the metadata it receives, however the draft intentionally keeps both = the >> syntax and semantics for the metadata properties as well as any = associated >> values opaque to any CDN that receives or distributes the associated >> metadata and says the associated "functionality SHOULD be agreed upon = a >> priori by CDN operators, however, these negotiations are beyond the = scope >> of CDNI." >>=20 >> Of course, the syntax and semantics of the CDNI metadata could be = agreed >> out of band between the operators of the interconnected CDNs but = doing >> that for all metadata properties that would be needed to meet the >> objectives of CDNI does not IMO provide any real advantage over what = one >> could do today by configuring individual services in different CDNs = and >> using CDNI request routing to redirect requests between those = services in >> each CDN. >>=20 >> I can see that the meaning of the value for a specific metadata = property >> might need to be opaque because the value may be applied differently = by >> different CDNs (e.g. a more general "QoS" value that each CDN maps to = an >> appropriate DSCP value depending on how the underlying network has = been >> configured/deployed) but those are more likely to be exceptions = rather >> than the general rule and in any case the property itself would still = need >> to be specified & defined, so even with that in mind I'm struggling = to see >> the value in keeping all metadata opaque. >=20 > My concern with defining all the semantics of metadata and designing a > protocol around that, is you typically end up with a less extensible > design. I would not want to have to update the metadata interface rfc > just to support a new piece of metadata in the future. I am not = saying > that we should not define metadata, I just think it should be separate > from the data model and the protocol, so I concentrated on those = first. > I definitely feel that we should define a base set of metadata that = all > CDNs should support. I do not think the draft prevents that. We agree on the fact that the CDNI metadata protocol specification = doesn't need to define all possible properties/semantics for all = possible delivery protocols and that properties and semantics for = different delivery protocols can be defined in separate documents. The CDNI metadata draft that Grant/David/I authored doesn't preclude = semantics/properties being defined in other documents (and implies that = is likely to be the case - see my response to Spencer just now). The = base set of properties that are described in our draft could easily be = broken out into a separate document if the consensus of the group is to = do so. We included the base properties and interface specification in a = single document so that readers could see how the interface could be = constructed and applied using a set of common base semantics/properties = for HTTP delivery supported by deployed CDNs today. So if we put aside the question of where to define the actual properties = and their semantics we're left with the data model and = interface/protocol itself. So let's compare and contrast some key = aspects of flexibility between the different proposals. Cache-ability & Latency: With the CDNI Metadata model we've proposed we think we've managed to = define a data model that is as simple as possible but no simpler. It has = a minimum number of data objects to allow objects that are likely to to = be large or reused to be broken out into separate resources to provide = efficiency and at the same time objects that may well have different = cache-ability lifetimes can be broken out into separate resources. The = interface specification allows inlining so that all related objects for = a Site can be included in a single request/response so we provide the = ability to have a simple implementation but also the flexibility to = optimise the implementation to balance object size and cache-ability = against number of requests/re-validations required. By keeping your model basically flat you force an implementation to = repeatedly have to transfer data that is common across a number of = Hostnames/Domains (e.g. the definition of Locations) and you force the = cache-ability for all data within a hostname/domain to be the same = whether it is specific to a hostname/domain or common across multiple = hostnames/domains. You therefore do not provide any ability for = implementations to optimise based on their knowledge (or configured = policies) of the different types of data that combine to describe the = CDNI Metadata for a Site/domain/hostname. Self-description: The links between objects in our model and the representations of the = different objects in our model are self-describing through the use of = relationships and media-types within the interface so a client can = easily determine what data objects are being referenced and what data = objects it is receiving and use the appropriate processing function to = interpret their contents. It is easy to add new data objects to our = model if required by defining new relationships and/or media types. In = contrast your representations aren't self-describing and so force a = tighter coupling between the client and server and they require some out = of band process to ensure that coupling is maintained. Bootstrapping & Coupling: Similarly, with the CDNI Metadata interface/protocol we have proposed, = the configuration/bootstrapping of the interface is as simple as = possible but no simpler (a single URI) from which the dCDN can discover = the location of all the CDNI metadata records they have access to. It = also allows the uCDN to define the URI format (and hostname it's = provided by) as they see fit. The uCDN has maximum flexibility to = organise the different CDNI metadata objects and complete control over = how they extend their implementation to support additional data objects = or how they support mapping different dCDNs to different sets of (or = versions of) CDNI metadata. Your proposal imposes a greater configuration/bootstrapping burden on = the dCDN as there is no way for it to discover the domains it has access = to, it needs to know the URI/hostname of the uCDN's Metadata interface = and the domains to query against that interface. The use of fixed paths = in the URI that map to the different data object enforces rigidity on = the uCDN's CDNI Metadata implementation (and tight coupling between the = client and server) and means that if the uCDN wishes to extend its = implementation to support additional objects it risks picking paths that = may later clash with paths defined by newer versions of your protocol. Taking the above factors into consideration I believe that our proposed = data model and interface specification is flexible and extensible enough = to address the current and future needs of CDNI. Ben From flefauch@cisco.com Tue Oct 18 06:59:09 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFF721F8AEE for ; Tue, 18 Oct 2011 06:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.866 X-Spam-Level: X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=-0.688, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFw-OGSGbSMN for ; Tue, 18 Oct 2011 06:59:08 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 242CF21F8AD9 for ; Tue, 18 Oct 2011 06:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=48202; q=dns/txt; s=iport; t=1318946348; x=1320155948; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=IPeqetX0YaDNdUQOsv4Z/71uXOx/o+DlW1xwO8t0/AE=; b=kItwobWQslprunUkOIL8EandRmF2OGSVBHvuFMi5voQiP/t0qqz05lvg 38IIT5dyhu8jOgsoo8m89YYITcg1HOQ5/93z0euTyED2D9hZrllGneXUR sQaBYugKmG+uVGKlFM03YNMqr3Dup9t/9xDiPIT7UnDJNKj6Dsu53JIWC o=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,365,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="8606406" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 18 Oct 2011 13:59:06 +0000 Received: from sjc-vpn2-375.cisco.com (sjc-vpn2-375.cisco.com [10.21.113.119]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9IDx6Om026511; Tue, 18 Oct 2011 13:59:06 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-779--810649510 From: Francois Le Faucheur In-Reply-To: <003201cc8d7a$86a15bb0$93e41310$@com> Date: Tue, 18 Oct 2011 07:00:50 -0700 Message-Id: <0CEEDA69-2312-4A4B-8BA3-60184D610558@cisco.com> References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <003201cc8d7a$86a15bb0$93e41310$@com> To: HeXiaoyan X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 13:59:09 -0000 --Apple-Mail-779--810649510 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On 18 Oct 2011, at 02:44, HeXiaoyan wrote: > Hi Francois, > > * the concept of "hostnames" should be made more flexible so it = matches not just on hostnames but on pattern match over hostname/path. = Let's call this "resource sets". > * "resource sets" should be dependent on "Agents". So perhaps = it shoudl be folded inside your "Metadata" so it can be defined on a per = "dCDN" basis. > =20 > Are you proposing remove the =93hostname=94 object or keep it and = adding =93resource sets=94 to =93Metadata=94? I was proposing that we have a single object but just make it more = flexible. In some cases, it will be identifying hostnames, but it some = case it may identify some more granular set of resources (eg. a hostname = + part of the URI path). > I think the =93hostname=94 object should be kept as sometimes the = customer would possibly deploy a enforcement policy associated to a = hostname , e.g. for hostname associated with a set of web pages, CP may = prefer DNS routing as HTTP redirection will cause cookie issues among = others. Keeping hostname level can provide cp with this flexibility. =20 I agree we want to be able to do that in certain situations. Cheers Francois > =20 > Best Regards > Xiaoyan(Susan) He > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Francois Le Faucheur > Sent: Tuesday, October 18, 2011 3:43 AM > To: Kevin J Ma > Cc: cdni@ietf.org > Subject: Re: [CDNi] CDNI Metadata Interface > =20 > Hello Kevin, > =20 > [with Individual hat on] > =20 > A first set of high level questions: > =20 > * directionality of metadata creation/retrieval/removal/update = mechanism: > Could you clarify which of the above operation you see possibly = happening in which direction? > For example, regarding update/removal, do you see: > *a) the POST possibly being issued towards the uCDN to = update/remove some metadata in the uCDN repository? > *b) the POST possibly being issued by the uCDN towards the dCDN = to update/remove some metadata in the dCDN repository (after some = out-of-date metadata had been retrieved by dCDN from uCDN). > For example, regarding retrieval, clearly we want the dCDN to issue a = GET towards the uCDN to acquire metadata. Now do you see that the GET = could possibly be also issued by the uCDN to check metadata stored by = the dCDN? > =20 > * in your CDNI metadata model, a "domain" is directly associated with = a set of "hostnames". So this assumes that the same set of unmodified = hostnames is used unmodified everywhere in all the potential dCDNs. That = can be the case in some deployment, but that may not always be the case. = For example, when HTTP redirection is used across CDNs, an upstream CDN = may want to modify (possibly hide) the actual content provider hostnames = (and possibly part of the URI path) when redirecting to a dCDN (I = believe this is mentioned in the framework).=20 > Would you consider modifying your proposed CDNI model to allow for the = fact that a domain may be "referenced" differently by some dCDNs than by = the uCDN? > I think it means: > * the concept of "hostnames" should be made more flexible so it = matches not just on hostnames but on pattern match over hostname/path. = Let's call this "resource sets". > * "resource sets" should be dependent on "Agents". So perhaps = it shoudl be folded inside your "Metadata" so it can be defined on a per = "dCDN" basis. > Would that work for you? > =20 > * in section 3.3.3, you have a couple of examples showing = "/CDNI/MI/domain". Should those not say "/CDNI/MI/metadata"? > =20 > =20 > Cheers > =20 > Francois > =20 > =20 > =20 > =20 > On 6 Oct 2011, at 22:21, Kevin J Ma wrote: >=20 >=20 > Hi all, >=20 > Just uploaded a new I-D with a proposed metadata model and API: >=20 > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt >=20 > The model takes a rather generic approach to metadata representation > to support opaque metadata and addresses some of the security issues > associated with metadata retrieval. Comments welcome. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 > =20 Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-779--810649510 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-780--810649510 --Apple-Mail-780--810649510 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi,

On 18 Oct 2011, at 02:44, = HeXiaoyan wrote:

Hi = Francois,
>     * the concept of "hostnames" should be made more flexible = so it matches not just on hostnames but on pattern match over = hostname/path. Let's call this "resource = sets".
       * "resource sets" should be dependent on "Agents". So = perhaps it shoudl be folded inside your "Metadata" so it can be defined = on a per "dCDN" basis.
Are you proposing remove the =93hostname=94 object = or keep it and adding =93resource sets=94 to = =93Metadata=94?

I was proposing that we have a single object but just make it more = flexible. In some cases, it will be identifying hostnames, but it some = case it may identify some more granular set of resources (eg. a hostname = + part of the URI path).

I think the =93hostname=94 object should be kept as = sometimes the customer would possibly deploy a enforcement policy = associated to a hostname , e.g. for hostname associated with  a set = of web pages, CP may prefer DNS routing as HTTP redirection will cause = cookie issues among others. Keeping hostname level can provide cp with = this flexibility. =  

I = agree we want to be able to do that in certain = situations.

Cheers

Franc= ois

 
Best Regards
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Francois Le = Faucheur
Sent: Tuesday, October 18, 2011 = 3:43 AM
To: Kevin J = Ma
Cc: cdni@ietf.org
Subject: Re: [CDNi] CDNI Metadata = Interface
 
Hello Kevin,
 
[with Individual hat = on]
 
A first set of high level = questions:
 
* directionality of metadata = creation/retrieval/removal/update = mechanism:
Could you clarify which of the above operation you see = possibly happening in which = direction?
For example, regarding update/removal, do you = see:
       *a)  the POST possibly being issued towards the = uCDN to update/remove some metadata in the uCDN = repository?
       *b) the POST possibly being issued by the uCDN towards = the dCDN to update/remove some metadata in the dCDN repository (after = some out-of-date metadata had been retrieved by dCDN from = uCDN).
For = example, regarding retrieval, clearly we want the dCDN to issue a GET = towards the uCDN to acquire metadata. Now do you see that the GET could = possibly be also issued by the uCDN to check metadata stored by the = dCDN?
 
* in your CDNI metadata model, a = "domain" is directly associated with a set of "hostnames". So this = assumes that the same set of unmodified hostnames is used unmodified = everywhere in all the potential dCDNs. That can be the case in some = deployment, but that may not always be the case. For example, when HTTP = redirection is used across CDNs, an upstream CDN may want to modify = (possibly hide) the actual content provider hostnames (and possibly part = of the URI path) when redirecting to a dCDN (I believe this is mentioned = in the framework). 
Would you consider modifying your = proposed CDNI model to allow for the fact that a domain may be = "referenced" differently by some dCDNs than by the = uCDN?
I = think it means:
       * the concept of "hostnames" should be made more flexible = so it matches not just on hostnames but on pattern match over = hostname/path. Let's call this "resource = sets".
       * "resource sets" should be dependent on "Agents". So = perhaps it shoudl be folded inside your "Metadata" so it can be defined = on a per "dCDN" basis.
Would that work for = you?
 
* in section 3.3.3, you have = a couple of examples showing "/CDNI/MI/domain". Should those not say = "/CDNI/MI/metadata"?
 
 
Cheers
 
Francois
 
      
 
 
On 6 Oct 2011, at 22:21, Kevin J = Ma wrote:


Hi all,

 Just uploaded = a new I-D with a proposed metadata model and = API:

   CDNi@ietf.org
 



Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-780--810649510 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-780--810649510-- --Apple-Mail-779--810649510-- From kevin.ma@azukisystems.com Tue Oct 18 07:26:50 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97ECD21F8C0D for ; Tue, 18 Oct 2011 07:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNxxK0DzgG4l for ; Tue, 18 Oct 2011 07:26:49 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7B421F8B68 for ; Tue, 18 Oct 2011 07:26:49 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B6CFD416E13; Tue, 18 Oct 2011 10:26:48 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C6F37416E3E; Tue, 18 Oct 2011 10:26:37 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Tue, 18 Oct 2011 10:26:36 -0400 From: Kevin J Ma To: Francois Le Faucheur Date: Tue, 18 Oct 2011 10:26:35 -0400 Thread-Topic: [CDNi] CDNI Metadata Interface Thread-Index: AcyNMl7nA3rELonvQR+0+Vx712mQfQAaQjwg Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6682887@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 14:26:50 -0000 Hi Francois, comments inline: > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Monday, October 17, 2011 3:43 PM > To: Kevin J Ma > Cc: Francois Le Faucheur; cdni@ietf.org > Subject: Re: [CDNi] CDNI Metadata Interface >=20 > Hello Kevin, >=20 > [with Individual hat on] >=20 > A first set of high level questions: >=20 > * directionality of metadata creation/retrieval/removal/update mechanism: > Could you clarify which of the above operation you see possibly happening > in which direction? > For example, regarding update/removal, do you see: > *a) the POST possibly being issued towards the uCDN to > update/remove some metadata in the uCDN repository? > *b) the POST possibly being issued by the uCDN towards the dCDN to > update/remove some metadata in the dCDN repository (after some out-of-dat= e > metadata had been retrieved by dCDN from uCDN). > For example, regarding retrieval, clearly we want the dCDN to issue a GET > towards the uCDN to acquire metadata. Now do you see that the GET could > possibly be also issued by the uCDN to check metadata stored by the dCDN? I think POSTs make the most sense going from upstream to downstream. The agent was intended to moderate this, since any given pair of CDNs could be both a uCDN and a dCDN for each other in different domains. I see no reason why GETs could not go in both directions. I can see a case where upstream entities would want to verify downstream entities. > * in your CDNI metadata model, a "domain" is directly associated with a > set of "hostnames". So this assumes that the same set of unmodified > hostnames is used unmodified everywhere in all the potential dCDNs. That > can be the case in some deployment, but that may not always be the case. > For example, when HTTP redirection is used across CDNs, an upstream CDN > may want to modify (possibly hide) the actual content provider hostnames > (and possibly part of the URI path) when redirecting to a dCDN (I believe > this is mentioned in the framework). I was thinking (though it is not noted in the document) that hostname lists could be different in different dCDNs. What is not entirely clear to me is how metadata would get set across cascaded CDNs, i.e., if the CP contracts CDN-A, and CDN-A makes a deal with CDN-B, and CDN-B makes a deal with CDN-C, does the CP or CDN-A know about CDN-C and is the CP or CDN-A responsible configuring metadata on CDN-C? Or, is CDN metadata only configured by the most immediate uCDN (or the CP), i.e., only CDN-B (or the CP) will know the values of metadata in CDN-C? > Would you consider modifying your proposed CDNI model to allow for the > fact that a domain may be "referenced" differently by some dCDNs than by > the uCDN? > I think it means: > * the concept of "hostnames" should be made more flexible so it > matches not just on hostnames but on pattern match over hostname/path. > Let's call this "resource sets". > * "resource sets" should be dependent on "Agents". So perhaps it > shoudl be folded inside your "Metadata" so it can be defined on a per > "dCDN" basis. > Would that work for you? Would the goal be to use the entire hostname/uri as a single combined key? I do not have a problem with merging them if we think that it would be useful. > * in section 3.3.3, you have a couple of examples showing > "/CDNI/MI/domain". Should those not say "/CDNI/MI/metadata"? Yep. Those are cut and paste errors, good catch! I will fix those. thanx! -- Kevin J. Ma =20 > Cheers >=20 > Francois >=20 >=20 >=20 >=20 > On 6 Oct 2011, at 22:21, Kevin J Ma wrote: >=20 >=20 > Hi all, >=20 > Just uploaded a new I-D with a proposed metadata model and API: >=20 > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt >=20 > The model takes a rather generic approach to metadata representation > to support opaque metadata and addresses some of the security issues > associated with metadata retrieval. Comments welcome. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From kevin.ma@azukisystems.com Tue Oct 18 07:27:55 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195AD21F8C10 for ; Tue, 18 Oct 2011 07:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vozaZDmB-Ype for ; Tue, 18 Oct 2011 07:27:54 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id CAAD621F8C0F for ; Tue, 18 Oct 2011 07:27:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 67952416F52; Tue, 18 Oct 2011 10:27:53 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DAE18416E27; Tue, 18 Oct 2011 10:27:42 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Tue, 18 Oct 2011 10:27:30 -0400 From: Kevin J Ma To: HeXiaoyan , "cdni@ietf.org" Date: Tue, 18 Oct 2011 10:27:40 -0400 Thread-Topic: [CDNi] CDNI Metadata Interface Thread-Index: AcyErDmDceDqNX+AQtKwjumpTmgL9wDNgegQABC/ZGAAiOeZgAAMTEwgAIdhgUAAENsBMAAiGgtwAA8asjA= Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6682889@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <010d01cc87f8$10bc5940$32350bc0$@com> <291CC3F9E50E7641901A54E85D0977C651B51517AD@MAILR002.mail.lan> <000501cc8a54$921298c0$b637ca40$@com> <291CC3F9E50E7641901A54E85D0977C651B523F27E@MAILR002.mail.lan> <000201cc8c9c$5d426180$17c72480$@com> <291CC3F9E50E7641901A54E85D0977C651B668260B@MAILR002.mail.lan> <003101cc8d78$27379dd0$75a6d970$@com> In-Reply-To: <003101cc8d78$27379dd0$75a6d970$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 14:27:55 -0000 Hi Susan, inline: > -----Original Message----- > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > Sent: Tuesday, October 18, 2011 5:27 AM > To: Kevin J Ma; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface >=20 > Kevin, > > Adding the one-to-many relationship > > between the hostname and metadata tables would cause duplicate entries > > in the metadata table (one per hostname)? > Sorry, after reading the draft again, I have to say my intention was that > the relationship between the Hostname and Metadata object should be a > one-to-zero or one-to-one relation like the figure below. All metadata > associated with one hostname or one url prefix which at least containing = a > hostname should be grouped in one Metadata object (i.e. explicitly define > all the properties of each hostname in one Metadata object). I think this > is > more straight-forward and consistent with the existing today CDN metadata > model. Is it possible for you to consider modifying your proposal on > this? Francois had a similar comment. One resolution would be to move the hostna= me into the metadata object and use it as part of the URI lookup? Would that make more sense? > +----------+ > | | 1 > | Agent +---------------------------+ > | | | > +----+-----+ | > | 1..* | > | | > | 1 | 1 > +----+-----+ +----+-----+ > | | | | > | Domain | | Metadata | > | | | | > +----+-----+ +-----+----+ > | 1 | > | | > | 1..* | > +----+-----+ | > | | 1 0..1 | > | Hostname +----------------------------+ > | | > +----------+ >=20 > When reading through the examples in section 3.3.3, I found no agent > id/name > is conveyed in the metadata retrieval message, I remember we discussed > that > for different agent the upCDN may response with different value of a > metadata, would you double check that? > Thanks. In the examples, I used HTTP basic auth, so the agent name/password is encoded in the Authorization header. thanx. -- Kevin J. Ma > Best Regards > Xiaoyan(Susan) He >=20 > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Tuesday, October 18, 2011 2:26 AM > To: HeXiaoyan; cdni@ietf.org > Subject: RE: [CDNi] CDNI Metadata Interface >=20 > Hi Susan, >=20 > ok, I think I understand now. In writing the draft, I was not sure if > this would be a typical use case. Adding the one-to-many relationship > between the hostname and metadata tables would cause duplicate entries > in the metadata table (one per hostname)? One alternative would be to > use a many-to-many relationship instead, though verification of domain > constraints on creation becomes more complex. In general, if we think > that this flexibility is required, I have no issue with making changes > to the model, however, if it is unlikely to be used, I would favor the > simpler approach. >=20 > Is a one-to-many relationship between the hostname and metadata tables > that much better than removing the hostname table completely (and just > adding a hostname field to the domain, i.e., the degenerate case where > each domain only has one hostname)? That is essentially what it would > be doing? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > Sent: Monday, October 17, 2011 3:14 AM > > To: Kevin J Ma; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Kevin, > > I share the view that the concept of Domain is useful, my suggestion is > > linking metadata to Hostname and keep the Domain, > > i.e. something like the figure below. Benefit is metadata associated > with > > one custormer can be grouped even different > > Hostnames belong the Domain has different metadata value. > > > > > > +----------+ > > | | 1 > > | Agent +---------------------------+ > > | | | > > +----+-----+ | > > | 1..* | > > | | > > | 1 | 1 > > +----+-----+ +----+-----+ > > | | | | > > | Domain | | Metadata | > > | | | | > > +----+-----+ +-----+----+ > > | 1 | > > | | > > | 1..* | > > +----+-----+ | > > | | 1 0..* | > > | Hostname +----------------------------+ > > | | > > +----------+ > > > > Thanks. > > > > Best Regards > > Xiaoyan(Susan) He > > -----Original Message----- > > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > > Sent: Friday, October 14, 2011 10:26 PM > > To: HeXiaoyan; cdni@ietf.org > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > Hi Susan, > > > > responses inline: > > > > > -----Original Message----- > > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > > Sent: Friday, October 14, 2011 5:35 AM > > > To: Kevin J Ma; cdni@ietf.org > > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > > > Hi Kevin, > > > Thanks for the response. Some further concern, > > > - I don't quite understand the restriction that require metadata of > all > > > hostnames in one Domain have same value. The case exist that for a > > > specific > > > metadata different hostnames often have different value. Compare with > > > creating multiple Domains with less hostname sharing the same > metadata, > > I > > > think link metadata to hostname not Domain is more simpler. > > > > From a conceptual perspective, it could be argued that the domain > > object is extraneous. As an implementation detail, however, the > > multi-table joins, imo, were simplified by having a central object > > to define the domain, so I added one. From an operator perspective, > > having a way to group multiple hostnames also seems useful, even > > though, in the degenerate case, you could just have one hostname per > > domain. If there is a concensus view that the domain is unnecessary, > > it could be removed. > > > > > -I interpret the role of the Agent object is to identify entities > > > communicated (correct me if I'm wrong), other interfaces in CDNI e.g. > > > Logging interface needs such an parameter as well, a universal > solution > > > for > > > that would be good, do you think the Agent object introduced in your > > draft > > > could also be applicable for other interfaces? > > > > I agree that the other interfaces (control/logging) will require some > > type of authentication and security. The agent concept could certainly > > be extended to other interfaces, and I agree that it would be good to > > have the same solution for all interfaces > > > > thanx. > > > > -- Kevin J. Ma > > > > > Best Regards > > > Xiaoyan(Susan) He > > > > > > -----Original Message----- > > > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > > > Sent: Tuesday, October 11, 2011 11:30 PM > > > To: HeXiaoyan; cdni@ietf.org > > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > > > Hi Susan, > > > > > > thanx for the comments, responses inline: > > > > > > > -----Original Message----- > > > > From: HeXiaoyan [mailto:hexiaoyan@huawei.com] > > > > Sent: Tuesday, October 11, 2011 5:28 AM > > > > To: Kevin J Ma; cdni@ietf.org > > > > Subject: RE: [CDNi] CDNI Metadata Interface > > > > > > > > Hi Kevin, > > > > Some quick questions and comments on this draft, > > > > >The Metadata objects are each associated with a URI within the > Domain > > > and > > > > accessible through any of the Hostnames... > > > > - Could you further explain or give an example how a metadata is > > > accessed > > > > by > > > > a Hostname within the Domain? And a further question is how the dat= a > > > model > > > > works if a metadata is only associated with a specific Hostname > within > > > one > > > > Doman? > > > > > > I was assuming that metadata would be valid for all hostnames. If a > > > hostname > > > needed separate metadata, a new domain would be required. I was > > thinking > > > of > > > hostname as a first level restriction. My implementation does > something > > > along > > > the lines of the following (where hostname is checked before metadata > > > lookup): > > > > > > domain =3D get_param_from_query_string(getenv("QUERY_STRING"), > "domain") > > > if (!db_verify_hostname_for_domain(getenv("SERVER_NAME"), domain)) > > > return error > > > metadata =3D > db_get_metadata_by_uri_domain_agent(getenv("REQUEST_URI"), > > > domain, > > > getenv("REMOTE_USER")) > > > xml =3D generate_xml_for_metadata(metadata) > > > return xml > > > > > > > - The relationship between Agent objects and Metadata objects is a > > > > one-to-one relationship, does this mean one agent can only access > one > > > > Metadata within one Domain? > > > > > > That is a typo in the doc, good catch, thanx! It should be one to > many. > > > Each metadata must be associated with a single agent, but an agent ca= n > > be > > > associated with multiple metadata. Agent-1 could have metadatas A, B= , > > and > > > C, while agent-2 could have a separate value for metadatas A and B, > and > > > also > > > have its own metadata D (that agent-1 does not have access to) > > > > > > > > The association of each Metadata to an Agent allows different > Agents > > > to > > > > retrieve different Metadata values for a given URI in the given > > Domain. > > > > - Don't understand why each Metadata object needs to be bind with a= n > > > Agent > > > > explicitly, IMO, whether to return different value to different > Agents > > > is > > > > an > > > > inside process of the upCDN, what downCDN needs to do is just > transmit > > > its > > > > identifier to the upCDN when retrieve a Metadata. > > > > > > I think the fact that a uCDN would want/need to give out different > > values > > > to > > > different dCDNs requires that there be a way to represent and store > that > > > information. Having it explicitly in the model, i think, simplifies > the > > > implementation and guarantees that all implementation give this issue > > > proper > > > consideration. > > > > > > > - Which entity is responsible for creating the Agent objects within > > one > > > > Domain? Does the CP can 'see' the downCDNs and creates correspondin= g > > > Agent > > > > objects and other CDNs on the way just transmitted it or each upCDN > > > > located > > > > in the cascaded path creates a Agent object for each its downCDN? > > > > > > This is a good question. Different agents would need to be create by > > > different > > > entities, as you mention. I would expect each CDN to create agents t= o > > > represent > > > those (outside that CDN) who need access to the metadata interface. > > > > > > thanx! > > > > > > -- Kevin J. Ma > > > > > > > Thanks. > > > > Best Regards > > > > Xiaoyan(Susan) He > > > > > > > > -----Original Message----- > > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behal= f > > Of > > > > Kevin J Ma > > > > Sent: Friday, October 07, 2011 1:21 PM > > > > To: cdni@ietf.org > > > > Subject: [CDNi] CDNI Metadata Interface > > > > > > > > Hi all, > > > > > > > > Just uploaded a new I-D with a proposed metadata model and API: > > > > > > > > http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata- > 00.txt > > > > > > > > The model takes a rather generic approach to metadata > representation > > > > to support opaque metadata and addresses some of the security > issues > > > > associated with metadata retrieval. Comments welcome. > > > > > > > > thanx. > > > > > > > > -- Kevin J. Ma > > > > > > > > _______________________________________________ > > > > CDNi mailing list > > > > CDNi@ietf.org > > > > https://www.ietf.org/mailman/listinfo/cdni >=20 From kevin.ma@azukisystems.com Tue Oct 18 09:03:54 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D791721F8BF7 for ; Tue, 18 Oct 2011 09:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.461 X-Spam-Level: X-Spam-Status: No, score=-2.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XONxn0drta6b for ; Tue, 18 Oct 2011 09:03:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6479D21F8BF6 for ; Tue, 18 Oct 2011 09:03:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C506D79F371; Tue, 18 Oct 2011 12:03:52 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E4BB379FE2E; Tue, 18 Oct 2011 12:03:40 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Tue, 18 Oct 2011 12:03:38 -0400 From: Kevin J Ma To: Ben Niven-Jenkins Date: Tue, 18 Oct 2011 12:03:38 -0400 Thread-Topic: [CDNi] Some questions regarding draft-ma-cdni-metadata Thread-Index: AcyNlIY8z60VbDtoQpOOh1nlhDc7ugAEDjEg Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6682920@MAILR002.mail.lan> References: <842E1148-9AFD-4A39-BBB3-89CAAB9E833A@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B668260C@MAILR002.mail.lan> <30D279D6-3F64-4E1F-A221-D293EE0261D7@niven-jenkins.co.uk> In-Reply-To: <30D279D6-3F64-4E1F-A221-D293EE0261D7@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Some questions regarding draft-ma-cdni-metadata X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:03:55 -0000 Ben, inline: > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Tuesday, October 18, 2011 8:50 AM > To: Kevin J Ma > Cc: cdni@ietf.org > Subject: Re: [CDNi] Some questions regarding draft-ma-cdni-metadata >=20 > Kevin, >=20 > Please see inline. >=20 > On 17 Oct 2011, at 19:26, Kevin J Ma wrote: > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > >> Ben Niven-Jenkins > >> I read draft-ma-cdni-metadata but I am struggling a little to > understand > >> how it fits into the overall framework of CDNI. > >> > >> When I read the draft it appeared to me to be aimed more at a Content > >> Provider or CDN Provider configuring the authoritative CDN rather that > for > >> Metadata exchange between CDNs because of its use of Agents, the fact > it > >> keeps all metadata opaque and because a lot of the protocol descriptio= n > is > >> about how to create and modify metadata records which only seems to > apply > >> to the authoritative CDN. > > > > I attempted to create an extensible representation for metadata and a > > complete protocol for manipulating metadata, though, not all users of > > the interface will need all aspects. Do you feel that the protocol is > > deficient for non-authoritative CDN use, or that authoritative CDNs do > > not need the metadata interface? >=20 > I think that we should stick to the scope of work we have been chartered > to address, in the case of CDNI Metadata that is an interface that "will > allow the CDNs to exchange content distribution metadata of inter-CDN > scope". >=20 > If the interface we specify is also usable in other scenarios then that's > great but I don't think we should be actively looking to design an > interface that is usable across a multitude of scenarios that are not in > scope of CDNI because it's a distraction and likely to defocus our > efforts. Our charter is not to define a new CP->CDN provisioning interfac= e > (they already exist) so we shouldn't be burning cycles working on things > that are out of charter. I personally do not see a difference between uCDN->dCDN and CP->uCDN. If in supporting uCDN->dCDN you get CP->uCDN, I think that is a bonus. I do not think we should ignore uCDN->dCDN just because it might be useful to CPs. Is the argument that a uCDN should never need to push metadata to a dCDN and therefore we do not need uCDN->dCDN support? > >> Agents: > >> The draft states that "The Agent object contains basic information for > >> authenticating entities which require access to Metadata." However it > is > >> not clear to me how the concept of the Agent object fits within the > >> framework of CDNI as the details of the different Agents that may be > able > >> to access metadata for a Content Service will be specific the to CDN > >> distributing that CDNI metadata. In other words I can't see why one > would > >> need to distribute Agent details between CDNs over CDNI because the > Agents > >> that are relevant for an uCDN are likely different to the Agents that = a > >> relevant to a dCDN. > > > > It was not intended that agent information be distributed between > > CDNs, that was what I tried to convery with the text stating: > > "Domains and Agents MAY be created as a part of an > > off-line business negotiation process or as a part of the CDNI > > bootstrapping process." > > Susan had a similar question about who would be responsible for the > > creation of agents. I will clarify that in the next version. >=20 > If Agent information is not supposed to be distributed between CDNs then > it is not of inter-CDN scope, is out of charter and therefore has no plac= e > in the context of CDNI IMO. >=20 > >> Later on the draft states: > >> The association of each Metadata to an Agent allows different Agents > >> to retrieve different Metadata values for a given URI in the given > >> Domain. This is intended to allow CDNs to separate upstream Metadat= a > >> from downstream Metadata (e.g., a uCDN content acquisition URL may > >> point to a CP origin, however the content acquisition URL that the > >> dCDN retrieves from the uCDN may point at a surrogate in the uCDN). > >> > >> This implies that the specification of Agents is really for imposing a > >> specific implementation on CDNs in how they manage metadata received > from > >> a uCDN and how they expose that metadata to dCDNs. As the scope of CDN= I > >> does not cover the internal workings or operation of a particular CDN > it > >> would appear to me that imposing a particular internal mechanism for a > >> single CDN to manage & distribute CDNI metadata is inappropriate for > the > >> CDNI WG. > > > > The point was that different consumers of the metadata interface may > > require different responses (or they may not). Could that be left up > > to individual implementations? Perhaps. I am not sure what internal > > mechanism this imposes? Are you saying that CDNI should only define > > the metadata semantics, and not the storage representation? My goal > > was to define a generic representation, that could adapt to any > > semantics? The agent is a part of that, though, in the degenerate > > case of a single agent, nothing is lost? >=20 > We should not be imposing storage representations. We don't need to > include Agents in CDNI Metadata as they're not distributed between CDNs. > If CDNs want to expose different Metadata to different dCDNs they can do > that without the concept of an Agent. >=20 > >> Metadata: > >> I am a little confused about the desire to keep the actual > specification > >> of metadata opaque. In order for a CDN to do anything useful with the > CDNI > >> metadata it receives it needs to understand the syntax and semantics o= f > >> the metadata it receives, however the draft intentionally keeps both > the > >> syntax and semantics for the metadata properties as well as any > associated > >> values opaque to any CDN that receives or distributes the associated > >> metadata and says the associated "functionality SHOULD be agreed upon = a > >> priori by CDN operators, however, these negotiations are beyond the > scope > >> of CDNI." > >> > >> Of course, the syntax and semantics of the CDNI metadata could be > agreed > >> out of band between the operators of the interconnected CDNs but doing > >> that for all metadata properties that would be needed to meet the > >> objectives of CDNI does not IMO provide any real advantage over what > one > >> could do today by configuring individual services in different CDNs an= d > >> using CDNI request routing to redirect requests between those services > in > >> each CDN. > >> > >> I can see that the meaning of the value for a specific metadata > property > >> might need to be opaque because the value may be applied differently b= y > >> different CDNs (e.g. a more general "QoS" value that each CDN maps to > an > >> appropriate DSCP value depending on how the underlying network has bee= n > >> configured/deployed) but those are more likely to be exceptions rather > >> than the general rule and in any case the property itself would still > need > >> to be specified & defined, so even with that in mind I'm struggling to > see > >> the value in keeping all metadata opaque. > > > > My concern with defining all the semantics of metadata and designing a > > protocol around that, is you typically end up with a less extensible > > design. I would not want to have to update the metadata interface rfc > > just to support a new piece of metadata in the future. I am not saying > > that we should not define metadata, I just think it should be separate > > from the data model and the protocol, so I concentrated on those first. > > I definitely feel that we should define a base set of metadata that all > > CDNs should support. I do not think the draft prevents that. >=20 > We agree on the fact that the CDNI metadata protocol specification doesn'= t > need to define all possible properties/semantics for all possible deliver= y > protocols and that properties and semantics for different delivery > protocols can be defined in separate documents. >=20 > The CDNI metadata draft that Grant/David/I authored doesn't preclude > semantics/properties being defined in other documents (and implies that i= s > likely to be the case - see my response to Spencer just now). The base se= t > of properties that are described in our draft could easily be broken out > into a separate document if the consensus of the group is to do so. We > included the base properties and interface specification in a single > document so that readers could see how the interface could be constructed > and applied using a set of common base semantics/properties for HTTP > delivery supported by deployed CDNs today. >=20 > So if we put aside the question of where to define the actual properties > and their semantics we're left with the data model and interface/protocol > itself. So let's compare and contrast some key aspects of flexibility > between the different proposals. >=20 > Cache-ability & Latency: > With the CDNI Metadata model we've proposed we think we've managed to > define a data model that is as simple as possible but no simpler. It has = a > minimum number of data objects to allow objects that are likely to to be > large or reused to be broken out into separate resources to provide > efficiency and at the same time objects that may well have different > cache-ability lifetimes can be broken out into separate resources. The > interface specification allows inlining so that all related objects for a > Site can be included in a single request/response so we provide the > ability to have a simple implementation but also the flexibility to > optimise the implementation to balance object size and cache-ability > against number of requests/re-validations required. The protocol in my draft also supports bulk retrieval, but if there is a nuance of inlining that is missing, I could certainly look at it. Though I did not address cacheability, I think it could be applied at the bulk response level as you describe? > By keeping your model basically flat you force an implementation to > repeatedly have to transfer data that is common across a number of > Hostnames/Domains (e.g. the definition of Locations) and you force the > cache-ability for all data within a hostname/domain to be the same whethe= r > it is specific to a hostname/domain or common across multiple > hostnames/domains. You therefore do not provide any ability for > implementations to optimise based on their knowledge (or configured > policies) of the different types of data that combine to describe the > CDNI Metadata for a Site/domain/hostname. >=20 > Self-description: > The links between objects in our model and the representations of the > different objects in our model are self-describing through the use of > relationships and media-types within the interface so a client can easily > determine what data objects are being referenced and what data objects it > is receiving and use the appropriate processing function to interpret > their contents. It is easy to add new data objects to our model if > required by defining new relationships and/or media types. In contrast > your representations aren't self-describing and so force a tighter > coupling between the client and server and they require some out of band > process to ensure that coupling is maintained. The individual pieces of metadata have a defined type. If the CDN supports a given piece of metadata, it will know what the type is. The metadata distribution protocol, imo, does not need to know the type as long as the CDN who receives the metadata understands it? Knowing the type is not necessarily enough information to know what to do with it, the full definition of the metadata is required either way? > Bootstrapping & Coupling: > Similarly, with the CDNI Metadata interface/protocol we have proposed, th= e > configuration/bootstrapping of the interface is as simple as possible but > no simpler (a single URI) from which the dCDN can discover the location o= f > all the CDNI metadata records they have access to. It also allows the uCD= N > to define the URI format (and hostname it's provided by) as they see fit. > The uCDN has maximum flexibility to organise the different CDNI metadata > objects and complete control over how they extend their implementation to > support additional data objects or how they support mapping different > dCDNs to different sets of (or versions of) CDNI metadata. >=20 > Your proposal imposes a greater configuration/bootstrapping burden on the > dCDN as there is no way for it to discover the domains it has access to, > it needs to know the URI/hostname of the uCDN's Metadata interface and th= e > domains to query against that interface. The use of fixed paths in the UR= I > that map to the different data object enforces rigidity on the uCDN's CDN= I > Metadata implementation (and tight coupling between the client and server= ) > and means that if the uCDN wishes to extend its implementation to support > additional objects it risks picking paths that may later clash with paths > defined by newer versions of your protocol. Your SiteFeed object provides Site information (which is fairly analogous to domain information). Domain information could also be put into a feed,= =20 however, I assume that business processes drive what goes into the SiteFeed= . Is the SiteFeed configured offline, as part of some business process? If so, then is it better to configure Site information as a feed in the uCDN, or as domains in the dCDN. I do not have a strong feeling either way, but I do not see our schemes as being so different. thanx. -- Kevin J. Ma > Taking the above factors into consideration I believe that our proposed > data model and interface specification is flexible and extensible enough > to address the current and future needs of CDNI. >=20 > Ben >=20 >=20 >=20 From lijincheng@huawei.com Wed Oct 19 02:24:28 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C0A21F8B70 for ; Wed, 19 Oct 2011 02:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgePA9x-4s2X for ; Wed, 19 Oct 2011 02:24:28 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6AF21F8B84 for ; Wed, 19 Oct 2011 02:24:27 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTB0011Q3GP0D@szxga05-in.huawei.com> for cdni@ietf.org; Wed, 19 Oct 2011 17:24:25 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTB0032O3GO5I@szxga05-in.huawei.com> for cdni@ietf.org; Wed, 19 Oct 2011 17:24:25 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEO34449; Wed, 19 Oct 2011 17:24:23 +0800 Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 19 Oct 2011 17:24:14 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.75]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Wed, 19 Oct 2011 17:24:08 +0800 Date: Wed, 19 Oct 2011 09:24:08 +0000 From: "Will Li(jincheng)" In-reply-to: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> X-Originating-IP: [10.144.242.41] To: Ben Niven-Jenkins , "cdni@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call Thread-index: AQHMjL1M8UDFDgdACEqAzOaAom66QJWDZJBw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> Subject: [CDNi] =?gb2312?b?tPC4tDogIFByZXBhcmluZyBkcmFmdC1pZXRmLWNkbmkt?= =?gb2312?b?cHJvYmxlbS1zdGF0ZW1lbnQgZm9yIFdHIExhc3QgQ2FsbA==?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 09:24:29 -0000 SGksIEJlbiwNCg0KVGhhbmsgeW91IGZvciB0aGUgZWZmb3J0cy4gVHdvIG1vcmUgY29tbWVudHMu DQoxKSBJbiBzZWN0aW9uIDMsIGRvIHlvdSB0aGluayBpdCBpcyBoZWxwZnVsIHRvIGFkZCBzb21l IGRlc2NyaXB0aW9uIG9uIGVhY2ggcm9sZSAoaS5lLiBDUCwgVXBzdHJlYW0gQ0ROLCBEb3duc3Ry ZWFtIENETiksIGFuZCB0aGVpciBidXNpbmVzcyByZWxhdGlvbnNoaXBzIGFzc3VtZWQgaW4gQ0RO ST8NCiAgVGhpcyBjb3VsZCBmYWNpbGl0YXRlIHBlb3BsZSB0byB1bmRlcnN0YW5kIHRoZSBmaWd1 cmUgYW5kIHRoZSBkcmFmdCBiZXR0ZXIuDQoyKUFub3RoZXIgZWRpdG9yaWFsIG9uZTogSW4gYnVs bGV0IDUgb2YgeW91ciBwcmV2aW91cyBtYWlsLCBjaGFuZ2luZyBJVFUgdG8gSVRVLVQgY291bGQg YmUgbW9yZSBzcGVjaWZpYy4NCg0KQlIsIFdpbGwgDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8 /sjLOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmdd ILT6se0gQmVuIE5pdmVuLUplbmtpbnMNCreiy83KsbzkOiAyMDExxOoxMNTCMTfI1SAxOTowOA0K ytW8/sjLOiBjZG5pQGlldGYub3JnDQrW98ziOiBbQ0ROaV0gUHJlcGFyaW5nIGRyYWZ0LWlldGYt Y2RuaS1wcm9ibGVtLXN0YXRlbWVudCBmb3IgV0cgTGFzdCBDYWxsDQoNCkNvbGxlYWd1ZXMsDQoN CkF0IHRoZSBsYXN0IElFVEYgSSBzYWlkIEkgd291bGQgdHJ5IHRvIHByZXBhcmUgYSB2ZXJzaW9u IG9mIHRoZSBDRE5JIHByb2JsZW0gU3RhdGVtZW50IChkcmFmdC1pZXRmLWNkbmktcHJvYmxlbS1z dGF0ZW1lbnQpIHRoYXQgaXMgcmVhZHkgZm9yIFdHIExhc3QgQ2FsbCBiZWZvcmUgSUVURjgyIGlu IFRhaXBlaS4NCg0KQXMgcGFydCBvZiB0aGF0IEkgaGF2ZSByZXZpZXdlZCB0aGUgY29tcGxldGUg ZHJhZnQgYW5kIG1hZGUgc29tZSBtaW5vciBlZGl0b3JpYWwgY2xlYW4tdXBzIHRvIG15IHdvcmtp bmcgY29weS4gSG93ZXZlciwgdGhlcmUgd2VyZSBhIG51bWJlciBvZiBvdGhlciBhcmVhcyB3aGVy ZSBJIHRoaW5rIGNoYW5nZXMgbmVlZCB0byBiZSBtYWRlIHRvIHRoZSBkb2N1bWVudCB0aGF0IEkg dGhpbmsgd2FycmFudCB3aWRlciBXRyByZXZpZXcvY29uc2Vuc3VzIGFuZCBJIGhhdmUgbGlzdGVk IHRoZW0gYmVsb3cgYWxvbmcgd2l0aCB0aGUgY2hhbmdlcyBJIGFtIHByb3Bvc2luZy4NCg0KQ291 bGQgeW91IHBsZWFzZSBwcm92aWRlIHlvdXIgZmVlZGJhY2sgb24gdGhlIGFyZWFzL3Byb3Bvc2Vk IHRleHQgSSBoYXZlIGhpZ2hsaWdodGVkIGJlbG93IGFzIHdlbGwgYXMgYW55IG90aGVyIGFyZWFz IG9mIHRoZSBkb2N1bWVudCB0aGF0IHlvdSB0aGluayByZXF1aXJlIGFkZGl0aW9uYWwgd29yay9j bGVhbnVwIGJlZm9yZSB5b3UgY29uc2lkZXIgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBhIFdH IExhc3QgQ2FsbC4NCg0KMSkgU2VjdGlvbiAyOiBVcGRhdGUgdGhlIGxhc3QgcGFyYWdyYXBoIHRv IHJlZmVyZW5jZSB0aGUgV0cgZHJhZnQgZm9yIENETkkgdXNlIGNhc2VzIGFuZCByZW1vdmUgcmVm ZXJlbmNlIHRvIGRyYWZ0LXdhdHNvbi1jZG5pLXVzZS1jYXNlcywgaS5lLg0KDQpPTEQ6DQogICBV c2UgY2FzZXMgZm9yIENETiBJbnRlcmNvbm5lY3Rpb24gYXJlIGZ1cnRoZXIgZGlzY3Vzc2VkIGlu DQogICBbSS1ELmJlcnRyYW5kLWNkbmktdXNlLWNhc2VzXSAod2hpY2ggY29udGFpbnMgYSBtZXJn ZWQgc2V0IG9mIHVzZQ0KICAgY2FzZXMgcHJldmlvdXNseSBwcmVzZW50ZWQgaW4gW0ktRC53YXRz b24tY2RuaS11c2UtY2FzZXNdIGFuZA0KICAgW0ktRC5iZXJ0cmFuZC1jZG5pLXVzZS1jYXNlcy0w MF0pLg0KTkVXOg0KICAgVXNlIGNhc2VzIGZvciBDRE4gSW50ZXJjb25uZWN0aW9uIGFyZSBmdXJ0 aGVyIGRpc2N1c3NlZCBpbg0KICAgW0ktRC5pZXRmLWNkbmktdXNlLWNhc2VzXS4NCg0KDQoyKSBT ZWN0aW9uIDQgY29udGFpbnMgYW4gaW50cm9kdWN0aW9uIGFuZCAyIHN1Yi1zZWN0aW9ucyAoNC4x ICYgNC4yKSB0aGF0IGFyZSBlYWNoIGp1c3QgYSBjb3VwbGUgb2Ygc2VudGVuY2VzLCBzbyBJIHBy b3Bvc2UgbWVyZ2luZyB0aGVtIGludG8gYSBzaW5nbGUgc2VjdGlvbiBhbmQgY2hhbmdpbmcgdGhl IGZpcnN0IHR3byBzZW50ZW5jZXMgb2Ygc2VjdGlvbiA0IGFwcHJvcHJpYXRlbHksIGkuZS4NCg0K T0xEOg0KICAgVGhpcyBzZWN0aW9uIGV4cGFuZHMgb24gaG93IENETkkgaW50ZXJmYWNlcyBjYW4g cmV1c2UgYW5kIGxldmVyYWdlDQogICBleGlzdGluZyBwcm90b2NvbHMuICBGaXJzdCB0aGUgInJl dXNlIGluc3RlYWQgb2YgcmVpbnZlbnQiIGRlc2lnbg0KICAgcHJpbmNpcGxlIGlzIHJlc3RhdGVk LCB0aGVuIGVhY2ggaW5ldHJmYWNlIGlzIGRpc2N1c3NlZCBpbmRpdmlkdWFsbHkNCiAgIHdpdGgg ZXhhbXBsZSBjYW5kaWRhdGUgcHJvdG9jb2xzIHRoYXQgY2FuIGJlIGNvbnNpZGVyZWQgZm9yIHJl dXNlIG9yDQogICBsZXZlcmFnZS4gDQpORVc6DQogICBUaGlzIHNlY3Rpb24gZXhwYW5kcyBvbiBo b3cgQ0ROSSBpbnRlcmZhY2VzIGNhbiByZXVzZSBhbmQgbGV2ZXJhZ2UNCiAgIGV4aXN0aW5nIHBy b3RvY29scyBiZWZvcmUgZGVzY3JpYmluZyBlYWNoIENETkkgaW50ZXJmYWNlIGluZGl2aWR1YWxs eQ0KICAgYW5kIGhpZ2hsaWdodGluZyBleGFtcGxlIGNhbmRpZGF0ZSBwcm90b2NvbHMgdGhhdCBj b3VsZCBjb25zaWRlcmVkIGZvcg0KICAgcmV1c2Ugb3IgbGV2ZXJhZ2luZyB0byBpbXBsZW1lbnQg dGhlIENETkkgaW50ZXJmYWNlcy4gIA0KDQoNCjMpIFNlY3Rpb24gNSBpcyBjdXJyZW50bHkgdGl0 bGUgIkdhcCBBbmFseXNpcyBvZiByZWxldmFudCBTdGFuZGFyZGlzYXRpb24gYW5kIFJlc2VhcmNo IEFjdGl2aXRpZXMiIGJ1dCBmb2xsb3dpbmcgdGhlIGFncmVlbWVudCBhdCB0aGUgbGFzdCBJRVRG IHRvIG1vdmUgdGhlIGdlbmVyaWMgZGVzY3JpcHRpb25zIG9mIG90aGVyIGFjdGl2aXRpZXMgaW50 byBhbiBhcHBlbmRpeCBTZWN0aW9uIDUgbm8gbG9uZ2VyIHJlZmVyZW5jZXMgYW55IHJlc2VhcmNo IGFjdGl2aXRpZXMgc28gSSBwcm9wb3NlIGNoYW5naW5nIHRoZSB0aXRsZSB0byIgR2FwIEFuYWx5 c2lzIG9mIHJlbGV2YW50IFN0YW5kYXJkaXNhdGlvbiBhY3Rpdml0aWVzIi4NCg0KNCkgQWZ0ZXIg dGhlIGdlbmVyYWwgaW50cm9kdWN0aW9uIGluIFNlY3Rpb24gNSB0aGVyZSBhcmUgb25seSBzZWN0 aW9ucyB0aGF0IG91dGxpbmUgb3RoZXIgcmVzZWFyY2ggYWN0aXZpdGllcyBmb3IgQ29udGVudCBB Y3F1aXNpdGlvbiAoc2VjdGlvbiA1LjEpIGFuZCBDRE5JIE1ldGFkYXRhIChTZWN0aW9uIDUuMikg YnV0IHRoZXJlIGFyZSBub3Qgc2VjdGlvbnMgZm9yIHRoZSBvdGhlciBDRE5JIGludGVyZmFjZXMg KENvbnRyb2wsIExvZ2dpbmcsIFJlcXVlc3QgUm91dGluZykuDQoNClRoZSByZWFzb24gZm9yIHRo ZSBsYWNrIG9mIHRleHQgaXMgSU1PIGJlY2F1c2UgdGhlcmUgaXMgbm8gY3VycmVudCBvciBwYXN0 IHN0YW5kYXJkaXNhdGlvbiBhY3Rpdml0eSBhZGRyZXNzaW5nIHRob3NlIGFyZWFzIGJ1dCB0aGUg ZG9jdW1lbnQgY3VycmVudGx5IGRvZXMgbm90IG1lbnRpb24gdGhhdCBhbmQgdGhlcmVmb3JlIGdp dmVzIHRoZSBpbXByZXNzaW9uIG9mIGJlaW5nIGluY29tcGxldGUuDQoNCkkgdGhlcmVmb3JlIHBy b3Bvc2UgbWFraW5nIHRoZSBmb2xsb3dpbmcgY2hhbmdlIHRvIHRoZSBsYXN0IHNlbnRlbmNlIGlu IFNlY3Rpb24gNToNCg0KT0xEOg0KICAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyB3aWxsIHN1bW1h cml6ZSB0aGUgZXhpc3Rpbmcgd29yayBvZiB0aGUNCiAgIHN0YW5kYXJkIGJvZGllcyBhYm92ZSBh Z2FpbnN0IHRoZSBDRE5JIHByb2JsZW0gc3BhY2UuDQpORVc6DQogICBUaGUgZm9sbG93aW5nIHNl Y3Rpb25zIHdpbGwgc3VtbWFyaXplIHRoZSBleGlzdGluZyB3b3JrIG9mIHRoZQ0KICAgc3RhbmRh cmQgYm9kaWVzIGFib3ZlIGFnYWluc3QgdGhlIENETkkgcHJvYmxlbSBzcGFjZS4gU2VjdGlvbiA1 LjENCiAgIHN1bW1hcmlzZXMgZXhpc3RpbmcgaW50ZXJmYWNlcyB0aGF0IGNvdWxkIGJlIGxldmVy YWdlZCBmb3IgY29udGVudA0KICAgYWNxdWlzaXRpb24gYmV0d2VlbiBDRE5zIGFuZCBTZWN0aW9u IDUuMiBzdW1tYXJpc2VzIGV4aXN0aW5nIG1ldGFkYXRhIA0KICAgc3BlY2lmaWNhdGlvbnMgdGhh dCBtYXkgYmUgYXBwbGljYWJsZSB0byBDRE5JLiBUbyBkYXRlIHRoZXJlIGlzIG5vDQogICBleGlz dGluZyBzdGFuZGFyZGlzYXRpb24gYWN0aXZpdGllcyBpbiB0aGUgYXJlYXMgb2YgdGhlIHJlbWFp bmluZw0KICAgQ0ROSSBpbnRlcmZhY2VzIChDRE5JIFJlcXVlc3QgUm91dGluZywgQ0ROSSBDb250 cm9sIGFuZCBDRE5JIExvZ2dpbmcpLg0KDQo1KSBJIGFsc28gcHJvcG9zZSB1c2luZyB0aGUgZm9s bG93aW5nIHRleHQgZm9yIHRoZSB0aGlyZCBidWxsZXQgaW4gU2VjdGlvbiA1IHVubGVzcyBzb21l b25lIGNhbiBzdWdnZXN0IG1vcmUgYXBwcm9wcmlhdGUgdGV4dCB0byBzdW1tYXJpc2UgaW4gYSBz ZW50ZW5jZSBvciB0d28gYW55IENETiBtZXRhZGF0YSByZWxhdGVkIHdvcmsgaW4gb3RoZXIgc3Rh bmRhcmRzIGJvZGllcy4NCg0KT0xEOg0KICAgbyAgPFRPRE86IEFkZCBhIHNlbnRlbmNlIG9uIElU VT4NCk5FVzoNCiAgIG8gIENhYmxlTGFicywgU05JQSBhbmQgSVRVIGhhdmUgZGVmaW5lZCAob3Ig YXJlIHdvcmtpbmcgb24pDQogICAgICBkZWZpbml0aW9ucyBmb3IgY29udGVudCByZWxhdGVkIG1l dGFkYXRhIGRlZmluaXRpb25zIGFuZCBzcGVjaWZpY2F0aW9uDQogICAgICBmb3IgaXRzIGRpc3Ry aWJ1dGlvbi4gSG93ZXZlciwgdGhleSBkbyBub3QgaW5jbHVkZSBtZXRhZGF0YSBzcGVjaWZpYw0K ICAgICAgdG8gdGhlIGRpc3RyaWJ1dGlvbiBvZiBjb250ZW50IHdpdGhpbiBhIENETiBvciBiZXR3 ZWVuIGludGVyY29ubmVjdGVkDQogICAgICBDRE5zLg0KDQo2KSBTZWN0aW9uIDEwLjEgbGlzdHMg YSBudW1iZXIgb2YgIm5vcm1hdGl2ZSByZWZlcmVuY2VzIiwgaWYgd2UgYWRvcHQgdGhlIHByb3Bv c2VkIGNoYW5nZXMgYWJvdmUgaXQgd2lsbCBlbmQgdXAgY29udGFpbmluZyAibm9ybWF0aXZlIiBy ZWZlcmVuY2VzIHRvOg0KICAgLSBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzDQogICAtIGRyYWZ0 LWJlcnRyYW5kLWNkbmktZXhwZXJpZW1lbnRzDQogICAtIGRyYWZ0LWplbmtpbnMtY2RuaS1uYW1l cw0KICAgLSBSRkMyMTE5DQoNCkFmdGVyIHJlYWRpbmcgdGhyb3VnaCB0aGUgdGV4dCBvZiB0aGUg UHJvYmxlbSBTdGF0ZW1lbnQgYWdhaW4sIEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IHRoZSBQcm9i bGVtIFN0YXRlbWVudCByZWZlcmVuY2VzIGFueSBvZiB0aG9zZSBkb2N1bWVudHMgbm9ybWF0aXZl bHkgYXMgdGhlIDMgQ0ROSSByZWxhdGVkIGRyYWZ0cyBhcmUgcmVmZXJlbmNlZCBpbiBhIGNvbnRl eHQgd2hlcmUgdGhleSBhcmUgZm9yIGZ1cnRoZXIgaW5mb3JtYXRpb24gYW5kIHRoZSBQcm9ibGVt IFN0YXRlbWVudCBkb2VzIG5vdCBtYWtlIHVzZSBvZiBhbnkgb2YgdGhlIGNhcGl0YWxpc2VkIHRl cm1zIGRlZmluZWQgaW4gUkZDMjExOS4NCg0KVGhlcmVmb3JlLCB1bmxlc3MgYW55b25lIG9iamVj dHMgSSB3aWxsIG1vdmUgdGhlIHJlZmVyZW5jZXMgZm9yIHRoZSB0aHJlZSBDRE5JIHJlbGF0ZWQg ZHJhZnRzIHRvIHRoZSAiSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyIgc2VjdGlvbiBhbmQgcmVtb3Zl IHRoZSByZWZlcmVuY2UgZm9yIFJGQzIxMTkuDQoNCg0KVGhhbmtzDQpCZW4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0 DQpDRE5pQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nk bmkNCg== From flefauch@cisco.com Wed Oct 19 08:16:30 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08B5821F84BC for ; Wed, 19 Oct 2011 08:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.637 X-Spam-Level: X-Spam-Status: No, score=-5.637 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mbEJf7ZH8pX for ; Wed, 19 Oct 2011 08:16:29 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 24A1D21F84B7 for ; Wed, 19 Oct 2011 08:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=26240; q=dns/txt; s=iport; t=1319037389; x=1320246989; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=YABRIR45+okgKpwmRzBTeVDqmmr3RRGPwAgpo3CEq4o=; b=BBjYHOuI2EefUO3AiboGmsdJEOs4IEQAV3NnQ8RUD31VUF/uPyWalpDN Q1azM501LTTWAgj3PKkJeNW5oK/zljgB92RdYmGsquHyH8FGCNN50zFmH mKuA+78T2f70kTIPbW7qxDmJsWzatw0nVsBgJjxLgE5b+V3f1W6DHQDqo 8=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,372,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="8893215" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 19 Oct 2011 15:16:17 +0000 Received: from sjc-vpn4-1154.cisco.com (sjc-vpn4-1154.cisco.com [10.21.84.129]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9JFGG97005940; Wed, 19 Oct 2011 15:16:16 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-188--719622329 From: Francois Le Faucheur In-Reply-To: <26AB1301-B8C8-423C-A1E4-B6BE0290735B@niven-jenkins.co.uk> Date: Wed, 19 Oct 2011 08:17:57 -0700 Message-Id: References: <9041A3C5-056C-4ED3-A697-FF6A49E1F3F3@cisco.com> <26AB1301-B8C8-423C-A1E4-B6BE0290735B@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] Proposal for a CDNI Metadata model & interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:16:30 -0000 --Apple-Mail-188--719622329 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 18 Oct 2011, at 01:00, Ben Niven-Jenkins wrote: > Francois, >=20 > Good question, see below. >=20 > On 17 Oct 2011, at 21:10, Francois Le Faucheur wrote: >> So to deal with metadata changes/invalidation reactively, the = uCDN/dCDN would play with TTL and conditional gets. >> So we end up with deployment trade-offs requiring tuning between = reactivity and revalidation load. >> Support of update/removal in the CDNI interface would allow to ensure = high reactivity for the important changes (eg immediately stop serving = content to a given region) while setting TTLs higher to ensure low = revalidation load. >> Is your motivation to exclude support for update/removal to keep = things as simple as possible so the group can define a minimum solution = asap, or do you think update/removal won't be needed at all even if we = picture large scale deployments. >=20 > Neither. Although we don't say so explicitly in the draft our thinking = was to model explicit CDNI Metadata invalidation/removal in the same = manner as explicit invalidation/removal of actual content and have that = performed via a request over the CDNI Control interface That can work also. Regardless of the actual approach to do so, there = seems to be agreement that we do need to be able to trigger = "delete/purge" metadata. Good. Thanks Francois > rather than having two separate approaches - one for CDNI metadata and = a different one for the content itself. >=20 > Ben >=20 Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-188--719622329 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-189--719622329 --Apple-Mail-189--719622329 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Francois,

Good question, see below.

On = 17 Oct 2011, at 21:10, Francois Le Faucheur wrote:
So to deal with metadata changes/invalidation reactively, = the uCDN/dCDN would play with TTL and conditional = gets.
So we end up with = deployment trade-offs requiring tuning between reactivity and = revalidation load.
Support of = update/removal in the CDNI interface would allow to ensure high = reactivity for the important changes (eg immediately stop serving = content to a given region) while setting TTLs higher to ensure low = revalidation load.
Is your = motivation to exclude support for update/removal to keep things as = simple as possible so the group can define a minimum solution asap, or = do you think update/removal won't be needed at all even if we picture = large scale deployments.

Neither. Although we don't = say so explicitly in the draft our thinking was to model explicit CDNI = Metadata invalidation/removal in the same manner as explicit = invalidation/removal of actual content and have that performed via a = request over the CDNI Control interface =

That can work also. Regardless of = the actual approach to do so, there seems to be agreement that we do = need to be able to trigger "delete/purge" metadata. = Good.
Thanks
Francois

rather than having two separate approaches - one for = CDNI metadata and a different one for the content = itself.

Ben




Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-189--719622329 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-189--719622329-- --Apple-Mail-188--719622329-- From Jan.Seedorf@neclab.eu Wed Oct 19 08:53:12 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E17B21F84FD; Wed, 19 Oct 2011 08:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCniyqZesabA; Wed, 19 Oct 2011 08:53:11 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 90A6321F851F; Wed, 19 Oct 2011 08:53:09 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C586E280001DA; Wed, 19 Oct 2011 17:53:17 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office.hd) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWOwtHy9SLAT; Wed, 19 Oct 2011 17:53:17 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id A3213280001AA; Wed, 19 Oct 2011 17:53:07 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.12]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 19 Oct 2011 17:52:58 +0200 From: Jan Seedorf To: "cdni@ietf.org" , "alto@ietf.org" Thread-Topic: Draft submitted on ALTO for CDNi request routing Thread-Index: AcyOdsKTya0HC6UWS0CBvXWXbwsQkg== Date: Wed, 19 Oct 2011 15:52:58 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE1D90ED8E@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: multipart/alternative; boundary="_000_2779C9F0771F974CAD742BAE6D9904FE1D90ED8EDAPHNISofficehd_" MIME-Version: 1.0 Subject: [CDNi] Draft submitted on ALTO for CDNi request routing X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:53:12 -0000 --_000_2779C9F0771F974CAD742BAE6D9904FE1D90ED8EDAPHNISofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CDNi folks, ALTO folks, I have just submitted a new draft which discusses how ALTO could help in CD= Ni request routing: Abstract: "... This document focusses on the Request Routing Interface of CDNi, and m= ore specifically on how the solutions currently being defined in the Applic= ation Layer Traffic Optimization (ALTO) WG can improve CDNi request routing= . The overall intention behind this document is to foster discussions (in = the CDNi as well as in the ALTO WG) regarding a) if, b) how, and c) under w= hat conditions ALTO can be useful to optimize CDNi request routing. As bas= is for this discussion, this document provides concrete examples of how ALT= O can be integrated within CDNi request routing. The examples in this do= cument are based on the use cases and examples currently being discussed in= the CDNi WG." http://www.ietf.org/id/draft-seedorf-alto-for-cdni-00.txt Comments (from CDNi WG and ALTO WG) are welcome, - Jan --_000_2779C9F0771F974CAD742BAE6D9904FE1D90ED8EDAPHNISofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= CDNi folks, ALTO folks,=

=  

= I have just submitted a new draft which discusse= s how ALTO could help in CDNi request routing:

=  

= Abstract:

= “… This document focusses on the Req= uest Routing Interface of CDNi, and more specifically on how the solutions currently being defined in the Application Layer Traffic Optimization (ALT= O) WG can improve CDNi request routing.  The overall intention behind = this document is to foster discussions (in the CDNi as well as in the ALTO = WG) regarding a) if, b) how, and c) under what conditions ALTO can be useful to optimize CDNi request routing. = As basis for this discussion, this document provides concrete examples of = how ALTO can be integrated within CDNi request routing.  The examples = in this   document are based on the use cases and examples currently being discussed in the CDNi WG.”

=  

= http://www.ietf.org/id/draft-seedorf-alto-for-cdni-00= .txt

=  

= Comments (from CDNi WG and ALTO WG) are welcome,=

=  

-          Jan

--_000_2779C9F0771F974CAD742BAE6D9904FE1D90ED8EDAPHNISofficehd_-- From flefauch@cisco.com Wed Oct 19 08:59:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9111F21F8C90 for ; Wed, 19 Oct 2011 08:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.522 X-Spam-Level: X-Spam-Status: No, score=-5.522 tagged_above=-999 required=5 tests=[AWL=-0.344, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoSBwpKOweLD for ; Wed, 19 Oct 2011 08:59:57 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED4121F8C8F for ; Wed, 19 Oct 2011 08:59:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=40335; q=dns/txt; s=iport; t=1319039997; x=1320249597; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=r6fm8DGV2gSRRT6ZyCTqpb3iphK/NvNmYeEQPAneqJs=; b=WjMmQMKBhKeNRmVdw5R1JNmMkzBQHgbE0IYO66EUXy9cKm7ij+Xu7juo RzdPtueeYjJ23lEedz3HLw40alrO1NAvG/SFO/u/09nRo40LJVQdwbx9Q wkddN6/LwH3oJouDGC1ZfAJ3NQQXMwR3+nLbmSxkdsltxB17hSDuxVvwC 0=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,373,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="8870324" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 19 Oct 2011 15:59:53 +0000 Received: from sjc-vpn4-1154.cisco.com (sjc-vpn4-1154.cisco.com [10.21.84.129]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p9JFxr5Y032278; Wed, 19 Oct 2011 15:59:53 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-253--717006628 From: Francois Le Faucheur In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B6682887@MAILR002.mail.lan> Date: Wed, 19 Oct 2011 09:01:33 -0700 Message-Id: References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C651B6682887@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:59:58 -0000 --Apple-Mail-253--717006628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi again, Thanks for the responses. See embedded below: On 18 Oct 2011, at 07:26, Kevin J Ma wrote: > Hi Francois, >=20 > comments inline: >=20 >> From: Francois Le Faucheur [mailto:flefauch@cisco.com] >> Sent: Monday, October 17, 2011 3:43 PM >> To: Kevin J Ma >> Cc: Francois Le Faucheur; cdni@ietf.org >> Subject: Re: [CDNi] CDNI Metadata Interface >>=20 >> Hello Kevin, >>=20 >> [with Individual hat on] >>=20 >> A first set of high level questions: >>=20 >> * directionality of metadata creation/retrieval/removal/update = mechanism: >> Could you clarify which of the above operation you see possibly = happening >> in which direction? >> For example, regarding update/removal, do you see: >> *a) the POST possibly being issued towards the uCDN to >> update/remove some metadata in the uCDN repository? >> *b) the POST possibly being issued by the uCDN towards the dCDN = to >> update/remove some metadata in the dCDN repository (after some = out-of-date >> metadata had been retrieved by dCDN from uCDN). >> For example, regarding retrieval, clearly we want the dCDN to issue a = GET >> towards the uCDN to acquire metadata. Now do you see that the GET = could >> possibly be also issued by the uCDN to check metadata stored by the = dCDN? >=20 > I think POSTs make the most sense going from upstream to downstream. > The agent was intended to moderate this, since any given pair of CDNs > could be both a uCDN and a dCDN for each other in different domains. Do we agree POST would normally be dis-allowed in dCDN-uCDN direction = (regardless of whether this is "enforced" by the Agent or something = else)? Regarding the use of POST for metadata creation, are you proposing it so = it is used by the uCDN to "create" metadata in the dCDN (ie to = pre-populate metadata in the dCDN) or are you proposing it so it is used = by say a CP to "create" the metadata in the uCDN that will then be = "pulled" by dCDN? (for metadata pre-positioning in dCDN, I had been thinking more of an = approach where the uCDN would issue a trigger instructing the dCDN to = GET the corresponding metadata) >=20 > I see no reason why GETs could not go in both directions. I can see a > case where upstream entities would want to verify downstream entities. Agreed. In any case, I would suggest that you discuss/document directionality in = upcoming versions, possibly though some table capturing all the possible = cases. >=20 >> * in your CDNI metadata model, a "domain" is directly associated with = a >> set of "hostnames". So this assumes that the same set of unmodified >> hostnames is used unmodified everywhere in all the potential dCDNs. = That >> can be the case in some deployment, but that may not always be the = case. >> For example, when HTTP redirection is used across CDNs, an upstream = CDN >> may want to modify (possibly hide) the actual content provider = hostnames >> (and possibly part of the URI path) when redirecting to a dCDN (I = believe >> this is mentioned in the framework). >=20 > I was thinking (though it is not noted in the document) that hostname > lists could be different in different dCDNs. What is not entirely > clear to me is how metadata would get set across cascaded CDNs, > i.e., if the CP contracts CDN-A, and CDN-A makes a deal with CDN-B, > and CDN-B makes a deal with CDN-C, does the CP or CDN-A know about > CDN-C and is the CP or CDN-A responsible configuring metadata on > CDN-C? Or, is CDN metadata only configured by the most immediate > uCDN (or the CP), i.e., only CDN-B (or the CP) will know the values of > metadata in CDN-C? In my opinion, everything would typically operate as a chain, because = the typical relationships between entities will be as a chain: CP knows CDN-A, CDN-A knows CDN-B, CDN-B knows CDN-C. So: * CDN-A would be responsible for crafting the metadata that will = be pulled by CDN-B. CDN-A may elect to allow CP to directly populate = (some/all) these metadata (so it does correctly reflect its policy). * CDN-B would then be responsible for crafting the metadata that = will be pulled by CDN-C. CDN-B may elect to allow CDN-A to directly = populate (some/all) these metadata (so it does correctly reflect its = policy). * etc. In any case, do you agree with the idea of having the = hostname/resource-sets be tied to the Agent (so they can be different on = a per CDN basis)? >=20 >> Would you consider modifying your proposed CDNI model to allow for = the >> fact that a domain may be "referenced" differently by some dCDNs than = by >> the uCDN? >> I think it means: >> * the concept of "hostnames" should be made more flexible so it >> matches not just on hostnames but on pattern match over = hostname/path. >> Let's call this "resource sets". >> * "resource sets" should be dependent on "Agents". So perhaps it >> shoudl be folded inside your "Metadata" so it can be defined on a per >> "dCDN" basis. >> Would that work for you? >=20 > Would the goal be to use the entire hostname/uri as a single combined > key? I do not have a problem with merging them if we think that it > would be useful. I do think it is useful to associate to a domain something that is more = flexible than hostname. For example, a hostname+beginning-of-path. In some cases, it will just be hostnames. In some cases, it will be = finer-grain Thanks Francois >=20 >> * in section 3.3.3, you have a couple of examples showing >> "/CDNI/MI/domain". Should those not say "/CDNI/MI/metadata"? >=20 > Yep. Those are cut and paste errors, good catch! I will fix those. >=20 > thanx! >=20 > -- Kevin J. Ma >=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >>=20 >>=20 >> On 6 Oct 2011, at 22:21, Kevin J Ma wrote: >>=20 >>=20 >> Hi all, >>=20 >> Just uploaded a new I-D with a proposed metadata model and API: >>=20 >> http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt >>=20 >> The model takes a rather generic approach to metadata representation >> to support opaque metadata and addresses some of the security issues >> associated with metadata retrieval. Comments welcome. >>=20 >> thanx. >>=20 >> -- Kevin J. Ma >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-253--717006628 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-254--717006628 --Apple-Mail-254--717006628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = again,

Thanks for the responses. See embedded = below:

On 18 Oct 2011, at 07:26, Kevin J Ma = wrote:

Hi Francois,

 comments = inline:

From: Francois Le Faucheur = [mailto:flefauch@cisco.com]
Sent: Monday, October 17, 2011 3:43 = PM
To: Kevin J = Ma
Cc: Francois Le Faucheur; = cdni@ietf.org
Subject: Re: [CDNi] CDNI Metadata = Interface

Hello = Kevin,

[with = Individual hat on]

A first set of = high level questions:

* = directionality of metadata creation/retrieval/removal/update = mechanism:
Could you clarify = which of the above operation you see possibly = happening
in which = direction?
For example, = regarding update/removal, do you see:
= *a)  the POST possibly being issued towards the uCDN = to
update/remove some metadata = in the uCDN repository?
*b) the = POST possibly being issued by the uCDN towards the dCDN = to
update/remove some metadata = in the dCDN repository (after some = out-of-date
metadata had been = retrieved by dCDN from uCDN).
For example, regarding retrieval, clearly we want the dCDN = to issue a GET
towards the = uCDN to acquire metadata. Now do you see that the GET = could
possibly be also issued = by the uCDN to check metadata stored by the dCDN?

I = think POSTs make the most sense going from upstream to = downstream.
The agent was intended to moderate this, since any given = pair of CDNs
could be both a uCDN and a dCDN for each other in = different domains.

Do we agree = POST would normally be dis-allowed in dCDN-uCDN direction (regardless of = whether this is "enforced" by the Agent or something = else)?

Regarding the use of POST for metadata = creation, are you proposing it so it is used by the uCDN to = "create" metadata in the dCDN (ie to pre-populate metadata in the dCDN) = or are you proposing it so it is used by say a CP to "create" the = metadata in the uCDN that will then be "pulled" by dCDN?
(for = metadata pre-positioning in dCDN, I had been thinking more of an = approach where the uCDN would issue a trigger instructing the dCDN to = GET the corresponding metadata)


I see no reason why GETs could not go in = both directions.  I can see a
case where upstream entities would = want to verify downstream = entities.

Agreed.

=
In any case, I would suggest that you = discuss/document directionality in upcoming versions, possibly = though some table capturing all the possible = cases.


* in your CDNI metadata model, a "domain" is directly = associated with a
set of = "hostnames". So this assumes that the same set of = unmodified
hostnames is used = unmodified everywhere in all the potential dCDNs. = That
can be the case in some = deployment, but that may not always be the = case.
For example, when HTTP = redirection is used across CDNs, an upstream = CDN
may want to modify = (possibly hide) the actual content provider = hostnames
(and possibly part = of the URI path) when redirecting to a dCDN (I = believe
this is mentioned in = the framework).

I was thinking (though it is not = noted in the document) that hostname
lists could be different in = different dCDNs.  What is not entirely
clear to me is how = metadata would get set across cascaded CDNs,
i.e., if the CP = contracts CDN-A, and CDN-A makes a deal with CDN-B,
and CDN-B makes a = deal with CDN-C, does the CP or CDN-A know about
CDN-C and is the CP = or CDN-A responsible configuring metadata on
CDN-C?  Or, is CDN = metadata only configured by the most immediate
uCDN (or the CP), = i.e., only CDN-B (or the CP) will know the values of
metadata in = CDN-C?

In my opinion, = everything would typically operate as a chain, because the typical = relationships between entities will be as a chain:
CP knows = CDN-A, CDN-A knows CDN-B, CDN-B knows = CDN-C.
So:
* CDN-A would be responsible = for crafting the metadata that will be pulled by CDN-B. CDN-A may elect = to allow CP to directly populate (some/all) these metadata (so it does = correctly reflect its policy).
* CDN-B would then be responsible = for crafting the metadata that will be pulled by = CDN-C. CDN-B may elect to allow CDN-A to directly populate = (some/all) these metadata (so it does correctly reflect its = policy).
= * etc.

In any case, do you agree = with the idea of having the hostname/resource-sets be tied to the Agent = (so they can be different on a per CDN basis)?


Would you consider = modifying your proposed CDNI model to allow for = the
fact that a domain may be = "referenced" differently by some dCDNs than = by
the = uCDN?
I think it = means:
* the = concept of "hostnames" should be made more flexible so = it
matches not just on = hostnames but on pattern match over = hostname/path.
Let's call this = "resource sets".
* = "resource sets" should be dependent on "Agents". So perhaps = it
shoudl be folded inside = your "Metadata" so it can be defined on a = per
"dCDN" = basis.
Would that work for = you?

Would the goal be to use the entire = hostname/uri as a single combined
key?  I do not have a problem = with merging them if we think that it
would be = useful.

I do think it is = useful to associate to a domain something that is more flexible than = hostname. For example, a hostname+beginning-of-path.
In some = cases, it will just be hostnames. In some cases, it will be = finer-grain

Thanks

Franc= ois


* in section 3.3.3, you have a couple of examples = showing
"/CDNI/MI/domain". = Should those not say "/CDNI/MI/metadata"?

Yep. =  Those are cut and paste errors, good catch!  I will fix = those.

thanx!

--  Kevin J. Ma

Cheers

Francois




On 6 Oct 2011, = at 22:21, Kevin J Ma wrote:


Hi = all,

Just uploaded = a new I-D with a proposed metadata model and = API:

  http://www.ietf.org/internet-drafts/draft-ma-cdni-metadata-00.txt
=

The model takes a rather generic approach to metadata = representation
to support = opaque metadata and addresses some of the security = issues
associated with = metadata retrieval.  Comments welcome.

thanx.

--  Kevin = J. Ma

_______________________________________________
CDNi mailing = list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni





Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-254--717006628 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-254--717006628-- --Apple-Mail-253--717006628-- From internet-drafts@ietf.org Wed Oct 19 12:39:16 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFF311F0C45; Wed, 19 Oct 2011 12:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UahOVF2Ru-R1; Wed, 19 Oct 2011 12:39:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0E521F8A57; Wed, 19 Oct 2011 12:39:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.61 Message-ID: <20111019193916.22274.53537.idtracker@ietfa.amsl.com> Date: Wed, 19 Oct 2011 12:39:16 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:39:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnec= tion Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-01.txt Pages : 20 Date : 2011-10-19 Content Delivery Networks (CDNs) are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. There is a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. This draft is a work in progress and requirements may be added, modified, or removed by the working group. Requirements Language The key words "High Priority", "Medium Priority" and= "Low Priority" in this document are to be interpreted in the following way: o "High Priority" indicates requirements that are to be suppo= rted by the CDNI interfaces. A requirement is stated as "High Priority&= quot; when it is established by the working group that it can be met without compromising the targeted schedule for WG deliverables, or when it is established that specifying a solution without meeting this requirement would not make sense and would justify re- adjusting the WG schedule, or both. This is tagged as "[HIGH]&q= uot;. o "Medium Priority" indicates requirements that are to be sup= ported by the CDNI interfaces unless the WG realizes at a later stage that attempting to meet this requirement would compromise the overall WG schedule (for example it would involve complexities that would result in significantly delaying the deliverables). This is tagged as "[MED]". o "Low Priority" indicates requirements that are to be suppor= ted by the CDNI interfaces provided that dedicating WG resources to this work does not prevent addressing "High Priority" and "= Medium Priority" requirements and that attempting to meet this requirement would not compromise the overall WG schedule. This is tagged as "[LOW]". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-requirements-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-requirements-01.txt From kleung@cisco.com Wed Oct 19 12:40:18 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B754C21F8A69 for ; Wed, 19 Oct 2011 12:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xu11ogulUJFG for ; Wed, 19 Oct 2011 12:40:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50521F85F1 for ; Wed, 19 Oct 2011 12:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=40213; q=dns/txt; s=iport; t=1319053213; x=1320262813; h=mime-version:subject:date:message-id:from:to:cc; bh=EHASWRHLBkGh0R3GJDC6QGmzX50P5oJmyJ0hoV8GWVc=; b=jifNgDfNsGnkK2kFN+PThKwpdkveEe8AbYHg1IMxxD+GpxPn2CW9AzbQ QFTu1Z0D2Bh4a7HroWnHA2tOc+fRpqmA+2IWYjW/niP3JxoL5aR6TIoP5 rSUASDr+GwZ94TScQsSPoEp7z+EUFhKGQmXBO9fDBKPrOEQ8D7KS6s1ix k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPgmn06tJXG8/2dsb2JhbABEgk2mM4EFgXABBBIBCREDQAkSARoQBhABBwdIDwEEGxMHnyoBnkiHOmEEiAKRL4xE X-IronPort-AV: E=Sophos;i="4.69,373,1315180800"; d="scan'208,217";a="29578849" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 19 Oct 2011 19:40:12 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9JJeB4B030538; Wed, 19 Oct 2011 19:40:12 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 12:40:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8E96.EA6A30D5" Date: Wed, 19 Oct 2011 12:40:09 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC521013DB55@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed update to CDNI requirements draft Thread-Index: AcyOlukkhOp5tgRCStmJJhptnWkdwA== From: "Kent Leung (kleung)" To: X-OriginalArrivalTime: 19 Oct 2011 19:40:12.0032 (UTC) FILETIME=[EAAC9800:01CC8E96] Subject: [CDNi] Proposed update to CDNI requirements draft X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:40:18 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC8E96.EA6A30D5 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi folks. We've received a few comments from the WG on the base = requirements draft (-00). There are some open issues marked for review. = In the attempt to "clean up" and expedite progress, here's a list of = proposed resolutions for the identified open issues in draft and WG = feedback. Since it may be easier to read the requirements document in = its entirety, the ver-01 will be published with the changes. Of course, = any further WG discussions and conclusions will be captured in the = subsequent version. =20 =20 Please review and comment. We believe that the draft is in stable = condition. If anyone disagrees, please specify any open issues that = need to be addressed. Thanks. =20 ----- Open issue list in draft ver-00: =20 1. Intro: OPEN ISSUE: Should requirements in each section be ordered by = priority? Resolution: Requirements are logically grouped. No need to be ordered = by priority which may change during working group discussions. =20 2. GEN-9: OPEN ISSUE: arbitrary number should more than one level?) Resolution: Change "to an arbitrary number of levels" to "to an = arbitrary number of levels beyond the first level" =20 3. GEN-13: OPEN ISSUE: Virtualization is transparent to CDNI, remove = requirement or justify why uCDN/dCDN needs to be aware?) Resolution: Requirement removed. =20 4. GEN-14: OPEN ISSUE: Add HTTP ABR requirements Resolution: Update requirement with "GEN-14: [HIGH] The CDNI solution = shall support HTTP Adaptive Bit Rate (ABR) content." =20 5. CNTL-4: OPEN ISSUE: how much influence the Upstream CDN ought to have = on pre-positioning of the content on surrogates inside the Downstream = CDN is TBD The surrogates in the Downstream CDN are not required to be exposed to = the Upstream CDN. =20 Resolution: Remove OPEN ISSUE comment. =20 6. REQ-1: OPEN ISSUE: Belong to Control Interface section? Resolution: Change "Control" to "Request-Routing" as the information = pertains to request routing function. =20 7. REQ-5/REQ-6: OPEN ISSUE: Surrogate selection is out of scope? Accuracy of the Surrogate selection was described as an example. There = is no requirement for Surrogate selection. Resolution: Remove OPEN ISSUE comment. =20 8. REQ-9: OPEN ISSUE: Why route looped request? The loop prevention mechanism should avoid request redirection loop. Resolution: Add "... by avoiding the loop ..." in the requirement as = clarification. =20 9. META-3: OPEN ISSUE: Confirm high priority Dynamic CDNI metadata acquisition is required. Resolution: Remove OPEN ISSUE comment =20 10. META-4: OPEN ISSUE: Confirm medium priority Pre-positioned CDNI metadata acquisition is considered medium priority? Resolution: Remove OPEN ISSUE comment =20 11. META-14: OPEN ISSUE: Expiration time needed? Expiration time may be included to remove content. Resolution: Remove OPEN ISSUE comment =20 10. LOG section: Editor's note: should we add a requirement for support = of aggregate/ summarized logs Resolution: Add the following new requirement: LOG-10 [LOW] The CDNI Logging interface may support aggregate/ = summarized logs (e.g. total bytes delivered for a content regardless of = individual User Agents to which it was delivered). =20 11. CNTL-1: Added "Only the object(s) and CDNI metadata that pertain to = the requesting Upstream CDN are allowed to be purged." to "Delete an = object" bullet. =20 =20 ----- WG feedback: =20 1. >>- Should REQ-1 be under Section 4 rather than 5? =20 KL> This is noted in the "OPEN ISSUE" statement. Unless there are = objections, this requirement should be moved to Section 4 CDNI Control = Interface. =20 Resolution: See #6 above. =20 2. >>- I think REQ-2 should be a MUST, and it should be written in the=20 >>context of=A9"The Upstream CDN MUST request aggregate information from = >>the Downstream CDN to facilitate=A9" If it's not a request, then it=20 >>must go the other way (the Downstream CDN MUST report to the Upstream=20 >>CDN). =20 KL> This requirement can be split into two. One for mandatory = parameters for base function of CDN selection (e.g. content types, = footprint). The other for optional parameters that can be useful (e.g. = metrics/attributes, affinities). The specific parameters should be left = for the solution draft to deal with. The "request" and "report" are RRI = pull and push, respectively. (See terms in framework draft). In this = requirement description, we've describe it more generically. =20 After consulting with other authors, the conclusion was that the = essential parameters used for request routing can be configured at the = Upstream CDN. Therefore, Request Routing Interface support for any of = the parameters is considered as optional. =20 Resolution: No action. =20 3. >>- In addition, I think REQ-2 should really be part of the control=20 >>protocol. >>This information should be known prior to initiating a Route Request. >>- Under the control protocol requirements, there is no requirement as=20 >>to how often this should occur. =20 KL> The need for information to be known by uCDN prior to route request = is only for the iterative CDNI request routing case. RRI supports this = with the push model. =20 Resolution: No action. =20 4. >>- Should REQ-4 also be under Section 4 rather than 5? =20 KL> I think there may still be some more debate on which functions = belong to RRI vs. Control Interface. If this requirement remains in the = Control Interface, it should be moved to Section 5 CDNI Control = Interface. =20 Resolution: Changed "Control interface" to "Request-Routing = architecture" in requirement because the information pertains to request = routing function. =20 5. >>- GEN-11 - With this requirement, it appears some other = requirements=20 >>are redundant or unnecessary. =20 =20 KL> For what it's worth, this is a generic requirement for loop free = information exchange. There may need to be explicit requirements = within the CDNI interface based on specific context. I think there's = some value in that. Open to disagreements and suggestions to delete = requirements or add new requirements.=20 =20 Resolution: No action. =20 6. >>- Section 6 - Is this intended to be a protocol within the control=20 >>protocol? To me it looks like it should. Another way to ask it is,=20 >>can this be included within the control protocol? =20 KL> Section 6 is for CDNI Metadata Distribution Interface. The function = is to distribute CDNI metadata. So we can avoid coupling protocols or = not debate in the requirements draft. That should be left to the = solution draft. =20 Resolution: No action =20 >>- R59 - Should it also include "alternative content" sources, options, = >>etc. in the case of "blackouts"? =20 7. KL> The list contains examples of content distribution control = policies. It's open to other examples that are commonly use or deemed = valuable. I'm not clear about alternative content sources. Maybe you = can provide some text to clarify? =20 Resolution: No action =20 8. >>- Section 7 - Should there be a "quality" metric or respond from = the=20 >>downstream CDN on the delivered content to the End user? >>=20 =20 KL> This could be a new [MED] or [LOW] priority requirement. =20 Resolution: Add new requirement, LOG-11, as follows: =20 LOG-11 [LOW] The CDNI Logging interface may provide "quality" metrics in = the logging of deliveries to User Agents performed by the Downstream = CDN. =20 9. >>With regards to cascaded CDNs, this could be very bad. I think = there=20 >>must be a control mechanism to indicate how many "cascades" are=20 >>involved in the CDNI and allow the Upstream CDN to cut it off at some=20 >>point. >>=20 =20 KL> I think this comment is not specific to CDNI Logging. You are = suggesting having a requirement to limit the number of cascaded CDNs = (GEN-9)? =20 This may be an implementation knob to limit levels of redirection. = Though it conflicts with GEN-9 on arbitruary levels. =20 Resolution: No action. =20 10. >>Also, should there be any mechanism to indicate whether = entitlements=20 >>are an issue to downstream CDNs from the CSP? >>=20 =20 KL> Not sure if entitlements have been discussed in the past. Others = can chime in. =20 Not clear if this is covered in the delegation blacklist in META-14 = requirement? =20 =20 Resolution: No action =20 =20 =20 Kent ------_=_NextPart_001_01CC8E96.EA6A30D5 Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi = folks.=A0 We’ve received a few comments from the WG on the base = requirements draft (-00).=A0 There are some open issues marked for = review.=A0 In the attempt to “clean up” and expedite = progress, here’s a list of proposed resolutions for the identified = open issues in draft and WG feedback.=A0 Since it may be easier to read = the requirements document in its entirety, the ver-01 will be published = with the changes.=A0 Of course, any further WG discussions and = conclusions will be captured in the subsequent version. = =A0

 

Please review and comment.=A0 We believe that the = draft is in stable condition.=A0 If anyone disagrees, please specify any = open issues that need to be addressed.=A0 Thanks.

 

-----

Open issue list in = draft ver-00:

 

1. Intro: OPEN = ISSUE: Should requirements in each section be ordered by = priority?

Resolution: = Requirements are logically grouped.=A0 No need to be ordered by priority = which may change during working group = discussions.

 

2. GEN-9: OPEN = ISSUE: arbitrary number should more than one = level?)

Resolution: Change = "to an arbitrary number of levels" to "to an arbitrary = number of levels beyond the first level"

 

3. GEN-13: OPEN = ISSUE: Virtualization is transparent to CDNI, remove requirement or = justify why uCDN/dCDN needs to be aware?)

Resolution: = Requirement removed.

 

4. GEN-14: OPEN = ISSUE: Add HTTP ABR requirements

Resolution: Update = requirement with "GEN-14: [HIGH] The CDNI solution shall support = HTTP Adaptive Bit Rate (ABR) content."

 

5. CNTL-4: OPEN = ISSUE: how much influence the Upstream CDN ought to have on = pre-positioning of the content on surrogates inside the Downstream CDN = is TBD

The surrogates in = the Downstream CDN are not required to be exposed to the Upstream = CDN.=A0

Resolution: Remove = OPEN ISSUE comment.

 

6. REQ-1: OPEN = ISSUE: Belong to Control Interface section?

Resolution: Change = "Control" to "Request-Routing" as the information = pertains to request routing function.

 

7. REQ-5/REQ-6: = OPEN ISSUE: Surrogate selection is out of scope?

Accuracy of the = Surrogate selection was described as an example.=A0 There is no = requirement for Surrogate selection.

Resolution: Remove = OPEN ISSUE comment.

 

8. REQ-9: OPEN = ISSUE: Why route looped request?

The loop prevention = mechanism should avoid request redirection loop.

Resolution: Add = "... by avoiding the loop ..." in the requirement as = clarification.

 

9. META-3: OPEN = ISSUE: Confirm high priority

Dynamic CDNI = metadata acquisition is required.

Resolution: Remove = OPEN ISSUE comment

 

10. META-4: OPEN = ISSUE: Confirm medium priority

Pre-positioned CDNI = metadata acquisition is considered medium = priority?

Resolution: Remove = OPEN ISSUE comment

 

11. META-14: OPEN = ISSUE: Expiration time needed?

Expiration time may = be included to remove content.

Resolution: Remove = OPEN ISSUE comment

 

10. LOG section: = Editor's note: should we add a requirement for support of aggregate/ = summarized logs

Resolution: Add the = following new requirement:

LOG-10 [LOW] The = CDNI Logging interface may support aggregate/ summarized logs (e.g. = total bytes delivered for a content regardless of individual User Agents = to which it was delivered).

 

11. CNTL-1: Added = "Only the object(s) and CDNI metadata that pertain to the = requesting Upstream CDN are allowed to be purged." to "Delete = an object" bullet.

 

 

-----

WG = feedback:

 

1. >>- Should = REQ-1 be under Section 4 rather than 5?

 

KL> This is = noted in the "OPEN ISSUE" statement.=A0 Unless there are = objections, this requirement should be moved to Section 4 CDNI Control = Interface.

 

Resolution: See #6 = above.

 

2. >>- I = think REQ-2 should be a MUST, and it should be written in the =

>>context = of=A9"The Upstream CDN MUST request aggregate information from =

>>the = Downstream CDN to facilitate=A9"=A0 If it's not a request, then it =

>>must go the = other way (the Downstream CDN MUST report to the Upstream =

>>CDN).

 

KL> This = requirement can be split into two.=A0 One for mandatory parameters for = base function of CDN selection (e.g. content types, footprint).=A0 The = other for optional parameters that can be useful (e.g. = metrics/attributes, affinities). The specific parameters should be left = for the solution draft to deal with.=A0 The "request" and = "report" are RRI pull and push, respectively.=A0 (See terms in = framework draft).=A0 In this requirement description, we've describe it = more generically.

 

After consulting = with other authors, the conclusion was that the essential parameters = used for request routing can be configured at the Upstream CDN.=A0 = Therefore, Request Routing Interface support for any of the parameters = is considered as optional.

 

Resolution: No = action.

 

3. >>- In = addition, I think REQ-2 should really be part of the control =

>>protocol.

>>This = information should be known prior to initiating a Route = Request.

>>- Under the = control protocol requirements, there is no requirement as =

>>to how = often this should occur.

 

KL> The need for = information to be known by uCDN prior to route request is only for the = iterative CDNI request routing case.=A0 RRI supports this with the push = model.

 

Resolution: No = action.

 

4. >>- Should = REQ-4 also be under Section 4 rather than 5?

 

KL> I think = there may still be some more debate on which functions belong to RRI vs. = Control Interface.=A0 If this requirement remains in the Control = Interface, it should be moved to Section 5 CDNI Control = Interface.

 

Resolution: Changed = "Control interface" to "Request-Routing = architecture" in requirement because the information pertains to = request routing function.

 

5. >>- GEN-11 = - With this requirement, it appears some other requirements =

>>are = redundant or unnecessary.

 

 

KL> For what = it's worth, this is a generic requirement for loop free information = exchange.=A0=A0 There may need to be explicit requirements within the = CDNI interface based on specific context.=A0 I think there's some value = in that.=A0 Open to disagreements and suggestions to delete requirements = or add new requirements.

 

Resolution: No = action.

 

6. >>- = Section 6 - Is this intended to be a protocol within the control =

>>protocol?=A0 To me it looks like it should.=A0 Another way = to ask it is,

>>can this be = included within the control protocol?

 

KL> Section 6 is = for CDNI Metadata Distribution Interface.=A0 The function is to = distribute CDNI metadata.=A0 So we can avoid coupling protocols or not = debate in the requirements draft.=A0 That should be left to the solution = draft.

 

Resolution: No = action

 

>>- R59 - = Should it also include "alternative content" sources, options, =

>>etc. in the = case of "blackouts"?

 

7. KL> The list = contains examples of content distribution control policies.=A0 It's open = to other examples that are commonly use or deemed valuable.=A0 I'm not = clear about alternative content sources.=A0 Maybe you can provide some = text to clarify?

 

Resolution: No = action

 

8. >>- = Section 7 - Should there be a "quality" metric or respond from = the

>>downstream = CDN on the delivered content to the End user?

>> 

 

KL> This could = be a new [MED] or [LOW] priority requirement.

 

Resolution: Add new = requirement, LOG-11, as follows:

 

LOG-11 [LOW] The = CDNI Logging interface may provide "quality" metrics in the = logging of deliveries to User Agents performed by the Downstream = CDN.

 

9. >>With = regards to cascaded CDNs, this could be very bad.=A0 I think there =

>>must be a = control mechanism to indicate how many "cascades" are =

>>involved in = the CDNI and allow the Upstream CDN to cut it off at some =

>>point.

>> 

 

KL> I think this = comment is not specific to CDNI Logging.=A0 You are suggesting having a = requirement to limit the number of cascaded CDNs = (GEN-9)?

 

This may be an = implementation knob to limit levels of redirection.=A0 Though it = conflicts with GEN-9 on arbitruary levels.

 

Resolution: No = action.

 

10. >>Also, = should there be any mechanism to indicate whether entitlements =

>>are an = issue to downstream CDNs from the CSP?

>> 

 

KL>=A0 Not sure = if entitlements have been discussed in the past.=A0 Others can chime = in.

 

Not clear if this = is covered in the delegation blacklist in META-14 requirement?=A0 =

 

Resolution: No = action

 

 

 

Kent

------_=_NextPart_001_01CC8E96.EA6A30D5-- From kevin.ma@azukisystems.com Wed Oct 19 22:53:57 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E88E11E80D7 for ; Wed, 19 Oct 2011 22:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9tHz3w4kRkE for ; Wed, 19 Oct 2011 22:53:55 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id B710211E80C2 for ; Wed, 19 Oct 2011 22:53:54 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 5CEA755474C; Thu, 20 Oct 2011 01:53:47 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB025.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 03799553A21; Thu, 20 Oct 2011 01:53:46 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB025.mail.lan ([10.110.17.25]) with mapi; Thu, 20 Oct 2011 01:53:45 -0400 From: Kevin J Ma To: Francois Le Faucheur Date: Thu, 20 Oct 2011 01:53:43 -0400 Thread-Topic: [CDNi] CDNI Metadata Interface Thread-Index: AcyOeCmM/aaZ6BCeReue7FxcOEZEugAbtgaQ Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6683047@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C651B50AF9D2@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C651B6682887@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C651B6683047MAILR002maill_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Metadata Interface X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 05:53:57 -0000 --_000_291CC3F9E50E7641901A54E85D0977C651B6683047MAILR002maill_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRnJhbmNvaXMsDQoNCiAgcmVzcG9uc2VzIGlubGluZToNCg0KPiBGcm9tOiBGcmFuY29pcyBM ZSBGYXVjaGV1ciBbbWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbV0NCj4gU2VudDogV2VkbmVzZGF5 LCBPY3RvYmVyIDE5LCAyMDExIDEyOjAyIFBNDQo+IFRvOiBLZXZpbiBKIE1hDQo+IENjOiBGcmFu Y29pcyBMZSBGYXVjaGV1cjsgY2RuaUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0NETmldIENE TkkgTWV0YWRhdGEgSW50ZXJmYWNlDQo+DQo+IEhpIGFnYWluLA0KPg0KPiBUaGFua3MgZm9yIHRo ZSByZXNwb25zZXMuIFNlZSBlbWJlZGRlZCBiZWxvdzoNCj4NCj4gT24gMTggT2N0IDIwMTEsIGF0 IDA3OjI2LCBLZXZpbiBKIE1hIHdyb3RlOg0KPg0KPg0KPiBIaSBGcmFuY29pcywNCj4NCj4gIGNv bW1lbnRzIGlubGluZToNCj4NCj4NCj4gRnJvbTogRnJhbmNvaXMgTGUgRmF1Y2hldXIgW21haWx0 bzpmbGVmYXVjaEBjaXNjby5jb21dDQo+IFNlbnQ6IE1vbmRheSwgT2N0b2JlciAxNywgMjAxMSAz OjQzIFBNDQo+IFRvOiBLZXZpbiBKIE1hDQo+IENjOiBGcmFuY29pcyBMZSBGYXVjaGV1cjsgY2Ru aUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0NETmldIENETkkgTWV0YWRhdGEgSW50ZXJmYWNl DQo+DQo+IEhlbGxvIEtldmluLA0KPg0KPiBbd2l0aCBJbmRpdmlkdWFsIGhhdCBvbl0NCj4NCj4g QSBmaXJzdCBzZXQgb2YgaGlnaCBsZXZlbCBxdWVzdGlvbnM6DQo+DQo+ICogZGlyZWN0aW9uYWxp dHkgb2YgbWV0YWRhdGEgY3JlYXRpb24vcmV0cmlldmFsL3JlbW92YWwvdXBkYXRlIG1lY2hhbmlz bToNCj4gQ291bGQgeW91IGNsYXJpZnkgd2hpY2ggb2YgdGhlIGFib3ZlIG9wZXJhdGlvbiB5b3Ug c2VlIHBvc3NpYmx5IGhhcHBlbmluZw0KPiBpbiB3aGljaCBkaXJlY3Rpb24/DQo+IEZvciBleGFt cGxlLCByZWdhcmRpbmcgdXBkYXRlL3JlbW92YWwsIGRvIHlvdSBzZWU6DQo+ICAgICAqYSkgIHRo ZSBQT1NUIHBvc3NpYmx5IGJlaW5nIGlzc3VlZCB0b3dhcmRzIHRoZSB1Q0ROIHRvDQo+IHVwZGF0 ZS9yZW1vdmUgc29tZSBtZXRhZGF0YSBpbiB0aGUgdUNETiByZXBvc2l0b3J5Pw0KPiAgICAgKmIp IHRoZSBQT1NUIHBvc3NpYmx5IGJlaW5nIGlzc3VlZCBieSB0aGUgdUNETiB0b3dhcmRzIHRoZSBk Q0ROIHRvDQo+IHVwZGF0ZS9yZW1vdmUgc29tZSBtZXRhZGF0YSBpbiB0aGUgZENETiByZXBvc2l0 b3J5IChhZnRlciBzb21lIG91dC1vZi1kYXRlDQo+IG1ldGFkYXRhIGhhZCBiZWVuIHJldHJpZXZl ZCBieSBkQ0ROIGZyb20gdUNETikuDQo+IEZvciBleGFtcGxlLCByZWdhcmRpbmcgcmV0cmlldmFs LCBjbGVhcmx5IHdlIHdhbnQgdGhlIGRDRE4gdG8gaXNzdWUgYSBHRVQNCj4gdG93YXJkcyB0aGUg dUNETiB0byBhY3F1aXJlIG1ldGFkYXRhLiBOb3cgZG8geW91IHNlZSB0aGF0IHRoZSBHRVQgY291 bGQNCj4gcG9zc2libHkgYmUgYWxzbyBpc3N1ZWQgYnkgdGhlIHVDRE4gdG8gY2hlY2sgbWV0YWRh dGEgc3RvcmVkIGJ5IHRoZSBkQ0ROPw0KPg0KPiBJIHRoaW5rIFBPU1RzIG1ha2UgdGhlIG1vc3Qg c2Vuc2UgZ29pbmcgZnJvbSB1cHN0cmVhbSB0byBkb3duc3RyZWFtLg0KPiBUaGUgYWdlbnQgd2Fz IGludGVuZGVkIHRvIG1vZGVyYXRlIHRoaXMsIHNpbmNlIGFueSBnaXZlbiBwYWlyIG9mIENETnMN Cj4gY291bGQgYmUgYm90aCBhIHVDRE4gYW5kIGEgZENETiBmb3IgZWFjaCBvdGhlciBpbiBkaWZm ZXJlbnQgZG9tYWlucy4NCj4NCj4gRG8gd2UgYWdyZWUgUE9TVCB3b3VsZCBub3JtYWxseSBiZSBk aXMtYWxsb3dlZCBpbiBkQ0ROLXVDRE4gZGlyZWN0aW9uDQo+IChyZWdhcmRsZXNzIG9mIHdoZXRo ZXIgdGhpcyBpcyAiZW5mb3JjZWQiIGJ5IHRoZSBBZ2VudCBvciBzb21ldGhpbmcgZWxzZSk/DQoN CkkgYWdyZWUgd2l0aCB0aGF0Lg0KDQo+IFJlZ2FyZGluZyB0aGUgdXNlIG9mIFBPU1QgZm9yIG1l dGFkYXRhIGNyZWF0aW9uLCBhcmUgeW91IHByb3Bvc2luZyBpdCBzbw0KPiBpdCBpcyB1c2VkIGJ5 IHRoZSB1Q0ROIHRvICJjcmVhdGUiIG1ldGFkYXRhIGluIHRoZSBkQ0ROIChpZSB0byBwcmUtDQo+ IHBvcHVsYXRlIG1ldGFkYXRhIGluIHRoZSBkQ0ROKSBvciBhcmUgeW91IHByb3Bvc2luZyBpdCBz byBpdCBpcyB1c2VkIGJ5DQo+IHNheSBhIENQIHRvICJjcmVhdGUiIHRoZSBtZXRhZGF0YSBpbiB0 aGUgdUNETiB0aGF0IHdpbGwgdGhlbiBiZSAicHVsbGVkIg0KPiBieSBkQ0ROPw0KPiAoZm9yIG1l dGFkYXRhIHByZS1wb3NpdGlvbmluZyBpbiBkQ0ROLCBJIGhhZCBiZWVuIHRoaW5raW5nIG1vcmUg b2YgYW4NCj4gYXBwcm9hY2ggd2hlcmUgdGhlIHVDRE4gd291bGQgaXNzdWUgYSB0cmlnZ2VyIGlu c3RydWN0aW5nIHRoZSBkQ0ROIHRvIEdFVA0KPiB0aGUgY29ycmVzcG9uZGluZyBtZXRhZGF0YSkN Cg0KUHJpbWFyaWx5LCBJIGFkZGVkIHRoZSBjcmVhdGUvbW9kaWZ5IEFQSXMgYmVjYXVzZSBpdCBz ZWVtcyBvZGQgdG8gaGF2ZQ0KYSByZXRyaWV2YWwgQVBJIHdpdGggbm8gd2F5IGZvciB0aGUgbWV0 YWRhdGEgdG8gaGF2ZSBiZWVuIHBvcHVsYXRlZA0KaW5pdGlhbGx5LiAgSXQgY291bGQgYmUgdXNl ZCBieSB0aGUgbG9jYWwgQ0ROIHRvIHBvcHVsYXRlIGl0cyBvd24NCmxvY2FsIG1ldGFkYXRhYmFz ZSwgYnkgQ1BzIHRvIHBvcHVsYXRlIHVDRE4gbWV0YWRhdGFiYXNlcywgb3IgYnkNCnVDRE5zIHRv IHBvcHVsYXRlIGRDRE4gbWV0YWRhdGFiYXNlcy4NCg0KPiBJIHNlZSBubyByZWFzb24gd2h5IEdF VHMgY291bGQgbm90IGdvIGluIGJvdGggZGlyZWN0aW9ucy4gIEkgY2FuIHNlZSBhDQo+IGNhc2Ug d2hlcmUgdXBzdHJlYW0gZW50aXRpZXMgd291bGQgd2FudCB0byB2ZXJpZnkgZG93bnN0cmVhbSBl bnRpdGllcy4NCj4NCj4gQWdyZWVkLg0KPg0KPiBJbiBhbnkgY2FzZSwgSSB3b3VsZCBzdWdnZXN0 IHRoYXQgeW91IGRpc2N1c3MvZG9jdW1lbnQgZGlyZWN0aW9uYWxpdHkgaW4NCj4gdXBjb21pbmcg dmVyc2lvbnMsIHBvc3NpYmx5IHRob3VnaCBzb21lIHRhYmxlIGNhcHR1cmluZyBhbGwgdGhlIHBv c3NpYmxlDQo+IGNhc2VzLg0KDQpDYW4gZG8uDQoNCj4gKiBpbiB5b3VyIENETkkgbWV0YWRhdGEg bW9kZWwsIGEgImRvbWFpbiIgaXMgZGlyZWN0bHkgYXNzb2NpYXRlZCB3aXRoIGENCj4gc2V0IG9m ICJob3N0bmFtZXMiLiBTbyB0aGlzIGFzc3VtZXMgdGhhdCB0aGUgc2FtZSBzZXQgb2YgdW5tb2Rp ZmllZA0KPiBob3N0bmFtZXMgaXMgdXNlZCB1bm1vZGlmaWVkIGV2ZXJ5d2hlcmUgaW4gYWxsIHRo ZSBwb3RlbnRpYWwgZENETnMuIFRoYXQNCj4gY2FuIGJlIHRoZSBjYXNlIGluIHNvbWUgZGVwbG95 bWVudCwgYnV0IHRoYXQgbWF5IG5vdCBhbHdheXMgYmUgdGhlIGNhc2UuDQo+IEZvciBleGFtcGxl LCB3aGVuIEhUVFAgcmVkaXJlY3Rpb24gaXMgdXNlZCBhY3Jvc3MgQ0ROcywgYW4gdXBzdHJlYW0g Q0RODQo+IG1heSB3YW50IHRvIG1vZGlmeSAocG9zc2libHkgaGlkZSkgdGhlIGFjdHVhbCBjb250 ZW50IHByb3ZpZGVyIGhvc3RuYW1lcw0KPiAoYW5kIHBvc3NpYmx5IHBhcnQgb2YgdGhlIFVSSSBw YXRoKSB3aGVuIHJlZGlyZWN0aW5nIHRvIGEgZENETiAoSSBiZWxpZXZlDQo+IHRoaXMgaXMgbWVu dGlvbmVkIGluIHRoZSBmcmFtZXdvcmspLg0KPg0KPiBJIHdhcyB0aGlua2luZyAodGhvdWdoIGl0 IGlzIG5vdCBub3RlZCBpbiB0aGUgZG9jdW1lbnQpIHRoYXQgaG9zdG5hbWUNCj4gbGlzdHMgY291 bGQgYmUgZGlmZmVyZW50IGluIGRpZmZlcmVudCBkQ0ROcy4gIFdoYXQgaXMgbm90IGVudGlyZWx5 DQo+IGNsZWFyIHRvIG1lIGlzIGhvdyBtZXRhZGF0YSB3b3VsZCBnZXQgc2V0IGFjcm9zcyBjYXNj YWRlZCBDRE5zLA0KPiBpLmUuLCBpZiB0aGUgQ1AgY29udHJhY3RzIENETi1BLCBhbmQgQ0ROLUEg bWFrZXMgYSBkZWFsIHdpdGggQ0ROLUIsDQo+IGFuZCBDRE4tQiBtYWtlcyBhIGRlYWwgd2l0aCBD RE4tQywgZG9lcyB0aGUgQ1Agb3IgQ0ROLUEga25vdyBhYm91dA0KPiBDRE4tQyBhbmQgaXMgdGhl IENQIG9yIENETi1BIHJlc3BvbnNpYmxlIGNvbmZpZ3VyaW5nIG1ldGFkYXRhIG9uDQo+IENETi1D PyAgT3IsIGlzIENETiBtZXRhZGF0YSBvbmx5IGNvbmZpZ3VyZWQgYnkgdGhlIG1vc3QgaW1tZWRp YXRlDQo+IHVDRE4gKG9yIHRoZSBDUCksIGkuZS4sIG9ubHkgQ0ROLUIgKG9yIHRoZSBDUCkgd2ls bCBrbm93IHRoZSB2YWx1ZXMgb2YNCj4gbWV0YWRhdGEgaW4gQ0ROLUM/DQo+DQo+IEluIG15IG9w aW5pb24sIGV2ZXJ5dGhpbmcgd291bGQgdHlwaWNhbGx5IG9wZXJhdGUgYXMgYSBjaGFpbiwgYmVj YXVzZSB0aGUNCj4gdHlwaWNhbCByZWxhdGlvbnNoaXBzIGJldHdlZW4gZW50aXRpZXMgd2lsbCBi ZSBhcyBhIGNoYWluOg0KPiBDUCBrbm93cyBDRE4tQSwgQ0ROLUEga25vd3MgQ0ROLUIsIENETi1C IGtub3dzIENETi1DLg0KPiBTbzoNCj4gICAgICogQ0ROLUEgd291bGQgYmUgcmVzcG9uc2libGUg Zm9yIGNyYWZ0aW5nIHRoZSBtZXRhZGF0YSB0aGF0IHdpbGwgYmUNCj4gcHVsbGVkIGJ5IENETi1C LiBDRE4tQSBtYXkgZWxlY3QgdG8gYWxsb3cgQ1AgdG8gZGlyZWN0bHkgcG9wdWxhdGUNCj4gKHNv bWUvYWxsKSB0aGVzZSBtZXRhZGF0YSAoc28gaXQgZG9lcyBjb3JyZWN0bHkgcmVmbGVjdCBpdHMg cG9saWN5KS4NCj4gICAgICogQ0ROLUIgd291bGQgdGhlbiBiZSByZXNwb25zaWJsZSBmb3IgY3Jh ZnRpbmcgdGhlIG1ldGFkYXRhIHRoYXQNCj4gd2lsbCBiZSBwdWxsZWQgYnkgQ0ROLUMuIENETi1C IG1heSBlbGVjdCB0byBhbGxvdyBDRE4tQSB0byBkaXJlY3RseQ0KPiBwb3B1bGF0ZSAoc29tZS9h bGwpIHRoZXNlIG1ldGFkYXRhIChzbyBpdCBkb2VzIGNvcnJlY3RseSByZWZsZWN0IGl0cw0KPiBw b2xpY3kpLg0KPiAgICAgKiBldGMuDQo+DQo+IEluIGFueSBjYXNlLCBkbyB5b3UgYWdyZWUgd2l0 aCB0aGUgaWRlYSBvZiBoYXZpbmcgdGhlIGhvc3RuYW1lL3Jlc291cmNlLQ0KPiBzZXRzIGJlIHRp ZWQgdG8gdGhlIEFnZW50IChzbyB0aGV5IGNhbiBiZSBkaWZmZXJlbnQgb24gYSBwZXIgQ0ROIGJh c2lzKT8NCg0KSSBhZ3JlZSB3aXRoIHRoaXMgYXMgd2VsbC4NCg0KPiBXb3VsZCB5b3UgY29uc2lk ZXIgbW9kaWZ5aW5nIHlvdXIgcHJvcG9zZWQgQ0ROSSBtb2RlbCB0byBhbGxvdyBmb3IgdGhlDQo+ IGZhY3QgdGhhdCBhIGRvbWFpbiBtYXkgYmUgInJlZmVyZW5jZWQiIGRpZmZlcmVudGx5IGJ5IHNv bWUgZENETnMgdGhhbiBieQ0KPiB0aGUgdUNETj8NCj4gSSB0aGluayBpdCBtZWFuczoNCj4gICAg ICogdGhlIGNvbmNlcHQgb2YgImhvc3RuYW1lcyIgc2hvdWxkIGJlIG1hZGUgbW9yZSBmbGV4aWJs ZSBzbyBpdA0KPiBtYXRjaGVzIG5vdCBqdXN0IG9uIGhvc3RuYW1lcyBidXQgb24gcGF0dGVybiBt YXRjaCBvdmVyIGhvc3RuYW1lL3BhdGguDQo+IExldCdzIGNhbGwgdGhpcyAicmVzb3VyY2Ugc2V0 cyIuDQo+ICAgICAqICJyZXNvdXJjZSBzZXRzIiBzaG91bGQgYmUgZGVwZW5kZW50IG9uICJBZ2Vu dHMiLiBTbyBwZXJoYXBzIGl0DQo+IHNob3VkbCBiZSBmb2xkZWQgaW5zaWRlIHlvdXIgIk1ldGFk YXRhIiBzbyBpdCBjYW4gYmUgZGVmaW5lZCBvbiBhIHBlcg0KPiAiZENETiIgYmFzaXMuDQo+IFdv dWxkIHRoYXQgd29yayBmb3IgeW91Pw0KPg0KPiBXb3VsZCB0aGUgZ29hbCBiZSB0byB1c2UgdGhl IGVudGlyZSBob3N0bmFtZS91cmkgYXMgYSBzaW5nbGUgY29tYmluZWQNCj4ga2V5PyAgSSBkbyBu b3QgaGF2ZSBhIHByb2JsZW0gd2l0aCBtZXJnaW5nIHRoZW0gaWYgd2UgdGhpbmsgdGhhdCBpdA0K PiB3b3VsZCBiZSB1c2VmdWwuDQo+DQo+IEkgZG8gdGhpbmsgaXQgaXMgdXNlZnVsIHRvIGFzc29j aWF0ZSB0byBhIGRvbWFpbiBzb21ldGhpbmcgdGhhdCBpcyBtb3JlDQo+IGZsZXhpYmxlIHRoYW4g aG9zdG5hbWUuIEZvciBleGFtcGxlLCBhIGhvc3RuYW1lK2JlZ2lubmluZy1vZi1wYXRoLg0KPiBJ biBzb21lIGNhc2VzLCBpdCB3aWxsIGp1c3QgYmUgaG9zdG5hbWVzLiBJbiBzb21lIGNhc2VzLCBp dCB3aWxsIGJlIGZpbmVyLQ0KPiBncmFpbg0KDQpVbmRlcnN0b29kLg0KDQp0aGFueC4NCg0KLS0g IEtldmluIEouIE1hDQoNCj4gVGhhbmtzDQo+DQo+IEZyYW5jb2lzDQo+DQo+DQo+DQo+ICogaW4g c2VjdGlvbiAzLjMuMywgeW91IGhhdmUgYSBjb3VwbGUgb2YgZXhhbXBsZXMgc2hvd2luZw0KPiAi L0NETkkvTUkvZG9tYWluIi4gU2hvdWxkIHRob3NlIG5vdCBzYXkgIi9DRE5JL01JL21ldGFkYXRh Ij8NCj4NCj4gWWVwLiAgVGhvc2UgYXJlIGN1dCBhbmQgcGFzdGUgZXJyb3JzLCBnb29kIGNhdGNo ISAgSSB3aWxsIGZpeCB0aG9zZS4NCj4NCj4gdGhhbnghDQo+DQo+IC0tICBLZXZpbiBKLiBNYQ0K Pg0KPg0KPiBDaGVlcnMNCj4NCj4gRnJhbmNvaXMNCj4NCj4NCj4NCj4NCj4gT24gNiBPY3QgMjAx MSwgYXQgMjI6MjEsIEtldmluIEogTWEgd3JvdGU6DQo+DQo+DQo+IEhpIGFsbCwNCj4NCj4gSnVz dCB1cGxvYWRlZCBhIG5ldyBJLUQgd2l0aCBhIHByb3Bvc2VkIG1ldGFkYXRhIG1vZGVsIGFuZCBB UEk6DQo+DQo+ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbWEt Y2RuaS1tZXRhZGF0YS0wMC50eHQNCj4NCj4gVGhlIG1vZGVsIHRha2VzIGEgcmF0aGVyIGdlbmVy aWMgYXBwcm9hY2ggdG8gbWV0YWRhdGEgcmVwcmVzZW50YXRpb24NCj4gdG8gc3VwcG9ydCBvcGFx dWUgbWV0YWRhdGEgYW5kIGFkZHJlc3NlcyBzb21lIG9mIHRoZSBzZWN1cml0eSBpc3N1ZXMNCj4g YXNzb2NpYXRlZCB3aXRoIG1ldGFkYXRhIHJldHJpZXZhbC4gIENvbW1lbnRzIHdlbGNvbWUuDQo+ DQo+IHRoYW54Lg0KPg0KPiAtLSAgS2V2aW4gSi4gTWENCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0ROaSBtYWlsaW5nIGxpc3QNCj4gQ0RO aUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkN Cj4NCj4NCj4NCj4NCj4NCj4NCj4NCj4gRnJhbmNvaXMgTGUgRmF1Y2hldXINCj4gRGlzdGluZ3Vp c2hlZCBFbmdpbmVlcg0KPiBDb3Jwb3JhdGUgRGV2ZWxvcG1lbnQNCj4gZmxlZmF1Y2hAY2lzY28u Y29tDQo+IFBob25lOiArMzMgNDkgNzIzIDI2MTkNCj4gTW9iaWxlOiArMzMgNiAxOSA5OCA1MCA5 MA0KPg0KPiBDaXNjbyBTeXN0ZW1zIEZyYW5jZQ0KPiBHcmVlbnNpZGUNCj4gNDAwIEF2ZSBkZSBS b3VtYW5pbGxlDQo+IDA2NDEwIFNvcGhpYSBBbnRpcG9saXMNCj4gRnJhbmNlDQo+IENpc2NvLmNv bQ0KPg0KPg0KPg0KPg0KPiAgVGhpbmsgYmVmb3JlIHlvdSBwcmludC4NCj4NCj4gVGhpcyBlbWFp bCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwgZm9yIHRo ZSBzb2xlDQo+IHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1c2Us IGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlDQo+IGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50DQo+IChvciBhdXRo b3JpemVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUg c2VuZGVyIGJ5DQo+IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1l c3NhZ2UuDQo+DQo+IENpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9uc2Fi aWl0w6kgbGltaXTDqWUsIFJ1ZSBDYW1pbGxlDQo+IERlc21vdWxpbnMg4oCTIEltbSBBdGxhbnRp cyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzDQo+IE1vdWxpbmVhdXgsIEF1 IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJlLCBEaXJlY3Rl dXIgZGUNCj4gbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUuDQo+DQo+IEZv ciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86DQo+IGh0dHA6Ly93d3cuY2lzY28u Y29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KPg0KDQoN Cg== --_000_291CC3F9E50E7641901A54E85D0977C651B6683047MAILR002maill_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxl LXRhYi1zcGFuO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBs ZS1zdHlsZS1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRp diBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPkhpIEZyYW5jb2lzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz7CoCByZXNwb25zZXMgaW5saW5lOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz4mZ3Q7IEZyb206IEZyYW5jb2lzIExlIEZhdWNoZXVyIFttYWls dG86ZmxlZmF1Y2hAY2lzY28uY29tXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyBTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTksIDIwMTEgMTI6MDIgUE08bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgVG86IEtldmluIEogTWE8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgQ2M6IEZyYW5jb2lz IExlIEZhdWNoZXVyOyBjZG5pQGlldGYub3JnPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IFN1YmplY3Q6IFJlOiBbQ0ROaV0gQ0ROSSBNZXRhZGF0YSBJbnRlcmZh Y2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IEhpIGFnYWluLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgVGhhbmtzIGZvciB0aGUgcmVzcG9uc2VzLiBTZWUgZW1i ZWRkZWQgYmVsb3c6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBPbiAxOCBPY3Qg MjAxMSwgYXQgMDc6MjYsIEtldmluIEogTWEgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsg SGkgRnJhbmNvaXMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0O8KgIGNvbW1lbnRz IGlubGluZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBGcm9tOiBGcmFuY29pcyBMZSBGYXVjaGV1 ciBbbWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgU2VudDogTW9uZGF5LCBPY3RvYmVyIDE3LCAyMDExIDM6NDMgUE08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgVG86IEtldmluIEog TWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgQ2M6IEZyYW5j b2lzIExlIEZhdWNoZXVyOyBjZG5pQGlldGYub3JnPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7IFN1YmplY3Q6IFJlOiBbQ0ROaV0gQ0ROSSBNZXRhZGF0YSBJbnRl cmZhY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IEhlbGxvIEtldmluLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgW3dpdGggSW5kaXZpZHVhbCBoYXQgb25dPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBBIGZpcnN0IHNldCBvZiBoaWdoIGxldmVs IHF1ZXN0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsg PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7ICogZGlyZWN0aW9u YWxpdHkgb2YgbWV0YWRhdGEgY3JlYXRpb24vcmV0cmlldmFsL3JlbW92YWwvdXBkYXRlIG1lY2hh bmlzbTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgQ291bGQg eW91IGNsYXJpZnkgd2hpY2ggb2YgdGhlIGFib3ZlIG9wZXJhdGlvbiB5b3Ugc2VlIHBvc3NpYmx5 IGhhcHBlbmluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBp biB3aGljaCBkaXJlY3Rpb24/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mZ3Q7IEZvciBleGFtcGxlLCByZWdhcmRpbmcgdXBkYXRlL3JlbW92YWwsIGRvIHlvdSBzZWU6 PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IMKgwqDCoCAqYSnC oCB0aGUgUE9TVCBwb3NzaWJseSBiZWluZyBpc3N1ZWQgdG93YXJkcyB0aGUgdUNETiB0bzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB1cGRhdGUvcmVtb3ZlIHNv bWUgbWV0YWRhdGEgaW4gdGhlIHVDRE4gcmVwb3NpdG9yeT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgwqDCoMKgICpiKSB0aGUgUE9TVCBwb3NzaWJseSBiZWlu ZyBpc3N1ZWQgYnkgdGhlIHVDRE4gdG93YXJkcyB0aGUgZENETiB0bzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB1cGRhdGUvcmVtb3ZlIHNvbWUgbWV0YWRhdGEg aW4gdGhlIGRDRE4gcmVwb3NpdG9yeSAoYWZ0ZXIgc29tZSBvdXQtb2YtZGF0ZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBtZXRhZGF0YSBoYWQgYmVlbiByZXRy aWV2ZWQgYnkgZENETiBmcm9tIHVDRE4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyBGb3IgZXhhbXBsZSwgcmVnYXJkaW5nIHJldHJpZXZhbCwgY2xlYXJseSB3 ZSB3YW50IHRoZSBkQ0ROIHRvIGlzc3VlIGEgR0VUPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7IHRvd2FyZHMgdGhlIHVDRE4gdG8gYWNxdWlyZSBtZXRhZGF0YS4g Tm93IGRvIHlvdSBzZWUgdGhhdCB0aGUgR0VUIGNvdWxkPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mZ3Q7IHBvc3NpYmx5IGJlIGFsc28gaXNzdWVkIGJ5IHRoZSB1Q0RO IHRvIGNoZWNrIG1ldGFkYXRhIHN0b3JlZCBieSB0aGUgZENETj88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IEkgdGhpbmsgUE9TVHMgbWFrZSB0aGUgbW9zdCBzZW5zZSBnb2luZyBm cm9tIHVwc3RyZWFtIHRvIGRvd25zdHJlYW0uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IFRoZSBhZ2VudCB3YXMgaW50ZW5kZWQgdG8gbW9kZXJhdGUgdGhpcywg c2luY2UgYW55IGdpdmVuIHBhaXIgb2YgQ0ROczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmd0OyBjb3VsZCBiZSBib3RoIGEgdUNETiBhbmQgYSBkQ0ROIGZvciBlYWNo IG90aGVyIGluIGRpZmZlcmVudCBkb21haW5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsgRG8gd2UgYWdyZWUgUE9TVCB3b3VsZCBub3JtYWxseSBiZSBkaXMtYWxsb3dlZCBpbiBk Q0ROLXVDRE4gZGlyZWN0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mZ3Q7IChyZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhpcyBpcyAmcXVvdDtlbmZvcmNlZCZxdW90 OyBieSB0aGUgQWdlbnQgb3Igc29tZXRoaW5nIGVsc2UpPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz5JIGFncmVlIHdpdGggdGhhdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jmd0OyBSZWdhcmRpbmcgdGhlIHVzZSBvZiBQT1NUIGZvciBtZXRhZGF0YSBjcmVhdGlvbiwgYXJl IHlvdSBwcm9wb3NpbmcgaXQgc288bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgaXQgaXMgdXNlZCBieSB0aGUgdUNETiB0byAmcXVvdDtjcmVhdGUmcXVvdDsgbWV0 YWRhdGEgaW4gdGhlIGRDRE4gKGllIHRvIHByZS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgcG9wdWxhdGUgbWV0YWRhdGEgaW4gdGhlIGRDRE4pIG9yIGFyZSB5 b3UgcHJvcG9zaW5nIGl0IHNvIGl0IGlzIHVzZWQgYnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyInPiZndDsgc2F5IGEgQ1AgdG8gJnF1b3Q7Y3JlYXRlJnF1b3Q7IHRoZSBt ZXRhZGF0YSBpbiB0aGUgdUNETiB0aGF0IHdpbGwgdGhlbiBiZSAmcXVvdDtwdWxsZWQmcXVvdDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgYnkgZENETj88bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgKGZvciBtZXRhZGF0YSBw cmUtcG9zaXRpb25pbmcgaW4gZENETiwgSSBoYWQgYmVlbiB0aGlua2luZyBtb3JlIG9mIGFuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IGFwcHJvYWNoIHdoZXJl IHRoZSB1Q0ROIHdvdWxkIGlzc3VlIGEgdHJpZ2dlciBpbnN0cnVjdGluZyB0aGUgZENETiB0byBH RVQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgdGhlIGNvcnJl c3BvbmRpbmcgbWV0YWRhdGEpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPlByaW1hcmls eSwgSSBhZGRlZCB0aGUgY3JlYXRlL21vZGlmeSBBUElzIGJlY2F1c2UgaXQgc2VlbXMgb2RkIHRv IGhhdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmEgcmV0cmlldmFs IEFQSSB3aXRoIG5vIHdheSBmb3IgdGhlIG1ldGFkYXRhIHRvIGhhdmUgYmVlbiBwb3B1bGF0ZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPmluaXRpYWxseS7CoCBJdCBj b3VsZCBiZSB1c2VkIGJ5IHRoZSBsb2NhbCBDRE4gdG8gcG9wdWxhdGUgaXRzIG93bjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+bG9jYWwgbWV0YWRhdGFiYXNlLCBieSBD UHMgdG8gcG9wdWxhdGUgdUNETiBtZXRhZGF0YWJhc2VzLCBvciBieTxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+dUNETnMgdG8gcG9wdWxhdGUgZENETiBtZXRhZGF0YWJh c2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IEkgc2VlIG5vIHJlYXNvbiB3 aHkgR0VUcyBjb3VsZCBub3QgZ28gaW4gYm90aCBkaXJlY3Rpb25zLsKgIEkgY2FuIHNlZSBhPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IGNhc2Ugd2hlcmUgdXBz dHJlYW0gZW50aXRpZXMgd291bGQgd2FudCB0byB2ZXJpZnkgZG93bnN0cmVhbSBlbnRpdGllcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IEFncmVlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7IEluIGFueSBjYXNlLCBJIHdvdWxkIHN1Z2dlc3QgdGhhdCB5b3Ug ZGlzY3Vzcy9kb2N1bWVudCBkaXJlY3Rpb25hbGl0eSBpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB1cGNvbWluZyB2ZXJzaW9ucywgcG9zc2libHkgdGhvdWdo IHNvbWUgdGFibGUgY2FwdHVyaW5nIGFsbCB0aGUgcG9zc2libGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgY2FzZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPkNhbiBkby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAqIGluIHlv dXIgQ0ROSSBtZXRhZGF0YSBtb2RlbCwgYSAmcXVvdDtkb21haW4mcXVvdDsgaXMgZGlyZWN0bHkg YXNzb2NpYXRlZCB3aXRoIGE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsgc2V0IG9mICZxdW90O2hvc3RuYW1lcyZxdW90Oy4gU28gdGhpcyBhc3N1bWVzIHRoYXQg dGhlIHNhbWUgc2V0IG9mIHVubW9kaWZpZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZndDsgaG9zdG5hbWVzIGlzIHVzZWQgdW5tb2RpZmllZCBldmVyeXdoZXJlIGlu IGFsbCB0aGUgcG90ZW50aWFsIGRDRE5zLiBUaGF0PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7IGNhbiBiZSB0aGUgY2FzZSBpbiBzb21lIGRlcGxveW1lbnQsIGJ1 dCB0aGF0IG1heSBub3QgYWx3YXlzIGJlIHRoZSBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBGb3IgZXhhbXBsZSwgd2hlbiBIVFRQIHJlZGlyZWN0aW9u IGlzIHVzZWQgYWNyb3NzIENETnMsIGFuIHVwc3RyZWFtIENETjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBtYXkgd2FudCB0byBtb2RpZnkgKHBvc3NpYmx5IGhp ZGUpIHRoZSBhY3R1YWwgY29udGVudCBwcm92aWRlciBob3N0bmFtZXM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgKGFuZCBwb3NzaWJseSBwYXJ0IG9mIHRoZSBV UkkgcGF0aCkgd2hlbiByZWRpcmVjdGluZyB0byBhIGRDRE4gKEkgYmVsaWV2ZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB0aGlzIGlzIG1lbnRpb25lZCBpbiB0 aGUgZnJhbWV3b3JrKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZn dDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IEkgd2FzIHRo aW5raW5nICh0aG91Z2ggaXQgaXMgbm90IG5vdGVkIGluIHRoZSBkb2N1bWVudCkgdGhhdCBob3N0 bmFtZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBsaXN0cyBj b3VsZCBiZSBkaWZmZXJlbnQgaW4gZGlmZmVyZW50IGRDRE5zLsKgIFdoYXQgaXMgbm90IGVudGly ZWx5PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IGNsZWFyIHRv IG1lIGlzIGhvdyBtZXRhZGF0YSB3b3VsZCBnZXQgc2V0IGFjcm9zcyBjYXNjYWRlZCBDRE5zLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBpLmUuLCBpZiB0aGUg Q1AgY29udHJhY3RzIENETi1BLCBhbmQgQ0ROLUEgbWFrZXMgYSBkZWFsIHdpdGggQ0ROLUIsPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IGFuZCBDRE4tQiBtYWtl cyBhIGRlYWwgd2l0aCBDRE4tQywgZG9lcyB0aGUgQ1Agb3IgQ0ROLUEga25vdyBhYm91dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBDRE4tQyBhbmQgaXMgdGhl IENQIG9yIENETi1BIHJlc3BvbnNpYmxlIGNvbmZpZ3VyaW5nIG1ldGFkYXRhIG9uPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IENETi1DP8KgIE9yLCBpcyBDRE4g bWV0YWRhdGEgb25seSBjb25maWd1cmVkIGJ5IHRoZSBtb3N0IGltbWVkaWF0ZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB1Q0ROIChvciB0aGUgQ1ApLCBpLmUu LCBvbmx5IENETi1CIChvciB0aGUgQ1ApIHdpbGwga25vdyB0aGUgdmFsdWVzIG9mPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IG1ldGFkYXRhIGluIENETi1DPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgSW4gbXkgb3BpbmlvbiwgZXZlcnl0aGlu ZyB3b3VsZCB0eXBpY2FsbHkgb3BlcmF0ZSBhcyBhIGNoYWluLCBiZWNhdXNlIHRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB0eXBpY2FsIHJlbGF0aW9uc2hp cHMgYmV0d2VlbiBlbnRpdGllcyB3aWxsIGJlIGFzIGEgY2hhaW46PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IENQIGtub3dzIENETi1BLCBDRE4tQSBrbm93cyBD RE4tQiwgQ0ROLUIga25vd3MgQ0ROLUMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mZ3Q7IFNvOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jmd0OyDCoMKgwqAgKiBDRE4tQSB3b3VsZCBiZSByZXNwb25zaWJsZSBmb3IgY3JhZnRpbmcgdGhl IG1ldGFkYXRhIHRoYXQgd2lsbCBiZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyBwdWxsZWQgYnkgQ0ROLUIuIENETi1BIG1heSBlbGVjdCB0byBhbGxvdyBDUCB0 byBkaXJlY3RseSBwb3B1bGF0ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jmd0OyAoc29tZS9hbGwpIHRoZXNlIG1ldGFkYXRhIChzbyBpdCBkb2VzIGNvcnJlY3RseSBy ZWZsZWN0IGl0cyBwb2xpY3kpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jmd0OyDCoMKgwqAgKiBDRE4tQiB3b3VsZCB0aGVuIGJlIHJlc3BvbnNpYmxlIGZvciBjcmFm dGluZyB0aGUgbWV0YWRhdGEgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyB3aWxsIGJlIHB1bGxlZCBieSBDRE4tQy4gQ0ROLUIgbWF5IGVsZWN0IHRvIGFs bG93IENETi1BIHRvIGRpcmVjdGx5PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mZ3Q7IHBvcHVsYXRlIChzb21lL2FsbCkgdGhlc2UgbWV0YWRhdGEgKHNvIGl0IGRvZXMg Y29ycmVjdGx5IHJlZmxlY3QgaXRzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mZ3Q7IHBvbGljeSkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mZ3Q7IMKgwqDCoCAqIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IElu IGFueSBjYXNlLCBkbyB5b3UgYWdyZWUgd2l0aCB0aGUgaWRlYSBvZiBoYXZpbmcgdGhlIGhvc3Ru YW1lL3Jlc291cmNlLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0 OyBzZXRzIGJlIHRpZWQgdG8gdGhlIEFnZW50IChzbyB0aGV5IGNhbiBiZSBkaWZmZXJlbnQgb24g YSBwZXIgQ0ROIGJhc2lzKT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+SSBhZ3JlZSB3 aXRoIHRoaXMgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBXb3Vs ZCB5b3UgY29uc2lkZXIgbW9kaWZ5aW5nIHlvdXIgcHJvcG9zZWQgQ0ROSSBtb2RlbCB0byBhbGxv dyBmb3IgdGhlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IGZh Y3QgdGhhdCBhIGRvbWFpbiBtYXkgYmUgJnF1b3Q7cmVmZXJlbmNlZCZxdW90OyBkaWZmZXJlbnRs eSBieSBzb21lIGRDRE5zIHRoYW4gYnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZndDsgdGhlIHVDRE4/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBO ZXciJz4mZ3Q7IEkgdGhpbmsgaXQgbWVhbnM6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IMKgwqDCoCAqIHRoZSBjb25jZXB0IG9mICZxdW90O2hvc3RuYW1lcyZx dW90OyBzaG91bGQgYmUgbWFkZSBtb3JlIGZsZXhpYmxlIHNvIGl0PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IG1hdGNoZXMgbm90IGp1c3Qgb24gaG9zdG5hbWVz IGJ1dCBvbiBwYXR0ZXJuIG1hdGNoIG92ZXIgaG9zdG5hbWUvcGF0aC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgTGV0J3MgY2FsbCB0aGlzICZxdW90O3Jlc291 cmNlIHNldHMmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4m Z3Q7IMKgwqDCoCAqICZxdW90O3Jlc291cmNlIHNldHMmcXVvdDsgc2hvdWxkIGJlIGRlcGVuZGVu dCBvbiAmcXVvdDtBZ2VudHMmcXVvdDsuIFNvIHBlcmhhcHMgaXQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgc2hvdWRsIGJlIGZvbGRlZCBpbnNpZGUgeW91ciAm cXVvdDtNZXRhZGF0YSZxdW90OyBzbyBpdCBjYW4gYmUgZGVmaW5lZCBvbiBhIHBlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAmcXVvdDtkQ0ROJnF1b3Q7IGJh c2lzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBXb3VsZCB0 aGF0IHdvcmsgZm9yIHlvdT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IFdvdWxk IHRoZSBnb2FsIGJlIHRvIHVzZSB0aGUgZW50aXJlIGhvc3RuYW1lL3VyaSBhcyBhIHNpbmdsZSBj b21iaW5lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBrZXk/ wqAgSSBkbyBub3QgaGF2ZSBhIHByb2JsZW0gd2l0aCBtZXJnaW5nIHRoZW0gaWYgd2UgdGhpbmsg dGhhdCBpdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyB3b3Vs ZCBiZSB1c2VmdWwuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7 IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBJIGRvIHRoaW5r IGl0IGlzIHVzZWZ1bCB0byBhc3NvY2lhdGUgdG8gYSBkb21haW4gc29tZXRoaW5nIHRoYXQgaXMg bW9yZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBmbGV4aWJs ZSB0aGFuIGhvc3RuYW1lLiBGb3IgZXhhbXBsZSwgYSBob3N0bmFtZStiZWdpbm5pbmctb2YtcGF0 aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgSW4gc29tZSBj YXNlcywgaXQgd2lsbCBqdXN0IGJlIGhvc3RuYW1lcy4gSW4gc29tZSBjYXNlcywgaXQgd2lsbCBi ZSBmaW5lci08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgZ3Jh aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+VW5kZXJzdG9vZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Iic+dGhhbnguPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPi0t wqAgS2V2aW4gSi4gTWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBUaGFua3M8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IEZyYW5jb2lzPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7ICog aW4gc2VjdGlvbiAzLjMuMywgeW91IGhhdmUgYSBjb3VwbGUgb2YgZXhhbXBsZXMgc2hvd2luZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyAmcXVvdDsvQ0ROSS9N SS9kb21haW4mcXVvdDsuIFNob3VsZCB0aG9zZSBub3Qgc2F5ICZxdW90Oy9DRE5JL01JL21ldGFk YXRhJnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgWWVwLsKgIFRob3Nl IGFyZSBjdXQgYW5kIHBhc3RlIGVycm9ycywgZ29vZCBjYXRjaCHCoCBJIHdpbGwgZml4IHRob3Nl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgdGhhbnghPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyAtLcKgIEtldmluIEouIE1hPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZn dDsgQ2hlZXJzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBGcmFuY29pczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi Q291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgT24g NiBPY3QgMjAxMSwgYXQgMjI6MjEsIEtldmluIEogTWEgd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsgSGkgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0 OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgSnVzdCB1cGxv YWRlZCBhIG5ldyBJLUQgd2l0aCBhIHByb3Bvc2VkIG1ldGFkYXRhIG1vZGVsIGFuZCBBUEk6PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0O8KgwqAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQtbWEtY2RuaS1tZXRhZGF0YS0wMC50eHQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mZ3Q7IFRoZSBtb2RlbCB0YWtlcyBhIHJhdGhlciBnZW5lcmljIGFw cHJvYWNoIHRvIG1ldGFkYXRhIHJlcHJlc2VudGF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mZ3Q7IHRvIHN1cHBvcnQgb3BhcXVlIG1ldGFkYXRhIGFuZCBhZGRy ZXNzZXMgc29tZSBvZiB0aGUgc2VjdXJpdHkgaXNzdWVzPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mZ3Q7IGFzc29jaWF0ZWQgd2l0aCBtZXRhZGF0YSByZXRyaWV2YWwu wqAgQ29tbWVudHMgd2VsY29tZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IHRo YW54LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgLS3CoCBLZXZpbiBKLiBNYTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZndDsgQ0ROaSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgQ0ROaUBpZXRmLm9yZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Nkbmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXci Jz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IEZyYW5jb2lzIExlIEZhdWNoZXVyPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IERpc3Rpbmd1aXNoZWQgRW5n aW5lZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgQ29ycG9y YXRlIERldmVsb3BtZW50PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4m Z3Q7IGZsZWZhdWNoQGNpc2NvLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Iic+Jmd0OyBQaG9uZTogKzMzIDQ5IDcyMyAyNjE5PG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiQ291cmllciBOZXciJz4mZ3Q7IE1vYmlsZTogKzMzIDYgMTkgOTggNTAgOTA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiQ291cmllciBOZXciJz4mZ3Q7IENpc2NvIFN5c3RlbXMgRnJhbmNlPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IEdyZWVuc2lkZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA0MDAgQXZlIGRlIFJvdW1hbmlsbGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgMDY0MTAgU29waGlhIEFu dGlwb2xpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBGcmFu Y2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgQ2lzY28uY29t PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmll ciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0 O8KgIFRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291 cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+ Jmd0OyBUaGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBt YXRlcmlhbCBmb3IgdGhlIHNvbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyInPiZndDsgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwg ZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyInPiZndDsgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyInPiZndDsgKG9yIGF1dGhvcml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lw aWVudCksIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPiZndDsgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVz IG9mIHRoaXMgbWVzc2FnZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIn PiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IENpc2Nv IFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9uc2FiaWl0w6kgbGltaXTDqWUsIFJ1 ZSBDYW1pbGxlPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IERl c21vdWxpbnMg4oCTIEltbSBBdGxhbnRpcyBaYWMgRm9ydW0gU2VpbmUgSWxvdCA3IDkyMTMwIElz c3kgbGVzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IE1vdWxp bmVhdXgsIEF1IGNhcGl0YWwgZGUgOTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJl LCBEaXJlY3RldXIgZGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZn dDsgbGEgcHVibGljYXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciJz4mZ3Q7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Iic+Jmd0OyBGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRv OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Jmd0OyBodHRwOi8vd3d3 LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPiZndDsgPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiQ291cmllciBOZXciJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Jv ZHk+PC9odG1sPg== --_000_291CC3F9E50E7641901A54E85D0977C651B6683047MAILR002maill_-- From sergem913@gmail.com Fri Oct 21 14:47:19 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6F8721F8A6C for ; Fri, 21 Oct 2011 14:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.371 X-Spam-Level: X-Spam-Status: No, score=-3.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJ1Er+16RdZT for ; Fri, 21 Oct 2011 14:47:18 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id E159021F8A67 for ; Fri, 21 Oct 2011 14:47:17 -0700 (PDT) Received: by bkas6 with SMTP id s6so6176787bka.31 for ; Fri, 21 Oct 2011 14:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=TcbTB1VpRsqeQc4QL2fv60bVnkQgeGQgIfKtiLwgJaU=; b=EyiGe3sC1BdXPOf0UM4ReeWs1c4Ca1ySZXVievNM0CDelc36UtOMmLaecOVtzemyrz R4n99vN4+vix1OYZkoNMddJK/6EGmfRpz4K1MiaKxTFPRb4xTtTNHiBKP6WgimC1buTh PnJIQwgHSno6OXShebivpHu/5gR9Jk6V2M9SY= MIME-Version: 1.0 Received: by 10.223.16.82 with SMTP id n18mr27040223faa.2.1319233632938; Fri, 21 Oct 2011 14:47:12 -0700 (PDT) Received: by 10.152.12.164 with HTTP; Fri, 21 Oct 2011 14:47:12 -0700 (PDT) Date: Fri, 21 Oct 2011 16:47:12 -0500 Message-ID: From: Serge Manning To: cdni@ietf.org Content-Type: multipart/alternative; boundary=00151747862e112c4c04afd604ba Subject: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 21:47:19 -0000 --00151747862e112c4c04afd604ba Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am resurrecting this old thread to let you know that a draft has finally been submitted. The authors have tried to analyze ATIS CSF's requirements and determine the additional requirements that are appropriate for CDNI. Our hope is that these additional reqs might be adopted into CDNI. Please take a look at the draft and provide your feedback. Thanks. Filename: draft-manning-cdni-additional-csf-reqs Revision: 00 Title: Additional Content Distribution Network Interconnection (CDNI) Requirements Based on ATIS CSF Creation date: 2011-10-21 WG ID: Individual Submission Number of pages: 9 ---------- Forwarded message ---------- From: Serge Manning Date: Fri, Jul 22, 2011 at 3:20 PM Subject: ATIS CDN Interconnect Reqs and IETF CDNI To: cdni@ietf.org I am a participant in the ATIS Cloud Services Forum (CSF) which has just published use cases and requirements on CDN Interconnect. ATIS CSF has overlaps with the goals of this WG but is coming with input from telecom operators' perspective. The reason for this email is that ATIS CSF will not be writing detailed technical specifications and so is hoping that this WG might be able to write standards to support *some* of the CSF requirements. ATIS CSF is also open to requirements feedback from this group in terms of technical limitations and suggestions. A few CSF members will be working to analyze and determine the unique requirements (relative to CDNI) that arise in CSF and submit them here in the near future (after Quebec). In the meantime, I encourage those interested to take a look at the CSF document. It is freely available for a time although it does require a painless registration. Go here a= nd register and then use the code "CSF711" for a free download. Thanks for you= r attention. Below I reproduce the ATIS press release to provide background info. --=20 --Serge =3D=3D=3D=3D=3D=3D=3D=3D *ATIS Cloud Services Forum Releases Content Distribution Network Interconnection Specifications * July 5, 2011 =97 Washington, DC =97 ATIS announced today that its Cloud Ser= vices Forum (CSF) has released the *CDN Interconnection Use Case Specification an= d High Level Requirements (ATIS-0200003) *standards document. The standard provides an initial description of content distribution networks (CDNs) and develops interconnection use cases and high-level requirements to support passing content distribution requests between two service providers. The standard enables CDN interconnection (CDN-I) by providing for common interfaces between providers=92 operations systems, back office interfaces, routing equipment, and network interconnections. The CSF=92s end-to-end process perspective is designed specifically to improve the efficiency and quality of service delivery to end users. Completed in only three months, this effort demonstrates ATIS=92 rapid response to evolving carrier needs a= nd delivers inter-carrier solutions essential to broad adoption of cloud services. =93The standard marks a major step forward in enabling seamless, global content delivery, especially for video, between service providers,=94 said ATIS President and CEO, Susan Miller. =93What sets the CSF=92s work apart = is its focus on business needs as the driver for better interconnection. This ATIS technical solution for inter-provider content delivery helps providers meet critical customer service imperatives=97namely, the need to improve end-user experience through cost effective video delivery.=94 This initial CSF standard is intended to serve as the basis for future efforts which will examine: 1) the delivery of more complex types of conten= t such as live streaming, video on demand, and peak-hour web interactions involving the use of authorization and authentication procedures; 2) the us= e of multicast delivery methods for some of these content types; and 3) interaction scenarios in a multi-provider content distribution environment involving a Federated Exchange. Until September 30, 2011, the new standard is available at no charge throug= h the ATIS Document Center by entering promotional code =93CSF711=94. The Doc= ument Center is the leading online resource to published and pre-published telecommunication standards, as well as technical reports, requirements and guidelines produced by ATIS-sponsored industry forums and committees. *About ATIS** *ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 200 companies actively formulate standards in ATIS=92 Committees, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Base= d and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Networks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Networked Car, IP Downloadable Security, Policy Management, and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications=92 Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Institute (ANSI). For more information, please visit www.atis.org . *About the Cloud Services Forum** *ATIS=92 Cloud Services Forum facilitates the adoption and advancement of cloud services from a network and IT perspective. Drawing upon business use cases that leverage cloud services=92 potential, the Forum addresses indust= ry priorities and develops implementable solutions for this evolving marketplace. CSF is working to ensure that cloud services =96 as offered by service providers =96 are quickly operationalized to facilitate the deliver= y of interoperable, secure, and managed services. Current priorities include content distribution network interconnection, cloud services framework, inter-carrier telepresence, virtual desktop, virtual private network, and development of a cloud services checklist for onboarding. ------------------------------ --=20 --Serge --00151747862e112c4c04afd604ba Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

I am resurrecting this old thread to let you know th= at a draft has finally been submitted. The authors have tried to analyze ATIS CS= F's requirements=A0and determine the additional requirements that are appropriate for CDNI. Our hope is that these additional reqs might be adopted into CDNI.=A0

=A0

Please take a look at the draft and provide your feedback. Thanks.

=A0

Filename: =A0 =A0 =A0 =A0draft-manning-cdni-additional-csf-re= qs
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Additional Content Distribution Network Interconnection (CDNI) Requirements Based on ATIS CSF
Creation date: =A0 2011-10-21
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9


--= -------- Forwarded message ----------
From: Serge Manning <sergem913@gmail.com>
Date: Fri, Jul 22, 2011 at 3:20 PM
Subject: ATIS CDN Interconnect Reqs a= nd IETF CDNI
To: cdni= @ietf.org


I am a participant in the ATIS Cloud Services Foru= m (CSF) which has just published use cases and requirements on CDN Intercon= nect.=A0ATIS CSF has overlaps with the goals of this WG but is coming with = input from telecom operators'=A0perspective.=A0

The reason for this email is that ATIS CSF will not be writi= ng detailed technical specifications and so is hoping that this WG might be= able to write standards to support *some* of the CSF requirements. ATIS CS= F is also open to requirements feedback from this group in terms of technic= al limitations and suggestions.=A0

A few CSF members will be working to analyze and determ= ine the unique requirements (relative to CDNI) that arise in CSF and submit= them here in the near future (after Quebec).

In the meantime, I encourage those interested to take a look at the CSF doc= ument. It is freely available for a time although it does require a painles= s registration. Go here and register and then use the code "CSF711&qu= ot; for a free download. Thanks for your attention.=A0

Below I reproduce the ATIS press release to provide bac= kground info.

--=A0
--Serge
=3D=3D=3D=3D=3D=3D=3D=3D

ATIS Cloud Services Forum Releases Content Distribution Network Interconnection Specifications=A0

=A0

July 5, 2011 =97 Washington, DC =97 ATIS announced today that its Cloud Services Forum (CS= F) has released the CDN Interconnection Use Case Specification and High Level Requirements (ATIS-0200003) standards document. =A0The standard provides an initial description of content distribution networks (CDNs) a= nd develops interconnection use cases and high-level requirements to support passing content distribution requests between two service providers.

The standard enables CDN interconnection (CDN-I) by providing for common interfaces between provid= ers=92 operations systems, back office interfaces, routing equipment, and networ= k interconnections. =A0The CSF=92s end-to-end process perspective is design= ed specifically to improve the efficiency and quality of service delivery to= end users. Completed in only three months, this effort demonstrates ATIS=92 r= apid response to evolving carrier needs and delivers inter-carrier solutions essential to broad adoption of cloud services.

=93The standard marks a major step forward in enabling seamless, global content delivery, especia= lly for video, between service providers,=94 said ATIS President and CEO, Sus= an Miller. =A0=93What sets the CSF=92s work apart is its focus on business n= eeds as the driver for better interconnection. This ATIS technical solution fo= r inter-provider content delivery helps providers meet critical customer service imperatives=97namely, the need to improve end-user experience thr= ough cost effective video delivery.=94

This initial CSF standard is intended to serve as the basis for future efforts which will examine: = 1) the delivery of more complex types of content such as live streaming, vid= eo on demand, and peak-hour web interactions involving the use of authorizat= ion and authentication procedures; 2) the use of multicast delivery methods f= or some of these content types; and 3) interaction scenarios in a multi-prov= ider content distribution environment involving a Federated Exchange.

Until September 30, 2011, t= he new standard is available at no charge through the ATIS Document Center by entering promotional code =93CSF711= =94. The Document Center is the leading online resource to published and pre-publi= shed telecommunication standards, as well as technical reports, requirements a= nd guidelines produced by ATIS-sponsored industry forums and committees.

About ATIS
ATIS is the leading technical planning and standards development organization committ= ed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 200 companies actively formulate standards in ATIS=92 Committees, covering is= sues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emerge= ncy Services, Architectural Platforms and Emerging Networks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving indust= ry priorities including Smart Grid, Machine-to-Machine, Networked Car, IP Downloadable Security, Policy Management, and Network Optimization.

ATIS is the North American Organizational Partner for the 3rd Generation Partnership Projec= t (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications=92 Sectors, an= d a member of the Inter-American Telecommunication Commission (CITEL). ATIS i= s accredited by the American National Standards Institute (ANSI). For more information, please visit www.at= is.org.

About the Cloud Services Forum=
ATIS=92 Cloud Services Forum facilitates the adoption and advancement of cloud services from a network and IT perspective. Drawing upon business use cases that leverage cloud services=92 potential, the Forum addresses industry priori= ties and develops implementable solutions for this evolving marketplace. CSF i= s working to ensure that cloud services =96 as offered by service providers= =96 are quickly operationalized to facilitate the delivery of interoperable, secu= re, and managed services. Current priorities include content distribution net= work interconnection, cloud services framework, inter-carrier telepresence, virtual desktop, virtual private network, and development of a cloud serv= ices checklist for onboarding.=A0

=A0



--
--Serge

--00151747862e112c4c04afd604ba-- From flefauch@cisco.com Fri Oct 21 19:28:04 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A8A1F0C3F for ; Fri, 21 Oct 2011 19:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.34 X-Spam-Level: X-Spam-Status: No, score=-5.34 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vg2b1fm9eoLZ for ; Fri, 21 Oct 2011 19:28:02 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0201F0C34 for ; Fri, 21 Oct 2011 19:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=40105; q=dns/txt; s=iport; t=1319250482; x=1320460082; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=mDqUC1LAnr1gNIcAmFJKFZk+86SDmZeVt7Q7ZEvX5DQ=; b=RpDdMwD9XarJ6dKCcf/F+Yin4obv3lWE5Vx0q/+DxmXt2LxvqC1cjZ0k c+P56GGZaRUgLzcU53htjn/hOdwPsABw6OXdTIJmq80+iaT3iDNhsuOYo 0zcJ88GUK0ugSfnaTtlPSiTVlBm3SMMCvrlSGRAoZE3c8O61DIxMLqJeh Q=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,390,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="9530075" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 22 Oct 2011 02:28:02 +0000 Received: from [10.21.74.40] ([10.21.74.40]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p9M2S1bv005596; Sat, 22 Oct 2011 02:28:01 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-69--506509193 From: Francois Le Faucheur In-Reply-To: Date: Fri, 21 Oct 2011 19:29:50 -0700 Message-Id: References: To: Serge Manning X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 02:28:04 -0000 --Apple-Mail-69--506509193 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Serge, Thanks for bringing the ATIS CSF requirements into our group as we had = agreed. Those seem to me generally in the right direction. Of course, they'll = have to be reviewed and prioritized by the group. Cheers Francois On 21 Oct 2011, at 14:47, Serge Manning wrote: > I am resurrecting this old thread to let you know that a draft has = finally been submitted. The authors have tried to analyze ATIS CSF's = requirements and determine the additional requirements that are = appropriate for CDNI. Our hope is that these additional reqs might be = adopted into CDNI.=20 >=20 > =20 > Please take a look at the draft and provide your feedback. Thanks. >=20 > =20 > Filename: draft-manning-cdni-additional-csf-reqs > Revision: 00 > Title: Additional Content Distribution Network = Interconnection (CDNI) Requirements Based on ATIS CSF > Creation date: 2011-10-21 > WG ID: Individual Submission > Number of pages: 9 >=20 >=20 > ---------- Forwarded message ---------- > From: Serge Manning > Date: Fri, Jul 22, 2011 at 3:20 PM > Subject: ATIS CDN Interconnect Reqs and IETF CDNI > To: cdni@ietf.org >=20 >=20 > I am a participant in the ATIS Cloud Services Forum (CSF) which has = just published use cases and requirements on CDN Interconnect. ATIS CSF = has overlaps with the goals of this WG but is coming with input from = telecom operators' perspective.=20 >=20 > The reason for this email is that ATIS CSF will not be writing = detailed technical specifications and so is hoping that this WG might be = able to write standards to support *some* of the CSF requirements. ATIS = CSF is also open to requirements feedback from this group in terms of = technical limitations and suggestions.=20 >=20 > A few CSF members will be working to analyze and determine the unique = requirements (relative to CDNI) that arise in CSF and submit them here = in the near future (after Quebec). >=20 > In the meantime, I encourage those interested to take a look at the = CSF document. It is freely available for a time although it does require = a painless registration. Go here and register and then use the code = "CSF711" for a free download. Thanks for your attention.=20 >=20 > Below I reproduce the ATIS press release to provide background info. >=20 > --=20 > --Serge >=20 > =3D=3D=3D=3D=3D=3D=3D=3D >=20 > ATIS Cloud Services Forum Releases Content Distribution Network = Interconnection Specifications=20 >=20 > =20 > July 5, 2011 =97 Washington, DC =97 ATIS announced today that its = Cloud Services Forum (CSF) has released the CDN Interconnection Use Case = Specification and High Level Requirements (ATIS-0200003) standards = document. The standard provides an initial description of content = distribution networks (CDNs) and develops interconnection use cases and = high-level requirements to support passing content distribution requests = between two service providers. >=20 > The standard enables CDN interconnection (CDN-I) by providing for = common interfaces between providers=92 operations systems, back office = interfaces, routing equipment, and network interconnections. The CSF=92s = end-to-end process perspective is designed specifically to improve the = efficiency and quality of service delivery to end users. Completed in = only three months, this effort demonstrates ATIS=92 rapid response to = evolving carrier needs and delivers inter-carrier solutions essential to = broad adoption of cloud services. >=20 > =93The standard marks a major step forward in enabling seamless, = global content delivery, especially for video, between service = providers,=94 said ATIS President and CEO, Susan Miller. =93What sets = the CSF=92s work apart is its focus on business needs as the driver for = better interconnection. This ATIS technical solution for inter-provider = content delivery helps providers meet critical customer service = imperatives=97namely, the need to improve end-user experience through = cost effective video delivery.=94 >=20 > This initial CSF standard is intended to serve as the basis for future = efforts which will examine: 1) the delivery of more complex types of = content such as live streaming, video on demand, and peak-hour web = interactions involving the use of authorization and authentication = procedures; 2) the use of multicast delivery methods for some of these = content types; and 3) interaction scenarios in a multi-provider content = distribution environment involving a Federated Exchange. >=20 > Until September 30, 2011, the new standard is available at no charge = through the ATIS Document Center by entering promotional code =93CSF711=94= . The Document Center is the leading online resource to published and = pre-published telecommunication standards, as well as technical reports, = requirements and guidelines produced by ATIS-sponsored industry forums = and committees. >=20 > About ATIS > ATIS is the leading technical planning and standards development = organization committed to the rapid development of global, market-driven = standards for the information, entertainment and communications = industry. More than 200 companies actively formulate standards in ATIS=92 = Committees, covering issues including: IPTV, Cloud Services, Energy = Efficiency, IP-Based and Wireless Technologies, Quality of Service, = Billing and Operational Support, Emergency Services, Architectural = Platforms and Emerging Networks. In addition, numerous Incubators, Focus = and Exploratory Groups address evolving industry priorities including = Smart Grid, Machine-to-Machine, Networked Car, IP Downloadable Security, = Policy Management, and Network Optimization. >=20 > ATIS is the North American Organizational Partner for the 3rd = Generation Partnership Project (3GPP), a member and major U.S. = contributor to the International Telecommunication Union (ITU) Radio and = Telecommunications=92 Sectors, and a member of the Inter-American = Telecommunication Commission (CITEL). ATIS is accredited by the American = National Standards Institute (ANSI). For more information, please visit = www.atis.org. >=20 > About the Cloud Services Forum > ATIS=92 Cloud Services Forum facilitates the adoption and advancement = of cloud services from a network and IT perspective. Drawing upon = business use cases that leverage cloud services=92 potential, the Forum = addresses industry priorities and develops implementable solutions for = this evolving marketplace. CSF is working to ensure that cloud services = =96 as offered by service providers =96 are quickly operationalized to = facilitate the delivery of interoperable, secure, and managed services. = Current priorities include content distribution network interconnection, = cloud services framework, inter-carrier telepresence, virtual desktop, = virtual private network, and development of a cloud services checklist = for onboarding.=20 >=20 > =20 >=20 >=20 >=20 > --=20 > --Serge >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-69--506509193 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-70--506509193 --Apple-Mail-70--506509193 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hello = Serge,

Thanks for bringing the ATIS CSF requirements = into our group as we had agreed.
Those seem to me generally in = the right direction. Of course, they'll have to be reviewed and = prioritized by the = group.

Cheers

Francois

On 21 Oct 2011, at 14:47, Serge Manning = wrote:

I am resurrecting this old thread = to let you know that a draft has finally been submitted. The authors have tried to analyze ATIS = CSF's requirements and determine the additional requirements that are appropriate for CDNI. Our hope is that these additional reqs might be adopted into CDNI. 

 

Please = take a look at the draft and provide your feedback. Thanks.

 

Filename:        draft-manning-cdni-additional-csf-reqs=
Revision:        00
Title:           Additional Content Distribution Network Interconnection (CDNI) = Requirements Based on ATIS CSF
Creation date:   2011-10-21
WG ID:           Individual Submission
Number of pages: 9


---------- Forwarded message ----------
From: = Serge Manning <sergem913@gmail.com>
Date: Fri, Jul 22, 2011 at 3:20 PM
Subject: ATIS CDN Interconnect = Reqs and IETF CDNI
To: cdni@ietf.org


I am a participant in the = ATIS Cloud Services Forum (CSF) which has just published use cases and = requirements on CDN Interconnect. ATIS CSF has overlaps with the = goals of this WG but is coming with input from telecom = operators' perspective. 

The reason for this email is that ATIS CSF will not be = writing detailed technical specifications and so is hoping that this WG = might be able to write standards to support *some* of the CSF = requirements. ATIS CSF is also open to requirements feedback from this = group in terms of technical limitations and suggestions. 

A few CSF members will be working to analyze and = determine the unique requirements (relative to CDNI) that arise in CSF = and submit them here in the near future (after = Quebec).

In the meantime, I encourage those interested to take a look at the CSF = document. It is freely available for a time although it does require a = painless registration. Go here = and register and then use the code "CSF711" for a free download. = Thanks for your attention. 

Below I reproduce the ATIS press release to provide = background = info.

-- 
--Serge

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

ATIS Cloud Services Forum Releases Content Distribution Network Interconnection Specifications 
 

July 5, 2011 =97 Washington, DC =97 ATIS announced today that its Cloud Services Forum = (CSF) has released the CDN Interconnection Use Case Specification and High = Level Requirements (ATIS-0200003) standards document.  The standard provides an initial description of content distribution networks = (CDNs) and develops interconnection use cases and high-level requirements to = support passing content distribution requests between two service = providers.

The standard enables CDN interconnection (CDN-I) by providing for common interfaces between = providers=92 operations systems, back office interfaces, routing equipment, and = network interconnections.  The CSF=92s end-to-end process perspective is = designed specifically to improve the efficiency and quality of service delivery = to end users. Completed in only three months, this effort demonstrates ATIS=92 = rapid response to evolving carrier needs and delivers inter-carrier = solutions essential to broad adoption of cloud services.

=93The standard marks = a major step forward in enabling seamless, global content delivery, = especially for video, between service providers,=94 said ATIS President and CEO, = Susan Miller.  =93What sets the CSF=92s work apart is its focus on = business needs as the driver for better interconnection. This ATIS technical solution = for inter-provider content delivery helps providers meet critical customer service imperatives=97namely, the need to improve end-user experience = through cost effective video delivery.=94

This initial CSF = standard is intended to serve as the basis for future efforts which will = examine: 1) the delivery of more complex types of content such as live streaming, = video on demand, and peak-hour web interactions involving the use of = authorization and authentication procedures; 2) the use of multicast delivery = methods for some of these content types; and 3) interaction scenarios in a = multi-provider content distribution environment involving a Federated = Exchange.

Until September 30, 2011, the new standard is available at no = charge through the ATIS Document Center by entering promotional code = =93CSF711=94. The Document Center is the leading online resource to published and = pre-published telecommunication standards, as well as technical reports, = requirements and guidelines produced by ATIS-sponsored industry forums and = committees.

About ATIS
ATIS is the leading technical planning and standards development organization = committed to the rapid development of global, market-driven standards for the information, entertainment and communications industry. More than 200 companies actively formulate standards in ATIS=92 Committees, covering = issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and = Wireless Technologies, Quality of Service, Billing and Operational Support, = Emergency Services, Architectural Platforms and Emerging Networks. In addition, numerous Incubators, Focus and Exploratory Groups address evolving = industry priorities including Smart Grid, Machine-to-Machine, Networked Car, IP Downloadable Security, Policy Management, and Network = Optimization.

ATIS is the North American Organizational Partner for the 3rd Generation Partnership = Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications=92 Sectors, = and a member of the Inter-American Telecommunication Commission (CITEL). = ATIS is accredited by the American National Standards Institute (ANSI). For = more information, please visit www.atis.org.

About the Cloud Services Forum
ATIS=92 Cloud Services Forum facilitates the adoption and advancement of cloud = services from a network and IT perspective. Drawing upon business use cases = that leverage cloud services=92 potential, the Forum addresses industry = priorities and develops implementable solutions for this evolving marketplace. = CSF is working to ensure that cloud services =96 as offered by service = providers =96 are quickly operationalized to facilitate the delivery of interoperable, = secure, and managed services. Current priorities include content distribution = network interconnection, cloud services framework, inter-carrier telepresence, virtual desktop, virtual private network, and development of a cloud = services checklist for onboarding. 

 



--
--Serge

_______________________________________________
CDNi mailing = list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni



Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-70--506509193 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-70--506509193-- --Apple-Mail-69--506509193-- From ben@niven-jenkins.co.uk Mon Oct 24 05:44:34 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263DD21F8D55 for ; Mon, 24 Oct 2011 05:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.461 X-Spam-Level: X-Spam-Status: No, score=-103.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfrX0y+qchD5 for ; Mon, 24 Oct 2011 05:44:32 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3A12621F8D51 for ; Mon, 24 Oct 2011 05:44:29 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RIJtB-0004UB-Am; Mon, 24 Oct 2011 13:44:26 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B6682920@MAILR002.mail.lan> Date: Mon, 24 Oct 2011 13:44:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <943A317A-AE56-464A-8CDB-A806332368BC@niven-jenkins.co.uk> References: <842E1148-9AFD-4A39-BBB3-89CAAB9E833A@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B668260C@MAILR002.mail.lan> <30D279D6-3F64-4E1F-A221-D293EE0261D7@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B6682920@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Some questions regarding draft-ma-cdni-metadata X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 12:44:34 -0000 Kevin, On 18 Oct 2011, at 17:03, Kevin J Ma wrote: >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> On 17 Oct 2011, at 19:26, Kevin J Ma wrote: >>> I attempted to create an extensible representation for metadata and = a >>> complete protocol for manipulating metadata, though, not all users = of >>> the interface will need all aspects. Do you feel that the protocol = is >>> deficient for non-authoritative CDN use, or that authoritative CDNs = do >>> not need the metadata interface? >>=20 >> I think that we should stick to the scope of work we have been = chartered >> to address, in the case of CDNI Metadata that is an interface that = "will >> allow the CDNs to exchange content distribution metadata of inter-CDN >> scope". >>=20 >> If the interface we specify is also usable in other scenarios then = that's >> great but I don't think we should be actively looking to design an >> interface that is usable across a multitude of scenarios that are not = in >> scope of CDNI because it's a distraction and likely to defocus our >> efforts. Our charter is not to define a new CP->CDN provisioning = interface >> (they already exist) so we shouldn't be burning cycles working on = things >> that are out of charter. >=20 > I personally do not see a difference between uCDN->dCDN and CP->uCDN. > If in supporting uCDN->dCDN you get CP->uCDN, I think that is a bonus. > I do not think we should ignore uCDN->dCDN just because it might be > useful to CPs. Is the argument that a uCDN should never need to push > metadata to a dCDN and therefore we do not need uCDN->dCDN support? My argument is that CP->uCDN and uCDN->dCDN are different beasts and in = supporting uCDN->dCDN you do not get a sufficient interface for = CP->uCDN. We thought about this when writing draft-jenkins-cdni-metadata and we = came to the conclusion that CP->uCDN is a provisioning interface whereas = for CDNI no provisioning is required, the dCDN only needs how to execute = the already-provisioned (in the uCDN) CDNI metadata. A multi-tenanted CP->uCDN provisioning interface requires a different = feature set and a richer data model than a uCDN->dCDN interface that = just needs to transfer already-provisioned CDNI metadata for a dCDN to = execute it. For example, a multi-tentanted CP->uCDN provisioning interface needs to = support features such as: - User & Role based access control and a user account hierarchy that = allows different business entities to control different levels of that = hierarchy. - Metadata access permissions as different users (at different levels in = the account hierarchy) may not have read or read/write access to all = types of metadata record and because users at different levels in the = account hierarchy have the requirement to add additional metadata = properties/policies (e.g. a Reseller may want to always have their = off-shore QA team added to any Delivery ACL to enable them to = troubleshoot). - Service/Account templates to simply provisioning. etc. When it comes to executing the CDN metadata (i.e. what a surrogate needs = to know to perform the actual content delivery) none of the above = features really matter, the CDN metadata can be flattened into a simpler = CDNI metadata data model that removes some of the complexities required = in a multi-tenanted provisioning data model as knowledge of how the CDNI = Metadata got into the system (and who is allowed to do what at which = level of the account hierarchy) is not needed when all the Surrogate = cares about is if and how it should delivery the actual content. So your assertion that a uCDN->dCDN interface automatically gives you a = sufficient CP->uCDN interface does not IMO hold true.=20 It doesn't matter whether the CDNI Metadata interface is push from uCDN = to dCDN or pull from dCDN to uCDN, what is required to build a = sufficient CP-uCDN provisioning interface is much more than what is = required purely for a sufficient CDNI Metadata interface. My opinion is = we should concentrate on what we're chartered to do (which is a CDNI = Metadata interface) and not try and expand that scope to be much wider = than it is currently. >>> My concern with defining all the semantics of metadata and designing = a >>> protocol around that, is you typically end up with a less extensible >>> design. I would not want to have to update the metadata interface = rfc >>> just to support a new piece of metadata in the future. I am not = saying >>> that we should not define metadata, I just think it should be = separate >>> from the data model and the protocol, so I concentrated on those = first. >>> I definitely feel that we should define a base set of metadata that = all >>> CDNs should support. I do not think the draft prevents that. >>=20 >> We agree on the fact that the CDNI metadata protocol specification = doesn't >> need to define all possible properties/semantics for all possible = delivery >> protocols and that properties and semantics for different delivery >> protocols can be defined in separate documents. >>=20 >> The CDNI metadata draft that Grant/David/I authored doesn't preclude >> semantics/properties being defined in other documents (and implies = that is >> likely to be the case - see my response to Spencer just now). The = base set >> of properties that are described in our draft could easily be broken = out >> into a separate document if the consensus of the group is to do so. = We >> included the base properties and interface specification in a single >> document so that readers could see how the interface could be = constructed >> and applied using a set of common base semantics/properties for HTTP >> delivery supported by deployed CDNs today. >>=20 >> So if we put aside the question of where to define the actual = properties >> and their semantics we're left with the data model and = interface/protocol >> itself. So let's compare and contrast some key aspects of flexibility >> between the different proposals. >>=20 >> Cache-ability & Latency: >> With the CDNI Metadata model we've proposed we think we've managed to >> define a data model that is as simple as possible but no simpler. It = has a >> minimum number of data objects to allow objects that are likely to to = be >> large or reused to be broken out into separate resources to provide >> efficiency and at the same time objects that may well have different >> cache-ability lifetimes can be broken out into separate resources. = The >> interface specification allows inlining so that all related objects = for a >> Site can be included in a single request/response so we provide the >> ability to have a simple implementation but also the flexibility to >> optimise the implementation to balance object size and cache-ability >> against number of requests/re-validations required. >=20 > The protocol in my draft also supports bulk retrieval, but if there is > a nuance of inlining that is missing, I could certainly look at it. > Though I did not address cacheability, I think it could be applied at > the bulk response level as you describe? My point was not that your proposal couldn't do bulk retrieval but that = by having a data model that is "too simple" rather than having achieving = your aim of a "more extensible" model/interface you actually have a = model/interface that is less flexible and less extensible than ours. Your model essentially ignores the reality that there are different = types of CDNI Metadata which are likely to have different "lifetimes" = (TTLs), different levels of reusability across CDN services & CPs and = will contain varying amounts of data. To give just one example: Think about the situation I mentioned earlier = of a Reseller (or CDN provider) wanting to add their off-shore QA team = to all Delivery ACLs to enable them to perform QA/troubleshooting/etc. = Your model provides no ability (that I can see) to avoid having to list = all the QA IP addresses against every every Metadata record (which are = defined per URI) in every Domain that will be interconnected. That's a = hell of a lot of unnecessary duplication. >> By keeping your model basically flat you force an implementation to >> repeatedly have to transfer data that is common across a number of >> Hostnames/Domains (e.g. the definition of Locations) and you force = the >> cache-ability for all data within a hostname/domain to be the same = whether >> it is specific to a hostname/domain or common across multiple >> hostnames/domains. You therefore do not provide any ability for >> implementations to optimise based on their knowledge (or configured >> policies) of the different types of data that combine to describe = the >> CDNI Metadata for a Site/domain/hostname. >>=20 >> Self-description: >> The links between objects in our model and the representations of the >> different objects in our model are self-describing through the use of >> relationships and media-types within the interface so a client can = easily >> determine what data objects are being referenced and what data = objects it >> is receiving and use the appropriate processing function to interpret >> their contents. It is easy to add new data objects to our model if >> required by defining new relationships and/or media types. In = contrast >> your representations aren't self-describing and so force a tighter >> coupling between the client and server and they require some out of = band >> process to ensure that coupling is maintained. >=20 > The individual pieces of metadata have a defined type. If the CDN > supports a given piece of metadata, it will know what the type is. = The > metadata distribution protocol, imo, does not need to know the type > as long as the CDN who receives the metadata understands it? Knowing > the type is not necessarily enough information to know what to do with > it, the full definition of the metadata is required either way? I don't see anything in your proposal that indicates what the type (or = protocol version) a particular piece of metadata has so I therefore = assume it must be known by some other method (e.g. the protocol version = is agreed out of band, the type is inferred from something) that has the = consequence of requiring tighter coupling between client & server. As an example, think through how if your proposal is deployed would you = migrate to a newer version of the protocol and the level of explicit = knowledge and coupling between clients & servers required to do so. With self-describing objects and standard HTTP content negotiation to = negotiate a version of the objects media-type that both client & server = support it is, for example, possible to deploy a new protocol version of = our proposal on the server without requiring any changes on the clients = while retaining full backward compatibility. Clients than can be = upgraded independently of one another over a period of time while still = retaining backwards compatibility. I don't see any way to do that with your proposal without requiring = configuration on the server to tell it what version to expect from each = client and updating that configuration in lock-step with updating the = client requiring tight client/server coupling and coupled out of band = configuration. =20 >> Bootstrapping & Coupling: >> Similarly, with the CDNI Metadata interface/protocol we have = proposed, the >> configuration/bootstrapping of the interface is as simple as possible = but >> no simpler (a single URI) from which the dCDN can discover the = location of >> all the CDNI metadata records they have access to. It also allows the = uCDN >> to define the URI format (and hostname it's provided by) as they see = fit. >> The uCDN has maximum flexibility to organise the different CDNI = metadata >> objects and complete control over how they extend their = implementation to >> support additional data objects or how they support mapping different >> dCDNs to different sets of (or versions of) CDNI metadata. >>=20 >> Your proposal imposes a greater configuration/bootstrapping burden on = the >> dCDN as there is no way for it to discover the domains it has access = to, >> it needs to know the URI/hostname of the uCDN's Metadata interface = and the >> domains to query against that interface. The use of fixed paths in = the URI >> that map to the different data object enforces rigidity on the uCDN's = CDNI >> Metadata implementation (and tight coupling between the client and = server) >> and means that if the uCDN wishes to extend its implementation to = support >> additional objects it risks picking paths that may later clash with = paths >> defined by newer versions of your protocol. >=20 > Your SiteFeed object provides Site information (which is fairly = analogous > to domain information). Domain information could also be put into a = feed,=20 > however, I assume that business processes drive what goes into the = SiteFeed. Of course it's possible to modify your proposal to look more like ours = :-) but my overall argument is that our proposal does everything yours = does in a more flexible & extensible way with the exception of defining = an Agent object which isn't relevant to CDNI Metadata anyway. > Is the SiteFeed configured offline, as part of some business process? > If so, then is it better to configure Site information as a feed in > the uCDN, or as domains in the dCDN. I do not have a strong feeling > either way, but I do not see our schemes as being so different. They're not the same thing though. The SiteFeed enables a dCDN to = bootstrap itself. Whether it is configured offline or automatically = generated by the uCDN based on some configured policy and/or other data = it has automatically obtained (e.g. another SiteFeed when the uCDN is = acting as a dCDN for another CDN) is an implementation decision for each = individual CDN. Your proposal doesn't include a proposal for bootstrapping unless you're = suggesting the uCDN POST Domains into the dCDN in advance of the dCDN = requiring the associated CDNI Metadata (but your draft doesn't propose = that so I'm just guessing)? Ben >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> Taking the above factors into consideration I believe that our = proposed >> data model and interface specification is flexible and extensible = enough >> to address the current and future needs of CDNI. >>=20 >> Ben >>=20 >>=20 >>=20 >=20 From ben@niven-jenkins.co.uk Mon Oct 24 07:35:32 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F6A21F8E4E for ; Mon, 24 Oct 2011 07:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.85 X-Spam-Level: X-Spam-Status: No, score=-101.85 tagged_above=-999 required=5 tests=[AWL=-1.492, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfg3BnZ19KME for ; Mon, 24 Oct 2011 07:35:32 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id CC8A521F8E47 for ; Mon, 24 Oct 2011 07:35:31 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RILcg-0004EV-AT; Mon, 24 Oct 2011 15:35:30 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=GB2312 From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 24 Oct 2011 15:35:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> To: Will Li(jincheng) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] =?utf-8?b?562U5aSNOiAgUHJlcGFyaW5nIGRyYWZ0LWlldGYtY2RuaS1w?= =?utf-8?q?roblem-statement_for_WG_Last_Call?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:35:33 -0000 Will, Thanks for reviewing the draft & proposed changes, my opinion is inline = below. On 19 Oct 2011, at 10:24, Will Li(jincheng) wrote: > Hi, Ben, >=20 > Thank you for the efforts. Two more comments. > 1) In section 3, do you think it is helpful to add some description on = each role (i.e. CP, Upstream CDN, Downstream CDN), and their business = relationships assumed in CDNI? > This could facilitate people to understand the figure and the draft = better. The different roles are defined as part of the terminology in Section = 1.1. I don't think the Problem Statement draft should try to describe the = different business relationships as they are many and varied depending = on things like the purpose of the specific CDN, the market it is = deployed in etc and it would be very difficult to describe all the = different business relationships and we would risk getting distracted by = comments along the lines of "what about this business relationship that = you haven't described" and "you haven't adequately captured how this = relationship could work" etc. Section 1.2 already states that "Readers are assumed to be familiar with = the architecture, features and operation of CDNs." and I assume if = readers already have that familiarity with how CDNs work & are operated = then they can understand how CSPs, upstream CDNs, downstream CDNs may = fit together as part of the CDNI reference model. =20 >=20 > 2)Another editorial one: In bullet 5 of your previous mail, changing = ITU to ITU-T could be more specific. Good catch! I will use ITU-T when I update the draft. Ben >=20 > BR, Will=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] =B4=FA=B1=ED Ben Niven-Jenkins > =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C217=C8=D5 19:08 > =CA=D5=BC=FE=C8=CB: cdni@ietf.org > =D6=F7=CC=E2: [CDNi] Preparing draft-ietf-cdni-problem-statement for = WG Last Call >=20 > Colleagues, >=20 > At the last IETF I said I would try to prepare a version of the CDNI = problem Statement (draft-ietf-cdni-problem-statement) that is ready for = WG Last Call before IETF82 in Taipei. >=20 > As part of that I have reviewed the complete draft and made some minor = editorial clean-ups to my working copy. However, there were a number of = other areas where I think changes need to be made to the document that I = think warrant wider WG review/consensus and I have listed them below = along with the changes I am proposing. >=20 > Could you please provide your feedback on the areas/proposed text I = have highlighted below as well as any other areas of the document that = you think require additional work/cleanup before you consider the = document is ready for a WG Last Call. >=20 > 1) Section 2: Update the last paragraph to reference the WG draft for = CDNI use cases and remove reference to draft-watson-cdni-use-cases, i.e. >=20 > OLD: > Use cases for CDN Interconnection are further discussed in > [I-D.bertrand-cdni-use-cases] (which contains a merged set of use > cases previously presented in [I-D.watson-cdni-use-cases] and > [I-D.bertrand-cdni-use-cases-00]). > NEW: > Use cases for CDN Interconnection are further discussed in > [I-D.ietf-cdni-use-cases]. >=20 >=20 > 2) Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) = that are each just a couple of sentences, so I propose merging them into = a single section and changing the first two sentences of section 4 = appropriately, i.e. >=20 > OLD: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols. First the "reuse instead of reinvent" design > principle is restated, then each inetrface is discussed individually > with example candidate protocols that can be considered for reuse or > leverage.=20 > NEW: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols before describing each CDNI interface = individually > and highlighting example candidate protocols that could considered = for > reuse or leveraging to implement the CDNI interfaces. =20 >=20 >=20 > 3) Section 5 is currently title "Gap Analysis of relevant = Standardisation and Research Activities" but following the agreement at = the last IETF to move the generic descriptions of other activities into = an appendix Section 5 no longer references any research activities so I = propose changing the title to" Gap Analysis of relevant Standardisation = activities". >=20 > 4) After the general introduction in Section 5 there are only sections = that outline other research activities for Content Acquisition (section = 5.1) and CDNI Metadata (Section 5.2) but there are not sections for the = other CDNI interfaces (Control, Logging, Request Routing). >=20 > The reason for the lack of text is IMO because there is no current or = past standardisation activity addressing those areas but the document = currently does not mention that and therefore gives the impression of = being incomplete. >=20 > I therefore propose making the following change to the last sentence = in Section 5: >=20 > OLD: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. > NEW: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. Section 5.1 > summarises existing interfaces that could be leveraged for content > acquisition between CDNs and Section 5.2 summarises existing = metadata=20 > specifications that may be applicable to CDNI. To date there is no > existing standardisation activities in the areas of the remaining > CDNI interfaces (CDNI Request Routing, CDNI Control and CDNI = Logging). >=20 > 5) I also propose using the following text for the third bullet in = Section 5 unless someone can suggest more appropriate text to summarise = in a sentence or two any CDN metadata related work in other standards = bodies. >=20 > OLD: > o > NEW: > o CableLabs, SNIA and ITU have defined (or are working on) > definitions for content related metadata definitions and = specification > for its distribution. However, they do not include metadata = specific > to the distribution of content within a CDN or between = interconnected > CDNs. >=20 > 6) Section 10.1 lists a number of "normative references", if we adopt = the proposed changes above it will end up containing "normative" = references to: > - draft-ietf-cdni-use-cases > - draft-bertrand-cdni-experiements > - draft-jenkins-cdni-names > - RFC2119 >=20 > After reading through the text of the Problem Statement again, I am = not convinced that the Problem Statement references any of those = documents normatively as the 3 CDNI related drafts are referenced in a = context where they are for further information and the Problem Statement = does not make use of any of the capitalised terms defined in RFC2119. >=20 > Therefore, unless anyone objects I will move the references for the = three CDNI related drafts to the "Informative References" section and = remove the reference for RFC2119. >=20 >=20 > Thanks > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Mon Oct 24 07:41:27 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE1821F8E06 for ; Mon, 24 Oct 2011 07:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.371 X-Spam-Level: X-Spam-Status: No, score=-103.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbPjQU2ly5OY for ; Mon, 24 Oct 2011 07:41:26 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3B02421F8E05 for ; Mon, 24 Oct 2011 07:41:26 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-121-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RILiP-0001Uy-4a; Mon, 24 Oct 2011 15:41:25 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> Date: Mon, 24 Oct 2011 15:41:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <33313338-AE8D-4161-85DA-B60FECC9AD30@niven-jenkins.co.uk> References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 14:41:27 -0000 Colleagues, The deadline for submitting Internet-Drafts prior to IETF82 is only a = week away and I would like to have a new version of the CDNI Problem = Statement published in time for discussion during IETF82. So far I've only seen comments from Will Li. If you have any comments or = opinions on the changes/updates I propose below please can you send them = this week (but the sooner the better). In the absence of any further comments I will assume that no one objects = to the proposals and update the Problem Statement and publish the = updated version before the deadline on Monday. Thanks Ben On 17 Oct 2011, at 12:07, Ben Niven-Jenkins wrote: > Colleagues, >=20 > At the last IETF I said I would try to prepare a version of the CDNI = problem Statement (draft-ietf-cdni-problem-statement) that is ready for = WG Last Call before IETF82 in Taipei. >=20 > As part of that I have reviewed the complete draft and made some minor = editorial clean-ups to my working copy. However, there were a number of = other areas where I think changes need to be made to the document that I = think warrant wider WG review/consensus and I have listed them below = along with the changes I am proposing. >=20 > Could you please provide your feedback on the areas/proposed text I = have highlighted below as well as any other areas of the document that = you think require additional work/cleanup before you consider the = document is ready for a WG Last Call. >=20 > 1) Section 2: Update the last paragraph to reference the WG draft for = CDNI use cases and remove reference to draft-watson-cdni-use-cases, i.e. >=20 > OLD: > Use cases for CDN Interconnection are further discussed in > [I-D.bertrand-cdni-use-cases] (which contains a merged set of use > cases previously presented in [I-D.watson-cdni-use-cases] and > [I-D.bertrand-cdni-use-cases-00]). > NEW: > Use cases for CDN Interconnection are further discussed in > [I-D.ietf-cdni-use-cases]. >=20 >=20 > 2) Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) = that are each just a couple of sentences, so I propose merging them into = a single section and changing the first two sentences of section 4 = appropriately, i.e. >=20 > OLD: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols. First the "reuse instead of reinvent" design > principle is restated, then each inetrface is discussed individually > with example candidate protocols that can be considered for reuse or > leverage.=20 > NEW: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols before describing each CDNI interface = individually > and highlighting example candidate protocols that could considered = for > reuse or leveraging to implement the CDNI interfaces. =20 >=20 >=20 > 3) Section 5 is currently title "Gap Analysis of relevant = Standardisation and Research Activities" but following the agreement at = the last IETF to move the generic descriptions of other activities into = an appendix Section 5 no longer references any research activities so I = propose changing the title to" Gap Analysis of relevant Standardisation = activities". >=20 > 4) After the general introduction in Section 5 there are only sections = that outline other research activities for Content Acquisition (section = 5.1) and CDNI Metadata (Section 5.2) but there are not sections for the = other CDNI interfaces (Control, Logging, Request Routing). >=20 > The reason for the lack of text is IMO because there is no current or = past standardisation activity addressing those areas but the document = currently does not mention that and therefore gives the impression of = being incomplete. >=20 > I therefore propose making the following change to the last sentence = in Section 5: >=20 > OLD: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. > NEW: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. Section 5.1 > summarises existing interfaces that could be leveraged for content > acquisition between CDNs and Section 5.2 summarises existing = metadata=20 > specifications that may be applicable to CDNI. To date there is no > existing standardisation activities in the areas of the remaining > CDNI interfaces (CDNI Request Routing, CDNI Control and CDNI = Logging). >=20 > 5) I also propose using the following text for the third bullet in = Section 5 unless someone can suggest more appropriate text to summarise = in a sentence or two any CDN metadata related work in other standards = bodies. >=20 > OLD: > o > NEW: > o CableLabs, SNIA and ITU have defined (or are working on) > definitions for content related metadata definitions and = specification > for its distribution. However, they do not include metadata = specific > to the distribution of content within a CDN or between = interconnected > CDNs. >=20 > 6) Section 10.1 lists a number of "normative references", if we adopt = the proposed changes above it will end up containing "normative" = references to: > - draft-ietf-cdni-use-cases > - draft-bertrand-cdni-experiements > - draft-jenkins-cdni-names > - RFC2119 >=20 > After reading through the text of the Problem Statement again, I am = not convinced that the Problem Statement references any of those = documents normatively as the 3 CDNI related drafts are referenced in a = context where they are for further information and the Problem Statement = does not make use of any of the capitalised terms defined in RFC2119. >=20 > Therefore, unless anyone objects I will move the references for the = three CDNI related drafts to the "Informative References" section and = remove the reference for RFC2119. >=20 >=20 > Thanks > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Oct 24 10:03:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6328221F8BC5 for ; Mon, 24 Oct 2011 10:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6kTQ4CSVmGd for ; Mon, 24 Oct 2011 10:03:58 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E01D421F8BBB for ; Mon, 24 Oct 2011 10:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=889; q=dns/txt; s=iport; t=1319475838; x=1320685438; h=from:subject:date:message-id:to:mime-version; bh=HVrK9+3S6IglnfibYYwRFlAExM0goXOT9x25xPgPFIQ=; b=PlPyutXUYLgdTUMxXgUrNSfQkeAvM5EvmGfJpCG0LIsm1xSx3FFZyQ2W wkY1f2TGlml+eniiV+7gc03i8x3jGP9P8YfA3oZnybWN7cPFMGde24bmN t+QBFR6PkBKQ9aVfB9wlMhkXLWlmvW+GDr7HHH799MOuPrW4iGWrl+1yK 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsHAFiapU6rRDoJ/2dsb2JhbABDmhSOfoEFgWUFHQGBBAECgVKFJoIwlFSBJgGeF4dfYQSIBowDkXs X-IronPort-AV: E=Sophos;i="4.69,399,1315180800"; d="scan'208,217";a="9897305" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 24 Oct 2011 17:03:40 +0000 Received: from sjc-vpn2-877.cisco.com (sjc-vpn2-877.cisco.com [10.21.115.109]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9OH3e6X027902 for ; Mon, 24 Oct 2011 17:03:40 GMT From: Francois Le Faucheur Content-Type: multipart/alternative; boundary=Apple-Mail-375--281283901 Date: Mon, 24 Oct 2011 10:03:35 -0700 Message-Id: To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] IETF82 - CDNI WG requests for slots X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:03:58 -0000 --Apple-Mail-375--281283901 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello All, We'd like to ask any interested parties to let us know about their = request for a slot at our WG meeting planned for IETF82. Regards, Francois & Rich --Apple-Mail-375--281283901 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello All,

We'd like to ask any interested parties to let us know about their request for a slot at our WG meeting planned for IETF82.

Regards,
Francois & Rich

--Apple-Mail-375--281283901-- From sprevidi@cisco.com Mon Oct 24 10:12:50 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEBDB21F8D5C for ; Mon, 24 Oct 2011 10:12:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVTgugg0ZXqr for ; Mon, 24 Oct 2011 10:12:48 -0700 (PDT) Received: from av-tac-sj.cisco.com (firebird.cisco.com [171.68.227.73]) by ietfa.amsl.com (Postfix) with ESMTP id A465421F8D4B for ; Mon, 24 Oct 2011 10:12:48 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from bonfire.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-sj.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9OHCRPO015476 for ; Mon, 24 Oct 2011 10:12:27 -0700 (PDT) Received: from dhcp-10-155-0-156.cisco.com (dhcp-10-155-0-156.cisco.com [10.155.0.156]) by bonfire.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id p9OHCQpC002423; Mon, 24 Oct 2011 10:12:26 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: Date: Mon, 24 Oct 2011 19:12:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Francois Le Faucheur X-Mailer: Apple Mail (2.1251.1) Cc: cdni@ietf.org Subject: Re: [CDNi] IETF82 - CDNI WG requests for slots X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 17:12:50 -0000 Francois, Rich, We have submitted following draft. I'd like to request a slot=20 on the next meeting agenda so to present it. Thanks. s. Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-previdi-cdni-footprint-advertisement-00.txt > Date: October 24, 2011 5:57:54 PM GMT+02:00 > To: sprevidi@cisco.com > Cc: jmedved@juniper.net, flefauch@cisco.com, allan.guillou@sfr.com, = sprevidi@cisco.com >=20 > A new version of I-D, = draft-previdi-cdni-footprint-advertisement-00.txt has been successfully = submitted by Stefano Previdi and posted to the IETF repository. >=20 > Filename: draft-previdi-cdni-footprint-advertisement > Revision: 00 > Title: CDNI Footprint Advertisement > Creation date: 2011-10-24 > WG ID: Individual Submission > Number of pages: 18 >=20 > Abstract: > This document describes the use of BGP for Content Delivery Networks > (CDNs) in order to advertise information about footprint and > connectivity to footprint in the context of CDNI. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 On Oct 24, 2011, at 7:03 PM, Francois Le Faucheur wrote: > Hello All, >=20 > We'd like to ask any interested parties to let us know about their = request for a slot at our WG meeting planned for IETF82. >=20 > Regards, > Francois & Rich >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From mcaulfie@cisco.com Mon Oct 24 11:34:48 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4C01F0C51 for ; Mon, 24 Oct 2011 11:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bNH7N66MSZQ for ; Mon, 24 Oct 2011 11:34:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B95CC1F0C3F for ; Mon, 24 Oct 2011 11:34:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mcaulfie@cisco.com; l=402; q=dns/txt; s=iport; t=1319481288; x=1320690888; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=0yxAOXrp40kAHZ+Yu+/tIbyiPHj8GJvUpKNCYgBCpds=; b=MUN/B2wHmZd19sZLNoVORSgAUZ/cH+KFZPlj/nNuzZqbZEh4XkCbM1Ck 745Q6PCjc4W4h6rdP/FXnRcDkH2jOMNvvnH4gD/0mJsYL/l0kwgNObu97 4KookAQKLwHQxuMpHoXoG/9QR3hQ62GYeCjPsz9m3bWi4cdCPqgyyxurK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0HAH2vpU6tJXHA/2dsb2JhbABDmhSOfoEFgXABAQMSAR0KUQEqBhgHVwEEGxqHZpQggSYBnh2HX2EEiAaROIxE X-IronPort-AV: E=Sophos;i="4.69,399,1315180800"; d="scan'208";a="30590225" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 24 Oct 2011 18:34:47 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id p9OIYlla015578 for ; Mon, 24 Oct 2011 18:34:47 GMT Received: from xmb-rcd-209.cisco.com ([72.163.62.216]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 13:34:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2011 13:34:45 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: CDNI Core Metadata Thread-Index: AcySe5qaWyQ4zQjhQVyLO3+hx9ZWbw== From: "Matt Caulfield (mcaulfie)" To: X-OriginalArrivalTime: 24 Oct 2011 18:34:46.0867 (UTC) FILETIME=[9B28B230:01CC927B] Subject: [CDNi] CDNI Core Metadata X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 18:34:48 -0000 Hello everyone, Just finished uploading a new I-D describing a proposal for the core set of CDNI metadata: http://tools.ietf.org/html/draft-caulfield-cdni-metadata-core-00 Although we have not yet studied the other metadata drafts in depth, we believe that our draft is complimentary to draft-ma-cdni-metadata and has some overlap with draft-jenkins-cdni-metadata. Thanks, Matt & Kent From flefauch@cisco.com Mon Oct 24 13:33:54 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F2911E8129 for ; Mon, 24 Oct 2011 13:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=0.711, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQDCYJSe378s for ; Mon, 24 Oct 2011 13:33:53 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id B5A5E11E8122 for ; Mon, 24 Oct 2011 13:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=705; q=dns/txt; s=iport; t=1319488432; x=1320698032; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=8ihJcVIeTFYIQ/ZSGUoMoNaS48z0uRKubS/nDL2wE2Y=; b=SVPJ7AYAy6ZKUbAss0687Yx4IZu0m/HUnnGiM3xwCHOKp8T6Nr7YCNL8 RzQYUeV+dtlmDA1OJbor3XFCIrI9IjkCnhZwZD5/HOUtBuJv19cBT6pq7 vlQbundc9dfB6adbY6RdQSjYzrCnIfZW3Rh0t5fogZhsp1h6ALsDzNT83 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcBAJHLpU6rRDoG/2dsb2JhbABDmVJDjn6BBYFuAQEBAQIBAQEBDwEnNBALC0YnMBkih14IlWIBnisEh19hBIgGjAORew X-IronPort-AV: E=Sophos;i="4.69,400,1315180800"; d="scan'208";a="9946449" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 24 Oct 2011 20:33:49 +0000 Received: from dhcp-171-70-243-64.cisco.com (dhcp-171-70-243-64.cisco.com [171.70.243.64]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9OKXnC6029443 for ; Mon, 24 Oct 2011 20:33:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Francois Le Faucheur In-Reply-To: Date: Mon, 24 Oct 2011 13:33:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: cdni@ietf.org X-Mailer: Apple Mail (2.1084) Subject: Re: [CDNi] CDNI Slot at IETF-82 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 20:33:54 -0000 Hello, As per the final agenda = (https://datatracker.ietf.org/meeting/82/agenda.html), the CDNI WG = session has been moved to : WEDNESDAY, November 16, 2011 09:00 - 11:30 Cheers Francois & Rich On 14 Oct 2011, at 04:30, Francois Le Faucheur wrote: > Hi, >=20 > Note that as per the _draft_ agenda = (https://datatracker.ietf.org/meeting/82/agenda.html), the CDNI WG = session is tentatively scheduled: > THURSDAY, November 17, 2011 > 15:20-17:20 >=20 > This is still subject to potential change. >=20 > Cheers >=20 > Francois >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From emile.stephan@orange.com Mon Oct 24 14:15:04 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCE211E80EA for ; Mon, 24 Oct 2011 14:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlXWrPJQgitE for ; Mon, 24 Oct 2011 14:15:04 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id DD6D911E80E7 for ; Mon, 24 Oct 2011 14:15:03 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 226B6AB0007 for ; Mon, 24 Oct 2011 23:16:04 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1B0CD8B8002 for ; Mon, 24 Oct 2011 23:16:04 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 24 Oct 2011 23:15:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 24 Oct 2011 23:14:59 +0200 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201FE4543@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-stephan-cdni-usecases-metadata-00.txt Thread-Index: AcySkTGhaTVs910fQZW6OIVmSPtadwAAC8Kg From: To: X-OriginalArrivalTime: 24 Oct 2011 21:15:03.0405 (UTC) FILETIME=[FF0FF1D0:01CC9291] Subject: [CDNi] TR: I-D Action: draft-stephan-cdni-usecases-metadata-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Oct 2011 21:15:05 -0000 Hi I uploaded a draft that we just achieved. It proposes a framework for = the exchange of content distribution metadata based between an upstream = CDN and a downstream CDN. =20 Abstract There are use cases where the delivery of contents by a CDN on the behalf of another requires the exchange of extra information between these CDNs. This memo proposes a RESTful framework for the exchange of content distribution metadata between an upstream and a downstream CDN. Then it applies this framework to the use cases selected by te CDNi WG [I-D.ietf-cdni-use-cases] to identify relevant operations, objects and information elements of the CDNi metadata interface and to verify that the RESTful approach suits for these operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stephan-cdni-usecases-metadata-= 00.txt=20 Regards Emile =20 -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org = [mailto:i-d-announce-bounces@ietf.org] De la part de = internet-drafts@ietf.org Envoy=E9=A0: lundi 24 octobre 2011 23:09 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-stephan-cdni-usecases-metadata-00.txt A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : metadata for CDNs Interconnection Author(s) : Stephan Emile Bertrand Gilles Fieau Frederic Pages Remi Filename : draft-stephan-cdni-usecases-metadata-00.txt Pages : 42 Date : 2011-10-24 There are use cases where the delivery of contents by a CDN on the behalf of another requires the exchange of extra information between these CDNs. This memo proposes a RESTful framework for the exchange of content distribution metadata between an upstream and a downstream CDN. Then it applies this framework to the use cases selected by te CDNi WG [I-D.ietf-cdni-use-cases] to identify relevant operations, objects and information elements of the CDNi metadata interface and to verify that the RESTful approach suits for these operations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-stephan-cdni-usecases-metadata-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-stephan-cdni-usecases-metadata-0= 0.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From hexiaoyan@huawei.com Mon Oct 24 17:47:15 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F00811E81F0 for ; Mon, 24 Oct 2011 17:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=5 tests=[AWL=-3.648, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWPV3vgjEgWd for ; Mon, 24 Oct 2011 17:47:14 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6965911E81E4 for ; Mon, 24 Oct 2011 17:47:14 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTL00JHJJINAU@szxga05-in.huawei.com> for cdni@ietf.org; Tue, 25 Oct 2011 08:47:11 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTL00CBUJIM7A@szxga05-in.huawei.com> for cdni@ietf.org; Tue, 25 Oct 2011 08:47:11 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEJ95016; Tue, 25 Oct 2011 08:47:10 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 08:47:06 +0800 Received: from w36710x (10.144.242.117) by smtpscn.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 25 Oct 2011 08:46:59 +0800 Date: Tue, 25 Oct 2011 08:46:58 +0800 From: HeXiaoyan In-reply-to: X-Originating-IP: [10.144.242.117] To: 'Francois Le Faucheur' , cdni@ietf.org Message-id: <000001cc92af$9aa7c4c0$cff74e40$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/alternative; boundary="Boundary_(ID_IcBlKLAjCad9rBqRIs3jHg)" Content-language: zh-cn Thread-index: AcySbvYcLTKvEsDhSyeQ736kYjDWNgAQCKWg X-CFilter-Loop: Reflected References: Subject: [CDNi] =?gb2312?b?tPC4tDogIElFVEY4MiAtIENETkkgV0cgcmVxdWVzdHMg?= =?gb2312?b?Zm9yIHNsb3Rz?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 00:47:15 -0000 --Boundary_(ID_IcBlKLAjCad9rBqRIs3jHg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: quoted-printable Hi Francois & Rich, I'd like to request a slot on the next meeting to present the following draft. http://www.ietf.org/id/draft-xiaoyan-cdni-request-routing-protocol-00.txt= =20 Thanks. Best Regards Xiaoyan(Susan) He =B7=A2=BC=FE=C8=CB: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] = =B4=FA=B1=ED Francois Le Faucheur =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 1:04 =CA=D5=BC=FE=C8=CB: cdni@ietf.org =D6=F7=CC=E2: [CDNi] IETF82 - CDNI WG requests for slots =20 Hello All, We'd like to ask any interested parties to let us know about their = request for a slot at our WG meeting planned for IETF82. Regards, Francois & Rich =20 --Boundary_(ID_IcBlKLAjCad9rBqRIs3jHg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Francois & Rich,

I'd like to request a slot on = the next meeting to present the following draft.

http://www.ietf.org/id/draft-xiaoyan-cdni-request-routing-proto= col-00.txt

 

Thanks.

Best Regards

Xiaoyan(Susan) He

=B7=A2=BC=FE=C8=CB: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] =B4=FA=B1=ED = Francois Le = Faucheur
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA10=D4=C225=C8=D5 1:04
=CA=D5=BC=FE=C8=CB: cdni@ietf.org
=D6=F7=CC=E2: = [CDNi] IETF82 - CDNI WG requests for slots

 

Hello All,

We'd like to ask any interested parties to let us know about their = request for a slot at our WG meeting planned for IETF82.

Regards,
Francois & Rich

 

--Boundary_(ID_IcBlKLAjCad9rBqRIs3jHg)-- From dgriffin@ee.ucl.ac.uk Tue Oct 25 03:29:10 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D61A521F8B4B for ; Tue, 25 Oct 2011 03:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XixoxoHPKpIf for ; Tue, 25 Oct 2011 03:29:10 -0700 (PDT) Received: from dax.ee.ucl.ac.uk (dax.ee.ucl.ac.uk [128.40.42.12]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC3921F8B4A for ; Tue, 25 Oct 2011 03:29:09 -0700 (PDT) Received: from [IPv6:::1] (dublin.ee.ucl.ac.uk [128.40.42.3]) (authenticated bits=0) by dax.ee.ucl.ac.uk (8.13.8/8.13.8) with ESMTP id p9PASig4029778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Oct 2011 11:28:45 +0100 (BST) Message-ID: <4EA68F59.808@ee.ucl.ac.uk> Date: Tue, 25 Oct 2011 11:28:41 +0100 From: David Griffin User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: cdni@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-UCL-EE-MailScanner-Information: Please contact the ISP for more information X-UCL-EE-MailScanner-ID: p9PASig4029778 X-UCL-EE-MailScanner: Found to be clean X-UCL-EE-MailScanner-From: dgriffin@ee.ucl.ac.uk Subject: [CDNi] draft-fmn-cdni-advanced-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 10:29:10 -0000 Hi all, The draft below has been uploaded to catalogue further CDNi use cases arising from ongoing research in several projects who are active in content distribution topics. The idea is to highlight some important issues for interconnecting CDNs beyond the use cases being used to drive the initial work of the WG, which we believe are highly relevant to the future direction of CDNi. Best regards, David ------------------------------ A new version of I-D, draft-fmn-cdni-advanced-use-cases-00.txt has been successfully submitted by Theodore Zahariadis and posted to the IETF repository. Filename: draft-fmn-cdni-advanced-use-cases Revision: 00 Title: Catalogue of Advanced Use Cases for Content Delivery Network Interconnection Creation date: 2011-10-24 WG ID: Individual Submission Number of pages: 14 Abstract: The purpose of this draft is to complement the current CDNi WG use- cases with a catalogue of advanced, longer-term CDN interconnection use cases. The work has been the contribution of six European Commission (EC) co-funded projects, which are part of the EC Future Media networks (FMN) cluster. From Jan.Seedorf@neclab.eu Tue Oct 25 03:40:11 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B7421F8B6F for ; Tue, 25 Oct 2011 03:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLaW4wNIQ7nJ for ; Tue, 25 Oct 2011 03:40:10 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7B36621F8B64 for ; Tue, 25 Oct 2011 03:40:04 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9C250280000F5; Tue, 25 Oct 2011 12:40:24 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas1.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlOoU1jDMEWb; Tue, 25 Oct 2011 12:40:24 +0200 (CEST) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 76EED28000080; Tue, 25 Oct 2011 12:40:04 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.17]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 25 Oct 2011 12:39:21 +0200 From: Jan Seedorf To: Francois Le Faucheur , "cdni@ietf.org" Thread-Topic: [CDNi] IETF82 - CDNI WG requests for slots Thread-Index: AQHMkm8ABotxWmJZtUymhArfHZV4wZWM3mnQ Date: Tue, 25 Oct 2011 10:39:20 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24E52B77@PALLENE.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.210] Content-Type: multipart/alternative; boundary="_000_2779C9F0771F974CAD742BAE6D9904FE24E52B77PALLENEofficehd_" MIME-Version: 1.0 Cc: "Vijay K. Gurbani \(vkg@bell-labs.com\)" Subject: Re: [CDNi] IETF82 - CDNI WG requests for slots X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2011 10:40:11 -0000 --_000_2779C9F0771F974CAD742BAE6D9904FE24E52B77PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Francois and Rich, I would like to present the draft I submitted on ALTO for CDNi Request Rout= ing (draft-seedorf-alto-for-cdni-00), see http://tools.ietf.org/html/draft-= seedorf-alto-for-cdni-00. As this is obviously relevant for ALTO as well, I have put the ALTO chairs = in CC. It may well be that the draft should rather be presented in the ALTO= WG, and I would be fine with that (presenting in ALTO and not in CDNi). - Jan From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: Monday, October 24, 2011 7:04 PM To: cdni@ietf.org Subject: [CDNi] IETF82 - CDNI WG requests for slots Hello All, We'd like to ask any interested parties to let us know about their request = for a slot at our WG meeting planned for IETF82. Regards, Francois & Rich --_000_2779C9F0771F974CAD742BAE6D9904FE24E52B77PALLENEofficehd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Dear Francois and Rich,=

=  

= I would like to present the draft I submitted on= ALTO for CDNi Request Routing (draft-seedorf-alto-for-cdni-00), see = http://tools.ietf.org/html/draft-seedorf-alto-for-cdni-00.

=  

= As this is obviously relevant for ALTO as well, = I have put the ALTO chairs in CC. It may well be that the draft should rather be presented in the ALTO WG, and I would be fine with that (= presenting in ALTO and not in CDNi).

=  

-          Jan

=  

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Beha= lf Of Francois Le Faucheur
Sent: Monday, October 24, 20= 11 7:04 PM
To: cdni@ietf.org
Subject: [CDNi] IETF82 - CDN= I WG requests for slots

 

Hello All,

We'd like to ask any interested parties to let us know about their request = for a slot at our WG meeting planned for IETF82.

Regards,
Francois & Rich

 

--_000_2779C9F0771F974CAD742BAE6D9904FE24E52B77PALLENEofficehd_-- From alan.kavanagh@ericsson.com Wed Oct 26 06:37:31 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA49A21F8AD8 for ; Wed, 26 Oct 2011 06:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VczSMGVEHim for ; Wed, 26 Oct 2011 06:37:30 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C1F0121F8A7D for ; Wed, 26 Oct 2011 06:37:30 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9QDav8S024801; Wed, 26 Oct 2011 08:37:17 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.232]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 26 Oct 2011 09:37:03 -0400 From: Alan Kavanagh To: Kevin J Ma , Ben Niven-Jenkins Date: Wed, 26 Oct 2011 09:37:02 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyILaNxgfGmi71uTyS4A0eFwyx96wAAOmFAAu0ghjA= Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D5170F26B74D@EUSAACMS0701.eamcs.ericsson.se> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B5151768@MAILR002.mail.lan> <291CC3F9E50E7641901A54E85D0977C651B515180A@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B515180A@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 13:37:31 -0000 Kevin/Ben I know im late punting this out, but felt its important we clarify this in = the use case document. Isnt it more the case that the CP does a business agreement with a CDN prov= ider to ensure he can deliver the content in a number of format and screen = density types and if this CDN provider is unable to do so the CP would not = do a business agreement with this CDN Provider in the first place.=20 Similarly, today a lot of CP's provide one Video Source and while I agree w= ith Ben that encoding is done outside the delivery node itself its typicall= y part of the CDN eco-system from my point of view. Yes both models exist b= ut then both should be captured in the use case document. This is important= to convey another major benefit of CDN and CDN-I thus that CP delivers one= high video source to the uCDN and that CDN is responsible for content deli= very in a number of format and screen density types etc. Similarly and I be= lieve Kevin Ma and other raised this at the Quebec IETF meeting in that CDN= -I should cover supporting transcoding, the main advantage is see is that t= he uCDN delivers one high video source to the dCDN and that in turns does t= he transcoding instead of having to fetch the same file x number of times w= hen it doesn't do the transcoding. I see this more so for Broadcast TV etc = so imho its something that should be in the CDN-I scope and somehow conveye= d in the appropriate docs. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kev= in J Ma Sent: October-11-11 12:04 PM To: Ben Niven-Jenkins Cc: ZhouZhipeng; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ben, The restriction is not that content "absolutely must be delivered by a different CDN", the restriction is that content should only be delivered in specific formats to specific end users, and certain users may only get access through specific CDNs. This can be (and is) enforced today by using different CDNs (e.g., separate CDNs for TV vs mobile). Once those two CDNs combine, it removes an inherent physical restriction, which some CPs may have been relying on. thanx. -- Kevin J. Ma > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Tuesday, October 11, 2011 11:51 AM > To: Kevin J Ma > Cc: Brandenburg, R. (Ray) van; cdni@ietf.org; ZhouZhipeng > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Kevin, >=20 > On 11 Oct 2011, at 15:48, Kevin J Ma wrote: >=20 > > Hi Ben, > > > > I do not disagree with the statements made below, however, I think =20 > > that there is one point that is missing: in a non-interconnected =20 > > world, CPs can (and do) put different representations into different =20 > > CDNs, knowing that representation-A will not be accessible via CDN-B. > > It is true that the CDN did not make any decision, the CP did,=20 > > however, the enforcement is based on the fact that those CDNs will=20 > > not share with each other and are physically separated. With CDNI,=20 > > if the uCDN has access to all representations but the CP needs to=20 > > enforce that specific dCDNs only have access to subsets of=20 > > representations (due to content licensing restrictions), enforcing=20 > > that probably requires metadata to describe those delivery restriction= s? >=20 > I'd like to understand these requirements better as I am aware of=20 > Content Providers that choose to use different CDNs for different=20 > representations based on business policy and I think that can be=20 > solved at the business agreement level in the same way as dealing with=20 > what delivery protocols or delivery footprint the Content Provider requir= es. >=20 > I am aware of licensing agreements that restrict what geographies=20 > content can be delivered from and what geographies content can be deliver= ed to. > Such requirements are already handled by the metadata proposal I co-=20 > authored through the use of SelectionACL & DeliveryACLs. >=20 > However, I've not heard of a licensing agreement that mandated that=20 > some representations of a piece of content absolutely must be=20 > delivered by a different CDN to other representations of the same content= . >=20 > Can you expand on the motivation and drivers behind that requirement? >=20 > Thanks > Ben >=20 > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 > >> Behalf Of Ben Niven-Jenkins > >> Sent: Tuesday, October 11, 2011 9:26 AM > >> To: Brandenburg, R. (Ray) van > >> Cc: cdni@ietf.org; ZhouZhipeng > >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > >> > >> > >> On 11 Oct 2011, at 13:12, Brandenburg, R. (Ray) van wrote: > >> > >>> Hi all, > >>> > >>> While I am neutral to the Content Adaptation discussion, I would=20 > >>> like > to > >> make sure that we do not throw out all features related to multiple=20 > >> representations, which would happen if we would just remove section > 5.1.3 > >> completely as suggested by Ben. > >> > >> I'm not sure how you draw that conclusion as removing section 5.1.3 > does > >> not throw out the ability to support multiple representations IMO. > >> > >>> The previous version of the use case document (betrand-02) had a > >> slightly different wording in section 2.4 than is now being used in=20 > >> section 5.1 of the new WG-version. I think the concept of=20 > >> resolution- based constraints, that was included in betrand-02,=20 > >> should remain in > some > >> form. While it is not the CDNs responsibility/decision whether to=20 > >> allow > a > >> specific representation to be delivered, I think a use case in=20 > >> which > some > >> dCDN only offers a subset of the representations available on the=20 > >> uCDN > is > >> quite valid (such as in a dedicated mobile CDN). > >> > >> I don't believe that dCDNs will only offer a subset of=20 > >> representations > in > >> the way you describe. They may only deliver to a subset of users=20 > >> (and maybe by implication a subset of possible devices) for example=20 > >> as a consequence of them being a dedicated mobile CDN (as opposed=20 > >> to an > active > >> decision they make). > >> > >> Let's look at how a content service is deployed. A Content Provider=20 > >> has some content (let's say a video) that the Content Provider may=20 > >> produce > in > >> a variety of representations (codecs, bit rates, resolutions, etc.). > They > >> may do that encoding themselves or outsource it (although that's=20 > >> not relevant to the point I'm making). > >> > >> A User will connect to the Content Provider's "portal" (which may=20 > >> be a > web > >> portal, an application, an EPG etc.). The Content Provider (through > their > >> portal) will offer the User the content in one or more of the=20 > >> available representations (e.g. by device type but how that=20 > >> decision is made is purely up to the Content Provider). The User=20 > >> selects a representation > and > >> the Content Provider offloads the delivery of that representation=20 > >> to > the > >> CDN (e.g. by returning the appropriate URI for that representation > within > >> the CDN to the User's client). The User then connects to the CDN=20 > >> and requests the representation they have selected (from the choice=20 > >> of representations offered to them by the Content Provider). > >> > >> At its essence a CDN maps incoming URIs (from User's clients) to > specific > >> content files on an upstream source (e.g. on-net storage or a=20 > >> Content Provider's Origin server) it has no explicit knowledge of=20 > >> what actual content that specific URI maps to or that it is one of=20 > >> X possible representations of the same content. > >> > >> At no point has the CDN been involved in the selection or=20 > >> restriction > of > >> the representations offered to or delivered to the User. In a CDNI=20 > >> scenario things are no different. A uCDN may select a dCDN based on > some > >> capability (e.g. what Users it can deliver to, what delivery=20 > >> protocols > it > >> can support) but I do not think that the specific representation of=20 > >> the content will enter into the equation beyond those constraints. > >> > >> For example, the dCDN is not going to say "I can only deliver=20 > >> representations with resolutions below AxB" and the uCDN often will=20 > >> not even know what the resolution or a particular representation is. > >> > >> What might happen is that a User on a particular network (or using=20 > >> a particular client/device) connects to the Content Provider's=20 > >> portal and > is > >> only offered a subset of the possible representations tailored (by=20 > >> the Content Provider's policy implemented in the Content Provider's=20 > >> portal) based on that User's Network/Client/Device. A dCDN may=20 > >> subsequently be selected that can serve that Network/Client/Service=20 > >> and that dCDN may > only > >> end up delivering to its Users a subset of all the possible=20 > >> representations the Content Provider has produced. But that is a=20 > >> consequence of the Network/Clients/Devices the dCDN is capable of > serving, > >> not an explicit decision made by the dCDN and communicated to the=20 > >> uCDN > for > >> that specific Content Provider's service. > >> > >> Ben > >> > >> > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From sergem913@gmail.com Wed Oct 26 07:39:03 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B5F21F8A67 for ; Wed, 26 Oct 2011 07:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.485 X-Spam-Level: X-Spam-Status: No, score=-3.485 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id le6p0k8VbMWH for ; Wed, 26 Oct 2011 07:39:02 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9575A21F8A64 for ; Wed, 26 Oct 2011 07:39:02 -0700 (PDT) Received: by faas12 with SMTP id s12so1870245faa.31 for ; Wed, 26 Oct 2011 07:39:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=74KIPq6xpenTWJHE0/QzG2d3pxIsCAkeOepe417gr+0=; b=KI1yOHj85qyE/V2DsDppkyHXiZdbBd8tCq2FviNacUOiQnQ3PXQIjjAsFSfsppRgvB 7IkGaiM097owx0cCNW56tadutDdc1QiNH9JA2SF9y55Ye2XUGjeAVltSnw+MxBDF2bMj 3QkFjK+vrGzlm95qsIORgtPyCkYngciJRzvVo= MIME-Version: 1.0 Received: by 10.223.85.139 with SMTP id o11mr59549330fal.0.1319639941720; Wed, 26 Oct 2011 07:39:01 -0700 (PDT) Received: by 10.152.12.164 with HTTP; Wed, 26 Oct 2011 07:39:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 26 Oct 2011 09:39:01 -0500 Message-ID: From: Serge Manning To: Francois Le Faucheur , "Woundy, Richard" Content-Type: multipart/alternative; boundary=000e0ce0f7b4f52a2804b0349d34 Cc: cdni@ietf.org Subject: Re: [CDNi] IETF82 - CDNI WG requests for slots X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:39:03 -0000 --000e0ce0f7b4f52a2804b0349d34 Content-Type: text/plain; charset=ISO-8859-1 Francois and Rich, I would like to request a slot for the following draft. Thanks. Filename: draft-manning-cdni-additional-csf-reqs Revision: 00 Title: Additional Content Distribution Network Interconnection (CDNI) Requirements Based on ATIS CSF Creation date: 2011-10-21 WG ID: Individual Submission Number of pages: 9 On Mon, Oct 24, 2011 at 12:03 PM, Francois Le Faucheur wrote: > Hello All, > > We'd like to ask any interested parties to let us know about their request > for a slot at our WG meeting planned for IETF82. > > Regards, > Francois & Rich > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > -- --Serge --000e0ce0f7b4f52a2804b0349d34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Francois and Rich,

I would like to request a slot for th= e following draft. Thanks.

Filename: =A0 = =A0 =A0 =A0draf= t-manning-cdni-additional-csf-reqs Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 = =A0 Additional Content Distribution Network Interconnection (CDNI) Requirem= ents Based on ATIS CSF
Creation date: =A0 2011-10-21=
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 9

On Mon, Oct 24, 2011 at 12:03 PM, Francois Le Faucheur <flefauch@cisco.com> wrote:
Hello A= ll,

We'd like to ask any interested parties to let us know about= their request for a slot at=A0our WG meeting planned for IETF82.

Regards,
Francois & Rich


___= ____________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni




--
--Serge<= br>
--000e0ce0f7b4f52a2804b0349d34-- From dgriffin@ee.ucl.ac.uk Wed Oct 26 07:49:08 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC9221F8B5B for ; Wed, 26 Oct 2011 07:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDVbokyF906n for ; Wed, 26 Oct 2011 07:49:07 -0700 (PDT) Received: from dax.ee.ucl.ac.uk (dax.ee.ucl.ac.uk [128.40.42.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC9621F8B6E for ; Wed, 26 Oct 2011 07:49:07 -0700 (PDT) Received: from [127.0.0.1] (dublin.ee.ucl.ac.uk [128.40.42.3]) (authenticated bits=0) by dax.ee.ucl.ac.uk (8.13.8/8.13.8) with ESMTP id p9QEm1lq022995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Oct 2011 15:48:02 +0100 (BST) Message-ID: <4EA81DFE.1000006@ee.ucl.ac.uk> Date: Wed, 26 Oct 2011 15:49:34 +0100 From: David Griffin User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cdni@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-UCL-EE-MailScanner-Information: Please contact the ISP for more information X-UCL-EE-MailScanner-ID: p9QEm1lq022995 X-UCL-EE-MailScanner: Found to be clean X-UCL-EE-MailScanner-From: dgriffin@ee.ucl.ac.uk Subject: Re: [CDNi] IETF82 - CDNI WG requests for slots X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 14:49:08 -0000 Hi Francois, Rich, We would like to request a slot for http://tools.ietf.org/html/draft-fmn-cdni-advanced-use-cases-00 Best regards, David On 24/10/2011 18:03, Francois Le Faucheur wrote: > Hello All, > > We'd like to ask any interested parties to let us know about their > request for a slot at our WG meeting planned for IETF82. > > Regards, > Francois & Rich > > > ------------------------------------------------------------------------ > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From alan.kavanagh@ericsson.com Wed Oct 26 12:11:59 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420DA21F888A for ; Wed, 26 Oct 2011 12:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4oEmA0Mhdas for ; Wed, 26 Oct 2011 12:11:57 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id A0A4B21F84A2 for ; Wed, 26 Oct 2011 12:11:57 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9QJBl03009609; Wed, 26 Oct 2011 14:11:52 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.232]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 26 Oct 2011 15:11:47 -0400 From: Alan Kavanagh To: ZhouZhipeng , Ben Niven-Jenkins Date: Wed, 26 Oct 2011 15:11:46 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAWs+Dg Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D5170F26BADD@EUSAACMS0701.eamcs.ericsson.se> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:11:59 -0000 Hi Zhou Slowly catching up on all these CDN-I emails :-) I fully agree with your assertion here, I had the same puzzlement when read= ing the use cases and looking at the lat few "hundred plus" emails on this. To me a core functionality of CDN's as Ben et.al has pointed out is to redu= ce cost, sending 1 stream as opposed to 10 streams is definitely a core req= uirement and a core use case for CDN-I too. Somewhat orthogonal to the use cases, but a case I feel is missing from the= current metadata drafts I have read is to define this case of supporting t= ranscoding for CDN-I. It makes perfect sense that CDN-I must support this s= cenario so that CDN's leverage on cost reduction by supporting transcoding. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Zho= uZhipeng Sent: October-12-11 5:23 AM To: Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hello Ben, The UE may select the content format on the CP web. After that the user onl= y desires to get his selected content. But how the content is transferred to the client is not worried by the user= . The CP may create a special format as required by the user and ask the CDN = to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transfo= rm to the format as the user select. In this case, it is nothing related to how the user select formats on CP we= bsite. So, it is the CP and user to decide the content format not the CDN(your ass= ert is not correct and seems you take that assert as your base for the disc= ussion). As for "the core CDN functionality offered by CDNs today", I have ever rais= ed an email before that your company's webpage has claimed supporting media= transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core fu= nctionalities by existing main stream CDNs. Thus we may compare and take de= ep look. I guess many people have the experience/knowledge of content related servic= e. The user and CP only care whether the CDN providers may satisfy their re= quirement while not care the internal process. Just as GSM/PSTN interconnec= tion, the user only care successful interconnection while not care how the = voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media format= s. One candidate is your company, another is CDN-X. The users are located in F= rance. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one= content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y whil= e CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the c= ost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in s= olution-2, it should only receive 1 stream but need to take transformation = to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the p= rice from BBC is same to both your company and CDN-X or BBC would select on= e CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is no= t a core functionality. So, if we all realize that currently the media type is rich, the CDN provid= ers should survive in the existing ecosystem and support the media types as= required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection,= the transformation should at once be solved. Otherwise the interconnection= may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > Ben and Philip, > I like to respond your concern in this one email: > > Ben, > I feel what we are now discussing is what is the "core" function of CDN. > As you say, CDN is used to deliver content. That is absolutely correct th= at the delivery capability is the core requirement for CDN system. > While CDN is used to provide the content delivery service. > What means service. It should include "time" "location" and "media type",= etc. These features are all the core feature for a service. > If we only concern "delivering one data block", I am not sure whether the= issues such as "logging" "geographic constraint" are the core of CDN. > > For "without explicit knowledge of what that content actually is ", I am = not sure whether the wording is accurate since generally a CDN may claim it= support different medias. > By this opportunity, I like to share a use case: a call from a GSM phone = to a PSTN telephone, the voice stream should be transformed from GSM voice = to G.711. > For the user, he does not need to know what type of data has been transfe= rred, but the operator has done some work to interconnect two systems, righ= t. > I like to know whether you may accept that my use case is similar to this= case above. I don't think your use case is similar to the analogy of mobile networks be= ing interconnected to PSTN networks. In the case of content delivery the ne= gotiation is done between the User/Client and the Content Provider and the = CDN is just used to execute/perform the delivery that has been negotiated. = The CDN is not involved in the decision making of what representations the = Content Provider decides to offer to the User/Client or in what representat= ions the User/Client decides to request. > As for you said selecting media by the "portal", you may see the way " uC= DN delivers multiple media streams to dCDN" is not good than "uCDN delivers= one media stream to dCDN and dCDN takes some adaptation to support multipl= e media types". Now what you're talking about is an optimisation, not a core function requi= red to actually deliver the content (and report, bill, etc. for that delive= ry). My position is that we should focus on how to enable the interconnection of= the core CDN functionality offered by CDNs today (which is also my interpr= etation of the scope of the CDNI working group as expressed in its charter)= because doing so is a significant piece of work in itself. Let's not start= trying to add in additional functionality beyond what the majority of CDNs= support today as that will just delay us getting usable specifications int= o the market in a timely fashion IMO. Ben > A good question is "security" since I have done six years on the DRM > and like to promote the DRM all around the world:) If the content is need= ed to be protected, generally you may know all the systems should be grante= d by the content owner. > Here I also like to clarify that not only the media itself but the inform= ation related to service itself (such as the geographic constraint) should = be protected also. > So, trust is not a problem for the media. > > Philip, > Thank you that you feel Content Adaption is an issue for "Requirements" b= ut I do not know why it is not for Use case. > I like to clarify to U that it is important for you operator since it may= save investment if the system may support different services. > For us vendor, we are happy operator may install a system for the mobile = service and another system for the FBB service. > But the reality is all operators ask us to provide a system that may supp= ort different service systems. > > Frankly, Ben and Philip, I remember I have explained somewhere that to im= plement this is rather simple . > At least the Use case and Requirement are informational to be referred in= future work. So I do really feel you may accept it. > Of course I like to respond your more concern and comments. > Thanks. > Zhipeng > > > > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Monday, October 10, 2011 11:22 PM > To: ben@niven-jenkins.co.uk; ZhouZhipeng > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Ben, Zhipeng, all, > > I think that Content Adaptation is more an issue for the Requirements doc= than for the Use cases draft. > > The key question is whether we want the CDNI interfaces to be able to cop= e with a scenario where (say) HD/SD conversion is done in the dCDN & to sig= nal about this. > > I think that coping with this scenario is a second order requirement, ie = we should not worry about it in the initial standards-track work. I don't k= now, did we ever decide whether the Use cases doc is restricted to "initial= " scenarios, or whether it's all-encompassing, ie covering "future" scenari= os as well? > > Scott, > Reading some of your examples, they seem to be valid even if content adap= tation (HD/SD) is out of scope. > - a dCDN might for some reason be unwilling to distribute HD? > - a CSP might want to make sure the dCDN can use HLS encapsulation? > But these sorts of examples seem to be static policy things (to do > with the capabilities & preferences of the CDNs & CSP), rather than > metadata associated with a particular piece of content. In the > discussion so far, I think negotiation about static policy stuff is > rather out of scope(?) > > On security considerations, an interesting question is whether trust is t= ransitive. Don't think it need be - just because CSP trusts uCDN, and uCDN = trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. Howeve= r, i suspect this can get arbitrarily complex - so one possibility is to sa= y that we will only handle cases where the trust is transitive. > > Best wishes > phil > > > Philip Eardley > Research and Technology Strategy > > This email contains BT information, which may be privileged or confidenti= al. It's meant only for the individual(s) or entity named above. If you're = not the intended recipient, note that disclosing, copying, distributing or = using this information is prohibited. If you've received this email in erro= r, please let me know immediately on the email address above. Thank you. We= monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ Registered in > England no: 1800000 > > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: 10 October 2011 12:04 > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Colleagues, > > IMO Section 5.1.3 should be removed from the Use Cases draft. Content Ada= ptation (i.e. taking in a content item in one format and transforming it to= another format or representation) is not a "core" function of a CDN which = typically delivers the content that is requested without explicit knowledge= of what that content actually is. > > Let's not forget that in building an end to end content service the CDN i= s only one component and is the component tasked with executing the deliver= y of a specific representation (version/copy/format etc.) of the selected c= ontent not the component tasked with deciding (or applying policy) on which= version/copy/representation of content should be delivered. > > The decision as to which version/copy/representation to offer and allow t= o be delivered to a given device/user is implemented outside of the CDN (e.= g. by the "portal" where the user first makes their content selection prior= to the CDN becoming involved in the delivery of the selected content). > > Ben > > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > >> Following Scott's comments on section 5.1.3, I feel Scott's description = on the use case of HD and SD is not exactly correct. >> If one movie has two formats of HD and SD, then we have two content with= different identifier. In DRM scope, the basic unit is a content copy. >> >> Here the first bullet "a subset of encodings deliverable to specific dev= ices," has listed the case of content adaptation. >> In last month, I have contacted the Authors of this document and taken s= ome email exchanges with Grant and Philip (BT). >> I have shown BT with some information that I know in this case and area = to explain the content flexibility is currently a basic requirement for CDN= service and related negotiation is needed in the CDN interconnection. >> Meanwhile, I should also invite you in this group raising your comments = or questions on this case since I hope my use case may be incorporated in t= he use case draft. >> >> If you have any more question or comments, pls share in this thread. >> Thanks. >> Zhipeng >> >> >> >> >> >> >> -----Original Message----- >> From: Scott Wainner [mailto:swainner@cisco.com] >> Sent: Friday, September 30, 2011 8:02 AM >> To: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> >> Section 2.3 Nomadic Users >> This description falls under the category of Geographic Extension >> yet the third paragraph states the case where a different device is >> used in the same CDN coverage area. The intent of this use case >> needs to be clarified. Perhaps the use case is trying to address the >> scenario where a Nomadic User-A with an agreement allowing access to >> content from CSP-A via uCDN moves to a dCDN in a different region. >> The dCDN is allowed to distribute the content of CSP-A to User-A; >> however, not other users in the region of the dCDN are allowed to >> retrieve the content unless they too have such an agreement. >> >> Section 5.1.3 Content Encoding Restrictions Need to clarify if we're >> talking about the restrictions on the delivery of specific content or >> the restrictions on the ability of a CDN to deliver specific content. >> I certainly understand the case where a CSP will restrict the >> distribution of content to a "managed path" if such content is HD >> while allowing the content distribution via an un-managed path if >> such content is SD (same could apply to encryption methods, delivery >> methods, etc.). On the contrary, the dCDN may have its own >> restrictions of blocking the distribution of HD content while >> allowing the distribution of SD content. >> >> o first bullet makes sense if the dCDN can perform a subset of >> encapsulations for a reference set of media (e.g. HLS, HSS, but not >> DASH) o second bullet makes sense where the dCDN doesn't want to >> offer high bit-rate variants of the media o third bullet make sense >> if the policy addresses QoE but I don't think subscriber >> rights/authorizations apply. >> >> Section 10 Security Considerations >> >> Aside from the security considerations WITHIN the uCDN and dCDN, I >> think we can describe this in four contexts: >> >> a. The relationship between the CSP and the uCDN (the principle contract >> arrangement for distribution) >> b. The relationship between the uCDN and dCDN (the transitive trust >> relationship that extends the contract defined in (a) above) c. The >> relationship between the User and dCDN (the recognition of right to >> download predicated on (b) above) d. The relationship between the >> User and CSP (the contract authorizing the user access to the >> content) >> >> The user is not interested in the a-b nor the b-c relationship. The >> user is only interested in the transparency and interoperability of >> the security relationship between d-b or d-c to the point that the >> authorization granted in d-a is viable when the delivery is initiated >> via either d-b or d-c. As an example, the uCDN might use URL >> appended tokens for authentication while dCDN might use URL appended >> hashes. The user doesn't want to know about the distinct methods, >> but transparency is only afforded if the methods are interoperable >> clearly defined when the delegation for content delivery is executed. >> Clearly, the choice of authentication method is determined by the respec= tive CDN's. >> >> Scott >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From alan.kavanagh@ericsson.com Wed Oct 26 12:33:51 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050F111E8089 for ; Wed, 26 Oct 2011 12:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqRAOAsDVxaP for ; Wed, 26 Oct 2011 12:33:49 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE3C11E808A for ; Wed, 26 Oct 2011 12:33:49 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9QJXFI9014217; Wed, 26 Oct 2011 14:33:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.232]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Wed, 26 Oct 2011 15:33:16 -0400 From: Alan Kavanagh To: Ben Niven-Jenkins , ZhouZhipeng Date: Wed, 26 Oct 2011 15:33:15 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyJAiyNegkrXe27RoGmrZGciDGKCQLEijNQ Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> In-Reply-To: <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 19:33:51 -0000 Ben Im assuming then based on your comments below are you suggesting we are goi= ng to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that there i= s some work to be done, but I still feel that content adaptation is to me a= fundamental requirement to what collectively we should address in the CDN-= I WG. I do agree with you that content adaptation is an optimization betwee= n CDN's but it's a very important one that I know Network Service Providers= particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: > Hello Ben, > The UE may select the content format on the CP web. After that the user o= nly desires to get his selected content. > But how the content is transferred to the client is not worried by the us= er. > The CP may create a special format as required by the user and ask the CD= N to deliver to user. > While CP may give a HD format content to uCDN and the dCDN may then trans= form to the format as the user select. Lots of things may be possible to do and CDN providers offer many additiona= l services on top of the "core" service of content delivery. However, our o= bjective (based on my interpretation of the CDNI charter) is to focus on wh= at is necessary to interconnect CDNs to deliver content from a CSP to an En= d User that is targeted and deployable within a short time frame (18-24 mon= ths). Content transformation/adaptation is not an essential requirement in order = to achieve that aim (we can deliver content from CSPs to End Users via mult= iple CDNs without needing or requiring any CDN supports content adaptation)= . In my opinion we have enough work to do already without trying to expand th= e scope of our work to include additional requirements that do not help us = address our core objectives as laid out in the CDNI charter. > In this case, it is nothing related to how the user select formats on CP = website. > So, it is the CP and user to decide the content format not the CDN(your a= ssert is not correct and seems you take that assert as your base for the di= scussion). > > As for "the core CDN functionality offered by CDNs today", I have ever ra= ised an email before that your company's webpage has claimed supporting med= ia transformation and multi-screen service. > Perhaps, I like asking you list some features that you feel are the core = functionalities by existing main stream CDNs. Thus we may compare and take = deep look. I think the core functionality maps pretty well to the CDNI interfaces, nam= ely: Request Routing, Metadata configuration, log production and control pl= us content acquisition and content delivery. > I guess many people have the experience/knowledge of content related serv= ice. The user and CP only care whether the CDN providers may satisfy their = requirement while not care the internal process. Just as GSM/PSTN interconn= ection, the user only care successful interconnection while not care how th= e voice is transformed in process. > > Besides, I like raise a case: > Given currently BBC recruits CDN providers that may support 10 media form= ats. > One candidate is your company, another is CDN-X. The users are located in= France. > So both your company and CDN-X should connect a France CDN provider(CDN-Y= ). > If your company's solution is to send 10 streams of different format > of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CD= N-Y while CDN-Y may conduct some adaptation. > Comparing these two solutions, for your company and CDN-X, absolutely the= cost of CDN-X is much lower. > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in= solution-2, it should only receive 1 stream but need to take transformatio= n to output 10 streams. > > Which solution is more competitive. it is Solution 1, right. Remember the= price from BBC is same to both your company and CDN-X or BBC would select = one CDN provider with the lower price. > If a CDN provider may not get the contract from CP, how it may say it is = not a core functionality. What you are describing is a possible optimization that a particular CDN ma= y wish to implement not a core functionality required to enable content del= ivery between interconnected CDNs. I can think of many optimizations that a= CDN could implement to differentiate their service but the internal workin= gs of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core= function required to enable content delivery between interconnected CDNs a= nd therefore given the workload we already have to specify solutions that d= o address the core functionality required to interconnect CDNs I do not thi= nk we should be trying to add more work into that workload as it will only = distract us from achieving our goal of producing deployable solutions withi= n the timeframe we are being told by operators they needs solutions within. Ben > So, if we all realize that currently the media type is rich, the CDN prov= iders should survive in the existing ecosystem and support the media types = as required by the market. > > Back to the case of GSM/G.711, it just when concerning the interconnectio= n, the transformation should at once be solved. Otherwise the interconnecti= on may not be operated. > > Br, > Zhipeng > > > > > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Wednesday, October 12, 2011 12:19 AM > To: ZhouZhipeng > Cc: philip.eardley@bt.com; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Zhipeng, > > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > >> Ben and Philip, >> I like to respond your concern in this one email: >> >> Ben, >> I feel what we are now discussing is what is the "core" function of CDN. >> As you say, CDN is used to deliver content. That is absolutely correct t= hat the delivery capability is the core requirement for CDN system. >> While CDN is used to provide the content delivery service. >> What means service. It should include "time" "location" and "media type"= , etc. These features are all the core feature for a service. >> If we only concern "delivering one data block", I am not sure whether th= e issues such as "logging" "geographic constraint" are the core of CDN. >> >> For "without explicit knowledge of what that content actually is ", I am= not sure whether the wording is accurate since generally a CDN may claim i= t support different medias. >> By this opportunity, I like to share a use case: a call from a GSM phone= to a PSTN telephone, the voice stream should be transformed from GSM voice= to G.711. >> For the user, he does not need to know what type of data has been transf= erred, but the operator has done some work to interconnect two systems, rig= ht. >> I like to know whether you may accept that my use case is similar to thi= s case above. > > I don't think your use case is similar to the analogy of mobile networks = being interconnected to PSTN networks. In the case of content delivery the = negotiation is done between the User/Client and the Content Provider and th= e CDN is just used to execute/perform the delivery that has been negotiated= . The CDN is not involved in the decision making of what representations th= e Content Provider decides to offer to the User/Client or in what represent= ations the User/Client decides to request. > >> As for you said selecting media by the "portal", you may see the way " u= CDN delivers multiple media streams to dCDN" is not good than "uCDN deliver= s one media stream to dCDN and dCDN takes some adaptation to support multip= le media types". > > Now what you're talking about is an optimisation, not a core function req= uired to actually deliver the content (and report, bill, etc. for that deli= very). > > My position is that we should focus on how to enable the interconnection = of the core CDN functionality offered by CDNs today (which is also my inter= pretation of the scope of the CDNI working group as expressed in its charte= r) because doing so is a significant piece of work in itself. Let's not sta= rt trying to add in additional functionality beyond what the majority of CD= Ns support today as that will just delay us getting usable specifications i= nto the market in a timely fashion IMO. > > Ben > >> A good question is "security" since I have done six years on the DRM >> and like to promote the DRM all around the world:) If the content is nee= ded to be protected, generally you may know all the systems should be grant= ed by the content owner. >> Here I also like to clarify that not only the media itself but the infor= mation related to service itself (such as the geographic constraint) should= be protected also. >> So, trust is not a problem for the media. >> >> Philip, >> Thank you that you feel Content Adaption is an issue for "Requirements" = but I do not know why it is not for Use case. >> I like to clarify to U that it is important for you operator since it ma= y save investment if the system may support different services. >> For us vendor, we are happy operator may install a system for the mobile= service and another system for the FBB service. >> But the reality is all operators ask us to provide a system that may sup= port different service systems. >> >> Frankly, Ben and Philip, I remember I have explained somewhere that to i= mplement this is rather simple . >> At least the Use case and Requirement are informational to be referred i= n future work. So I do really feel you may accept it. >> Of course I like to respond your more concern and comments. >> Thanks. >> Zhipeng >> >> >> >> -----Original Message----- >> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >> Sent: Monday, October 10, 2011 11:22 PM >> To: ben@niven-jenkins.co.uk; ZhouZhipeng >> Cc: cdni@ietf.org >> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> >> Ben, Zhipeng, all, >> >> I think that Content Adaptation is more an issue for the Requirements do= c than for the Use cases draft. >> >> The key question is whether we want the CDNI interfaces to be able to co= pe with a scenario where (say) HD/SD conversion is done in the dCDN & to si= gnal about this. >> >> I think that coping with this scenario is a second order requirement, ie= we should not worry about it in the initial standards-track work. I don't = know, did we ever decide whether the Use cases doc is restricted to "initia= l" scenarios, or whether it's all-encompassing, ie covering "future" scenar= ios as well? >> >> Scott, >> Reading some of your examples, they seem to be valid even if content ada= ptation (HD/SD) is out of scope. >> - a dCDN might for some reason be unwilling to distribute HD? >> - a CSP might want to make sure the dCDN can use HLS encapsulation? >> But these sorts of examples seem to be static policy things (to do >> with the capabilities & preferences of the CDNs & CSP), rather than >> metadata associated with a particular piece of content. In the >> discussion so far, I think negotiation about static policy stuff is >> rather out of scope(?) >> >> On security considerations, an interesting question is whether trust is = transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN= trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. Howev= er, i suspect this can get arbitrarily complex - so one possibility is to s= ay that we will only handle cases where the trust is transitive. >> >> Best wishes >> phil >> >> >> Philip Eardley >> Research and Technology Strategy >> >> This email contains BT information, which may be privileged or confident= ial. It's meant only for the individual(s) or entity named above. If you're= not the intended recipient, note that disclosing, copying, distributing or= using this information is prohibited. If you've received this email in err= or, please let me know immediately on the email address above. Thank you. W= e monitor our email system, and may record your emails. >> British Telecommunications plc >> Registered office: 81 Newgate Street London EC1A 7AJ Registered in >> England no: 1800000 >> >> >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf >> Of Ben Niven-Jenkins >> Sent: 10 October 2011 12:04 >> To: ZhouZhipeng >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> >> Colleagues, >> >> IMO Section 5.1.3 should be removed from the Use Cases draft. Content Ad= aptation (i.e. taking in a content item in one format and transforming it t= o another format or representation) is not a "core" function of a CDN which= typically delivers the content that is requested without explicit knowledg= e of what that content actually is. >> >> Let's not forget that in building an end to end content service the CDN = is only one component and is the component tasked with executing the delive= ry of a specific representation (version/copy/format etc.) of the selected = content not the component tasked with deciding (or applying policy) on whic= h version/copy/representation of content should be delivered. >> >> The decision as to which version/copy/representation to offer and allow = to be delivered to a given device/user is implemented outside of the CDN (e= .g. by the "portal" where the user first makes their content selection prio= r to the CDN becoming involved in the delivery of the selected content). >> >> Ben >> >> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: >> >>> Following Scott's comments on section 5.1.3, I feel Scott's description= on the use case of HD and SD is not exactly correct. >>> If one movie has two formats of HD and SD, then we have two content wit= h different identifier. In DRM scope, the basic unit is a content copy. >>> >>> Here the first bullet "a subset of encodings deliverable to specific de= vices," has listed the case of content adaptation. >>> In last month, I have contacted the Authors of this document and taken = some email exchanges with Grant and Philip (BT). >>> I have shown BT with some information that I know in this case and area= to explain the content flexibility is currently a basic requirement for CD= N service and related negotiation is needed in the CDN interconnection. >>> Meanwhile, I should also invite you in this group raising your comments= or questions on this case since I hope my use case may be incorporated in = the use case draft. >>> >>> If you have any more question or comments, pls share in this thread. >>> Thanks. >>> Zhipeng >>> >>> >>> >>> >>> >>> >>> -----Original Message----- >>> From: Scott Wainner [mailto:swainner@cisco.com] >>> Sent: Friday, September 30, 2011 8:02 AM >>> To: cdni@ietf.org >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>> >>> Section 2.3 Nomadic Users >>> This description falls under the category of Geographic Extension >>> yet the third paragraph states the case where a different device is >>> used in the same CDN coverage area. The intent of this use case >>> needs to be clarified. Perhaps the use case is trying to address >>> the scenario where a Nomadic User-A with an agreement allowing >>> access to content from CSP-A via uCDN moves to a dCDN in a different >>> region. The dCDN is allowed to distribute the content of CSP-A to >>> User-A; however, not other users in the region of the dCDN are >>> allowed to retrieve the content unless they too have such an agreement. >>> >>> Section 5.1.3 Content Encoding Restrictions Need to clarify if we're >>> talking about the restrictions on the delivery of specific content >>> or the restrictions on the ability of a CDN to deliver specific >>> content. I certainly understand the case where a CSP will restrict >>> the distribution of content to a "managed path" if such content is >>> HD while allowing the content distribution via an un-managed path if >>> such content is SD (same could apply to encryption methods, delivery >>> methods, etc.). On the contrary, the dCDN may have its own >>> restrictions of blocking the distribution of HD content while >>> allowing the distribution of SD content. >>> >>> o first bullet makes sense if the dCDN can perform a subset of >>> encapsulations for a reference set of media (e.g. HLS, HSS, but not >>> DASH) o second bullet makes sense where the dCDN doesn't want to >>> offer high bit-rate variants of the media o third bullet make sense >>> if the policy addresses QoE but I don't think subscriber >>> rights/authorizations apply. >>> >>> Section 10 Security Considerations >>> >>> Aside from the security considerations WITHIN the uCDN and dCDN, I >>> think we can describe this in four contexts: >>> >>> a. The relationship between the CSP and the uCDN (the principle contrac= t >>> arrangement for distribution) >>> b. The relationship between the uCDN and dCDN (the transitive trust >>> relationship that extends the contract defined in (a) above) c. The >>> relationship between the User and dCDN (the recognition of right to >>> download predicated on (b) above) d. The relationship between the >>> User and CSP (the contract authorizing the user access to the >>> content) >>> >>> The user is not interested in the a-b nor the b-c relationship. The >>> user is only interested in the transparency and interoperability of >>> the security relationship between d-b or d-c to the point that the >>> authorization granted in d-a is viable when the delivery is >>> initiated via either d-b or d-c. As an example, the uCDN might use >>> URL appended tokens for authentication while dCDN might use URL >>> appended hashes. The user doesn't want to know about the distinct >>> methods, but transparency is only afforded if the methods are >>> interoperable clearly defined when the delegation for content >>> delivery is executed. Clearly, the choice of authentication method is = determined by the respective CDN's. >>> >>> Scott >>> >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From mark@jet-stream.nl Wed Oct 26 13:03:01 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCB911E80AC for ; Wed, 26 Oct 2011 13:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQfSIiR-Drcv for ; Wed, 26 Oct 2011 13:02:58 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id C576311E80A3 for ; Wed, 26 Oct 2011 13:02:57 -0700 (PDT) Received: from [172.20.10.2] (host068-025.kpn-gprs.nl [62.133.68.25]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id p9QK2KhD031162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Oct 2011 22:02:24 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-344--97759596 From: Mark de Jong In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 26 Oct 2011 21:02:20 +0100 Message-Id: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> To: Alan Kavanagh X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:03:01 -0000 --Apple-Mail-344--97759596 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alan, As Ben stated the overall discussion right now is about delivery, not on = adaptation. It is hard enough to get consensus on the delivery aspect = already not to mention your requirement from content adaptation added to = that, so I agree with Ben we should stick with the delivery aspect for = the first specs. I can imagine this could be a discussion later on but = please let us keep the scope of this be clean and transparent. It is of = benefit of everyone to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: > Ben >=20 > Im assuming then based on your comments below are you suggesting we = are going to have a number of versions of the CDN-I Metadata? >=20 > I sympathise with what you are pointing out below and do agree that = there is some work to be done, but I still feel that content adaptation = is to me a fundamental requirement to what collectively we should = address in the CDN-I WG. I do agree with you that content adaptation is = an optimization between CDN's but it's a very important one that I know = Network Service Providers particularly require. >=20 > Alan >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins > Sent: October-12-11 1:13 PM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Zhipeng, >=20 > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: >=20 >> Hello Ben, >> The UE may select the content format on the CP web. After that the = user only desires to get his selected content. >> But how the content is transferred to the client is not worried by = the user. >> The CP may create a special format as required by the user and ask = the CDN to deliver to user. >> While CP may give a HD format content to uCDN and the dCDN may then = transform to the format as the user select. >=20 > Lots of things may be possible to do and CDN providers offer many = additional services on top of the "core" service of content delivery. = However, our objective (based on my interpretation of the CDNI charter) = is to focus on what is necessary to interconnect CDNs to deliver content = from a CSP to an End User that is targeted and deployable within a short = time frame (18-24 months). >=20 > Content transformation/adaptation is not an essential requirement in = order to achieve that aim (we can deliver content from CSPs to End Users = via multiple CDNs without needing or requiring any CDN supports content = adaptation). >=20 > In my opinion we have enough work to do already without trying to = expand the scope of our work to include additional requirements that do = not help us address our core objectives as laid out in the CDNI charter. >=20 >> In this case, it is nothing related to how the user select formats on = CP website. >> So, it is the CP and user to decide the content format not the = CDN(your assert is not correct and seems you take that assert as your = base for the discussion). >>=20 >> As for "the core CDN functionality offered by CDNs today", I have = ever raised an email before that your company's webpage has claimed = supporting media transformation and multi-screen service. >> Perhaps, I like asking you list some features that you feel are the = core functionalities by existing main stream CDNs. Thus we may compare = and take deep look. >=20 > I think the core functionality maps pretty well to the CDNI = interfaces, namely: Request Routing, Metadata configuration, log = production and control plus content acquisition and content delivery. >=20 >> I guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in process. >>=20 >> Besides, I like raise a case: >> Given currently BBC recruits CDN providers that may support 10 media = formats. >> One candidate is your company, another is CDN-X. The users are = located in France. >> So both your company and CDN-X should connect a France CDN = provider(CDN-Y). >> If your company's solution is to send 10 streams of different format >> of one content to CDN-Y; While CDN-X's solution is to send 1 stream = to CDN-Y while CDN-Y may conduct some adaptation. >> Comparing these two solutions, for your company and CDN-X, absolutely = the cost of CDN-X is much lower. >> For CDN-Y, in solution-1, it should receive/forward 10 streams ; = while in solution-2, it should only receive 1 stream but need to take = transformation to output 10 streams. >>=20 >> Which solution is more competitive. it is Solution 1, right. Remember = the price from BBC is same to both your company and CDN-X or BBC would = select one CDN provider with the lower price. >> If a CDN provider may not get the contract from CP, how it may say it = is not a core functionality. >=20 > What you are describing is a possible optimization that a particular = CDN may wish to implement not a core functionality required to enable = content delivery between interconnected CDNs. I can think of many = optimizations that a CDN could implement to differentiate their service = but the internal workings of an individual CDN are out of scope of our = charter. >=20 > So to repeat my position for a final time: Content adaptation is not a = core function required to enable content delivery between interconnected = CDNs and therefore given the workload we already have to specify = solutions that do address the core functionality required to = interconnect CDNs I do not think we should be trying to add more work = into that workload as it will only distract us from achieving our goal = of producing deployable solutions within the timeframe we are being told = by operators they needs solutions within. >=20 > Ben >=20 >> So, if we all realize that currently the media type is rich, the CDN = providers should survive in the existing ecosystem and support the media = types as required by the market. >>=20 >> Back to the case of GSM/G.711, it just when concerning the = interconnection, the transformation should at once be solved. Otherwise = the interconnection may not be operated. >>=20 >> Br, >> Zhipeng >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> Sent: Wednesday, October 12, 2011 12:19 AM >> To: ZhouZhipeng >> Cc: philip.eardley@bt.com; cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >> Zhipeng, >>=20 >> On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: >>=20 >>> Ben and Philip, >>> I like to respond your concern in this one email: >>>=20 >>> Ben, >>> I feel what we are now discussing is what is the "core" function of = CDN. >>> As you say, CDN is used to deliver content. That is absolutely = correct that the delivery capability is the core requirement for CDN = system. >>> While CDN is used to provide the content delivery service. >>> What means service. It should include "time" "location" and "media = type", etc. These features are all the core feature for a service. >>> If we only concern "delivering one data block", I am not sure = whether the issues such as "logging" "geographic constraint" are the = core of CDN. >>>=20 >>> For "without explicit knowledge of what that content actually is ", = I am not sure whether the wording is accurate since generally a CDN may = claim it support different medias. >>> By this opportunity, I like to share a use case: a call from a GSM = phone to a PSTN telephone, the voice stream should be transformed from = GSM voice to G.711. >>> For the user, he does not need to know what type of data has been = transferred, but the operator has done some work to interconnect two = systems, right. >>> I like to know whether you may accept that my use case is similar to = this case above. >>=20 >> I don't think your use case is similar to the analogy of mobile = networks being interconnected to PSTN networks. In the case of content = delivery the negotiation is done between the User/Client and the Content = Provider and the CDN is just used to execute/perform the delivery that = has been negotiated. The CDN is not involved in the decision making of = what representations the Content Provider decides to offer to the = User/Client or in what representations the User/Client decides to = request. >>=20 >>> As for you said selecting media by the "portal", you may see the way = " uCDN delivers multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media types". >>=20 >> Now what you're talking about is an optimisation, not a core function = required to actually deliver the content (and report, bill, etc. for = that delivery). >>=20 >> My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO. >>=20 >> Ben >>=20 >>> A good question is "security" since I have done six years on the DRM >>> and like to promote the DRM all around the world:) If the content is = needed to be protected, generally you may know all the systems should be = granted by the content owner. >>> Here I also like to clarify that not only the media itself but the = information related to service itself (such as the geographic = constraint) should be protected also. >>> So, trust is not a problem for the media. >>>=20 >>> Philip, >>> Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use case. >>> I like to clarify to U that it is important for you operator since = it may save investment if the system may support different services. >>> For us vendor, we are happy operator may install a system for the = mobile service and another system for the FBB service. >>> But the reality is all operators ask us to provide a system that may = support different service systems. >>>=20 >>> Frankly, Ben and Philip, I remember I have explained somewhere that = to implement this is rather simple . >>> At least the Use case and Requirement are informational to be = referred in future work. So I do really feel you may accept it. >>> Of course I like to respond your more concern and comments. >>> Thanks. >>> Zhipeng >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>> Sent: Monday, October 10, 2011 11:22 PM >>> To: ben@niven-jenkins.co.uk; ZhouZhipeng >>> Cc: cdni@ietf.org >>> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>=20 >>> Ben, Zhipeng, all, >>>=20 >>> I think that Content Adaptation is more an issue for the = Requirements doc than for the Use cases draft. >>>=20 >>> The key question is whether we want the CDNI interfaces to be able = to cope with a scenario where (say) HD/SD conversion is done in the dCDN = & to signal about this. >>>=20 >>> I think that coping with this scenario is a second order = requirement, ie we should not worry about it in the initial = standards-track work. I don't know, did we ever decide whether the Use = cases doc is restricted to "initial" scenarios, or whether it's = all-encompassing, ie covering "future" scenarios as well? >>>=20 >>> Scott, >>> Reading some of your examples, they seem to be valid even if content = adaptation (HD/SD) is out of scope. >>> - a dCDN might for some reason be unwilling to distribute HD? >>> - a CSP might want to make sure the dCDN can use HLS encapsulation? >>> But these sorts of examples seem to be static policy things (to do >>> with the capabilities & preferences of the CDNs & CSP), rather than >>> metadata associated with a particular piece of content. In the >>> discussion so far, I think negotiation about static policy stuff is >>> rather out of scope(?) >>>=20 >>> On security considerations, an interesting question is whether trust = is transitive. Don't think it need be - just because CSP trusts uCDN, = and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the = dCDN. However, i suspect this can get arbitrarily complex - so one = possibility is to say that we will only handle cases where the trust is = transitive. >>>=20 >>> Best wishes >>> phil >>>=20 >>>=20 >>> Philip Eardley >>> Research and Technology Strategy >>>=20 >>> This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. >>> British Telecommunications plc >>> Registered office: 81 Newgate Street London EC1A 7AJ Registered in >>> England no: 1800000 >>>=20 >>>=20 >>> -----Original Message----- >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf >>> Of Ben Niven-Jenkins >>> Sent: 10 October 2011 12:04 >>> To: ZhouZhipeng >>> Cc: cdni@ietf.org >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>=20 >>> Colleagues, >>>=20 >>> IMO Section 5.1.3 should be removed from the Use Cases draft. = Content Adaptation (i.e. taking in a content item in one format and = transforming it to another format or representation) is not a "core" = function of a CDN which typically delivers the content that is requested = without explicit knowledge of what that content actually is. >>>=20 >>> Let's not forget that in building an end to end content service the = CDN is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. >>>=20 >>> The decision as to which version/copy/representation to offer and = allow to be delivered to a given device/user is implemented outside of = the CDN (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content). >>>=20 >>> Ben >>>=20 >>> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: >>>=20 >>>> Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. >>>> If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. >>>>=20 >>>> Here the first bullet "a subset of encodings deliverable to = specific devices," has listed the case of content adaptation. >>>> In last month, I have contacted the Authors of this document and = taken some email exchanges with Grant and Philip (BT). >>>> I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. >>>> Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. >>>>=20 >>>> If you have any more question or comments, pls share in this = thread. >>>> Thanks. >>>> Zhipeng >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Scott Wainner [mailto:swainner@cisco.com] >>>> Sent: Friday, September 30, 2011 8:02 AM >>>> To: cdni@ietf.org >>>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>>=20 >>>> Section 2.3 Nomadic Users >>>> This description falls under the category of Geographic Extension >>>> yet the third paragraph states the case where a different device is >>>> used in the same CDN coverage area. The intent of this use case >>>> needs to be clarified. Perhaps the use case is trying to address >>>> the scenario where a Nomadic User-A with an agreement allowing >>>> access to content from CSP-A via uCDN moves to a dCDN in a = different >>>> region. The dCDN is allowed to distribute the content of CSP-A to >>>> User-A; however, not other users in the region of the dCDN are >>>> allowed to retrieve the content unless they too have such an = agreement. >>>>=20 >>>> Section 5.1.3 Content Encoding Restrictions Need to clarify if = we're >>>> talking about the restrictions on the delivery of specific content >>>> or the restrictions on the ability of a CDN to deliver specific >>>> content. I certainly understand the case where a CSP will restrict >>>> the distribution of content to a "managed path" if such content is >>>> HD while allowing the content distribution via an un-managed path = if >>>> such content is SD (same could apply to encryption methods, = delivery >>>> methods, etc.). On the contrary, the dCDN may have its own >>>> restrictions of blocking the distribution of HD content while >>>> allowing the distribution of SD content. >>>>=20 >>>> o first bullet makes sense if the dCDN can perform a subset of >>>> encapsulations for a reference set of media (e.g. HLS, HSS, but not >>>> DASH) o second bullet makes sense where the dCDN doesn't want to >>>> offer high bit-rate variants of the media o third bullet make sense >>>> if the policy addresses QoE but I don't think subscriber >>>> rights/authorizations apply. >>>>=20 >>>> Section 10 Security Considerations >>>>=20 >>>> Aside from the security considerations WITHIN the uCDN and dCDN, I >>>> think we can describe this in four contexts: >>>>=20 >>>> a. The relationship between the CSP and the uCDN (the principle = contract >>>> arrangement for distribution) >>>> b. The relationship between the uCDN and dCDN (the transitive trust >>>> relationship that extends the contract defined in (a) above) c. The >>>> relationship between the User and dCDN (the recognition of right to >>>> download predicated on (b) above) d. The relationship between the >>>> User and CSP (the contract authorizing the user access to the >>>> content) >>>>=20 >>>> The user is not interested in the a-b nor the b-c relationship. The >>>> user is only interested in the transparency and interoperability of >>>> the security relationship between d-b or d-c to the point that the >>>> authorization granted in d-a is viable when the delivery is >>>> initiated via either d-b or d-c. As an example, the uCDN might use >>>> URL appended tokens for authentication while dCDN might use URL >>>> appended hashes. The user doesn't want to know about the distinct >>>> methods, but transparency is only afforded if the methods are >>>> interoperable clearly defined when the delegation for content >>>> delivery is executed. Clearly, the choice of authentication method = is determined by the respective CDN's. >>>>=20 >>>> Scott >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 --Apple-Mail-344--97759596 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Alan,

As Ben stated the overall discussion right now = is about delivery, not on adaptation. It is hard enough to get consensus = on the delivery aspect already not to mention your requirement from = content adaptation added to that, so I agree with Ben we should stick = with the delivery aspect for the first specs. I can imagine this = could be a discussion later on but please let us keep the scope of this = be clean and transparent. It is of benefit of everyone to get the first = specs as fast as possible. Thanks.

mark@jet-stream.com
Office: = +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 = 5264214

- = Event: Meet us at = Streaming Media Europe, 17-18 October, London, = UK
- = Event: Meet us at Online Video Strategies, 19 October, London, = UK
- = Event: Meet us at CDN World Summit, 25-28 October, London, = UK
- News: Pre-request= your Technology Whitepaper now and be the first to have it, check www.jet-stream.com
http://www.jet-stream.com to = download our 'Six Trends in CDNs' brochure
- VideoExchange: www.vdo-x.net
 Streamzilla: www.streamzillacdn.com
- Corporate: www.jet-stream.com

On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote:

Ben

Im assuming then based on your comments = below are you suggesting we are going to have a number of versions of = the CDN-I Metadata?

I sympathise with what you are pointing out = below and do agree that there is some work to be done, but I still feel = that content adaptation is to me a fundamental requirement to what = collectively we should address in the CDN-I WG. I do agree with you that = content adaptation is an optimization between CDN's but it's a very = important one that I know Network Service Providers particularly = require.

Alan

-----Original Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: = October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] = I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On = 12 Oct 2011, at 10:22, ZhouZhipeng wrote:

Hello Ben,
The = UE may select the content format on the CP web. After that the user only = desires to get his selected content.
But how the content is transferred to the client is not = worried by the user.
The CP = may create a special format as required by the user and ask the CDN to = deliver to user.
While CP may = give a HD format content to uCDN and the dCDN may then transform to the = format as the user select.

Lots of things may be = possible to do and CDN providers offer many additional services on top = of the "core" service of content delivery. However, our objective (based = on my interpretation of the CDNI charter) is to focus on what is = necessary to interconnect CDNs to deliver content from a CSP to an End = User that is targeted and deployable within a short time frame (18-24 = months).

Content transformation/adaptation is not an essential = requirement in order to achieve that aim (we can deliver content from = CSPs to End Users via multiple CDNs without needing or requiring any CDN = supports content adaptation).

In my opinion we have enough work = to do already without trying to expand the scope of our work to include = additional requirements that do not help us address our core objectives = as laid out in the CDNI charter.

In = this case, it is nothing related to how the user select formats on CP = website.
So, it is the CP and = user to decide the content format not the CDN(your assert is not correct = and seems you take that assert as your base for the = discussion).

As for "the = core CDN functionality offered by CDNs today", I have ever raised an = email before that your company's webpage has claimed supporting media = transformation and multi-screen service.
Perhaps, I like asking you list some features that you = feel are the core functionalities by existing main stream CDNs. Thus we = may compare and take deep look.

I think the core = functionality maps pretty well to the CDNI interfaces, namely: Request = Routing, Metadata configuration, log production and control plus content = acquisition and content delivery.

I = guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in = process.

Besides, I like = raise a case:
Given currently = BBC recruits CDN providers that may support 10 media = formats.
One candidate is your = company, another is CDN-X. The users are located in = France.
So both your company = and CDN-X should connect a France CDN = provider(CDN-Y).
If your = company's solution is to send 10 streams of different = format
of one content to = CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y = may conduct some adaptation.
Comparing these two solutions, for your company and CDN-X, = absolutely the cost of CDN-X is much lower.
For CDN-Y, in solution-1, it should receive/forward 10 = streams ; while in solution-2, it should only receive 1 stream but need = to take transformation to output 10 streams.

Which solution = is more competitive. it is Solution 1, right. Remember the price from = BBC is same to both your company and CDN-X or BBC would select one CDN = provider with the lower price.
If a CDN provider may not get the contract from CP, how it = may say it is not a core functionality.

What you are = describing is a possible optimization that a particular CDN may wish to = implement not a core functionality required to enable content delivery = between interconnected CDNs. I can think of many optimizations that a = CDN could implement to differentiate their service but the internal = workings of an individual CDN are out of scope of our charter.

So = to repeat my position for a final time: Content adaptation is not a core = function required to enable content delivery between interconnected CDNs = and therefore given the workload we already have to specify solutions = that do address the core functionality required to interconnect CDNs I = do not think we should be trying to add more work into that workload as = it will only distract us from achieving our goal of producing deployable = solutions within the timeframe we are being told by operators they needs = solutions within.

Ben

So, if we = all realize that currently the media type is rich, the CDN providers = should survive in the existing ecosystem and support the media types as = required by the market.

Back to the = case of GSM/G.711, it just when concerning the interconnection, the = transformation should at once be solved. Otherwise the interconnection = may not be operated.

Br,
Zhipeng




-----Original = Message-----
From: Ben = Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]
Sent: Wednesday, October 12, 2011 12:19 = AM
To: = ZhouZhipeng
Cc: philip.eardley@bt.com; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 11 Oct 2011, = at 05:16, ZhouZhipeng wrote:

Ben and Philip,
I like to respond your concern = in this one email:

Ben,
I feel what we are now = discussing is what is the "core" function of = CDN.
As you say, CDN is used to deliver content. That is = absolutely correct that the delivery capability is the core requirement = for CDN system.
While CDN is used to provide the = content delivery service.
What means service. It should = include "time" "location" and "media type", etc. These features are all = the core feature for a service.
If we only concern "delivering = one data block", I am not sure whether the issues such as "logging" = "geographic constraint" are the core of = CDN.

For "without explicit knowledge = of what that content actually is ", I am not sure whether the wording is = accurate since generally a CDN may claim it support different = medias.
By this opportunity, I like to share a use case: a call = from a GSM phone to a PSTN telephone, the voice stream should be = transformed from GSM voice to = G.711.
For the user, he does not need to know what type of data = has been transferred, but the operator has done some work to = interconnect two systems, = right.
I like to know whether you may accept that my use case is = similar to this case above.

I don't think = your use case is similar to the analogy of mobile networks being = interconnected to PSTN networks. In the case of content delivery the = negotiation is done between the User/Client and the Content Provider and = the CDN is just used to execute/perform the delivery that has been = negotiated. The CDN is not involved in the decision making of what = representations the Content Provider decides to offer to the User/Client = or in what representations the User/Client decides to = request.

As for you said selecting media by the "portal", you may = see the way " uCDN delivers multiple media streams to dCDN" is not good = than "uCDN delivers one media stream to dCDN and dCDN takes some = adaptation to support multiple media = types".

Now what you're = talking about is an optimisation, not a core function required to = actually deliver the content (and report, bill, etc. for that = delivery).

My position is = that we should focus on how to enable the interconnection of the core = CDN functionality offered by CDNs today (which is also my interpretation = of the scope of the CDNI working group as expressed in its charter) = because doing so is a significant piece of work in itself. Let's not = start trying to add in additional functionality beyond what the majority = of CDNs support today as that will just delay us getting usable = specifications into the market in a timely fashion = IMO.

Ben

A good question is "security" since I have done six years = on the DRM
and like to promote the DRM all = around the world:) If the content is needed to be protected, generally = you may know all the systems should be granted by the content = owner.
Here I also like to clarify that not only the media itself = but the information related to service itself (such as the geographic = constraint) should be protected = also.
So, trust is not a problem for the = media.

Philip,
Thank you that you feel Content = Adaption is an issue for "Requirements" but I do not know why it is not = for Use case.
I like to clarify to U that it = is important for you operator since it may save investment if the system = may support different services.
For us vendor, we are happy = operator may install a system for the mobile service and another system = for the FBB service.
But the reality is all operators = ask us to provide a system that may support different service = systems.

Frankly, Ben and Philip, I = remember I have explained somewhere that to implement this is rather = simple .
At least the Use case and = Requirement are informational to be referred in future work. So I do = really feel you may accept it.
Of course I like to respond your = more concern and comments.
Thanks.
Zhipeng



-----Original = Message-----
From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]
Sent: Monday, October 10, 2011 = 11:22 PM
To: ben@niven-jenkins.co.uk; = ZhouZhipeng
Cc: cdni@ietf.org
Subject: RE: = [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, = all,

I think that Content Adaptation = is more an issue for the Requirements doc than for the Use cases = draft.

The key question is whether we = want the CDNI interfaces to be able to cope with a scenario where (say) = HD/SD conversion is done in the dCDN & to signal about = this.

I think that coping with this = scenario is a second order requirement, ie we should not worry about it = in the initial standards-track work. I don't know, did we ever decide = whether the Use cases doc is restricted to "initial" scenarios, or = whether it's all-encompassing, ie covering "future" scenarios as = well?

Scott,
Reading some of your examples, = they seem to be valid even if content adaptation (HD/SD) is out of = scope.
- a dCDN might for some reason be unwilling to distribute = HD?
- a CSP might want to make sure the dCDN can use HLS = encapsulation?
But these sorts of examples seem = to be static policy things (to = do
with the capabilities & preferences of the CDNs & = CSP), rather than
metadata associated with a = particular piece of content. In = the
discussion so far, I think negotiation about static policy = stuff is
rather out of = scope(?)

On security considerations, an = interesting question is whether trust is transitive. Don't think it need = be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean = that the CSP automatically trusts the dCDN. However, i suspect this can = get arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.

Best = wishes
phil


Philip = Eardley
Research and Technology = Strategy

This email contains BT = information, which may be privileged or confidential. It's meant only = for the individual(s) or entity named above. If you're not the intended = recipient, note that disclosing, copying, distributing or using this = information is prohibited. If you've received this email in error, = please let me know immediately on the email address above. Thank you. We = monitor our email system, and may record your = emails.
British Telecommunications = plc
Registered office: 81 Newgate Street London EC1A 7AJ = Registered in
England no: = 1800000


-----Original = Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On = Behalf
Of Ben = Niven-Jenkins
Sent: 10 October 2011 = 12:04
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: = [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Colleagues,

IMO Section 5.1.3 should be = removed from the Use Cases draft. Content Adaptation (i.e. taking in a = content item in one format and transforming it to another format or = representation) is not a "core" function of a CDN which typically = delivers the content that is requested without explicit knowledge of = what that content actually is.

Let's not forget that in = building an end to end content service the CDN is only one component and = is the component tasked with executing the delivery of a specific = representation (version/copy/format etc.) of the selected content not = the component tasked with deciding (or applying policy) on which = version/copy/representation of content should be = delivered.

The decision as to which = version/copy/representation to offer and allow to be delivered to a = given device/user is implemented outside of the CDN (e.g. by the = "portal" where the user first makes their content selection prior to the = CDN becoming involved in the delivery of the selected = content).

Ben

On 8 Oct 2011, at 08:20, = ZhouZhipeng wrote:

Following Scott's comments on section 5.1.3, I feel = Scott's description on the use case of HD and SD is not exactly = correct.
If one = movie has two formats of HD and SD, then we have two content with = different identifier. In DRM scope, the basic unit is a content = copy.

Here = the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content = adaptation.
In = last month, I have contacted the Authors of this document and taken some = email exchanges with Grant and Philip = (BT).
I have = shown BT with some information that I know in this case and area to = explain the content flexibility is currently a basic requirement for CDN = service and related negotiation is needed in the CDN = interconnection.
Meanwhile, I should also invite you in this group raising = your comments or questions on this case since I hope my use case may be = incorporated in the use case = draft.

If you = have any more question or comments, pls share in this = thread.
Thanks.
Zhipeng






-----Original = Message-----
From: = Scott Wainner = [mailto:swainner@cisco.com]
Sent: Friday, September 30, 2011 8:02 = AM
To: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Section = 2.3 Nomadic Users
This = description falls under the category of Geographic = Extension
yet = the third paragraph states the case where a different device = is
used = in the same CDN coverage area.  The intent of this use = case
needs = to be clarified.  Perhaps the use case is trying to = address
the = scenario where a Nomadic User-A with an agreement = allowing
access = to content from CSP-A via uCDN moves to a dCDN in a = different
region. =  The dCDN is allowed to distribute the content of CSP-A = to
User-A; = however, not other users in the region of the dCDN = are
allowed = to retrieve the content unless they too have such an = agreement.

Section = 5.1.3 Content Encoding Restrictions Need to clarify if = we're
talking = about the restrictions on the delivery of specific = content
or the = restrictions on the ability of a CDN to deliver = specific
content.=  I certainly understand the case where a CSP will = restrict
the = distribution of content to a "managed path" if such content = is
HD = while allowing the content distribution via an un-managed path = if
such = content is SD (same could apply to encryption methods, = delivery
methods,= etc.).  On the contrary, the dCDN may have its = own
restrictions of blocking the distribution of HD content = while
allowing= the distribution of SD = content.

o = first bullet makes sense if the dCDN can perform a subset = of
encapsulations for a reference set of media (e.g. HLS, = HSS, but not
DASH) = o second bullet makes sense where the dCDN doesn't want = to
offer = high bit-rate variants of the media o third bullet make = sense
if the = policy addresses QoE but I don't think = subscriber
rights/authorizations = apply.

Section = 10 Security = Considerations

Aside = from the security considerations WITHIN the uCDN and dCDN, = I
think = we can describe this in four = contexts:

a. The = relationship between the CSP and the uCDN (the principle = contract
arrangement for = distribution)
b. The = relationship between the uCDN and dCDN (the transitive = trust
relationship that extends the contract defined in (a) = above) c. The
relationship between the User and dCDN (the recognition of = right to
download= predicated on (b) above) d. The relationship between = the
User = and CSP (the contract authorizing the user access to = the
content)

The = user is not interested in the a-b nor the b-c relationship. = The
user = is only interested in the transparency and interoperability = of
the = security relationship between d-b or d-c to the point that = the
authorization granted in d-a is viable when the delivery = is
initiated via either d-b or d-c.  As an example, the = uCDN might use
URL = appended tokens for authentication while dCDN might use = URL
appended= hashes.  The user doesn't want to know about the = distinct
methods,= but transparency is only afforded if the methods = are
interoperable clearly defined when the delegation for = content
delivery= is executed.  Clearly, the choice of authentication method is = determined by the respective = CDN's.

Scott

_______________________________________________
CDNi mailing = list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni

_______________________________________________
CDNi = mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni


_______________________________________= ________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni
_______________________________________________
= CDNi mailing = list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

= --Apple-Mail-344--97759596-- From mark@jet-stream.nl Wed Oct 26 13:21:44 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF301F0C3D for ; Wed, 26 Oct 2011 13:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVyleHsx4ajd for ; Wed, 26 Oct 2011 13:21:42 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id 6176C1F0C3B for ; Wed, 26 Oct 2011 13:21:41 -0700 (PDT) Received: from [172.20.10.2] (host068-010.kpn-gprs.nl [62.133.68.10]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id p9QKLDHd021352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Oct 2011 22:21:16 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-359--96687033 From: Mark de Jong In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 26 Oct 2011 21:20:12 +0100 Message-Id: <0420F22C-4D04-43B7-8ADB-C238850F2B76@jet-stream.nl> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> To: Alan Kavanagh X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:21:45 -0000 --Apple-Mail-359--96687033 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alan, As Ben stated the overall discussion right now is about delivery, not on = adaptation. It is hard enough to get consensus on the delivery aspect = already not to mention your requirement from content adaptation added to = that, so I agree with Ben we should stick with the delivery aspect for = the first specs. I can imagine this could be a discussion later on but = please let us keep the scope of this be clean and transparent. It is of = benefit of everyone to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: > Ben >=20 > Im assuming then based on your comments below are you suggesting we = are going to have a number of versions of the CDN-I Metadata? >=20 > I sympathise with what you are pointing out below and do agree that = there is some work to be done, but I still feel that content adaptation = is to me a fundamental requirement to what collectively we should = address in the CDN-I WG. I do agree with you that content adaptation is = an optimization between CDN's but it's a very important one that I know = Network Service Providers particularly require. >=20 > Alan >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins > Sent: October-12-11 1:13 PM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Zhipeng, >=20 > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: >=20 >> Hello Ben, >> The UE may select the content format on the CP web. After that the = user only desires to get his selected content. >> But how the content is transferred to the client is not worried by = the user. >> The CP may create a special format as required by the user and ask = the CDN to deliver to user. >> While CP may give a HD format content to uCDN and the dCDN may then = transform to the format as the user select. >=20 > Lots of things may be possible to do and CDN providers offer many = additional services on top of the "core" service of content delivery. = However, our objective (based on my interpretation of the CDNI charter) = is to focus on what is necessary to interconnect CDNs to deliver content = from a CSP to an End User that is targeted and deployable within a short = time frame (18-24 months). >=20 > Content transformation/adaptation is not an essential requirement in = order to achieve that aim (we can deliver content from CSPs to End Users = via multiple CDNs without needing or requiring any CDN supports content = adaptation). >=20 > In my opinion we have enough work to do already without trying to = expand the scope of our work to include additional requirements that do = not help us address our core objectives as laid out in the CDNI charter. >=20 >> In this case, it is nothing related to how the user select formats on = CP website. >> So, it is the CP and user to decide the content format not the = CDN(your assert is not correct and seems you take that assert as your = base for the discussion). >>=20 >> As for "the core CDN functionality offered by CDNs today", I have = ever raised an email before that your company's webpage has claimed = supporting media transformation and multi-screen service. >> Perhaps, I like asking you list some features that you feel are the = core functionalities by existing main stream CDNs. Thus we may compare = and take deep look. >=20 > I think the core functionality maps pretty well to the CDNI = interfaces, namely: Request Routing, Metadata configuration, log = production and control plus content acquisition and content delivery. >=20 >> I guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in process. >>=20 >> Besides, I like raise a case: >> Given currently BBC recruits CDN providers that may support 10 media = formats. >> One candidate is your company, another is CDN-X. The users are = located in France. >> So both your company and CDN-X should connect a France CDN = provider(CDN-Y). >> If your company's solution is to send 10 streams of different format >> of one content to CDN-Y; While CDN-X's solution is to send 1 stream = to CDN-Y while CDN-Y may conduct some adaptation. >> Comparing these two solutions, for your company and CDN-X, absolutely = the cost of CDN-X is much lower. >> For CDN-Y, in solution-1, it should receive/forward 10 streams ; = while in solution-2, it should only receive 1 stream but need to take = transformation to output 10 streams. >>=20 >> Which solution is more competitive. it is Solution 1, right. Remember = the price from BBC is same to both your company and CDN-X or BBC would = select one CDN provider with the lower price. >> If a CDN provider may not get the contract from CP, how it may say it = is not a core functionality. >=20 > What you are describing is a possible optimization that a particular = CDN may wish to implement not a core functionality required to enable = content delivery between interconnected CDNs. I can think of many = optimizations that a CDN could implement to differentiate their service = but the internal workings of an individual CDN are out of scope of our = charter. >=20 > So to repeat my position for a final time: Content adaptation is not a = core function required to enable content delivery between interconnected = CDNs and therefore given the workload we already have to specify = solutions that do address the core functionality required to = interconnect CDNs I do not think we should be trying to add more work = into that workload as it will only distract us from achieving our goal = of producing deployable solutions within the timeframe we are being told = by operators they needs solutions within. >=20 > Ben >=20 >> So, if we all realize that currently the media type is rich, the CDN = providers should survive in the existing ecosystem and support the media = types as required by the market. >>=20 >> Back to the case of GSM/G.711, it just when concerning the = interconnection, the transformation should at once be solved. Otherwise = the interconnection may not be operated. >>=20 >> Br, >> Zhipeng >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> Sent: Wednesday, October 12, 2011 12:19 AM >> To: ZhouZhipeng >> Cc: philip.eardley@bt.com; cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >> Zhipeng, >>=20 >> On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: >>=20 >>> Ben and Philip, >>> I like to respond your concern in this one email: >>>=20 >>> Ben, >>> I feel what we are now discussing is what is the "core" function of = CDN. >>> As you say, CDN is used to deliver content. That is absolutely = correct that the delivery capability is the core requirement for CDN = system. >>> While CDN is used to provide the content delivery service. >>> What means service. It should include "time" "location" and "media = type", etc. These features are all the core feature for a service. >>> If we only concern "delivering one data block", I am not sure = whether the issues such as "logging" "geographic constraint" are the = core of CDN. >>>=20 >>> For "without explicit knowledge of what that content actually is ", = I am not sure whether the wording is accurate since generally a CDN may = claim it support different medias. >>> By this opportunity, I like to share a use case: a call from a GSM = phone to a PSTN telephone, the voice stream should be transformed from = GSM voice to G.711. >>> For the user, he does not need to know what type of data has been = transferred, but the operator has done some work to interconnect two = systems, right. >>> I like to know whether you may accept that my use case is similar to = this case above. >>=20 >> I don't think your use case is similar to the analogy of mobile = networks being interconnected to PSTN networks. In the case of content = delivery the negotiation is done between the User/Client and the Content = Provider and the CDN is just used to execute/perform the delivery that = has been negotiated. The CDN is not involved in the decision making of = what representations the Content Provider decides to offer to the = User/Client or in what representations the User/Client decides to = request. >>=20 >>> As for you said selecting media by the "portal", you may see the way = " uCDN delivers multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media types". >>=20 >> Now what you're talking about is an optimisation, not a core function = required to actually deliver the content (and report, bill, etc. for = that delivery). >>=20 >> My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO. >>=20 >> Ben >>=20 >>> A good question is "security" since I have done six years on the DRM >>> and like to promote the DRM all around the world:) If the content is = needed to be protected, generally you may know all the systems should be = granted by the content owner. >>> Here I also like to clarify that not only the media itself but the = information related to service itself (such as the geographic = constraint) should be protected also. >>> So, trust is not a problem for the media. >>>=20 >>> Philip, >>> Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use case. >>> I like to clarify to U that it is important for you operator since = it may save investment if the system may support different services. >>> For us vendor, we are happy operator may install a system for the = mobile service and another system for the FBB service. >>> But the reality is all operators ask us to provide a system that may = support different service systems. >>>=20 >>> Frankly, Ben and Philip, I remember I have explained somewhere that = to implement this is rather simple . >>> At least the Use case and Requirement are informational to be = referred in future work. So I do really feel you may accept it. >>> Of course I like to respond your more concern and comments. >>> Thanks. >>> Zhipeng >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>> Sent: Monday, October 10, 2011 11:22 PM >>> To: ben@niven-jenkins.co.uk; ZhouZhipeng >>> Cc: cdni@ietf.org >>> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>=20 >>> Ben, Zhipeng, all, >>>=20 >>> I think that Content Adaptation is more an issue for the = Requirements doc than for the Use cases draft. >>>=20 >>> The key question is whether we want the CDNI interfaces to be able = to cope with a scenario where (say) HD/SD conversion is done in the dCDN = & to signal about this. >>>=20 >>> I think that coping with this scenario is a second order = requirement, ie we should not worry about it in the initial = standards-track work. I don't know, did we ever decide whether the Use = cases doc is restricted to "initial" scenarios, or whether it's = all-encompassing, ie covering "future" scenarios as well? >>>=20 >>> Scott, >>> Reading some of your examples, they seem to be valid even if content = adaptation (HD/SD) is out of scope. >>> - a dCDN might for some reason be unwilling to distribute HD? >>> - a CSP might want to make sure the dCDN can use HLS encapsulation? >>> But these sorts of examples seem to be static policy things (to do >>> with the capabilities & preferences of the CDNs & CSP), rather than >>> metadata associated with a particular piece of content. In the >>> discussion so far, I think negotiation about static policy stuff is >>> rather out of scope(?) >>>=20 >>> On security considerations, an interesting question is whether trust = is transitive. Don't think it need be - just because CSP trusts uCDN, = and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the = dCDN. However, i suspect this can get arbitrarily complex - so one = possibility is to say that we will only handle cases where the trust is = transitive. >>>=20 >>> Best wishes >>> phil >>>=20 >>>=20 >>> Philip Eardley >>> Research and Technology Strategy >>>=20 >>> This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. >>> British Telecommunications plc >>> Registered office: 81 Newgate Street London EC1A 7AJ Registered in >>> England no: 1800000 >>>=20 >>>=20 >>> -----Original Message----- >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf >>> Of Ben Niven-Jenkins >>> Sent: 10 October 2011 12:04 >>> To: ZhouZhipeng >>> Cc: cdni@ietf.org >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>=20 >>> Colleagues, >>>=20 >>> IMO Section 5.1.3 should be removed from the Use Cases draft. = Content Adaptation (i.e. taking in a content item in one format and = transforming it to another format or representation) is not a "core" = function of a CDN which typically delivers the content that is requested = without explicit knowledge of what that content actually is. >>>=20 >>> Let's not forget that in building an end to end content service the = CDN is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. >>>=20 >>> The decision as to which version/copy/representation to offer and = allow to be delivered to a given device/user is implemented outside of = the CDN (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content). >>>=20 >>> Ben >>>=20 >>> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: >>>=20 >>>> Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. >>>> If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. >>>>=20 >>>> Here the first bullet "a subset of encodings deliverable to = specific devices," has listed the case of content adaptation. >>>> In last month, I have contacted the Authors of this document and = taken some email exchanges with Grant and Philip (BT). >>>> I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. >>>> Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. >>>>=20 >>>> If you have any more question or comments, pls share in this = thread. >>>> Thanks. >>>> Zhipeng >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Scott Wainner [mailto:swainner@cisco.com] >>>> Sent: Friday, September 30, 2011 8:02 AM >>>> To: cdni@ietf.org >>>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>>=20 >>>> Section 2.3 Nomadic Users >>>> This description falls under the category of Geographic Extension >>>> yet the third paragraph states the case where a different device is >>>> used in the same CDN coverage area. The intent of this use case >>>> needs to be clarified. Perhaps the use case is trying to address >>>> the scenario where a Nomadic User-A with an agreement allowing >>>> access to content from CSP-A via uCDN moves to a dCDN in a = different >>>> region. The dCDN is allowed to distribute the content of CSP-A to >>>> User-A; however, not other users in the region of the dCDN are >>>> allowed to retrieve the content unless they too have such an = agreement. >>>>=20 >>>> Section 5.1.3 Content Encoding Restrictions Need to clarify if = we're >>>> talking about the restrictions on the delivery of specific content >>>> or the restrictions on the ability of a CDN to deliver specific >>>> content. I certainly understand the case where a CSP will restrict >>>> the distribution of content to a "managed path" if such content is >>>> HD while allowing the content distribution via an un-managed path = if >>>> such content is SD (same could apply to encryption methods, = delivery >>>> methods, etc.). On the contrary, the dCDN may have its own >>>> restrictions of blocking the distribution of HD content while >>>> allowing the distribution of SD content. >>>>=20 >>>> o first bullet makes sense if the dCDN can perform a subset of >>>> encapsulations for a reference set of media (e.g. HLS, HSS, but not >>>> DASH) o second bullet makes sense where the dCDN doesn't want to >>>> offer high bit-rate variants of the media o third bullet make sense >>>> if the policy addresses QoE but I don't think subscriber >>>> rights/authorizations apply. >>>>=20 >>>> Section 10 Security Considerations >>>>=20 >>>> Aside from the security considerations WITHIN the uCDN and dCDN, I >>>> think we can describe this in four contexts: >>>>=20 >>>> a. The relationship between the CSP and the uCDN (the principle = contract >>>> arrangement for distribution) >>>> b. The relationship between the uCDN and dCDN (the transitive trust >>>> relationship that extends the contract defined in (a) above) c. The >>>> relationship between the User and dCDN (the recognition of right to >>>> download predicated on (b) above) d. The relationship between the >>>> User and CSP (the contract authorizing the user access to the >>>> content) >>>>=20 >>>> The user is not interested in the a-b nor the b-c relationship. The >>>> user is only interested in the transparency and interoperability of >>>> the security relationship between d-b or d-c to the point that the >>>> authorization granted in d-a is viable when the delivery is >>>> initiated via either d-b or d-c. As an example, the uCDN might use >>>> URL appended tokens for authentication while dCDN might use URL >>>> appended hashes. The user doesn't want to know about the distinct >>>> methods, but transparency is only afforded if the methods are >>>> interoperable clearly defined when the delegation for content >>>> delivery is executed. Clearly, the choice of authentication method = is determined by the respective CDN's. >>>>=20 >>>> Scott >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 --Apple-Mail-359--96687033 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Alan,

As Ben stated the overall discussion right now = is about delivery, not on adaptation. It is hard enough to get consensus = on the delivery aspect already not to mention your requirement from = content adaptation added to that, so I agree with Ben we should stick = with the delivery aspect for the first specs. I can imagine this = could be a discussion later on but please let us keep the scope of this = be clean and transparent. It is of benefit of everyone to get the first = specs as fast as possible. Thanks.

mark@jet-stream.com
Office: = +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 = 5264214

- = Event: Meet us at = Streaming Media Europe, 17-18 October, London, = UK
- = Event: Meet us at Online Video Strategies, 19 October, London, = UK
- = Event: Meet us at CDN World Summit, 25-28 October, London, = UK
- News: Pre-request= your Technology Whitepaper now and be the first to have it, check www.jet-stream.com
http://www.jet-stream.com to = download our 'Six Trends in CDNs' brochure
- VideoExchange: www.vdo-x.net
 Streamzilla: www.streamzillacdn.com
- Corporate: www.jet-stream.com

On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote:

Ben

Im assuming then based on your comments = below are you suggesting we are going to have a number of versions of = the CDN-I Metadata?

I sympathise with what you are pointing out = below and do agree that there is some work to be done, but I still feel = that content adaptation is to me a fundamental requirement to what = collectively we should address in the CDN-I WG. I do agree with you that = content adaptation is an optimization between CDN's but it's a very = important one that I know Network Service Providers particularly = require.

Alan

-----Original Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: = October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] = I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On = 12 Oct 2011, at 10:22, ZhouZhipeng wrote:

Hello Ben,
The = UE may select the content format on the CP web. After that the user only = desires to get his selected content.
But how the content is transferred to the client is not = worried by the user.
The CP = may create a special format as required by the user and ask the CDN to = deliver to user.
While CP may = give a HD format content to uCDN and the dCDN may then transform to the = format as the user select.

Lots of things may be = possible to do and CDN providers offer many additional services on top = of the "core" service of content delivery. However, our objective (based = on my interpretation of the CDNI charter) is to focus on what is = necessary to interconnect CDNs to deliver content from a CSP to an End = User that is targeted and deployable within a short time frame (18-24 = months).

Content transformation/adaptation is not an essential = requirement in order to achieve that aim (we can deliver content from = CSPs to End Users via multiple CDNs without needing or requiring any CDN = supports content adaptation).

In my opinion we have enough work = to do already without trying to expand the scope of our work to include = additional requirements that do not help us address our core objectives = as laid out in the CDNI charter.

In = this case, it is nothing related to how the user select formats on CP = website.
So, it is the CP and = user to decide the content format not the CDN(your assert is not correct = and seems you take that assert as your base for the = discussion).

As for "the = core CDN functionality offered by CDNs today", I have ever raised an = email before that your company's webpage has claimed supporting media = transformation and multi-screen service.
Perhaps, I like asking you list some features that you = feel are the core functionalities by existing main stream CDNs. Thus we = may compare and take deep look.

I think the core = functionality maps pretty well to the CDNI interfaces, namely: Request = Routing, Metadata configuration, log production and control plus content = acquisition and content delivery.

I = guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in = process.

Besides, I like = raise a case:
Given currently = BBC recruits CDN providers that may support 10 media = formats.
One candidate is your = company, another is CDN-X. The users are located in = France.
So both your company = and CDN-X should connect a France CDN = provider(CDN-Y).
If your = company's solution is to send 10 streams of different = format
of one content to = CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y = may conduct some adaptation.
Comparing these two solutions, for your company and CDN-X, = absolutely the cost of CDN-X is much lower.
For CDN-Y, in solution-1, it should receive/forward 10 = streams ; while in solution-2, it should only receive 1 stream but need = to take transformation to output 10 streams.

Which solution = is more competitive. it is Solution 1, right. Remember the price from = BBC is same to both your company and CDN-X or BBC would select one CDN = provider with the lower price.
If a CDN provider may not get the contract from CP, how it = may say it is not a core functionality.

What you are = describing is a possible optimization that a particular CDN may wish to = implement not a core functionality required to enable content delivery = between interconnected CDNs. I can think of many optimizations that a = CDN could implement to differentiate their service but the internal = workings of an individual CDN are out of scope of our charter.

So = to repeat my position for a final time: Content adaptation is not a core = function required to enable content delivery between interconnected CDNs = and therefore given the workload we already have to specify solutions = that do address the core functionality required to interconnect CDNs I = do not think we should be trying to add more work into that workload as = it will only distract us from achieving our goal of producing deployable = solutions within the timeframe we are being told by operators they needs = solutions within.

Ben

So, if we = all realize that currently the media type is rich, the CDN providers = should survive in the existing ecosystem and support the media types as = required by the market.

Back to the = case of GSM/G.711, it just when concerning the interconnection, the = transformation should at once be solved. Otherwise the interconnection = may not be operated.

Br,
Zhipeng




-----Original = Message-----
From: Ben = Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]
Sent: Wednesday, October 12, 2011 12:19 = AM
To: = ZhouZhipeng
Cc: philip.eardley@bt.com; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 11 Oct 2011, = at 05:16, ZhouZhipeng wrote:

Ben and Philip,
I like to respond your concern = in this one email:

Ben,
I feel what we are now = discussing is what is the "core" function of = CDN.
As you say, CDN is used to deliver content. That is = absolutely correct that the delivery capability is the core requirement = for CDN system.
While CDN is used to provide the = content delivery service.
What means service. It should = include "time" "location" and "media type", etc. These features are all = the core feature for a service.
If we only concern "delivering = one data block", I am not sure whether the issues such as "logging" = "geographic constraint" are the core of = CDN.

For "without explicit knowledge = of what that content actually is ", I am not sure whether the wording is = accurate since generally a CDN may claim it support different = medias.
By this opportunity, I like to share a use case: a call = from a GSM phone to a PSTN telephone, the voice stream should be = transformed from GSM voice to = G.711.
For the user, he does not need to know what type of data = has been transferred, but the operator has done some work to = interconnect two systems, = right.
I like to know whether you may accept that my use case is = similar to this case above.

I don't think = your use case is similar to the analogy of mobile networks being = interconnected to PSTN networks. In the case of content delivery the = negotiation is done between the User/Client and the Content Provider and = the CDN is just used to execute/perform the delivery that has been = negotiated. The CDN is not involved in the decision making of what = representations the Content Provider decides to offer to the User/Client = or in what representations the User/Client decides to = request.

As for you said selecting media by the "portal", you may = see the way " uCDN delivers multiple media streams to dCDN" is not good = than "uCDN delivers one media stream to dCDN and dCDN takes some = adaptation to support multiple media = types".

Now what you're = talking about is an optimisation, not a core function required to = actually deliver the content (and report, bill, etc. for that = delivery).

My position is = that we should focus on how to enable the interconnection of the core = CDN functionality offered by CDNs today (which is also my interpretation = of the scope of the CDNI working group as expressed in its charter) = because doing so is a significant piece of work in itself. Let's not = start trying to add in additional functionality beyond what the majority = of CDNs support today as that will just delay us getting usable = specifications into the market in a timely fashion = IMO.

Ben

A good question is "security" since I have done six years = on the DRM
and like to promote the DRM all = around the world:) If the content is needed to be protected, generally = you may know all the systems should be granted by the content = owner.
Here I also like to clarify that not only the media itself = but the information related to service itself (such as the geographic = constraint) should be protected = also.
So, trust is not a problem for the = media.

Philip,
Thank you that you feel Content = Adaption is an issue for "Requirements" but I do not know why it is not = for Use case.
I like to clarify to U that it = is important for you operator since it may save investment if the system = may support different services.
For us vendor, we are happy = operator may install a system for the mobile service and another system = for the FBB service.
But the reality is all operators = ask us to provide a system that may support different service = systems.

Frankly, Ben and Philip, I = remember I have explained somewhere that to implement this is rather = simple .
At least the Use case and = Requirement are informational to be referred in future work. So I do = really feel you may accept it.
Of course I like to respond your = more concern and comments.
Thanks.
Zhipeng



-----Original = Message-----
From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]
Sent: Monday, October 10, 2011 = 11:22 PM
To: ben@niven-jenkins.co.uk; = ZhouZhipeng
Cc: cdni@ietf.org
Subject: RE: = [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, = all,

I think that Content Adaptation = is more an issue for the Requirements doc than for the Use cases = draft.

The key question is whether we = want the CDNI interfaces to be able to cope with a scenario where (say) = HD/SD conversion is done in the dCDN & to signal about = this.

I think that coping with this = scenario is a second order requirement, ie we should not worry about it = in the initial standards-track work. I don't know, did we ever decide = whether the Use cases doc is restricted to "initial" scenarios, or = whether it's all-encompassing, ie covering "future" scenarios as = well?

Scott,
Reading some of your examples, = they seem to be valid even if content adaptation (HD/SD) is out of = scope.
- a dCDN might for some reason be unwilling to distribute = HD?
- a CSP might want to make sure the dCDN can use HLS = encapsulation?
But these sorts of examples seem = to be static policy things (to = do
with the capabilities & preferences of the CDNs & = CSP), rather than
metadata associated with a = particular piece of content. In = the
discussion so far, I think negotiation about static policy = stuff is
rather out of = scope(?)

On security considerations, an = interesting question is whether trust is transitive. Don't think it need = be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean = that the CSP automatically trusts the dCDN. However, i suspect this can = get arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.

Best = wishes
phil


Philip = Eardley
Research and Technology = Strategy

This email contains BT = information, which may be privileged or confidential. It's meant only = for the individual(s) or entity named above. If you're not the intended = recipient, note that disclosing, copying, distributing or using this = information is prohibited. If you've received this email in error, = please let me know immediately on the email address above. Thank you. We = monitor our email system, and may record your = emails.
British Telecommunications = plc
Registered office: 81 Newgate Street London EC1A 7AJ = Registered in
England no: = 1800000


-----Original = Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On = Behalf
Of Ben = Niven-Jenkins
Sent: 10 October 2011 = 12:04
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: = [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Colleagues,

IMO Section 5.1.3 should be = removed from the Use Cases draft. Content Adaptation (i.e. taking in a = content item in one format and transforming it to another format or = representation) is not a "core" function of a CDN which typically = delivers the content that is requested without explicit knowledge of = what that content actually is.

Let's not forget that in = building an end to end content service the CDN is only one component and = is the component tasked with executing the delivery of a specific = representation (version/copy/format etc.) of the selected content not = the component tasked with deciding (or applying policy) on which = version/copy/representation of content should be = delivered.

The decision as to which = version/copy/representation to offer and allow to be delivered to a = given device/user is implemented outside of the CDN (e.g. by the = "portal" where the user first makes their content selection prior to the = CDN becoming involved in the delivery of the selected = content).

Ben

On 8 Oct 2011, at 08:20, = ZhouZhipeng wrote:

Following Scott's comments on section 5.1.3, I feel = Scott's description on the use case of HD and SD is not exactly = correct.
If one = movie has two formats of HD and SD, then we have two content with = different identifier. In DRM scope, the basic unit is a content = copy.

Here = the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content = adaptation.
In = last month, I have contacted the Authors of this document and taken some = email exchanges with Grant and Philip = (BT).
I have = shown BT with some information that I know in this case and area to = explain the content flexibility is currently a basic requirement for CDN = service and related negotiation is needed in the CDN = interconnection.
Meanwhile, I should also invite you in this group raising = your comments or questions on this case since I hope my use case may be = incorporated in the use case = draft.

If you = have any more question or comments, pls share in this = thread.
Thanks.
Zhipeng






-----Original = Message-----
From: = Scott Wainner = [mailto:swainner@cisco.com]
Sent: Friday, September 30, 2011 8:02 = AM
To: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Section = 2.3 Nomadic Users
This = description falls under the category of Geographic = Extension
yet = the third paragraph states the case where a different device = is
used = in the same CDN coverage area.  The intent of this use = case
needs = to be clarified.  Perhaps the use case is trying to = address
the = scenario where a Nomadic User-A with an agreement = allowing
access = to content from CSP-A via uCDN moves to a dCDN in a = different
region. =  The dCDN is allowed to distribute the content of CSP-A = to
User-A; = however, not other users in the region of the dCDN = are
allowed = to retrieve the content unless they too have such an = agreement.

Section = 5.1.3 Content Encoding Restrictions Need to clarify if = we're
talking = about the restrictions on the delivery of specific = content
or the = restrictions on the ability of a CDN to deliver = specific
content.=  I certainly understand the case where a CSP will = restrict
the = distribution of content to a "managed path" if such content = is
HD = while allowing the content distribution via an un-managed path = if
such = content is SD (same could apply to encryption methods, = delivery
methods,= etc.).  On the contrary, the dCDN may have its = own
restrictions of blocking the distribution of HD content = while
allowing= the distribution of SD = content.

o = first bullet makes sense if the dCDN can perform a subset = of
encapsulations for a reference set of media (e.g. HLS, = HSS, but not
DASH) = o second bullet makes sense where the dCDN doesn't want = to
offer = high bit-rate variants of the media o third bullet make = sense
if the = policy addresses QoE but I don't think = subscriber
rights/authorizations = apply.

Section = 10 Security = Considerations

Aside = from the security considerations WITHIN the uCDN and dCDN, = I
think = we can describe this in four = contexts:

a. The = relationship between the CSP and the uCDN (the principle = contract
arrangement for = distribution)
b. The = relationship between the uCDN and dCDN (the transitive = trust
relationship that extends the contract defined in (a) = above) c. The
relationship between the User and dCDN (the recognition of = right to
download= predicated on (b) above) d. The relationship between = the
User = and CSP (the contract authorizing the user access to = the
content)

The = user is not interested in the a-b nor the b-c relationship. = The
user = is only interested in the transparency and interoperability = of
the = security relationship between d-b or d-c to the point that = the
authorization granted in d-a is viable when the delivery = is
initiated via either d-b or d-c.  As an example, the = uCDN might use
URL = appended tokens for authentication while dCDN might use = URL
appended= hashes.  The user doesn't want to know about the = distinct
methods,= but transparency is only afforded if the methods = are
interoperable clearly defined when the delegation for = content
delivery= is executed.  Clearly, the choice of authentication method is = determined by the respective = CDN's.

Scott

_______________________________________________
CDNi mailing = list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni

_______________________________________________
CDNi = mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni


_______________________________________= ________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni
______________________________________________= _
CDNi mailing = list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

= --Apple-Mail-359--96687033-- From mark@jet-stream.nl Wed Oct 26 13:21:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F4D1F0C54 for ; Wed, 26 Oct 2011 13:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uGn1+oJ0PLc for ; Wed, 26 Oct 2011 13:21:55 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4D91F0C52 for ; Wed, 26 Oct 2011 13:21:54 -0700 (PDT) Received: from [172.20.10.2] (host068-010.kpn-gprs.nl [62.133.68.10]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id p9QKLDHe021352 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 26 Oct 2011 22:21:35 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-360--96621559 From: Mark de Jong In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> Date: Wed, 26 Oct 2011 21:21:18 +0100 Message-Id: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> To: Alan Kavanagh X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 20:21:58 -0000 --Apple-Mail-360--96621559 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alan, As Ben stated the overall discussion right now is about delivery, not on = adaptation. It is hard enough to get consensus on the delivery aspect = already not to mention your requirement from content adaptation added to = that, so I agree with Ben we should stick with the delivery aspect for = the first specs. I can imagine this could be a discussion later on but = please let us keep the scope of this be clean and transparent. It is of = benefit of everyone to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: > Ben >=20 > Im assuming then based on your comments below are you suggesting we = are going to have a number of versions of the CDN-I Metadata? >=20 > I sympathise with what you are pointing out below and do agree that = there is some work to be done, but I still feel that content adaptation = is to me a fundamental requirement to what collectively we should = address in the CDN-I WG. I do agree with you that content adaptation is = an optimization between CDN's but it's a very important one that I know = Network Service Providers particularly require. >=20 > Alan >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins > Sent: October-12-11 1:13 PM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Zhipeng, >=20 > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: >=20 >> Hello Ben, >> The UE may select the content format on the CP web. After that the = user only desires to get his selected content. >> But how the content is transferred to the client is not worried by = the user. >> The CP may create a special format as required by the user and ask = the CDN to deliver to user. >> While CP may give a HD format content to uCDN and the dCDN may then = transform to the format as the user select. >=20 > Lots of things may be possible to do and CDN providers offer many = additional services on top of the "core" service of content delivery. = However, our objective (based on my interpretation of the CDNI charter) = is to focus on what is necessary to interconnect CDNs to deliver content = from a CSP to an End User that is targeted and deployable within a short = time frame (18-24 months). >=20 > Content transformation/adaptation is not an essential requirement in = order to achieve that aim (we can deliver content from CSPs to End Users = via multiple CDNs without needing or requiring any CDN supports content = adaptation). >=20 > In my opinion we have enough work to do already without trying to = expand the scope of our work to include additional requirements that do = not help us address our core objectives as laid out in the CDNI charter. >=20 >> In this case, it is nothing related to how the user select formats on = CP website. >> So, it is the CP and user to decide the content format not the = CDN(your assert is not correct and seems you take that assert as your = base for the discussion). >>=20 >> As for "the core CDN functionality offered by CDNs today", I have = ever raised an email before that your company's webpage has claimed = supporting media transformation and multi-screen service. >> Perhaps, I like asking you list some features that you feel are the = core functionalities by existing main stream CDNs. Thus we may compare = and take deep look. >=20 > I think the core functionality maps pretty well to the CDNI = interfaces, namely: Request Routing, Metadata configuration, log = production and control plus content acquisition and content delivery. >=20 >> I guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in process. >>=20 >> Besides, I like raise a case: >> Given currently BBC recruits CDN providers that may support 10 media = formats. >> One candidate is your company, another is CDN-X. The users are = located in France. >> So both your company and CDN-X should connect a France CDN = provider(CDN-Y). >> If your company's solution is to send 10 streams of different format >> of one content to CDN-Y; While CDN-X's solution is to send 1 stream = to CDN-Y while CDN-Y may conduct some adaptation. >> Comparing these two solutions, for your company and CDN-X, absolutely = the cost of CDN-X is much lower. >> For CDN-Y, in solution-1, it should receive/forward 10 streams ; = while in solution-2, it should only receive 1 stream but need to take = transformation to output 10 streams. >>=20 >> Which solution is more competitive. it is Solution 1, right. Remember = the price from BBC is same to both your company and CDN-X or BBC would = select one CDN provider with the lower price. >> If a CDN provider may not get the contract from CP, how it may say it = is not a core functionality. >=20 > What you are describing is a possible optimization that a particular = CDN may wish to implement not a core functionality required to enable = content delivery between interconnected CDNs. I can think of many = optimizations that a CDN could implement to differentiate their service = but the internal workings of an individual CDN are out of scope of our = charter. >=20 > So to repeat my position for a final time: Content adaptation is not a = core function required to enable content delivery between interconnected = CDNs and therefore given the workload we already have to specify = solutions that do address the core functionality required to = interconnect CDNs I do not think we should be trying to add more work = into that workload as it will only distract us from achieving our goal = of producing deployable solutions within the timeframe we are being told = by operators they needs solutions within. >=20 > Ben >=20 >> So, if we all realize that currently the media type is rich, the CDN = providers should survive in the existing ecosystem and support the media = types as required by the market. >>=20 >> Back to the case of GSM/G.711, it just when concerning the = interconnection, the transformation should at once be solved. Otherwise = the interconnection may not be operated. >>=20 >> Br, >> Zhipeng >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> Sent: Wednesday, October 12, 2011 12:19 AM >> To: ZhouZhipeng >> Cc: philip.eardley@bt.com; cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>=20 >> Zhipeng, >>=20 >> On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: >>=20 >>> Ben and Philip, >>> I like to respond your concern in this one email: >>>=20 >>> Ben, >>> I feel what we are now discussing is what is the "core" function of = CDN. >>> As you say, CDN is used to deliver content. That is absolutely = correct that the delivery capability is the core requirement for CDN = system. >>> While CDN is used to provide the content delivery service. >>> What means service. It should include "time" "location" and "media = type", etc. These features are all the core feature for a service. >>> If we only concern "delivering one data block", I am not sure = whether the issues such as "logging" "geographic constraint" are the = core of CDN. >>>=20 >>> For "without explicit knowledge of what that content actually is ", = I am not sure whether the wording is accurate since generally a CDN may = claim it support different medias. >>> By this opportunity, I like to share a use case: a call from a GSM = phone to a PSTN telephone, the voice stream should be transformed from = GSM voice to G.711. >>> For the user, he does not need to know what type of data has been = transferred, but the operator has done some work to interconnect two = systems, right. >>> I like to know whether you may accept that my use case is similar to = this case above. >>=20 >> I don't think your use case is similar to the analogy of mobile = networks being interconnected to PSTN networks. In the case of content = delivery the negotiation is done between the User/Client and the Content = Provider and the CDN is just used to execute/perform the delivery that = has been negotiated. The CDN is not involved in the decision making of = what representations the Content Provider decides to offer to the = User/Client or in what representations the User/Client decides to = request. >>=20 >>> As for you said selecting media by the "portal", you may see the way = " uCDN delivers multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media types". >>=20 >> Now what you're talking about is an optimisation, not a core function = required to actually deliver the content (and report, bill, etc. for = that delivery). >>=20 >> My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO. >>=20 >> Ben >>=20 >>> A good question is "security" since I have done six years on the DRM >>> and like to promote the DRM all around the world:) If the content is = needed to be protected, generally you may know all the systems should be = granted by the content owner. >>> Here I also like to clarify that not only the media itself but the = information related to service itself (such as the geographic = constraint) should be protected also. >>> So, trust is not a problem for the media. >>>=20 >>> Philip, >>> Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use case. >>> I like to clarify to U that it is important for you operator since = it may save investment if the system may support different services. >>> For us vendor, we are happy operator may install a system for the = mobile service and another system for the FBB service. >>> But the reality is all operators ask us to provide a system that may = support different service systems. >>>=20 >>> Frankly, Ben and Philip, I remember I have explained somewhere that = to implement this is rather simple . >>> At least the Use case and Requirement are informational to be = referred in future work. So I do really feel you may accept it. >>> Of course I like to respond your more concern and comments. >>> Thanks. >>> Zhipeng >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] >>> Sent: Monday, October 10, 2011 11:22 PM >>> To: ben@niven-jenkins.co.uk; ZhouZhipeng >>> Cc: cdni@ietf.org >>> Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>=20 >>> Ben, Zhipeng, all, >>>=20 >>> I think that Content Adaptation is more an issue for the = Requirements doc than for the Use cases draft. >>>=20 >>> The key question is whether we want the CDNI interfaces to be able = to cope with a scenario where (say) HD/SD conversion is done in the dCDN = & to signal about this. >>>=20 >>> I think that coping with this scenario is a second order = requirement, ie we should not worry about it in the initial = standards-track work. I don't know, did we ever decide whether the Use = cases doc is restricted to "initial" scenarios, or whether it's = all-encompassing, ie covering "future" scenarios as well? >>>=20 >>> Scott, >>> Reading some of your examples, they seem to be valid even if content = adaptation (HD/SD) is out of scope. >>> - a dCDN might for some reason be unwilling to distribute HD? >>> - a CSP might want to make sure the dCDN can use HLS encapsulation? >>> But these sorts of examples seem to be static policy things (to do >>> with the capabilities & preferences of the CDNs & CSP), rather than >>> metadata associated with a particular piece of content. In the >>> discussion so far, I think negotiation about static policy stuff is >>> rather out of scope(?) >>>=20 >>> On security considerations, an interesting question is whether trust = is transitive. Don't think it need be - just because CSP trusts uCDN, = and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the = dCDN. However, i suspect this can get arbitrarily complex - so one = possibility is to say that we will only handle cases where the trust is = transitive. >>>=20 >>> Best wishes >>> phil >>>=20 >>>=20 >>> Philip Eardley >>> Research and Technology Strategy >>>=20 >>> This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. >>> British Telecommunications plc >>> Registered office: 81 Newgate Street London EC1A 7AJ Registered in >>> England no: 1800000 >>>=20 >>>=20 >>> -----Original Message----- >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf >>> Of Ben Niven-Jenkins >>> Sent: 10 October 2011 12:04 >>> To: ZhouZhipeng >>> Cc: cdni@ietf.org >>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>=20 >>> Colleagues, >>>=20 >>> IMO Section 5.1.3 should be removed from the Use Cases draft. = Content Adaptation (i.e. taking in a content item in one format and = transforming it to another format or representation) is not a "core" = function of a CDN which typically delivers the content that is requested = without explicit knowledge of what that content actually is. >>>=20 >>> Let's not forget that in building an end to end content service the = CDN is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. >>>=20 >>> The decision as to which version/copy/representation to offer and = allow to be delivered to a given device/user is implemented outside of = the CDN (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content). >>>=20 >>> Ben >>>=20 >>> On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: >>>=20 >>>> Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. >>>> If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. >>>>=20 >>>> Here the first bullet "a subset of encodings deliverable to = specific devices," has listed the case of content adaptation. >>>> In last month, I have contacted the Authors of this document and = taken some email exchanges with Grant and Philip (BT). >>>> I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. >>>> Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. >>>>=20 >>>> If you have any more question or comments, pls share in this = thread. >>>> Thanks. >>>> Zhipeng >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> -----Original Message----- >>>> From: Scott Wainner [mailto:swainner@cisco.com] >>>> Sent: Friday, September 30, 2011 8:02 AM >>>> To: cdni@ietf.org >>>> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >>>>=20 >>>> Section 2.3 Nomadic Users >>>> This description falls under the category of Geographic Extension >>>> yet the third paragraph states the case where a different device is >>>> used in the same CDN coverage area. The intent of this use case >>>> needs to be clarified. Perhaps the use case is trying to address >>>> the scenario where a Nomadic User-A with an agreement allowing >>>> access to content from CSP-A via uCDN moves to a dCDN in a = different >>>> region. The dCDN is allowed to distribute the content of CSP-A to >>>> User-A; however, not other users in the region of the dCDN are >>>> allowed to retrieve the content unless they too have such an = agreement. >>>>=20 >>>> Section 5.1.3 Content Encoding Restrictions Need to clarify if = we're >>>> talking about the restrictions on the delivery of specific content >>>> or the restrictions on the ability of a CDN to deliver specific >>>> content. I certainly understand the case where a CSP will restrict >>>> the distribution of content to a "managed path" if such content is >>>> HD while allowing the content distribution via an un-managed path = if >>>> such content is SD (same could apply to encryption methods, = delivery >>>> methods, etc.). On the contrary, the dCDN may have its own >>>> restrictions of blocking the distribution of HD content while >>>> allowing the distribution of SD content. >>>>=20 >>>> o first bullet makes sense if the dCDN can perform a subset of >>>> encapsulations for a reference set of media (e.g. HLS, HSS, but not >>>> DASH) o second bullet makes sense where the dCDN doesn't want to >>>> offer high bit-rate variants of the media o third bullet make sense >>>> if the policy addresses QoE but I don't think subscriber >>>> rights/authorizations apply. >>>>=20 >>>> Section 10 Security Considerations >>>>=20 >>>> Aside from the security considerations WITHIN the uCDN and dCDN, I >>>> think we can describe this in four contexts: >>>>=20 >>>> a. The relationship between the CSP and the uCDN (the principle = contract >>>> arrangement for distribution) >>>> b. The relationship between the uCDN and dCDN (the transitive trust >>>> relationship that extends the contract defined in (a) above) c. The >>>> relationship between the User and dCDN (the recognition of right to >>>> download predicated on (b) above) d. The relationship between the >>>> User and CSP (the contract authorizing the user access to the >>>> content) >>>>=20 >>>> The user is not interested in the a-b nor the b-c relationship. The >>>> user is only interested in the transparency and interoperability of >>>> the security relationship between d-b or d-c to the point that the >>>> authorization granted in d-a is viable when the delivery is >>>> initiated via either d-b or d-c. As an example, the uCDN might use >>>> URL appended tokens for authentication while dCDN might use URL >>>> appended hashes. The user doesn't want to know about the distinct >>>> methods, but transparency is only afforded if the methods are >>>> interoperable clearly defined when the delegation for content >>>> delivery is executed. Clearly, the choice of authentication method = is determined by the respective CDN's. >>>>=20 >>>> Scott >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 --Apple-Mail-360--96621559 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Alan,

As Ben stated the overall discussion right now = is about delivery, not on adaptation. It is hard enough to get consensus = on the delivery aspect already not to mention your requirement from = content adaptation added to that, so I agree with Ben we should stick = with the delivery aspect for the first specs. I can imagine this = could be a discussion later on but please let us keep the scope of this = be clean and transparent. It is of benefit of everyone to get the first = specs as fast as possible. Thanks.

mark@jet-stream.com
Office: = +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 = 5264214

- = Event: Meet us at = Streaming Media Europe, 17-18 October, London, = UK
- = Event: Meet us at Online Video Strategies, 19 October, London, = UK
- = Event: Meet us at CDN World Summit, 25-28 October, London, = UK
- News: Pre-request= your Technology Whitepaper now and be the first to have it, check www.jet-stream.com
http://www.jet-stream.com to = download our 'Six Trends in CDNs' brochure
- VideoExchange: www.vdo-x.net
 Streamzilla: www.streamzillacdn.com
- Corporate: www.jet-stream.com

On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote:

Ben

Im assuming then based on your comments = below are you suggesting we are going to have a number of versions of = the CDN-I Metadata?

I sympathise with what you are pointing out = below and do agree that there is some work to be done, but I still feel = that content adaptation is to me a fundamental requirement to what = collectively we should address in the CDN-I WG. I do agree with you that = content adaptation is an optimization between CDN's but it's a very = important one that I know Network Service Providers particularly = require.

Alan

-----Original Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: = October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] = I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On = 12 Oct 2011, at 10:22, ZhouZhipeng wrote:

Hello Ben,
The = UE may select the content format on the CP web. After that the user only = desires to get his selected content.
But how the content is transferred to the client is not = worried by the user.
The CP = may create a special format as required by the user and ask the CDN to = deliver to user.
While CP may = give a HD format content to uCDN and the dCDN may then transform to the = format as the user select.

Lots of things may be = possible to do and CDN providers offer many additional services on top = of the "core" service of content delivery. However, our objective (based = on my interpretation of the CDNI charter) is to focus on what is = necessary to interconnect CDNs to deliver content from a CSP to an End = User that is targeted and deployable within a short time frame (18-24 = months).

Content transformation/adaptation is not an essential = requirement in order to achieve that aim (we can deliver content from = CSPs to End Users via multiple CDNs without needing or requiring any CDN = supports content adaptation).

In my opinion we have enough work = to do already without trying to expand the scope of our work to include = additional requirements that do not help us address our core objectives = as laid out in the CDNI charter.

In = this case, it is nothing related to how the user select formats on CP = website.
So, it is the CP and = user to decide the content format not the CDN(your assert is not correct = and seems you take that assert as your base for the = discussion).

As for "the = core CDN functionality offered by CDNs today", I have ever raised an = email before that your company's webpage has claimed supporting media = transformation and multi-screen service.
Perhaps, I like asking you list some features that you = feel are the core functionalities by existing main stream CDNs. Thus we = may compare and take deep look.

I think the core = functionality maps pretty well to the CDNI interfaces, namely: Request = Routing, Metadata configuration, log production and control plus content = acquisition and content delivery.

I = guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in = process.

Besides, I like = raise a case:
Given currently = BBC recruits CDN providers that may support 10 media = formats.
One candidate is your = company, another is CDN-X. The users are located in = France.
So both your company = and CDN-X should connect a France CDN = provider(CDN-Y).
If your = company's solution is to send 10 streams of different = format
of one content to = CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y = may conduct some adaptation.
Comparing these two solutions, for your company and CDN-X, = absolutely the cost of CDN-X is much lower.
For CDN-Y, in solution-1, it should receive/forward 10 = streams ; while in solution-2, it should only receive 1 stream but need = to take transformation to output 10 streams.

Which solution = is more competitive. it is Solution 1, right. Remember the price from = BBC is same to both your company and CDN-X or BBC would select one CDN = provider with the lower price.
If a CDN provider may not get the contract from CP, how it = may say it is not a core functionality.

What you are = describing is a possible optimization that a particular CDN may wish to = implement not a core functionality required to enable content delivery = between interconnected CDNs. I can think of many optimizations that a = CDN could implement to differentiate their service but the internal = workings of an individual CDN are out of scope of our charter.

So = to repeat my position for a final time: Content adaptation is not a core = function required to enable content delivery between interconnected CDNs = and therefore given the workload we already have to specify solutions = that do address the core functionality required to interconnect CDNs I = do not think we should be trying to add more work into that workload as = it will only distract us from achieving our goal of producing deployable = solutions within the timeframe we are being told by operators they needs = solutions within.

Ben

So, if we = all realize that currently the media type is rich, the CDN providers = should survive in the existing ecosystem and support the media types as = required by the market.

Back to the = case of GSM/G.711, it just when concerning the interconnection, the = transformation should at once be solved. Otherwise the interconnection = may not be operated.

Br,
Zhipeng




-----Original = Message-----
From: Ben = Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]
Sent: Wednesday, October 12, 2011 12:19 = AM
To: = ZhouZhipeng
Cc: philip.eardley@bt.com; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 11 Oct 2011, = at 05:16, ZhouZhipeng wrote:

Ben and Philip,
I like to respond your concern = in this one email:

Ben,
I feel what we are now = discussing is what is the "core" function of = CDN.
As you say, CDN is used to deliver content. That is = absolutely correct that the delivery capability is the core requirement = for CDN system.
While CDN is used to provide the = content delivery service.
What means service. It should = include "time" "location" and "media type", etc. These features are all = the core feature for a service.
If we only concern "delivering = one data block", I am not sure whether the issues such as "logging" = "geographic constraint" are the core of = CDN.

For "without explicit knowledge = of what that content actually is ", I am not sure whether the wording is = accurate since generally a CDN may claim it support different = medias.
By this opportunity, I like to share a use case: a call = from a GSM phone to a PSTN telephone, the voice stream should be = transformed from GSM voice to = G.711.
For the user, he does not need to know what type of data = has been transferred, but the operator has done some work to = interconnect two systems, = right.
I like to know whether you may accept that my use case is = similar to this case above.

I don't think = your use case is similar to the analogy of mobile networks being = interconnected to PSTN networks. In the case of content delivery the = negotiation is done between the User/Client and the Content Provider and = the CDN is just used to execute/perform the delivery that has been = negotiated. The CDN is not involved in the decision making of what = representations the Content Provider decides to offer to the User/Client = or in what representations the User/Client decides to = request.

As for you said selecting media by the "portal", you may = see the way " uCDN delivers multiple media streams to dCDN" is not good = than "uCDN delivers one media stream to dCDN and dCDN takes some = adaptation to support multiple media = types".

Now what you're = talking about is an optimisation, not a core function required to = actually deliver the content (and report, bill, etc. for that = delivery).

My position is = that we should focus on how to enable the interconnection of the core = CDN functionality offered by CDNs today (which is also my interpretation = of the scope of the CDNI working group as expressed in its charter) = because doing so is a significant piece of work in itself. Let's not = start trying to add in additional functionality beyond what the majority = of CDNs support today as that will just delay us getting usable = specifications into the market in a timely fashion = IMO.

Ben

A good question is "security" since I have done six years = on the DRM
and like to promote the DRM all = around the world:) If the content is needed to be protected, generally = you may know all the systems should be granted by the content = owner.
Here I also like to clarify that not only the media itself = but the information related to service itself (such as the geographic = constraint) should be protected = also.
So, trust is not a problem for the = media.

Philip,
Thank you that you feel Content = Adaption is an issue for "Requirements" but I do not know why it is not = for Use case.
I like to clarify to U that it = is important for you operator since it may save investment if the system = may support different services.
For us vendor, we are happy = operator may install a system for the mobile service and another system = for the FBB service.
But the reality is all operators = ask us to provide a system that may support different service = systems.

Frankly, Ben and Philip, I = remember I have explained somewhere that to implement this is rather = simple .
At least the Use case and = Requirement are informational to be referred in future work. So I do = really feel you may accept it.
Of course I like to respond your = more concern and comments.
Thanks.
Zhipeng



-----Original = Message-----
From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]
Sent: Monday, October 10, 2011 = 11:22 PM
To: ben@niven-jenkins.co.uk; = ZhouZhipeng
Cc: cdni@ietf.org
Subject: RE: = [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, = all,

I think that Content Adaptation = is more an issue for the Requirements doc than for the Use cases = draft.

The key question is whether we = want the CDNI interfaces to be able to cope with a scenario where (say) = HD/SD conversion is done in the dCDN & to signal about = this.

I think that coping with this = scenario is a second order requirement, ie we should not worry about it = in the initial standards-track work. I don't know, did we ever decide = whether the Use cases doc is restricted to "initial" scenarios, or = whether it's all-encompassing, ie covering "future" scenarios as = well?

Scott,
Reading some of your examples, = they seem to be valid even if content adaptation (HD/SD) is out of = scope.
- a dCDN might for some reason be unwilling to distribute = HD?
- a CSP might want to make sure the dCDN can use HLS = encapsulation?
But these sorts of examples seem = to be static policy things (to = do
with the capabilities & preferences of the CDNs & = CSP), rather than
metadata associated with a = particular piece of content. In = the
discussion so far, I think negotiation about static policy = stuff is
rather out of = scope(?)

On security considerations, an = interesting question is whether trust is transitive. Don't think it need = be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean = that the CSP automatically trusts the dCDN. However, i suspect this can = get arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.

Best = wishes
phil


Philip = Eardley
Research and Technology = Strategy

This email contains BT = information, which may be privileged or confidential. It's meant only = for the individual(s) or entity named above. If you're not the intended = recipient, note that disclosing, copying, distributing or using this = information is prohibited. If you've received this email in error, = please let me know immediately on the email address above. Thank you. We = monitor our email system, and may record your = emails.
British Telecommunications = plc
Registered office: 81 Newgate Street London EC1A 7AJ = Registered in
England no: = 1800000


-----Original = Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On = Behalf
Of Ben = Niven-Jenkins
Sent: 10 October 2011 = 12:04
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: = [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Colleagues,

IMO Section 5.1.3 should be = removed from the Use Cases draft. Content Adaptation (i.e. taking in a = content item in one format and transforming it to another format or = representation) is not a "core" function of a CDN which typically = delivers the content that is requested without explicit knowledge of = what that content actually is.

Let's not forget that in = building an end to end content service the CDN is only one component and = is the component tasked with executing the delivery of a specific = representation (version/copy/format etc.) of the selected content not = the component tasked with deciding (or applying policy) on which = version/copy/representation of content should be = delivered.

The decision as to which = version/copy/representation to offer and allow to be delivered to a = given device/user is implemented outside of the CDN (e.g. by the = "portal" where the user first makes their content selection prior to the = CDN becoming involved in the delivery of the selected = content).

Ben

On 8 Oct 2011, at 08:20, = ZhouZhipeng wrote:

Following Scott's comments on section 5.1.3, I feel = Scott's description on the use case of HD and SD is not exactly = correct.
If one = movie has two formats of HD and SD, then we have two content with = different identifier. In DRM scope, the basic unit is a content = copy.

Here = the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content = adaptation.
In = last month, I have contacted the Authors of this document and taken some = email exchanges with Grant and Philip = (BT).
I have = shown BT with some information that I know in this case and area to = explain the content flexibility is currently a basic requirement for CDN = service and related negotiation is needed in the CDN = interconnection.
Meanwhile, I should also invite you in this group raising = your comments or questions on this case since I hope my use case may be = incorporated in the use case = draft.

If you = have any more question or comments, pls share in this = thread.
Thanks.
Zhipeng






-----Original = Message-----
From: = Scott Wainner = [mailto:swainner@cisco.com]
Sent: Friday, September 30, 2011 8:02 = AM
To: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Section = 2.3 Nomadic Users
This = description falls under the category of Geographic = Extension
yet = the third paragraph states the case where a different device = is
used = in the same CDN coverage area.  The intent of this use = case
needs = to be clarified.  Perhaps the use case is trying to = address
the = scenario where a Nomadic User-A with an agreement = allowing
access = to content from CSP-A via uCDN moves to a dCDN in a = different
region. =  The dCDN is allowed to distribute the content of CSP-A = to
User-A; = however, not other users in the region of the dCDN = are
allowed = to retrieve the content unless they too have such an = agreement.

Section = 5.1.3 Content Encoding Restrictions Need to clarify if = we're
talking = about the restrictions on the delivery of specific = content
or the = restrictions on the ability of a CDN to deliver = specific
content.=  I certainly understand the case where a CSP will = restrict
the = distribution of content to a "managed path" if such content = is
HD = while allowing the content distribution via an un-managed path = if
such = content is SD (same could apply to encryption methods, = delivery
methods,= etc.).  On the contrary, the dCDN may have its = own
restrictions of blocking the distribution of HD content = while
allowing= the distribution of SD = content.

o = first bullet makes sense if the dCDN can perform a subset = of
encapsulations for a reference set of media (e.g. HLS, = HSS, but not
DASH) = o second bullet makes sense where the dCDN doesn't want = to
offer = high bit-rate variants of the media o third bullet make = sense
if the = policy addresses QoE but I don't think = subscriber
rights/authorizations = apply.

Section = 10 Security = Considerations

Aside = from the security considerations WITHIN the uCDN and dCDN, = I
think = we can describe this in four = contexts:

a. The = relationship between the CSP and the uCDN (the principle = contract
arrangement for = distribution)
b. The = relationship between the uCDN and dCDN (the transitive = trust
relationship that extends the contract defined in (a) = above) c. The
relationship between the User and dCDN (the recognition of = right to
download= predicated on (b) above) d. The relationship between = the
User = and CSP (the contract authorizing the user access to = the
content)

The = user is not interested in the a-b nor the b-c relationship. = The
user = is only interested in the transparency and interoperability = of
the = security relationship between d-b or d-c to the point that = the
authorization granted in d-a is viable when the delivery = is
initiated via either d-b or d-c.  As an example, the = uCDN might use
URL = appended tokens for authentication while dCDN might use = URL
appended= hashes.  The user doesn't want to know about the = distinct
methods,= but transparency is only afforded if the methods = are
interoperable clearly defined when the delegation for = content
delivery= is executed.  Clearly, the choice of authentication method is = determined by the respective = CDN's.

Scott

_______________________________________________
CDNi mailing = list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni

_______________________________________________
CDNi = mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni


_______________________________________= ________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni
______________________________________________= _
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni


= --Apple-Mail-360--96621559-- From kleung@cisco.com Wed Oct 26 14:01:40 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5214D11E808C for ; Wed, 26 Oct 2011 14:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSMN5x5UBXAj for ; Wed, 26 Oct 2011 14:01:37 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2E39C11E808A for ; Wed, 26 Oct 2011 14:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=101253; q=dns/txt; s=iport; t=1319662897; x=1320872497; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=s40FyfGp6EYMELeQ8I1huNNeNH+pKz6lbqSqJC3MQv8=; b=Ld4Ioy0MSxvNY6EVznGabrDDsiDw0lAMM1j6lperKdwkoALyk8vvwPS5 NkO/GvkSfLU06rf9rp11E/4atqPdc1ObyFgioja8WD3qAH8Vess4ds6PS eDhPazlDbwHodEvBuw1Ko5EBAVY2PdMogmepTmpIx2eVBGnw6T8syBFFB E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskAAGp0qE6rRDoG/2dsb2JhbABCgk2XOY9IgQWBbgEBAQQBAQEPAQcBAREDGSUEBwwCAgIBCBEEAQELBhABBgEGARURHwkIAQEEAQkJCBIBB4dmlkoBnmUCiAdhBIgGkTqFAYdI X-IronPort-AV: E=Sophos;i="4.69,411,1315180800"; d="scan'208,217";a="10505657" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 26 Oct 2011 21:01:36 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p9QL1Z1B025696; Wed, 26 Oct 2011 21:01:36 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Oct 2011 14:01:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC9422.7284EFD5" Date: Wed, 26 Oct 2011 14:01:33 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC521024D515@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyUHPRtSjiwYJQpTDmB4L6cDKJtXgABUsew References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com><4E8506FC.1020701@cisco.com><260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com><853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk><9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net><260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com><1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk><260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com><166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk><1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> From: "Kent Leung (kleung)" To: "Mark de Jong" , "Alan Kavanagh" X-OriginalArrivalTime: 26 Oct 2011 21:01:36.0339 (UTC) FILETIME=[72D6F230:01CC9422] Cc: cdni@ietf.org, ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 21:01:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9422.7284EFD5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also agree with Ben that content adaptation is an optimization that is out of scope. We have enough to do in the WG already. =20 Kent =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Mark de Jong Sent: Wednesday, October 26, 2011 1:21 PM To: Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Hi Alan, =20 As Ben stated the overall discussion right now is about delivery, not on adaptation. It is hard enough to get consensus on the delivery aspect already not to mention your requirement from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for the first specs. I can imagine this could be a discussion later on but please let us keep the scope of this be clean and transparent. It is of benefit of everyone to get the first specs as fast as possible. Thanks. =20 Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 =20 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs' brochure =20 - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com =20 On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: Ben Im assuming then based on your comments below are you suggesting we are going to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that there is some work to be done, but I still feel that content adaptation is to me a fundamental requirement to what collectively we should address in the CDN-I WG. I do agree with you that content adaptation is an optimization between CDN's but it's a very important one that I know Network Service Providers particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: Hello Ben, The UE may select the content format on the CP web. After that the user only desires to get his selected content. But how the content is transferred to the client is not worried by the user. The CP may create a special format as required by the user and ask the CDN to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select. Lots of things may be possible to do and CDN providers offer many additional services on top of the "core" service of content delivery. However, our objective (based on my interpretation of the CDNI charter) is to focus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and deployable within a short time frame (18-24 months). Content transformation/adaptation is not an essential requirement in order to achieve that aim (we can deliver content from CSPs to End Users via multiple CDNs without needing or requiring any CDN supports content adaptation). In my opinion we have enough work to do already without trying to expand the scope of our work to include additional requirements that do not help us address our core objectives as laid out in the CDNI charter. In this case, it is nothing related to how the user select formats on CP website. So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion). =20 As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look. I think the core functionality maps pretty well to the CDNI interfaces, namely: Request Routing, Metadata configuration, log production and control plus content acquisition and content delivery. I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process. =20 Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media formats. One candidate is your company, another is CDN-X. The users are located in France. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams. =20 Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. What you are describing is a possible optimization that a particular CDN may wish to implement not a core functionality required to enable content delivery between interconnected CDNs. I can think of many optimizations that a CDN could implement to differentiate their service but the internal workings of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core function required to enable content delivery between interconnected CDNs and therefore given the workload we already have to specify solutions that do address the core functionality required to interconnect CDNs I do not think we should be trying to add more work into that workload as it will only distract us from achieving our goal of producing deployable solutions within the timeframe we are being told by operators they needs solutions within. Ben So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market. =20 Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated. =20 Br, Zhipeng =20 =20 =20 =20 -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Zhipeng, =20 On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: =20 Ben and Philip, I like to respond your concern in this one email: =20 Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN. =20 For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias. By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711. For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to this case above. =20 I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request. =20 As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types". =20 Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery). =20 My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO. =20 Ben =20 A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) If the content is needed to be protected, generally you may know all the systems should be granted by the content owner. Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also. So, trust is not a problem for the media. =20 Philip, Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it may save investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service. But the reality is all operators ask us to provide a system that may support different service systems. =20 Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple . At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng =20 =20 =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Ben, Zhipeng, all, =20 I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft. =20 The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this. =20 I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well? =20 Scott, Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) =20 On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive. =20 Best wishes phil =20 =20 Philip Eardley Research and Technology Strategy =20 This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 =20 =20 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Colleagues, =20 IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is. =20 Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered. =20 The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content). =20 Ben =20 On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: =20 Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. =20 Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. =20 If you have any more question or comments, pls share in this thread. Thanks. Zhipeng =20 =20 =20 =20 =20 =20 -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. =20 Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. =20 o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. =20 Section 10 Security Considerations =20 Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: =20 a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) =20 The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is determined by the respective CDN's. =20 Scott =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 ------_=_NextPart_001_01CC9422.7284EFD5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I also agree with Ben that content adaptation is an optimization that = is out of scope.  We have enough to do in the WG = already.

 

Kent

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Mark de Jong
Sent: Wednesday, October 26, 2011 1:21 = PM
To: Alan Kavanagh
Cc: cdni@ietf.org; = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Hi = Alan,

 

As Ben stated the overall discussion right now is = about delivery, not on adaptation. It is hard enough to get consensus on = the delivery aspect already not to mention your requirement from content = adaptation added to that, so I agree with Ben we should stick with the = delivery aspect for the first specs. I can imagine this could be a = discussion later on but please let us keep the scope of this be clean = and transparent. It is of benefit of everyone to get the first specs as = fast as possible. Thanks.

 

<= div>

= Met vriendelijke groet,

= Kind regards,=

Mark de Jong
International Business = Developer
Jet-Stream = BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214

<= o:p> 

= - Event:=  = Meet us at Streaming Media Europe, 17-18 October, London, = UK

= - Event:=  Meet us at Online Video Strategies, 19 October, London, = UK

= - Event:=  Meet us at CDN World Summit, 25-28 October, London, = UK

= -=  = News:=  Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com

= - News: Check http://www.jet-stream.com to = download our 'Six Trends in CDNs' brochure

 

= -=  = Blog:=  = www.jet-stream.com/blog/

= -=  = VideoExchange:=  = www.vdo-x.net

= -=  = Streamzilla:=  = www.streamzillacdn.com<= /span>

= -=  = Corporate:=  = www.jet-stream.com

=
<= p class=3DMsoNormal> 

On 26, Oct,2011, at 8:33 PM, Alan Kavanagh = wrote:



Ben

Im assuming then based on your comments = below are you suggesting we are going to have a number of versions of = the CDN-I Metadata?

I sympathise with what you are pointing out = below and do agree that there is some work to be done, but I still feel = that content adaptation is to me a fundamental requirement to what = collectively we should address in the CDN-I WG. I do agree with you that = content adaptation is an optimization between CDN's but it's a very = important one that I know Network Service Providers particularly = require.

Alan

-----Original Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: = October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] = I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On = 12 Oct 2011, at 10:22, ZhouZhipeng wrote:


Hello Ben,

The = UE may select the content format on the CP web. After that the user only = desires to get his selected = content.

But = how the content is transferred to the client is not worried by the = user.

The = CP may create a special format as required by the user and ask the CDN = to deliver to user.

While CP may give a HD format content to uCDN and the = dCDN may then transform to the format as the user = select.


Lots of = things may be possible to do and CDN providers offer many additional = services on top of the "core" service of content delivery. = However, our objective (based on my interpretation of the CDNI charter) = is to focus on what is necessary to interconnect CDNs to deliver content = from a CSP to an End User that is targeted and deployable within a short = time frame (18-24 months).

Content transformation/adaptation is = not an essential requirement in order to achieve that aim (we can = deliver content from CSPs to End Users via multiple CDNs without needing = or requiring any CDN supports content adaptation).

In my opinion = we have enough work to do already without trying to expand the scope of = our work to include additional requirements that do not help us address = our core objectives as laid out in the CDNI = charter.


In this case, it = is nothing related to how the user select formats on CP = website.

So, = it is the CP and user to decide the content format not the CDN(your = assert is not correct and seems you take that assert as your base for = the discussion).

 

As = for "the core CDN functionality offered by CDNs today", I have = ever raised an email before that your company's webpage has claimed = supporting media transformation and multi-screen = service.

Perhaps, I like asking you list some features that you = feel are the core functionalities by existing main stream CDNs. Thus we = may compare and take deep look.


I think the core functionality maps pretty well to = the CDNI interfaces, namely: Request Routing, Metadata configuration, = log production and control plus content acquisition and content = delivery.


I guess many = people have the experience/knowledge of content related service. The = user and CP only care whether the CDN providers may satisfy their = requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in process.

 

Besides, I like raise a = case:

Given currently BBC recruits CDN providers that may = support 10 media formats.

One = candidate is your company, another is CDN-X. The users are located in = France.

So = both your company and CDN-X should connect a France CDN = provider(CDN-Y).

If = your company's solution is to send 10 streams of different = format

of = one content to CDN-Y; While CDN-X's solution is to send 1 stream to = CDN-Y while CDN-Y may conduct some = adaptation.

Comparing these two solutions, for your company and = CDN-X, absolutely the cost of CDN-X is much = lower.

For = CDN-Y, in solution-1, it should receive/forward 10 streams ; while in = solution-2, it should only receive 1 stream but need to take = transformation to output 10 = streams.

 

Which solution is more competitive. it is Solution 1, = right. Remember the price from BBC is same to both your company and = CDN-X or BBC would select one CDN provider with the lower = price.

If a = CDN provider may not get the contract from CP, how it may say it is not = a core functionality.


What you are describing is a possible optimization = that a particular CDN may wish to implement not a core functionality = required to enable content delivery between interconnected CDNs. I can = think of many optimizations that a CDN could implement to differentiate = their service but the internal workings of an individual CDN are out of = scope of our charter.

So to repeat my position for a final time: = Content adaptation is not a core function required to enable content = delivery between interconnected CDNs and therefore given the workload we = already have to specify solutions that do address the core functionality = required to interconnect CDNs I do not think we should be trying to add = more work into that workload as it will only distract us from achieving = our goal of producing deployable solutions within the timeframe we are = being told by operators they needs solutions = within.

Ben


So, if = we all realize that currently the media type is rich, the CDN providers = should survive in the existing ecosystem and support the media types as = required by the market.

 

Back = to the case of GSM/G.711, it just when concerning the interconnection, = the transformation should at once be solved. Otherwise the = interconnection may not be = operated.

 

Br,

Zhipeng

 

 

 

 

-----Original = Message-----

From: Ben Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]

Sent: Wednesday, October 12, 2011 12:19 = AM

To: = ZhouZhipeng

Cc: = philip.eardley@bt.com; cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Zhipeng,

 

On = 11 Oct 2011, at 05:16, ZhouZhipeng = wrote:

 

Ben = and Philip,

I = like to respond your concern in this one = email:

 

Ben,

I = feel what we are now discussing is what is the "core" function = of CDN.

As = you say, CDN is used to deliver content. That is absolutely correct that = the delivery capability is the core requirement for CDN = system.

While CDN is used to provide the content delivery = service.

What = means service. It should include "time" "location" = and "media type", etc. These features are all the core feature = for a service.

If = we only concern "delivering one data block", I am not sure = whether the issues such as "logging" "geographic = constraint" are the core of = CDN.

 

For = "without explicit knowledge of what that content actually is = ", I am not sure whether the wording is accurate since generally a = CDN may claim it support different = medias.

By = this opportunity, I like to share a use case: a call from a GSM phone to = a PSTN telephone, the voice stream should be transformed from GSM voice = to G.711.

For = the user, he does not need to know what type of data has been = transferred, but the operator has done some work to interconnect two = systems, right.

I = like to know whether you may accept that my use case is similar to this = case above.

 

I = don't think your use case is similar to the analogy of mobile networks = being interconnected to PSTN networks. In the case of content delivery = the negotiation is done between the User/Client and the Content Provider = and the CDN is just used to execute/perform the delivery that has been = negotiated. The CDN is not involved in the decision making of what = representations the Content Provider decides to offer to the User/Client = or in what representations the User/Client decides to = request.

 

As = for you said selecting media by the "portal", you may see the = way " uCDN delivers multiple media streams to dCDN" is not = good than "uCDN delivers one media stream to dCDN and dCDN takes = some adaptation to support multiple media = types".

 

Now = what you're talking about is an optimisation, not a core function = required to actually deliver the content (and report, bill, etc. for = that delivery).

 

My = position is that we should focus on how to enable the interconnection of = the core CDN functionality offered by CDNs today (which is also my = interpretation of the scope of the CDNI working group as expressed in = its charter) because doing so is a significant piece of work in itself. = Let's not start trying to add in additional functionality beyond what = the majority of CDNs support today as that will just delay us getting = usable specifications into the market in a timely fashion = IMO.

 

Ben

 

A = good question is "security" since I have done six years on the = DRM

and = like to promote the DRM all around the world:) If the content is needed = to be protected, generally you may know all the systems should be = granted by the content = owner.

Here = I also like to clarify that not only the media itself but the = information related to service itself (such as the geographic = constraint) should be protected = also.

So, = trust is not a problem for the = media.

 

Philip,

Thank you that you feel Content Adaption is an issue = for "Requirements" but I do not know why it is not for Use = case.

I = like to clarify to U that it is important for you operator since it may = save investment if the system may support different = services.

For = us vendor, we are happy operator may install a system for the mobile = service and another system for the FBB = service.

But = the reality is all operators ask us to provide a system that may support = different service = systems.

 

Frankly, Ben and Philip, I remember I have explained = somewhere that to implement this is rather simple = .

At = least the Use case and Requirement are informational to be referred in = future work. So I do really feel you may accept = it.

Of = course I like to respond your more concern and = comments.

Thanks.

Zhipeng

 

 

 

-----Original = Message-----

From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]

Sent: Monday, October 10, 2011 11:22 = PM

To: = ben@niven-jenkins.co.uk; = ZhouZhipeng

Cc: = cdni@ietf.org

Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

=

 

Ben, = Zhipeng, all,

 

I = think that Content Adaptation is more an issue for the Requirements doc = than for the Use cases = draft.

 

The = key question is whether we want the CDNI interfaces to be able to cope = with a scenario where (say) HD/SD conversion is done in the dCDN & = to signal about = this.

 

I = think that coping with this scenario is a second order requirement, ie = we should not worry about it in the initial standards-track work. I = don't know, did we ever decide whether the Use cases doc is restricted = to "initial" scenarios, or whether it's all-encompassing, ie = covering "future" scenarios as = well?

 

Scott,

Reading some of your examples, they seem to be valid = even if content adaptation (HD/SD) is out of = scope.

- a = dCDN might for some reason be unwilling to distribute = HD?

- a = CSP might want to make sure the dCDN can use HLS = encapsulation?

But = these sorts of examples seem to be static policy things (to = do

with = the capabilities & preferences of the CDNs & CSP), rather = than

metadata associated with a particular piece of = content. In the

discussion so far, I think negotiation about static = policy stuff is

rather out of = scope(?)

 

On = security considerations, an interesting question is whether trust is = transitive. Don't think it need be - just because CSP trusts uCDN, and = uCDN trusts dCDN doesn't mean that the CSP automatically trusts the = dCDN. However, i suspect this can get arbitrarily complex - so one = possibility is to say that we will only handle cases where the trust is = transitive.

 

Best = wishes

phil

 

 

Philip = Eardley

Research and Technology = Strategy

 

This = email contains BT information, which may be privileged or confidential. = It's meant only for the individual(s) or entity named above. If you're = not the intended recipient, note that disclosing, copying, distributing = or using this information is prohibited. If you've received this email = in error, please let me know immediately on the email address above. = Thank you. We monitor our email system, and may record your = emails.

British Telecommunications = plc

Registered office: 81 Newgate Street London EC1A 7AJ = Registered in

England no: = 1800000

 

 

-----Original = Message-----

From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On = Behalf

Of = Ben Niven-Jenkins

Sent: 10 October 2011 = 12:04

To: = ZhouZhipeng

Cc: = cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

=

 

Colleagues,

 

IMO = Section 5.1.3 should be removed from the Use Cases draft. Content = Adaptation (i.e. taking in a content item in one format and transforming = it to another format or representation) is not a "core" = function of a CDN which typically delivers the content that is requested = without explicit knowledge of what that content actually = is.

 

Let's not forget that in building an end to end = content service the CDN is only one component and is the component = tasked with executing the delivery of a specific representation = (version/copy/format etc.) of the selected content not the component = tasked with deciding (or applying policy) on which = version/copy/representation of content should be = delivered.

 

The = decision as to which version/copy/representation to offer and allow to = be delivered to a given device/user is implemented outside of the CDN = (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content).

 

Ben

 

On 8 = Oct 2011, at 08:20, ZhouZhipeng = wrote:

 

Following Scott's comments on section 5.1.3, I feel = Scott's description on the use case of HD and SD is not exactly = correct.

If = one movie has two formats of HD and SD, then we have two content with = different identifier. In DRM scope, the basic unit is a content = copy.

 

Here = the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content = adaptation.

In = last month, I have contacted the Authors of this document and taken some = email exchanges with Grant and Philip = (BT).

I = have shown BT with some information that I know in this case and area to = explain the content flexibility is currently a basic requirement for CDN = service and related negotiation is needed in the CDN = interconnection.

Meanwhile, I should also invite you in this group = raising your comments or questions on this case since I hope my use case = may be incorporated in the use case = draft.

 

If = you have any more question or comments, pls share in this = thread.

Thanks.

Zhipeng

 

 

 

 

 

 

-----Original = Message-----

From: Scott Wainner = [mailto:swainner@cisco.com]

Sent: Friday, September 30, 2011 8:02 = AM

To: = cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

=

 

Section 2.3 Nomadic = Users

This = description falls under the category of Geographic = Extension

yet = the third paragraph states the case where a different device = is

used = in the same CDN coverage area.  The intent of this use = case

needs to be clarified.  Perhaps the use case is = trying to = address

the = scenario where a Nomadic User-A with an agreement = allowing

access to content from CSP-A via uCDN moves to a dCDN = in a = different

region.  The dCDN is allowed to distribute the = content of CSP-A = to

User-A; however, not other users in the region of the = dCDN = are

allowed to retrieve the content unless they too have = such an = agreement.

 

Section 5.1.3 Content Encoding Restrictions Need to = clarify if = we're

talking about the restrictions on the delivery of = specific = content

or = the restrictions on the ability of a CDN to deliver = specific

content.  I certainly understand the case where a = CSP will = restrict

the = distribution of content to a "managed path" if such content = is

HD = while allowing the content distribution via an un-managed path = if

such = content is SD (same could apply to encryption methods, = delivery

methods, etc.).  On the contrary, the dCDN may = have its = own

restrictions of blocking the distribution of HD = content = while

allowing the distribution of SD = content.

 

o = first bullet makes sense if the dCDN can perform a subset = of

encapsulations for a reference set of media (e.g. HLS, = HSS, but = not

DASH) o second bullet makes sense where the dCDN = doesn't want = to

offer high bit-rate variants of the media o third = bullet make = sense

if = the policy addresses QoE but I don't think = subscriber

rights/authorizations = apply.

 

Section 10 Security = Considerations

 

Aside from the security considerations WITHIN the uCDN = and dCDN, = I

think we can describe this in four = contexts:

 

a. = The relationship between the CSP and the uCDN (the principle = contract

arrangement for = distribution)

b. = The relationship between the uCDN and dCDN (the transitive = trust

relationship that extends the contract defined in (a) = above) c. = The

relationship between the User and dCDN (the = recognition of right = to

download predicated on (b) above) d. The relationship = between = the

User = and CSP (the contract authorizing the user access to = the

content)

 

The = user is not interested in the a-b nor the b-c relationship. = The

user = is only interested in the transparency and interoperability = of

the = security relationship between d-b or d-c to the point that = the

authorization granted in d-a is viable when the = delivery = is

initiated via either d-b or d-c.  As an example, = the uCDN might = use

URL = appended tokens for authentication while dCDN might use = URL

appended hashes.  The user doesn't want to know = about the = distinct

methods, but transparency is only afforded if the = methods = are

interoperable clearly defined when the delegation for = content

delivery is executed.  Clearly, the choice of = authentication method is determined by the respective = CDN's.

 

Scott

 

_______________________________________________

CDNi = mailing = list

CDNi@ietf.org

https://www.ietf.org/= mailman/listinfo/cdni

 

_______________________________________________

CDNi = mailing list

CDNi@ietf.org

https://www.ietf.org/= mailman/listinfo/cdni

 


______________________________________= _________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/= mailman/listinfo/cdni
____________________________________________= ___
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni

 

------_=_NextPart_001_01CC9422.7284EFD5-- From alan.kavanagh@ericsson.com Wed Oct 26 14:04:11 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8879E11E80AF for ; Wed, 26 Oct 2011 14:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=-0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeVrtzi+4z-y for ; Wed, 26 Oct 2011 14:04:08 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2782611E808A for ; Wed, 26 Oct 2011 14:04:08 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9QL3Y4u001169; Wed, 26 Oct 2011 16:04:01 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.232]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 26 Oct 2011 17:03:47 -0400 From: Alan Kavanagh To: "Kent Leung (kleung)" , Mark de Jong Date: Wed, 26 Oct 2011 17:03:45 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyUHPRtSjiwYJQpTDmB4L6cDKJtXgABUsewAAAVQkA= Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34@EUSAACMS0701.eamcs.ericsson.se> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com><4E8506FC.1020701@cisco.com><260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com><853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk><9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net><260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com><1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk><260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com><166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk><1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> <2979E38DD6FC6544B789C8DAD7BAFC521024D515@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC521024D515@xmb-sjc-235.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34EUSAACMS0701e_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 21:04:11 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So are we defining a limited set of use cases or should we ensure that use = cases at the very least ensure that the realistic use cases both deployed t= oday and ones planed are captured in the use cases document? Alan ________________________________ From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: October-26-11 5:02 PM To: Mark de Jong; Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I also agree with Ben that content adaptation is an optimization that is ou= t of scope. We have enough to do in the WG already. Kent From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Mar= k de Jong Sent: Wednesday, October 26, 2011 1:21 PM To: Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Alan, As Ben stated the overall discussion right now is about delivery, not on ad= aptation. It is hard enough to get consensus on the delivery aspect already= not to mention your requirement from content adaptation added to that, so = I agree with Ben we should stick with the delivery aspect for the first spe= cs. I can imagine this could be a discussion later on but please let us kee= p the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to have= it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs= ' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: Ben Im assuming then based on your comments below are you suggesting we are goi= ng to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that there i= s some work to be done, but I still feel that content adaptation is to me a= fundamental requirement to what collectively we should address in the CDN-= I WG. I do agree with you that content adaptation is an optimization betwee= n CDN's but it's a very important one that I know Network Service Providers= particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: Hello Ben, The UE may select the content format on the CP web. After that the user onl= y desires to get his selected content. But how the content is transferred to the client is not worried by the user= . The CP may create a special format as required by the user and ask the CDN = to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transfo= rm to the format as the user select. Lots of things may be possible to do and CDN providers offer many additiona= l services on top of the "core" service of content delivery. However, our o= bjective (based on my interpretation of the CDNI charter) is to focus on wh= at is necessary to interconnect CDNs to deliver content from a CSP to an En= d User that is targeted and deployable within a short time frame (18-24 mon= ths). Content transformation/adaptation is not an essential requirement in order = to achieve that aim (we can deliver content from CSPs to End Users via mult= iple CDNs without needing or requiring any CDN supports content adaptation)= . In my opinion we have enough work to do already without trying to expand th= e scope of our work to include additional requirements that do not help us = address our core objectives as laid out in the CDNI charter. In this case, it is nothing related to how the user select formats on CP we= bsite. So, it is the CP and user to decide the content format not the CDN(your ass= ert is not correct and seems you take that assert as your base for the disc= ussion). As for "the core CDN functionality offered by CDNs today", I have ever rais= ed an email before that your company's webpage has claimed supporting media= transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core fu= nctionalities by existing main stream CDNs. Thus we may compare and take de= ep look. I think the core functionality maps pretty well to the CDNI interfaces, nam= ely: Request Routing, Metadata configuration, log production and control pl= us content acquisition and content delivery. I guess many people have the experience/knowledge of content related servic= e. The user and CP only care whether the CDN providers may satisfy their re= quirement while not care the internal process. Just as GSM/PSTN interconnec= tion, the user only care successful interconnection while not care how the = voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media format= s. One candidate is your company, another is CDN-X. The users are located in F= rance. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-= Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the c= ost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in s= olution-2, it should only receive 1 stream but need to take transformation = to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the p= rice from BBC is same to both your company and CDN-X or BBC would select on= e CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is no= t a core functionality. What you are describing is a possible optimization that a particular CDN ma= y wish to implement not a core functionality required to enable content del= ivery between interconnected CDNs. I can think of many optimizations that a= CDN could implement to differentiate their service but the internal workin= gs of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core= function required to enable content delivery between interconnected CDNs a= nd therefore given the workload we already have to specify solutions that d= o address the core functionality required to interconnect CDNs I do not thi= nk we should be trying to add more work into that workload as it will only = distract us from achieving our goal of producing deployable solutions withi= n the timeframe we are being told by operators they needs solutions within. Ben So, if we all realize that currently the media type is rich, the CDN provid= ers should survive in the existing ecosystem and support the media types as= required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection,= the transformation should at once be solved. Otherwise the interconnection= may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: Ben and Philip, I like to respond your concern in this one email: Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct that= the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media type", e= tc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether the i= ssues such as "logging" "geographic constraint" are the core of CDN. For "without explicit knowledge of what that content actually is ", I am no= t sure whether the wording is accurate since generally a CDN may claim it s= upport different medias. By this opportunity, I like to share a use case: a call from a GSM phone to= a PSTN telephone, the voice stream should be transformed from GSM voice to= G.711. For the user, he does not need to know what type of data has been transferr= ed, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to this c= ase above. I don't think your use case is similar to the analogy of mobile networks be= ing interconnected to PSTN networks. In the case of content delivery the ne= gotiation is done between the User/Client and the Content Provider and the = CDN is just used to execute/perform the delivery that has been negotiated. = The CDN is not involved in the decision making of what representations the = Content Provider decides to offer to the User/Client or in what representat= ions the User/Client decides to request. As for you said selecting media by the "portal", you may see the way " uCDN= delivers multiple media streams to dCDN" is not good than "uCDN delivers o= ne media stream to dCDN and dCDN takes some adaptation to support multiple = media types". Now what you're talking about is an optimisation, not a core function requi= red to actually deliver the content (and report, bill, etc. for that delive= ry). My position is that we should focus on how to enable the interconnection of= the core CDN functionality offered by CDNs today (which is also my interpr= etation of the scope of the CDNI working group as expressed in its charter)= because doing so is a significant piece of work in itself. Let's not start= trying to add in additional functionality beyond what the majority of CDNs= support today as that will just delay us getting usable specifications int= o the market in a timely fashion IMO. Ben A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) If the content is needed= to be protected, generally you may know all the systems should be granted = by the content owner. Here I also like to clarify that not only the media itself but the informat= ion related to service itself (such as the geographic constraint) should be= protected also. So, trust is not a problem for the media. Philip, Thank you that you feel Content Adaption is an issue for "Requirements" but= I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it may s= ave investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile se= rvice and another system for the FBB service. But the reality is all operators ask us to provide a system that may suppor= t different service systems. Frankly, Ben and Philip, I remember I have explained somewhere that to impl= ement this is rather simple . At least the Use case and Requirement are informational to be referred in f= uture work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng -----Original Message----- From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ben, Zhipeng, all, I think that Content Adaptation is more an issue for the Requirements doc t= han for the Use cases draft. The key question is whether we want the CDNI interfaces to be able to cope = with a scenario where (say) HD/SD conversion is done in the dCDN & to signa= l about this. I think that coping with this scenario is a second order requirement, ie we= should not worry about it in the initial standards-track work. I don't kno= w, did we ever decide whether the Use cases doc is restricted to "initial" = scenarios, or whether it's all-encompassing, ie covering "future" scenarios= as well? Scott, Reading some of your examples, they seem to be valid even if content adapta= tion (HD/SD) is out of scope. - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) On security considerations, an interesting question is whether trust is tra= nsitive. Don't think it need be - just because CSP trusts uCDN, and uCDN tr= usts dCDN doesn't mean that the CSP automatically trusts the dCDN. However,= i suspect this can get arbitrarily complex - so one possibility is to say = that we will only handle cases where the trust is transitive. Best wishes phil Philip Eardley Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adapt= ation (i.e. taking in a content item in one format and transforming it to a= nother format or representation) is not a "core" function of a CDN which ty= pically delivers the content that is requested without explicit knowledge o= f what that content actually is. Let's not forget that in building an end to end content service the CDN is = only one component and is the component tasked with executing the delivery = of a specific representation (version/copy/format etc.) of the selected con= tent not the component tasked with deciding (or applying policy) on which v= ersion/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to = be delivered to a given device/user is implemented outside of the CDN (e.g.= by the "portal" where the user first makes their content selection prior t= o the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: Following Scott's comments on section 5.1.3, I feel Scott's description on = the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with di= fferent identifier. In DRM scope, the basic unit is a content copy. Here the first bullet "a subset of encodings deliverable to specific device= s," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken some= email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area to = explain the content flexibility is currently a basic requirement for CDN se= rvice and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments or = questions on this case since I hope my use case may be incorporated in the = use case draft. If you have any more question or comments, pls share in this thread. Thanks. Zhipeng -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. Section 10 Security Considerations Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is dete= rmined by the respective CDN's. Scott _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So are we defining a limited set of use cases or s= hould we=20 ensure that use cases at the very least ensure that the realistic use cases= both=20 deployed today and ones planed are captured in the use cases document?=20
 
Alan

From: Kent Leung (kleung)=20 [mailto:kleung@cisco.com]
Sent: October-26-11 5:02 PM
To:<= /B>=20 Mark de Jong; Alan Kavanagh
Cc: cdni@ietf.org;=20 ZhouZhipeng
Subject: RE: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

I=20 also agree with Ben that content adaptation is an optimization that is out = of=20 scope.  We have enough to do in the WG already.

 

Kent

 

From:<= /B>=20 cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ma= rk de=20 Jong
Sent: Wednesday, October 26, 2011 1:21 PM
To: Alan= =20 Kavanagh
Cc: cdni@ietf.org; ZhouZhipeng
Subject: Re: [C= DNi]=20 I-D Action: draft-ietf-cdni-use-cases-00.txt

 

Hi Alan,

 

As Ben stated the overall discussion right now is abou= t=20 delivery, not on adaptation. It is hard enough to get consensus on the deli= very=20 aspect already not to mention your requirement from content adaptation adde= d to=20 that, so I agree with Ben we should stick with the delivery aspect for the = first=20 specs. I can imagine this could be a discussion later on but please le= t us=20 keep the scope of this be clean and transparent. It is of benefit of everyo= ne to=20 get the first specs as fast as possible. Thanks.

 

 

 

On 26, Oct,2011, at 8:33 PM, Alan Kavanagh=20 wrote:



Ben

Im assuming then based on your comments bel= ow are=20 you suggesting we are going to have a number of versions of the CDN-I=20 Metadata?

I sympathise with what you are pointing out below and do a= gree=20 that there is some work to be done, but I still feel that content adaptatio= n is=20 to me a fundamental requirement to what collectively we should address in t= he=20 CDN-I WG. I do agree with you that content adaptation is an optimization be= tween=20 CDN's but it's a very important one that I know Network Service Providers=20 particularly require.

Alan

-----Original Message-----
From= : cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent:=20 October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D = Action:=20 draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 12 Oct 2011, at= =20 10:22, ZhouZhipeng wrote:


Hello Ben,

The UE may select the content format on the CP web. = After=20 that the user only desires to get his selected=20 content.

But how the content is transferred to the client is = not=20 worried by the user.

The CP may create a special format as required by th= e user=20 and ask the CDN to deliver to user.

While CP may give a HD format content to uCDN and th= e dCDN=20 may then transform to the format as the user select.


Lots of things may be possible to do and CDN provi= ders=20 offer many additional services on top of the "core" service of content deli= very.=20 However, our objective (based on my interpretation of the CDNI charter) is = to=20 focus on what is necessary to interconnect CDNs to deliver content from a C= SP to=20 an End User that is targeted and deployable within a short time frame (18-2= 4=20 months).

Content transformation/adaptation is not an essential=20 requirement in order to achieve that aim (we can deliver content from CSPs = to=20 End Users via multiple CDNs without needing or requiring any CDN supports=20 content adaptation).

In my opinion we have enough work to do already= =20 without trying to expand the scope of our work to include additional=20 requirements that do not help us address our core objectives as laid out in= the=20 CDNI charter.


In this case, it is nothing related to how the user se= lect=20 formats on CP website.

So, it is the CP and user to decide the content form= at not=20 the CDN(your assert is not correct and seems you take that assert as your= base=20 for the discussion).

 

As for "the core CDN functionality offered by CDNs t= oday",=20 I have ever raised an email before that your company's webpage has claime= d=20 supporting media transformation and multi-screen=20 service.

Perhaps, I like asking you list some features that y= ou feel=20 are the core functionalities by existing main stream CDNs. Thus we may co= mpare=20 and take deep look.


I think the core functionality maps pretty well to= the=20 CDNI interfaces, namely: Request Routing, Metadata configuration, log produ= ction=20 and control plus content acquisition and content=20 delivery.


I guess many people have the experience/knowledge of c= ontent=20 related service. The user and CP only care whether the CDN providers may sa= tisfy=20 their requirement while not care the internal process. Just as GSM/PSTN=20 interconnection, the user only care successful interconnection while not ca= re=20 how the voice is transformed in process.

 

Besides, I like raise a case:

Given currently BBC recruits CDN providers that may = support=20 10 media formats.

One candidate is your company, another is CDN-X. The= users=20 are located in France.

So both your company and CDN-X should connect a Fran= ce CDN=20 provider(CDN-Y).

If your company's solution is to send 10 streams of= =20 different format

of one content to CDN-Y; While CDN-X's solution is t= o send=20 1 stream to CDN-Y while CDN-Y may conduct some=20 adaptation.

Comparing these two solutions, for your company and = CDN-X,=20 absolutely the cost of CDN-X is much lower.

For CDN-Y, in solution-1, it should receive/forward = 10=20 streams ; while in solution-2, it should only receive 1 stream but need t= o=20 take transformation to output 10 streams.

 

Which solution is more competitive. it is Solution 1= ,=20 right. Remember the price from BBC is same to both your company and CDN-X= or=20 BBC would select one CDN provider with the lower=20 price.

If a CDN provider may not get the contract from CP, = how it=20 may say it is not a core functionality.


What you are describing is a possible optimization= that a=20 particular CDN may wish to implement not a core functionality required to e= nable=20 content delivery between interconnected CDNs. I can think of many optimizat= ions=20 that a CDN could implement to differentiate their service but the internal= =20 workings of an individual CDN are out of scope of our charter.

So to= =20 repeat my position for a final time: Content adaptation is not a core funct= ion=20 required to enable content delivery between interconnected CDNs and therefo= re=20 given the workload we already have to specify solutions that do address the= core=20 functionality required to interconnect CDNs I do not think we should be try= ing=20 to add more work into that workload as it will only distract us from achiev= ing=20 our goal of producing deployable solutions within the timeframe we are bein= g=20 told by operators they needs solutions=20 within.

Ben


So, if we all realize that currently the media type is= rich,=20 the CDN providers should survive in the existing ecosystem and support the = media=20 types as required by the market.

 

Back to the case of GSM/G.711, it just when concerni= ng the=20 interconnection, the transformation should at once be solved. Otherwise t= he=20 interconnection may not be operated.

 

Br,

Zhipeng

 

 

 

 

-----Original Message-----

From: Ben Niven-Jenkins=20 [mailto:ben@niven-jenkins.co.uk]

Sent: Wednesday, October 12, 2011 12:19=20 AM

To: ZhouZhipeng

Cc: philip.eardley@bt.com; cdni@ietf.org

Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

 

Zhipeng,

 

On 11 Oct 2011, at 05:16, ZhouZhipeng=20 wrote:

 

Ben and Philip,

I like to respond your concern in this one=20 email:

 

Ben,

I feel what we are now discussing is what is the "= core"=20 function of CDN.

As you say, CDN is used to deliver content. That i= s=20 absolutely correct that the delivery capability is the core requirement= for=20 CDN system.

While CDN is used to provide the content delivery= =20 service.

What means service. It should include "time" "loca= tion"=20 and "media type", etc. These features are all the core feature for a=20 service.

If we only concern "delivering one data block", I = am not=20 sure whether the issues such as "logging" "geographic constraint" are t= he=20 core of CDN.

 

For "without explicit knowledge of what that conte= nt=20 actually is ", I am not sure whether the wording is accurate since gene= rally=20 a CDN may claim it support different=20 medias.

By this opportunity, I like to share a use case: a= call=20 from a GSM phone to a PSTN telephone, the voice stream should be transf= ormed=20 from GSM voice to G.711.

For the user, he does not need to know what type o= f data=20 has been transferred, but the operator has done some work to interconne= ct=20 two systems, right.

I like to know whether you may accept that my use = case is=20 similar to this case above.

 

I don't think your use case is similar to the analog= y of=20 mobile networks being interconnected to PSTN networks. In the case of con= tent=20 delivery the negotiation is done between the User/Client and the Content= =20 Provider and the CDN is just used to execute/perform the delivery that ha= s=20 been negotiated. The CDN is not involved in the decision making of what=20 representations the Content Provider decides to offer to the User/Client = or in=20 what representations the User/Client decides to=20 request.

 

As for you said selecting media by the "portal", y= ou may=20 see the way " uCDN delivers multiple media streams to dCDN" is not good= than=20 "uCDN delivers one media stream to dCDN and dCDN takes some adaptation = to=20 support multiple media types".

 

Now what you're talking about is an optimisation, no= t a=20 core function required to actually deliver the content (and report, bill,= etc.=20 for that delivery).

 

My position is that we should focus on how to enable= the=20 interconnection of the core CDN functionality offered by CDNs today (whic= h is=20 also my interpretation of the scope of the CDNI working group as expresse= d in=20 its charter) because doing so is a significant piece of work in itself. L= et's=20 not start trying to add in additional functionality beyond what the major= ity=20 of CDNs support today as that will just delay us getting usable specifica= tions=20 into the market in a timely fashion IMO.

 

Ben

 

A good question is "security" since I have done si= x years=20 on the DRM

and like to promote the DRM all around the world:)= If the=20 content is needed to be protected, generally you may know all the syste= ms=20 should be granted by the content owner.

Here I also like to clarify that not only the medi= a=20 itself but the information related to service itself (such as the geogr= aphic=20 constraint) should be protected also.

So, trust is not a problem for the=20 media.

 

Philip,

Thank you that you feel Content Adaption is an iss= ue for=20 "Requirements" but I do not know why it is not for Use=20 case.

I like to clarify to U that it is important for yo= u=20 operator since it may save investment if the system may support differe= nt=20 services.

For us vendor, we are happy operator may install a= system=20 for the mobile service and another system for the FBB=20 service.

But the reality is all operators ask us to provide= a=20 system that may support different service=20 systems.

 

Frankly, Ben and Philip, I remember I have explain= ed=20 somewhere that to implement this is rather simple=20 .

At least the Use case and Requirement are informat= ional=20 to be referred in future work. So I do really feel you may accept=20 it.

Of course I like to respond your more concern and= =20 comments.

Thanks.

Zhipeng

 

 

 

-----Original=20 Message-----

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]

Sent: Monday, October 10, 2011 11:22=20 PM

To: ben@niven-jenkins.co.uk;=20 ZhouZhipeng

Cc: cdni@ietf.org

Subject: RE: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

 

Ben, Zhipeng, all,

 

I think that Content Adaptation is more an issue f= or the=20 Requirements doc than for the Use cases=20 draft.

 

The key question is whether we want the CDNI inter= faces=20 to be able to cope with a scenario where (say) HD/SD conversion is done= in=20 the dCDN & to signal about this.

 

I think that coping with this scenario is a second= order=20 requirement, ie we should not worry about it in the initial standards-t= rack=20 work. I don't know, did we ever decide whether the Use cases doc is=20 restricted to "initial" scenarios, or whether it's all-encompassing, ie= =20 covering "future" scenarios as well?

 

Scott,

Reading some of your examples, they seem to be val= id even=20 if content adaptation (HD/SD) is out of=20 scope.

- a dCDN might for some reason be unwilling to dis= tribute=20 HD?

- a CSP might want to make sure the dCDN can use H= LS=20 encapsulation?

But these sorts of examples seem to be static poli= cy=20 things (to do

with the capabilities & preferences of the CDN= s &=20 CSP), rather than

metadata associated with a particular piece of con= tent.=20 In the

discussion so far, I think negotiation about stati= c=20 policy stuff is

rather out of=20 scope(?)

 

On security considerations, an interesting questio= n is=20 whether trust is transitive. Don't think it need be - just because CSP= =20 trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatical= ly=20 trusts the dCDN. However, i suspect this can get arbitrarily complex - = so=20 one possibility is to say that we will only handle cases where the trus= t is=20 transitive.

 

Best wishes

phil

 

 

Philip Eardley

Research and Technology=20 Strategy

 

This email contains BT information, which may be=20 privileged or confidential. It's meant only for the individual(s) or en= tity=20 named above. If you're not the intended recipient, note that disclosing= ,=20 copying, distributing or using this information is prohibited. If you'v= e=20 received this email in error, please let me know immediately on the ema= il=20 address above. Thank you. We monitor our email system, and may record y= our=20 emails.

British Telecommunications=20 plc

Registered office: 81 Newgate Street London EC1A 7= AJ=20 Registered in

England no: 1800000

 

 

-----Original=20 Message-----

From: cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On=20 Behalf

Of Ben Niven-Jenkins

Sent: 10 October 2011=20 12:04

To: ZhouZhipeng

Cc: cdni@ietf.org

Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

 

Colleagues,

 

IMO Section 5.1.3 should be removed from the Use C= ases=20 draft. Content Adaptation (i.e. taking in a content item in one format = and=20 transforming it to another format or representation) is not a "core"=20 function of a CDN which typically delivers the content that is requeste= d=20 without explicit knowledge of what that content actually=20 is.

 

Let's not forget that in building an end to end co= ntent=20 service the CDN is only one component and is the component tasked with= =20 executing the delivery of a specific representation (version/copy/forma= t=20 etc.) of the selected content not the component tasked with deciding (o= r=20 applying policy) on which version/copy/representation of content should= be=20 delivered.

 

The decision as to which version/copy/representati= on to=20 offer and allow to be delivered to a given device/user is implemented=20 outside of the CDN (e.g. by the "portal" where the user first makes the= ir=20 content selection prior to the CDN becoming involved in the delivery of= the=20 selected content).

 

Ben

 

On 8 Oct 2011, at 08:20, ZhouZhipeng=20 wrote:

 

Following Scott's comments on section 5.1.3, I f= eel=20 Scott's description on the use case of HD and SD is not exactly=20 correct.

If one movie has two formats of HD and SD, then = we have=20 two content with different identifier. In DRM scope, the basic unit i= s a=20 content copy.

 

<= /BLOCKQUOTE>

Here the first bullet "a subset of encodings=20 deliverable to specific devices," has listed the case of content=20 adaptation.

In last month, I have contacted the Authors of t= his=20 document and taken some email exchanges with Grant and Philip=20 (BT).

I have shown BT with some information that I kno= w in=20 this case and area to explain the content flexibility is currently a = basic=20 requirement for CDN service and related negotiation is needed in the = CDN=20 interconnection.

Meanwhile, I should also invite you in this grou= p=20 raising your comments or questions on this case since I hope my use c= ase=20 may be incorporated in the use case=20 draft.

 

<= /BLOCKQUOTE>

If you have any more question or comments, pls s= hare in=20 this thread.

Thanks.

=

Zhipeng

=

 

<= /BLOCKQUOTE>

 

<= /BLOCKQUOTE>

 

<= /BLOCKQUOTE>

 

<= /BLOCKQUOTE>

 

<= /BLOCKQUOTE>

 

<= /BLOCKQUOTE>

-----Original=20 Message-----

From: Scott Wainner=20 [mailto:swainner@cisco.com]

<= /BLOCKQUOTE>

Sent: Friday, September 30, 2011 8:02=20 AM

To: cdni@ietf.org

Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

 

<= /BLOCKQUOTE>

Section 2.3 Nomadic=20 Users

This description falls under the category of Geo= graphic=20 Extension

yet the third paragraph states the case where a= =20 different device is

used in the same CDN coverage area.  The in= tent of=20 this use case

needs to be clarified.  Perhaps the use cas= e is=20 trying to address

the scenario where a Nomadic User-A with an agre= ement=20 allowing

access to content from CSP-A via uCDN moves to a= dCDN=20 in a different

region.  The dCDN is allowed to distribute = the=20 content of CSP-A to

User-A; however, not other users in the region o= f the=20 dCDN are

allowed to retrieve the content unless they too = have=20 such an agreement.

 

<= /BLOCKQUOTE>

Section 5.1.3 Content Encoding Restrictions Need= to=20 clarify if we're

talking about the restrictions on the delivery o= f=20 specific content

or the restrictions on the ability of a CDN to d= eliver=20 specific

content.  I certainly understand the case w= here a=20 CSP will restrict

the distribution of content to a "managed path" = if such=20 content is

HD while allowing the content distribution via a= n=20 un-managed path if

such content is SD (same could apply to encrypti= on=20 methods, delivery

methods, etc.).  On the contrary, the dCDN = may=20 have its own

restrictions of blocking the distribution of HD = content=20 while

allowing the distribution of SD=20 content.

 

<= /BLOCKQUOTE>

o first bullet makes sense if the dCDN can perfo= rm a=20 subset of

encapsulations for a reference set of media (e.g= . HLS,=20 HSS, but not

DASH) o second bullet makes sense where the dCDN= =20 doesn't want to

offer high bit-rate variants of the media o thir= d=20 bullet make sense

if the policy addresses QoE but I don't think=20 subscriber

rights/authorizations=20 apply.

 

<= /BLOCKQUOTE>

Section 10 Security=20 Considerations

 

<= /BLOCKQUOTE>

Aside from the security considerations WITHIN th= e uCDN=20 and dCDN, I

think we can describe this in four=20 contexts:

 

<= /BLOCKQUOTE>

a. The relationship between the CSP and the uCDN= (the=20 principle contract

arrangement for=20 distribution)

b. The relationship between the uCDN and dCDN (t= he=20 transitive trust

relationship that extends the contract defined i= n (a)=20 above) c. The

relationship between the User and dCDN (the reco= gnition=20 of right to

download predicated on (b) above) d. The relatio= nship=20 between the

User and CSP (the contract authorizing the user = access=20 to the

content)

 

<= /BLOCKQUOTE>

The user is not interested in the a-b nor the b-= c=20 relationship. The

user is only interested in the transparency and= =20 interoperability of

the security relationship between d-b or d-c to = the=20 point that the

authorization granted in d-a is viable when the= =20 delivery is

initiated via either d-b or d-c.  As an exa= mple,=20 the uCDN might use

URL appended tokens for authentication while dCD= N might=20 use URL

appended hashes.  The user doesn't want to = know=20 about the distinct

methods, but transparency is only afforded if th= e=20 methods are

interoperable clearly defined when the delegatio= n for=20 content

delivery is executed.  Clearly, the choice = of=20 authentication method is determined by the respective=20 CDN's.

 

<= /BLOCKQUOTE>

Scott

 

<= /BLOCKQUOTE>
_______________________________________________

CDNi mailing=20 list

CDNi@ietf.org

https://www.ietf.= org/mailman/listinfo/cdni

 

_______________________________________________<= /o:p>

CDNi mailing list

CDNi@ietf.org

https://www.ietf.or= g/mailman/listinfo/cdni

 


_________________________________________= ______
CDNi=20 mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni
_______________________________________________<= BR>CDNi=20 mailing list
CDNi@ietf.org
https://www.ietf.org/mai= lman/listinfo/cdni

 

--_000_1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34EUSAACMS0701e_-- From lijincheng@huawei.com Wed Oct 26 19:35:03 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 978B221F8ADE for ; Wed, 26 Oct 2011 19:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZVo+KZuqZ-u for ; Wed, 26 Oct 2011 19:35:02 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4122E21F8AD6 for ; Wed, 26 Oct 2011 19:35:02 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTP007YNDU3VD@szxga03-in.huawei.com> for cdni@ietf.org; Thu, 27 Oct 2011 10:34:51 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTP0010QDT672@szxga03-in.huawei.com> for cdni@ietf.org; Thu, 27 Oct 2011 10:34:51 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEL49388; Thu, 27 Oct 2011 10:34:50 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 27 Oct 2011 10:34:45 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.75]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 10:34:44 +0800 Date: Thu, 27 Oct 2011 02:34:44 +0000 From: "Will Li(jincheng)" In-reply-to: X-Originating-IP: [10.144.242.41] To: Ben Niven-Jenkins Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?tPC4tDogW0NETmldIFByZXBhcmluZyBkcmFmdC1pZXRmLWNkbmktcHJvYmxl?= =?gb2312?Q?m-statement_for_WG_Last_Call?= Thread-index: AQHMjL1M8UDFDgdACEqAzOaAom66QJWDZJBwgAewLQCABG8hQA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> Cc: "cdni@ietf.org" Subject: Re: [CDNi] =?gb2312?b?tPC4tDogIFByZXBhcmluZyBkcmFmdC1pZXRmLWNkbmkt?= =?gb2312?b?cHJvYmxlbS1zdGF0ZW1lbnQgZm9yIFdHIExhc3QgQ2FsbA==?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 02:35:03 -0000 SGksIEJlbiwNCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2UsIGZ1cnRoZXIgdGhvdWdodCBpbiBs aW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbiBOaXZlbi1K ZW5raW5zIFttYWlsdG86YmVuQG5pdmVuLWplbmtpbnMuY28udWtdDQo+IFNlbnQ6IE1vbmRheSwg T2N0b2JlciAyNCwgMjAxMSAxMDozNSBQTQ0KPiBUbzogV2lsbCBMaShqaW5jaGVuZykNCj4gQ2M6 IGNkbmlAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6ILTwuLQ6IFtDRE5pXSBQcmVwYXJpbmcgZHJh ZnQtaWV0Zi1jZG5pLXByb2JsZW0tc3RhdGVtZW50IGZvciBXRw0KPiBMYXN0IENhbGwNCj4gDQo+ IFdpbGwsDQo+IA0KPiBUaGFua3MgZm9yIHJldmlld2luZyB0aGUgZHJhZnQgJiBwcm9wb3NlZCBj aGFuZ2VzLCBteSBvcGluaW9uIGlzIGlubGluZSBiZWxvdy4NCj4gDQo+IE9uIDE5IE9jdCAyMDEx LCBhdCAxMDoyNCwgV2lsbCBMaShqaW5jaGVuZykgd3JvdGU6DQo+IA0KPiA+IEhpLCBCZW4sDQo+ ID4NCj4gPiBUaGFuayB5b3UgZm9yIHRoZSBlZmZvcnRzLiBUd28gbW9yZSBjb21tZW50cy4NCj4g PiAxKSBJbiBzZWN0aW9uIDMsIGRvIHlvdSB0aGluayBpdCBpcyBoZWxwZnVsIHRvIGFkZCBzb21l IGRlc2NyaXB0aW9uIG9uIGVhY2ggcm9sZQ0KPiAoaS5lLiBDUCwgVXBzdHJlYW0gQ0ROLCBEb3du c3RyZWFtIENETiksIGFuZCB0aGVpciBidXNpbmVzcyByZWxhdGlvbnNoaXBzDQo+IGFzc3VtZWQg aW4gQ0ROST8NCj4gPiAgVGhpcyBjb3VsZCBmYWNpbGl0YXRlIHBlb3BsZSB0byB1bmRlcnN0YW5k IHRoZSBmaWd1cmUgYW5kIHRoZSBkcmFmdCBiZXR0ZXIuDQo+IA0KPiBUaGUgZGlmZmVyZW50IHJv bGVzIGFyZSBkZWZpbmVkIGFzIHBhcnQgb2YgdGhlIHRlcm1pbm9sb2d5IGluIFNlY3Rpb24gMS4x Lg0KDQpJIHNlZS4gVGhhbmtzLg0KDQo+IA0KPiBJIGRvbid0IHRoaW5rIHRoZSBQcm9ibGVtIFN0 YXRlbWVudCBkcmFmdCBzaG91bGQgdHJ5IHRvIGRlc2NyaWJlIHRoZSBkaWZmZXJlbnQNCj4gYnVz aW5lc3MgcmVsYXRpb25zaGlwcyBhcyB0aGV5IGFyZSBtYW55IGFuZCB2YXJpZWQgZGVwZW5kaW5n IG9uIHRoaW5ncyBsaWtlIHRoZQ0KPiBwdXJwb3NlIG9mIHRoZSBzcGVjaWZpYyBDRE4sIHRoZSBt YXJrZXQgaXQgaXMgZGVwbG95ZWQgaW4gZXRjIGFuZCBpdCB3b3VsZCBiZSB2ZXJ5DQo+IGRpZmZp Y3VsdCB0byBkZXNjcmliZSBhbGwgdGhlIGRpZmZlcmVudCBidXNpbmVzcyByZWxhdGlvbnNoaXBz IGFuZCB3ZSB3b3VsZCByaXNrDQo+IGdldHRpbmcgZGlzdHJhY3RlZCBieSBjb21tZW50cyBhbG9u ZyB0aGUgbGluZXMgb2YgIndoYXQgYWJvdXQgdGhpcyBidXNpbmVzcw0KPiByZWxhdGlvbnNoaXAg dGhhdCB5b3UgaGF2ZW4ndCBkZXNjcmliZWQiIGFuZCAieW91IGhhdmVuJ3QgYWRlcXVhdGVseSBj YXB0dXJlZA0KPiBob3cgdGhpcyByZWxhdGlvbnNoaXAgY291bGQgd29yayIgZXRjLg0KPiANCj4g U2VjdGlvbiAxLjIgYWxyZWFkeSBzdGF0ZXMgdGhhdCAiUmVhZGVycyBhcmUgYXNzdW1lZCB0byBi ZSBmYW1pbGlhciB3aXRoIHRoZQ0KPiBhcmNoaXRlY3R1cmUsIGZlYXR1cmVzIGFuZCBvcGVyYXRp b24gb2YgQ0ROcy4iIGFuZCBJIGFzc3VtZSBpZiByZWFkZXJzIGFscmVhZHkNCj4gaGF2ZSB0aGF0 IGZhbWlsaWFyaXR5IHdpdGggaG93IENETnMgd29yayAmIGFyZSBvcGVyYXRlZCB0aGVuIHRoZXkg Y2FuDQo+IHVuZGVyc3RhbmQgaG93IENTUHMsIHVwc3RyZWFtIENETnMsIGRvd25zdHJlYW0gQ0RO cyBtYXkgZml0IHRvZ2V0aGVyIGFzDQo+IHBhcnQgb2YgdGhlIENETkkgcmVmZXJlbmNlIG1vZGVs Lg0KPiANCkFncmVlIGluYXBwcm9wcmlhdGUgZGVzY3JpcHRpb24gbWF5IGxlYWQgY29uZnVzaW9u LiBIb3dldmVyLCBJIGFtIHRoaW5raW5nIG9mIHNvbWUgZ2VuZXJhbCBidXQgc2FmZSBkZXNjcmlw dGlvbnMgb24gdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGVzZSByb2xlcywgbGlrZSANCiJJbiBhIHR5 cGljYWwgY29udGVudCBkZWxpdmVyeSBzZXJ2aWNlLCBBIENTUCBjb250cmFjdHMgd2l0aCBhbiB1 cHN0cmVhbSBDRE4gdG8gc3RvcmUgYW5kIGRlbGl2ZXIgY29udGVudCB0byBVc2VyIEFnZW50czsg dGhlIHVwc3RyZWFtIENETiBmdXJ0aGVyIGNvbnRyYWN0cyB3aXRoIG9uZSBvciBtb3JlIGRvd25z dHJlYW0gQ0ROKHMpIHRvIGRpc3RyaWJ1dGUgYW5kIGRlbGl2ZXIgY29udGVudHMgb24gdUNETqGv cyBiZWhhbGYuIEhvd2V2ZXIsIHRoZXNlIGJ1c2luZXNzIHJlbGF0aW9uc2hpcHMgYXJlIG91dCBv ZiBzY29wZSBvZiBDRE5JLiIsIGlmIHRoaXMga2luZCBvZiBkZXNjcmlwdGlvbiBpcyBzYWZlIHRv IGJlIGFkZGVkIGJlbG93IHRoZSBmaWd1cmUsIHRoZW4gaXQgY2FuIGVhc2UgcGVvcGxlIHRvIHVu ZGVyc3RhbmQgdGhlIGZvbGxvd2luZyBzdGFmZiBpbiB0aGlzIGRyYWZ0Lg0KDQo+ID4NCj4gPiAy KUFub3RoZXIgZWRpdG9yaWFsIG9uZTogSW4gYnVsbGV0IDUgb2YgeW91ciBwcmV2aW91cyBtYWls LCBjaGFuZ2luZyBJVFUgdG8gSVRVLVQNCj4gY291bGQgYmUgbW9yZSBzcGVjaWZpYy4NCj4gDQo+ IEdvb2QgY2F0Y2ghIEkgd2lsbCB1c2UgSVRVLVQgd2hlbiBJIHVwZGF0ZSB0aGUgZHJhZnQuDQo+ IA0KPiBCZW4NCj4gDQo+ID4NCj4gPiBCUiwgV2lsbA0KPiA+DQo+ID4gLS0tLS3Tyrz+1K28/i0t LS0tDQo+ID4gt6K8/sjLOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjZG5pLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gQmVuDQo+IE5pdmVuLUplbmtpbnMNCj4gPiC3osvNyrG85DogMjAx McTqMTDUwjE3yNUgMTk6MDgNCj4gPiDK1bz+yMs6IGNkbmlAaWV0Zi5vcmcNCj4gPiDW98ziOiBb Q0ROaV0gUHJlcGFyaW5nIGRyYWZ0LWlldGYtY2RuaS1wcm9ibGVtLXN0YXRlbWVudCBmb3IgV0cg TGFzdCBDYWxsDQo+ID4NCj4gPiBDb2xsZWFndWVzLA0KPiA+DQo+ID4gQXQgdGhlIGxhc3QgSUVU RiBJIHNhaWQgSSB3b3VsZCB0cnkgdG8gcHJlcGFyZSBhIHZlcnNpb24gb2YgdGhlIENETkkgcHJv YmxlbQ0KPiBTdGF0ZW1lbnQgKGRyYWZ0LWlldGYtY2RuaS1wcm9ibGVtLXN0YXRlbWVudCkgdGhh dCBpcyByZWFkeSBmb3IgV0cgTGFzdCBDYWxsDQo+IGJlZm9yZSBJRVRGODIgaW4gVGFpcGVpLg0K PiA+DQo+ID4gQXMgcGFydCBvZiB0aGF0IEkgaGF2ZSByZXZpZXdlZCB0aGUgY29tcGxldGUgZHJh ZnQgYW5kIG1hZGUgc29tZSBtaW5vcg0KPiBlZGl0b3JpYWwgY2xlYW4tdXBzIHRvIG15IHdvcmtp bmcgY29weS4gSG93ZXZlciwgdGhlcmUgd2VyZSBhIG51bWJlciBvZiBvdGhlcg0KPiBhcmVhcyB3 aGVyZSBJIHRoaW5rIGNoYW5nZXMgbmVlZCB0byBiZSBtYWRlIHRvIHRoZSBkb2N1bWVudCB0aGF0 IEkgdGhpbmsNCj4gd2FycmFudCB3aWRlciBXRyByZXZpZXcvY29uc2Vuc3VzIGFuZCBJIGhhdmUg bGlzdGVkIHRoZW0gYmVsb3cgYWxvbmcgd2l0aA0KPiB0aGUgY2hhbmdlcyBJIGFtIHByb3Bvc2lu Zy4NCj4gPg0KPiA+IENvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSB5b3VyIGZlZWRiYWNrIG9uIHRo ZSBhcmVhcy9wcm9wb3NlZCB0ZXh0IEkgaGF2ZQ0KPiBoaWdobGlnaHRlZCBiZWxvdyBhcyB3ZWxs IGFzIGFueSBvdGhlciBhcmVhcyBvZiB0aGUgZG9jdW1lbnQgdGhhdCB5b3UgdGhpbmsNCj4gcmVx dWlyZSBhZGRpdGlvbmFsIHdvcmsvY2xlYW51cCBiZWZvcmUgeW91IGNvbnNpZGVyIHRoZSBkb2N1 bWVudCBpcyByZWFkeSBmb3IgYQ0KPiBXRyBMYXN0IENhbGwuDQo+ID4NCj4gPiAxKSBTZWN0aW9u IDI6IFVwZGF0ZSB0aGUgbGFzdCBwYXJhZ3JhcGggdG8gcmVmZXJlbmNlIHRoZSBXRyBkcmFmdCBm b3IgQ0ROSSB1c2UNCj4gY2FzZXMgYW5kIHJlbW92ZSByZWZlcmVuY2UgdG8gZHJhZnQtd2F0c29u LWNkbmktdXNlLWNhc2VzLCBpLmUuDQo+ID4NCj4gPiBPTEQ6DQo+ID4gICBVc2UgY2FzZXMgZm9y IENETiBJbnRlcmNvbm5lY3Rpb24gYXJlIGZ1cnRoZXIgZGlzY3Vzc2VkIGluDQo+ID4gICBbSS1E LmJlcnRyYW5kLWNkbmktdXNlLWNhc2VzXSAod2hpY2ggY29udGFpbnMgYSBtZXJnZWQgc2V0IG9m IHVzZQ0KPiA+ICAgY2FzZXMgcHJldmlvdXNseSBwcmVzZW50ZWQgaW4gW0ktRC53YXRzb24tY2Ru aS11c2UtY2FzZXNdIGFuZA0KPiA+ICAgW0ktRC5iZXJ0cmFuZC1jZG5pLXVzZS1jYXNlcy0wMF0p Lg0KPiA+IE5FVzoNCj4gPiAgIFVzZSBjYXNlcyBmb3IgQ0ROIEludGVyY29ubmVjdGlvbiBhcmUg ZnVydGhlciBkaXNjdXNzZWQgaW4NCj4gPiAgIFtJLUQuaWV0Zi1jZG5pLXVzZS1jYXNlc10uDQo+ ID4NCj4gPg0KPiA+IDIpIFNlY3Rpb24gNCBjb250YWlucyBhbiBpbnRyb2R1Y3Rpb24gYW5kIDIg c3ViLXNlY3Rpb25zICg0LjEgJiA0LjIpIHRoYXQgYXJlIGVhY2gNCj4ganVzdCBhIGNvdXBsZSBv ZiBzZW50ZW5jZXMsIHNvIEkgcHJvcG9zZSBtZXJnaW5nIHRoZW0gaW50byBhIHNpbmdsZSBzZWN0 aW9uIGFuZA0KPiBjaGFuZ2luZyB0aGUgZmlyc3QgdHdvIHNlbnRlbmNlcyBvZiBzZWN0aW9uIDQg YXBwcm9wcmlhdGVseSwgaS5lLg0KPiA+DQo+ID4gT0xEOg0KPiA+ICAgVGhpcyBzZWN0aW9uIGV4 cGFuZHMgb24gaG93IENETkkgaW50ZXJmYWNlcyBjYW4gcmV1c2UgYW5kIGxldmVyYWdlDQo+ID4g ICBleGlzdGluZyBwcm90b2NvbHMuICBGaXJzdCB0aGUgInJldXNlIGluc3RlYWQgb2YgcmVpbnZl bnQiIGRlc2lnbg0KPiA+ICAgcHJpbmNpcGxlIGlzIHJlc3RhdGVkLCB0aGVuIGVhY2ggaW5ldHJm YWNlIGlzIGRpc2N1c3NlZCBpbmRpdmlkdWFsbHkNCj4gPiAgIHdpdGggZXhhbXBsZSBjYW5kaWRh dGUgcHJvdG9jb2xzIHRoYXQgY2FuIGJlIGNvbnNpZGVyZWQgZm9yIHJldXNlIG9yDQo+ID4gICBs ZXZlcmFnZS4NCj4gPiBORVc6DQo+ID4gICBUaGlzIHNlY3Rpb24gZXhwYW5kcyBvbiBob3cgQ0RO SSBpbnRlcmZhY2VzIGNhbiByZXVzZSBhbmQgbGV2ZXJhZ2UNCj4gPiAgIGV4aXN0aW5nIHByb3Rv Y29scyBiZWZvcmUgZGVzY3JpYmluZyBlYWNoIENETkkgaW50ZXJmYWNlIGluZGl2aWR1YWxseQ0K PiA+ICAgYW5kIGhpZ2hsaWdodGluZyBleGFtcGxlIGNhbmRpZGF0ZSBwcm90b2NvbHMgdGhhdCBj b3VsZCBjb25zaWRlcmVkIGZvcg0KPiA+ICAgcmV1c2Ugb3IgbGV2ZXJhZ2luZyB0byBpbXBsZW1l bnQgdGhlIENETkkgaW50ZXJmYWNlcy4NCj4gPg0KPiA+DQo+ID4gMykgU2VjdGlvbiA1IGlzIGN1 cnJlbnRseSB0aXRsZSAiR2FwIEFuYWx5c2lzIG9mIHJlbGV2YW50IFN0YW5kYXJkaXNhdGlvbiBh bmQNCj4gUmVzZWFyY2ggQWN0aXZpdGllcyIgYnV0IGZvbGxvd2luZyB0aGUgYWdyZWVtZW50IGF0 IHRoZSBsYXN0IElFVEYgdG8gbW92ZSB0aGUNCj4gZ2VuZXJpYyBkZXNjcmlwdGlvbnMgb2Ygb3Ro ZXIgYWN0aXZpdGllcyBpbnRvIGFuIGFwcGVuZGl4IFNlY3Rpb24gNSBubyBsb25nZXINCj4gcmVm ZXJlbmNlcyBhbnkgcmVzZWFyY2ggYWN0aXZpdGllcyBzbyBJIHByb3Bvc2UgY2hhbmdpbmcgdGhl IHRpdGxlIHRvIiBHYXAgQW5hbHlzaXMNCj4gb2YgcmVsZXZhbnQgU3RhbmRhcmRpc2F0aW9uIGFj dGl2aXRpZXMiLg0KPiA+DQo+ID4gNCkgQWZ0ZXIgdGhlIGdlbmVyYWwgaW50cm9kdWN0aW9uIGlu IFNlY3Rpb24gNSB0aGVyZSBhcmUgb25seSBzZWN0aW9ucyB0aGF0DQo+IG91dGxpbmUgb3RoZXIg cmVzZWFyY2ggYWN0aXZpdGllcyBmb3IgQ29udGVudCBBY3F1aXNpdGlvbiAoc2VjdGlvbiA1LjEp IGFuZCBDRE5JDQo+IE1ldGFkYXRhIChTZWN0aW9uIDUuMikgYnV0IHRoZXJlIGFyZSBub3Qgc2Vj dGlvbnMgZm9yIHRoZSBvdGhlciBDRE5JIGludGVyZmFjZXMNCj4gKENvbnRyb2wsIExvZ2dpbmcs IFJlcXVlc3QgUm91dGluZykuDQo+ID4NCj4gPiBUaGUgcmVhc29uIGZvciB0aGUgbGFjayBvZiB0 ZXh0IGlzIElNTyBiZWNhdXNlIHRoZXJlIGlzIG5vIGN1cnJlbnQgb3IgcGFzdA0KPiBzdGFuZGFy ZGlzYXRpb24gYWN0aXZpdHkgYWRkcmVzc2luZyB0aG9zZSBhcmVhcyBidXQgdGhlIGRvY3VtZW50 IGN1cnJlbnRseSBkb2VzDQo+IG5vdCBtZW50aW9uIHRoYXQgYW5kIHRoZXJlZm9yZSBnaXZlcyB0 aGUgaW1wcmVzc2lvbiBvZiBiZWluZyBpbmNvbXBsZXRlLg0KPiA+DQo+ID4gSSB0aGVyZWZvcmUg cHJvcG9zZSBtYWtpbmcgdGhlIGZvbGxvd2luZyBjaGFuZ2UgdG8gdGhlIGxhc3Qgc2VudGVuY2Ug aW4gU2VjdGlvbg0KPiA1Og0KPiA+DQo+ID4gT0xEOg0KPiA+ICAgVGhlIGZvbGxvd2luZyBzZWN0 aW9ucyB3aWxsIHN1bW1hcml6ZSB0aGUgZXhpc3Rpbmcgd29yayBvZiB0aGUNCj4gPiAgIHN0YW5k YXJkIGJvZGllcyBhYm92ZSBhZ2FpbnN0IHRoZSBDRE5JIHByb2JsZW0gc3BhY2UuDQo+ID4gTkVX Og0KPiA+ICAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyB3aWxsIHN1bW1hcml6ZSB0aGUgZXhpc3Rp bmcgd29yayBvZiB0aGUNCj4gPiAgIHN0YW5kYXJkIGJvZGllcyBhYm92ZSBhZ2FpbnN0IHRoZSBD RE5JIHByb2JsZW0gc3BhY2UuIFNlY3Rpb24gNS4xDQo+ID4gICBzdW1tYXJpc2VzIGV4aXN0aW5n IGludGVyZmFjZXMgdGhhdCBjb3VsZCBiZSBsZXZlcmFnZWQgZm9yIGNvbnRlbnQNCj4gPiAgIGFj cXVpc2l0aW9uIGJldHdlZW4gQ0ROcyBhbmQgU2VjdGlvbiA1LjIgc3VtbWFyaXNlcyBleGlzdGlu ZyBtZXRhZGF0YQ0KPiA+ICAgc3BlY2lmaWNhdGlvbnMgdGhhdCBtYXkgYmUgYXBwbGljYWJsZSB0 byBDRE5JLiBUbyBkYXRlIHRoZXJlIGlzIG5vDQo+ID4gICBleGlzdGluZyBzdGFuZGFyZGlzYXRp b24gYWN0aXZpdGllcyBpbiB0aGUgYXJlYXMgb2YgdGhlIHJlbWFpbmluZw0KPiA+ICAgQ0ROSSBp bnRlcmZhY2VzIChDRE5JIFJlcXVlc3QgUm91dGluZywgQ0ROSSBDb250cm9sIGFuZCBDRE5JIExv Z2dpbmcpLg0KPiA+DQo+ID4gNSkgSSBhbHNvIHByb3Bvc2UgdXNpbmcgdGhlIGZvbGxvd2luZyB0 ZXh0IGZvciB0aGUgdGhpcmQgYnVsbGV0IGluIFNlY3Rpb24gNSB1bmxlc3MNCj4gc29tZW9uZSBj YW4gc3VnZ2VzdCBtb3JlIGFwcHJvcHJpYXRlIHRleHQgdG8gc3VtbWFyaXNlIGluIGEgc2VudGVu Y2Ugb3IgdHdvDQo+IGFueSBDRE4gbWV0YWRhdGEgcmVsYXRlZCB3b3JrIGluIG90aGVyIHN0YW5k YXJkcyBib2RpZXMuDQo+ID4NCj4gPiBPTEQ6DQo+ID4gICBvICA8VE9ETzogQWRkIGEgc2VudGVu Y2Ugb24gSVRVPg0KPiA+IE5FVzoNCj4gPiAgIG8gIENhYmxlTGFicywgU05JQSBhbmQgSVRVIGhh dmUgZGVmaW5lZCAob3IgYXJlIHdvcmtpbmcgb24pDQo+ID4gICAgICBkZWZpbml0aW9ucyBmb3Ig Y29udGVudCByZWxhdGVkIG1ldGFkYXRhIGRlZmluaXRpb25zIGFuZCBzcGVjaWZpY2F0aW9uDQo+ ID4gICAgICBmb3IgaXRzIGRpc3RyaWJ1dGlvbi4gSG93ZXZlciwgdGhleSBkbyBub3QgaW5jbHVk ZSBtZXRhZGF0YSBzcGVjaWZpYw0KPiA+ICAgICAgdG8gdGhlIGRpc3RyaWJ1dGlvbiBvZiBjb250 ZW50IHdpdGhpbiBhIENETiBvciBiZXR3ZWVuIGludGVyY29ubmVjdGVkDQo+ID4gICAgICBDRE5z Lg0KPiA+DQo+ID4gNikgU2VjdGlvbiAxMC4xIGxpc3RzIGEgbnVtYmVyIG9mICJub3JtYXRpdmUg cmVmZXJlbmNlcyIsIGlmIHdlIGFkb3B0IHRoZQ0KPiBwcm9wb3NlZCBjaGFuZ2VzIGFib3ZlIGl0 IHdpbGwgZW5kIHVwIGNvbnRhaW5pbmcgIm5vcm1hdGl2ZSIgcmVmZXJlbmNlcyB0bzoNCj4gPiAg IC0gZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcw0KPiA+ICAgLSBkcmFmdC1iZXJ0cmFuZC1jZG5p LWV4cGVyaWVtZW50cw0KPiA+ICAgLSBkcmFmdC1qZW5raW5zLWNkbmktbmFtZXMNCj4gPiAgIC0g UkZDMjExOQ0KPiA+DQo+ID4gQWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHRoZSB0ZXh0IG9mIHRoZSBQ cm9ibGVtIFN0YXRlbWVudCBhZ2FpbiwgSSBhbSBub3QNCj4gY29udmluY2VkIHRoYXQgdGhlIFBy b2JsZW0gU3RhdGVtZW50IHJlZmVyZW5jZXMgYW55IG9mIHRob3NlIGRvY3VtZW50cw0KPiBub3Jt YXRpdmVseSBhcyB0aGUgMyBDRE5JIHJlbGF0ZWQgZHJhZnRzIGFyZSByZWZlcmVuY2VkIGluIGEg Y29udGV4dCB3aGVyZSB0aGV5DQo+IGFyZSBmb3IgZnVydGhlciBpbmZvcm1hdGlvbiBhbmQgdGhl IFByb2JsZW0gU3RhdGVtZW50IGRvZXMgbm90IG1ha2UgdXNlIG9mDQo+IGFueSBvZiB0aGUgY2Fw aXRhbGlzZWQgdGVybXMgZGVmaW5lZCBpbiBSRkMyMTE5Lg0KPiA+DQo+ID4gVGhlcmVmb3JlLCB1 bmxlc3MgYW55b25lIG9iamVjdHMgSSB3aWxsIG1vdmUgdGhlIHJlZmVyZW5jZXMgZm9yIHRoZSB0 aHJlZSBDRE5JDQo+IHJlbGF0ZWQgZHJhZnRzIHRvIHRoZSAiSW5mb3JtYXRpdmUgUmVmZXJlbmNl cyIgc2VjdGlvbiBhbmQgcmVtb3ZlIHRoZSByZWZlcmVuY2UNCj4gZm9yIFJGQzIxMTkuDQo+ID4N Cj4gPg0KPiA+IFRoYW5rcw0KPiA+IEJlbg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBDRE5pIG1haWxpbmcgbGlzdA0KPiA+IENE TmlAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nk bmkNCg0K From zhouzhipeng@huawei.com Thu Oct 27 00:46:50 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6239921F84A8 for ; Thu, 27 Oct 2011 00:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPGmB6ugy3D7 for ; Thu, 27 Oct 2011 00:46:37 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 678E621F84CB for ; Thu, 27 Oct 2011 00:46:36 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTP0010ZS898G@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 27 Oct 2011 15:45:45 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTP00MUPS7E25@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 27 Oct 2011 15:45:44 +0800 (CST) Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEL77952; Thu, 27 Oct 2011 15:45:42 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 27 Oct 2011 15:45:34 +0800 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.117]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 15:45:36 +0800 Date: Thu, 27 Oct 2011 07:45:36 +0000 From: ZhouZhipeng In-reply-to: X-Originating-IP: [10.138.73.38] To: Mark de Jong , Alan Kavanagh Message-id: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tqFHzhUhFa1rM2poBKGQhg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgBYn8ICAAA1tAIABOe8g X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 07:46:50 -0000 --Boundary_(ID_tqFHzhUhFa1rM2poBKGQhg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hello Mark, Nice to meet you on line. In your company's website, I just find some information that addresses " Vodafone subscribers complained about video performance." See: http://www.jet-stream.nl/search/?search=transcoding Dear all in this group, In last few days, except the public email discussions I have contacted with some people and discussed with my own colleagues of all details on this issue. First, although the market requirement for it is very important, I feel I'd better show up more information on the procedure involved. I have explained many times that to support content adaptation is rather simple while the wording is not enough. I am busy making some contributions on this and plan to upload to ETSI meeting and IETF CDNI. By these work I feel the people may catch a whole view on this issue. Second, for that functionality, in implementation, if some entity does not choose to support it, it may be ok. Since it may be negotiated between two CDNs. If dCDN does not support that, it may be the uCDN responsible to complete the transcoding and deliver the content of multiple formats and rates to dCDN. Third, although CDNI is a new architecture, while the content operating has been existed for years. As I know the content from USA to the downstream operator is transferred on one copy and the downstream operator will handle the transcoding. Perhaps, the content adaptation is more on the mobile operating. But I feel currently most operator will be a all service operator. And for the CDN providers, it may be better to support all kinds of service. Besides, I like say that the technology on this topic has been for many years and has been rather mature, even some items in ietf such as rfc3507 icap. So from the technique point of view, it is a nature action to be involved in CDN interconnection. Thanks. Zhipeng From: Mark de Jong [mailto:mark@jet-stream.nl] Sent: Thursday, October 27, 2011 4:21 AM To: Alan Kavanagh Cc: Ben Niven-Jenkins; ZhouZhipeng; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Alan, As Ben stated the overall discussion right now is about delivery, not on adaptation. It is hard enough to get consensus on the delivery aspect already not to mention your requirement from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for the first specs. I can imagine this could be a discussion later on but please let us keep the scope of this be clean and transparent. It is of benefit of everyone to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: Ben Im assuming then based on your comments below are you suggesting we are going to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that there is some work to be done, but I still feel that content adaptation is to me a fundamental requirement to what collectively we should address in the CDN-I WG. I do agree with you that content adaptation is an optimization between CDN's but it's a very important one that I know Network Service Providers particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: Hello Ben, The UE may select the content format on the CP web. After that the user only desires to get his selected content. But how the content is transferred to the client is not worried by the user. The CP may create a special format as required by the user and ask the CDN to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select. Lots of things may be possible to do and CDN providers offer many additional services on top of the "core" service of content delivery. However, our objective (based on my interpretation of the CDNI charter) is to focus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and deployable within a short time frame (18-24 months). Content transformation/adaptation is not an essential requirement in order to achieve that aim (we can deliver content from CSPs to End Users via multiple CDNs without needing or requiring any CDN supports content adaptation). In my opinion we have enough work to do already without trying to expand the scope of our work to include additional requirements that do not help us address our core objectives as laid out in the CDNI charter. In this case, it is nothing related to how the user select formats on CP website. So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion). As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look. I think the core functionality maps pretty well to the CDNI interfaces, namely: Request Routing, Metadata configuration, log production and control plus content acquisition and content delivery. I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media formats. One candidate is your company, another is CDN-X. The users are located in France. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. What you are describing is a possible optimization that a particular CDN may wish to implement not a core functionality required to enable content delivery between interconnected CDNs. I can think of many optimizations that a CDN could implement to differentiate their service but the internal workings of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core function required to enable content delivery between interconnected CDNs and therefore given the workload we already have to specify solutions that do address the core functionality required to interconnect CDNs I do not think we should be trying to add more work into that workload as it will only distract us from achieving our goal of producing deployable solutions within the timeframe we are being told by operators they needs solutions within. Ben So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: Ben and Philip, I like to respond your concern in this one email: Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN. For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias. By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711. For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to this case above. I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request. As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types". Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery). My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO. Ben A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) If the content is needed to be protected, generally you may know all the systems should be granted by the content owner. Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also. So, trust is not a problem for the media. Philip, Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it may save investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service. But the reality is all operators ask us to provide a system that may support different service systems. Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple . At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ben, Zhipeng, all, I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft. The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this. I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well? Scott, Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive. Best wishes phil Philip Eardley Research and Technology Strategy This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is. Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. If you have any more question or comments, pls share in this thread. Thanks. Zhipeng -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. Section 10 Security Considerations Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is determined by the respective CDN's. Scott _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --Boundary_(ID_tqFHzhUhFa1rM2poBKGQhg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hello Mark= ,

Nice to me= et you on line.

In your co= mpany’s website, I just find some information that addresses “ Vodafone s= ubscribers complained about video performance.”

See:<= /o:p>

http://www.jet-stre= am.nl/search/?search=3Dtranscoding

 = ;

Dear all i= n this group,

In last fe= w days, except the public email discussions I have contacted with some peop= le and discussed with my own colleagues of all details on this issue.

First, alt= hough the market requirement for it is very important, I feel I’d bet= ter show up more information on the procedure involved. I have explained many times that to support content adaptation is rather simple while the w= ording is not enough.

I am busy = making some contributions on this and plan to upload to ETSI meeting and IE= TF CDNI.

By these w= ork  I feel the people may catch a whole view on this issue.

Second, fo= r that functionality, in implementation, if some entity does not choose to = support it, it may be ok. Since it may be negotiated between two CDNs.

If dCDN do= es not support that, it may be the uCDN responsible to complete the transco= ding and deliver the content of multiple formats and rates to dCDN.

Third, alt= hough CDNI is a new architecture, while the content operating has been exis= ted for years. As I know the content from USA to the downstream operator is transferred on one copy and the downstream operator will handl= e the transcoding.

 = ;

Perhaps, t= he content adaptation is more on the mobile operating. But I feel currently= most operator will be a all service operator. And for the CDN providers, it may be better to support all kinds of service.

Besides, I= like say that the technology on this topic has been for many years and has= been rather mature, even some items in ietf such as rfc3507 icap. So from the technique point of view, it is a nature action to be inv= olved in CDN interconnection.

Thanks.

Zhipeng

 = ;

 = ;

 = ;

From: Mark de Jong [mailto:mark@jet-stream.nl]
Sent: Thursday, October 27, 2011 4:21 AM
To: Alan Kavanagh
Cc: Ben Niven-Jenkins; ZhouZhipeng; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

 

Hi Alan,

 

As Ben stated the overall discu= ssion right now is about delivery, not on adaptation. It is hard enough to = get consensus on the delivery aspect already not to mention your requiremen= t from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for the first= specs. I can imagine this could be a discussion later on but please l= et us keep the scope of this be clean and transparent. It is of benefit of = everyone to get the first specs as fast as possible. Thanks.

 

Met vriendelijke groet,

Kind regards,

Mark de Jong
International Business Developer Jet-Stream BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214

 

- Event: Meet us at Streaming Media Europe, 17-18 October, London, UK

- Event: Meet us at Online Video Strategies, 19 October, London, UK

- Event: Meet us at CDN World Summit, 25-28 October, London, UK

- News: www.jet-stream.com

- News: Check http://www.jet-stream.com to download our 'Six Trend= s in CDNs' brochure<= o:p>

 = ;

- VideoExchange: ww= w.vdo-x.net

- Streamzilla: <= span lang=3D"EN-US" style=3D"font-size:6.5pt;font-family:"Calibri"= ;,"sans-serif";color:black">www.streamzillacdn.com

- Corporate:<= /b> www.jet= -stream.com

 

On 26, Oct,2011, at 8:33 PM, Al= an Kavanagh wrote:



Ben

Im assuming then based on your comments below are you suggesting we are goi= ng to have a number of versions of the CDN-I Metadata?

I sympathise with what you are pointing out below and do agree that there i= s some work to be done, but I still feel that content adaptation is to me a= fundamental requirement to what collectively we should address in the CDN-= I WG. I do agree with you that content adaptation is an optimization between CDN's but it's a very important one = that I know Network Service Providers particularly require.

Alan

-----Original Message-----
From: cdni-bounces@ietf.org [m= ailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 12 Oct 2011, at 10:22, ZhouZhipeng wrote:


Hello Ben,

The UE may select the content f= ormat on the CP web. After that the user only desires to get his selected c= ontent.

But how the content is transfer= red to the client is not worried by the user.

The CP may create a special for= mat as required by the user and ask the CDN to deliver to user.<= /span>

While CP may give a HD format c= ontent to uCDN and the dCDN may then transform to the format as the user se= lect.


Lots of things may be possible to do and CDN providers offer many additiona= l services on top of the "core" service of content delivery. Howe= ver, our objective (based on my interpretation of the CDNI charter) is to f= ocus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and dep= loyable within a short time frame (18-24 months).

Content transformation/adaptation is not an essential requirement in order = to achieve that aim (we can deliver content from CSPs to End Users via mult= iple CDNs without needing or requiring any CDN supports content adaptation)= .

In my opinion we have enough work to do already without trying to expand th= e scope of our work to include additional requirements that do not help us = address our core objectives as laid out in the CDNI charter.


In this case, it is nothing rel= ated to how the user select formats on CP website.

So, it is the CP and user to de= cide the content format not the CDN(your assert is not correct and seems yo= u take that assert as your base for the discussion).

 

As for "the core CDN funct= ionality offered by CDNs today", I have ever raised an email before th= at your company's webpage has claimed supporting media transformation and m= ulti-screen service.

Perhaps, I like asking you list= some features that you feel are the core functionalities by existing main = stream CDNs. Thus we may compare and take deep look.


I think the core functionality maps pretty well to the CDNI interfaces, nam= ely: Request Routing, Metadata configuration, log production and control pl= us content acquisition and content delivery.


I guess many people have the ex= perience/knowledge of content related service. The user and CP only care wh= ether the CDN providers may satisfy their requirement while not care the in= ternal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice= is transformed in process.

 

Besides, I like raise a case:

Given currently BBC recruits CD= N providers that may support 10 media formats.

One candidate is your company, = another is CDN-X. The users are located in France.

So both your company and CDN-X = should connect a France CDN provider(CDN-Y).

If your company's solution is t= o send 10 streams of different format

of one content to CDN-Y; While = CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some = adaptation.

Comparing these two solutions, = for your company and CDN-X, absolutely the cost of CDN-X is much lower.

For CDN-Y, in solution-1, it sh= ould receive/forward 10 streams ; while in solution-2, it should only recei= ve 1 stream but need to take transformation to output 10 streams.

 

Which solution is more competit= ive. it is Solution 1, right. Remember the price from BBC is same to both y= our company and CDN-X or BBC would select one CDN provider with the lower p= rice.

If a CDN provider may not get t= he contract from CP, how it may say it is not a core functionality.


What you are describing is a possible optimization that a particular CDN ma= y wish to implement not a core functionality required to enable content del= ivery between interconnected CDNs. I can think of many optimizations that a= CDN could implement to differentiate their service but the internal workings of an individual CDN are out of sc= ope of our charter.

So to repeat my position for a final time: Content adaptation is not a core= function required to enable content delivery between interconnected CDNs a= nd therefore given the workload we already have to specify solutions that d= o address the core functionality required to interconnect CDNs I do not think we should be trying to add mo= re work into that workload as it will only distract us from achieving our g= oal of producing deployable solutions within the timeframe we are being tol= d by operators they needs solutions within.

Ben


So, if we all realize that curr= ently the media type is rich, the CDN providers should survive in the exist= ing ecosystem and support the media types as required by the market.

 

Back to the case of GSM/G.711, = it just when concerning the interconnection, the transformation should at o= nce be solved. Otherwise the interconnection may not be operated.

 

Br,

Zhipeng

 

 

 

 

-----Original Message-----=

From: Ben Niven-Jenkins [mailto= :ben@niven-jenkins.co.uk]

Sent: Wednesday, October 12, 20= 11 12:19 AM

To: ZhouZhipeng

Cc: philip.eardley@bt.com; cdni@ietf.org

Subject: Re: [CDNi] I-D Action:= draft-ietf-cdni-use-cases-00.txt

 

Zhipeng,

 

On 11 Oct 2011, at 05:16, ZhouZ= hipeng wrote:

 

Ben and Philip,

I like to respond your concern = in this one email:

 

Ben,

I feel what we are now discussi= ng is what is the "core" function of CDN.

As you say, CDN is used to deli= ver content. That is absolutely correct that the delivery capability is the= core requirement for CDN system.

While CDN is used to provide th= e content delivery service.

What means service. It should i= nclude "time" "location" and "media type", et= c. These features are all the core feature for a service.=

If we only concern "delive= ring one data block", I am not sure whether the issues such as "l= ogging" "geographic constraint" are the core of CDN.

 

For "without explicit know= ledge of what that content actually is ", I am not sure whether the wo= rding is accurate since generally a CDN may claim it support different medi= as.

By this opportunity, I like to = share a use case: a call from a GSM phone to a PSTN telephone, the voice st= ream should be transformed from GSM voice to G.711.

For the user, he does not need = to know what type of data has been transferred, but the operator has done s= ome work to interconnect two systems, right.

I like to know whether you may = accept that my use case is similar to this case above.

 

I don't think your use case is = similar to the analogy of mobile networks being interconnected to PSTN netw= orks. In the case of content delivery the negotiation is done between the U= ser/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been neg= otiated. The CDN is not involved in the decision making of what representat= ions the Content Provider decides to offer to the User/Client or in what re= presentations the User/Client decides to request.

 

As for you said selecting media= by the "portal", you may see the way " uCDN delivers multip= le media streams to dCDN" is not good than "uCDN delivers one med= ia stream to dCDN and dCDN takes some adaptation to support multiple media types".

 

Now what you're talking about i= s an optimisation, not a core function required to actually deliver the con= tent (and report, bill, etc. for that delivery).

 

My position is that we should f= ocus on how to enable the interconnection of the core CDN functionality off= ered by CDNs today (which is also my interpretation of the scope of the CDN= I working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's = not start trying to add in additional functionality beyond what the majorit= y of CDNs support today as that will just delay us getting usable specifica= tions into the market in a timely fashion IMO.

 

Ben

 

A good question is "securi= ty" since I have done six years on the DRM

and like to promote the DRM all= around the world:) If the content is needed to be protected, generally you= may know all the systems should be granted by the content owner.

Here I also like to clarify tha= t not only the media itself but the information related to service itself (= such as the geographic constraint) should be protected also.

So, trust is not a problem for = the media.

 

Philip,

Thank you that you feel Content= Adaption is an issue for "Requirements" but I do not know why it= is not for Use case.

I like to clarify to U that it = is important for you operator since it may save investment if the system ma= y support different services.

For us vendor, we are happy ope= rator may install a system for the mobile service and another system for th= e FBB service.

But the reality is all operator= s ask us to provide a system that may support different service systems.

 

Frankly, Ben and Philip, I reme= mber I have explained somewhere that to implement this is rather simple .

At least the Use case and Requi= rement are informational to be referred in future work. So I do really feel= you may accept it.

Of course I like to respond you= r more concern and comments.

Thanks.

Zhipeng

 

 

 

-----Original Message-----=

From: philip.eardley@bt.com [mailto:philip.eardley@bt.com]<= /p>

Sent: Monday, October 10, 2011 = 11:22 PM

To: ben@niven-jenkins.co.uk; ZhouZhipeng

Cc: cdni@ietf.org

Subject: RE: [CDNi] I-D Action:= draft-ietf-cdni-use-cases-00.txt

 

Ben, Zhipeng, all,

 

I think that Content Adaptation= is more an issue for the Requirements doc than for the Use cases draft.

 

The key question is whether we = want the CDNI interfaces to be able to cope with a scenario where (say) HD/= SD conversion is done in the dCDN & to signal about this.

 

I think that coping with this s= cenario is a second order requirement, ie we should not worry about it in t= he initial standards-track work. I don't know, did we ever decide whether t= he Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future"= ; scenarios as well?

 

Scott,

Reading some of your examples, = they seem to be valid even if content adaptation (HD/SD) is out of scope.

- a dCDN might for some reason = be unwilling to distribute HD?

- a CSP might want to make sure= the dCDN can use HLS encapsulation?

But these sorts of examples see= m to be static policy things (to do

with the capabilities & pre= ferences of the CDNs & CSP), rather than

metadata associated with a part= icular piece of content. In the

discussion so far, I think nego= tiation about static policy stuff is

rather out of scope(?)

 

On security considerations, an = interesting question is whether trust is transitive. Don't think it need be= - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the= CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility i= s to say that we will only handle cases where the trust is transitive.=

 

Best wishes

phil

 

 

Philip Eardley

Research and Technology Strateg= y

 

This email contains BT informat= ion, which may be privileged or confidential. It's meant only for the indiv= idual(s) or entity named above. If you're not the intended recipient, note = that disclosing, copying, distributing or using this information is prohibited. If you've received this email in = error, please let me know immediately on the email address above. Thank you= . We monitor our email system, and may record your emails.

British Telecommunications plc<= o:p>

Registered office: 81 Newgate S= treet London EC1A 7AJ Registered in

England no: 1800000<= /span>

 

 

-----Original Message-----=

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf

Of Ben Niven-Jenkins=

Sent: 10 October 2011 12:04

To: ZhouZhipeng

Cc: cdni@ietf.org

Subject: Re: [CDNi] I-D Action:= draft-ietf-cdni-use-cases-00.txt

 

Colleagues,

 

IMO Section 5.1.3 should be rem= oved from the Use Cases draft. Content Adaptation (i.e. taking in a content= item in one format and transforming it to another format or representation= ) is not a "core" function of a CDN which typically delivers the content that is requested without explicit kn= owledge of what that content actually is.

 

Let's not forget that in buildi= ng an end to end content service the CDN is only one component and is the c= omponent tasked with executing the delivery of a specific representation (v= ersion/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on whi= ch version/copy/representation of content should be delivered.

 

The decision as to which versio= n/copy/representation to offer and allow to be delivered to a given device/= user is implemented outside of the CDN (e.g. by the "portal" wher= e the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content= ).

 

Ben

 

On 8 Oct 2011, at 08:20, ZhouZh= ipeng wrote:

 

Following Scott's comments on s= ection 5.1.3, I feel Scott's description on the use case of HD and SD is no= t exactly correct.

If one movie has two formats of= HD and SD, then we have two content with different identifier. In DRM scop= e, the basic unit is a content copy.

 

Here the first bullet "a s= ubset of encodings deliverable to specific devices," has listed the ca= se of content adaptation.

In last month, I have contacted= the Authors of this document and taken some email exchanges with Grant and= Philip (BT).

I have shown BT with some infor= mation that I know in this case and area to explain the content flexibility= is currently a basic requirement for CDN service and related negotiation i= s needed in the CDN interconnection.

Meanwhile, I should also invite= you in this group raising your comments or questions on this case since I = hope my use case may be incorporated in the use case draft.

 

If you have any more question o= r comments, pls share in this thread.

Thanks.

Zhipeng

 

 

 

 

 

 

-----Original Message-----=

From: Scott Wainner [mailto:swa= inner@cisco.com]

Sent: Friday, September 30, 201= 1 8:02 AM

To: cdni@ietf.org

Subject: Re: [CDNi] I-D Action:= draft-ietf-cdni-use-cases-00.txt

 

Section 2.3 Nomadic Users<= /o:p>

This description falls under th= e category of Geographic Extension

yet the third paragraph states = the case where a different device is

used in the same CDN coverage a= rea.  The intent of this use case

needs to be clarified.  Pe= rhaps the use case is trying to address

the scenario where a Nomadic Us= er-A with an agreement allowing

access to content from CSP-A vi= a uCDN moves to a dCDN in a different

region.  The dCDN is allow= ed to distribute the content of CSP-A to

User-A; however, not other user= s in the region of the dCDN are

allowed to retrieve the content= unless they too have such an agreement.

 

Section 5.1.3 Content Encoding = Restrictions Need to clarify if we're

talking about the restrictions = on the delivery of specific content

or the restrictions on the abil= ity of a CDN to deliver specific

content.  I certainly unde= rstand the case where a CSP will restrict

the distribution of content to = a "managed path" if such content is

HD while allowing the content d= istribution via an un-managed path if

such content is SD (same could = apply to encryption methods, delivery

methods, etc.).  On the co= ntrary, the dCDN may have its own

restrictions of blocking the di= stribution of HD content while

allowing the distribution of SD= content.

 

o first bullet makes sense if t= he dCDN can perform a subset of

encapsulations for a reference = set of media (e.g. HLS, HSS, but not

DASH) o second bullet makes sen= se where the dCDN doesn't want to

offer high bit-rate variants of= the media o third bullet make sense

if the policy addresses QoE but= I don't think subscriber

rights/authorizations apply.

 

Section 10 Security Considerati= ons

 

Aside from the security conside= rations WITHIN the uCDN and dCDN, I

think we can describe this in f= our contexts:

 

a. The relationship between the= CSP and the uCDN (the principle contract

arrangement for distribution)

b. The relationship between the= uCDN and dCDN (the transitive trust

relationship that extends the c= ontract defined in (a) above) c. The

relationship between the User a= nd dCDN (the recognition of right to

download predicated on (b) abov= e) d. The relationship between the

User and CSP (the contract auth= orizing the user access to the

content)

 

The user is not interested in t= he a-b nor the b-c relationship. The

user is only interested in the = transparency and interoperability of

the security relationship betwe= en d-b or d-c to the point that the

authorization granted in d-a is= viable when the delivery is

initiated via either d-b or d-c= .  As an example, the uCDN might use

URL appended tokens for authent= ication while dCDN might use URL

appended hashes.  The user= doesn't want to know about the distinct

methods, but transparency is on= ly afforded if the methods are

interoperable clearly defined w= hen the delegation for content

delivery is executed.  Cle= arly, the choice of authentication method is determined by the respective C= DN's.

 

Scott

 

_______________________________= ________________

CDNi mailing list

CDNi@ietf.org

https://www.ietf.org/mailman/listinfo/cdni=

 

_______________________________= ________________

CDNi mailing list

CDNi@ietf.org

https://www.ietf.org/mailman/listinfo/cdni=

 

=
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni

 

--Boundary_(ID_tqFHzhUhFa1rM2poBKGQhg)-- From mark@jet-stream.nl Thu Oct 27 00:57:37 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4C021F85B5 for ; Thu, 27 Oct 2011 00:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uwHQppid3CcW for ; Thu, 27 Oct 2011 00:57:34 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id 517FF21F85AE for ; Thu, 27 Oct 2011 00:57:32 -0700 (PDT) Received: from pc0046.hhpn.btopenzone.com ([217.41.230.215]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id p9R7v1F4002162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Oct 2011 09:57:01 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-753--54882366 From: Mark de Jong In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> Date: Thu, 27 Oct 2011 08:56:57 +0100 Message-Id: References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> To: ZhouZhipeng X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 07:57:38 -0000 --Apple-Mail-753--54882366 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Zhipeng, As said: I agree this can be a discussion later and be added to the = requirements in a future release. However: in respect to the speed of = the process and as the delivery part is the biggest majority of the = business for interconnection (please note: interconnection is a business = driver, not technology driver) the focus should be delivery.=20 Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 27, Oct,2011, at 8:45 AM, ZhouZhipeng wrote: > Hello Mark, > Nice to meet you on line. > In your company=92s website, I just find some information that = addresses =93 Vodafone subscribers complained about video performance.=94 > See: > http://www.jet-stream.nl/search/?search=3Dtranscoding > =20 > Dear all in this group, > In last few days, except the public email discussions I have contacted = with some people and discussed with my own colleagues of all details on = this issue. > First, although the market requirement for it is very important, I = feel I=92d better show up more information on the procedure involved. I = have explained many times that to support content adaptation is rather = simple while the wording is not enough. > I am busy making some contributions on this and plan to upload to ETSI = meeting and IETF CDNI. > By these work I feel the people may catch a whole view on this issue. > Second, for that functionality, in implementation, if some entity does = not choose to support it, it may be ok. Since it may be negotiated = between two CDNs. > If dCDN does not support that, it may be the uCDN responsible to = complete the transcoding and deliver the content of multiple formats and = rates to dCDN. > Third, although CDNI is a new architecture, while the content = operating has been existed for years. As I know the content from USA to = the downstream operator is transferred on one copy and the downstream = operator will handle the transcoding. > =20 > Perhaps, the content adaptation is more on the mobile operating. But I = feel currently most operator will be a all service operator. And for the = CDN providers, it may be better to support all kinds of service. > Besides, I like say that the technology on this topic has been for = many years and has been rather mature, even some items in ietf such as = rfc3507 icap. So from the technique point of view, it is a nature action = to be involved in CDN interconnection. > Thanks. > Zhipeng > =20 > =20 > =20 > From: Mark de Jong [mailto:mark@jet-stream.nl]=20 > Sent: Thursday, October 27, 2011 4:21 AM > To: Alan Kavanagh > Cc: Ben Niven-Jenkins; ZhouZhipeng; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Hi Alan, > =20 > As Ben stated the overall discussion right now is about delivery, not = on adaptation. It is hard enough to get consensus on the delivery aspect = already not to mention your requirement from content adaptation added to = that, so I agree with Ben we should stick with the delivery aspect for = the first specs. I can imagine this could be a discussion later on but = please let us keep the scope of this be clean and transparent. It is of = benefit of everyone to get the first specs as fast as possible. Thanks. > =20 > Met vriendelijke groet, > Kind regards, >=20 > Mark de Jong > International Business Developer > Jet-Stream BV >=20 > E-mail: mark@jet-stream.com > Office: +31 (0)50 5261820 > Mobile: +31 (0)6 81108263 > Fax: +31 (0)50 5264214 > =20 > - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK > - Event: Meet us at Online Video Strategies, 19 October, London, UK > - Event: Meet us at CDN World Summit, 25-28 October, London, UK > - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com > - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure > =20 > - Blog: www.jet-stream.com/blog/ > - VideoExchange: www.vdo-x.net > - Streamzilla: www.streamzillacdn.com > - Corporate: www.jet-stream.com > =20 > On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: >=20 >=20 > Ben >=20 > Im assuming then based on your comments below are you suggesting we = are going to have a number of versions of the CDN-I Metadata? >=20 > I sympathise with what you are pointing out below and do agree that = there is some work to be done, but I still feel that content adaptation = is to me a fundamental requirement to what collectively we should = address in the CDN-I WG. I do agree with you that content adaptation is = an optimization between CDN's but it's a very important one that I know = Network Service Providers particularly require. >=20 > Alan >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins > Sent: October-12-11 1:13 PM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Zhipeng, >=20 > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: >=20 >=20 > Hello Ben, > The UE may select the content format on the CP web. After that the = user only desires to get his selected content. > But how the content is transferred to the client is not worried by the = user. > The CP may create a special format as required by the user and ask the = CDN to deliver to user. > While CP may give a HD format content to uCDN and the dCDN may then = transform to the format as the user select. >=20 > Lots of things may be possible to do and CDN providers offer many = additional services on top of the "core" service of content delivery. = However, our objective (based on my interpretation of the CDNI charter) = is to focus on what is necessary to interconnect CDNs to deliver content = from a CSP to an End User that is targeted and deployable within a short = time frame (18-24 months). >=20 > Content transformation/adaptation is not an essential requirement in = order to achieve that aim (we can deliver content from CSPs to End Users = via multiple CDNs without needing or requiring any CDN supports content = adaptation). >=20 > In my opinion we have enough work to do already without trying to = expand the scope of our work to include additional requirements that do = not help us address our core objectives as laid out in the CDNI charter. >=20 >=20 > In this case, it is nothing related to how the user select formats on = CP website. > So, it is the CP and user to decide the content format not the = CDN(your assert is not correct and seems you take that assert as your = base for the discussion). > =20 > As for "the core CDN functionality offered by CDNs today", I have ever = raised an email before that your company's webpage has claimed = supporting media transformation and multi-screen service. > Perhaps, I like asking you list some features that you feel are the = core functionalities by existing main stream CDNs. Thus we may compare = and take deep look. >=20 > I think the core functionality maps pretty well to the CDNI = interfaces, namely: Request Routing, Metadata configuration, log = production and control plus content acquisition and content delivery. >=20 >=20 > I guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in process. > =20 > Besides, I like raise a case: > Given currently BBC recruits CDN providers that may support 10 media = formats. > One candidate is your company, another is CDN-X. The users are located = in France. > So both your company and CDN-X should connect a France CDN = provider(CDN-Y). > If your company's solution is to send 10 streams of different format > of one content to CDN-Y; While CDN-X's solution is to send 1 stream to = CDN-Y while CDN-Y may conduct some adaptation. > Comparing these two solutions, for your company and CDN-X, absolutely = the cost of CDN-X is much lower. > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while = in solution-2, it should only receive 1 stream but need to take = transformation to output 10 streams. > =20 > Which solution is more competitive. it is Solution 1, right. Remember = the price from BBC is same to both your company and CDN-X or BBC would = select one CDN provider with the lower price. > If a CDN provider may not get the contract from CP, how it may say it = is not a core functionality. >=20 > What you are describing is a possible optimization that a particular = CDN may wish to implement not a core functionality required to enable = content delivery between interconnected CDNs. I can think of many = optimizations that a CDN could implement to differentiate their service = but the internal workings of an individual CDN are out of scope of our = charter. >=20 > So to repeat my position for a final time: Content adaptation is not a = core function required to enable content delivery between interconnected = CDNs and therefore given the workload we already have to specify = solutions that do address the core functionality required to = interconnect CDNs I do not think we should be trying to add more work = into that workload as it will only distract us from achieving our goal = of producing deployable solutions within the timeframe we are being told = by operators they needs solutions within. >=20 > Ben >=20 >=20 > So, if we all realize that currently the media type is rich, the CDN = providers should survive in the existing ecosystem and support the media = types as required by the market. > =20 > Back to the case of GSM/G.711, it just when concerning the = interconnection, the transformation should at once be solved. Otherwise = the interconnection may not be operated. > =20 > Br, > Zhipeng > =20 > =20 > =20 > =20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Wednesday, October 12, 2011 12:19 AM > To: ZhouZhipeng > Cc: philip.eardley@bt.com; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Zhipeng, > =20 > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > =20 > Ben and Philip, > I like to respond your concern in this one email: > =20 > Ben, > I feel what we are now discussing is what is the "core" function of = CDN. > As you say, CDN is used to deliver content. That is absolutely correct = that the delivery capability is the core requirement for CDN system. > While CDN is used to provide the content delivery service. > What means service. It should include "time" "location" and "media = type", etc. These features are all the core feature for a service. > If we only concern "delivering one data block", I am not sure whether = the issues such as "logging" "geographic constraint" are the core of = CDN. > =20 > For "without explicit knowledge of what that content actually is ", I = am not sure whether the wording is accurate since generally a CDN may = claim it support different medias. > By this opportunity, I like to share a use case: a call from a GSM = phone to a PSTN telephone, the voice stream should be transformed from = GSM voice to G.711. > For the user, he does not need to know what type of data has been = transferred, but the operator has done some work to interconnect two = systems, right. > I like to know whether you may accept that my use case is similar to = this case above. > =20 > I don't think your use case is similar to the analogy of mobile = networks being interconnected to PSTN networks. In the case of content = delivery the negotiation is done between the User/Client and the Content = Provider and the CDN is just used to execute/perform the delivery that = has been negotiated. The CDN is not involved in the decision making of = what representations the Content Provider decides to offer to the = User/Client or in what representations the User/Client decides to = request. > =20 > As for you said selecting media by the "portal", you may see the way " = uCDN delivers multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media types". > =20 > Now what you're talking about is an optimisation, not a core function = required to actually deliver the content (and report, bill, etc. for = that delivery). > =20 > My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO. > =20 > Ben > =20 > A good question is "security" since I have done six years on the DRM > and like to promote the DRM all around the world:) If the content is = needed to be protected, generally you may know all the systems should be = granted by the content owner. > Here I also like to clarify that not only the media itself but the = information related to service itself (such as the geographic = constraint) should be protected also. > So, trust is not a problem for the media. > =20 > Philip, > Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use case. > I like to clarify to U that it is important for you operator since it = may save investment if the system may support different services. > For us vendor, we are happy operator may install a system for the = mobile service and another system for the FBB service. > But the reality is all operators ask us to provide a system that may = support different service systems. > =20 > Frankly, Ben and Philip, I remember I have explained somewhere that to = implement this is rather simple . > At least the Use case and Requirement are informational to be referred = in future work. So I do really feel you may accept it. > Of course I like to respond your more concern and comments. > Thanks. > Zhipeng > =20 > =20 > =20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Monday, October 10, 2011 11:22 PM > To: ben@niven-jenkins.co.uk; ZhouZhipeng > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Ben, Zhipeng, all, > =20 > I think that Content Adaptation is more an issue for the Requirements = doc than for the Use cases draft. > =20 > The key question is whether we want the CDNI interfaces to be able to = cope with a scenario where (say) HD/SD conversion is done in the dCDN & = to signal about this. > =20 > I think that coping with this scenario is a second order requirement, = ie we should not worry about it in the initial standards-track work. I = don't know, did we ever decide whether the Use cases doc is restricted = to "initial" scenarios, or whether it's all-encompassing, ie covering = "future" scenarios as well? > =20 > Scott, > Reading some of your examples, they seem to be valid even if content = adaptation (HD/SD) is out of scope. > - a dCDN might for some reason be unwilling to distribute HD? > - a CSP might want to make sure the dCDN can use HLS encapsulation? > But these sorts of examples seem to be static policy things (to do > with the capabilities & preferences of the CDNs & CSP), rather than > metadata associated with a particular piece of content. In the > discussion so far, I think negotiation about static policy stuff is > rather out of scope(?) > =20 > On security considerations, an interesting question is whether trust = is transitive. Don't think it need be - just because CSP trusts uCDN, = and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the = dCDN. However, i suspect this can get arbitrarily complex - so one = possibility is to say that we will only handle cases where the trust is = transitive. > =20 > Best wishes > phil > =20 > =20 > Philip Eardley > Research and Technology Strategy > =20 > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ Registered in > England no: 1800000 > =20 > =20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: 10 October 2011 12:04 > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Colleagues, > =20 > IMO Section 5.1.3 should be removed from the Use Cases draft. Content = Adaptation (i.e. taking in a content item in one format and transforming = it to another format or representation) is not a "core" function of a = CDN which typically delivers the content that is requested without = explicit knowledge of what that content actually is. > =20 > Let's not forget that in building an end to end content service the = CDN is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. > =20 > The decision as to which version/copy/representation to offer and = allow to be delivered to a given device/user is implemented outside of = the CDN (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content). > =20 > Ben > =20 > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > =20 > Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. > If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. > =20 > Here the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content adaptation. > In last month, I have contacted the Authors of this document and taken = some email exchanges with Grant and Philip (BT). > I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. > Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. > =20 > If you have any more question or comments, pls share in this thread. > Thanks. > Zhipeng > =20 > =20 > =20 > =20 > =20 > =20 > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com] > Sent: Friday, September 30, 2011 8:02 AM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Section 2.3 Nomadic Users > This description falls under the category of Geographic Extension > yet the third paragraph states the case where a different device is > used in the same CDN coverage area. The intent of this use case > needs to be clarified. Perhaps the use case is trying to address > the scenario where a Nomadic User-A with an agreement allowing > access to content from CSP-A via uCDN moves to a dCDN in a different > region. The dCDN is allowed to distribute the content of CSP-A to > User-A; however, not other users in the region of the dCDN are > allowed to retrieve the content unless they too have such an = agreement. > =20 > Section 5.1.3 Content Encoding Restrictions Need to clarify if we're > talking about the restrictions on the delivery of specific content > or the restrictions on the ability of a CDN to deliver specific > content. I certainly understand the case where a CSP will restrict > the distribution of content to a "managed path" if such content is > HD while allowing the content distribution via an un-managed path if > such content is SD (same could apply to encryption methods, delivery > methods, etc.). On the contrary, the dCDN may have its own > restrictions of blocking the distribution of HD content while > allowing the distribution of SD content. > =20 > o first bullet makes sense if the dCDN can perform a subset of > encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) o second bullet makes sense where the dCDN doesn't want to > offer high bit-rate variants of the media o third bullet make sense > if the policy addresses QoE but I don't think subscriber > rights/authorizations apply. > =20 > Section 10 Security Considerations > =20 > Aside from the security considerations WITHIN the uCDN and dCDN, I > think we can describe this in four contexts: > =20 > a. The relationship between the CSP and the uCDN (the principle = contract > arrangement for distribution) > b. The relationship between the uCDN and dCDN (the transitive trust > relationship that extends the contract defined in (a) above) c. The > relationship between the User and dCDN (the recognition of right to > download predicated on (b) above) d. The relationship between the > User and CSP (the contract authorizing the user access to the > content) > =20 > The user is not interested in the a-b nor the b-c relationship. The > user is only interested in the transparency and interoperability of > the security relationship between d-b or d-c to the point that the > authorization granted in d-a is viable when the delivery is > initiated via either d-b or d-c. As an example, the uCDN might use > URL appended tokens for authentication while dCDN might use URL > appended hashes. The user doesn't want to know about the distinct > methods, but transparency is only afforded if the methods are > interoperable clearly defined when the delegation for content > delivery is executed. Clearly, the choice of authentication method is = determined by the respective CDN's. > =20 > Scott > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > =20 --Apple-Mail-753--54882366 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Zhipeng,

As said: I agree = this can be a discussion later and be added to the requirements in a = future release. However: in respect to the speed of the process and as = the delivery part is the biggest majority of the business for = interconnection (please note: interconnection is a business driver, not = technology driver) the focus should be delivery. 
Met vriendelijke = groet,
Kind = regards,

Mark de Jong
International Business = Developer
Jet-Stream BV

E-mail: mark@jet-stream.com
Office: = +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 = 5264214

- = Event: Meet us at = Streaming Media Europe, 17-18 October, London, = UK
- = Event: Meet us at Online Video Strategies, 19 October, London, = UK
- = Event: Meet us at CDN World Summit, 25-28 October, London, = UK
- News: Pre-request= your Technology Whitepaper now and be the first to have it, check www.jet-stream.com
http://www.jet-stream.com to = download our 'Six Trends in CDNs' brochure
- VideoExchange: www.vdo-x.net
 Streamzilla: www.streamzillacdn.com
- Corporate: www.jet-stream.com

On 27, Oct,2011, at 8:45 AM, ZhouZhipeng wrote:

Nice to meet you on = line.
In your company=92s website, I just find some = information that addresses =93 Vodafone subscribers complained about video = performance.=94See:
 
Hi = Alan,
 
As Ben stated the overall = discussion right now is about delivery, not on adaptation. It is hard = enough to get consensus on the delivery aspect already not to mention = your requirement from content adaptation added to that, so I agree with = Ben we should stick with the delivery aspect for the first specs. I = can imagine this could be a discussion later on but please let us keep = the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. = Thanks.
 
Met vriendelijke groet,
Kind = regards,

Mark de Jong
International Business = Developer
Jet-Stream = BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214
- = Event: Meet us at = Streaming Media Europe, 17-18 October, London, UK
- Event: Meet us at Online Video Strategies, 19 = October, London, UK- = Event: Meet us at CDN World Summit, 25-28 = October, London, UK  Pre-request your Technology Whitepaper = now and be the first to have it, check www.jet-stream.com
- News: Check http://www.jet-stream.com to download our 'Six Trends = in CDNs' brochure 
-  
On 26, Oct,2011, at 8:33 PM, Alan = Kavanagh wrote:


Ben

Im assuming then based = on your comments below are you suggesting we are going to have a number = of versions of the CDN-I Metadata?

I sympathise with what you are = pointing out below and do agree that there is some work to be done, but = I still feel that content adaptation is to me a fundamental requirement = to what collectively we should address in the CDN-I WG. I do agree with = you that content adaptation is an optimization between CDN's but it's a = very important one that I know Network Service Providers particularly = require.

Alan

-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: = ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 12 Oct 2011, = at 10:22, ZhouZhipeng wrote:


Hello = Ben,
The UE may select the = content format on the CP web. After that the user only desires to get = his selected content.
But how the content is transferred to the client is not = worried by the user.
The CP may create a special format as required by the = user and ask the CDN to deliver to = user.
While CP = may give a HD format content to uCDN and the dCDN may then transform to = the format as the user select.

Lots of things may be possible = to do and CDN providers offer many additional services on top of the = "core" service of content delivery. However, our objective (based on my = interpretation of the CDNI charter) is to focus on what is necessary to = interconnect CDNs to deliver content from a CSP to an End User that is = targeted and deployable within a short time frame (18-24 = months).

Content transformation/adaptation is not an essential = requirement in order to achieve that aim (we can deliver content from = CSPs to End Users via multiple CDNs without needing or requiring any CDN = supports content adaptation).

In my opinion we have enough work = to do already without trying to expand the scope of our work to include = additional requirements that do not help us address our core objectives = as laid out in the CDNI charter.


In this case, it is nothing = related to how the user select formats on CP = website.
So, it is the CP and = user to decide the content format not the CDN(your assert is not correct = and seems you take that assert as your base for the = discussion).
 
As for "the core CDN functionality offered by CDNs = today", I have ever raised an email before that your company's webpage = has claimed supporting media transformation and multi-screen = service.
Perhaps, I like asking you list some features that you = feel are the core functionalities by existing main stream CDNs. Thus we = may compare and take deep look.

I think the core functionality = maps pretty well to the CDNI interfaces, namely: Request Routing, = Metadata configuration, log production and control plus content = acquisition and content = delivery.


I guess many people have the experience/knowledge of = content related service. The user and CP only care whether the CDN = providers may satisfy their requirement while not care the internal = process. Just as GSM/PSTN interconnection, the user only care successful = interconnection while not care how the voice is transformed in = process.
 
Besides, I like raise a = case:
Given = currently BBC recruits CDN providers that may support 10 media = formats.
One candidate is your company, another is CDN-X. The = users are located in = France.
So both your company and CDN-X should connect a France = CDN provider(CDN-Y).
If your company's solution is to send 10 streams of = different format
of one content to CDN-Y; While CDN-X's solution is to = send 1 stream to CDN-Y while CDN-Y may conduct some = adaptation.
Comparing these two solutions, for your company and = CDN-X, absolutely the cost of CDN-X is much = lower.
For CDN-Y, in solution-1, it should receive/forward 10 = streams ; while in solution-2, it should only receive 1 stream but need = to take transformation to output 10 = streams.
 
Which solution is more competitive. it is Solution 1, = right. Remember the price from BBC is same to both your company and = CDN-X or BBC would select one CDN provider with the lower = price.
If a CDN provider may not get the contract from CP, how = it may say it is not a core = functionality.

What you are describing is a = possible optimization that a particular CDN may wish to implement not a = core functionality required to enable content delivery between = interconnected CDNs. I can think of many optimizations that a CDN could = implement to differentiate their service but the internal workings of an = individual CDN are out of scope of our charter.

So to repeat my = position for a final time: Content adaptation is not a core function = required to enable content delivery between interconnected CDNs and = therefore given the workload we already have to specify solutions that = do address the core functionality required to interconnect CDNs I do not = think we should be trying to add more work into that workload as it will = only distract us from achieving our goal of producing deployable = solutions within the timeframe we are being told by operators they needs = solutions within.

Ben


So, if we all realize that = currently the media type is rich, the CDN providers should survive in = the existing ecosystem and support the media types as required by the = market.
 
Back to the case of GSM/G.711, it just when concerning = the interconnection, the transformation should at once be solved. = Otherwise the interconnection may not be = operated.
 
Br,
Zhipeng
 
 
 
 
-----Original = Message-----
From: Ben Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]
Sent: Wednesday, October 12, 2011 = 12:19 AM
To: = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Zhipeng,
 
On 11 Oct 2011, at 05:16, ZhouZhipeng = wrote:
 
Ben and = Philip,
I like to respond your concern in this one = email:
 
Ben,
I feel what we are now discussing is what is the "core" = function of = CDN.
As you say, CDN is used to deliver content. That is = absolutely correct that the delivery capability is the core requirement = for CDN = system.
While CDN is used to provide the content delivery = service.
What means service. It should include "time" "location" = and "media type", etc. These features are all the core feature for a = service.
If we only concern "delivering one data block", I am not = sure whether the issues such as "logging" "geographic constraint" are = the core of = CDN.
 
For "without explicit knowledge of what that content = actually is ", I am not sure whether the wording is accurate since = generally a CDN may claim it support different = medias.
By this opportunity, I like to share a use case: a call = from a GSM phone to a PSTN telephone, the voice stream should be = transformed from GSM voice to = G.711.
For the user, he does not need to know what type of data = has been transferred, but the operator has done some work to = interconnect two systems, = right.
I like to know whether you may accept that my use case is = similar to this case = above.
 
I don't think your use case is similar to the analogy of = mobile networks being interconnected to PSTN networks. In the case of = content delivery the negotiation is done between the User/Client and the = Content Provider and the CDN is just used to execute/perform the = delivery that has been negotiated. The CDN is not involved in the = decision making of what representations the Content Provider decides to = offer to the User/Client or in what representations the User/Client = decides to request.
 
As for you said selecting media by the "portal", you may = see the way " uCDN delivers multiple media streams to dCDN" is not good = than "uCDN delivers one media stream to dCDN and dCDN takes some = adaptation to support multiple media = types".
 
Now what you're talking about is an optimisation, not a = core function required to actually deliver the content (and report, = bill, etc. for that = delivery).
 
My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO.
 
Ben
 
A good question is "security" since I have done six years = on the DRM
and like to promote the DRM all around the world:) If the = content is needed to be protected, generally you may know all the = systems should be granted by the content = owner.
Here I also like to clarify that not only the media = itself but the information related to service itself (such as the = geographic constraint) should be protected = also.
So, trust is not a problem for the = media.
 
Philip,
Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use = case.
I like to clarify to U that it is important for you = operator since it may save investment if the system may support = different = services.
For us vendor, we are happy operator may install a system = for the mobile service and another system for the FBB = service.
But the reality is all operators ask us to provide a = system that may support different service = systems.
 
Frankly, Ben and Philip, I remember I have explained = somewhere that to implement this is rather simple = .
At least the Use case and Requirement are informational = to be referred in future work. So I do really feel you may accept = it.
Of course I like to respond your more concern and = comments.
Thanks.
Zhipeng
 
 
 
-----Original = Message-----
From: philip.eardley@bt.com [mailto:philip.eardley@bt.com= ]
Sent: Monday, October 10, 2011 11:22 = PM
To: ben@niven-jenkins.co.uk; = ZhouZhipeng
Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Ben, Zhipeng, = all,
 
I think that Content Adaptation is more an issue for the = Requirements doc than for the Use cases = draft.
 
The key question is whether we want the CDNI interfaces = to be able to cope with a scenario where (say) HD/SD conversion is done = in the dCDN & to signal about = this.
 
I think that coping with this scenario is a second order = requirement, ie we should not worry about it in the initial = standards-track work. I don't know, did we ever decide whether the Use = cases doc is restricted to "initial" scenarios, or whether it's = all-encompassing, ie covering "future" scenarios as = well?
 
Scott,
Reading some of your examples, they seem to be valid even = if content adaptation (HD/SD) is out of = scope.
- a dCDN might for some reason be unwilling to distribute = HD?
- a CSP might want to make sure the dCDN can use HLS = encapsulation?
But these sorts of examples seem to be static policy = things (to = do
with the capabilities & preferences of the CDNs & = CSP), rather = than
metadata associated with a particular piece of content. = In the
discussion so far, I think negotiation about static = policy stuff = is
rather out of = scope(?)
 
On security considerations, an interesting question is = whether trust is transitive. Don't think it need be - just because CSP = trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP = automatically trusts the dCDN. However, i suspect this can get = arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.
 
Best = wishes
phil
 
 
Philip = Eardley
Research and Technology = Strategy
 
This email contains BT information, which may be = privileged or confidential. It's meant only for the individual(s) or = entity named above. If you're not the intended recipient, note that = disclosing, copying, distributing or using this information is = prohibited. If you've received this email in error, please let me know = immediately on the email address above. Thank you. We monitor our email = system, and may record your = emails.
British Telecommunications = plc
Registered office: 81 Newgate Street London EC1A 7AJ = Registered = in
England no: = 1800000
 
 
-----Original = Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf
Of Ben = Niven-Jenkins
Sent: 10 October 2011 = 12:04
To: = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Colleagues,
 
IMO Section 5.1.3 should be removed from the Use Cases = draft. Content Adaptation (i.e. taking in a content item in one format = and transforming it to another format or representation) is not a "core" = function of a CDN which typically delivers the content that is requested = without explicit knowledge of what that content actually = is.
 
Let's not forget that in building an end to end content = service the CDN is only one component and is the component tasked with = executing the delivery of a specific representation (version/copy/format = etc.) of the selected content not the component tasked with deciding (or = applying policy) on which version/copy/representation of content should = be = delivered.
 
The decision as to which version/copy/representation to = offer and allow to be delivered to a given device/user is implemented = outside of the CDN (e.g. by the "portal" where the user first makes = their content selection prior to the CDN becoming involved in the = delivery of the selected = content).
 
Ben
 
On 8 Oct 2011, at 08:20, ZhouZhipeng = wrote:
 
Following Scott's comments on section 5.1.3, I feel = Scott's description on the use case of HD and SD is not exactly = correct.
If one movie has two formats of HD and SD, then we have = two content with different identifier. In DRM scope, the basic unit is a = content = copy.
 
Here the first bullet "a subset of = encodings deliverable to specific devices," has listed the case of = content = adaptation.
=
In last month, I have contacted the Authors of this = document and taken some email exchanges with Grant and Philip = (BT).
I have shown BT with some information that I know in this = case and area to explain the content flexibility is currently a basic = requirement for CDN service and related negotiation is needed in the CDN = interconnection.
Meanwhile, I should also invite = you in this group raising your comments or questions on this case since = I hope my use case may be incorporated in the use case = draft.
 
If you have any more question or = comments, pls share in this = thread.
Thanks.
Zhipeng
 
 
 
 
 
 
-----Original = Message-----
From: Scott Wainner = [mailto:swainner@cisco.com]
Sent: Friday, September 30, 2011 = 8:02 = AM
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Section 2.3 Nomadic = Users
This description falls under the category of Geographic = Extension
yet the third paragraph states the case where a different = device = is
used in the same CDN coverage area.  The intent of = this use = case
needs to be clarified.  Perhaps the use case is = trying to = address
the scenario where a Nomadic User-A with an agreement = allowing
access to content from CSP-A via uCDN moves to a dCDN in = a = different
region.  The dCDN is allowed to distribute the = content of CSP-A = to
User-A; however, not other users in the region of the = dCDN = are
allowed to retrieve the content unless they too have such = an = agreement.
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
 
Section 5.1.3 Content Encoding = Restrictions Need to clarify if = we're
talking about the restrictions on the delivery of = specific = content
or the restrictions on the ability of a CDN to deliver = specific
content.  I certainly understand the case where a = CSP will = restrict
the distribution of content to a "managed path" if such = content = is
HD while allowing the content distribution via an = un-managed path = if
such content is SD (same could apply to encryption = methods, = delivery
methods, etc.).  On the contrary, the dCDN may have = its = own
restrictions of blocking the distribution of HD content = while
allowing the distribution of SD = content.
 
o first bullet makes sense if the = dCDN can perform a subset = of
encapsulations for a reference set of media (e.g. HLS, = HSS, but = not
DASH) o second bullet makes sense where the dCDN doesn't = want = to
offer high bit-rate variants of the media o third bullet = make = sense
if the policy addresses QoE but I don't think = subscriber
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
rights/authorizations = apply.
 
Section 10 Security = Considerations
 
Aside from the security = considerations WITHIN the uCDN and dCDN, = I
think we can describe this in four = contexts:
 
a. The relationship between the = CSP and the uCDN (the principle = contract
arrangement for = distribution)
b. The relationship between the = uCDN and dCDN (the transitive = trust
relationship that extends the contract defined in (a) = above) c. = The
relationship between the User and dCDN (the recognition = of right = to
download predicated on (b) above) d. The relationship = between = the
User and CSP (the contract authorizing the user access to = the
content)
<= /blockquote>
 
The user is not interested in the = a-b nor the b-c relationship. = The
user is only interested in the transparency and = interoperability = of
the security relationship between d-b or d-c to the point = that = the
authorization granted in d-a is viable when the delivery = is
initiated via either d-b or d-c.  As an example, the = uCDN might = use
URL appended tokens for authentication while dCDN might = use = URL
appended hashes.  The user doesn't want to know = about the = distinct
methods, but transparency is only afforded if the methods = are
interoperable clearly defined when the delegation for = content
delivery is executed.  Clearly, the choice of = authentication method is determined by the respective = CDN's.
 
Scott
 
_______________________________________________<= /span>
CDNi mailing = list
_______________________________________________<= /span>

= --Apple-Mail-753--54882366-- From zhouzhipeng@huawei.com Thu Oct 27 01:12:59 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FE921F85B8 for ; Thu, 27 Oct 2011 01:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dv67oB5Gc4vb for ; Thu, 27 Oct 2011 01:12:45 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E4EBD21F85AE for ; Thu, 27 Oct 2011 01:12:44 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTP00L2JTET9M@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 27 Oct 2011 16:11:17 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTP0028OTC55F@szxga05-in.huawei.com> for cdni@ietf.org; Thu, 27 Oct 2011 16:11:17 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEL80928; Thu, 27 Oct 2011 16:11:15 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 27 Oct 2011 16:11:10 +0800 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.117]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Thu, 27 Oct 2011 16:11:08 +0800 Date: Thu, 27 Oct 2011 08:11:08 +0000 From: ZhouZhipeng In-reply-to: X-Originating-IP: [10.138.73.38] To: Mark de Jong Message-id: <260A32EFD5C9EB47AD504929D005DF6217F6C749@SZXEML519-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yKY1wcUJ6zlGCLk1uIP4Tg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgBYn8ICAAA1tAIABOe8g//+IbYCAAIZnEA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 08:12:59 -0000 --Boundary_(ID_yKY1wcUJ6zlGCLk1uIP4Tg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Mark, I fully agree that it is a business driver. So I emphasized many times that the content adaptation is a urgent and important market demand. In fact I am not advertising for some http streaming products, but the variable streaming solution is the real market requirement. Absolutely CDN is for delivery but it should be also clarified here it is "content delivery" not only "bitrate delivery". As you see the operator may develop subscribers only when it may provide enough functionality and quality. Thanks. Zhipeng From: Mark de Jong [mailto:mark@jet-stream.nl] Sent: Thursday, October 27, 2011 3:57 PM To: ZhouZhipeng Cc: Alan Kavanagh; Ben Niven-Jenkins; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Zhipeng, As said: I agree this can be a discussion later and be added to the requirements in a future release. However: in respect to the speed of the process and as the delivery part is the biggest majority of the business for interconnection (please note: interconnection is a business driver, not technology driver) the focus should be delivery. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 27, Oct,2011, at 8:45 AM, ZhouZhipeng wrote: Hello Mark, Nice to meet you on line. In your company's website, I just find some information that addresses " Vodafone subscribers complained about video performance." See: http://www.jet-stream.nl/search/?search=transcoding Dear all in this group, In last few days, except the public email discussions I have contacted with some people and discussed with my own colleagues of all details on this issue. First, although the market requirement for it is very important, I feel I'd better show up more information on the procedure involved. I have explained many times that to support content adaptation is rather simple while the wording is not enough. I am busy making some contributions on this and plan to upload to ETSI meeting and IETF CDNI. By these work I feel the people may catch a whole view on this issue. Second, for that functionality, in implementation, if some entity does not choose to support it, it may be ok. Since it may be negotiated between two CDNs. If dCDN does not support that, it may be the uCDN responsible to complete the transcoding and deliver the content of multiple formats and rates to dCDN. Third, although CDNI is a new architecture, while the content operating has been existed for years. As I know the content from USA to the downstream operator is transferred on one copy and the downstream operator will handle the transcoding. Perhaps, the content adaptation is more on the mobile operating. But I feel currently most operator will be a all service operator. And for the CDN providers, it may be better to support all kinds of service. Besides, I like say that the technology on this topic has been for many years and has been rather mature, even some items in ietf such as rfc3507 icap. So from the technique point of view, it is a nature action to be involved in CDN interconnection. Thanks. Zhipeng From: Mark de Jong [mailto:mark@jet-stream.nl] Sent: Thursday, October 27, 2011 4:21 AM To: Alan Kavanagh Cc: Ben Niven-Jenkins; ZhouZhipeng; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Alan, As Ben stated the overall discussion right now is about delivery, not on adaptation. It is hard enough to get consensus on the delivery aspect already not to mention your requirement from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for the first specs. I can imagine this could be a discussion later on but please let us keep the scope of this be clean and transparent. It is of benefit of everyone to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: Ben Im assuming then based on your comments below are you suggesting we are going to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that there is some work to be done, but I still feel that content adaptation is to me a fundamental requirement to what collectively we should address in the CDN-I WG. I do agree with you that content adaptation is an optimization between CDN's but it's a very important one that I know Network Service Providers particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: Hello Ben, The UE may select the content format on the CP web. After that the user only desires to get his selected content. But how the content is transferred to the client is not worried by the user. The CP may create a special format as required by the user and ask the CDN to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select. Lots of things may be possible to do and CDN providers offer many additional services on top of the "core" service of content delivery. However, our objective (based on my interpretation of the CDNI charter) is to focus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and deployable within a short time frame (18-24 months). Content transformation/adaptation is not an essential requirement in order to achieve that aim (we can deliver content from CSPs to End Users via multiple CDNs without needing or requiring any CDN supports content adaptation). In my opinion we have enough work to do already without trying to expand the scope of our work to include additional requirements that do not help us address our core objectives as laid out in the CDNI charter. In this case, it is nothing related to how the user select formats on CP website. So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion). As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look. I think the core functionality maps pretty well to the CDNI interfaces, namely: Request Routing, Metadata configuration, log production and control plus content acquisition and content delivery. I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media formats. One candidate is your company, another is CDN-X. The users are located in France. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. What you are describing is a possible optimization that a particular CDN may wish to implement not a core functionality required to enable content delivery between interconnected CDNs. I can think of many optimizations that a CDN could implement to differentiate their service but the internal workings of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core function required to enable content delivery between interconnected CDNs and therefore given the workload we already have to specify solutions that do address the core functionality required to interconnect CDNs I do not think we should be trying to add more work into that workload as it will only distract us from achieving our goal of producing deployable solutions within the timeframe we are being told by operators they needs solutions within. Ben So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: Ben and Philip, I like to respond your concern in this one email: Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN. For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias. By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711. For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to this case above. I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request. As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types". Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery). My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO. Ben A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) If the content is needed to be protected, generally you may know all the systems should be granted by the content owner. Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also. So, trust is not a problem for the media. Philip, Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it may save investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service. But the reality is all operators ask us to provide a system that may support different service systems. Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple . At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ben, Zhipeng, all, I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft. The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this. I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well? Scott, Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive. Best wishes phil Philip Eardley Research and Technology Strategy This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is. Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. If you have any more question or comments, pls share in this thread. Thanks. Zhipeng -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. Section 10 Security Considerations Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is determined by the respective CDN's. Scott _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --Boundary_(ID_yKY1wcUJ6zlGCLk1uIP4Tg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Mark,

I fully ag= ree that it is a business driver. So I emphasized many times that the conte= nt adaptation is a urgent and important market demand.

In fact I = am not advertising for some http streaming products, but the variable strea= ming solution is the real market requirement.

Absolutely= CDN is for delivery but it should be also clarified here it is “cont= ent delivery” not only “bitrate delivery”.

As you see= the operator may develop subscribers only when it may provide enough funct= ionality and quality.

 = ;

Thanks.

Zhipeng

 = ;

From: Mark de Jong [mailto:mark@jet-stream.nl]
Sent: Thursday, October 27, 2011 3:57 PM
To: ZhouZhipeng
Cc: Alan Kavanagh; Ben Niven-Jenkins; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

 

Hi Zhipeng,

 

As said: I agree this can be a = discussion later and be added to the requirements in a future release. Howe= ver: in respect to the speed of the process and as the delivery part is the= biggest majority of the business for interconnection (please note: interconnection is a business driver, not te= chnology driver) the focus should be delivery. 

 = ;

Met vriendelijke groet,

Kind regards,

Mark de Jong
International Business Developer Jet-Stream BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214

 

- Event: Meet us at Streaming Media Europe, 17-18 October, London, UK

- VideoExchange: ww= w.vdo-x.net

- Streamzilla: <= span lang=3D"EN-US" style=3D"font-size:6.5pt;font-family:"Calibri"= ;,"sans-serif";color:black">www.streamzillacdn.com

- Corporate:<= /b> www.jet= -stream.com

 

On 27, Oct,2011, at 8:45 AM, Zh= ouZhipeng wrote:



Hello Mark= ,

Nice to me= et you on line.

In your co= mpany’s website, I just find some information that addresses “<= span class=3D"apple-converted-space"> Vodafone subscribers complained about video performance.”

See:

 

Dear all i= n this group,

In last fe= w days, except the public email discussions I have contacted with some peop= le and discussed with my own colleagues of all details on this issue.

First, alt= hough the market requirement for it is very important, I feel I’d bet= ter show up more information on the procedure involved. I have explained many times that to support content adaptation is rather simple while the w= ording is not enough.

I am busy = making some contributions on this and plan to upload to ETSI meeting and IE= TF CDNI.

By these w= ork  I feel the people may catch a whole view on this issue.

Second, fo= r that functionality, in implementation, if some entity does not choose to = support it, it may be ok. Since it may be negotiated between two CDNs.

If dCDN do= es not support that, it may be the uCDN responsible to complete the transco= ding and deliver the content of multiple formats and rates to dCDN.

Third, alt= hough CDNI is a new architecture, while the content operating has been exis= ted for years. As I know the content from USA to the downstream operator is transferred on one copy and the downstream operator will handl= e the transcoding.

 

Perhaps, t= he content adaptation is more on the mobile operating. But I feel currently= most operator will be a all service operator. And for the CDN providers, it may be better to support all kinds of service.

Besides, I= like say that the technology on this topic has been for many years and has= been rather mature, even some items in ietf such as rfc3507 icap. So from the technique point of view, it is a nature action to be inv= olved in CDN interconnection.=

Thanks.

Zhipeng

 

 

 

From: Mark de Jong [mailto:mark@jet-stream.nl]&= nbsp;
Sent: Thursday, Oc= tober 27, 2011 4:21 AM
To: Alan Kavanagh<= br> Cc: Ben Niven-Jenk= ins; ZhouZhipeng; cdni@ietf.org
Subject: Re: [CDNi= ] I-D Action: draft-ietf-cdni-use-cases-00.txt<= o:p>

 

Hi Alan,

 

As Ben stated the overall discu= ssion right now is about delivery, not on adaptation. It is hard enough to = get consensus on the delivery aspect already not to mention your requiremen= t from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for the first= specs. I can imagine this could be a discussion later on but please l= et us keep the scope of this be clean and transparent. It is of benefit of = everyone to get the first specs as fast as possible. Thanks.

 

Met vriendelijke groet,

Kind regards,

Mark de Jong
International Business Developer Jet-Stream BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214

 <= span lang=3D"EN-US">

- Event: Meet us at Streaming Media Europe, 17-18 October, London, UK

- Event: Meet us at Online Video Strategies, 19 October, London, UK

- Event: Meet us at CDN World Summit, 25-28 October, London, UK

- News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs' brochure

 

- Blog: = www.jet-stream.com/blog/<= /span>

- VideoExchange: ww= w.vdo-x.net

- Streamzilla: <= span lang=3D"EN-US" style=3D"font-size:6.5pt;font-family:"Calibri"= ;,"sans-serif";color:black">www.streamzillacdn.com

- Corporate:<= /b> www.jet= -stream.com

 

On 26, Oct,2011, at 8:33 PM, Al= an Kavanagh wrote:




Ben

Im assuming then based on your comments below are you suggesting we are goi= ng to have a number of versions of the CDN-I Metadata?

I sympathise with what you are pointing out below and do agree that there i= s some work to be done, but I still feel that content adaptation is to me a= fundamental requirement to what collectively we should address in the CDN-= I WG. I do agree with you that content adaptation is an optimization between CDN's but it's a very important one = that I know Network Service Providers particularly require.

Alan

-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Nive= n-Jenkins
Sent: October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 12 Oct 2011, at 10:22, ZhouZhipeng wrote:



Hello Ben,

The UE may select the content f= ormat on the CP web. After that the user only desires to get his selected c= ontent.

But how the content is transfer= red to the client is not worried by the user.

The CP may create a special for= mat as required by the user and ask the CDN to deliver to user.<= /span>

While CP may give a HD format c= ontent to uCDN and the dCDN may then transform to the format as the user se= lect.


Lots of things may be possible to do and CDN providers offer many additiona= l services on top of the "core" service of content delivery. Howe= ver, our objective (based on my interpretation of the CDNI charter) is to f= ocus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and dep= loyable within a short time frame (18-24 months).

Content transformation/adaptation is not an essential requirement in order = to achieve that aim (we can deliver content from CSPs to End Users via mult= iple CDNs without needing or requiring any CDN supports content adaptation)= .

In my opinion we have enough work to do already without trying to expand th= e scope of our work to include additional requirements that do not help us = address our core objectives as laid out in the CDNI charter.



In this case, it is nothing rel= ated to how the user select formats on CP website.

So, it is the CP and user to de= cide the content format not the CDN(your assert is not correct and seems yo= u take that assert as your base for the discussion).

 

As for "the core CDN funct= ionality offered by CDNs today", I have ever raised an email before th= at your company's webpage has claimed supporting media transformation and m= ulti-screen service.

Perhaps, I like asking you list= some features that you feel are the core functionalities by existing main = stream CDNs. Thus we may compare and take deep look.


I think the core functionality maps pretty well to the CDNI interfaces, nam= ely: Request Routing, Metadata configuration, log production and control pl= us content acquisition and content delivery.



I guess many people have the ex= perience/knowledge of content related service. The user and CP only care wh= ether the CDN providers may satisfy their requirement while not care the in= ternal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice= is transformed in process.

 

Besides, I like raise a case:

Given currently BBC recruits CD= N providers that may support 10 media formats.

One candidate is your company, = another is CDN-X. The users are located in France.

So both your company and CDN-X = should connect a France CDN provider(CDN-Y).

If your company's solution is t= o send 10 streams of different format

of one content to CDN-Y; While = CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some = adaptation.

Comparing these two solutions, = for your company and CDN-X, absolutely the cost of CDN-X is much lower.

For CDN-Y, in solution-1, it sh= ould receive/forward 10 streams ; while in solution-2, it should only recei= ve 1 stream but need to take transformation to output 10 streams.

 

Which solution is more competit= ive. it is Solution 1, right. Remember the price from BBC is same to both y= our company and CDN-X or BBC would select one CDN provider with the lower p= rice.

If a CDN provider may not get t= he contract from CP, how it may say it is not a core functionality.


What you are describing is a possible optimization that a particular CDN ma= y wish to implement not a core functionality required to enable content del= ivery between interconnected CDNs. I can think of many optimizations that a= CDN could implement to differentiate their service but the internal workings of an individual CDN are out of sc= ope of our charter.

So to repeat my position for a final time: Content adaptation is not a core= function required to enable content delivery between interconnected CDNs a= nd therefore given the workload we already have to specify solutions that d= o address the core functionality required to interconnect CDNs I do not think we should be trying to add mo= re work into that workload as it will only distract us from achieving our g= oal of producing deployable solutions within the timeframe we are being tol= d by operators they needs solutions within.

Ben



So, if we all realize that curr= ently the media type is rich, the CDN providers should survive in the exist= ing ecosystem and support the media types as required by the market.

 

Back to the case of GSM/G.711, = it just when concerning the interconnection, the transformation should at o= nce be solved. Otherwise the interconnection may not be operated.

 

Br,

Zhipeng

 

 

 

 

-----Original Message-----=

From: Ben Niven-Jenkins [mailto= :ben@niven-jenkins.co.uk]

Sent: Wednesday, October 12, 20= 11 12:19 AM

To: ZhouZhipeng

Subject: Re: [CDNi] I-D Action:= draft-ietf-cdni-use-cases-00.txt

 

Zhipeng,

 

On 11 Oct 2011, at 05:16, ZhouZ= hipeng wrote:

 

Ben and Philip,

I like to respond your concern = in this one email:

 

Ben,

I feel what we are now discussi= ng is what is the "core" function of CDN.

As you say, CDN is used to deli= ver content. That is absolutely correct that the delivery capability is the= core requirement for CDN system.

While CDN is used to provide th= e content delivery service.

What means service. It should i= nclude "time" "location" and "media type", et= c. These features are all the core feature for a service.=

If we only concern "delive= ring one data block", I am not sure whether the issues such as "l= ogging" "geographic constraint" are the core of CDN.

 

For "without explicit know= ledge of what that content actually is ", I am not sure whether the wo= rding is accurate since generally a CDN may claim it support different medi= as.

By this opportunity, I like to = share a use case: a call from a GSM phone to a PSTN telephone, the voice st= ream should be transformed from GSM voice to G.711.

For the user, he does not need = to know what type of data has been transferred, but the operator has done s= ome work to interconnect two systems, right.

I like to know whether you may = accept that my use case is similar to this case above.

 

I don't think your use case is = similar to the analogy of mobile networks being interconnected to PSTN netw= orks. In the case of content delivery the negotiation is done between the U= ser/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been neg= otiated. The CDN is not involved in the decision making of what representat= ions the Content Provider decides to offer to the User/Client or in what re= presentations the User/Client decides to request.

 

As for you said selecting media= by the "portal", you may see the way " uCDN delivers multip= le media streams to dCDN" is not good than "uCDN delivers one med= ia stream to dCDN and dCDN takes some adaptation to support multiple media types".

 

Now what you're talking about i= s an optimisation, not a core function required to actually deliver the con= tent (and report, bill, etc. for that delivery).

 

My position is that we should f= ocus on how to enable the interconnection of the core CDN functionality off= ered by CDNs today (which is also my interpretation of the scope of the CDN= I working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's = not start trying to add in additional functionality beyond what the majorit= y of CDNs support today as that will just delay us getting usable specifica= tions into the market in a timely fashion IMO.

 

Ben

 

A good question is "securi= ty" since I have done six years on the DRM

and like to promote the DRM all= around the world:) If the content is needed to be protected, generally you= may know all the systems should be granted by the content owner.

Here I also like to clarify tha= t not only the media itself but the information related to service itself (= such as the geographic constraint) should be protected also.

So, trust is not a problem for = the media.

 

Philip,

Thank you that you feel Content= Adaption is an issue for "Requirements" but I do not know why it= is not for Use case.

I like to clarify to U that it = is important for you operator since it may save investment if the system ma= y support different services.

For us vendor, we are happy ope= rator may install a system for the mobile service and another system for th= e FBB service.

But the reality is all operator= s ask us to provide a system that may support different service systems.

 

Frankly, Ben and Philip, I reme= mber I have explained somewhere that to implement this is rather simple .

At least the Use case and Requi= rement are informational to be referred in future work. So I do really feel= you may accept it.

Of course I like to respond you= r more concern and comments.

Thanks.

Zhipeng

 

 

 

-----Original Message-----=

From: philip.ea= rdley@bt.com [mailto:= philip.eardley@bt.com]

Sent: Monday, October 10, 2011 = 11:22 PM

To: ben@niven= -jenkins.co.uk; ZhouZhipeng

Subject: RE: [CDNi] I-D Action:= draft-ietf-cdni-use-cases-00.txt

 

Ben, Zhipeng, all,

 

I think that Content Adaptation= is more an issue for the Requirements doc than for the Use cases draft.

 

The key question is whether we = want the CDNI interfaces to be able to cope with a scenario where (say) HD/= SD conversion is done in the dCDN & to signal about this.

 

I think that coping with this s= cenario is a second order requirement, ie we should not worry about it in t= he initial standards-track work. I don't know, did we ever decide whether t= he Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future"= ; scenarios as well?

 

Scott,

Reading some of your examples, = they seem to be valid even if content adaptation (HD/SD) is out of scope.

- a dCDN might for some reason = be unwilling to distribute HD?

- a CSP might want to make sure= the dCDN can use HLS encapsulation?

But these sorts of examples see= m to be static policy things (to do

with the capabilities & pre= ferences of the CDNs & CSP), rather than

metadata associated with a part= icular piece of content. In the

discussion so far, I think nego= tiation about static policy stuff is

rather out of scope(?)

 

On security considerations, an = interesting question is whether trust is transitive. Don't think it need be= - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the= CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility i= s to say that we will only handle cases where the trust is transitive.=

 

Best wishes

phil

 

 

Philip Eardley

Research and Technology Strateg= y

 

This email contains BT informat= ion, which may be privileged or confidential. It's meant only for the indiv= idual(s) or entity named above. If you're not the intended recipient, note = that disclosing, copying, distributing or using this information is prohibited. If you've received this email in = error, please let me know immediately on the email address above. Thank you= . We monitor our email system, and may record your emails.

British Telecommunications plc<= o:p>

Registered office: 81 Newgate S= treet London EC1A 7AJ Registered in

England no: 1800000<= /span>

 

 

-----Original Message-----=

From: cdni-boun= ces@ietf.org [mailto:= cdni-bounces@ietf.org] On Behalf

Of Ben Niven-Jenkins=

Sent: 10 October 2011 12:04

To: ZhouZhipeng

Subject: Re: [CDNi] I-D Action:= draft-ietf-cdni-use-cases-00.txt

 

Colleagues,

 

IMO Section 5.1.3 should be rem= oved from the Use Cases draft. Content Adaptation (i.e. taking in a content= item in one format and transforming it to another format or representation= ) is not a "core" function of a CDN which typically delivers the content that is requested without explicit kn= owledge of what that content actually is.

 

Let's not forget that in buildi= ng an end to end content service the CDN is only one component and is the c= omponent tasked with executing the delivery of a specific representation (v= ersion/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on whi= ch version/copy/representation of content should be delivered.

 

The decision as to which versio= n/copy/representation to offer and allow to be delivered to a given device/= user is implemented outside of the CDN (e.g. by the "portal" wher= e the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content= ).

 

Ben

 

On 8 Oct 2011, at 08:20, ZhouZh= ipeng wrote:

 

Following Scott's comments on s= ection 5.1.3, I feel Scott's description on the use case of HD and SD is no= t exactly correct.

If one movie has two formats of= HD and SD, then we have two content with different identifier. In DRM scop= e, the basic unit is a content copy.

 

Here the first bullet "a s= ubset of encodings deliverable to specific devices," has listed the ca= se of content adaptation.

In last month, I have contacted= the Authors of this document and taken some email exchanges with Grant and= Philip (BT).

I have shown BT with some infor= mation that I know in this case and area to explain the content flexibility= is currently a basic requirement for CDN service and related negotiation i= s needed in the CDN interconnection.

Meanwhile, I should also invite= you in this group raising your comments or questions on this case since I = hope my use case may be incorporated in the use case draft.

 

If you have any more question o= r comments, pls share in this thread.

Thanks.

Zhipeng

 

 

 

 

 

 

-----Original Message-----=

From: Scott Wainner [mailto:swa= inner@cisco.com]

Sent: Friday, September 30, 201= 1 8:02 AM

Subject: Re: [CDNi] I-D Action:= draft-ietf-cdni-use-cases-00.txt

 

Section 2.3 Nomadic Users<= /o:p>

This description falls under th= e category of Geographic Extension

yet the third paragraph states = the case where a different device is

used in the same CDN coverage a= rea.  The intent of this use case

needs to be clarified.  Pe= rhaps the use case is trying to address

the scenario where a Nomadic Us= er-A with an agreement allowing

access to content from CSP-A vi= a uCDN moves to a dCDN in a different

region.  The dCDN is allow= ed to distribute the content of CSP-A to

User-A; however, not other user= s in the region of the dCDN are

allowed to retrieve the content= unless they too have such an agreement.

 

Section 5.1.3 Content Encoding = Restrictions Need to clarify if we're

talking about the restrictions = on the delivery of specific content

or the restrictions on the abil= ity of a CDN to deliver specific

content.  I certainly unde= rstand the case where a CSP will restrict

the distribution of content to = a "managed path" if such content is

HD while allowing the content d= istribution via an un-managed path if

such content is SD (same could = apply to encryption methods, delivery

methods, etc.).  On the co= ntrary, the dCDN may have its own

restrictions of blocking the di= stribution of HD content while

allowing the distribution of SD= content.

 

o first bullet makes sense if t= he dCDN can perform a subset of

encapsulations for a reference = set of media (e.g. HLS, HSS, but not

DASH) o second bullet makes sen= se where the dCDN doesn't want to

offer high bit-rate variants of= the media o third bullet make sense

if the policy addresses QoE but= I don't think subscriber

rights/authorizations apply.

 

Section 10 Security Considerati= ons

 

Aside from the security conside= rations WITHIN the uCDN and dCDN, I

think we can describe this in f= our contexts:

 

a. The relationship between the= CSP and the uCDN (the principle contract

arrangement for distribution)

b. The relationship between the= uCDN and dCDN (the transitive trust

relationship that extends the c= ontract defined in (a) above) c. The

relationship between the User a= nd dCDN (the recognition of right to

download predicated on (b) abov= e) d. The relationship between the

User and CSP (the contract auth= orizing the user access to the

content)

 

The user is not interested in t= he a-b nor the b-c relationship. The

user is only interested in the = transparency and interoperability of

the security relationship betwe= en d-b or d-c to the point that the

authorization granted in d-a is= viable when the delivery is

initiated via either d-b or d-c= .  As an example, the uCDN might use

URL appended tokens for authent= ication while dCDN might use URL

appended hashes.  The user= doesn't want to know about the distinct

methods, but transparency is on= ly afforded if the methods are

interoperable clearly defined w= hen the delegation for content

delivery is executed.  Cle= arly, the choice of authentication method is determined by the respective C= DN's.

 

Scott

 

_______________________________= ________________

CDNi mailing list

 

_______________________________= ________________

CDNi mailing list

 

=
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni

 

 

--Boundary_(ID_yKY1wcUJ6zlGCLk1uIP4Tg)-- From mark@jet-stream.nl Thu Oct 27 02:41:09 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2FD21F8490 for ; Thu, 27 Oct 2011 02:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.697 X-Spam-Level: X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5sk-LNDleqv for ; Thu, 27 Oct 2011 02:41:05 -0700 (PDT) Received: from monitor1.jet-stream.nl (smtp.jet-stream.nl [91.196.106.226]) by ietfa.amsl.com (Postfix) with ESMTP id D96B921F89BA for ; Thu, 27 Oct 2011 02:41:03 -0700 (PDT) Received: from pc0046.hhpn.btopenzone.com ([217.41.230.215]) (authenticated bits=0) by monitor1.jet-stream.nl (8.13.7/8.13.7) with ESMTP id p9R9eXNX014070 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 27 Oct 2011 11:40:35 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-845--48670556 From: Mark de Jong In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6217F6C749@SZXEML519-MBX.china.huawei.com> Date: Thu, 27 Oct 2011 10:40:29 +0100 Message-Id: <7ACB09B9-C857-44A8-B47F-A15136FC6AD8@jet-stream.nl> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <260A32EFD5C9EB47AD504929D005DF6217F6C749@SZXEML519-MBX.china.huawei.com> To: ZhouZhipeng X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 09:41:09 -0000 --Apple-Mail-845--48670556 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Zhipeng, It is a slowly growing demand but still very little in terms of = revenue/demand. The majority of the business nowadays and in respect to = interconnection will be about delivery on the short/mid-term. We really = don't get much request for content adaptation on our own CDN-service or = as a requirement for our CDN-software. So I disagree that adaptation is = an important market demand at this moment, especially on = interconnection. I think I have made my point that we stick with = delivery for the reasons I already mentioned and I think the group = agrees with that too. Again: I'm not excluding the option for the = future. So please: let us stop this discussion and go forward on the = actual work to be done: standards. :) Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 27, Oct,2011, at 9:11 AM, ZhouZhipeng wrote: > Hi Mark, > I fully agree that it is a business driver. So I emphasized many times = that the content adaptation is a urgent and important market demand. > In fact I am not advertising for some http streaming products, but the = variable streaming solution is the real market requirement. > Absolutely CDN is for delivery but it should be also clarified here it = is =93content delivery=94 not only =93bitrate delivery=94. > As you see the operator may develop subscribers only when it may = provide enough functionality and quality. > =20 > Thanks. > Zhipeng > =20 > From: Mark de Jong [mailto:mark@jet-stream.nl]=20 > Sent: Thursday, October 27, 2011 3:57 PM > To: ZhouZhipeng > Cc: Alan Kavanagh; Ben Niven-Jenkins; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Hi Zhipeng, > =20 > As said: I agree this can be a discussion later and be added to the = requirements in a future release. However: in respect to the speed of = the process and as the delivery part is the biggest majority of the = business for interconnection (please note: interconnection is a business = driver, not technology driver) the focus should be delivery.=20 > =20 > Met vriendelijke groet, > Kind regards, >=20 > Mark de Jong > International Business Developer > Jet-Stream BV >=20 > E-mail: mark@jet-stream.com > Office: +31 (0)50 5261820 > Mobile: +31 (0)6 81108263 > Fax: +31 (0)50 5264214 > =20 > - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK > - Event: Meet us at Online Video Strategies, 19 October, London, UK > - Event: Meet us at CDN World Summit, 25-28 October, London, UK > - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com > - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure > =20 > - Blog: www.jet-stream.com/blog/ > - VideoExchange: www.vdo-x.net > - Streamzilla: www.streamzillacdn.com > - Corporate: www.jet-stream.com > =20 > On 27, Oct,2011, at 8:45 AM, ZhouZhipeng wrote: >=20 >=20 > Hello Mark, > Nice to meet you on line. > In your company=92s website, I just find some information that = addresses =93 Vodafone subscribers complained about video performance.=94 > See: > http://www.jet-stream.nl/search/?search=3Dtranscoding > =20 > Dear all in this group, > In last few days, except the public email discussions I have contacted = with some people and discussed with my own colleagues of all details on = this issue. > First, although the market requirement for it is very important, I = feel I=92d better show up more information on the procedure involved. I = have explained many times that to support content adaptation is rather = simple while the wording is not enough. > I am busy making some contributions on this and plan to upload to ETSI = meeting and IETF CDNI. > By these work I feel the people may catch a whole view on this issue. > Second, for that functionality, in implementation, if some entity does = not choose to support it, it may be ok. Since it may be negotiated = between two CDNs. > If dCDN does not support that, it may be the uCDN responsible to = complete the transcoding and deliver the content of multiple formats and = rates to dCDN. > Third, although CDNI is a new architecture, while the content = operating has been existed for years. As I know the content from USA to = the downstream operator is transferred on one copy and the downstream = operator will handle the transcoding. > =20 > Perhaps, the content adaptation is more on the mobile operating. But I = feel currently most operator will be a all service operator. And for the = CDN providers, it may be better to support all kinds of service. > Besides, I like say that the technology on this topic has been for = many years and has been rather mature, even some items in ietf such as = rfc3507 icap. So from the technique point of view, it is a nature action = to be involved in CDN interconnection. > Thanks. > Zhipeng > =20 > =20 > =20 > From: Mark de Jong [mailto:mark@jet-stream.nl]=20 > Sent: Thursday, October 27, 2011 4:21 AM > To: Alan Kavanagh > Cc: Ben Niven-Jenkins; ZhouZhipeng; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Hi Alan, > =20 > As Ben stated the overall discussion right now is about delivery, not = on adaptation. It is hard enough to get consensus on the delivery aspect = already not to mention your requirement from content adaptation added to = that, so I agree with Ben we should stick with the delivery aspect for = the first specs. I can imagine this could be a discussion later on but = please let us keep the scope of this be clean and transparent. It is of = benefit of everyone to get the first specs as fast as possible. Thanks. > =20 > Met vriendelijke groet, > Kind regards, >=20 > Mark de Jong > International Business Developer > Jet-Stream BV >=20 > E-mail: mark@jet-stream.com > Office: +31 (0)50 5261820 > Mobile: +31 (0)6 81108263 > Fax: +31 (0)50 5264214 > =20 > - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK > - Event: Meet us at Online Video Strategies, 19 October, London, UK > - Event: Meet us at CDN World Summit, 25-28 October, London, UK > - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com > - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure > =20 > - Blog: www.jet-stream.com/blog/ > - VideoExchange: www.vdo-x.net > - Streamzilla: www.streamzillacdn.com > - Corporate: www.jet-stream.com > =20 > On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: >=20 >=20 >=20 > Ben >=20 > Im assuming then based on your comments below are you suggesting we = are going to have a number of versions of the CDN-I Metadata? >=20 > I sympathise with what you are pointing out below and do agree that = there is some work to be done, but I still feel that content adaptation = is to me a fundamental requirement to what collectively we should = address in the CDN-I WG. I do agree with you that content adaptation is = an optimization between CDN's but it's a very important one that I know = Network Service Providers particularly require. >=20 > Alan >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins > Sent: October-12-11 1:13 PM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Zhipeng, >=20 > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: >=20 >=20 >=20 > Hello Ben, > The UE may select the content format on the CP web. After that the = user only desires to get his selected content. > But how the content is transferred to the client is not worried by the = user. > The CP may create a special format as required by the user and ask the = CDN to deliver to user. > While CP may give a HD format content to uCDN and the dCDN may then = transform to the format as the user select. >=20 > Lots of things may be possible to do and CDN providers offer many = additional services on top of the "core" service of content delivery. = However, our objective (based on my interpretation of the CDNI charter) = is to focus on what is necessary to interconnect CDNs to deliver content = from a CSP to an End User that is targeted and deployable within a short = time frame (18-24 months). >=20 > Content transformation/adaptation is not an essential requirement in = order to achieve that aim (we can deliver content from CSPs to End Users = via multiple CDNs without needing or requiring any CDN supports content = adaptation). >=20 > In my opinion we have enough work to do already without trying to = expand the scope of our work to include additional requirements that do = not help us address our core objectives as laid out in the CDNI charter. >=20 >=20 >=20 > In this case, it is nothing related to how the user select formats on = CP website. > So, it is the CP and user to decide the content format not the = CDN(your assert is not correct and seems you take that assert as your = base for the discussion). > =20 > As for "the core CDN functionality offered by CDNs today", I have ever = raised an email before that your company's webpage has claimed = supporting media transformation and multi-screen service. > Perhaps, I like asking you list some features that you feel are the = core functionalities by existing main stream CDNs. Thus we may compare = and take deep look. >=20 > I think the core functionality maps pretty well to the CDNI = interfaces, namely: Request Routing, Metadata configuration, log = production and control plus content acquisition and content delivery. >=20 >=20 >=20 > I guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in process. > =20 > Besides, I like raise a case: > Given currently BBC recruits CDN providers that may support 10 media = formats. > One candidate is your company, another is CDN-X. The users are located = in France. > So both your company and CDN-X should connect a France CDN = provider(CDN-Y). > If your company's solution is to send 10 streams of different format > of one content to CDN-Y; While CDN-X's solution is to send 1 stream to = CDN-Y while CDN-Y may conduct some adaptation. > Comparing these two solutions, for your company and CDN-X, absolutely = the cost of CDN-X is much lower. > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while = in solution-2, it should only receive 1 stream but need to take = transformation to output 10 streams. > =20 > Which solution is more competitive. it is Solution 1, right. Remember = the price from BBC is same to both your company and CDN-X or BBC would = select one CDN provider with the lower price. > If a CDN provider may not get the contract from CP, how it may say it = is not a core functionality. >=20 > What you are describing is a possible optimization that a particular = CDN may wish to implement not a core functionality required to enable = content delivery between interconnected CDNs. I can think of many = optimizations that a CDN could implement to differentiate their service = but the internal workings of an individual CDN are out of scope of our = charter. >=20 > So to repeat my position for a final time: Content adaptation is not a = core function required to enable content delivery between interconnected = CDNs and therefore given the workload we already have to specify = solutions that do address the core functionality required to = interconnect CDNs I do not think we should be trying to add more work = into that workload as it will only distract us from achieving our goal = of producing deployable solutions within the timeframe we are being told = by operators they needs solutions within. >=20 > Ben >=20 >=20 >=20 > So, if we all realize that currently the media type is rich, the CDN = providers should survive in the existing ecosystem and support the media = types as required by the market. > =20 > Back to the case of GSM/G.711, it just when concerning the = interconnection, the transformation should at once be solved. Otherwise = the interconnection may not be operated. > =20 > Br, > Zhipeng > =20 > =20 > =20 > =20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Wednesday, October 12, 2011 12:19 AM > To: ZhouZhipeng > Cc: philip.eardley@bt.com; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Zhipeng, > =20 > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > =20 > Ben and Philip, > I like to respond your concern in this one email: > =20 > Ben, > I feel what we are now discussing is what is the "core" function of = CDN. > As you say, CDN is used to deliver content. That is absolutely correct = that the delivery capability is the core requirement for CDN system. > While CDN is used to provide the content delivery service. > What means service. It should include "time" "location" and "media = type", etc. These features are all the core feature for a service. > If we only concern "delivering one data block", I am not sure whether = the issues such as "logging" "geographic constraint" are the core of = CDN. > =20 > For "without explicit knowledge of what that content actually is ", I = am not sure whether the wording is accurate since generally a CDN may = claim it support different medias. > By this opportunity, I like to share a use case: a call from a GSM = phone to a PSTN telephone, the voice stream should be transformed from = GSM voice to G.711. > For the user, he does not need to know what type of data has been = transferred, but the operator has done some work to interconnect two = systems, right. > I like to know whether you may accept that my use case is similar to = this case above. > =20 > I don't think your use case is similar to the analogy of mobile = networks being interconnected to PSTN networks. In the case of content = delivery the negotiation is done between the User/Client and the Content = Provider and the CDN is just used to execute/perform the delivery that = has been negotiated. The CDN is not involved in the decision making of = what representations the Content Provider decides to offer to the = User/Client or in what representations the User/Client decides to = request. > =20 > As for you said selecting media by the "portal", you may see the way " = uCDN delivers multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media types". > =20 > Now what you're talking about is an optimisation, not a core function = required to actually deliver the content (and report, bill, etc. for = that delivery). > =20 > My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO. > =20 > Ben > =20 > A good question is "security" since I have done six years on the DRM > and like to promote the DRM all around the world:) If the content is = needed to be protected, generally you may know all the systems should be = granted by the content owner. > Here I also like to clarify that not only the media itself but the = information related to service itself (such as the geographic = constraint) should be protected also. > So, trust is not a problem for the media. > =20 > Philip, > Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use case. > I like to clarify to U that it is important for you operator since it = may save investment if the system may support different services. > For us vendor, we are happy operator may install a system for the = mobile service and another system for the FBB service. > But the reality is all operators ask us to provide a system that may = support different service systems. > =20 > Frankly, Ben and Philip, I remember I have explained somewhere that to = implement this is rather simple . > At least the Use case and Requirement are informational to be referred = in future work. So I do really feel you may accept it. > Of course I like to respond your more concern and comments. > Thanks. > Zhipeng > =20 > =20 > =20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Monday, October 10, 2011 11:22 PM > To: ben@niven-jenkins.co.uk; ZhouZhipeng > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Ben, Zhipeng, all, > =20 > I think that Content Adaptation is more an issue for the Requirements = doc than for the Use cases draft. > =20 > The key question is whether we want the CDNI interfaces to be able to = cope with a scenario where (say) HD/SD conversion is done in the dCDN & = to signal about this. > =20 > I think that coping with this scenario is a second order requirement, = ie we should not worry about it in the initial standards-track work. I = don't know, did we ever decide whether the Use cases doc is restricted = to "initial" scenarios, or whether it's all-encompassing, ie covering = "future" scenarios as well? > =20 > Scott, > Reading some of your examples, they seem to be valid even if content = adaptation (HD/SD) is out of scope. > - a dCDN might for some reason be unwilling to distribute HD? > - a CSP might want to make sure the dCDN can use HLS encapsulation? > But these sorts of examples seem to be static policy things (to do > with the capabilities & preferences of the CDNs & CSP), rather than > metadata associated with a particular piece of content. In the > discussion so far, I think negotiation about static policy stuff is > rather out of scope(?) > =20 > On security considerations, an interesting question is whether trust = is transitive. Don't think it need be - just because CSP trusts uCDN, = and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the = dCDN. However, i suspect this can get arbitrarily complex - so one = possibility is to say that we will only handle cases where the trust is = transitive. > =20 > Best wishes > phil > =20 > =20 > Philip Eardley > Research and Technology Strategy > =20 > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ Registered in > England no: 1800000 > =20 > =20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: 10 October 2011 12:04 > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Colleagues, > =20 > IMO Section 5.1.3 should be removed from the Use Cases draft. Content = Adaptation (i.e. taking in a content item in one format and transforming = it to another format or representation) is not a "core" function of a = CDN which typically delivers the content that is requested without = explicit knowledge of what that content actually is. > =20 > Let's not forget that in building an end to end content service the = CDN is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. > =20 > The decision as to which version/copy/representation to offer and = allow to be delivered to a given device/user is implemented outside of = the CDN (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content). > =20 > Ben > =20 > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > =20 > Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. > If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. > =20 > Here the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content adaptation. > In last month, I have contacted the Authors of this document and taken = some email exchanges with Grant and Philip (BT). > I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. > Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. > =20 > If you have any more question or comments, pls share in this thread. > Thanks. > Zhipeng > =20 > =20 > =20 > =20 > =20 > =20 > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com] > Sent: Friday, September 30, 2011 8:02 AM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Section 2.3 Nomadic Users > This description falls under the category of Geographic Extension > yet the third paragraph states the case where a different device is > used in the same CDN coverage area. The intent of this use case > needs to be clarified. Perhaps the use case is trying to address > the scenario where a Nomadic User-A with an agreement allowing > access to content from CSP-A via uCDN moves to a dCDN in a different > region. The dCDN is allowed to distribute the content of CSP-A to > User-A; however, not other users in the region of the dCDN are > allowed to retrieve the content unless they too have such an = agreement. > =20 > Section 5.1.3 Content Encoding Restrictions Need to clarify if we're > talking about the restrictions on the delivery of specific content > or the restrictions on the ability of a CDN to deliver specific > content. I certainly understand the case where a CSP will restrict > the distribution of content to a "managed path" if such content is > HD while allowing the content distribution via an un-managed path if > such content is SD (same could apply to encryption methods, delivery > methods, etc.). On the contrary, the dCDN may have its own > restrictions of blocking the distribution of HD content while > allowing the distribution of SD content. > =20 > o first bullet makes sense if the dCDN can perform a subset of > encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) o second bullet makes sense where the dCDN doesn't want to > offer high bit-rate variants of the media o third bullet make sense > if the policy addresses QoE but I don't think subscriber > rights/authorizations apply. > =20 > Section 10 Security Considerations > =20 > Aside from the security considerations WITHIN the uCDN and dCDN, I > think we can describe this in four contexts: > =20 > a. The relationship between the CSP and the uCDN (the principle = contract > arrangement for distribution) > b. The relationship between the uCDN and dCDN (the transitive trust > relationship that extends the contract defined in (a) above) c. The > relationship between the User and dCDN (the recognition of right to > download predicated on (b) above) d. The relationship between the > User and CSP (the contract authorizing the user access to the > content) > =20 > The user is not interested in the a-b nor the b-c relationship. The > user is only interested in the transparency and interoperability of > the security relationship between d-b or d-c to the point that the > authorization granted in d-a is viable when the delivery is > initiated via either d-b or d-c. As an example, the uCDN might use > URL appended tokens for authentication while dCDN might use URL > appended hashes. The user doesn't want to know about the distinct > methods, but transparency is only afforded if the methods are > interoperable clearly defined when the delegation for content > delivery is executed. Clearly, the choice of authentication method is = determined by the respective CDN's. > =20 > Scott > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > =20 > =20 --Apple-Mail-845--48670556 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Zhipeng,

It is a slowly = growing demand but still very little in terms of = revenue/demand. The majority of the business nowadays and in = respect to interconnection will be about delivery on the short/mid-term. = We really don't get much request for content adaptation on our own = CDN-service or as a requirement for our CDN-software. So I disagree that = adaptation is an important market demand at this moment, especially on = interconnection. I think I have made my point that we stick with = delivery for the reasons I already mentioned and I think the group = agrees with that too. Again: I'm not excluding the option for the = future. So please: let us stop this discussion and go forward on the = actual work to be done: standards. :)
Met vriendelijke = groet,
Kind = regards,

Mark de Jong
International Business = Developer
Jet-Stream BV

E-mail: mark@jet-stream.com
Office: = +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 = 5264214

- = Event: Meet us at = Streaming Media Europe, 17-18 October, London, = UK
- = Event: Meet us at Online Video Strategies, 19 October, London, = UK
- = Event: Meet us at CDN World Summit, 25-28 October, London, = UK
- News: Pre-request= your Technology Whitepaper now and be the first to have it, check www.jet-stream.com
http://www.jet-stream.com to = download our 'Six Trends in CDNs' brochure
- VideoExchange: www.vdo-x.net
 Streamzilla: www.streamzillacdn.com
- Corporate: www.jet-stream.com

On 27, Oct,2011, at 9:11 AM, ZhouZhipeng wrote:

Hi = Mark,
I fully agree that it is a business driver. So I = emphasized many times that the content adaptation is a urgent and = important market demand.
In fact I am not advertising for = some http streaming products, but the variable streaming solution is the = real market requirement.
Absolutely CDN is for delivery = but it should be also clarified here it is =93content delivery=94 not = only =93bitrate delivery=94.
As you see = the operator may develop subscribers only when it may provide enough = functionality and quality.
Thanks.
 
 Mark de Jong = [mailto:mark@jet-stream.nl] 
Sent: Thursday, October 27, 2011 = 3:57 PM
To: ZhouZhipeng
Cc: Alan Kavanagh; Ben = Niven-Jenkins; cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Hi = Zhipeng,
 
As said: I agree this can be a = discussion later and be added to the requirements in a future release. = However: in respect to the speed of the process and as the delivery part = is the biggest majority of the business for interconnection (please = note: interconnection is a business driver, not technology driver) the = focus should be = delivery. 
=
Met = vriendelijke groet,Kind = regards,

Mark de Jong
International Business = Developer
Jet-Stream = BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214
- = Event: Meet us at = Streaming Media Europe, 17-18 October, London, UK
- Event: Meet us at Online Video Strategies, 19 = October, London, UK- = Event: Meet us at CDN World Summit, 25-28 = October, London, UK  Pre-request your Technology Whitepaper = now and be the first to have it, check www.jet-stream.com
- News: Check http://www.jet-stream.com to download our 'Six Trends = in CDNs' brochure 
-  
On 27, Oct,2011, at 8:45 AM, = ZhouZhipeng wrote:


Hello = Mark,
Nice to = meet you on line.
In your = company=92s website, I just find some information that addresses =93 Vodafone subscribers complained about video = performance.=94
 
Hi = Alan,
 
As Ben stated the overall = discussion right now is about delivery, not on adaptation. It is hard = enough to get consensus on the delivery aspect already not to mention = your requirement from content adaptation added to that, so I agree with = Ben we should stick with the delivery aspect for the first specs. I = can imagine this could be a discussion later on but please let us keep = the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. = Thanks.
 
 
On 26, Oct,2011, at 8:33 PM, Alan = Kavanagh wrote:



Ben

Im assuming then based = on your comments below are you suggesting we are going to have a number = of versions of the CDN-I Metadata?

I sympathise with what you are = pointing out below and do agree that there is some work to be done, but = I still feel that content adaptation is to me a fundamental requirement = to what collectively we should address in the CDN-I WG. I do agree with = you that content adaptation is an optimization between CDN's but it's a = very important one that I know Network Service Providers particularly = require.

Alan

-----Original Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: = ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 12 Oct 2011, = at 10:22, ZhouZhipeng = wrote:



Hello = Ben,
The UE may = select the content format on the CP web. After that the user only = desires to get his selected = content.
But how the content is transferred = to the client is not worried by the = user.
The CP may create a special format = as required by the user and ask the CDN to deliver to = user.
While CP may give a HD format = content to uCDN and the dCDN may then transform to the format as the = user select.

Lots of things may be possible = to do and CDN providers offer many additional services on top of the = "core" service of content delivery. However, our objective (based on my = interpretation of the CDNI charter) is to focus on what is necessary to = interconnect CDNs to deliver content from a CSP to an End User that is = targeted and deployable within a short time frame (18-24 = months).

Content transformation/adaptation is not an essential = requirement in order to achieve that aim (we can deliver content from = CSPs to End Users via multiple CDNs without needing or requiring any CDN = supports content adaptation).

In my opinion we have enough work = to do already without trying to expand the scope of our work to include = additional requirements that do not help us address our core objectives = as laid out in the CDNI = charter.



In this case, it is nothing = related to how the user select formats on CP = website.
So, = it is the CP and user to decide the content format not the CDN(your = assert is not correct and seems you take that assert as your base for = the discussion).
 
As for "the core CDN functionality = offered by CDNs today", I have ever raised an email before that your = company's webpage has claimed supporting media transformation and = multi-screen = service.
Perhaps, I like asking you list = some features that you feel are the core functionalities by existing = main stream CDNs. Thus we may compare and take deep = look.

I think the core functionality = maps pretty well to the CDNI interfaces, namely: Request Routing, = Metadata configuration, log production and control plus content = acquisition and content = delivery.



I guess many people have the = experience/knowledge of content related service. The user and CP only = care whether the CDN providers may satisfy their requirement while not = care the internal process. Just as GSM/PSTN interconnection, the user = only care successful interconnection while not care how the voice is = transformed in process.
 
Besides, I like raise a = case:
Given currently BBC recruits CDN = providers that may support 10 media = formats.
One candidate is your company, = another is CDN-X. The users are located in = France.
So both your company and CDN-X = should connect a France CDN = provider(CDN-Y).
If your company's solution is to = send 10 streams of different = format
of one content to CDN-Y; While = CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct = some adaptation.
Comparing these two solutions, for = your company and CDN-X, absolutely the cost of CDN-X is much = lower.
For CDN-Y, in solution-1, it = should receive/forward 10 streams ; while in solution-2, it should only = receive 1 stream but need to take transformation to output 10 = streams.
 
Which solution is more = competitive. it is Solution 1, right. Remember the price from BBC is = same to both your company and CDN-X or BBC would select one CDN provider = with the lower = price.
If a CDN provider may not get the = contract from CP, how it may say it is not a core = functionality.

What you are describing is a = possible optimization that a particular CDN may wish to implement not a = core functionality required to enable content delivery between = interconnected CDNs. I can think of many optimizations that a CDN could = implement to differentiate their service but the internal workings of an = individual CDN are out of scope of our charter.

So to repeat my = position for a final time: Content adaptation is not a core function = required to enable content delivery between interconnected CDNs and = therefore given the workload we already have to specify solutions that = do address the core functionality required to interconnect CDNs I do not = think we should be trying to add more work into that workload as it will = only distract us from achieving our goal of producing deployable = solutions within the timeframe we are being told by operators they needs = solutions = within.

Ben



So, if we all realize that = currently the media type is rich, the CDN providers should survive in = the existing ecosystem and support the media types as required by the = market.
 
Back to the case of GSM/G.711, it = just when concerning the interconnection, the transformation should at = once be solved. Otherwise the interconnection may not be = operated.
 
Br,
Zhipeng
 
 
 
 
-----Original = Message-----
From: Ben Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]
Sent: Wednesday, October 12, 2011 = 12:19 AM
To: = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Zhipeng,
 
On 11 Oct 2011, at 05:16, = ZhouZhipeng wrote:
 
Ben and = Philip,
I like to respond your concern in = this one = email:
 
Ben,
I feel what we are now discussing = is what is the "core" function of = CDN.
As you say, CDN is used to deliver = content. That is absolutely correct that the delivery capability is the = core requirement for CDN = system.
While CDN is used to provide the = content delivery = service.
What means service. It should = include "time" "location" and "media type", etc. These features are all = the core feature for a = service.
If we only concern "delivering one = data block", I am not sure whether the issues such as "logging" = "geographic constraint" are the core of = CDN.
 
For "without explicit knowledge of = what that content actually is ", I am not sure whether the wording is = accurate since generally a CDN may claim it support different = medias.
By this opportunity, I like to = share a use case: a call from a GSM phone to a PSTN telephone, the voice = stream should be transformed from GSM voice to = G.711.
For the user, he does not need to = know what type of data has been transferred, but the operator has done = some work to interconnect two systems, = right.
I like to know whether you may = accept that my use case is similar to this case = above.
 
I don't think your use case is = similar to the analogy of mobile networks being interconnected to PSTN = networks. In the case of content delivery the negotiation is done = between the User/Client and the Content Provider and the CDN is just = used to execute/perform the delivery that has been negotiated. The CDN = is not involved in the decision making of what representations the = Content Provider decides to offer to the User/Client or in what = representations the User/Client decides to = request.
 
As for you said selecting media by = the "portal", you may see the way " uCDN delivers multiple media streams = to dCDN" is not good than "uCDN delivers one media stream to dCDN and = dCDN takes some adaptation to support multiple media = types".
 
Now what you're talking about is = an optimisation, not a core function required to actually deliver the = content (and report, bill, etc. for that = delivery).
 
My position is that we should = focus on how to enable the interconnection of the core CDN functionality = offered by CDNs today (which is also my interpretation of the scope of = the CDNI working group as expressed in its charter) because doing so is = a significant piece of work in itself. Let's not start trying to add in = additional functionality beyond what the majority of CDNs support today = as that will just delay us getting usable specifications into the market = in a timely fashion = IMO.
 
Ben
 
A good question is "security" = since I have done six years on the = DRM
and like to promote the DRM all = around the world:) If the content is needed to be protected, generally = you may know all the systems should be granted by the content = owner.
Here I also like to clarify that = not only the media itself but the information related to service itself = (such as the geographic constraint) should be protected = also.
So, trust is not a problem for the = media.
 
Philip,
Thank you that you feel Content = Adaption is an issue for "Requirements" but I do not know why it is not = for Use = case.
I like to clarify to U that it is = important for you operator since it may save investment if the system = may support different = services.
For us vendor, we are happy = operator may install a system for the mobile service and another system = for the FBB = service.
But the reality is all operators = ask us to provide a system that may support different service = systems.
 
Frankly, Ben and Philip, I = remember I have explained somewhere that to implement this is rather = simple = .
At least the Use case and = Requirement are informational to be referred in future work. So I do = really feel you may accept = it.
Of course I like to respond your = more concern and = comments.
Thanks.
Zhipeng
 
 
 
-----Original = Message-----
From: philip.eardley@bt.com [mailto:philip.eardley@bt.com= ]
Sent: Monday, October 10, 2011 = 11:22 = PM
To: ben@niven-jenkins.co.uk; = ZhouZhipeng
Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Ben, Zhipeng, = all,
 
I think that Content Adaptation is = more an issue for the Requirements doc than for the Use cases = draft.
 
The key question is whether we = want the CDNI interfaces to be able to cope with a scenario where (say) = HD/SD conversion is done in the dCDN & to signal about = this.
 
I think that coping with this = scenario is a second order requirement, ie we should not worry about it = in the initial standards-track work. I don't know, did we ever decide = whether the Use cases doc is restricted to "initial" scenarios, or = whether it's all-encompassing, ie covering "future" scenarios as = well?
 
Scott,
Reading some of your examples, = they seem to be valid even if content adaptation (HD/SD) is out of = scope.
- a dCDN might for some reason be = unwilling to distribute = HD?
- a CSP might want to make sure = the dCDN can use HLS = encapsulation?
But these sorts of examples seem = to be static policy things (to = do
with the capabilities & = preferences of the CDNs & CSP), rather = than
metadata associated with a = particular piece of content. In = the
discussion so far, I think = negotiation about static policy stuff = is
rather out of = scope(?)
 
On security considerations, an = interesting question is whether trust is transitive. Don't think it need = be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean = that the CSP automatically trusts the dCDN. However, i suspect this can = get arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.
 
Best = wishes
phil
 
 
Philip = Eardley
Research and Technology = Strategy
 
This email contains BT = information, which may be privileged or confidential. It's meant only = for the individual(s) or entity named above. If you're not the intended = recipient, note that disclosing, copying, distributing or using this = information is prohibited. If you've received this email in error, = please let me know immediately on the email address above. Thank you. We = monitor our email system, and may record your = emails.
British Telecommunications = plc
Registered office: 81 Newgate = Street London EC1A 7AJ Registered = in
England no: = 1800000
 
 
-----Original = Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On = Behalf
Of Ben = Niven-Jenkins
Sent: 10 October 2011 = 12:04
To: = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Colleagues,
 
IMO Section 5.1.3 should be = removed from the Use Cases draft. Content Adaptation (i.e. taking in a = content item in one format and transforming it to another format or = representation) is not a "core" function of a CDN which typically = delivers the content that is requested without explicit knowledge of = what that content actually = is.
 
Let's not forget that in building = an end to end content service the CDN is only one component and is the = component tasked with executing the delivery of a specific = representation (version/copy/format etc.) of the selected content not = the component tasked with deciding (or applying policy) on which = version/copy/representation of content should be = delivered.
 
The decision as to which = version/copy/representation to offer and allow to be delivered to a = given device/user is implemented outside of the CDN (e.g. by the = "portal" where the user first makes their content selection prior to the = CDN becoming involved in the delivery of the selected = content).
 
Ben
=
 
On 8 Oct 2011, at 08:20, = ZhouZhipeng = wrote:
 
Following Scott's comments on = section 5.1.3, I feel Scott's description on the use case of HD and SD = is not exactly = correct.
If one movie has two formats of HD = and SD, then we have two content with different identifier. In DRM = scope, the basic unit is a content = copy.
=
 
Here the first bullet "a subset of = encodings deliverable to specific devices," has listed the case of = content = adaptation.
In last month, I have contacted = the Authors of this document and taken some email exchanges with Grant = and Philip = (BT).
=
I have shown BT with some = information that I know in this case and area to explain the content = flexibility is currently a basic requirement for CDN service and related = negotiation is needed in the CDN = interconnection.
Meanwhile, I should also invite = you in this group raising your comments or questions on this case since = I hope my use case may be incorporated in the use case = draft.
 
If you have any more question or = comments, pls share in this = thread.
Thanks.
Zhipeng
 
 
 
 
 
 
-----Original = Message-----
From: Scott Wainner = [mailto:swainner@cisco.com]
Sent: = Friday, September 30, 2011 8:02 = AM
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Section 2.3 Nomadic = Users
=
This description falls under the = category of Geographic = Extension
yet the third paragraph states the = case where a different device = is
used in the same CDN coverage = area.  The intent of this use = case
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
needs to be clarified. =  Perhaps the use case is trying to = address
the scenario where a Nomadic = User-A with an agreement = allowing
access to content from CSP-A via = uCDN moves to a dCDN in a = different
region.  The dCDN is allowed = to distribute the content of CSP-A = to
User-A; however, not other users = in the region of the dCDN = are
allowed to retrieve the content = unless they too have such an = agreement.
 
Section 5.1.3 Content Encoding = Restrictions Need to clarify if = we're
=
talking about the restrictions on = the delivery of specific = content
or the restrictions on the ability = of a CDN to deliver = specific
content.  I certainly = understand the case where a CSP will = restrict
the distribution of content to a = "managed path" if such content = is
HD while allowing the content = distribution via an un-managed path = if
such content is SD (same could = apply to encryption methods, = delivery
methods, etc.).  On the = contrary, the dCDN may have its = own
restrictions of blocking the = distribution of HD content = while
=
allowing the distribution of SD = content.
 
o first bullet makes sense if the = dCDN can perform a subset = of
encapsulations for a reference set = of media (e.g. HLS, HSS, but = not
DASH) o second bullet makes sense = where the dCDN doesn't want = to
offer high bit-rate variants of = the media o third bullet make = sense
=
if the policy addresses QoE but I = don't think = subscriber
rights/authorizations = apply.
 
Section 10 Security = Considerations
 
Aside from the security = considerations WITHIN the uCDN and dCDN, = I
think we can describe this in four = contexts:
 
a. The relationship between the = CSP and the uCDN (the principle = contract
arrangement for = distribution)
b. The relationship between the = uCDN and dCDN (the transitive = trust
=
relationship that extends the = contract defined in (a) above) c. = The
relationship between the User and = dCDN (the recognition of right = to
download predicated on (b) above) = d. The relationship between = the
User and CSP (the contract = authorizing the user access to = the
content)
 
The user is not interested in the = a-b nor the b-c relationship. = The
user is only interested in the = transparency and interoperability = of
the security relationship between = d-b or d-c to the point that = the
authorization granted in d-a is = viable when the delivery = is
initiated via either d-b or d-c. =  As an example, the uCDN might = use
URL appended tokens for = authentication while dCDN might use = URL
appended hashes.  The user = doesn't want to know about the = distinct
methods, but transparency is only = afforded if the methods = are
interoperable clearly defined when = the delegation for = content
delivery is executed. =  Clearly, the choice of authentication method is determined by the = respective = CDN's.
 
Scott
 
_______________________________________________<= /span>
CDNi mailing = list
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">

= --Apple-Mail-845--48670556-- From ben@niven-jenkins.co.uk Thu Oct 27 03:59:20 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0030C21F86A5 for ; Thu, 27 Oct 2011 03:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.159 X-Spam-Level: X-Spam-Status: No, score=-103.159 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWEGMyLgK-g3 for ; Thu, 27 Oct 2011 03:59:19 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 3722621F8663 for ; Thu, 27 Oct 2011 03:59:19 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp65-237.cachelogic.com) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RJNg3-00045B-C5; Thu, 27 Oct 2011 11:59:15 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 27 Oct 2011 11:59:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2A0AF3CA-36D1-4F0E-8D09-3E29EFBC72A6@niven-jenkins.co.uk> References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> To: Will Li(jincheng) X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] =?utf-8?b?562U5aSNOiAgUHJlcGFyaW5nIGRyYWZ0LWlldGYtY2RuaS1w?= =?utf-8?q?roblem-statement_for_WG_Last_Call?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 10:59:20 -0000 Will, On 27 Oct 2011, at 03:34, Will Li(jincheng) wrote: >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> I don't think the Problem Statement draft should try to describe the = different >> business relationships as they are many and varied depending on = things like the >> purpose of the specific CDN, the market it is deployed in etc and it = would be very >> difficult to describe all the different business relationships and we = would risk >> getting distracted by comments along the lines of "what about this = business >> relationship that you haven't described" and "you haven't adequately = captured >> how this relationship could work" etc. >>=20 >> Section 1.2 already states that "Readers are assumed to be familiar = with the >> architecture, features and operation of CDNs." and I assume if = readers already >> have that familiarity with how CDNs work & are operated then they can >> understand how CSPs, upstream CDNs, downstream CDNs may fit together = as >> part of the CDNI reference model. >>=20 > Agree inappropriate description may lead confusion. However, I am = thinking of some general but safe descriptions on the relationship of = these roles, like=20 > "In a typical content delivery service, A CSP contracts with an = upstream CDN to store and deliver content to User Agents; the upstream = CDN further contracts with one or more downstream CDN(s) to distribute = and deliver contents on uCDN=92s behalf. However, these business = relationships are out of scope of CDNI.", if this kind of description is = safe to be added below the figure, then it can ease people to understand = the following staff in this draft. I took another look at the draft and my proposal is to add a couple of = sentences to the bottom of the first paragraph of the Introduction = (Section 1) as follows: OLD: This creates a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. NEW: This creates a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. For example, a CSP = could contract with an "authoritative" CDN for the delivery content and = that CDN could contract with one or more downstream CDN(s) to distribute and deliver some or all of the content on behalf of the authoritative = CDN. The formation and details of any business relationships between a CSP = and=20 a CDN and between one CDN and another CDN are out of scope of this=20 document. Ben From richard_woundy@cable.comcast.com Thu Oct 27 04:23:19 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5321F899F for ; Thu, 27 Oct 2011 04:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.684 X-Spam-Level: X-Spam-Status: No, score=-100.684 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nSYWDq1j1B6O for ; Thu, 27 Oct 2011 04:23:15 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 535FC21F889A for ; Thu, 27 Oct 2011 04:23:15 -0700 (PDT) Received: from ([24.40.55.42]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.58906500; Thu, 27 Oct 2011 05:30:44 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Thu, 27 Oct 2011 07:22:59 -0400 From: "Woundy, Richard" To: "'zhouzhipeng@huawei.com'" , "'mark@jet-stream.nl'" , "'alan.kavanagh@ericsson.com'" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMlJrH+AfYaJHkLUSNSjteXvY+9A== Date: Thu, 27 Oct 2011 11:22:58 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.50.241] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136C1D7DPACDCEXMB05cabl_" MIME-Version: 1.0 Cc: "'cdni@ietf.org'" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 11:23:19 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1136C1D7DPACDCEXMB05cabl_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PkluIHlvdXIgY29tcGFueeKAmXMgd2Vic2l0ZSwgSSBqdXN0IGZpbmQgc29tZSBpbmZvcm1hdGlv bg0KDQpJIGhhdmUgdG8gc3RlcCBpbiBhcyBjby1jaGFpciBoZXJlLg0KDQpUaGUgZ29hbCBvZiB0 aGlzIFdHIGlzIG5vdCB0byBhbGlnbiB2ZW5kb3IgcHJvZHVjdCByb2FkbWFwcywgb3IgdG8gZXF1 YWxpemUgYWxsIHZlbmRvciBvZmZlcmluZ3MsIG9yIHRvIHNwZWNpZnkgdGhlIGVudGlyZSBDRE5J IGVjb3N5c3RlbS4gVGhlIGdvYWwgb2YgdGhpcyBXRyBpcyB0byBlbmFibGUgdGhlIGludGVyY29u bmVjdGlvbiBhbmQgaW50ZXJvcGVyYXRpb24gb2YgdHdvIG9yIG1vcmUgQ0ROcywgd2l0aGluIHRo ZSBib3VuZHMgb2YgdGhlIENETkkgd2cgY2hhcnRlci4NCg0KSXQgaXMgT0sgdG8gaGF2ZSBhIGRp c2N1c3Npb24gYWJvdXQgd2hldGhlciBjb250ZW50IGFkYXB0YXRpb24gbmVlZHMgdG8gYmUgcGVy Zm9ybWVkIGJ5IHRoZSBkQ0ROLCBzaW5jZSB0aGF0IGRlY2lzaW9uIGltcGFjdHMgdGhlIHVDRE4t ZENETiBpbnRlcmZhY2UuIFNvIGxldCdzIGZpbmQgYSBwcm9kdWN0aXZlIHdheSB0byBkaXNjdXNz IHRoaXMgb24gdGhlIG1haWxpbmcgbGlzdCwgYW5kIHRvIGNsb3NlIHRoZSBkaXNjdXNzaW9uIGJ5 IElFVEYgODIgKGlmIG5vdCBzb29uZXIpLg0KDQpDYW4gc29tZW9uZSBkZXNjcmliZSByZWFsLWxp ZmUgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBDRE4gKG9yIGVkZ2UgY2FjaGUtYmFzZWQpIGNv bnRlbnQgYWRhcHRhdGlvbiBpcyBuZWVkZWQgdG9kYXkgaW4gYSBwcm9kdWN0aW9uIGVudmlyb25t ZW50LCBvciBzaG9ydGx5PyBOb3QgbWVyZWx5IGEgZmVhdHVyZSBpbiBhIHZlbmRvcidzIHByb2R1 Y3QgbWF0ZXJpYWxzPw0KDQpTcGVha2luZyBhcyBhbiBpbmRpdmlkdWFsLCBJIGNhbiBmaW5kIGEg bG90IG9mIGV4YW1wbGVzIHdoZXJlIGRvd25zdHJlYW0gY29udGVudCBhZGFwdGF0aW9uIGlzIG5v dCBuZWVkZWQsIGFuZCBhbnkgYWRhcHRhdGlvbiBpcyByZWFsbHkgcGFydCBvZiB0aGUgQ1AgLSB1 Q0ROIGludGVyZmFjZSAod2hpY2ggaXMgb3V0IG9mIHRoZSBzY29wZSBvZiBvdXIgY2hhcnRlciku DQoNCi0tIFJpY2gNCg0KDQpGcm9tOiBaaG91WmhpcGVuZyBbbWFpbHRvOnpob3V6aGlwZW5nQGh1 YXdlaS5jb21dDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSAwMzo0NSBBTQ0KVG86 IE1hcmsgZGUgSm9uZyA8bWFya0BqZXQtc3RyZWFtLm5sPjsgQWxhbiBLYXZhbmFnaCA8YWxhbi5r YXZhbmFnaEBlcmljc3Nvbi5jb20+DQpDYzogY2RuaUBpZXRmLm9yZyA8Y2RuaUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNl cy0wMC50eHQNCg0KSGVsbG8gTWFyaywNCk5pY2UgdG8gbWVldCB5b3Ugb24gbGluZS4NCkluIHlv dXIgY29tcGFueeKAmXMgd2Vic2l0ZSwgSSBqdXN0IGZpbmQgc29tZSBpbmZvcm1hdGlvbiB0aGF0 IGFkZHJlc3NlcyDigJwgVm9kYWZvbmUgc3Vic2NyaWJlcnMgY29tcGxhaW5lZCBhYm91dCB2aWRl byBwZXJmb3JtYW5jZS7igJ0NClNlZToNCmh0dHA6Ly93d3cuamV0LXN0cmVhbS5ubC9zZWFyY2gv P3NlYXJjaD10cmFuc2NvZGluZw0KDQpEZWFyIGFsbCBpbiB0aGlzIGdyb3VwLA0KSW4gbGFzdCBm ZXcgZGF5cywgZXhjZXB0IHRoZSBwdWJsaWMgZW1haWwgZGlzY3Vzc2lvbnMgSSBoYXZlIGNvbnRh Y3RlZCB3aXRoIHNvbWUgcGVvcGxlIGFuZCBkaXNjdXNzZWQgd2l0aCBteSBvd24gY29sbGVhZ3Vl cyBvZiBhbGwgZGV0YWlscyBvbiB0aGlzIGlzc3VlLg0KRmlyc3QsIGFsdGhvdWdoIHRoZSBtYXJr ZXQgcmVxdWlyZW1lbnQgZm9yIGl0IGlzIHZlcnkgaW1wb3J0YW50LCBJIGZlZWwgSeKAmWQgYmV0 dGVyIHNob3cgdXAgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGUgcHJvY2VkdXJlIGludm9sdmVkLiBJ IGhhdmUgZXhwbGFpbmVkIG1hbnkgdGltZXMgdGhhdCB0byBzdXBwb3J0IGNvbnRlbnQgYWRhcHRh dGlvbiBpcyByYXRoZXIgc2ltcGxlIHdoaWxlIHRoZSB3b3JkaW5nIGlzIG5vdCBlbm91Z2guDQpJ IGFtIGJ1c3kgbWFraW5nIHNvbWUgY29udHJpYnV0aW9ucyBvbiB0aGlzIGFuZCBwbGFuIHRvIHVw bG9hZCB0byBFVFNJIG1lZXRpbmcgYW5kIElFVEYgQ0ROSS4NCkJ5IHRoZXNlIHdvcmsgIEkgZmVl bCB0aGUgcGVvcGxlIG1heSBjYXRjaCBhIHdob2xlIHZpZXcgb24gdGhpcyBpc3N1ZS4NClNlY29u ZCwgZm9yIHRoYXQgZnVuY3Rpb25hbGl0eSwgaW4gaW1wbGVtZW50YXRpb24sIGlmIHNvbWUgZW50 aXR5IGRvZXMgbm90IGNob29zZSB0byBzdXBwb3J0IGl0LCBpdCBtYXkgYmUgb2suIFNpbmNlIGl0 IG1heSBiZSBuZWdvdGlhdGVkIGJldHdlZW4gdHdvIENETnMuDQpJZiBkQ0ROIGRvZXMgbm90IHN1 cHBvcnQgdGhhdCwgaXQgbWF5IGJlIHRoZSB1Q0ROIHJlc3BvbnNpYmxlIHRvIGNvbXBsZXRlIHRo ZSB0cmFuc2NvZGluZyBhbmQgZGVsaXZlciB0aGUgY29udGVudCBvZiBtdWx0aXBsZSBmb3JtYXRz IGFuZCByYXRlcyB0byBkQ0ROLg0KVGhpcmQsIGFsdGhvdWdoIENETkkgaXMgYSBuZXcgYXJjaGl0 ZWN0dXJlLCB3aGlsZSB0aGUgY29udGVudCBvcGVyYXRpbmcgaGFzIGJlZW4gZXhpc3RlZCBmb3Ig eWVhcnMuIEFzIEkga25vdyB0aGUgY29udGVudCBmcm9tIFVTQSB0byB0aGUgZG93bnN0cmVhbSBv cGVyYXRvciBpcyB0cmFuc2ZlcnJlZCBvbiBvbmUgY29weSBhbmQgdGhlIGRvd25zdHJlYW0gb3Bl cmF0b3Igd2lsbCBoYW5kbGUgdGhlIHRyYW5zY29kaW5nLg0KDQpQZXJoYXBzLCB0aGUgY29udGVu dCBhZGFwdGF0aW9uIGlzIG1vcmUgb24gdGhlIG1vYmlsZSBvcGVyYXRpbmcuIEJ1dCBJIGZlZWwg Y3VycmVudGx5IG1vc3Qgb3BlcmF0b3Igd2lsbCBiZSBhIGFsbCBzZXJ2aWNlIG9wZXJhdG9yLiBB bmQgZm9yIHRoZSBDRE4gcHJvdmlkZXJzLCBpdCBtYXkgYmUgYmV0dGVyIHRvIHN1cHBvcnQgYWxs IGtpbmRzIG9mIHNlcnZpY2UuDQpCZXNpZGVzLCBJIGxpa2Ugc2F5IHRoYXQgdGhlIHRlY2hub2xv Z3kgb24gdGhpcyB0b3BpYyBoYXMgYmVlbiBmb3IgbWFueSB5ZWFycyBhbmQgaGFzIGJlZW4gcmF0 aGVyIG1hdHVyZSwgZXZlbiBzb21lIGl0ZW1zIGluIGlldGYgc3VjaCBhcyByZmMzNTA3IGljYXAu IFNvIGZyb20gdGhlIHRlY2huaXF1ZSBwb2ludCBvZiB2aWV3LCBpdCBpcyBhIG5hdHVyZSBhY3Rp b24gdG8gYmUgaW52b2x2ZWQgaW4gQ0ROIGludGVyY29ubmVjdGlvbi4NClRoYW5rcy4NClpoaXBl bmcNCg0KDQoNCkZyb206IE1hcmsgZGUgSm9uZyBbbWFpbHRvOm1hcmtAamV0LXN0cmVhbS5ubF0N ClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDExIDQ6MjEgQU0NClRvOiBBbGFuIEthdmFu YWdoDQpDYzogQmVuIE5pdmVuLUplbmtpbnM7IFpob3VaaGlwZW5nOyBjZG5pQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMt MDAudHh0DQoNCkhpIEFsYW4sDQoNCkFzIEJlbiBzdGF0ZWQgdGhlIG92ZXJhbGwgZGlzY3Vzc2lv biByaWdodCBub3cgaXMgYWJvdXQgZGVsaXZlcnksIG5vdCBvbiBhZGFwdGF0aW9uLiBJdCBpcyBo YXJkIGVub3VnaCB0byBnZXQgY29uc2Vuc3VzIG9uIHRoZSBkZWxpdmVyeSBhc3BlY3QgYWxyZWFk eSBub3QgdG8gbWVudGlvbiB5b3VyIHJlcXVpcmVtZW50IGZyb20gY29udGVudCBhZGFwdGF0aW9u IGFkZGVkIHRvIHRoYXQsIHNvIEkgYWdyZWUgd2l0aCBCZW4gd2Ugc2hvdWxkIHN0aWNrIHdpdGgg dGhlIGRlbGl2ZXJ5IGFzcGVjdCBmb3IgdGhlIGZpcnN0IHNwZWNzLiBJIGNhbiBpbWFnaW5lIHRo aXMgY291bGQgYmUgYSBkaXNjdXNzaW9uIGxhdGVyIG9uIGJ1dCBwbGVhc2UgbGV0IHVzIGtlZXAg dGhlIHNjb3BlIG9mIHRoaXMgYmUgY2xlYW4gYW5kIHRyYW5zcGFyZW50LiBJdCBpcyBvZiBiZW5l Zml0IG9mIGV2ZXJ5b25lIHRvIGdldCB0aGUgZmlyc3Qgc3BlY3MgYXMgZmFzdCBhcyBwb3NzaWJs ZS4gVGhhbmtzLg0KDQpNZXQgdnJpZW5kZWxpamtlIGdyb2V0LA0KS2luZCByZWdhcmRzLA0KDQpN YXJrIGRlIEpvbmcNCkludGVybmF0aW9uYWwgQnVzaW5lc3MgRGV2ZWxvcGVyDQpKZXQtU3RyZWFt IEJWDQoNCkUtbWFpbDogbWFya0BqZXQtc3RyZWFtLmNvbTxtYWlsdG86bWFya0BqZXQtc3RyZWFt LmNvbT4NCk9mZmljZTogKzMxICgwKTUwIDUyNjE4MjANCk1vYmlsZTogKzMxICgwKTYgODExMDgy NjMNCkZheDogKzMxICgwKTUwIDUyNjQyMTQNCg0KLSBFdmVudDogTWVldCB1cyBhdCBTdHJlYW1p bmcgTWVkaWEgRXVyb3BlLCAxNy0xOCBPY3RvYmVyLCBMb25kb24sIFVLDQotIEV2ZW50OiBNZWV0 IHVzIGF0IE9ubGluZSBWaWRlbyBTdHJhdGVnaWVzLCAxOSBPY3RvYmVyLCBMb25kb24sIFVLDQot IEV2ZW50OiBNZWV0IHVzIGF0IENETiBXb3JsZCBTdW1taXQsIDI1LTI4IE9jdG9iZXIsIExvbmRv biwgVUsNCi0gTmV3czogUHJlLXJlcXVlc3QgeW91ciBUZWNobm9sb2d5IFdoaXRlcGFwZXIgbm93 IGFuZCBiZSB0aGUgZmlyc3QgdG8gaGF2ZSBpdCwgY2hlY2sgd3d3LmpldC1zdHJlYW0uY29tPGh0 dHA6Ly93d3cuamV0LXN0cmVhbS5jb20+DQotIE5ld3M6IENoZWNrIGh0dHA6Ly93d3cuamV0LXN0 cmVhbS5jb20gdG8gZG93bmxvYWQgb3VyICdTaXggVHJlbmRzIGluIENETnMnIGJyb2NodXJlDQoN Ci0gQmxvZzogd3d3LmpldC1zdHJlYW0uY29tL2Jsb2cvPGh0dHA6Ly93d3cuamV0LXN0cmVhbS5j b20vYmxvZy8+DQotIFZpZGVvRXhjaGFuZ2U6IHd3dy52ZG8teC5uZXQ8aHR0cDovL3d3dy52ZG8t eC5uZXQ+DQotIFN0cmVhbXppbGxhOiB3d3cuc3RyZWFtemlsbGFjZG4uY29tPGh0dHA6Ly93d3cu c3RyZWFtemlsbGFjZG4uY29tPg0KLSBDb3Jwb3JhdGU6IHd3dy5qZXQtc3RyZWFtLmNvbTxodHRw Oi8vd3d3LmpldC1zdHJlYW0uY29tPg0KDQpPbiAyNiwgT2N0LDIwMTEsIGF0IDg6MzMgUE0sIEFs YW4gS2F2YW5hZ2ggd3JvdGU6DQoNCg0KQmVuDQoNCkltIGFzc3VtaW5nIHRoZW4gYmFzZWQgb24g eW91ciBjb21tZW50cyBiZWxvdyBhcmUgeW91IHN1Z2dlc3Rpbmcgd2UgYXJlIGdvaW5nIHRvIGhh dmUgYSBudW1iZXIgb2YgdmVyc2lvbnMgb2YgdGhlIENETi1JIE1ldGFkYXRhPw0KDQpJIHN5bXBh dGhpc2Ugd2l0aCB3aGF0IHlvdSBhcmUgcG9pbnRpbmcgb3V0IGJlbG93IGFuZCBkbyBhZ3JlZSB0 aGF0IHRoZXJlIGlzIHNvbWUgd29yayB0byBiZSBkb25lLCBidXQgSSBzdGlsbCBmZWVsIHRoYXQg Y29udGVudCBhZGFwdGF0aW9uIGlzIHRvIG1lIGEgZnVuZGFtZW50YWwgcmVxdWlyZW1lbnQgdG8g d2hhdCBjb2xsZWN0aXZlbHkgd2Ugc2hvdWxkIGFkZHJlc3MgaW4gdGhlIENETi1JIFdHLiBJIGRv IGFncmVlIHdpdGggeW91IHRoYXQgY29udGVudCBhZGFwdGF0aW9uIGlzIGFuIG9wdGltaXphdGlv biBiZXR3ZWVuIENETidzIGJ1dCBpdCdzIGEgdmVyeSBpbXBvcnRhbnQgb25lIHRoYXQgSSBrbm93 IE5ldHdvcmsgU2VydmljZSBQcm92aWRlcnMgcGFydGljdWxhcmx5IHJlcXVpcmUuDQoNCkFsYW4N Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNkbmktYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJlbiBOaXZlbi1KZW5raW5zDQpTZW50OiBPY3RvYmVyLTEyLTEx IDE6MTMgUE0NClRvOiBaaG91WmhpcGVuZw0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Ru aS11c2UtY2FzZXMtMDAudHh0DQoNClpoaXBlbmcsDQoNCk9uIDEyIE9jdCAyMDExLCBhdCAxMDoy MiwgWmhvdVpoaXBlbmcgd3JvdGU6DQoNCg0KSGVsbG8gQmVuLA0KVGhlIFVFIG1heSBzZWxlY3Qg dGhlIGNvbnRlbnQgZm9ybWF0IG9uIHRoZSBDUCB3ZWIuIEFmdGVyIHRoYXQgdGhlIHVzZXIgb25s eSBkZXNpcmVzIHRvIGdldCBoaXMgc2VsZWN0ZWQgY29udGVudC4NCkJ1dCBob3cgdGhlIGNvbnRl bnQgaXMgdHJhbnNmZXJyZWQgdG8gdGhlIGNsaWVudCBpcyBub3Qgd29ycmllZCBieSB0aGUgdXNl ci4NClRoZSBDUCBtYXkgY3JlYXRlIGEgc3BlY2lhbCBmb3JtYXQgYXMgcmVxdWlyZWQgYnkgdGhl IHVzZXIgYW5kIGFzayB0aGUgQ0ROIHRvIGRlbGl2ZXIgdG8gdXNlci4NCldoaWxlIENQIG1heSBn aXZlIGEgSEQgZm9ybWF0IGNvbnRlbnQgdG8gdUNETiBhbmQgdGhlIGRDRE4gbWF5IHRoZW4gdHJh bnNmb3JtIHRvIHRoZSBmb3JtYXQgYXMgdGhlIHVzZXIgc2VsZWN0Lg0KDQpMb3RzIG9mIHRoaW5n cyBtYXkgYmUgcG9zc2libGUgdG8gZG8gYW5kIENETiBwcm92aWRlcnMgb2ZmZXIgbWFueSBhZGRp dGlvbmFsIHNlcnZpY2VzIG9uIHRvcCBvZiB0aGUgImNvcmUiIHNlcnZpY2Ugb2YgY29udGVudCBk ZWxpdmVyeS4gSG93ZXZlciwgb3VyIG9iamVjdGl2ZSAoYmFzZWQgb24gbXkgaW50ZXJwcmV0YXRp b24gb2YgdGhlIENETkkgY2hhcnRlcikgaXMgdG8gZm9jdXMgb24gd2hhdCBpcyBuZWNlc3Nhcnkg dG8gaW50ZXJjb25uZWN0IENETnMgdG8gZGVsaXZlciBjb250ZW50IGZyb20gYSBDU1AgdG8gYW4g RW5kIFVzZXIgdGhhdCBpcyB0YXJnZXRlZCBhbmQgZGVwbG95YWJsZSB3aXRoaW4gYSBzaG9ydCB0 aW1lIGZyYW1lICgxOC0yNCBtb250aHMpLg0KDQpDb250ZW50IHRyYW5zZm9ybWF0aW9uL2FkYXB0 YXRpb24gaXMgbm90IGFuIGVzc2VudGlhbCByZXF1aXJlbWVudCBpbiBvcmRlciB0byBhY2hpZXZl IHRoYXQgYWltICh3ZSBjYW4gZGVsaXZlciBjb250ZW50IGZyb20gQ1NQcyB0byBFbmQgVXNlcnMg dmlhIG11bHRpcGxlIENETnMgd2l0aG91dCBuZWVkaW5nIG9yIHJlcXVpcmluZyBhbnkgQ0ROIHN1 cHBvcnRzIGNvbnRlbnQgYWRhcHRhdGlvbikuDQoNCkluIG15IG9waW5pb24gd2UgaGF2ZSBlbm91 Z2ggd29yayB0byBkbyBhbHJlYWR5IHdpdGhvdXQgdHJ5aW5nIHRvIGV4cGFuZCB0aGUgc2NvcGUg b2Ygb3VyIHdvcmsgdG8gaW5jbHVkZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB0aGF0IGRvIG5v dCBoZWxwIHVzIGFkZHJlc3Mgb3VyIGNvcmUgb2JqZWN0aXZlcyBhcyBsYWlkIG91dCBpbiB0aGUg Q0ROSSBjaGFydGVyLg0KDQoNCkluIHRoaXMgY2FzZSwgaXQgaXMgbm90aGluZyByZWxhdGVkIHRv IGhvdyB0aGUgdXNlciBzZWxlY3QgZm9ybWF0cyBvbiBDUCB3ZWJzaXRlLg0KU28sIGl0IGlzIHRo ZSBDUCBhbmQgdXNlciB0byBkZWNpZGUgdGhlIGNvbnRlbnQgZm9ybWF0IG5vdCB0aGUgQ0ROKHlv dXIgYXNzZXJ0IGlzIG5vdCBjb3JyZWN0IGFuZCBzZWVtcyB5b3UgdGFrZSB0aGF0IGFzc2VydCBh cyB5b3VyIGJhc2UgZm9yIHRoZSBkaXNjdXNzaW9uKS4NCg0KQXMgZm9yICJ0aGUgY29yZSBDRE4g ZnVuY3Rpb25hbGl0eSBvZmZlcmVkIGJ5IENETnMgdG9kYXkiLCBJIGhhdmUgZXZlciByYWlzZWQg YW4gZW1haWwgYmVmb3JlIHRoYXQgeW91ciBjb21wYW55J3Mgd2VicGFnZSBoYXMgY2xhaW1lZCBz dXBwb3J0aW5nIG1lZGlhIHRyYW5zZm9ybWF0aW9uIGFuZCBtdWx0aS1zY3JlZW4gc2VydmljZS4N ClBlcmhhcHMsIEkgbGlrZSBhc2tpbmcgeW91IGxpc3Qgc29tZSBmZWF0dXJlcyB0aGF0IHlvdSBm ZWVsIGFyZSB0aGUgY29yZSBmdW5jdGlvbmFsaXRpZXMgYnkgZXhpc3RpbmcgbWFpbiBzdHJlYW0g Q0ROcy4gVGh1cyB3ZSBtYXkgY29tcGFyZSBhbmQgdGFrZSBkZWVwIGxvb2suDQoNCkkgdGhpbmsg dGhlIGNvcmUgZnVuY3Rpb25hbGl0eSBtYXBzIHByZXR0eSB3ZWxsIHRvIHRoZSBDRE5JIGludGVy ZmFjZXMsIG5hbWVseTogUmVxdWVzdCBSb3V0aW5nLCBNZXRhZGF0YSBjb25maWd1cmF0aW9uLCBs b2cgcHJvZHVjdGlvbiBhbmQgY29udHJvbCBwbHVzIGNvbnRlbnQgYWNxdWlzaXRpb24gYW5kIGNv bnRlbnQgZGVsaXZlcnkuDQoNCg0KSSBndWVzcyBtYW55IHBlb3BsZSBoYXZlIHRoZSBleHBlcmll bmNlL2tub3dsZWRnZSBvZiBjb250ZW50IHJlbGF0ZWQgc2VydmljZS4gVGhlIHVzZXIgYW5kIENQ IG9ubHkgY2FyZSB3aGV0aGVyIHRoZSBDRE4gcHJvdmlkZXJzIG1heSBzYXRpc2Z5IHRoZWlyIHJl cXVpcmVtZW50IHdoaWxlIG5vdCBjYXJlIHRoZSBpbnRlcm5hbCBwcm9jZXNzLiBKdXN0IGFzIEdT TS9QU1ROIGludGVyY29ubmVjdGlvbiwgdGhlIHVzZXIgb25seSBjYXJlIHN1Y2Nlc3NmdWwgaW50 ZXJjb25uZWN0aW9uIHdoaWxlIG5vdCBjYXJlIGhvdyB0aGUgdm9pY2UgaXMgdHJhbnNmb3JtZWQg aW4gcHJvY2Vzcy4NCg0KQmVzaWRlcywgSSBsaWtlIHJhaXNlIGEgY2FzZToNCkdpdmVuIGN1cnJl bnRseSBCQkMgcmVjcnVpdHMgQ0ROIHByb3ZpZGVycyB0aGF0IG1heSBzdXBwb3J0IDEwIG1lZGlh IGZvcm1hdHMuDQpPbmUgY2FuZGlkYXRlIGlzIHlvdXIgY29tcGFueSwgYW5vdGhlciBpcyBDRE4t WC4gVGhlIHVzZXJzIGFyZSBsb2NhdGVkIGluIEZyYW5jZS4NClNvIGJvdGggeW91ciBjb21wYW55 IGFuZCBDRE4tWCBzaG91bGQgY29ubmVjdCBhIEZyYW5jZSBDRE4gcHJvdmlkZXIoQ0ROLVkpLg0K SWYgeW91ciBjb21wYW55J3Mgc29sdXRpb24gaXMgdG8gc2VuZCAxMCBzdHJlYW1zIG9mIGRpZmZl cmVudCBmb3JtYXQNCm9mIG9uZSBjb250ZW50IHRvIENETi1ZOyBXaGlsZSBDRE4tWCdzIHNvbHV0 aW9uIGlzIHRvIHNlbmQgMSBzdHJlYW0gdG8gQ0ROLVkgd2hpbGUgQ0ROLVkgbWF5IGNvbmR1Y3Qg c29tZSBhZGFwdGF0aW9uLg0KQ29tcGFyaW5nIHRoZXNlIHR3byBzb2x1dGlvbnMsIGZvciB5b3Vy IGNvbXBhbnkgYW5kIENETi1YLCBhYnNvbHV0ZWx5IHRoZSBjb3N0IG9mIENETi1YIGlzIG11Y2gg bG93ZXIuDQpGb3IgQ0ROLVksIGluIHNvbHV0aW9uLTEsIGl0IHNob3VsZCByZWNlaXZlL2Zvcndh cmQgMTAgc3RyZWFtcyA7IHdoaWxlIGluIHNvbHV0aW9uLTIsIGl0IHNob3VsZCBvbmx5IHJlY2Vp dmUgMSBzdHJlYW0gYnV0IG5lZWQgdG8gdGFrZSB0cmFuc2Zvcm1hdGlvbiB0byBvdXRwdXQgMTAg c3RyZWFtcy4NCg0KV2hpY2ggc29sdXRpb24gaXMgbW9yZSBjb21wZXRpdGl2ZS4gaXQgaXMgU29s dXRpb24gMSwgcmlnaHQuIFJlbWVtYmVyIHRoZSBwcmljZSBmcm9tIEJCQyBpcyBzYW1lIHRvIGJv dGggeW91ciBjb21wYW55IGFuZCBDRE4tWCBvciBCQkMgd291bGQgc2VsZWN0IG9uZSBDRE4gcHJv dmlkZXIgd2l0aCB0aGUgbG93ZXIgcHJpY2UuDQpJZiBhIENETiBwcm92aWRlciBtYXkgbm90IGdl dCB0aGUgY29udHJhY3QgZnJvbSBDUCwgaG93IGl0IG1heSBzYXkgaXQgaXMgbm90IGEgY29yZSBm dW5jdGlvbmFsaXR5Lg0KDQpXaGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyBhIHBvc3NpYmxlIG9w dGltaXphdGlvbiB0aGF0IGEgcGFydGljdWxhciBDRE4gbWF5IHdpc2ggdG8gaW1wbGVtZW50IG5v dCBhIGNvcmUgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCB0byBlbmFibGUgY29udGVudCBkZWxpdmVy eSBiZXR3ZWVuIGludGVyY29ubmVjdGVkIENETnMuIEkgY2FuIHRoaW5rIG9mIG1hbnkgb3B0aW1p emF0aW9ucyB0aGF0IGEgQ0ROIGNvdWxkIGltcGxlbWVudCB0byBkaWZmZXJlbnRpYXRlIHRoZWly IHNlcnZpY2UgYnV0IHRoZSBpbnRlcm5hbCB3b3JraW5ncyBvZiBhbiBpbmRpdmlkdWFsIENETiBh cmUgb3V0IG9mIHNjb3BlIG9mIG91ciBjaGFydGVyLg0KDQpTbyB0byByZXBlYXQgbXkgcG9zaXRp b24gZm9yIGEgZmluYWwgdGltZTogQ29udGVudCBhZGFwdGF0aW9uIGlzIG5vdCBhIGNvcmUgZnVu Y3Rpb24gcmVxdWlyZWQgdG8gZW5hYmxlIGNvbnRlbnQgZGVsaXZlcnkgYmV0d2VlbiBpbnRlcmNv bm5lY3RlZCBDRE5zIGFuZCB0aGVyZWZvcmUgZ2l2ZW4gdGhlIHdvcmtsb2FkIHdlIGFscmVhZHkg aGF2ZSB0byBzcGVjaWZ5IHNvbHV0aW9ucyB0aGF0IGRvIGFkZHJlc3MgdGhlIGNvcmUgZnVuY3Rp b25hbGl0eSByZXF1aXJlZCB0byBpbnRlcmNvbm5lY3QgQ0ROcyBJIGRvIG5vdCB0aGluayB3ZSBz aG91bGQgYmUgdHJ5aW5nIHRvIGFkZCBtb3JlIHdvcmsgaW50byB0aGF0IHdvcmtsb2FkIGFzIGl0 IHdpbGwgb25seSBkaXN0cmFjdCB1cyBmcm9tIGFjaGlldmluZyBvdXIgZ29hbCBvZiBwcm9kdWNp bmcgZGVwbG95YWJsZSBzb2x1dGlvbnMgd2l0aGluIHRoZSB0aW1lZnJhbWUgd2UgYXJlIGJlaW5n IHRvbGQgYnkgb3BlcmF0b3JzIHRoZXkgbmVlZHMgc29sdXRpb25zIHdpdGhpbi4NCg0KQmVuDQoN Cg0KU28sIGlmIHdlIGFsbCByZWFsaXplIHRoYXQgY3VycmVudGx5IHRoZSBtZWRpYSB0eXBlIGlz IHJpY2gsIHRoZSBDRE4gcHJvdmlkZXJzIHNob3VsZCBzdXJ2aXZlIGluIHRoZSBleGlzdGluZyBl Y29zeXN0ZW0gYW5kIHN1cHBvcnQgdGhlIG1lZGlhIHR5cGVzIGFzIHJlcXVpcmVkIGJ5IHRoZSBt YXJrZXQuDQoNCkJhY2sgdG8gdGhlIGNhc2Ugb2YgR1NNL0cuNzExLCBpdCBqdXN0IHdoZW4gY29u Y2VybmluZyB0aGUgaW50ZXJjb25uZWN0aW9uLCB0aGUgdHJhbnNmb3JtYXRpb24gc2hvdWxkIGF0 IG9uY2UgYmUgc29sdmVkLiBPdGhlcndpc2UgdGhlIGludGVyY29ubmVjdGlvbiBtYXkgbm90IGJl IG9wZXJhdGVkLg0KDQpCciwNClpoaXBlbmcNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEJlbiBOaXZlbi1KZW5raW5zIFttYWlsdG86YmVuQG5pdmVuLWplbmtpbnMu Y28udWtdDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIwMTEgMTI6MTkgQU0NClRvOiBa aG91WmhpcGVuZw0KQ2M6IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxtYWlsdG86cGhpbGlwLmVhcmRs ZXlAYnQuY29tPjsgY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQN Cg0KWmhpcGVuZywNCg0KT24gMTEgT2N0IDIwMTEsIGF0IDA1OjE2LCBaaG91WmhpcGVuZyB3cm90 ZToNCg0KQmVuIGFuZCBQaGlsaXAsDQpJIGxpa2UgdG8gcmVzcG9uZCB5b3VyIGNvbmNlcm4gaW4g dGhpcyBvbmUgZW1haWw6DQoNCkJlbiwNCkkgZmVlbCB3aGF0IHdlIGFyZSBub3cgZGlzY3Vzc2lu ZyBpcyB3aGF0IGlzIHRoZSAiY29yZSIgZnVuY3Rpb24gb2YgQ0ROLg0KQXMgeW91IHNheSwgQ0RO IGlzIHVzZWQgdG8gZGVsaXZlciBjb250ZW50LiBUaGF0IGlzIGFic29sdXRlbHkgY29ycmVjdCB0 aGF0IHRoZSBkZWxpdmVyeSBjYXBhYmlsaXR5IGlzIHRoZSBjb3JlIHJlcXVpcmVtZW50IGZvciBD RE4gc3lzdGVtLg0KV2hpbGUgQ0ROIGlzIHVzZWQgdG8gcHJvdmlkZSB0aGUgY29udGVudCBkZWxp dmVyeSBzZXJ2aWNlLg0KV2hhdCBtZWFucyBzZXJ2aWNlLiBJdCBzaG91bGQgaW5jbHVkZSAidGlt ZSIgImxvY2F0aW9uIiBhbmQgIm1lZGlhIHR5cGUiLCBldGMuIFRoZXNlIGZlYXR1cmVzIGFyZSBh bGwgdGhlIGNvcmUgZmVhdHVyZSBmb3IgYSBzZXJ2aWNlLg0KSWYgd2Ugb25seSBjb25jZXJuICJk ZWxpdmVyaW5nIG9uZSBkYXRhIGJsb2NrIiwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSBpc3N1 ZXMgc3VjaCBhcyAibG9nZ2luZyIgImdlb2dyYXBoaWMgY29uc3RyYWludCIgYXJlIHRoZSBjb3Jl IG9mIENETi4NCg0KRm9yICJ3aXRob3V0IGV4cGxpY2l0IGtub3dsZWRnZSBvZiB3aGF0IHRoYXQg Y29udGVudCBhY3R1YWxseSBpcyAiLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIHdvcmRpbmcg aXMgYWNjdXJhdGUgc2luY2UgZ2VuZXJhbGx5IGEgQ0ROIG1heSBjbGFpbSBpdCBzdXBwb3J0IGRp ZmZlcmVudCBtZWRpYXMuDQpCeSB0aGlzIG9wcG9ydHVuaXR5LCBJIGxpa2UgdG8gc2hhcmUgYSB1 c2UgY2FzZTogYSBjYWxsIGZyb20gYSBHU00gcGhvbmUgdG8gYSBQU1ROIHRlbGVwaG9uZSwgdGhl IHZvaWNlIHN0cmVhbSBzaG91bGQgYmUgdHJhbnNmb3JtZWQgZnJvbSBHU00gdm9pY2UgdG8gRy43 MTEuDQpGb3IgdGhlIHVzZXIsIGhlIGRvZXMgbm90IG5lZWQgdG8ga25vdyB3aGF0IHR5cGUgb2Yg ZGF0YSBoYXMgYmVlbiB0cmFuc2ZlcnJlZCwgYnV0IHRoZSBvcGVyYXRvciBoYXMgZG9uZSBzb21l IHdvcmsgdG8gaW50ZXJjb25uZWN0IHR3byBzeXN0ZW1zLCByaWdodC4NCkkgbGlrZSB0byBrbm93 IHdoZXRoZXIgeW91IG1heSBhY2NlcHQgdGhhdCBteSB1c2UgY2FzZSBpcyBzaW1pbGFyIHRvIHRo aXMgY2FzZSBhYm92ZS4NCg0KSSBkb24ndCB0aGluayB5b3VyIHVzZSBjYXNlIGlzIHNpbWlsYXIg dG8gdGhlIGFuYWxvZ3kgb2YgbW9iaWxlIG5ldHdvcmtzIGJlaW5nIGludGVyY29ubmVjdGVkIHRv IFBTVE4gbmV0d29ya3MuIEluIHRoZSBjYXNlIG9mIGNvbnRlbnQgZGVsaXZlcnkgdGhlIG5lZ290 aWF0aW9uIGlzIGRvbmUgYmV0d2VlbiB0aGUgVXNlci9DbGllbnQgYW5kIHRoZSBDb250ZW50IFBy b3ZpZGVyIGFuZCB0aGUgQ0ROIGlzIGp1c3QgdXNlZCB0byBleGVjdXRlL3BlcmZvcm0gdGhlIGRl bGl2ZXJ5IHRoYXQgaGFzIGJlZW4gbmVnb3RpYXRlZC4gVGhlIENETiBpcyBub3QgaW52b2x2ZWQg aW4gdGhlIGRlY2lzaW9uIG1ha2luZyBvZiB3aGF0IHJlcHJlc2VudGF0aW9ucyB0aGUgQ29udGVu dCBQcm92aWRlciBkZWNpZGVzIHRvIG9mZmVyIHRvIHRoZSBVc2VyL0NsaWVudCBvciBpbiB3aGF0 IHJlcHJlc2VudGF0aW9ucyB0aGUgVXNlci9DbGllbnQgZGVjaWRlcyB0byByZXF1ZXN0Lg0KDQpB cyBmb3IgeW91IHNhaWQgc2VsZWN0aW5nIG1lZGlhIGJ5IHRoZSAicG9ydGFsIiwgeW91IG1heSBz ZWUgdGhlIHdheSAiIHVDRE4gZGVsaXZlcnMgbXVsdGlwbGUgbWVkaWEgc3RyZWFtcyB0byBkQ0RO IiBpcyBub3QgZ29vZCB0aGFuICJ1Q0ROIGRlbGl2ZXJzIG9uZSBtZWRpYSBzdHJlYW0gdG8gZENE TiBhbmQgZENETiB0YWtlcyBzb21lIGFkYXB0YXRpb24gdG8gc3VwcG9ydCBtdWx0aXBsZSBtZWRp YSB0eXBlcyIuDQoNCk5vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0IGlzIGFuIG9wdGltaXNh dGlvbiwgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBhY3R1YWxseSBkZWxpdmVyIHRo ZSBjb250ZW50IChhbmQgcmVwb3J0LCBiaWxsLCBldGMuIGZvciB0aGF0IGRlbGl2ZXJ5KS4NCg0K TXkgcG9zaXRpb24gaXMgdGhhdCB3ZSBzaG91bGQgZm9jdXMgb24gaG93IHRvIGVuYWJsZSB0aGUg aW50ZXJjb25uZWN0aW9uIG9mIHRoZSBjb3JlIENETiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkg Q0ROcyB0b2RheSAod2hpY2ggaXMgYWxzbyBteSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgc2NvcGUg b2YgdGhlIENETkkgd29ya2luZyBncm91cCBhcyBleHByZXNzZWQgaW4gaXRzIGNoYXJ0ZXIpIGJl Y2F1c2UgZG9pbmcgc28gaXMgYSBzaWduaWZpY2FudCBwaWVjZSBvZiB3b3JrIGluIGl0c2VsZi4g TGV0J3Mgbm90IHN0YXJ0IHRyeWluZyB0byBhZGQgaW4gYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5 IGJleW9uZCB3aGF0IHRoZSBtYWpvcml0eSBvZiBDRE5zIHN1cHBvcnQgdG9kYXkgYXMgdGhhdCB3 aWxsIGp1c3QgZGVsYXkgdXMgZ2V0dGluZyB1c2FibGUgc3BlY2lmaWNhdGlvbnMgaW50byB0aGUg bWFya2V0IGluIGEgdGltZWx5IGZhc2hpb24gSU1PLg0KDQpCZW4NCg0KQSBnb29kIHF1ZXN0aW9u IGlzICJzZWN1cml0eSIgc2luY2UgSSBoYXZlIGRvbmUgc2l4IHllYXJzIG9uIHRoZSBEUk0NCmFu ZCBsaWtlIHRvIHByb21vdGUgdGhlIERSTSBhbGwgYXJvdW5kIHRoZSB3b3JsZDopIElmIHRoZSBj b250ZW50IGlzIG5lZWRlZCB0byBiZSBwcm90ZWN0ZWQsIGdlbmVyYWxseSB5b3UgbWF5IGtub3cg YWxsIHRoZSBzeXN0ZW1zIHNob3VsZCBiZSBncmFudGVkIGJ5IHRoZSBjb250ZW50IG93bmVyLg0K SGVyZSBJIGFsc28gbGlrZSB0byBjbGFyaWZ5IHRoYXQgbm90IG9ubHkgdGhlIG1lZGlhIGl0c2Vs ZiBidXQgdGhlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gc2VydmljZSBpdHNlbGYgKHN1Y2ggYXMg dGhlIGdlb2dyYXBoaWMgY29uc3RyYWludCkgc2hvdWxkIGJlIHByb3RlY3RlZCBhbHNvLg0KU28s IHRydXN0IGlzIG5vdCBhIHByb2JsZW0gZm9yIHRoZSBtZWRpYS4NCg0KUGhpbGlwLA0KVGhhbmsg eW91IHRoYXQgeW91IGZlZWwgQ29udGVudCBBZGFwdGlvbiBpcyBhbiBpc3N1ZSBmb3IgIlJlcXVp cmVtZW50cyIgYnV0IEkgZG8gbm90IGtub3cgd2h5IGl0IGlzIG5vdCBmb3IgVXNlIGNhc2UuDQpJ IGxpa2UgdG8gY2xhcmlmeSB0byBVIHRoYXQgaXQgaXMgaW1wb3J0YW50IGZvciB5b3Ugb3BlcmF0 b3Igc2luY2UgaXQgbWF5IHNhdmUgaW52ZXN0bWVudCBpZiB0aGUgc3lzdGVtIG1heSBzdXBwb3J0 IGRpZmZlcmVudCBzZXJ2aWNlcy4NCkZvciB1cyB2ZW5kb3IsIHdlIGFyZSBoYXBweSBvcGVyYXRv ciBtYXkgaW5zdGFsbCBhIHN5c3RlbSBmb3IgdGhlIG1vYmlsZSBzZXJ2aWNlIGFuZCBhbm90aGVy IHN5c3RlbSBmb3IgdGhlIEZCQiBzZXJ2aWNlLg0KQnV0IHRoZSByZWFsaXR5IGlzIGFsbCBvcGVy YXRvcnMgYXNrIHVzIHRvIHByb3ZpZGUgYSBzeXN0ZW0gdGhhdCBtYXkgc3VwcG9ydCBkaWZmZXJl bnQgc2VydmljZSBzeXN0ZW1zLg0KDQpGcmFua2x5LCBCZW4gYW5kIFBoaWxpcCwgSSByZW1lbWJl ciBJIGhhdmUgZXhwbGFpbmVkIHNvbWV3aGVyZSB0aGF0IHRvIGltcGxlbWVudCB0aGlzIGlzIHJh dGhlciBzaW1wbGUgLg0KQXQgbGVhc3QgdGhlIFVzZSBjYXNlIGFuZCBSZXF1aXJlbWVudCBhcmUg aW5mb3JtYXRpb25hbCB0byBiZSByZWZlcnJlZCBpbiBmdXR1cmUgd29yay4gU28gSSBkbyByZWFs bHkgZmVlbCB5b3UgbWF5IGFjY2VwdCBpdC4NCk9mIGNvdXJzZSBJIGxpa2UgdG8gcmVzcG9uZCB5 b3VyIG1vcmUgY29uY2VybiBhbmQgY29tbWVudHMuDQpUaGFua3MuDQpaaGlwZW5nDQoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGhpbGlwLmVhcmRsZXlAYnQuY29tPG1h aWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20+IFttYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29t XQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDEwLCAyMDExIDExOjIyIFBNDQpUbzogYmVuQG5pdmVu LWplbmtpbnMuY28udWs8bWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPjsgWmhvdVpoaXBl bmcNCkNjOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0KU3ViamVjdDogUkU6 IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQpC ZW4sIFpoaXBlbmcsIGFsbCwNCg0KSSB0aGluayB0aGF0IENvbnRlbnQgQWRhcHRhdGlvbiBpcyBt b3JlIGFuIGlzc3VlIGZvciB0aGUgUmVxdWlyZW1lbnRzIGRvYyB0aGFuIGZvciB0aGUgVXNlIGNh c2VzIGRyYWZ0Lg0KDQpUaGUga2V5IHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ugd2FudCB0aGUgQ0RO SSBpbnRlcmZhY2VzIHRvIGJlIGFibGUgdG8gY29wZSB3aXRoIGEgc2NlbmFyaW8gd2hlcmUgKHNh eSkgSEQvU0QgY29udmVyc2lvbiBpcyBkb25lIGluIHRoZSBkQ0ROICYgdG8gc2lnbmFsIGFib3V0 IHRoaXMuDQoNCkkgdGhpbmsgdGhhdCBjb3Bpbmcgd2l0aCB0aGlzIHNjZW5hcmlvIGlzIGEgc2Vj b25kIG9yZGVyIHJlcXVpcmVtZW50LCBpZSB3ZSBzaG91bGQgbm90IHdvcnJ5IGFib3V0IGl0IGlu IHRoZSBpbml0aWFsIHN0YW5kYXJkcy10cmFjayB3b3JrLiBJIGRvbid0IGtub3csIGRpZCB3ZSBl dmVyIGRlY2lkZSB3aGV0aGVyIHRoZSBVc2UgY2FzZXMgZG9jIGlzIHJlc3RyaWN0ZWQgdG8gImlu aXRpYWwiIHNjZW5hcmlvcywgb3Igd2hldGhlciBpdCdzIGFsbC1lbmNvbXBhc3NpbmcsIGllIGNv dmVyaW5nICJmdXR1cmUiIHNjZW5hcmlvcyBhcyB3ZWxsPw0KDQpTY290dCwNClJlYWRpbmcgc29t ZSBvZiB5b3VyIGV4YW1wbGVzLCB0aGV5IHNlZW0gdG8gYmUgdmFsaWQgZXZlbiBpZiBjb250ZW50 IGFkYXB0YXRpb24gKEhEL1NEKSBpcyBvdXQgb2Ygc2NvcGUuDQotIGEgZENETiBtaWdodCBmb3Ig c29tZSByZWFzb24gYmUgdW53aWxsaW5nIHRvIGRpc3RyaWJ1dGUgSEQ/DQotIGEgQ1NQIG1pZ2h0 IHdhbnQgdG8gbWFrZSBzdXJlIHRoZSBkQ0ROIGNhbiB1c2UgSExTIGVuY2Fwc3VsYXRpb24/DQpC dXQgdGhlc2Ugc29ydHMgb2YgZXhhbXBsZXMgc2VlbSB0byBiZSBzdGF0aWMgcG9saWN5IHRoaW5n cyAodG8gZG8NCndpdGggdGhlIGNhcGFiaWxpdGllcyAmIHByZWZlcmVuY2VzIG9mIHRoZSBDRE5z ICYgQ1NQKSwgcmF0aGVyIHRoYW4NCm1ldGFkYXRhIGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRpY3Vs YXIgcGllY2Ugb2YgY29udGVudC4gSW4gdGhlDQpkaXNjdXNzaW9uIHNvIGZhciwgSSB0aGluayBu ZWdvdGlhdGlvbiBhYm91dCBzdGF0aWMgcG9saWN5IHN0dWZmIGlzDQpyYXRoZXIgb3V0IG9mIHNj b3BlKD8pDQoNCk9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbiBpbnRlcmVzdGluZyBxdWVz dGlvbiBpcyB3aGV0aGVyIHRydXN0IGlzIHRyYW5zaXRpdmUuIERvbid0IHRoaW5rIGl0IG5lZWQg YmUgLSBqdXN0IGJlY2F1c2UgQ1NQIHRydXN0cyB1Q0ROLCBhbmQgdUNETiB0cnVzdHMgZENETiBk b2Vzbid0IG1lYW4gdGhhdCB0aGUgQ1NQIGF1dG9tYXRpY2FsbHkgdHJ1c3RzIHRoZSBkQ0ROLiBI b3dldmVyLCBpIHN1c3BlY3QgdGhpcyBjYW4gZ2V0IGFyYml0cmFyaWx5IGNvbXBsZXggLSBzbyBv bmUgcG9zc2liaWxpdHkgaXMgdG8gc2F5IHRoYXQgd2Ugd2lsbCBvbmx5IGhhbmRsZSBjYXNlcyB3 aGVyZSB0aGUgdHJ1c3QgaXMgdHJhbnNpdGl2ZS4NCg0KQmVzdCB3aXNoZXMNCnBoaWwNCg0KDQpQ aGlsaXAgRWFyZGxleQ0KUmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgU3RyYXRlZ3kNCg0KVGhpcyBl bWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3Ig Y29uZmlkZW50aWFsLiBJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVu dGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91J3JlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBu b3RlIHRoYXQgZGlzY2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5nIG9yIHVzaW5nIHRoaXMg aW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVseSBvbiB0aGUgZW1haWwgYWRk cmVzcyBhYm92ZS4gVGhhbmsgeW91LiBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBt YXkgcmVjb3JkIHlvdXIgZW1haWxzLg0KQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQpS ZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKIFJlZ2lz dGVyZWQgaW4NCkVuZ2xhbmQgbm86IDE4MDAwMDANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogY2RuaS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjZG5pLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCk9mIEJlbiBO aXZlbi1KZW5raW5zDQpTZW50OiAxMCBPY3RvYmVyIDIwMTEgMTI6MDQNClRvOiBaaG91WmhpcGVu Zw0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0DQoNCkNv bGxlYWd1ZXMsDQoNCklNTyBTZWN0aW9uIDUuMS4zIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhl IFVzZSBDYXNlcyBkcmFmdC4gQ29udGVudCBBZGFwdGF0aW9uIChpLmUuIHRha2luZyBpbiBhIGNv bnRlbnQgaXRlbSBpbiBvbmUgZm9ybWF0IGFuZCB0cmFuc2Zvcm1pbmcgaXQgdG8gYW5vdGhlciBm b3JtYXQgb3IgcmVwcmVzZW50YXRpb24pIGlzIG5vdCBhICJjb3JlIiBmdW5jdGlvbiBvZiBhIENE TiB3aGljaCB0eXBpY2FsbHkgZGVsaXZlcnMgdGhlIGNvbnRlbnQgdGhhdCBpcyByZXF1ZXN0ZWQg d2l0aG91dCBleHBsaWNpdCBrbm93bGVkZ2Ugb2Ygd2hhdCB0aGF0IGNvbnRlbnQgYWN0dWFsbHkg aXMuDQoNCkxldCdzIG5vdCBmb3JnZXQgdGhhdCBpbiBidWlsZGluZyBhbiBlbmQgdG8gZW5kIGNv bnRlbnQgc2VydmljZSB0aGUgQ0ROIGlzIG9ubHkgb25lIGNvbXBvbmVudCBhbmQgaXMgdGhlIGNv bXBvbmVudCB0YXNrZWQgd2l0aCBleGVjdXRpbmcgdGhlIGRlbGl2ZXJ5IG9mIGEgc3BlY2lmaWMg cmVwcmVzZW50YXRpb24gKHZlcnNpb24vY29weS9mb3JtYXQgZXRjLikgb2YgdGhlIHNlbGVjdGVk IGNvbnRlbnQgbm90IHRoZSBjb21wb25lbnQgdGFza2VkIHdpdGggZGVjaWRpbmcgKG9yIGFwcGx5 aW5nIHBvbGljeSkgb24gd2hpY2ggdmVyc2lvbi9jb3B5L3JlcHJlc2VudGF0aW9uIG9mIGNvbnRl bnQgc2hvdWxkIGJlIGRlbGl2ZXJlZC4NCg0KVGhlIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHZlcnNp b24vY29weS9yZXByZXNlbnRhdGlvbiB0byBvZmZlciBhbmQgYWxsb3cgdG8gYmUgZGVsaXZlcmVk IHRvIGEgZ2l2ZW4gZGV2aWNlL3VzZXIgaXMgaW1wbGVtZW50ZWQgb3V0c2lkZSBvZiB0aGUgQ0RO IChlLmcuIGJ5IHRoZSAicG9ydGFsIiB3aGVyZSB0aGUgdXNlciBmaXJzdCBtYWtlcyB0aGVpciBj b250ZW50IHNlbGVjdGlvbiBwcmlvciB0byB0aGUgQ0ROIGJlY29taW5nIGludm9sdmVkIGluIHRo ZSBkZWxpdmVyeSBvZiB0aGUgc2VsZWN0ZWQgY29udGVudCkuDQoNCkJlbg0KDQpPbiA4IE9jdCAy MDExLCBhdCAwODoyMCwgWmhvdVpoaXBlbmcgd3JvdGU6DQoNCkZvbGxvd2luZyBTY290dCdzIGNv bW1lbnRzIG9uIHNlY3Rpb24gNS4xLjMsIEkgZmVlbCBTY290dCdzIGRlc2NyaXB0aW9uIG9uIHRo ZSB1c2UgY2FzZSBvZiBIRCBhbmQgU0QgaXMgbm90IGV4YWN0bHkgY29ycmVjdC4NCklmIG9uZSBt b3ZpZSBoYXMgdHdvIGZvcm1hdHMgb2YgSEQgYW5kIFNELCB0aGVuIHdlIGhhdmUgdHdvIGNvbnRl bnQgd2l0aCBkaWZmZXJlbnQgaWRlbnRpZmllci4gSW4gRFJNIHNjb3BlLCB0aGUgYmFzaWMgdW5p dCBpcyBhIGNvbnRlbnQgY29weS4NCg0KSGVyZSB0aGUgZmlyc3QgYnVsbGV0ICJhIHN1YnNldCBv ZiBlbmNvZGluZ3MgZGVsaXZlcmFibGUgdG8gc3BlY2lmaWMgZGV2aWNlcywiIGhhcyBsaXN0ZWQg dGhlIGNhc2Ugb2YgY29udGVudCBhZGFwdGF0aW9uLg0KSW4gbGFzdCBtb250aCwgSSBoYXZlIGNv bnRhY3RlZCB0aGUgQXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50IGFuZCB0YWtlbiBzb21lIGVtYWls IGV4Y2hhbmdlcyB3aXRoIEdyYW50IGFuZCBQaGlsaXAgKEJUKS4NCkkgaGF2ZSBzaG93biBCVCB3 aXRoIHNvbWUgaW5mb3JtYXRpb24gdGhhdCBJIGtub3cgaW4gdGhpcyBjYXNlIGFuZCBhcmVhIHRv IGV4cGxhaW4gdGhlIGNvbnRlbnQgZmxleGliaWxpdHkgaXMgY3VycmVudGx5IGEgYmFzaWMgcmVx dWlyZW1lbnQgZm9yIENETiBzZXJ2aWNlIGFuZCByZWxhdGVkIG5lZ290aWF0aW9uIGlzIG5lZWRl ZCBpbiB0aGUgQ0ROIGludGVyY29ubmVjdGlvbi4NCk1lYW53aGlsZSwgSSBzaG91bGQgYWxzbyBp bnZpdGUgeW91IGluIHRoaXMgZ3JvdXAgcmFpc2luZyB5b3VyIGNvbW1lbnRzIG9yIHF1ZXN0aW9u cyBvbiB0aGlzIGNhc2Ugc2luY2UgSSBob3BlIG15IHVzZSBjYXNlIG1heSBiZSBpbmNvcnBvcmF0 ZWQgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0Lg0KDQpJZiB5b3UgaGF2ZSBhbnkgbW9yZSBxdWVzdGlv biBvciBjb21tZW50cywgcGxzIHNoYXJlIGluIHRoaXMgdGhyZWFkLg0KVGhhbmtzLg0KWmhpcGVu Zw0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNjb3R0IFdh aW5uZXIgW21haWx0bzpzd2Fpbm5lckBjaXNjby5jb21dDQpTZW50OiBGcmlkYXksIFNlcHRlbWJl ciAzMCwgMjAxMSA4OjAyIEFNDQpUbzogY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1j YXNlcy0wMC50eHQNCg0KU2VjdGlvbiAyLjMgTm9tYWRpYyBVc2Vycw0KVGhpcyBkZXNjcmlwdGlv biBmYWxscyB1bmRlciB0aGUgY2F0ZWdvcnkgb2YgR2VvZ3JhcGhpYyBFeHRlbnNpb24NCnlldCB0 aGUgdGhpcmQgcGFyYWdyYXBoIHN0YXRlcyB0aGUgY2FzZSB3aGVyZSBhIGRpZmZlcmVudCBkZXZp Y2UgaXMNCnVzZWQgaW4gdGhlIHNhbWUgQ0ROIGNvdmVyYWdlIGFyZWEuICBUaGUgaW50ZW50IG9m IHRoaXMgdXNlIGNhc2UNCm5lZWRzIHRvIGJlIGNsYXJpZmllZC4gIFBlcmhhcHMgdGhlIHVzZSBj YXNlIGlzIHRyeWluZyB0byBhZGRyZXNzDQp0aGUgc2NlbmFyaW8gd2hlcmUgYSBOb21hZGljIFVz ZXItQSB3aXRoIGFuIGFncmVlbWVudCBhbGxvd2luZw0KYWNjZXNzIHRvIGNvbnRlbnQgZnJvbSBD U1AtQSB2aWEgdUNETiBtb3ZlcyB0byBhIGRDRE4gaW4gYSBkaWZmZXJlbnQNCnJlZ2lvbi4gIFRo ZSBkQ0ROIGlzIGFsbG93ZWQgdG8gZGlzdHJpYnV0ZSB0aGUgY29udGVudCBvZiBDU1AtQSB0bw0K VXNlci1BOyBob3dldmVyLCBub3Qgb3RoZXIgdXNlcnMgaW4gdGhlIHJlZ2lvbiBvZiB0aGUgZENE TiBhcmUNCmFsbG93ZWQgdG8gcmV0cmlldmUgdGhlIGNvbnRlbnQgdW5sZXNzIHRoZXkgdG9vIGhh dmUgc3VjaCBhbiBhZ3JlZW1lbnQuDQoNClNlY3Rpb24gNS4xLjMgQ29udGVudCBFbmNvZGluZyBS ZXN0cmljdGlvbnMgTmVlZCB0byBjbGFyaWZ5IGlmIHdlJ3JlDQp0YWxraW5nIGFib3V0IHRoZSBy ZXN0cmljdGlvbnMgb24gdGhlIGRlbGl2ZXJ5IG9mIHNwZWNpZmljIGNvbnRlbnQNCm9yIHRoZSBy ZXN0cmljdGlvbnMgb24gdGhlIGFiaWxpdHkgb2YgYSBDRE4gdG8gZGVsaXZlciBzcGVjaWZpYw0K Y29udGVudC4gIEkgY2VydGFpbmx5IHVuZGVyc3RhbmQgdGhlIGNhc2Ugd2hlcmUgYSBDU1Agd2ls bCByZXN0cmljdA0KdGhlIGRpc3RyaWJ1dGlvbiBvZiBjb250ZW50IHRvIGEgIm1hbmFnZWQgcGF0 aCIgaWYgc3VjaCBjb250ZW50IGlzDQpIRCB3aGlsZSBhbGxvd2luZyB0aGUgY29udGVudCBkaXN0 cmlidXRpb24gdmlhIGFuIHVuLW1hbmFnZWQgcGF0aCBpZg0Kc3VjaCBjb250ZW50IGlzIFNEIChz YW1lIGNvdWxkIGFwcGx5IHRvIGVuY3J5cHRpb24gbWV0aG9kcywgZGVsaXZlcnkNCm1ldGhvZHMs IGV0Yy4pLiAgT24gdGhlIGNvbnRyYXJ5LCB0aGUgZENETiBtYXkgaGF2ZSBpdHMgb3duDQpyZXN0 cmljdGlvbnMgb2YgYmxvY2tpbmcgdGhlIGRpc3RyaWJ1dGlvbiBvZiBIRCBjb250ZW50IHdoaWxl DQphbGxvd2luZyB0aGUgZGlzdHJpYnV0aW9uIG9mIFNEIGNvbnRlbnQuDQoNCm8gZmlyc3QgYnVs bGV0IG1ha2VzIHNlbnNlIGlmIHRoZSBkQ0ROIGNhbiBwZXJmb3JtIGEgc3Vic2V0IG9mDQplbmNh cHN1bGF0aW9ucyBmb3IgYSByZWZlcmVuY2Ugc2V0IG9mIG1lZGlhIChlLmcuIEhMUywgSFNTLCBi dXQgbm90DQpEQVNIKSBvIHNlY29uZCBidWxsZXQgbWFrZXMgc2Vuc2Ugd2hlcmUgdGhlIGRDRE4g ZG9lc24ndCB3YW50IHRvDQpvZmZlciBoaWdoIGJpdC1yYXRlIHZhcmlhbnRzIG9mIHRoZSBtZWRp YSBvIHRoaXJkIGJ1bGxldCBtYWtlIHNlbnNlDQppZiB0aGUgcG9saWN5IGFkZHJlc3NlcyBRb0Ug YnV0IEkgZG9uJ3QgdGhpbmsgc3Vic2NyaWJlcg0KcmlnaHRzL2F1dGhvcml6YXRpb25zIGFwcGx5 Lg0KDQpTZWN0aW9uIDEwIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCkFzaWRlIGZyb20gdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIFdJVEhJTiB0aGUgdUNETiBhbmQgZENETiwgSQ0KdGhp bmsgd2UgY2FuIGRlc2NyaWJlIHRoaXMgaW4gZm91ciBjb250ZXh0czoNCg0KYS4gVGhlIHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIHRoZSBDU1AgYW5kIHRoZSB1Q0ROICh0aGUgcHJpbmNpcGxlIGNvbnRy YWN0DQphcnJhbmdlbWVudCBmb3IgZGlzdHJpYnV0aW9uKQ0KYi4gVGhlIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIHRoZSB1Q0ROIGFuZCBkQ0ROICh0aGUgdHJhbnNpdGl2ZSB0cnVzdA0KcmVsYXRpb25z aGlwIHRoYXQgZXh0ZW5kcyB0aGUgY29udHJhY3QgZGVmaW5lZCBpbiAoYSkgYWJvdmUpIGMuIFRo ZQ0KcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIFVzZXIgYW5kIGRDRE4gKHRoZSByZWNvZ25pdGlv biBvZiByaWdodCB0bw0KZG93bmxvYWQgcHJlZGljYXRlZCBvbiAoYikgYWJvdmUpIGQuIFRoZSBy ZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUNClVzZXIgYW5kIENTUCAodGhlIGNvbnRyYWN0IGF1dGhv cml6aW5nIHRoZSB1c2VyIGFjY2VzcyB0byB0aGUNCmNvbnRlbnQpDQoNClRoZSB1c2VyIGlzIG5v dCBpbnRlcmVzdGVkIGluIHRoZSBhLWIgbm9yIHRoZSBiLWMgcmVsYXRpb25zaGlwLiBUaGUNCnVz ZXIgaXMgb25seSBpbnRlcmVzdGVkIGluIHRoZSB0cmFuc3BhcmVuY3kgYW5kIGludGVyb3BlcmFi aWxpdHkgb2YNCnRoZSBzZWN1cml0eSByZWxhdGlvbnNoaXAgYmV0d2VlbiBkLWIgb3IgZC1jIHRv IHRoZSBwb2ludCB0aGF0IHRoZQ0KYXV0aG9yaXphdGlvbiBncmFudGVkIGluIGQtYSBpcyB2aWFi bGUgd2hlbiB0aGUgZGVsaXZlcnkgaXMNCmluaXRpYXRlZCB2aWEgZWl0aGVyIGQtYiBvciBkLWMu ICBBcyBhbiBleGFtcGxlLCB0aGUgdUNETiBtaWdodCB1c2UNClVSTCBhcHBlbmRlZCB0b2tlbnMg Zm9yIGF1dGhlbnRpY2F0aW9uIHdoaWxlIGRDRE4gbWlnaHQgdXNlIFVSTA0KYXBwZW5kZWQgaGFz aGVzLiAgVGhlIHVzZXIgZG9lc24ndCB3YW50IHRvIGtub3cgYWJvdXQgdGhlIGRpc3RpbmN0DQpt ZXRob2RzLCBidXQgdHJhbnNwYXJlbmN5IGlzIG9ubHkgYWZmb3JkZWQgaWYgdGhlIG1ldGhvZHMg YXJlDQppbnRlcm9wZXJhYmxlIGNsZWFybHkgZGVmaW5lZCB3aGVuIHRoZSBkZWxlZ2F0aW9uIGZv ciBjb250ZW50DQpkZWxpdmVyeSBpcyBleGVjdXRlZC4gIENsZWFybHksIHRoZSBjaG9pY2Ugb2Yg YXV0aGVudGljYXRpb24gbWV0aG9kIGlzIGRldGVybWluZWQgYnkgdGhlIHJlc3BlY3RpdmUgQ0RO J3MuDQoNClNjb3R0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5n IGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5v cmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NkbmkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQo= --_000_1CA25301D2219F40B3AA37201F0EACD1136C1D7DPACDCEXMB05cabl_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxp bmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1z cGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg OTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSI+DQo8Zm9udCBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0O0luIHlvdXIgY29tcGFueeKAmXMg d2Vic2l0ZSwgSSBqdXN0IGZpbmQgc29tZSBpbmZvcm1hdGlvbjxicj4NCjxicj4NCkkgaGF2ZSB0 byBzdGVwIGluIGFzIGNvLWNoYWlyIGhlcmUuPGJyPg0KPGJyPg0KVGhlIGdvYWwgb2YgdGhpcyBX RyBpcyBub3QgdG8gYWxpZ24gdmVuZG9yIHByb2R1Y3Qgcm9hZG1hcHMsIG9yIHRvIGVxdWFsaXpl IGFsbCB2ZW5kb3Igb2ZmZXJpbmdzLCBvciB0byBzcGVjaWZ5IHRoZSBlbnRpcmUgQ0ROSSBlY29z eXN0ZW0uIFRoZSBnb2FsIG9mIHRoaXMgV0cgaXMgdG8gZW5hYmxlIHRoZSBpbnRlcmNvbm5lY3Rp b24gYW5kIGludGVyb3BlcmF0aW9uIG9mIHR3byBvciBtb3JlIENETnMsIHdpdGhpbiB0aGUgYm91 bmRzIG9mIHRoZQ0KIENETkkgd2cgY2hhcnRlci48YnI+DQo8YnI+DQpJdCBpcyBPSyB0byBoYXZl IGEgZGlzY3Vzc2lvbiBhYm91dCB3aGV0aGVyIGNvbnRlbnQgYWRhcHRhdGlvbiBuZWVkcyB0byBi ZSBwZXJmb3JtZWQgYnkgdGhlIGRDRE4sIHNpbmNlIHRoYXQgZGVjaXNpb24gaW1wYWN0cyB0aGUg dUNETi1kQ0ROIGludGVyZmFjZS4gU28gbGV0J3MgZmluZCBhIHByb2R1Y3RpdmUgd2F5IHRvIGRp c2N1c3MgdGhpcyBvbiB0aGUgbWFpbGluZyBsaXN0LCBhbmQgdG8gY2xvc2UgdGhlIGRpc2N1c3Np b24gYnkgSUVURiA4Mg0KIChpZiBub3Qgc29vbmVyKS48YnI+DQo8YnI+DQpDYW4gc29tZW9uZSBk ZXNjcmliZSByZWFsLWxpZmUgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBDRE4gKG9yIGVkZ2Ug Y2FjaGUtYmFzZWQpIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBuZWVkZWQgdG9kYXkgaW4gYSBwcm9k dWN0aW9uIGVudmlyb25tZW50LCBvciBzaG9ydGx5PyBOb3QgbWVyZWx5IGEgZmVhdHVyZSBpbiBh IHZlbmRvcidzIHByb2R1Y3QgbWF0ZXJpYWxzPzxicj4NCjxicj4NClNwZWFraW5nIGFzIGFuIGlu ZGl2aWR1YWwsIEkgY2FuIGZpbmQgYSBsb3Qgb2YgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBj b250ZW50IGFkYXB0YXRpb24gaXMgbm90IG5lZWRlZCwgYW5kIGFueSBhZGFwdGF0aW9uIGlzIHJl YWxseSBwYXJ0IG9mIHRoZSBDUCAtIHVDRE4gaW50ZXJmYWNlICh3aGljaCBpcyBvdXQgb2YgdGhl IHNjb3BlIG9mIG91ciBjaGFydGVyKS48YnI+DQo8YnI+DQotLSBSaWNoPGJyPg0KPC9mb250Pjxi cj4NCiZuYnNwOzxicj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxmb250IHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48Yj5Gcm9tPC9iPjogWmhvdVpoaXBlbmcgW21haWx0bzp6aG91emhpcGVu Z0BodWF3ZWkuY29tXQ0KPGJyPg0KPGI+U2VudDwvYj46IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAy MDExIDAzOjQ1IEFNPGJyPg0KPGI+VG88L2I+OiBNYXJrIGRlIEpvbmcgJmx0O21hcmtAamV0LXN0 cmVhbS5ubCZndDs7IEFsYW4gS2F2YW5hZ2ggJmx0O2FsYW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29t Jmd0Ow0KPGJyPg0KPGI+Q2M8L2I+OiBjZG5pQGlldGYub3JnICZsdDtjZG5pQGlldGYub3JnJmd0 OyA8YnI+DQo8Yj5TdWJqZWN0PC9iPjogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LWNkbmktdXNlLWNhc2VzLTAwLnR4dCA8YnI+DQo8L2ZvbnQ+Jm5ic3A7PGJyPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyBNYXJr LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TmljZSB0byBtZWV0 IHlvdSBvbiBsaW5lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SW4geW91ciBjb21wYW554oCZcyB3ZWJzaXRlLCBJIGp1c3QgZmluZCBzb21lIGluZm9ybWF0aW9u IHRoYXQgYWRkcmVzc2VzIOKAnA0KPC9zcGFuPjxzcGFuIGxhbmc9Ik5MIiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzRDNTY1QztsYXlvdXQtZ3JpZC1tb2RlOmxpbmUiPlZvZGFmb25lIHN1YnNj cmliZXJzIGNvbXBsYWluZWQgYWJvdXQgdmlkZW8gcGVyZm9ybWFuY2Uu4oCdPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vd3d3LmpldC1zdHJl YW0ubmwvc2VhcmNoLz9zZWFyY2g9dHJhbnNjb2RpbmciPmh0dHA6Ly93d3cuamV0LXN0cmVhbS5u bC9zZWFyY2gvP3NlYXJjaD10cmFuc2NvZGluZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+RGVhciBhbGwgaW4gdGhpcyBncm91cCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIGxhc3QgZmV3IGRheXMsIGV4Y2VwdCB0aGUgcHVibGlj IGVtYWlsIGRpc2N1c3Npb25zIEkgaGF2ZSBjb250YWN0ZWQgd2l0aCBzb21lIHBlb3BsZSBhbmQg ZGlzY3Vzc2VkIHdpdGggbXkgb3duIGNvbGxlYWd1ZXMgb2YgYWxsIGRldGFpbHMgb24NCiB0aGlz IGlzc3VlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Rmlyc3Qs IGFsdGhvdWdoIHRoZSBtYXJrZXQgcmVxdWlyZW1lbnQgZm9yIGl0IGlzIHZlcnkgaW1wb3J0YW50 LCBJIGZlZWwgSeKAmWQgYmV0dGVyIHNob3cgdXAgbW9yZSBpbmZvcm1hdGlvbiBvbiB0aGUgcHJv Y2VkdXJlIGludm9sdmVkLiBJIGhhdmUgZXhwbGFpbmVkDQogbWFueSB0aW1lcyB0aGF0IHRvIHN1 cHBvcnQgY29udGVudCBhZGFwdGF0aW9uIGlzIHJhdGhlciBzaW1wbGUgd2hpbGUgdGhlIHdvcmRp bmcgaXMgbm90IGVub3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgYW0gYnVzeSBtYWtpbmcgc29tZSBjb250cmlidXRpb25zIG9uIHRoaXMgYW5kIHBsYW4g dG8gdXBsb2FkIHRvIEVUU0kgbWVldGluZyBhbmQgSUVURiBDRE5JLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnkgdGhlc2Ugd29yayZuYnNwOyBJIGZlZWwgdGhl IHBlb3BsZSBtYXkgY2F0Y2ggYSB3aG9sZSB2aWV3IG9uIHRoaXMgaXNzdWUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWNvbmQsIGZvciB0aGF0IGZ1bmN0aW9u YWxpdHksIGluIGltcGxlbWVudGF0aW9uLCBpZiBzb21lIGVudGl0eSBkb2VzIG5vdCBjaG9vc2Ug dG8gc3VwcG9ydCBpdCwgaXQgbWF5IGJlIG9rLiBTaW5jZSBpdCBtYXkgYmUgbmVnb3RpYXRlZCBi ZXR3ZWVuDQogdHdvIENETnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JZiBkQ0ROIGRvZXMgbm90IHN1cHBvcnQgdGhhdCwgaXQgbWF5IGJlIHRoZSB1Q0ROIHJl c3BvbnNpYmxlIHRvIGNvbXBsZXRlIHRoZSB0cmFuc2NvZGluZyBhbmQgZGVsaXZlciB0aGUgY29u dGVudCBvZiBtdWx0aXBsZSBmb3JtYXRzIGFuZCByYXRlcw0KIHRvIGRDRE4uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlyZCwgYWx0aG91Z2ggQ0ROSSBpcyBh IG5ldyBhcmNoaXRlY3R1cmUsIHdoaWxlIHRoZSBjb250ZW50IG9wZXJhdGluZyBoYXMgYmVlbiBl eGlzdGVkIGZvciB5ZWFycy4gQXMgSSBrbm93IHRoZSBjb250ZW50IGZyb20gVVNBIHRvIHRoZSBk b3duc3RyZWFtDQogb3BlcmF0b3IgaXMgdHJhbnNmZXJyZWQgb24gb25lIGNvcHkgYW5kIHRoZSBk b3duc3RyZWFtIG9wZXJhdG9yIHdpbGwgaGFuZGxlIHRoZSB0cmFuc2NvZGluZy4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5QZXJoYXBzLCB0aGUgY29udGVudCBhZGFwdGF0 aW9uIGlzIG1vcmUgb24gdGhlIG1vYmlsZSBvcGVyYXRpbmcuIEJ1dCBJIGZlZWwgY3VycmVudGx5 IG1vc3Qgb3BlcmF0b3Igd2lsbCBiZSBhIGFsbCBzZXJ2aWNlIG9wZXJhdG9yLiBBbmQgZm9yIHRo ZQ0KIENETiBwcm92aWRlcnMsIGl0IG1heSBiZSBiZXR0ZXIgdG8gc3VwcG9ydCBhbGwga2luZHMg b2Ygc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJl c2lkZXMsIEkgbGlrZSBzYXkgdGhhdCB0aGUgdGVjaG5vbG9neSBvbiB0aGlzIHRvcGljIGhhcyBi ZWVuIGZvciBtYW55IHllYXJzIGFuZCBoYXMgYmVlbiByYXRoZXIgbWF0dXJlLCBldmVuIHNvbWUg aXRlbXMgaW4gaWV0ZiBzdWNoIGFzIHJmYzM1MDcNCiBpY2FwLiBTbyBmcm9tIHRoZSB0ZWNobmlx dWUgcG9pbnQgb2YgdmlldywgaXQgaXMgYSBuYXR1cmUgYWN0aW9uIHRvIGJlIGludm9sdmVkIGlu IENETiBpbnRlcmNvbm5lY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5aaGlwZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFyayBkZSBKb25nIFtt YWlsdG86bWFya0BqZXQtc3RyZWFtLm5sXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBP Y3RvYmVyIDI3LCAyMDExIDQ6MjEgQU08YnI+DQo8Yj5Ubzo8L2I+IEFsYW4gS2F2YW5hZ2g8YnI+ DQo8Yj5DYzo8L2I+IEJlbiBOaXZlbi1KZW5raW5zOyBaaG91WmhpcGVuZzsgY2RuaUBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Y2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ SGkgQWxhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBCZW4g c3RhdGVkIHRoZSBvdmVyYWxsIGRpc2N1c3Npb24gcmlnaHQgbm93IGlzIGFib3V0IGRlbGl2ZXJ5 LCBub3Qgb24gYWRhcHRhdGlvbi4gSXQgaXMgaGFyZCBlbm91Z2ggdG8gZ2V0IGNvbnNlbnN1cyBv biB0aGUgZGVsaXZlcnkgYXNwZWN0IGFscmVhZHkgbm90IHRvIG1lbnRpb24geW91ciByZXF1aXJl bWVudCBmcm9tIGNvbnRlbnQgYWRhcHRhdGlvbiBhZGRlZCB0byB0aGF0LA0KIHNvIEkgYWdyZWUg d2l0aCBCZW4gd2Ugc2hvdWxkIHN0aWNrIHdpdGggdGhlIGRlbGl2ZXJ5IGFzcGVjdCBmb3IgdGhl IGZpcnN0IHNwZWNzLiZuYnNwO0kgY2FuIGltYWdpbmUgdGhpcyBjb3VsZCBiZSBhIGRpc2N1c3Np b24gbGF0ZXIgb24gYnV0IHBsZWFzZSBsZXQgdXMga2VlcCB0aGUgc2NvcGUgb2YgdGhpcyBiZSBj bGVhbiBhbmQgdHJhbnNwYXJlbnQuIEl0IGlzIG9mIGJlbmVmaXQgb2YgZXZlcnlvbmUgdG8gZ2V0 IHRoZSBmaXJzdCBzcGVjcyBhcyBmYXN0DQogYXMgcG9zc2libGUuIFRoYW5rcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFz cz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5NZXQgdnJpZW5kZWxpamtlIGdyb2V0LDwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5LaW5kIHJlZ2FyZHMsPC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxi cj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5NYXJrIGRlIEpvbmc8L3NwYW4+PGJy Pg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPkludGVybmF0aW9uYWwgQnVzaW5lc3Mg RGV2ZWxvcGVyPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5KZXQt U3RyZWFtIEJWPC9zcGFuPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFu Ij5FLW1haWw6IDxhIGhyZWY9Im1haWx0bzptYXJrQGpldC1zdHJlYW0uY29tIj5tYXJrQGpldC1z dHJlYW0uY29tPC9hPjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+ T2ZmaWNlOiAmIzQzOzMxICgwKTUwIDUyNjE4MjA8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImFw cGxlLXN0eWxlLXNwYW4iPk1vYmlsZTogJiM0MzszMSAoMCk2IDgxMTA4MjYzPC9zcGFuPjxicj4N CjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5GYXg6ICYjNDM7MzEgKDApNTAgNTI2NDIx NDwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LSBFdmVu dDo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TWVldA0KIHVzIGF0IFN0 cmVhbWluZyBNZWRpYSBFdXJvcGUsIDE3LTE4IE9jdG9iZXIsIExvbmRvbiwgVUs8L3NwYW4+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0gRXZlbnQ6PC9zcGFu PjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7TWVldA0KIHVzIGF0 IE9ubGluZSBWaWRlbyBTdHJhdGVnaWVzLCAxOSBPY3RvYmVyLCBMb25kb24sIFVLPC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tIEV2ZW50Ojwvc3Bh bj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwO01lZXQNCiB1cyBh dCBDRE4gV29ybGQgU3VtbWl0LCAyNS0yOCBPY3RvYmVyLCBMb25kb24sIFVLPC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tPC9zcGFuPjwvc3Bhbj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+TmV3czo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDtQcmUtcmVxdWVzdA0KIHlvdXIgVGVjaG5vbG9neSBXaGl0ZXBh cGVyIG5vdyBhbmQgYmUgdGhlIGZpcnN0IHRvIGhhdmUgaXQsIGNoZWNrIDxhIGhyZWY9Imh0dHA6 Ly93d3cuamV0LXN0cmVhbS5jb20iPg0Kd3d3LmpldC1zdHJlYW0uY29tPC9hPjwvc3Bhbj48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tJm5ic3A7PGI+TmV3czombmJzcDs8L2I+ Q2hlY2smbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmpldC1zdHJlYW0uY29tIj5odHRwOi8vd3d3 LmpldC1zdHJlYW0uY29tPC9hPiB0byBkb3dubG9hZCBvdXIgJ1NpeCBUcmVuZHMNCiBpbiBDRE5z JyBicm9jaHVyZTwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi08L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUt c3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5CbG9nOjwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbS9ibG9nLyI+d3d3LmpldC1z dHJlYW0uY29tL2Jsb2cvPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5 bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4tPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VmlkZW9FeGNoYW5n ZTo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9 Imh0dHA6Ly93d3cudmRvLXgubmV0Ij53d3cudmRvLXgubmV0PC9hPjwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2 LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+U3RyZWFtemlsbGE6PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBw bGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LnN0cmVhbXppbGxhY2RuLmNvbSI+d3d3LnN0 cmVhbXppbGxhY2RuLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkNvcnBvcmF0ZTo8 L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3 dy5qZXQtc3RyZWFtLmNvbSI+d3d3LmpldC1zdHJlYW0uY29tPC9hPjwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDI2LCBPY3QsMjAxMSwgYXQgODozMyBQTSwgQWxhbiBLYXZh bmFnaCB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlbjxi cj4NCjxicj4NCkltIGFzc3VtaW5nIHRoZW4gYmFzZWQgb24geW91ciBjb21tZW50cyBiZWxvdyBh cmUgeW91IHN1Z2dlc3Rpbmcgd2UgYXJlIGdvaW5nIHRvIGhhdmUgYSBudW1iZXIgb2YgdmVyc2lv bnMgb2YgdGhlIENETi1JIE1ldGFkYXRhPzxicj4NCjxicj4NCkkgc3ltcGF0aGlzZSB3aXRoIHdo YXQgeW91IGFyZSBwb2ludGluZyBvdXQgYmVsb3cgYW5kIGRvIGFncmVlIHRoYXQgdGhlcmUgaXMg c29tZSB3b3JrIHRvIGJlIGRvbmUsIGJ1dCBJIHN0aWxsIGZlZWwgdGhhdCBjb250ZW50IGFkYXB0 YXRpb24gaXMgdG8gbWUgYSBmdW5kYW1lbnRhbCByZXF1aXJlbWVudCB0byB3aGF0IGNvbGxlY3Rp dmVseSB3ZSBzaG91bGQgYWRkcmVzcyBpbiB0aGUgQ0ROLUkgV0cuIEkgZG8gYWdyZWUgd2l0aCB5 b3UgdGhhdCBjb250ZW50DQogYWRhcHRhdGlvbiBpcyBhbiBvcHRpbWl6YXRpb24gYmV0d2VlbiBD RE4ncyBidXQgaXQncyBhIHZlcnkgaW1wb3J0YW50IG9uZSB0aGF0IEkga25vdyBOZXR3b3JrIFNl cnZpY2UgUHJvdmlkZXJzIHBhcnRpY3VsYXJseSByZXF1aXJlLjxicj4NCjxicj4NCkFsYW48YnI+ DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IDxhIGhyZWY9Im1h aWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmciPmNkbmktYm91bmNlc0BpZXRmLm9yZzwvYT4gW21h aWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCZW4gTml2ZW4tSmVua2lu czxicj4NClNlbnQ6IE9jdG9iZXItMTItMTEgMToxMyBQTTxicj4NClRvOiBaaG91WmhpcGVuZzxi cj4NCkNjOiA8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48 YnI+DQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2Ut Y2FzZXMtMDAudHh0PGJyPg0KPGJyPg0KWmhpcGVuZyw8YnI+DQo8YnI+DQpPbiAxMiBPY3QgMjAx MSwgYXQgMTA6MjIsIFpob3VaaGlwZW5nIHdyb3RlOjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5I ZWxsbyBCZW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+VGhlIFVFIG1heSBzZWxlY3QgdGhlIGNvbnRlbnQgZm9ybWF0IG9u IHRoZSBDUCB3ZWIuIEFmdGVyIHRoYXQgdGhlIHVzZXIgb25seSBkZXNpcmVzIHRvIGdldCBoaXMg c2VsZWN0ZWQgY29udGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CdXQgaG93IHRoZSBjb250 ZW50IGlzIHRyYW5zZmVycmVkIHRvIHRoZSBjbGllbnQgaXMgbm90IHdvcnJpZWQgYnkgdGhlIHVz ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIENQIG1heSBjcmVhdGUgYSBzcGVjaWFsIGZv cm1hdCBhcyByZXF1aXJlZCBieSB0aGUgdXNlciBhbmQgYXNrIHRoZSBDRE4gdG8gZGVsaXZlciB0 byB1c2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoaWxlIENQIG1heSBnaXZlIGEgSEQgZm9y bWF0IGNvbnRlbnQgdG8gdUNETiBhbmQgdGhlIGRDRE4gbWF5IHRoZW4gdHJhbnNmb3JtIHRvIHRo ZSBmb3JtYXQgYXMgdGhlIHVzZXIgc2VsZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpM b3RzIG9mIHRoaW5ncyBtYXkgYmUgcG9zc2libGUgdG8gZG8gYW5kIENETiBwcm92aWRlcnMgb2Zm ZXIgbWFueSBhZGRpdGlvbmFsIHNlcnZpY2VzIG9uIHRvcCBvZiB0aGUgJnF1b3Q7Y29yZSZxdW90 OyBzZXJ2aWNlIG9mIGNvbnRlbnQgZGVsaXZlcnkuIEhvd2V2ZXIsIG91ciBvYmplY3RpdmUgKGJh c2VkIG9uIG15IGludGVycHJldGF0aW9uIG9mIHRoZSBDRE5JIGNoYXJ0ZXIpIGlzIHRvIGZvY3Vz IG9uIHdoYXQgaXMgbmVjZXNzYXJ5IHRvIGludGVyY29ubmVjdA0KIENETnMgdG8gZGVsaXZlciBj b250ZW50IGZyb20gYSBDU1AgdG8gYW4gRW5kIFVzZXIgdGhhdCBpcyB0YXJnZXRlZCBhbmQgZGVw bG95YWJsZSB3aXRoaW4gYSBzaG9ydCB0aW1lIGZyYW1lICgxOC0yNCBtb250aHMpLjxicj4NCjxi cj4NCkNvbnRlbnQgdHJhbnNmb3JtYXRpb24vYWRhcHRhdGlvbiBpcyBub3QgYW4gZXNzZW50aWFs IHJlcXVpcmVtZW50IGluIG9yZGVyIHRvIGFjaGlldmUgdGhhdCBhaW0gKHdlIGNhbiBkZWxpdmVy IGNvbnRlbnQgZnJvbSBDU1BzIHRvIEVuZCBVc2VycyB2aWEgbXVsdGlwbGUgQ0ROcyB3aXRob3V0 IG5lZWRpbmcgb3IgcmVxdWlyaW5nIGFueSBDRE4gc3VwcG9ydHMgY29udGVudCBhZGFwdGF0aW9u KS48YnI+DQo8YnI+DQpJbiBteSBvcGluaW9uIHdlIGhhdmUgZW5vdWdoIHdvcmsgdG8gZG8gYWxy ZWFkeSB3aXRob3V0IHRyeWluZyB0byBleHBhbmQgdGhlIHNjb3BlIG9mIG91ciB3b3JrIHRvIGlu Y2x1ZGUgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgdGhhdCBkbyBub3QgaGVscCB1cyBhZGRyZXNz IG91ciBjb3JlIG9iamVjdGl2ZXMgYXMgbGFpZCBvdXQgaW4gdGhlIENETkkgY2hhcnRlci48YnI+ DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhpcyBjYXNlLCBpdCBpcyBub3RoaW5nIHJlbGF0ZWQg dG8gaG93IHRoZSB1c2VyIHNlbGVjdCBmb3JtYXRzIG9uIENQIHdlYnNpdGUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U28s IGl0IGlzIHRoZSBDUCBhbmQgdXNlciB0byBkZWNpZGUgdGhlIGNvbnRlbnQgZm9ybWF0IG5vdCB0 aGUgQ0ROKHlvdXIgYXNzZXJ0IGlzIG5vdCBjb3JyZWN0IGFuZCBzZWVtcyB5b3UgdGFrZSB0aGF0 IGFzc2VydCBhcyB5b3VyIGJhc2UgZm9yIHRoZSBkaXNjdXNzaW9uKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBmb3IgJnF1b3Q7dGhlIGNv cmUgQ0ROIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSBDRE5zIHRvZGF5JnF1b3Q7LCBJIGhhdmUg ZXZlciByYWlzZWQgYW4gZW1haWwgYmVmb3JlIHRoYXQgeW91ciBjb21wYW55J3Mgd2VicGFnZSBo YXMgY2xhaW1lZCBzdXBwb3J0aW5nIG1lZGlhIHRyYW5zZm9ybWF0aW9uIGFuZCBtdWx0aS1zY3Jl ZW4gc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QZXJoYXBzLCBJIGxpa2UgYXNraW5n IHlvdSBsaXN0IHNvbWUgZmVhdHVyZXMgdGhhdCB5b3UgZmVlbCBhcmUgdGhlIGNvcmUgZnVuY3Rp b25hbGl0aWVzIGJ5IGV4aXN0aW5nIG1haW4gc3RyZWFtIENETnMuIFRodXMgd2UgbWF5IGNvbXBh cmUgYW5kIHRha2UgZGVlcCBsb29rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpJIHRoaW5r IHRoZSBjb3JlIGZ1bmN0aW9uYWxpdHkgbWFwcyBwcmV0dHkgd2VsbCB0byB0aGUgQ0ROSSBpbnRl cmZhY2VzLCBuYW1lbHk6IFJlcXVlc3QgUm91dGluZywgTWV0YWRhdGEgY29uZmlndXJhdGlvbiwg bG9nIHByb2R1Y3Rpb24gYW5kIGNvbnRyb2wgcGx1cyBjb250ZW50IGFjcXVpc2l0aW9uIGFuZCBj b250ZW50IGRlbGl2ZXJ5Ljxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGd1ZXNzIG1hbnkgcGVv cGxlIGhhdmUgdGhlIGV4cGVyaWVuY2Uva25vd2xlZGdlIG9mIGNvbnRlbnQgcmVsYXRlZCBzZXJ2 aWNlLiBUaGUgdXNlciBhbmQgQ1Agb25seSBjYXJlIHdoZXRoZXIgdGhlIENETiBwcm92aWRlcnMg bWF5IHNhdGlzZnkgdGhlaXIgcmVxdWlyZW1lbnQgd2hpbGUgbm90IGNhcmUgdGhlIGludGVybmFs IHByb2Nlc3MuIEp1c3QgYXMgR1NNL1BTVE4gaW50ZXJjb25uZWN0aW9uLA0KIHRoZSB1c2VyIG9u bHkgY2FyZSBzdWNjZXNzZnVsIGludGVyY29ubmVjdGlvbiB3aGlsZSBub3QgY2FyZSBob3cgdGhl IHZvaWNlIGlzIHRyYW5zZm9ybWVkIGluIHByb2Nlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+QmVzaWRlcywgSSBsaWtlIHJhaXNlIGEgY2FzZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5HaXZlbiBjdXJyZW50bHkgQkJDIHJlY3J1aXRzIENETiBwcm92aWRlcnMgdGhh dCBtYXkgc3VwcG9ydCAxMCBtZWRpYSBmb3JtYXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9u ZSBjYW5kaWRhdGUgaXMgeW91ciBjb21wYW55LCBhbm90aGVyIGlzIENETi1YLiBUaGUgdXNlcnMg YXJlIGxvY2F0ZWQgaW4gRnJhbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvIGJvdGggeW91 ciBjb21wYW55IGFuZCBDRE4tWCBzaG91bGQgY29ubmVjdCBhIEZyYW5jZSBDRE4gcHJvdmlkZXIo Q0ROLVkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHlvdXIgY29tcGFueSdzIHNvbHV0aW9u IGlzIHRvIHNlbmQgMTAgc3RyZWFtcyBvZiBkaWZmZXJlbnQgZm9ybWF0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+b2Ygb25lIGNvbnRlbnQgdG8gQ0ROLVk7IFdoaWxlIENETi1YJ3Mgc29sdXRpb24g aXMgdG8gc2VuZCAxIHN0cmVhbSB0byBDRE4tWSB3aGlsZSBDRE4tWSBtYXkgY29uZHVjdCBzb21l IGFkYXB0YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q29tcGFyaW5nIHRoZXNlIHR3byBz b2x1dGlvbnMsIGZvciB5b3VyIGNvbXBhbnkgYW5kIENETi1YLCBhYnNvbHV0ZWx5IHRoZSBjb3N0 IG9mIENETi1YIGlzIG11Y2ggbG93ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIENETi1Z LCBpbiBzb2x1dGlvbi0xLCBpdCBzaG91bGQgcmVjZWl2ZS9mb3J3YXJkIDEwIHN0cmVhbXMgOyB3 aGlsZSBpbiBzb2x1dGlvbi0yLCBpdCBzaG91bGQgb25seSByZWNlaXZlIDEgc3RyZWFtIGJ1dCBu ZWVkIHRvIHRha2UgdHJhbnNmb3JtYXRpb24gdG8gb3V0cHV0IDEwIHN0cmVhbXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hpY2ggc29sdXRp b24gaXMgbW9yZSBjb21wZXRpdGl2ZS4gaXQgaXMgU29sdXRpb24gMSwgcmlnaHQuIFJlbWVtYmVy IHRoZSBwcmljZSBmcm9tIEJCQyBpcyBzYW1lIHRvIGJvdGggeW91ciBjb21wYW55IGFuZCBDRE4t WCBvciBCQkMgd291bGQgc2VsZWN0IG9uZSBDRE4gcHJvdmlkZXIgd2l0aCB0aGUgbG93ZXIgcHJp Y2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgYSBDRE4gcHJvdmlkZXIgbWF5IG5vdCBnZXQg dGhlIGNvbnRyYWN0IGZyb20gQ1AsIGhvdyBpdCBtYXkgc2F5IGl0IGlzIG5vdCBhIGNvcmUgZnVu Y3Rpb25hbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KV2hhdCB5b3UgYXJlIGRlc2Ny aWJpbmcgaXMgYSBwb3NzaWJsZSBvcHRpbWl6YXRpb24gdGhhdCBhIHBhcnRpY3VsYXIgQ0ROIG1h eSB3aXNoIHRvIGltcGxlbWVudCBub3QgYSBjb3JlIGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgdG8g ZW5hYmxlIGNvbnRlbnQgZGVsaXZlcnkgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5zLiBJIGNh biB0aGluayBvZiBtYW55IG9wdGltaXphdGlvbnMgdGhhdCBhIENETiBjb3VsZCBpbXBsZW1lbnQg dG8gZGlmZmVyZW50aWF0ZQ0KIHRoZWlyIHNlcnZpY2UgYnV0IHRoZSBpbnRlcm5hbCB3b3JraW5n cyBvZiBhbiBpbmRpdmlkdWFsIENETiBhcmUgb3V0IG9mIHNjb3BlIG9mIG91ciBjaGFydGVyLjxi cj4NCjxicj4NClNvIHRvIHJlcGVhdCBteSBwb3NpdGlvbiBmb3IgYSBmaW5hbCB0aW1lOiBDb250 ZW50IGFkYXB0YXRpb24gaXMgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBlbmFibGUg Y29udGVudCBkZWxpdmVyeSBiZXR3ZWVuIGludGVyY29ubmVjdGVkIENETnMgYW5kIHRoZXJlZm9y ZSBnaXZlbiB0aGUgd29ya2xvYWQgd2UgYWxyZWFkeSBoYXZlIHRvIHNwZWNpZnkgc29sdXRpb25z IHRoYXQgZG8gYWRkcmVzcyB0aGUgY29yZSBmdW5jdGlvbmFsaXR5DQogcmVxdWlyZWQgdG8gaW50 ZXJjb25uZWN0IENETnMgSSBkbyBub3QgdGhpbmsgd2Ugc2hvdWxkIGJlIHRyeWluZyB0byBhZGQg bW9yZSB3b3JrIGludG8gdGhhdCB3b3JrbG9hZCBhcyBpdCB3aWxsIG9ubHkgZGlzdHJhY3QgdXMg ZnJvbSBhY2hpZXZpbmcgb3VyIGdvYWwgb2YgcHJvZHVjaW5nIGRlcGxveWFibGUgc29sdXRpb25z IHdpdGhpbiB0aGUgdGltZWZyYW1lIHdlIGFyZSBiZWluZyB0b2xkIGJ5IG9wZXJhdG9ycyB0aGV5 IG5lZWRzIHNvbHV0aW9ucw0KIHdpdGhpbi48YnI+DQo8YnI+DQpCZW48YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+U28sIGlmIHdlIGFsbCByZWFsaXplIHRoYXQgY3VycmVudGx5IHRoZSBtZWRpYSB0 eXBlIGlzIHJpY2gsIHRoZSBDRE4gcHJvdmlkZXJzIHNob3VsZCBzdXJ2aXZlIGluIHRoZSBleGlz dGluZyBlY29zeXN0ZW0gYW5kIHN1cHBvcnQgdGhlIG1lZGlhIHR5cGVzIGFzIHJlcXVpcmVkIGJ5 IHRoZSBtYXJrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmFjayB0 byB0aGUgY2FzZSBvZiBHU00vRy43MTEsIGl0IGp1c3Qgd2hlbiBjb25jZXJuaW5nIHRoZSBpbnRl cmNvbm5lY3Rpb24sIHRoZSB0cmFuc2Zvcm1hdGlvbiBzaG91bGQgYXQgb25jZSBiZSBzb2x2ZWQu IE90aGVyd2lzZSB0aGUgaW50ZXJjb25uZWN0aW9uIG1heSBub3QgYmUgb3BlcmF0ZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnIsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTogQmVu IE5pdmVuLUplbmtpbnMgW21haWx0bzpiZW5Abml2ZW4tamVua2lucy5jby51a108bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIwMTEgMTI6MTkgQU08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UbzogWmhvdVpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5DYzogPGEgaHJlZj0ibWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbSI+DQpwaGlsaXAu ZWFyZGxleUBidC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBp ZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJqZWN0OiBSZTogW0NETmldIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WmhpcGVuZyw8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAxMSBPY3QgMjAx MSwgYXQgMDU6MTYsIFpob3VaaGlwZW5nIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVuIGFuZCBQaGlsaXAsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGxpa2UgdG8gcmVzcG9uZCB5b3VyIGNvbmNl cm4gaW4gdGhpcyBvbmUgZW1haWw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlbiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZmVlbCB3aGF0IHdlIGFy ZSBub3cgZGlzY3Vzc2luZyBpcyB3aGF0IGlzIHRoZSAmcXVvdDtjb3JlJnF1b3Q7IGZ1bmN0aW9u IG9mIENETi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHlvdSBz YXksIENETiBpcyB1c2VkIHRvIGRlbGl2ZXIgY29udGVudC4gVGhhdCBpcyBhYnNvbHV0ZWx5IGNv cnJlY3QgdGhhdCB0aGUgZGVsaXZlcnkgY2FwYWJpbGl0eSBpcyB0aGUgY29yZSByZXF1aXJlbWVu dCBmb3IgQ0ROIHN5c3RlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PldoaWxlIENETiBpcyB1c2VkIHRvIHByb3ZpZGUgdGhlIGNvbnRlbnQgZGVsaXZlcnkgc2Vydmlj ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoYXQgbWVhbnMgc2Vy dmljZS4gSXQgc2hvdWxkIGluY2x1ZGUgJnF1b3Q7dGltZSZxdW90OyAmcXVvdDtsb2NhdGlvbiZx dW90OyBhbmQgJnF1b3Q7bWVkaWEgdHlwZSZxdW90OywgZXRjLiBUaGVzZSBmZWF0dXJlcyBhcmUg YWxsIHRoZSBjb3JlIGZlYXR1cmUgZm9yIGEgc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPklmIHdlIG9ubHkgY29uY2VybiAmcXVvdDtkZWxpdmVyaW5nIG9u ZSBkYXRhIGJsb2NrJnF1b3Q7LCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIGlzc3VlcyBzdWNo IGFzICZxdW90O2xvZ2dpbmcmcXVvdDsgJnF1b3Q7Z2VvZ3JhcGhpYyBjb25zdHJhaW50JnF1b3Q7 IGFyZSB0aGUgY29yZSBvZiBDRE4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciAm cXVvdDt3aXRob3V0IGV4cGxpY2l0IGtub3dsZWRnZSBvZiB3aGF0IHRoYXQgY29udGVudCBhY3R1 YWxseSBpcyAmcXVvdDssIEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgd29yZGluZyBpcyBhY2N1 cmF0ZSBzaW5jZSBnZW5lcmFsbHkgYSBDRE4gbWF5IGNsYWltIGl0IHN1cHBvcnQgZGlmZmVyZW50 IG1lZGlhcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ5IHRoaXMg b3Bwb3J0dW5pdHksIEkgbGlrZSB0byBzaGFyZSBhIHVzZSBjYXNlOiBhIGNhbGwgZnJvbSBhIEdT TSBwaG9uZSB0byBhIFBTVE4gdGVsZXBob25lLCB0aGUgdm9pY2Ugc3RyZWFtIHNob3VsZCBiZSB0 cmFuc2Zvcm1lZCBmcm9tIEdTTSB2b2ljZSB0byBHLjcxMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkZvciB0aGUgdXNlciwgaGUgZG9lcyBub3QgbmVlZCB0byBrbm93 IHdoYXQgdHlwZSBvZiBkYXRhIGhhcyBiZWVuIHRyYW5zZmVycmVkLCBidXQgdGhlIG9wZXJhdG9y IGhhcyBkb25lIHNvbWUgd29yayB0byBpbnRlcmNvbm5lY3QgdHdvIHN5c3RlbXMsIHJpZ2h0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBsaWtlIHRvIGtub3cgd2hl dGhlciB5b3UgbWF5IGFjY2VwdCB0aGF0IG15IHVzZSBjYXNlIGlzIHNpbWlsYXIgdG8gdGhpcyBj YXNlIGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZG9uJ3QgdGhpbmsgeW91ciB1c2UgY2FzZSBpcyBzaW1p bGFyIHRvIHRoZSBhbmFsb2d5IG9mIG1vYmlsZSBuZXR3b3JrcyBiZWluZyBpbnRlcmNvbm5lY3Rl ZCB0byBQU1ROIG5ldHdvcmtzLiBJbiB0aGUgY2FzZSBvZiBjb250ZW50IGRlbGl2ZXJ5IHRoZSBu ZWdvdGlhdGlvbiBpcyBkb25lIGJldHdlZW4gdGhlIFVzZXIvQ2xpZW50IGFuZCB0aGUgQ29udGVu dCBQcm92aWRlcg0KIGFuZCB0aGUgQ0ROIGlzIGp1c3QgdXNlZCB0byBleGVjdXRlL3BlcmZvcm0g dGhlIGRlbGl2ZXJ5IHRoYXQgaGFzIGJlZW4gbmVnb3RpYXRlZC4gVGhlIENETiBpcyBub3QgaW52 b2x2ZWQgaW4gdGhlIGRlY2lzaW9uIG1ha2luZyBvZiB3aGF0IHJlcHJlc2VudGF0aW9ucyB0aGUg Q29udGVudCBQcm92aWRlciBkZWNpZGVzIHRvIG9mZmVyIHRvIHRoZSBVc2VyL0NsaWVudCBvciBp biB3aGF0IHJlcHJlc2VudGF0aW9ucyB0aGUgVXNlci9DbGllbnQgZGVjaWRlcw0KIHRvIHJlcXVl c3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5BcyBmb3IgeW91IHNhaWQgc2VsZWN0aW5nIG1lZGlhIGJ5IHRoZSAmcXVvdDtwb3J0YWwmcXVv dDssIHlvdSBtYXkgc2VlIHRoZSB3YXkgJnF1b3Q7IHVDRE4gZGVsaXZlcnMgbXVsdGlwbGUgbWVk aWEgc3RyZWFtcyB0byBkQ0ROJnF1b3Q7IGlzIG5vdCBnb29kIHRoYW4gJnF1b3Q7dUNETiBkZWxp dmVycyBvbmUgbWVkaWEgc3RyZWFtIHRvIGRDRE4gYW5kIGRDRE4gdGFrZXMgc29tZSBhZGFwdGF0 aW9uIHRvIHN1cHBvcnQgbXVsdGlwbGUNCiBtZWRpYSB0eXBlcyZxdW90Oy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5O b3cgd2hhdCB5b3UncmUgdGFsa2luZyBhYm91dCBpcyBhbiBvcHRpbWlzYXRpb24sIG5vdCBhIGNv cmUgZnVuY3Rpb24gcmVxdWlyZWQgdG8gYWN0dWFsbHkgZGVsaXZlciB0aGUgY29udGVudCAoYW5k IHJlcG9ydCwgYmlsbCwgZXRjLiBmb3IgdGhhdCBkZWxpdmVyeSkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TXkgcG9zaXRpb24gaXMgdGhhdCB3 ZSBzaG91bGQgZm9jdXMgb24gaG93IHRvIGVuYWJsZSB0aGUgaW50ZXJjb25uZWN0aW9uIG9mIHRo ZSBjb3JlIENETiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgQ0ROcyB0b2RheSAod2hpY2ggaXMg YWxzbyBteSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgc2NvcGUgb2YgdGhlIENETkkgd29ya2luZyBn cm91cCBhcyBleHByZXNzZWQgaW4gaXRzDQogY2hhcnRlcikgYmVjYXVzZSBkb2luZyBzbyBpcyBh IHNpZ25pZmljYW50IHBpZWNlIG9mIHdvcmsgaW4gaXRzZWxmLiBMZXQncyBub3Qgc3RhcnQgdHJ5 aW5nIHRvIGFkZCBpbiBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgYmV5b25kIHdoYXQgdGhlIG1h am9yaXR5IG9mIENETnMgc3VwcG9ydCB0b2RheSBhcyB0aGF0IHdpbGwganVzdCBkZWxheSB1cyBn ZXR0aW5nIHVzYWJsZSBzcGVjaWZpY2F0aW9ucyBpbnRvIHRoZSBtYXJrZXQgaW4gYSB0aW1lbHkN CiBmYXNoaW9uIElNTy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5CZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkEgZ29vZCBxdWVzdGlvbiBpcyAmcXVvdDtzZWN1cml0eSZxdW90OyBzaW5j ZSBJIGhhdmUgZG9uZSBzaXggeWVhcnMgb24gdGhlIERSTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+YW5kIGxpa2UgdG8gcHJvbW90ZSB0aGUgRFJNIGFsbCBhcm91bmQg dGhlIHdvcmxkOikgSWYgdGhlIGNvbnRlbnQgaXMgbmVlZGVkIHRvIGJlIHByb3RlY3RlZCwgZ2Vu ZXJhbGx5IHlvdSBtYXkga25vdyBhbGwgdGhlIHN5c3RlbXMgc2hvdWxkIGJlIGdyYW50ZWQgYnkg dGhlIGNvbnRlbnQgb3duZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5IZXJlIEkgYWxzbyBsaWtlIHRvIGNsYXJpZnkgdGhhdCBub3Qgb25seSB0aGUgbWVkaWEgaXRz ZWxmIGJ1dCB0aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBzZXJ2aWNlIGl0c2VsZiAoc3VjaCBh cyB0aGUgZ2VvZ3JhcGhpYyBjb25zdHJhaW50KSBzaG91bGQgYmUgcHJvdGVjdGVkIGFsc28uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TbywgdHJ1c3QgaXMgbm90IGEg cHJvYmxlbSBmb3IgdGhlIG1lZGlhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QaGls aXAsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UgdGhh dCB5b3UgZmVlbCBDb250ZW50IEFkYXB0aW9uIGlzIGFuIGlzc3VlIGZvciAmcXVvdDtSZXF1aXJl bWVudHMmcXVvdDsgYnV0IEkgZG8gbm90IGtub3cgd2h5IGl0IGlzIG5vdCBmb3IgVXNlIGNhc2Uu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGxpa2UgdG8gY2xhcmlm eSB0byBVIHRoYXQgaXQgaXMgaW1wb3J0YW50IGZvciB5b3Ugb3BlcmF0b3Igc2luY2UgaXQgbWF5 IHNhdmUgaW52ZXN0bWVudCBpZiB0aGUgc3lzdGVtIG1heSBzdXBwb3J0IGRpZmZlcmVudCBzZXJ2 aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciB1cyB2ZW5k b3IsIHdlIGFyZSBoYXBweSBvcGVyYXRvciBtYXkgaW5zdGFsbCBhIHN5c3RlbSBmb3IgdGhlIG1v YmlsZSBzZXJ2aWNlIGFuZCBhbm90aGVyIHN5c3RlbSBmb3IgdGhlIEZCQiBzZXJ2aWNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IHRoZSByZWFsaXR5IGlzIGFs bCBvcGVyYXRvcnMgYXNrIHVzIHRvIHByb3ZpZGUgYSBzeXN0ZW0gdGhhdCBtYXkgc3VwcG9ydCBk aWZmZXJlbnQgc2VydmljZSBzeXN0ZW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5G cmFua2x5LCBCZW4gYW5kIFBoaWxpcCwgSSByZW1lbWJlciBJIGhhdmUgZXhwbGFpbmVkIHNvbWV3 aGVyZSB0aGF0IHRvIGltcGxlbWVudCB0aGlzIGlzIHJhdGhlciBzaW1wbGUgLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QXQgbGVhc3QgdGhlIFVzZSBjYXNlIGFuZCBS ZXF1aXJlbWVudCBhcmUgaW5mb3JtYXRpb25hbCB0byBiZSByZWZlcnJlZCBpbiBmdXR1cmUgd29y ay4gU28gSSBkbyByZWFsbHkgZmVlbCB5b3UgbWF5IGFjY2VwdCBpdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9mIGNvdXJzZSBJIGxpa2UgdG8gcmVzcG9uZCB5b3Vy IG1vcmUgY29uY2VybiBhbmQgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5aaGlwZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTogPGEgaHJlZj0ibWFpbHRvOnBoaWxp cC5lYXJkbGV5QGJ0LmNvbSI+DQpwaGlsaXAuZWFyZGxleUBidC5jb208L2E+IFttYWlsdG86cGhp bGlwLmVhcmRsZXlAYnQuY29tXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+U2VudDogTW9uZGF5LCBPY3RvYmVyIDEwLCAyMDExIDExOjIyIFBNPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UbzogPGEgaHJlZj0ibWFpbHRvOmJlbkBuaXZlbi1q ZW5raW5zLmNvLnVrIj4NCmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPC9hPjsgWmhvdVpoaXBlbmc8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNjOiA8YSBocmVmPSJtYWls dG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlN1YmplY3Q6IFJFOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ QmVuLCBaaGlwZW5nLCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsg dGhhdCBDb250ZW50IEFkYXB0YXRpb24gaXMgbW9yZSBhbiBpc3N1ZSBmb3IgdGhlIFJlcXVpcmVt ZW50cyBkb2MgdGhhbiBmb3IgdGhlIFVzZSBjYXNlcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIGtleSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHdhbnQgdGhlIENETkkg aW50ZXJmYWNlcyB0byBiZSBhYmxlIHRvIGNvcGUgd2l0aCBhIHNjZW5hcmlvIHdoZXJlIChzYXkp IEhEL1NEIGNvbnZlcnNpb24gaXMgZG9uZSBpbiB0aGUgZENETiAmYW1wOyB0byBzaWduYWwgYWJv dXQgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB0aGluayB0aGF0IGNvcGlu ZyB3aXRoIHRoaXMgc2NlbmFyaW8gaXMgYSBzZWNvbmQgb3JkZXIgcmVxdWlyZW1lbnQsIGllIHdl IHNob3VsZCBub3Qgd29ycnkgYWJvdXQgaXQgaW4gdGhlIGluaXRpYWwgc3RhbmRhcmRzLXRyYWNr IHdvcmsuIEkgZG9uJ3Qga25vdywgZGlkIHdlIGV2ZXIgZGVjaWRlIHdoZXRoZXIgdGhlIFVzZSBj YXNlcyBkb2MgaXMgcmVzdHJpY3RlZCB0byAmcXVvdDtpbml0aWFsJnF1b3Q7DQogc2NlbmFyaW9z LCBvciB3aGV0aGVyIGl0J3MgYWxsLWVuY29tcGFzc2luZywgaWUgY292ZXJpbmcgJnF1b3Q7ZnV0 dXJlJnF1b3Q7IHNjZW5hcmlvcyBhcyB3ZWxsPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5TY290dCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlYWRpbmcg c29tZSBvZiB5b3VyIGV4YW1wbGVzLCB0aGV5IHNlZW0gdG8gYmUgdmFsaWQgZXZlbiBpZiBjb250 ZW50IGFkYXB0YXRpb24gKEhEL1NEKSBpcyBvdXQgb2Ygc2NvcGUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIGEgZENETiBtaWdodCBmb3Igc29tZSByZWFzb24gYmUg dW53aWxsaW5nIHRvIGRpc3RyaWJ1dGUgSEQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4tIGEgQ1NQIG1pZ2h0IHdhbnQgdG8gbWFrZSBzdXJlIHRoZSBkQ0ROIGNhbiB1 c2UgSExTIGVuY2Fwc3VsYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5CdXQgdGhlc2Ugc29ydHMgb2YgZXhhbXBsZXMgc2VlbSB0byBiZSBzdGF0aWMgcG9saWN5 IHRoaW5ncyAodG8gZG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPndp dGggdGhlIGNhcGFiaWxpdGllcyAmYW1wOyBwcmVmZXJlbmNlcyBvZiB0aGUgQ0ROcyAmYW1wOyBD U1ApLCByYXRoZXIgdGhhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ bWV0YWRhdGEgYXNzb2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBwaWVjZSBvZiBjb250ZW50LiBJ biB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmRpc2N1c3Npb24g c28gZmFyLCBJIHRoaW5rIG5lZ290aWF0aW9uIGFib3V0IHN0YXRpYyBwb2xpY3kgc3R1ZmYgaXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJhdGhlciBvdXQgb2Ygc2Nv cGUoPyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMsIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdHJ1c3QgaXMgdHJhbnNp dGl2ZS4gRG9uJ3QgdGhpbmsgaXQgbmVlZCBiZSAtIGp1c3QgYmVjYXVzZSBDU1AgdHJ1c3RzIHVD RE4sIGFuZCB1Q0ROIHRydXN0cyBkQ0ROIGRvZXNuJ3QgbWVhbiB0aGF0IHRoZSBDU1AgYXV0b21h dGljYWxseSB0cnVzdHMgdGhlIGRDRE4uDQogSG93ZXZlciwgaSBzdXNwZWN0IHRoaXMgY2FuIGdl dCBhcmJpdHJhcmlseSBjb21wbGV4IC0gc28gb25lIHBvc3NpYmlsaXR5IGlzIHRvIHNheSB0aGF0 IHdlIHdpbGwgb25seSBoYW5kbGUgY2FzZXMgd2hlcmUgdGhlIHRydXN0IGlzIHRyYW5zaXRpdmUu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3Qgd2lzaGVzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5waGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UGhpbGlw IEVhcmRsZXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlc2VhcmNo IGFuZCBUZWNobm9sb2d5IFN0cmF0ZWd5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo aXMgZW1haWwgY29udGFpbnMgQlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBiZSBwcml2aWxlZ2Vk IG9yIGNvbmZpZGVudGlhbC4gSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbChzKSBv ciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlvdSdyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZw0KIG9yIHVzaW5n IHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVseSBvbiB0aGUgZW1h aWwgYWRkcmVzcyBhYm92ZS4gVGhhbmsgeW91LiBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0s IGFuZCBtYXkgcmVjb3JkIHlvdXIgZW1haWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+QnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBT dHJlZXQgTG9uZG9uIEVDMUEgN0FKIFJlZ2lzdGVyZWQgaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkVuZ2xhbmQgbm86IDE4MDAwMDA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+RnJvbTogPGEgaHJlZj0ibWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZyI+ DQpjZG5pLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9mIEJl biBOaXZlbi1KZW5raW5zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5T ZW50OiAxMCBPY3RvYmVyIDIwMTEgMTI6MDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRvOiBaaG91WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Q2M6IDxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U3ViamVjdDogUmU6 IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Db2xsZWFndWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5JTU8gU2VjdGlvbiA1LjEuMyBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBV c2UgQ2FzZXMgZHJhZnQuIENvbnRlbnQgQWRhcHRhdGlvbiAoaS5lLiB0YWtpbmcgaW4gYSBjb250 ZW50IGl0ZW0gaW4gb25lIGZvcm1hdCBhbmQgdHJhbnNmb3JtaW5nIGl0IHRvIGFub3RoZXIgZm9y bWF0IG9yIHJlcHJlc2VudGF0aW9uKSBpcyBub3QgYSAmcXVvdDtjb3JlJnF1b3Q7IGZ1bmN0aW9u IG9mIGEgQ0RODQogd2hpY2ggdHlwaWNhbGx5IGRlbGl2ZXJzIHRoZSBjb250ZW50IHRoYXQgaXMg cmVxdWVzdGVkIHdpdGhvdXQgZXhwbGljaXQga25vd2xlZGdlIG9mIHdoYXQgdGhhdCBjb250ZW50 IGFjdHVhbGx5IGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5MZXQncyBub3QgZm9y Z2V0IHRoYXQgaW4gYnVpbGRpbmcgYW4gZW5kIHRvIGVuZCBjb250ZW50IHNlcnZpY2UgdGhlIENE TiBpcyBvbmx5IG9uZSBjb21wb25lbnQgYW5kIGlzIHRoZSBjb21wb25lbnQgdGFza2VkIHdpdGgg ZXhlY3V0aW5nIHRoZSBkZWxpdmVyeSBvZiBhIHNwZWNpZmljIHJlcHJlc2VudGF0aW9uICh2ZXJz aW9uL2NvcHkvZm9ybWF0IGV0Yy4pIG9mIHRoZSBzZWxlY3RlZA0KIGNvbnRlbnQgbm90IHRoZSBj b21wb25lbnQgdGFza2VkIHdpdGggZGVjaWRpbmcgKG9yIGFwcGx5aW5nIHBvbGljeSkgb24gd2hp Y2ggdmVyc2lvbi9jb3B5L3JlcHJlc2VudGF0aW9uIG9mIGNvbnRlbnQgc2hvdWxkIGJlIGRlbGl2 ZXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGRlY2lzaW9uIGFzIHRvIHdo aWNoIHZlcnNpb24vY29weS9yZXByZXNlbnRhdGlvbiB0byBvZmZlciBhbmQgYWxsb3cgdG8gYmUg ZGVsaXZlcmVkIHRvIGEgZ2l2ZW4gZGV2aWNlL3VzZXIgaXMgaW1wbGVtZW50ZWQgb3V0c2lkZSBv ZiB0aGUgQ0ROIChlLmcuIGJ5IHRoZSAmcXVvdDtwb3J0YWwmcXVvdDsgd2hlcmUgdGhlIHVzZXIg Zmlyc3QgbWFrZXMgdGhlaXIgY29udGVudCBzZWxlY3Rpb24NCiBwcmlvciB0byB0aGUgQ0ROIGJl Y29taW5nIGludm9sdmVkIGluIHRoZSBkZWxpdmVyeSBvZiB0aGUgc2VsZWN0ZWQgY29udGVudCku PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5PbiA4IE9jdCAyMDExLCBhdCAwODoyMCwgWmhvdVpoaXBlbmcgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9sbG93aW5nIFNjb3R0J3MgY29tbWVudHMgb24g c2VjdGlvbiA1LjEuMywgSSBmZWVsIFNjb3R0J3MgZGVzY3JpcHRpb24gb24gdGhlIHVzZSBjYXNl IG9mIEhEIGFuZCBTRCBpcyBub3QgZXhhY3RseSBjb3JyZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiBvbmUgbW92aWUgaGFzIHR3 byBmb3JtYXRzIG9mIEhEIGFuZCBTRCwgdGhlbiB3ZSBoYXZlIHR3byBjb250ZW50IHdpdGggZGlm ZmVyZW50IGlkZW50aWZpZXIuIEluIERSTSBzY29wZSwgdGhlIGJhc2ljIHVuaXQgaXMgYSBjb250 ZW50IGNvcHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5IZXJlIHRoZSBmaXJzdCBidWxsZXQgJnF1b3Q7YSBzdWJzZXQgb2Yg ZW5jb2RpbmdzIGRlbGl2ZXJhYmxlIHRvIHNwZWNpZmljIGRldmljZXMsJnF1b3Q7IGhhcyBsaXN0 ZWQgdGhlIGNhc2Ugb2YgY29udGVudCBhZGFwdGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBsYXN0IG1vbnRoLCBJIGhhdmUg Y29udGFjdGVkIHRoZSBBdXRob3JzIG9mIHRoaXMgZG9jdW1lbnQgYW5kIHRha2VuIHNvbWUgZW1h aWwgZXhjaGFuZ2VzIHdpdGggR3JhbnQgYW5kIFBoaWxpcCAoQlQpLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGhhdmUgc2hvd24gQlQg d2l0aCBzb21lIGluZm9ybWF0aW9uIHRoYXQgSSBrbm93IGluIHRoaXMgY2FzZSBhbmQgYXJlYSB0 byBleHBsYWluIHRoZSBjb250ZW50IGZsZXhpYmlsaXR5IGlzIGN1cnJlbnRseSBhIGJhc2ljIHJl cXVpcmVtZW50IGZvciBDRE4gc2VydmljZSBhbmQgcmVsYXRlZCBuZWdvdGlhdGlvbiBpcyBuZWVk ZWQgaW4gdGhlIENETiBpbnRlcmNvbm5lY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk1lYW53aGlsZSwgSSBzaG91bGQgYWxzbyBp bnZpdGUgeW91IGluIHRoaXMgZ3JvdXAgcmFpc2luZyB5b3VyIGNvbW1lbnRzIG9yIHF1ZXN0aW9u cyBvbiB0aGlzIGNhc2Ugc2luY2UgSSBob3BlIG15IHVzZSBjYXNlIG1heSBiZSBpbmNvcnBvcmF0 ZWQgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgeW91IGhhdmUgYW55IG1vcmUgcXVl c3Rpb24gb3IgY29tbWVudHMsIHBscyBzaGFyZSBpbiB0aGlzIHRocmVhZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5aaGlw ZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkZyb206IFNjb3R0IFdhaW5uZXIgW21haWx0bzpzd2Fpbm5lckBjaXNj by5jb21dPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDMwLCAyMDExIDg6MDIgQU08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VG86IDxhIGhy ZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJqZWN0OiBSZTog W0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5TZWN0aW9uIDIuMyBOb21hZGljIFVzZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgZGVzY3JpcHRpb24gZmFsbHMgdW5kZXIg dGhlIGNhdGVnb3J5IG9mIEdlb2dyYXBoaWMgRXh0ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnlldCB0aGUgdGhpcmQgcGFyYWdy YXBoIHN0YXRlcyB0aGUgY2FzZSB3aGVyZSBhIGRpZmZlcmVudCBkZXZpY2UgaXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dXNlZCBpbiB0 aGUgc2FtZSBDRE4gY292ZXJhZ2UgYXJlYS4gJm5ic3A7VGhlIGludGVudCBvZiB0aGlzIHVzZSBj YXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPm5lZWRzIHRvIGJlIGNsYXJpZmllZC4gJm5ic3A7UGVyaGFwcyB0aGUgdXNlIGNhc2UgaXMg dHJ5aW5nIHRvIGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+dGhlIHNjZW5hcmlvIHdoZXJlIGEgTm9tYWRpYyBVc2VyLUEgd2l0 aCBhbiBhZ3JlZW1lbnQgYWxsb3dpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YWNjZXNzIHRvIGNvbnRlbnQgZnJvbSBDU1AtQSB2aWEg dUNETiBtb3ZlcyB0byBhIGRDRE4gaW4gYSBkaWZmZXJlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cmVnaW9uLiAmbmJzcDtUaGUgZENE TiBpcyBhbGxvd2VkIHRvIGRpc3RyaWJ1dGUgdGhlIGNvbnRlbnQgb2YgQ1NQLUEgdG88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VXNlci1B OyBob3dldmVyLCBub3Qgb3RoZXIgdXNlcnMgaW4gdGhlIHJlZ2lvbiBvZiB0aGUgZENETiBhcmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ YWxsb3dlZCB0byByZXRyaWV2ZSB0aGUgY29udGVudCB1bmxlc3MgdGhleSB0b28gaGF2ZSBzdWNo IGFuIGFncmVlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlY3Rpb24gNS4xLjMgQ29udGVudCBFbmNvZGluZyBSZXN0 cmljdGlvbnMgTmVlZCB0byBjbGFyaWZ5IGlmIHdlJ3JlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRhbGtpbmcgYWJvdXQgdGhlIHJlc3Ry aWN0aW9ucyBvbiB0aGUgZGVsaXZlcnkgb2Ygc3BlY2lmaWMgY29udGVudDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vciB0aGUgcmVzdHJp Y3Rpb25zIG9uIHRoZSBhYmlsaXR5IG9mIGEgQ0ROIHRvIGRlbGl2ZXIgc3BlY2lmaWM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Y29udGVu dC4gJm5ic3A7SSBjZXJ0YWlubHkgdW5kZXJzdGFuZCB0aGUgY2FzZSB3aGVyZSBhIENTUCB3aWxs IHJlc3RyaWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPnRoZSBkaXN0cmlidXRpb24gb2YgY29udGVudCB0byBhICZxdW90O21hbmFnZWQg cGF0aCZxdW90OyBpZiBzdWNoIGNvbnRlbnQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SEQgd2hpbGUgYWxsb3dpbmcgdGhlIGNvbnRl bnQgZGlzdHJpYnV0aW9uIHZpYSBhbiB1bi1tYW5hZ2VkIHBhdGggaWY8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+c3VjaCBjb250ZW50IGlz IFNEIChzYW1lIGNvdWxkIGFwcGx5IHRvIGVuY3J5cHRpb24gbWV0aG9kcywgZGVsaXZlcnk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+bWV0 aG9kcywgZXRjLikuICZuYnNwO09uIHRoZSBjb250cmFyeSwgdGhlIGRDRE4gbWF5IGhhdmUgaXRz IG93bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5yZXN0cmljdGlvbnMgb2YgYmxvY2tpbmcgdGhlIGRpc3RyaWJ1dGlvbiBvZiBIRCBjb250 ZW50IHdoaWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPmFsbG93aW5nIHRoZSBkaXN0cmlidXRpb24gb2YgU0QgY29udGVudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pm8gZmlyc3QgYnVsbGV0IG1ha2VzIHNlbnNlIGlmIHRoZSBkQ0ROIGNhbiBwZXJmb3JtIGEgc3Vi c2V0IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPmVuY2Fwc3VsYXRpb25zIGZvciBhIHJlZmVyZW5jZSBzZXQgb2YgbWVkaWEgKGUuZy4g SExTLCBIU1MsIGJ1dCBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+REFTSCkgbyBzZWNvbmQgYnVsbGV0IG1ha2VzIHNlbnNlIHdoZXJl IHRoZSBkQ0ROIGRvZXNuJ3Qgd2FudCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vZmZlciBoaWdoIGJpdC1yYXRlIHZhcmlhbnRzIG9m IHRoZSBtZWRpYSBvIHRoaXJkIGJ1bGxldCBtYWtlIHNlbnNlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmlmIHRoZSBwb2xpY3kgYWRkcmVz c2VzIFFvRSBidXQgSSBkb24ndCB0aGluayBzdWJzY3JpYmVyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJpZ2h0cy9hdXRob3JpemF0aW9u cyBhcHBseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlNlY3Rpb24gMTAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkFzaWRlIGZyb20gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIFdJVEhJTiB0aGUgdUNETiBh bmQgZENETiwgSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj50aGluayB3ZSBjYW4gZGVzY3JpYmUgdGhpcyBpbiBmb3VyIGNvbnRleHRzOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+YS4gVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBDU1AgYW5kIHRoZSB1Q0ROICh0 aGUgcHJpbmNpcGxlIGNvbnRyYWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFycmFuZ2VtZW50IGZvciBkaXN0cmlidXRpb24pPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmIuIFRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdUNETiBhbmQgZENETiAodGhlIHRyYW5zaXRpdmUg dHJ1c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+cmVsYXRpb25zaGlwIHRoYXQgZXh0ZW5kcyB0aGUgY29udHJhY3QgZGVmaW5lZCBpbiAo YSkgYWJvdmUpIGMuIFRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5yZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgVXNlciBhbmQgZENETiAo dGhlIHJlY29nbml0aW9uIG9mIHJpZ2h0IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmRvd25sb2FkIHByZWRpY2F0ZWQgb24gKGIpIGFi b3ZlKSBkLiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlVzZXIgYW5kIENTUCAodGhlIGNv bnRyYWN0IGF1dGhvcml6aW5nIHRoZSB1c2VyIGFjY2VzcyB0byB0aGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Y29udGVudCk8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlRoZSB1c2VyIGlzIG5vdCBpbnRlcmVzdGVkIGluIHRoZSBhLWIgbm9yIHRoZSBiLWMgcmVsYXRp b25zaGlwLiBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+dXNlciBpcyBvbmx5IGludGVyZXN0ZWQgaW4gdGhlIHRyYW5zcGFyZW5jeSBh bmQgaW50ZXJvcGVyYWJpbGl0eSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50aGUgc2VjdXJpdHkgcmVsYXRpb25zaGlwIGJldHdlZW4g ZC1iIG9yIGQtYyB0byB0aGUgcG9pbnQgdGhhdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YXV0aG9yaXphdGlvbiBncmFudGVkIGlu IGQtYSBpcyB2aWFibGUgd2hlbiB0aGUgZGVsaXZlcnkgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+aW5pdGlhdGVkIHZpYSBlaXRoZXIg ZC1iIG9yIGQtYy4gJm5ic3A7QXMgYW4gZXhhbXBsZSwgdGhlIHVDRE4gbWlnaHQgdXNlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlVSTCBh cHBlbmRlZCB0b2tlbnMgZm9yIGF1dGhlbnRpY2F0aW9uIHdoaWxlIGRDRE4gbWlnaHQgdXNlIFVS TDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5hcHBlbmRlZCBoYXNoZXMuICZuYnNwO1RoZSB1c2VyIGRvZXNuJ3Qgd2FudCB0byBrbm93IGFi b3V0IHRoZSBkaXN0aW5jdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5tZXRob2RzLCBidXQgdHJhbnNwYXJlbmN5IGlzIG9ubHkgYWZmb3Jk ZWQgaWYgdGhlIG1ldGhvZHMgYXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPmludGVyb3BlcmFibGUgY2xlYXJseSBkZWZpbmVkIHdoZW4g dGhlIGRlbGVnYXRpb24gZm9yIGNvbnRlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ZGVsaXZlcnkgaXMgZXhlY3V0ZWQuICZuYnNwO0Ns ZWFybHksIHRoZSBjaG9pY2Ugb2YgYXV0aGVudGljYXRpb24gbWV0aG9kIGlzIGRldGVybWluZWQg YnkgdGhlIHJlc3BlY3RpdmUgQ0ROJ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TY290dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q0ROaSBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0ibWFpbHRvOkNETmlAaWV0Zi5vcmciPkNETmlAaWV0Zi5vcmc8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q0ROaSBt YWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhy ZWY9Im1haWx0bzpDRE5pQGlldGYub3JnIj5DRE5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZG5pIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Nkbmk8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDRE5p IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDRE5pQGlldGYub3JnIj5DRE5pQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pPC9h Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KQ0ROaSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q0ROaUBpZXRmLm9yZyI+ Q0ROaUBpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Nkbmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1CA25301D2219F40B3AA37201F0EACD1136C1D7DPACDCEXMB05cabl_-- From richard_woundy@cable.comcast.com Thu Oct 27 06:01:40 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201F021F8663 for ; Thu, 27 Oct 2011 06:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.402 X-Spam-Level: X-Spam-Status: No, score=-101.402 tagged_above=-999 required=5 tests=[AWL=-1.467, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_21=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pY3t9qCutib6 for ; Thu, 27 Oct 2011 06:01:38 -0700 (PDT) Received: from cable.comcast.com (copdcimo01.potomac.co.ndcwest.comcast.net [76.96.32.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9596B21F863E for ; Thu, 27 Oct 2011 06:01:38 -0700 (PDT) Received: from ([24.40.55.41]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.58917520; Thu, 27 Oct 2011 07:08:54 -0600 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB02.cable.comcast.com ([fe80::11d4:f530:37a0:9f4e%11]) with mapi id 14.01.0339.001; Thu, 27 Oct 2011 09:01:23 -0400 From: "Woundy, Richard" To: Alan Kavanagh , ZhouZhipeng , Ben Niven-Jenkins Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMf6O2gfGmi71uTyS4A0eFwyx965VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAWs+DggAErLoA= Date: Thu, 27 Oct 2011 13:01:21 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136C1FBC@PACDCEXMB05.cable.comcast.com> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BADD@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D5170F26BADD@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.96.111.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 13:01:40 -0000 > To me a core functionality of CDN's as Ben et.al has pointed out is to re= duce cost, sending 1 stream as opposed to 10 streams is definitely a core r= equirement and a core use case for CDN-I too. Maybe. The counter-argument is, do I have to spend much more on surrogates = / edge nodes to enable transcoding + fragmentation + encryption? Does that = additional cost offset the incremental network savings? -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ala= n Kavanagh Sent: Wednesday, October 26, 2011 3:12 PM To: ZhouZhipeng; Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Zhou Slowly catching up on all these CDN-I emails :-) I fully agree with your assertion here, I had the same puzzlement when read= ing the use cases and looking at the lat few "hundred plus" emails on this. To me a core functionality of CDN's as Ben et.al has pointed out is to redu= ce cost, sending 1 stream as opposed to 10 streams is definitely a core req= uirement and a core use case for CDN-I too. Somewhat orthogonal to the use cases, but a case I feel is missing from the= current metadata drafts I have read is to define this case of supporting t= ranscoding for CDN-I. It makes perfect sense that CDN-I must support this s= cenario so that CDN's leverage on cost reduction by supporting transcoding. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Zho= uZhipeng Sent: October-12-11 5:23 AM To: Ben Niven-Jenkins Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hello Ben, The UE may select the content format on the CP web. After that the user onl= y desires to get his selected content. But how the content is transferred to the client is not worried by the user= . The CP may create a special format as required by the user and ask the CDN = to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transfo= rm to the format as the user select. In this case, it is nothing related to how the user select formats on CP we= bsite. So, it is the CP and user to decide the content format not the CDN(your ass= ert is not correct and seems you take that assert as your base for the disc= ussion). As for "the core CDN functionality offered by CDNs today", I have ever rais= ed an email before that your company's webpage has claimed supporting media= transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core fu= nctionalities by existing main stream CDNs. Thus we may compare and take de= ep look. I guess many people have the experience/knowledge of content related servic= e. The user and CP only care whether the CDN providers may satisfy their re= quirement while not care the internal process. Just as GSM/PSTN interconnec= tion, the user only care successful interconnection while not care how the = voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media format= s. One candidate is your company, another is CDN-X. The users are located in F= rance. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one= content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y whil= e CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the c= ost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in s= olution-2, it should only receive 1 stream but need to take transformation = to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the p= rice from BBC is same to both your company and CDN-X or BBC would select on= e CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is no= t a core functionality. So, if we all realize that currently the media type is rich, the CDN provid= ers should survive in the existing ecosystem and support the media types as= required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection,= the transformation should at once be solved. Otherwise the interconnection= may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > Ben and Philip, > I like to respond your concern in this one email: > > Ben, > I feel what we are now discussing is what is the "core" function of CDN. > As you say, CDN is used to deliver content. That is absolutely correct th= at the delivery capability is the core requirement for CDN system. > While CDN is used to provide the content delivery service. > What means service. It should include "time" "location" and "media type",= etc. These features are all the core feature for a service. > If we only concern "delivering one data block", I am not sure whether the= issues such as "logging" "geographic constraint" are the core of CDN. > > For "without explicit knowledge of what that content actually is ", I am = not sure whether the wording is accurate since generally a CDN may claim it= support different medias. > By this opportunity, I like to share a use case: a call from a GSM phone = to a PSTN telephone, the voice stream should be transformed from GSM voice = to G.711. > For the user, he does not need to know what type of data has been transfe= rred, but the operator has done some work to interconnect two systems, righ= t. > I like to know whether you may accept that my use case is similar to this= case above. I don't think your use case is similar to the analogy of mobile networks be= ing interconnected to PSTN networks. In the case of content delivery the ne= gotiation is done between the User/Client and the Content Provider and the = CDN is just used to execute/perform the delivery that has been negotiated. = The CDN is not involved in the decision making of what representations the = Content Provider decides to offer to the User/Client or in what representat= ions the User/Client decides to request. > As for you said selecting media by the "portal", you may see the way " uC= DN delivers multiple media streams to dCDN" is not good than "uCDN delivers= one media stream to dCDN and dCDN takes some adaptation to support multipl= e media types". Now what you're talking about is an optimisation, not a core function requi= red to actually deliver the content (and report, bill, etc. for that delive= ry). My position is that we should focus on how to enable the interconnection of= the core CDN functionality offered by CDNs today (which is also my interpr= etation of the scope of the CDNI working group as expressed in its charter)= because doing so is a significant piece of work in itself. Let's not start= trying to add in additional functionality beyond what the majority of CDNs= support today as that will just delay us getting usable specifications int= o the market in a timely fashion IMO. Ben > A good question is "security" since I have done six years on the DRM > and like to promote the DRM all around the world:) If the content is need= ed to be protected, generally you may know all the systems should be grante= d by the content owner. > Here I also like to clarify that not only the media itself but the inform= ation related to service itself (such as the geographic constraint) should = be protected also. > So, trust is not a problem for the media. > > Philip, > Thank you that you feel Content Adaption is an issue for "Requirements" b= ut I do not know why it is not for Use case. > I like to clarify to U that it is important for you operator since it may= save investment if the system may support different services. > For us vendor, we are happy operator may install a system for the mobile = service and another system for the FBB service. > But the reality is all operators ask us to provide a system that may supp= ort different service systems. > > Frankly, Ben and Philip, I remember I have explained somewhere that to im= plement this is rather simple . > At least the Use case and Requirement are informational to be referred in= future work. So I do really feel you may accept it. > Of course I like to respond your more concern and comments. > Thanks. > Zhipeng > > > > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Monday, October 10, 2011 11:22 PM > To: ben@niven-jenkins.co.uk; ZhouZhipeng > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Ben, Zhipeng, all, > > I think that Content Adaptation is more an issue for the Requirements doc= than for the Use cases draft. > > The key question is whether we want the CDNI interfaces to be able to cop= e with a scenario where (say) HD/SD conversion is done in the dCDN & to sig= nal about this. > > I think that coping with this scenario is a second order requirement, ie = we should not worry about it in the initial standards-track work. I don't k= now, did we ever decide whether the Use cases doc is restricted to "initial= " scenarios, or whether it's all-encompassing, ie covering "future" scenari= os as well? > > Scott, > Reading some of your examples, they seem to be valid even if content adap= tation (HD/SD) is out of scope. > - a dCDN might for some reason be unwilling to distribute HD? > - a CSP might want to make sure the dCDN can use HLS encapsulation? > But these sorts of examples seem to be static policy things (to do > with the capabilities & preferences of the CDNs & CSP), rather than > metadata associated with a particular piece of content. In the > discussion so far, I think negotiation about static policy stuff is > rather out of scope(?) > > On security considerations, an interesting question is whether trust is t= ransitive. Don't think it need be - just because CSP trusts uCDN, and uCDN = trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. Howeve= r, i suspect this can get arbitrarily complex - so one possibility is to sa= y that we will only handle cases where the trust is transitive. > > Best wishes > phil > > > Philip Eardley > Research and Technology Strategy > > This email contains BT information, which may be privileged or confidenti= al. It's meant only for the individual(s) or entity named above. If you're = not the intended recipient, note that disclosing, copying, distributing or = using this information is prohibited. If you've received this email in erro= r, please let me know immediately on the email address above. Thank you. We= monitor our email system, and may record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ Registered in > England no: 1800000 > > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: 10 October 2011 12:04 > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Colleagues, > > IMO Section 5.1.3 should be removed from the Use Cases draft. Content Ada= ptation (i.e. taking in a content item in one format and transforming it to= another format or representation) is not a "core" function of a CDN which = typically delivers the content that is requested without explicit knowledge= of what that content actually is. > > Let's not forget that in building an end to end content service the CDN i= s only one component and is the component tasked with executing the deliver= y of a specific representation (version/copy/format etc.) of the selected c= ontent not the component tasked with deciding (or applying policy) on which= version/copy/representation of content should be delivered. > > The decision as to which version/copy/representation to offer and allow t= o be delivered to a given device/user is implemented outside of the CDN (e.= g. by the "portal" where the user first makes their content selection prior= to the CDN becoming involved in the delivery of the selected content). > > Ben > > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > >> Following Scott's comments on section 5.1.3, I feel Scott's description = on the use case of HD and SD is not exactly correct. >> If one movie has two formats of HD and SD, then we have two content with= different identifier. In DRM scope, the basic unit is a content copy. >> >> Here the first bullet "a subset of encodings deliverable to specific dev= ices," has listed the case of content adaptation. >> In last month, I have contacted the Authors of this document and taken s= ome email exchanges with Grant and Philip (BT). >> I have shown BT with some information that I know in this case and area = to explain the content flexibility is currently a basic requirement for CDN= service and related negotiation is needed in the CDN interconnection. >> Meanwhile, I should also invite you in this group raising your comments = or questions on this case since I hope my use case may be incorporated in t= he use case draft. >> >> If you have any more question or comments, pls share in this thread. >> Thanks. >> Zhipeng >> >> >> >> >> >> >> -----Original Message----- >> From: Scott Wainner [mailto:swainner@cisco.com] >> Sent: Friday, September 30, 2011 8:02 AM >> To: cdni@ietf.org >> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >> >> Section 2.3 Nomadic Users >> This description falls under the category of Geographic Extension >> yet the third paragraph states the case where a different device is >> used in the same CDN coverage area. The intent of this use case >> needs to be clarified. Perhaps the use case is trying to address the >> scenario where a Nomadic User-A with an agreement allowing access to >> content from CSP-A via uCDN moves to a dCDN in a different region. >> The dCDN is allowed to distribute the content of CSP-A to User-A; >> however, not other users in the region of the dCDN are allowed to >> retrieve the content unless they too have such an agreement. >> >> Section 5.1.3 Content Encoding Restrictions Need to clarify if we're >> talking about the restrictions on the delivery of specific content or >> the restrictions on the ability of a CDN to deliver specific content. >> I certainly understand the case where a CSP will restrict the >> distribution of content to a "managed path" if such content is HD >> while allowing the content distribution via an un-managed path if >> such content is SD (same could apply to encryption methods, delivery >> methods, etc.). On the contrary, the dCDN may have its own >> restrictions of blocking the distribution of HD content while >> allowing the distribution of SD content. >> >> o first bullet makes sense if the dCDN can perform a subset of >> encapsulations for a reference set of media (e.g. HLS, HSS, but not >> DASH) o second bullet makes sense where the dCDN doesn't want to >> offer high bit-rate variants of the media o third bullet make sense >> if the policy addresses QoE but I don't think subscriber >> rights/authorizations apply. >> >> Section 10 Security Considerations >> >> Aside from the security considerations WITHIN the uCDN and dCDN, I >> think we can describe this in four contexts: >> >> a. The relationship between the CSP and the uCDN (the principle contract >> arrangement for distribution) >> b. The relationship between the uCDN and dCDN (the transitive trust >> relationship that extends the contract defined in (a) above) c. The >> relationship between the User and dCDN (the recognition of right to >> download predicated on (b) above) d. The relationship between the >> User and CSP (the contract authorizing the user access to the >> content) >> >> The user is not interested in the a-b nor the b-c relationship. The >> user is only interested in the transparency and interoperability of >> the security relationship between d-b or d-c to the point that the >> authorization granted in d-a is viable when the delivery is initiated >> via either d-b or d-c. As an example, the uCDN might use URL >> appended tokens for authentication while dCDN might use URL appended >> hashes. The user doesn't want to know about the distinct methods, >> but transparency is only afforded if the methods are interoperable >> clearly defined when the delegation for content delivery is executed. >> Clearly, the choice of authentication method is determined by the respec= tive CDN's. >> >> Scott >> >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From alan.kavanagh@ericsson.com Thu Oct 27 06:10:29 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9055421F8B17 for ; Thu, 27 Oct 2011 06:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.473 X-Spam-Level: X-Spam-Status: No, score=-5.473 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL53d6kDpmzl for ; Thu, 27 Oct 2011 06:10:26 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 31E5221F8B16 for ; Thu, 27 Oct 2011 06:10:26 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p9RD9uHX030710; Thu, 27 Oct 2011 08:10:01 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.232]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 27 Oct 2011 09:09:58 -0400 From: Alan Kavanagh To: Mark de Jong Date: Thu, 27 Oct 2011 09:09:56 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyUHO2ngxC8x2J+Rdy1pRXtzqLx1gAjMI5w Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D5170F2D66F3@EUSAACMS0701.eamcs.ericsson.se> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com> <4E8506FC.1020701@cisco.com> <260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com> <853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk> <9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net> <260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com> <1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com> <166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1B6D0317D3AD964FBF3956DEFA3524D5170F2D66F3EUSAACMS0701e_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 13:10:29 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D5170F2D66F3EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mark So are we defining a limited set of use cases or should we ensure that use = cases at the very least ensure that the realistic use cases both deployed t= oday and ones planed are captured in the use cases document? Alan ________________________________ From: Mark de Jong [mailto:mark@jet-stream.nl] Sent: October-26-11 4:21 PM To: Alan Kavanagh Cc: Ben Niven-Jenkins; ZhouZhipeng; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Alan, As Ben stated the overall discussion right now is about delivery, not on ad= aptation. It is hard enough to get consensus on the delivery aspect already= not to mention your requirement from content adaptation added to that, so = I agree with Ben we should stick with the delivery aspect for the first spe= cs. I can imagine this could be a discussion later on but please let us kee= p the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to have= it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs= ' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: Ben Im assuming then based on your comments below are you suggesting we are goi= ng to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that there i= s some work to be done, but I still feel that content adaptation is to me a= fundamental requirement to what collectively we should address in the CDN-= I WG. I do agree with you that content adaptation is an optimization betwee= n CDN's but it's a very important one that I know Network Service Providers= particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: Hello Ben, The UE may select the content format on the CP web. After that the user onl= y desires to get his selected content. But how the content is transferred to the client is not worried by the user= . The CP may create a special format as required by the user and ask the CDN = to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transfo= rm to the format as the user select. Lots of things may be possible to do and CDN providers offer many additiona= l services on top of the "core" service of content delivery. However, our o= bjective (based on my interpretation of the CDNI charter) is to focus on wh= at is necessary to interconnect CDNs to deliver content from a CSP to an En= d User that is targeted and deployable within a short time frame (18-24 mon= ths). Content transformation/adaptation is not an essential requirement in order = to achieve that aim (we can deliver content from CSPs to End Users via mult= iple CDNs without needing or requiring any CDN supports content adaptation)= . In my opinion we have enough work to do already without trying to expand th= e scope of our work to include additional requirements that do not help us = address our core objectives as laid out in the CDNI charter. In this case, it is nothing related to how the user select formats on CP we= bsite. So, it is the CP and user to decide the content format not the CDN(your ass= ert is not correct and seems you take that assert as your base for the disc= ussion). As for "the core CDN functionality offered by CDNs today", I have ever rais= ed an email before that your company's webpage has claimed supporting media= transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core fu= nctionalities by existing main stream CDNs. Thus we may compare and take de= ep look. I think the core functionality maps pretty well to the CDNI interfaces, nam= ely: Request Routing, Metadata configuration, log production and control pl= us content acquisition and content delivery. I guess many people have the experience/knowledge of content related servic= e. The user and CP only care whether the CDN providers may satisfy their re= quirement while not care the internal process. Just as GSM/PSTN interconnec= tion, the user only care successful interconnection while not care how the = voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media format= s. One candidate is your company, another is CDN-X. The users are located in F= rance. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-= Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the c= ost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in s= olution-2, it should only receive 1 stream but need to take transformation = to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the p= rice from BBC is same to both your company and CDN-X or BBC would select on= e CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is no= t a core functionality. What you are describing is a possible optimization that a particular CDN ma= y wish to implement not a core functionality required to enable content del= ivery between interconnected CDNs. I can think of many optimizations that a= CDN could implement to differentiate their service but the internal workin= gs of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core= function required to enable content delivery between interconnected CDNs a= nd therefore given the workload we already have to specify solutions that d= o address the core functionality required to interconnect CDNs I do not thi= nk we should be trying to add more work into that workload as it will only = distract us from achieving our goal of producing deployable solutions withi= n the timeframe we are being told by operators they needs solutions within. Ben So, if we all realize that currently the media type is rich, the CDN provid= ers should survive in the existing ecosystem and support the media types as= required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection,= the transformation should at once be solved. Otherwise the interconnection= may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: Ben and Philip, I like to respond your concern in this one email: Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct that= the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media type", e= tc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether the i= ssues such as "logging" "geographic constraint" are the core of CDN. For "without explicit knowledge of what that content actually is ", I am no= t sure whether the wording is accurate since generally a CDN may claim it s= upport different medias. By this opportunity, I like to share a use case: a call from a GSM phone to= a PSTN telephone, the voice stream should be transformed from GSM voice to= G.711. For the user, he does not need to know what type of data has been transferr= ed, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to this c= ase above. I don't think your use case is similar to the analogy of mobile networks be= ing interconnected to PSTN networks. In the case of content delivery the ne= gotiation is done between the User/Client and the Content Provider and the = CDN is just used to execute/perform the delivery that has been negotiated. = The CDN is not involved in the decision making of what representations the = Content Provider decides to offer to the User/Client or in what representat= ions the User/Client decides to request. As for you said selecting media by the "portal", you may see the way " uCDN= delivers multiple media streams to dCDN" is not good than "uCDN delivers o= ne media stream to dCDN and dCDN takes some adaptation to support multiple = media types". Now what you're talking about is an optimisation, not a core function requi= red to actually deliver the content (and report, bill, etc. for that delive= ry). My position is that we should focus on how to enable the interconnection of= the core CDN functionality offered by CDNs today (which is also my interpr= etation of the scope of the CDNI working group as expressed in its charter)= because doing so is a significant piece of work in itself. Let's not start= trying to add in additional functionality beyond what the majority of CDNs= support today as that will just delay us getting usable specifications int= o the market in a timely fashion IMO. Ben A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) If the content is needed= to be protected, generally you may know all the systems should be granted = by the content owner. Here I also like to clarify that not only the media itself but the informat= ion related to service itself (such as the geographic constraint) should be= protected also. So, trust is not a problem for the media. Philip, Thank you that you feel Content Adaption is an issue for "Requirements" but= I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it may s= ave investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile se= rvice and another system for the FBB service. But the reality is all operators ask us to provide a system that may suppor= t different service systems. Frankly, Ben and Philip, I remember I have explained somewhere that to impl= ement this is rather simple . At least the Use case and Requirement are informational to be referred in f= uture work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng -----Original Message----- From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ben, Zhipeng, all, I think that Content Adaptation is more an issue for the Requirements doc t= han for the Use cases draft. The key question is whether we want the CDNI interfaces to be able to cope = with a scenario where (say) HD/SD conversion is done in the dCDN & to signa= l about this. I think that coping with this scenario is a second order requirement, ie we= should not worry about it in the initial standards-track work. I don't kno= w, did we ever decide whether the Use cases doc is restricted to "initial" = scenarios, or whether it's all-encompassing, ie covering "future" scenarios= as well? Scott, Reading some of your examples, they seem to be valid even if content adapta= tion (HD/SD) is out of scope. - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) On security considerations, an interesting question is whether trust is tra= nsitive. Don't think it need be - just because CSP trusts uCDN, and uCDN tr= usts dCDN doesn't mean that the CSP automatically trusts the dCDN. However,= i suspect this can get arbitrarily complex - so one possibility is to say = that we will only handle cases where the trust is transitive. Best wishes phil Philip Eardley Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adapt= ation (i.e. taking in a content item in one format and transforming it to a= nother format or representation) is not a "core" function of a CDN which ty= pically delivers the content that is requested without explicit knowledge o= f what that content actually is. Let's not forget that in building an end to end content service the CDN is = only one component and is the component tasked with executing the delivery = of a specific representation (version/copy/format etc.) of the selected con= tent not the component tasked with deciding (or applying policy) on which v= ersion/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to = be delivered to a given device/user is implemented outside of the CDN (e.g.= by the "portal" where the user first makes their content selection prior t= o the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: Following Scott's comments on section 5.1.3, I feel Scott's description on = the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with di= fferent identifier. In DRM scope, the basic unit is a content copy. Here the first bullet "a subset of encodings deliverable to specific device= s," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken some= email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area to = explain the content flexibility is currently a basic requirement for CDN se= rvice and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments or = questions on this case since I hope my use case may be incorporated in the = use case draft. If you have any more question or comments, pls share in this thread. Thanks. Zhipeng -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. Section 10 Security Considerations Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is dete= rmined by the respective CDN's. Scott _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_1B6D0317D3AD964FBF3956DEFA3524D5170F2D66F3EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Mark
 

From: Mark de Jong [mailto:mark@jet-str= eam.nl]=20
Sent: October-26-11 4:21 PM
To: Alan Kavanagh
Cc= :=20 Ben Niven-Jenkins; ZhouZhipeng; cdni@ietf.org
Subject: Re: [CDNi]= I-D=20 Action: draft-ietf-cdni-use-cases-00.txt

Hi Alan,

As Ben stated the overall discussion right now is about delivery, not = on=20 adaptation. It is hard enough to get consensus on the delivery aspect alrea= dy=20 not to mention your requirement from content adaptation added to that, so I= =20 agree with Ben we should stick with the delivery aspect for the first=20 specs. I can imagine this could be a discussion later on but please le= t us=20 keep the scope of this be clean and transparent. It is of benefit of everyo= ne to=20 get the first specs as fast as possible. Thanks.

So are we defining a limited set of use case= s or=20 should we ensure that use cases at the very least ensure that the realistic= use=20 cases both deployed today and ones planed are captured in the use cases=20 document? 
 
Alan
Met vriendelijke groet,
Kind regards,

Mark de Jong
Internationa= l=20 Business Developer
Jet-Stream BV

E-mail: mark@jet-stream.com
Office: +31 = (0)50=20 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50=20 5264214

- Event: Meet us at Streaming Media Europ= e,=20 17-18 October, London, UK
- Event: Meet us at Online Video Stra= tegies,=20 19 October, London, UK
- Event: Meet us at CDN World Summit,= 25-28=20 October, London, UK
- News: Pre-request yo= ur=20 Technology Whitepaper now and be the first to have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to downloa= d our=20 'Six Trends in CDNs' brochure

- Blog: www.jet-stream.com/blog/
- VideoExchange: www.vdo-x.net
- Streamzilla: www.streamzillacdn.com
- Corporate: www.jet-stream.com
<= /DIV>

On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote:
Ben

Im assuming then based on your comments below are you=20 suggesting we are going to have a number of versions of the CDN-I=20 Metadata?

I sympathise with what you are pointing out below and do= =20 agree that there is some work to be done, but I still feel that content=20 adaptation is to me a fundamental requirement to what collectively we sho= uld=20 address in the CDN-I WG. I do agree with you that content adaptation is a= n=20 optimization between CDN's but it's a very important one that I know Netw= ork=20 Service Providers particularly require.

Alan

-----Original= =20 Message-----
From: cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent:=20 October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-= D=20 Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 12 Oct= =20 2011, at 10:22, ZhouZhipeng wrote:

Hello Ben,
The UE may select the content format on the CP = web.=20 After that the user only desires to get his selected content.
But how the content is transferred to the clien= t is=20 not worried by the user.
The CP may create a special format as required = by=20 the user and ask the CDN to deliver to user.
While CP may give a HD format content to uCDN a= nd=20 the dCDN may then transform to the format as the user=20 select.

Lots of things may be possible to do and CDN= =20 providers offer many additional services on top of the "core" service of= =20 content delivery. However, our objective (based on my interpretation of t= he=20 CDNI charter) is to focus on what is necessary to interconnect CDNs to de= liver=20 content from a CSP to an End User that is targeted and deployable within = a=20 short time frame (18-24 months).

Content transformation/adaptation= is=20 not an essential requirement in order to achieve that aim (we can deliver= =20 content from CSPs to End Users via multiple CDNs without needing or requi= ring=20 any CDN supports content adaptation).

In my opinion we have enough= work=20 to do already without trying to expand the scope of our work to include=20 additional requirements that do not help us address our core objectives a= s=20 laid out in the CDNI charter.

In this case, it is nothing related to how the = user=20 select formats on CP website.
So, it is the CP and user to decide the content= =20 format not the CDN(your assert is not correct and seems you take that a= ssert=20 as your base for the discussion).

As for "the core CDN functionality offered by C= DNs=20 today", I have ever raised an email before that your company's webpage = has=20 claimed supporting media transformation and multi-screen=20 service.
Perhaps, I like asking you list some features t= hat=20 you feel are the core functionalities by existing main stream CDNs. Thu= s we=20 may compare and take deep look.

I think the core=20 functionality maps pretty well to the CDNI interfaces, namely: Request=20 Routing, Metadata configuration, log production and control plus content= =20 acquisition and content delivery.

I guess many people have the experience/knowled= ge of=20 content related service. The user and CP only care whether the CDN prov= iders=20 may satisfy their requirement while not care the internal process. Just= as=20 GSM/PSTN interconnection, the user only care successful interconnection= =20 while not care how the voice is transformed in process.

Besides, I like raise a case:
Given currently BBC recruits CDN providers that= may=20 support 10 media formats.
One candidate is your company, another is CDN-X= . The=20 users are located in France.
So both your company and CDN-X should connect a= =20 France CDN provider(CDN-Y).
If your company's solution is to send 10 stream= s of=20 different format
of one content to CDN-Y; While CDN-X's solution= is=20 to send 1 stream to CDN-Y while CDN-Y may conduct some=20 adaptation.
Comparing these two solutions, for your company= and=20 CDN-X, absolutely the cost of CDN-X is much lower.
For CDN-Y, in solution-1, it should receive/for= ward=20 10 streams ; while in solution-2, it should only receive 1 stream but n= eed=20 to take transformation to output 10 streams.

Which solution is more competitive. it is Solut= ion=20 1, right. Remember the price from BBC is same to both your company and = CDN-X=20 or BBC would select one CDN provider with the lower price.
If a CDN provider may not get the contract from= CP,=20 how it may say it is not a core functionality.

What= you=20 are describing is a possible optimization that a particular CDN may wish = to=20 implement not a core functionality required to enable content delivery be= tween=20 interconnected CDNs. I can think of many optimizations that a CDN could=20 implement to differentiate their service but the internal workings of an= =20 individual CDN are out of scope of our charter.

So to repeat my=20 position for a final time: Content adaptation is not a core function requ= ired=20 to enable content delivery between interconnected CDNs and therefore give= n the=20 workload we already have to specify solutions that do address the core=20 functionality required to interconnect CDNs I do not think we should be t= rying=20 to add more work into that workload as it will only distract us from achi= eving=20 our goal of producing deployable solutions within the timeframe we are be= ing=20 told by operators they needs solutions within.

Ben

So, if we all realize that currently the media = type=20 is rich, the CDN providers should survive in the existing ecosystem and= =20 support the media types as required by the market.

Back to the case of GSM/G.711, it just when=20 concerning the interconnection, the transformation should at once be so= lved.=20 Otherwise the interconnection may not be operated.

Br,
Zhipeng




-----Original Message-----
From: Ben Niven-Jenkins=20 [mailto:ben@niven-jenkins.co.uk]
Sent: Wednesday, October 12, 2011 12:19=20 AM
To: ZhouZhipeng
Cc: philip.eardley@bt.com; cdni@ietf.org
Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 11 Oct 2011, at 05:16, ZhouZhipeng=20 wrote:

Ben and Philip,
I like to respond your concern in this one=20 email:

Ben,
I feel what we are now discussing is what is = the=20 "core" function of CDN.
As you say, CDN is used to deliver content. T= hat=20 is absolutely correct that the delivery capability is the core requir= ement=20 for CDN system.
While CDN is used to provide the content deli= very=20 service.
What means service. It should include "time"= =20 "location" and "media type", etc. These features are all the core fea= ture=20 for a service.
If we only concern "delivering one data block= ", I=20 am not sure whether the issues such as "logging" "geographic constrai= nt"=20 are the core of CDN.

For "without explicit knowledge of what that= =20 content actually is ", I am not sure whether the wording is accurate = since=20 generally a CDN may claim it support different=20 medias.
By this opportunity, I like to share a use ca= se: a=20 call from a GSM phone to a PSTN telephone, the voice stream should be= =20 transformed from GSM voice to G.711.
For the user, he does not need to know what t= ype=20 of data has been transferred, but the operator has done some work to= =20 interconnect two systems, right.
I like to know whether you may accept that my= use=20 case is similar to this case above.

I don't think your use case is similar to the=20 analogy of mobile networks being interconnected to PSTN networks. In th= e=20 case of content delivery the negotiation is done between the User/Clien= t and=20 the Content Provider and the CDN is just used to execute/perform the=20 delivery that has been negotiated. The CDN is not involved in the decis= ion=20 making of what representations the Content Provider decides to offer to= the=20 User/Client or in what representations the User/Client decides to=20 request.

As for you said selecting media by the "porta= l",=20 you may see the way " uCDN delivers multiple media streams to dCDN" i= s not=20 good than "uCDN delivers one media stream to dCDN and dCDN takes some= =20 adaptation to support multiple media types".

Now what you're talking about is an optimisatio= n,=20 not a core function required to actually deliver the content (and repor= t,=20 bill, etc. for that delivery).

My position is that we should focus on how to e= nable=20 the interconnection of the core CDN functionality offered by CDNs today= =20 (which is also my interpretation of the scope of the CDNI working group= as=20 expressed in its charter) because doing so is a significant piece of wo= rk in=20 itself. Let's not start trying to add in additional functionality beyon= d=20 what the majority of CDNs support today as that will just delay us gett= ing=20 usable specifications into the market in a timely fashion=20 IMO.

Ben

A good question is "security" since I have do= ne=20 six years on the DRM
and like to promote the DRM all around the wo= rld:)=20 If the content is needed to be protected, generally you may know all = the=20 systems should be granted by the content owner.
Here I also like to clarify that not only the= =20 media itself but the information related to service itself (such as t= he=20 geographic constraint) should be protected also.
So, trust is not a problem for the=20 media.

Philip,
Thank you that you feel Content Adaption is a= n=20 issue for "Requirements" but I do not know why it is not for Use=20 case.
I like to clarify to U that it is important f= or=20 you operator since it may save investment if the system may support=20 different services.
For us vendor, we are happy operator may inst= all a=20 system for the mobile service and another system for the FBB=20 service.
But the reality is all operators ask us to pr= ovide=20 a system that may support different service=20 systems.

Frankly, Ben and Philip, I remember I have=20 explained somewhere that to implement this is rather simple=20 .
At least the Use case and Requirement are=20 informational to be referred in future work. So I do really feel you = may=20 accept it.
Of course I like to respond your more concern= and=20 comments.
Thanks.
Zhipeng



-----Original=20 Message-----
From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]
Sent: Monday, October 10, 2011 11:22=20 PM
To: ben@niven-jenkins.co.uk;= =20 ZhouZhipeng
Cc: cdni@ietf.org
Subject: RE: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

Ben, Zhipeng, all,

I think that Content Adaptation is more an is= sue=20 for the Requirements doc than for the Use cases=20 draft.

The key question is whether we want the CDNI= =20 interfaces to be able to cope with a scenario where (say) HD/SD conve= rsion=20 is done in the dCDN & to signal about this.

I think that coping with this scenario is a s= econd=20 order requirement, ie we should not worry about it in the initial=20 standards-track work. I don't know, did we ever decide whether the Us= e=20 cases doc is restricted to "initial" scenarios, or whether it's=20 all-encompassing, ie covering "future" scenarios as=20 well?

Scott,
Reading some of your examples, they seem to b= e=20 valid even if content adaptation (HD/SD) is out of=20 scope.
- a dCDN might for some reason be unwilling t= o=20 distribute HD?
- a CSP might want to make sure the dCDN can = use=20 HLS encapsulation?
But these sorts of examples seem to be static= =20 policy things (to do
with the capabilities & preferences of th= e=20 CDNs & CSP), rather than
metadata associated with a particular piece o= f=20 content. In the
discussion so far, I think negotiation about= =20 static policy stuff is
rather out of scope(?)

On security considerations, an interesting=20 question is whether trust is transitive. Don't think it need be - jus= t=20 because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the C= SP=20 automatically trusts the dCDN. However, i suspect this can get arbitr= arily=20 complex - so one possibility is to say that we will only handle cases= =20 where the trust is transitive.

Best wishes
phil


Philip Eardley
Research and Technology=20 Strategy

This email contains BT information, which may= be=20 privileged or confidential. It's meant only for the individual(s) or= =20 entity named above. If you're not the intended recipient, note that=20 disclosing, copying, distributing or using this information is prohib= ited.=20 If you've received this email in error, please let me know immediatel= y on=20 the email address above. Thank you. We monitor our email system, and = may=20 record your emails.
British Telecommunications=20 plc
Registered office: 81 Newgate Street London E= C1A=20 7AJ Registered in
England no: 1800000


-----Original=20 Message-----
From: cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On Behalf
Of Ben Niven-Jenkins
Sent: 10 October 2011=20 12:04
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

Colleagues,

IMO Section 5.1.3 should be removed from the = Use=20 Cases draft. Content Adaptation (i.e. taking in a content item in one= =20 format and transforming it to another format or representation) is no= t a=20 "core" function of a CDN which typically delivers the content that is= =20 requested without explicit knowledge of what that content actually=20 is.

Let's not forget that in building an end to e= nd=20 content service the CDN is only one component and is the component ta= sked=20 with executing the delivery of a specific representation=20 (version/copy/format etc.) of the selected content not the component= =20 tasked with deciding (or applying policy) on which=20 version/copy/representation of content should be=20 delivered.

The decision as to which=20 version/copy/representation to offer and allow to be delivered to a g= iven=20 device/user is implemented outside of the CDN (e.g. by the "portal" w= here=20 the user first makes their content selection prior to the CDN becomin= g=20 involved in the delivery of the selected=20 content).

Ben

On 8 Oct 2011, at 08:20, ZhouZhipeng=20 wrote:

Following Scott's comments on section 5.1.3= , I=20 feel Scott's description on the use case of HD and SD is not exactl= y=20 correct.
If one movie has two formats of HD and SD, = then=20 we have two content with different identifier. In DRM scope, the ba= sic=20 unit is a content copy.

Here the first bullet "a subset of encoding= s=20 deliverable to specific devices," has listed the case of content=20 adaptation.
In last month, I have contacted the Authors= of=20 this document and taken some email exchanges with Grant and Philip= =20 (BT).
I have shown BT with some information that = I=20 know in this case and area to explain the content flexibility is=20 currently a basic requirement for CDN service and related negotiati= on is=20 needed in the CDN interconnection.
Meanwhile, I should also invite you in this= =20 group raising your comments or questions on this case since I hope = my=20 use case may be incorporated in the use case=20 draft.

If you have any more question or comments, = pls=20 share in this thread.
Thanks.
Zhipeng






-----Original=20 Message-----
From: Scott Wainner=20 [mailto:swainner@cisco.com]
Sent: Friday, September 30, 2011 8:02=20 AM
To: cdni@ietf.org
Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

Section 2.3 Nomadic=20 Users
This description falls under the category o= f=20 Geographic Extension
yet the third paragraph states the case whe= re a=20 different device is
used in the same CDN coverage area.  T= he=20 intent of this use case
needs to be clarified.  Perhaps the us= e=20 case is trying to address
the scenario where a Nomadic User-A with an= =20 agreement allowing
access to content from CSP-A via uCDN moves= to a=20 dCDN in a different
region.  The dCDN is allowed to distri= bute=20 the content of CSP-A to
User-A; however, not other users in the reg= ion=20 of the dCDN are
allowed to retrieve the content unless they= too=20 have such an agreement.

Section 5.1.3 Content Encoding Restrictions= Need=20 to clarify if we're
talking about the restrictions on the deliv= ery=20 of specific content
or the restrictions on the ability of a CDN= to=20 deliver specific
content.  I certainly understand the c= ase=20 where a CSP will restrict
the distribution of content to a "managed p= ath"=20 if such content is
HD while allowing the content distribution = via=20 an un-managed path if
such content is SD (same could apply to=20 encryption methods, delivery
methods, etc.).  On the contrary, the = dCDN=20 may have its own
restrictions of blocking the distribution o= f HD=20 content while
allowing the distribution of SD=20 content.

o first bullet makes sense if the dCDN can= =20 perform a subset of
encapsulations for a reference set of media= =20 (e.g. HLS, HSS, but not
DASH) o second bullet makes sense where the= dCDN=20 doesn't want to
offer high bit-rate variants of the media o= =20 third bullet make sense
if the policy addresses QoE but I don't thi= nk=20 subscriber
rights/authorizations=20 apply.

Section 10 Security=20 Considerations

Aside from the security considerations WITH= IN=20 the uCDN and dCDN, I
think we can describe this in four=20 contexts:

a. The relationship between the CSP and the= uCDN=20 (the principle contract
arrangement for=20 distribution)
b. The relationship between the uCDN and dC= DN=20 (the transitive trust
relationship that extends the contract defi= ned=20 in (a) above) c. The
relationship between the User and dCDN (the= =20 recognition of right to
download predicated on (b) above) d. The=20 relationship between the
User and CSP (the contract authorizing the = user=20 access to the
content)

The user is not interested in the a-b nor t= he=20 b-c relationship. The
user is only interested in the transparency= and=20 interoperability of
the security relationship between d-b or d-= c to=20 the point that the
authorization granted in d-a is viable when= the=20 delivery is
initiated via either d-b or d-c.  As a= n=20 example, the uCDN might use
URL appended tokens for authentication whil= e=20 dCDN might use URL
appended hashes.  The user doesn't wan= t to=20 know about the distinct
methods, but transparency is only afforded = if=20 the methods are
interoperable clearly defined when the=20 delegation for content
delivery is executed.  Clearly, the ch= oice=20 of authentication method is determined by the respective=20 CDN's.

Scott

_______________________________________________
CDNi mailing=20 list
CDNi@ietf.org
https://www.iet= f.org/mailman/listinfo/cdni

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.= org/mailman/listinfo/cdni


______________________________________= _________
CDNi=20 mailing list
CDNi@ietf.org
https://www.ietf.org/= mailman/listinfo/cdni
______________________________________________= _
CDNi=20 mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni


--_000_1B6D0317D3AD964FBF3956DEFA3524D5170F2D66F3EUSAACMS0701e_-- From lijincheng@huawei.com Thu Oct 27 23:11:58 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8371021F853E for ; Thu, 27 Oct 2011 23:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.619 X-Spam-Level: ** X-Spam-Status: No, score=2.619 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id la3I6pKRIxN0 for ; Thu, 27 Oct 2011 23:11:58 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A4F0E21F8515 for ; Thu, 27 Oct 2011 23:11:57 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTR00GD7IJULW@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 28 Oct 2011 14:11:54 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTR00EPLIJUSL@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 28 Oct 2011 14:11:54 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEM46158; Fri, 28 Oct 2011 14:11:54 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 28 Oct 2011 14:11:48 +0800 Received: from SZXEML524-MBX.china.huawei.com ([169.254.4.75]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 14:11:48 +0800 Date: Fri, 28 Oct 2011 06:11:48 +0000 From: "Will Li(jincheng)" In-reply-to: <2A0AF3CA-36D1-4F0E-8D09-3E29EFBC72A6@niven-jenkins.co.uk> X-Originating-IP: [10.144.242.41] To: Ben Niven-Jenkins Message-id: MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: =?gb2312?B?tPC4tDogW0NETmldIFByZXBhcmluZyBkcmFmdC1pZXRmLWNkbmktcHJvYmxl?= =?gb2312?Q?m-statement_for_WG_Last_Call?= Thread-index: AQHMjL1M8UDFDgdACEqAzOaAom66QJWDZJBwgAewLQCABG8hQIAAC3gAgAHH/fA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> <2A0AF3CA-36D1-4F0E-8D09-3E29EFBC72A6@niven-jenkins.co.uk> Cc: "cdni@ietf.org" Subject: Re: [CDNi] =?gb2312?b?tPC4tDogIFByZXBhcmluZyBkcmFmdC1pZXRmLWNkbmkt?= =?gb2312?b?cHJvYmxlbS1zdGF0ZW1lbnQgZm9yIFdHIExhc3QgQ2FsbA==?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 06:11:58 -0000 SGksIEJlbiwNCg0KRmluZSB0byBtZS4gVGhhbmtzLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEJlbiBOaXZlbi1KZW5raW5zIFttYWlsdG86YmVuQG5pdmVuLWplbmtp bnMuY28udWtdDQo+IFNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDExIDY6NTkgUE0NCj4g VG86IFdpbGwgTGkoamluY2hlbmcpDQo+IENjOiBjZG5pQGlldGYub3JnDQo+IFN1YmplY3Q6IFJl OiC08Li0OiBbQ0ROaV0gUHJlcGFyaW5nIGRyYWZ0LWlldGYtY2RuaS1wcm9ibGVtLXN0YXRlbWVu dCBmb3IgV0cNCj4gTGFzdCBDYWxsDQo+IA0KPiBXaWxsLA0KPiANCj4gT24gMjcgT2N0IDIwMTEs IGF0IDAzOjM0LCBXaWxsIExpKGppbmNoZW5nKSB3cm90ZToNCj4gPj4gRnJvbTogQmVuIE5pdmVu LUplbmtpbnMgW21haWx0bzpiZW5Abml2ZW4tamVua2lucy5jby51a10NCj4gPj4gSSBkb24ndCB0 aGluayB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQgZHJhZnQgc2hvdWxkIHRyeSB0byBkZXNjcmliZSB0 aGUgZGlmZmVyZW50DQo+ID4+IGJ1c2luZXNzIHJlbGF0aW9uc2hpcHMgYXMgdGhleSBhcmUgbWFu eSBhbmQgdmFyaWVkIGRlcGVuZGluZyBvbiB0aGluZ3MgbGlrZQ0KPiB0aGUNCj4gPj4gcHVycG9z ZSBvZiB0aGUgc3BlY2lmaWMgQ0ROLCB0aGUgbWFya2V0IGl0IGlzIGRlcGxveWVkIGluIGV0YyBh bmQgaXQgd291bGQgYmUNCj4gdmVyeQ0KPiA+PiBkaWZmaWN1bHQgdG8gZGVzY3JpYmUgYWxsIHRo ZSBkaWZmZXJlbnQgYnVzaW5lc3MgcmVsYXRpb25zaGlwcyBhbmQgd2Ugd291bGQgcmlzaw0KPiA+ PiBnZXR0aW5nIGRpc3RyYWN0ZWQgYnkgY29tbWVudHMgYWxvbmcgdGhlIGxpbmVzIG9mICJ3aGF0 IGFib3V0IHRoaXMgYnVzaW5lc3MNCj4gPj4gcmVsYXRpb25zaGlwIHRoYXQgeW91IGhhdmVuJ3Qg ZGVzY3JpYmVkIiBhbmQgInlvdSBoYXZlbid0IGFkZXF1YXRlbHkNCj4gY2FwdHVyZWQNCj4gPj4g aG93IHRoaXMgcmVsYXRpb25zaGlwIGNvdWxkIHdvcmsiIGV0Yy4NCj4gPj4NCj4gPj4gU2VjdGlv biAxLjIgYWxyZWFkeSBzdGF0ZXMgdGhhdCAiUmVhZGVycyBhcmUgYXNzdW1lZCB0byBiZSBmYW1p bGlhciB3aXRoIHRoZQ0KPiA+PiBhcmNoaXRlY3R1cmUsIGZlYXR1cmVzIGFuZCBvcGVyYXRpb24g b2YgQ0ROcy4iIGFuZCBJIGFzc3VtZSBpZiByZWFkZXJzIGFscmVhZHkNCj4gPj4gaGF2ZSB0aGF0 IGZhbWlsaWFyaXR5IHdpdGggaG93IENETnMgd29yayAmIGFyZSBvcGVyYXRlZCB0aGVuIHRoZXkg Y2FuDQo+ID4+IHVuZGVyc3RhbmQgaG93IENTUHMsIHVwc3RyZWFtIENETnMsIGRvd25zdHJlYW0g Q0ROcyBtYXkgZml0IHRvZ2V0aGVyIGFzDQo+ID4+IHBhcnQgb2YgdGhlIENETkkgcmVmZXJlbmNl IG1vZGVsLg0KPiA+Pg0KPiA+IEFncmVlIGluYXBwcm9wcmlhdGUgZGVzY3JpcHRpb24gbWF5IGxl YWQgY29uZnVzaW9uLiBIb3dldmVyLCBJIGFtIHRoaW5raW5nIG9mDQo+IHNvbWUgZ2VuZXJhbCBi dXQgc2FmZSBkZXNjcmlwdGlvbnMgb24gdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGVzZSByb2xlcywg bGlrZQ0KPiA+ICJJbiBhIHR5cGljYWwgY29udGVudCBkZWxpdmVyeSBzZXJ2aWNlLCBBIENTUCBj b250cmFjdHMgd2l0aCBhbiB1cHN0cmVhbSBDRE4gdG8NCj4gc3RvcmUgYW5kIGRlbGl2ZXIgY29u dGVudCB0byBVc2VyIEFnZW50czsgdGhlIHVwc3RyZWFtIENETiBmdXJ0aGVyIGNvbnRyYWN0cw0K PiB3aXRoIG9uZSBvciBtb3JlIGRvd25zdHJlYW0gQ0ROKHMpIHRvIGRpc3RyaWJ1dGUgYW5kIGRl bGl2ZXIgY29udGVudHMgb24NCj4gdUNETqGvcyBiZWhhbGYuIEhvd2V2ZXIsIHRoZXNlIGJ1c2lu ZXNzIHJlbGF0aW9uc2hpcHMgYXJlIG91dCBvZiBzY29wZSBvZiBDRE5JLiIsDQo+IGlmIHRoaXMg a2luZCBvZiBkZXNjcmlwdGlvbiBpcyBzYWZlIHRvIGJlIGFkZGVkIGJlbG93IHRoZSBmaWd1cmUs IHRoZW4gaXQgY2FuIGVhc2UNCj4gcGVvcGxlIHRvIHVuZGVyc3RhbmQgdGhlIGZvbGxvd2luZyBz dGFmZiBpbiB0aGlzIGRyYWZ0Lg0KPiANCj4gSSB0b29rIGFub3RoZXIgbG9vayBhdCB0aGUgZHJh ZnQgYW5kIG15IHByb3Bvc2FsIGlzIHRvIGFkZCBhIGNvdXBsZSBvZiBzZW50ZW5jZXMNCj4gdG8g dGhlIGJvdHRvbSBvZiB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoZSBJbnRyb2R1Y3Rpb24gKFNl Y3Rpb24gMSkgYXMgZm9sbG93czoNCj4gDQo+IA0KPiBPTEQ6DQo+ICAgIFRoaXMgY3JlYXRlcyBh IHJlcXVpcmVtZW50IGZvciBpbnRlcmNvbm5lY3Rpbmcgc3RhbmRhbG9uZQ0KPiAgICBDRE5zIHNv IHRoYXQgdGhlaXIgY29sbGVjdGl2ZSBDRE4gZm9vdHByaW50IGNhbiBiZSBsZXZlcmFnZWQgZm9y IHRoZQ0KPiAgICBlbmQtdG8tZW5kIGRlbGl2ZXJ5IG9mIGNvbnRlbnQgZnJvbSBDb250ZW50IFNl cnZpY2UgUHJvdmlkZXJzIChDU1BzKQ0KPiAgICB0byBFbmQgVXNlcnMuICBIb3dldmVyLCBubyBz dGFuZGFyZHMgb3Igb3BlbiBzcGVjaWZpY2F0aW9ucyBjdXJyZW50bHkNCj4gICAgZXhpc3QgdG8g ZmFjaWxpdGF0ZSBzdWNoIENETiBpbnRlcmNvbm5lY3Rpb24uDQo+IE5FVzoNCj4gICAgVGhpcyBj cmVhdGVzIGEgcmVxdWlyZW1lbnQgZm9yIGludGVyY29ubmVjdGluZyBzdGFuZGFsb25lDQo+ICAg IENETnMgc28gdGhhdCB0aGVpciBjb2xsZWN0aXZlIENETiBmb290cHJpbnQgY2FuIGJlIGxldmVy YWdlZCBmb3IgdGhlDQo+ICAgIGVuZC10by1lbmQgZGVsaXZlcnkgb2YgY29udGVudCBmcm9tIENv bnRlbnQgU2VydmljZSBQcm92aWRlcnMgKENTUHMpDQo+ICAgIHRvIEVuZCBVc2Vycy4gIEhvd2V2 ZXIsIG5vIHN0YW5kYXJkcyBvciBvcGVuIHNwZWNpZmljYXRpb25zIGN1cnJlbnRseQ0KPiAgICBl eGlzdCB0byBmYWNpbGl0YXRlIHN1Y2ggQ0ROIGludGVyY29ubmVjdGlvbi4gRm9yIGV4YW1wbGUs IGEgQ1NQIGNvdWxkDQo+ICAgIGNvbnRyYWN0IHdpdGggYW4gImF1dGhvcml0YXRpdmUiIENETiBm b3IgdGhlIGRlbGl2ZXJ5IGNvbnRlbnQgYW5kIHRoYXQgQ0RODQo+ICAgIGNvdWxkIGNvbnRyYWN0 IHdpdGggb25lIG9yIG1vcmUgZG93bnN0cmVhbSBDRE4ocykgdG8gZGlzdHJpYnV0ZSBhbmQNCj4g ICAgZGVsaXZlciBzb21lIG9yIGFsbCBvZiB0aGUgY29udGVudCBvbiBiZWhhbGYgb2YgdGhlIGF1 dGhvcml0YXRpdmUgQ0ROLg0KPiAgICBUaGUgZm9ybWF0aW9uIGFuZCBkZXRhaWxzIG9mIGFueSBi dXNpbmVzcyByZWxhdGlvbnNoaXBzIGJldHdlZW4gYSBDU1AgYW5kDQo+ICAgIGEgQ0ROIGFuZCBi ZXR3ZWVuIG9uZSBDRE4gYW5kIGFub3RoZXIgQ0ROIGFyZSBvdXQgb2Ygc2NvcGUgb2YgdGhpcw0K PiAgICBkb2N1bWVudC4NCj4gDQo+IEJlbg0KDQo= From zhouzhipeng@huawei.com Fri Oct 28 02:26:32 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CCA21F8610 for ; Fri, 28 Oct 2011 02:26:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWmlsvLYPUNv for ; Fri, 28 Oct 2011 02:26:32 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id A2DA021F863E for ; Fri, 28 Oct 2011 02:26:18 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTR00A6ZRIF21@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 28 Oct 2011 17:25:27 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTR00FK8RIFXL@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 28 Oct 2011 17:25:27 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AER81132; Fri, 28 Oct 2011 17:25:26 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 28 Oct 2011 17:25:18 +0800 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.117]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Fri, 28 Oct 2011 17:25:13 +0800 Date: Fri, 28 Oct 2011 09:25:11 +0000 From: ZhouZhipeng In-reply-to: <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> X-Originating-IP: [10.138.73.38] To: "Woundy, Richard" , "'mark@jet-stream.nl'" , "'alan.kavanagh@ericsson.com'" , =?utf-8?B?77ybY2hlbndlaXlqQGNoaW5hbW9iaWxlLmNvbQ==?= Message-id: <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/related; boundary="Boundary_(ID_LrroFSWRXtXISoZEEmpZOA)"; type="multipart/alternative" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgBYn8ICAAA1tAIABOe8g///B/QCAAfcmAA== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> Cc: "'cdni@ietf.org'" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 09:26:32 -0000 --Boundary_(ID_LrroFSWRXtXISoZEEmpZOA) Content-type: multipart/alternative; boundary="Boundary_(ID_xpIuX+soGX65496WnIyqkQ)" --Boundary_(ID_xpIuX+soGX65496WnIyqkQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 RGVhciBhbGwsDQpJbiB0aGVzZSBkYXlzIEkgYW0gYnVzeSBtYWtpbmcgYSBzdW1tYXJ5IGFuYWx5 c2lzIG9uIHRoaXMgdG9waWMuIEFzIFJpY2hhcmTigJlzIHJlcXVlc3QsIEkgbGlrZSB0byBzaG93 IG15IGluZm9ybWF0aW9uIGFsdGhvdWdoIHBlcmhhcHMgbm90IGNvbXBsZXRlIHJpZ2h0IG5vdy4N Cg0KDQoxKSAgICAgSSBoYXZlIGRvbmUgc29tZSB3b3JrIHRvIGNvbGxlY3QgZGlmZmVyZW50IGNv bXBhbnnigJlzIHJlcXVpcmVtZW50cyBhbmQgb3BpbmlvbnMgb24gdGhpcyBmdW5jdGlvbmFsaXR5 Lg0KDQpPbmUsIEkgZmVlbCBtb3N0IG9mIHVzIGhhdmUgYWxyZWFkeSBiZWVuIGF3YXJlIG9mIHRo ZSBzZXJ2aWNlIG9mIGNvbnRlbnQgYWRhcHRhdGlvbiwgYW5kIEkgYWxzbyBzZW50IGFuIGVtYWls IHllc3RlcmRheSB0aGF0IFZvZGFwaG9uZSBub3cgaXMgcmVxdWlyaW5nIHRoZSBzb2x1dGlvbiB0 byBlbmhhbmNlIHRoZSBwZXJmb3JtYW5jZSBvZiBpdHMgbW9iaWxlIHZpZGVvIHNlcnZpY2UuDQoN ClNlY29uZCwgaGVyZSBpcyBhbiBhcnRpY2xlIGFib3V0IENJU0NPIDog4oCcQ2lzY28gdXJnZXMg bW9iaWxlIG9wZXJhdG9ycyB0byBhZGQgdmFsdWUgdG8gQ0ROIHNlcnZpY2Vz4oCdIGh0dHA6Ly93 d3cudG90YWx0ZWxlLmNvbS92aWV3LmFzcHg/SUQ9NDY4NzA1DQoNCkJlc2lkZXMsIEkgaGF2ZSBj aGVja2VkIG1hbnkgQ0ROIGNvbXBhbnnigJlzIHdlYnNpdGVzLiBNYW55IGNsYWltIHRvIHN1cHBv cnQgdHJhbnNjb2Rpbmcgd2hpbGUgc29tZSBtYXkgbm90Lg0KDQoNCg0KMikgICAgIEZvciB0aGUg d29yZGluZyDigJxjb250ZW50IGFkYXB0YXRpb27igJ0sIGl0IHNob3VsZCBiZSBjbGFyaWZpZWQg aGVyZSB0aGF0IGl0IG1heSBiZSB0d28ga2luZHMuDQoNCk9uZSBpcyBvbmx5IHRoZSB0cmFuc2Zv cm1hdGlvbiBvZiBlbmNhcHN1bGF0aW9uIGZvcm1hdC4gRm9yIGV4YW1wbGUgdGhlIEguMjY0IHN0 cmVhbSBpcyBlbmNhcHN1bGF0ZWQgaW4gQVBQTEUgYW5kIEFkb2JlIGZvcm1hdCByZXNwZWN0aXZl bHkuDQoNCkkga25vdyB0aGF0IENvbWNhc3QgaGFzIGEgcHJvamVjdCB0aGF0IG5lZWRzIHRvIHBp Y2sgdGhlIEguMjY0IG1lZGlhIGZyb20gdGhlIFRTIHN0cmVhbSBhbmQgdGhlbiBlbmNhcHN1bGF0 ZWQgdGhlbSBpbnRvIGRpZmZlcmVudCBmb3JtYXRzKEFQUExFLEFkb2Jl4oCmKSB0byBkaWZmZXJl bnQgZGV2aWNlcy4NCg0KRm9yIHRoaXMga2luZCBvZiB0cmFuc2Zvcm1hdGlvbiwgdGhlIGNvbXB1 dGluZyBjb3N0IGlzIHZlcnkgdmVyeSBsb3cgYW5kIG1heSBiZSBuZWFybHkgbmVnbGVjdGVkLg0K DQpUaGUgb3RoZXIgaXMgdG8gdHJhbnNjb2RpbmcuICBGb3IgZXhhbXBsZSB0byBzdXBwb3J0IGRp ZmZlcmVudCBiaXRyYXRlcy4gIFNpbmNlIGVuY29kZXIgaXMgYSBoaWdoIHZhbHVlIGZhY2lsaXR5 LCB3ZSBzaG91bGQgY29tcGFyZSB0aGUgY2FwaXRhbCBjb3N0IG9mIGVuY29kZXIgYW5kIHRyYW5z cG9ydCBjb3N0Lg0KDQpKdXN0IHRha2UgYSBzaW1wbGUgbW9kZWw6IGNvbnRlbnQgaXMgZGVsaXZl cmVkIGZyb20gTm9kZSBBIHRvIE5vZGUgQi4NCg0KW2NpZDppbWFnZTAwMi5wbmdAMDFDQzk1OTYu OEFDNzkzNzBdDQoNClRoZXJlIGFyZSB0d28gc29sdXRpb25zOg0KDQoxKSAgICAgQSBoYXZlIHRo ZSB0cmFuc2NvZGVyIGFuZCBkZWxpdmVyIG11bHRpLWZvcm1hdCBjb250ZW50IHRvIEINCg0KMikg ICAgIEIgaGF2ZSB0aGUgdHJhbnNjb2RlcjsgQSBvbmx5IGRlbGl2ZXJzIG9uZSBmb3JtYXQgY29u dGVudCB0byBCIGFuZCBCIHdvdWxkIHRyYW5zY29kZS4NCg0KRnJvbSB3aG9sZSBzeXN0ZW0gcG9p bnQgb2YgdmlldywgZWl0aGVyIEEgb3IgQiB3b3VsZCB0cmFuc2NvZGUgd2hpbGUgdGhlIGJhbmR3 aWR0aCB3b3VsZCBiZSBzYXZlZCBpbiBzb2x1dGlvbiBCLiBIZW5jZSBzb2x1dGlvbiBCIGlzIGJl dHRlci4NCg0KTm93IHByb3ZpZGVkIHRoZSBiYW5kd2lkdGggaXMgcGFpZCBieSBCIGFuZCBCIHNo b3VsZCBkZWNpZGUgd2hldGhlciB0byBpbnN0YWxsIHRyYW5zY29kZXIuDQoNCihSaWNoYXJkIGhh cyBzYWlkIHRvIHNldCB0cmFuc2NvZGVyIGluIGVhY2ggZWRnZSBzZXJ2ZXIpDQoNCklmIHRoZSBj b3N0IG9mIHJlbnRpbmcgYmFuZHdpZHRoIChmb3IgYSBmZXcgbW9udGhzKSBpcyBtb3JlIGV4cGVu c2l2ZSB0aGFuIHRoZSBwcmljZSBvZiB0cmFuc2NvZGVyIHN1cHBvcnRpbmcgdGhlIHNhbWUgYmFu ZHdpZHRoLCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcHV0IHRoZSB0cmFuc2NvZGVyIGF0IHRoZSBy ZWNlaXZlciBOb2RlIEIuDQoNCkluIGZhY3QgSSBoYXZlIGludmVzdGlnYXRlZCB0aGlzIGlzc3Vl IGZvciBtdWNoIHRpbWUuIFdoaWxlIGluIGRpZmZlcmVudCBhcmVhIHRoZSBwcmljZSBvZiBiYW5k d2lkdGggbWF5IGJlIGRpZmZlcmVudC4gIEFuZCB0aGUgdHJhbnNwb3J0IGJ1cmRlbiBiZXR3ZWVu IHR3byBkaXN0YW50IHBsYWNlcyBvciBvdmVyIGEgYmFkIG5hdHVyZSBlbnZpcm9ubWVudCB3b3Vs ZCBiZSBtdWNoIGhpZ2hlci4NCg0KSGVyZSB0aGUgcHJpY2UgaW4gVVNBIG1heSBiZSByZWZlcnJl ZCBhczogaHR0cDovL3NtYWxsYnVzaW5lc3MudmVyaXpvbi5jb20vcHJvZHVjdHMvaW50ZXJuZXQv aHNpL292ZXJ2aWV3LmFzcHgjcGxhbnMuDQoNCkluIFZlcml6b24sIHRoZSBwYWNrYWdlIGZvciAx MC0xNW1icHMgaXMgJDkwIHBlciBtb250aCAoSSBmZWVsIHRoZSBiYW5kd2lkdGggcXVhbGl0eSBm b3IgYnVzaW5lc3Mgd291bGQgYmUgZ3VhcmFudGVlZCkuIEkgcXVlcnkgdGhhdCB0aGUgYmFuZHdp ZHRoIHByaWNlIGluIENoaW5hIG1heSBiZSA1MCUgaGlnaGVyLg0KDQpJIGRvIG5vdCBrbm93IGhv dyBtdWNoIHRoZSBwcmljZSB3aWxsIGJlIGZvciB0aGUgYmFuZHdpZHRoIGZyb20gQW1zdGVyZGFt IHRvIFBhcmlzIChjcm9zcyBjb3VudHJ5IGluIHRoZSBzYW1lIGNvbnRpbmVudCkuICBCdXQgSSBm ZWVsIHRoZSBwcmljZSBmcm9tIE5ld1lvcmsgdG8gUGFyaXMgd291bGQgYWJzb2x1dGVseSBiZSB2 ZXJ5IGhpZ2guICBBcyBmb3IgdGhlIEVuY29kZXIsIGl0IGFsc28gdmFyaWVzLiBQZXJoYXBzIHRo ZSBwcmljZSBpbiBDaGluYSB3aWxsIGJlIGhpZ2hlciB0aGFuIGluIFVTQS4gQW5kIGluIGZhY3Qg dGhlIHByaWNlIG9mIGJhbmR3aWR0aCBhbmQgZW5jb2RlciBkZXBlbmRzIG1vc3RseSBvbiB0aGUg Y29uY3JldGUgYnVzaW5lc3MgaXRlbXMuIEZvciBleGFtcGxlIHRoZSBwcmljZSB0byBIdWF3ZWkg bWF5IGJlIGxvd2VyIHRoYW4gdGhlIHB1YmxpYyBwcmljZS4NCg0KQnkgbXkgY3VycmVudCBldmFs dWF0aW9uIGluIENoaW5hIGl0IGlzIGJldHRlciB1c2luZyB0aGUgdHJhbnNjb2RlciB0aGFuIHJl bnRpbmcgbXVsdGlwbGUgdGltZXMgYnJvYWRiYW5kLg0KDQpTb21lIHBlb3BsZSBoYXZlIHRvbGQg bWUgdGhhdCBmb3IgdGhlIG9wZXJhdG9yIGhpbXNlbGYgcHJvYmFibHkgdGhlIGJhbmR3aWR0aCBj b3N0IHdvdWxkIGJlIHZlcnkgbG93IGluIHRoZSBpbnRlcm5hbCBjYXBpdGFsIGNvdW50aW5nLiBC dXQgZm9yIHRoZSBpbmRlcGVuZGVudCBDRE4sIGl0IG1heSBhbm90aGVyIHRoaW5nLg0KDQpTbywg bXkgc3VnZ2VzdGlvbiBpcyB0byBsZXQgZGlmZmVyZW50IHdheXMgY28tZXhpc3QuIEkgaGF2ZSBh bm5vdW5jZWQgdGhhdCB0byBsZXQgdHdvIHNpZGVzIG5lZ290aWF0ZSB3aGV0aGVyIHRvIGFzc2ln biBkQ0ROIGZvciB0aGUgY29udGVudCBhZGFwdGF0aW9uLg0KDQoNCg0KSW4gZmFjdCwgZnJvbSBD UCB0byBDRE4sICB0aGVyZSBhcmUgdGhlIHJlYWwgYnVzaW5lc3NlcyB0aGF0IGVpdGhlciBsZXQg Q1AgdG8gcHJvdmlkZSBtdWx0aS1mb3JtYXQgY29udGVudCBvciBsZXQgdGhlIENETiB0byByZWNl aXZlIG9uZSBmb3JtYXQgYW5kIGNvbXBsZXRlIHRoZSB0cmFuc2Zvcm1hdGlvbiwgZGVwZW5kaW5n IG9uIHRoZSBjb25jcmV0ZSBidXNpbmVzcy4NCg0KQnkgdGhlIHNhbWUgbG9naWMsIGZvcm0gdUNE TiB0byBkQ0ROLCBpdCBtYXkgYmUgZWl0aGVyIHRoZSB1Q0ROIHRvIHByb3ZpZGUgbXVsdGktZm9y bWF0IGNvbnRlbnQgb3IgdGhlIGRDRE4gdG8gcmVjZWl2ZSBvbmUgZm9ybWF0IGNvbnRlbnQgYW5k IHRoZW4gY29tcGxldGUgdGhlIHRyYW5zZm9ybWF0aW9uLg0KDQpDdXJyZW50bHkgdGhlcmUgaXMg bm90IHRoZSByZWFsIENETi1DRE4gY29ubmVjdGlvbiwgaGVuY2Ugd2UgYXJlIGJhc2luZyBvdXIg a25vd2xlZGdlIG9uIHRoZSByZWxhdGVkIHNvbHV0aW9uIHRvIG1ha2Ugb3VyIHNvbHV0aW9ucy4N Cg0KDQoNCjMpICAgICBBcyBmb3IgdGhlIHByb2NlZHVyZSBvZiBjb250ZW50IGFkYXB0YXRpb24s IEkganVzdCBkcmFmdCBhIGRpYWdyYW0gYXMgYmVsb3c6DQoNCltjaWQ6aW1hZ2UwMDQucG5nQDAx Q0M5NTk2LjhBQzc5MzcwXQ0KDQoNCg0KWW91IG1heSBzZWUgdGhlIHNvbHV0aW9uIGlzIHJhdGhl ciBjbGVhciBhbmQgdGhlIG1ldGFkYXRhIG5lZWRlZCB3b3VsZCBiZSBjbGVhciBhbHNvLg0KDQoN Cg0KRGVhciwNCg0KQnkgbXkgYW5hbHlzaXMgYWJvdmUsIEkga2luZGx5IGludml0ZSB5b3VyIGlk ZWFzIHdoZXRoZXIgaXQgbWF5IGJlIGFuIGFwcGxpY2FibGUgYW5kIHNpbXBsZSBwYXJ0IGluIHRo ZSBDRE5JIGl0ZW0sIHByb3ZpZGVkIHRoYXQgdGhlIHNvbHV0aW9uIGlzIG9wZW4gdG8gdGhlIHR5 cGVzIG9mIGNvbnRlbnQgYWRhcHRhdGlvbiBhbmQgbWF5IGJlIG9wdGlvbmFsbHkgaW1wbGVtZW50 ZWQgaW4gdGhlIHJlYWwgc29sdXRpb25zL2J1c2luZXNzLiBJIGZlZWwgZm9yIHRob3NlIG9wZXJh dG9ycyB0aGF0IG5lZWQgc3VjaCBmdW5jdGlvbmFsaXR5IGl0IHdvdWxkIGJlIHZlcnkgZ29vZCB3 aGlsZSBpdCBkb2VzIG5vdCBpbXBhY3Qgb3RoZXJzIHRoYXQgZG8gbm90IGltcGxlbWVudCBpdC4N Cg0KVGhhbmtzLg0KDQpaaGlwZW5nDQoNCg0KRnJvbTogV291bmR5LCBSaWNoYXJkIFttYWlsdG86 UmljaGFyZF9Xb3VuZHlAY2FibGUuY29tY2FzdC5jb21dDQpTZW50OiBUaHVyc2RheSwgT2N0b2Jl ciAyNywgMjAxMSA3OjIzIFBNDQpUbzogWmhvdVpoaXBlbmc7ICdtYXJrQGpldC1zdHJlYW0ubmwn OyAnYWxhbi5rYXZhbmFnaEBlcmljc3Nvbi5jb20nDQpDYzogJ2NkbmlAaWV0Zi5vcmcnOyBXb3Vu ZHksIFJpY2hhcmQNClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1j ZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KPkluIHlvdXIgY29tcGFueeKAmXMgd2Vic2l0ZSwgSSBq dXN0IGZpbmQgc29tZSBpbmZvcm1hdGlvbg0KDQpJIGhhdmUgdG8gc3RlcCBpbiBhcyBjby1jaGFp ciBoZXJlLg0KDQpUaGUgZ29hbCBvZiB0aGlzIFdHIGlzIG5vdCB0byBhbGlnbiB2ZW5kb3IgcHJv ZHVjdCByb2FkbWFwcywgb3IgdG8gZXF1YWxpemUgYWxsIHZlbmRvciBvZmZlcmluZ3MsIG9yIHRv IHNwZWNpZnkgdGhlIGVudGlyZSBDRE5JIGVjb3N5c3RlbS4gVGhlIGdvYWwgb2YgdGhpcyBXRyBp cyB0byBlbmFibGUgdGhlIGludGVyY29ubmVjdGlvbiBhbmQgaW50ZXJvcGVyYXRpb24gb2YgdHdv IG9yIG1vcmUgQ0ROcywgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIENETkkgd2cgY2hhcnRlci4N Cg0KSXQgaXMgT0sgdG8gaGF2ZSBhIGRpc2N1c3Npb24gYWJvdXQgd2hldGhlciBjb250ZW50IGFk YXB0YXRpb24gbmVlZHMgdG8gYmUgcGVyZm9ybWVkIGJ5IHRoZSBkQ0ROLCBzaW5jZSB0aGF0IGRl Y2lzaW9uIGltcGFjdHMgdGhlIHVDRE4tZENETiBpbnRlcmZhY2UuIFNvIGxldCdzIGZpbmQgYSBw cm9kdWN0aXZlIHdheSB0byBkaXNjdXNzIHRoaXMgb24gdGhlIG1haWxpbmcgbGlzdCwgYW5kIHRv IGNsb3NlIHRoZSBkaXNjdXNzaW9uIGJ5IElFVEYgODIgKGlmIG5vdCBzb29uZXIpLg0KDQpDYW4g c29tZW9uZSBkZXNjcmliZSByZWFsLWxpZmUgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBDRE4g KG9yIGVkZ2UgY2FjaGUtYmFzZWQpIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBuZWVkZWQgdG9kYXkg aW4gYSBwcm9kdWN0aW9uIGVudmlyb25tZW50LCBvciBzaG9ydGx5PyBOb3QgbWVyZWx5IGEgZmVh dHVyZSBpbiBhIHZlbmRvcidzIHByb2R1Y3QgbWF0ZXJpYWxzPw0KDQpTcGVha2luZyBhcyBhbiBp bmRpdmlkdWFsLCBJIGNhbiBmaW5kIGEgbG90IG9mIGV4YW1wbGVzIHdoZXJlIGRvd25zdHJlYW0g Y29udGVudCBhZGFwdGF0aW9uIGlzIG5vdCBuZWVkZWQsIGFuZCBhbnkgYWRhcHRhdGlvbiBpcyBy ZWFsbHkgcGFydCBvZiB0aGUgQ1AgLSB1Q0ROIGludGVyZmFjZSAod2hpY2ggaXMgb3V0IG9mIHRo ZSBzY29wZSBvZiBvdXIgY2hhcnRlcikuDQoNCi0tIFJpY2gNCg0KDQpGcm9tOiBaaG91WmhpcGVu ZyBbbWFpbHRvOnpob3V6aGlwZW5nQGh1YXdlaS5jb21dDQpTZW50OiBUaHVyc2RheSwgT2N0b2Jl ciAyNywgMjAxMSAwMzo0NSBBTQ0KVG86IE1hcmsgZGUgSm9uZyA8bWFya0BqZXQtc3RyZWFtLm5s PjsgQWxhbiBLYXZhbmFnaCA8YWxhbi5rYXZhbmFnaEBlcmljc3Nvbi5jb20+DQpDYzogY2RuaUBp ZXRmLm9yZyA8Y2RuaUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KSGVsbG8gTWFyaywNCk5pY2UgdG8g bWVldCB5b3Ugb24gbGluZS4NCkluIHlvdXIgY29tcGFueeKAmXMgd2Vic2l0ZSwgSSBqdXN0IGZp bmQgc29tZSBpbmZvcm1hdGlvbiB0aGF0IGFkZHJlc3NlcyDigJwgVm9kYWZvbmUgc3Vic2NyaWJl cnMgY29tcGxhaW5lZCBhYm91dCB2aWRlbyBwZXJmb3JtYW5jZS7igJ0NClNlZToNCmh0dHA6Ly93 d3cuamV0LXN0cmVhbS5ubC9zZWFyY2gvP3NlYXJjaD10cmFuc2NvZGluZw0KDQpEZWFyIGFsbCBp biB0aGlzIGdyb3VwLA0KSW4gbGFzdCBmZXcgZGF5cywgZXhjZXB0IHRoZSBwdWJsaWMgZW1haWwg ZGlzY3Vzc2lvbnMgSSBoYXZlIGNvbnRhY3RlZCB3aXRoIHNvbWUgcGVvcGxlIGFuZCBkaXNjdXNz ZWQgd2l0aCBteSBvd24gY29sbGVhZ3VlcyBvZiBhbGwgZGV0YWlscyBvbiB0aGlzIGlzc3VlLg0K Rmlyc3QsIGFsdGhvdWdoIHRoZSBtYXJrZXQgcmVxdWlyZW1lbnQgZm9yIGl0IGlzIHZlcnkgaW1w b3J0YW50LCBJIGZlZWwgSeKAmWQgYmV0dGVyIHNob3cgdXAgbW9yZSBpbmZvcm1hdGlvbiBvbiB0 aGUgcHJvY2VkdXJlIGludm9sdmVkLiBJIGhhdmUgZXhwbGFpbmVkIG1hbnkgdGltZXMgdGhhdCB0 byBzdXBwb3J0IGNvbnRlbnQgYWRhcHRhdGlvbiBpcyByYXRoZXIgc2ltcGxlIHdoaWxlIHRoZSB3 b3JkaW5nIGlzIG5vdCBlbm91Z2guDQpJIGFtIGJ1c3kgbWFraW5nIHNvbWUgY29udHJpYnV0aW9u cyBvbiB0aGlzIGFuZCBwbGFuIHRvIHVwbG9hZCB0byBFVFNJIG1lZXRpbmcgYW5kIElFVEYgQ0RO SS4NCkJ5IHRoZXNlIHdvcmsgIEkgZmVlbCB0aGUgcGVvcGxlIG1heSBjYXRjaCBhIHdob2xlIHZp ZXcgb24gdGhpcyBpc3N1ZS4NClNlY29uZCwgZm9yIHRoYXQgZnVuY3Rpb25hbGl0eSwgaW4gaW1w bGVtZW50YXRpb24sIGlmIHNvbWUgZW50aXR5IGRvZXMgbm90IGNob29zZSB0byBzdXBwb3J0IGl0 LCBpdCBtYXkgYmUgb2suIFNpbmNlIGl0IG1heSBiZSBuZWdvdGlhdGVkIGJldHdlZW4gdHdvIENE TnMuDQpJZiBkQ0ROIGRvZXMgbm90IHN1cHBvcnQgdGhhdCwgaXQgbWF5IGJlIHRoZSB1Q0ROIHJl c3BvbnNpYmxlIHRvIGNvbXBsZXRlIHRoZSB0cmFuc2NvZGluZyBhbmQgZGVsaXZlciB0aGUgY29u dGVudCBvZiBtdWx0aXBsZSBmb3JtYXRzIGFuZCByYXRlcyB0byBkQ0ROLg0KVGhpcmQsIGFsdGhv dWdoIENETkkgaXMgYSBuZXcgYXJjaGl0ZWN0dXJlLCB3aGlsZSB0aGUgY29udGVudCBvcGVyYXRp bmcgaGFzIGJlZW4gZXhpc3RlZCBmb3IgeWVhcnMuIEFzIEkga25vdyB0aGUgY29udGVudCBmcm9t IFVTQSB0byB0aGUgZG93bnN0cmVhbSBvcGVyYXRvciBpcyB0cmFuc2ZlcnJlZCBvbiBvbmUgY29w eSBhbmQgdGhlIGRvd25zdHJlYW0gb3BlcmF0b3Igd2lsbCBoYW5kbGUgdGhlIHRyYW5zY29kaW5n Lg0KDQpQZXJoYXBzLCB0aGUgY29udGVudCBhZGFwdGF0aW9uIGlzIG1vcmUgb24gdGhlIG1vYmls ZSBvcGVyYXRpbmcuIEJ1dCBJIGZlZWwgY3VycmVudGx5IG1vc3Qgb3BlcmF0b3Igd2lsbCBiZSBh IGFsbCBzZXJ2aWNlIG9wZXJhdG9yLiBBbmQgZm9yIHRoZSBDRE4gcHJvdmlkZXJzLCBpdCBtYXkg YmUgYmV0dGVyIHRvIHN1cHBvcnQgYWxsIGtpbmRzIG9mIHNlcnZpY2UuDQpCZXNpZGVzLCBJIGxp a2Ugc2F5IHRoYXQgdGhlIHRlY2hub2xvZ3kgb24gdGhpcyB0b3BpYyBoYXMgYmVlbiBmb3IgbWFu eSB5ZWFycyBhbmQgaGFzIGJlZW4gcmF0aGVyIG1hdHVyZSwgZXZlbiBzb21lIGl0ZW1zIGluIGll dGYgc3VjaCBhcyByZmMzNTA3IGljYXAuIFNvIGZyb20gdGhlIHRlY2huaXF1ZSBwb2ludCBvZiB2 aWV3LCBpdCBpcyBhIG5hdHVyZSBhY3Rpb24gdG8gYmUgaW52b2x2ZWQgaW4gQ0ROIGludGVyY29u bmVjdGlvbi4NClRoYW5rcy4NClpoaXBlbmcNCg0KDQoNCg0KRnJvbTogTWFyayBkZSBKb25nIFtt YWlsdG86bWFya0BqZXQtc3RyZWFtLm5sXQ0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjcsIDIw MTEgNDoyMSBBTQ0KVG86IEFsYW4gS2F2YW5hZ2gNCkNjOiBCZW4gTml2ZW4tSmVua2luczsgWmhv dVpoaXBlbmc7IGNkbmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KSGkgQWxhbiwNCg0KQXMgQmVuIHN0 YXRlZCB0aGUgb3ZlcmFsbCBkaXNjdXNzaW9uIHJpZ2h0IG5vdyBpcyBhYm91dCBkZWxpdmVyeSwg bm90IG9uIGFkYXB0YXRpb24uIEl0IGlzIGhhcmQgZW5vdWdoIHRvIGdldCBjb25zZW5zdXMgb24g dGhlIGRlbGl2ZXJ5IGFzcGVjdCBhbHJlYWR5IG5vdCB0byBtZW50aW9uIHlvdXIgcmVxdWlyZW1l bnQgZnJvbSBjb250ZW50IGFkYXB0YXRpb24gYWRkZWQgdG8gdGhhdCwgc28gSSBhZ3JlZSB3aXRo IEJlbiB3ZSBzaG91bGQgc3RpY2sgd2l0aCB0aGUgZGVsaXZlcnkgYXNwZWN0IGZvciB0aGUgZmly c3Qgc3BlY3MuIEkgY2FuIGltYWdpbmUgdGhpcyBjb3VsZCBiZSBhIGRpc2N1c3Npb24gbGF0ZXIg b24gYnV0IHBsZWFzZSBsZXQgdXMga2VlcCB0aGUgc2NvcGUgb2YgdGhpcyBiZSBjbGVhbiBhbmQg dHJhbnNwYXJlbnQuIEl0IGlzIG9mIGJlbmVmaXQgb2YgZXZlcnlvbmUgdG8gZ2V0IHRoZSBmaXJz dCBzcGVjcyBhcyBmYXN0IGFzIHBvc3NpYmxlLiBUaGFua3MuDQoNCk1ldCB2cmllbmRlbGlqa2Ug Z3JvZXQsDQpLaW5kIHJlZ2FyZHMsDQoNCk1hcmsgZGUgSm9uZw0KSW50ZXJuYXRpb25hbCBCdXNp bmVzcyBEZXZlbG9wZXINCkpldC1TdHJlYW0gQlYNCg0KRS1tYWlsOiBtYXJrQGpldC1zdHJlYW0u Y29tPG1haWx0bzptYXJrQGpldC1zdHJlYW0uY29tPg0KT2ZmaWNlOiArMzEgKDApNTAgNTI2MTgy MA0KTW9iaWxlOiArMzEgKDApNiA4MTEwODI2Mw0KRmF4OiArMzEgKDApNTAgNTI2NDIxNA0KDQot IEV2ZW50OiBNZWV0IHVzIGF0IFN0cmVhbWluZyBNZWRpYSBFdXJvcGUsIDE3LTE4IE9jdG9iZXIs IExvbmRvbiwgVUsNCi0gRXZlbnQ6IE1lZXQgdXMgYXQgT25saW5lIFZpZGVvIFN0cmF0ZWdpZXMs IDE5IE9jdG9iZXIsIExvbmRvbiwgVUsNCi0gRXZlbnQ6IE1lZXQgdXMgYXQgQ0ROIFdvcmxkIFN1 bW1pdCwgMjUtMjggT2N0b2JlciwgTG9uZG9uLCBVSw0KLSBOZXdzOiBQcmUtcmVxdWVzdCB5b3Vy IFRlY2hub2xvZ3kgV2hpdGVwYXBlciBub3cgYW5kIGJlIHRoZSBmaXJzdCB0byBoYXZlIGl0LCBj aGVjayB3d3cuamV0LXN0cmVhbS5jb208aHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbT4NCi0gTmV3 czogQ2hlY2sgaHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbSB0byBkb3dubG9hZCBvdXIgJ1NpeCBU cmVuZHMgaW4gQ0ROcycgYnJvY2h1cmUNCg0KLSBCbG9nOiB3d3cuamV0LXN0cmVhbS5jb20vYmxv Zy88aHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbS9ibG9nLz4NCi0gVmlkZW9FeGNoYW5nZTogd3d3 LnZkby14Lm5ldDxodHRwOi8vd3d3LnZkby14Lm5ldD4NCi0gU3RyZWFtemlsbGE6IHd3dy5zdHJl YW16aWxsYWNkbi5jb208aHR0cDovL3d3dy5zdHJlYW16aWxsYWNkbi5jb20+DQotIENvcnBvcmF0 ZTogd3d3LmpldC1zdHJlYW0uY29tPGh0dHA6Ly93d3cuamV0LXN0cmVhbS5jb20+DQoNCk9uIDI2 LCBPY3QsMjAxMSwgYXQgODozMyBQTSwgQWxhbiBLYXZhbmFnaCB3cm90ZToNCg0KQmVuDQoNCklt IGFzc3VtaW5nIHRoZW4gYmFzZWQgb24geW91ciBjb21tZW50cyBiZWxvdyBhcmUgeW91IHN1Z2dl c3Rpbmcgd2UgYXJlIGdvaW5nIHRvIGhhdmUgYSBudW1iZXIgb2YgdmVyc2lvbnMgb2YgdGhlIENE Ti1JIE1ldGFkYXRhPw0KDQpJIHN5bXBhdGhpc2Ugd2l0aCB3aGF0IHlvdSBhcmUgcG9pbnRpbmcg b3V0IGJlbG93IGFuZCBkbyBhZ3JlZSB0aGF0IHRoZXJlIGlzIHNvbWUgd29yayB0byBiZSBkb25l LCBidXQgSSBzdGlsbCBmZWVsIHRoYXQgY29udGVudCBhZGFwdGF0aW9uIGlzIHRvIG1lIGEgZnVu ZGFtZW50YWwgcmVxdWlyZW1lbnQgdG8gd2hhdCBjb2xsZWN0aXZlbHkgd2Ugc2hvdWxkIGFkZHJl c3MgaW4gdGhlIENETi1JIFdHLiBJIGRvIGFncmVlIHdpdGggeW91IHRoYXQgY29udGVudCBhZGFw dGF0aW9uIGlzIGFuIG9wdGltaXphdGlvbiBiZXR3ZWVuIENETidzIGJ1dCBpdCdzIGEgdmVyeSBp bXBvcnRhbnQgb25lIHRoYXQgSSBrbm93IE5ldHdvcmsgU2VydmljZSBQcm92aWRlcnMgcGFydGlj dWxhcmx5IHJlcXVpcmUuDQoNCkFsYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IGNkbmktYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnPiBb bWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbiBOaXZlbi1KZW5r aW5zDQpTZW50OiBPY3RvYmVyLTEyLTExIDE6MTMgUE0NClRvOiBaaG91WmhpcGVuZw0KQ2M6IGNk bmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NETmldIEkt RCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0DQoNClpoaXBlbmcsDQoN Ck9uIDEyIE9jdCAyMDExLCBhdCAxMDoyMiwgWmhvdVpoaXBlbmcgd3JvdGU6DQoNCkhlbGxvIEJl biwNClRoZSBVRSBtYXkgc2VsZWN0IHRoZSBjb250ZW50IGZvcm1hdCBvbiB0aGUgQ1Agd2ViLiBB ZnRlciB0aGF0IHRoZSB1c2VyIG9ubHkgZGVzaXJlcyB0byBnZXQgaGlzIHNlbGVjdGVkIGNvbnRl bnQuDQpCdXQgaG93IHRoZSBjb250ZW50IGlzIHRyYW5zZmVycmVkIHRvIHRoZSBjbGllbnQgaXMg bm90IHdvcnJpZWQgYnkgdGhlIHVzZXIuDQpUaGUgQ1AgbWF5IGNyZWF0ZSBhIHNwZWNpYWwgZm9y bWF0IGFzIHJlcXVpcmVkIGJ5IHRoZSB1c2VyIGFuZCBhc2sgdGhlIENETiB0byBkZWxpdmVyIHRv IHVzZXIuDQpXaGlsZSBDUCBtYXkgZ2l2ZSBhIEhEIGZvcm1hdCBjb250ZW50IHRvIHVDRE4gYW5k IHRoZSBkQ0ROIG1heSB0aGVuIHRyYW5zZm9ybSB0byB0aGUgZm9ybWF0IGFzIHRoZSB1c2VyIHNl bGVjdC4NCg0KTG90cyBvZiB0aGluZ3MgbWF5IGJlIHBvc3NpYmxlIHRvIGRvIGFuZCBDRE4gcHJv dmlkZXJzIG9mZmVyIG1hbnkgYWRkaXRpb25hbCBzZXJ2aWNlcyBvbiB0b3Agb2YgdGhlICJjb3Jl IiBzZXJ2aWNlIG9mIGNvbnRlbnQgZGVsaXZlcnkuIEhvd2V2ZXIsIG91ciBvYmplY3RpdmUgKGJh c2VkIG9uIG15IGludGVycHJldGF0aW9uIG9mIHRoZSBDRE5JIGNoYXJ0ZXIpIGlzIHRvIGZvY3Vz IG9uIHdoYXQgaXMgbmVjZXNzYXJ5IHRvIGludGVyY29ubmVjdCBDRE5zIHRvIGRlbGl2ZXIgY29u dGVudCBmcm9tIGEgQ1NQIHRvIGFuIEVuZCBVc2VyIHRoYXQgaXMgdGFyZ2V0ZWQgYW5kIGRlcGxv eWFibGUgd2l0aGluIGEgc2hvcnQgdGltZSBmcmFtZSAoMTgtMjQgbW9udGhzKS4NCg0KQ29udGVu dCB0cmFuc2Zvcm1hdGlvbi9hZGFwdGF0aW9uIGlzIG5vdCBhbiBlc3NlbnRpYWwgcmVxdWlyZW1l bnQgaW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGF0IGFpbSAod2UgY2FuIGRlbGl2ZXIgY29udGVudCBm cm9tIENTUHMgdG8gRW5kIFVzZXJzIHZpYSBtdWx0aXBsZSBDRE5zIHdpdGhvdXQgbmVlZGluZyBv ciByZXF1aXJpbmcgYW55IENETiBzdXBwb3J0cyBjb250ZW50IGFkYXB0YXRpb24pLg0KDQpJbiBt eSBvcGluaW9uIHdlIGhhdmUgZW5vdWdoIHdvcmsgdG8gZG8gYWxyZWFkeSB3aXRob3V0IHRyeWlu ZyB0byBleHBhbmQgdGhlIHNjb3BlIG9mIG91ciB3b3JrIHRvIGluY2x1ZGUgYWRkaXRpb25hbCBy ZXF1aXJlbWVudHMgdGhhdCBkbyBub3QgaGVscCB1cyBhZGRyZXNzIG91ciBjb3JlIG9iamVjdGl2 ZXMgYXMgbGFpZCBvdXQgaW4gdGhlIENETkkgY2hhcnRlci4NCg0KSW4gdGhpcyBjYXNlLCBpdCBp cyBub3RoaW5nIHJlbGF0ZWQgdG8gaG93IHRoZSB1c2VyIHNlbGVjdCBmb3JtYXRzIG9uIENQIHdl YnNpdGUuDQpTbywgaXQgaXMgdGhlIENQIGFuZCB1c2VyIHRvIGRlY2lkZSB0aGUgY29udGVudCBm b3JtYXQgbm90IHRoZSBDRE4oeW91ciBhc3NlcnQgaXMgbm90IGNvcnJlY3QgYW5kIHNlZW1zIHlv dSB0YWtlIHRoYXQgYXNzZXJ0IGFzIHlvdXIgYmFzZSBmb3IgdGhlIGRpc2N1c3Npb24pLg0KDQpB cyBmb3IgInRoZSBjb3JlIENETiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgQ0ROcyB0b2RheSIs IEkgaGF2ZSBldmVyIHJhaXNlZCBhbiBlbWFpbCBiZWZvcmUgdGhhdCB5b3VyIGNvbXBhbnkncyB3 ZWJwYWdlIGhhcyBjbGFpbWVkIHN1cHBvcnRpbmcgbWVkaWEgdHJhbnNmb3JtYXRpb24gYW5kIG11 bHRpLXNjcmVlbiBzZXJ2aWNlLg0KUGVyaGFwcywgSSBsaWtlIGFza2luZyB5b3UgbGlzdCBzb21l IGZlYXR1cmVzIHRoYXQgeW91IGZlZWwgYXJlIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdGllcyBieSBl eGlzdGluZyBtYWluIHN0cmVhbSBDRE5zLiBUaHVzIHdlIG1heSBjb21wYXJlIGFuZCB0YWtlIGRl ZXAgbG9vay4NCg0KSSB0aGluayB0aGUgY29yZSBmdW5jdGlvbmFsaXR5IG1hcHMgcHJldHR5IHdl bGwgdG8gdGhlIENETkkgaW50ZXJmYWNlcywgbmFtZWx5OiBSZXF1ZXN0IFJvdXRpbmcsIE1ldGFk YXRhIGNvbmZpZ3VyYXRpb24sIGxvZyBwcm9kdWN0aW9uIGFuZCBjb250cm9sIHBsdXMgY29udGVu dCBhY3F1aXNpdGlvbiBhbmQgY29udGVudCBkZWxpdmVyeS4NCg0KSSBndWVzcyBtYW55IHBlb3Bs ZSBoYXZlIHRoZSBleHBlcmllbmNlL2tub3dsZWRnZSBvZiBjb250ZW50IHJlbGF0ZWQgc2Vydmlj ZS4gVGhlIHVzZXIgYW5kIENQIG9ubHkgY2FyZSB3aGV0aGVyIHRoZSBDRE4gcHJvdmlkZXJzIG1h eSBzYXRpc2Z5IHRoZWlyIHJlcXVpcmVtZW50IHdoaWxlIG5vdCBjYXJlIHRoZSBpbnRlcm5hbCBw cm9jZXNzLiBKdXN0IGFzIEdTTS9QU1ROIGludGVyY29ubmVjdGlvbiwgdGhlIHVzZXIgb25seSBj YXJlIHN1Y2Nlc3NmdWwgaW50ZXJjb25uZWN0aW9uIHdoaWxlIG5vdCBjYXJlIGhvdyB0aGUgdm9p Y2UgaXMgdHJhbnNmb3JtZWQgaW4gcHJvY2Vzcy4NCg0KQmVzaWRlcywgSSBsaWtlIHJhaXNlIGEg Y2FzZToNCkdpdmVuIGN1cnJlbnRseSBCQkMgcmVjcnVpdHMgQ0ROIHByb3ZpZGVycyB0aGF0IG1h eSBzdXBwb3J0IDEwIG1lZGlhIGZvcm1hdHMuDQpPbmUgY2FuZGlkYXRlIGlzIHlvdXIgY29tcGFu eSwgYW5vdGhlciBpcyBDRE4tWC4gVGhlIHVzZXJzIGFyZSBsb2NhdGVkIGluIEZyYW5jZS4NClNv IGJvdGggeW91ciBjb21wYW55IGFuZCBDRE4tWCBzaG91bGQgY29ubmVjdCBhIEZyYW5jZSBDRE4g cHJvdmlkZXIoQ0ROLVkpLg0KSWYgeW91ciBjb21wYW55J3Mgc29sdXRpb24gaXMgdG8gc2VuZCAx MCBzdHJlYW1zIG9mIGRpZmZlcmVudCBmb3JtYXQNCm9mIG9uZSBjb250ZW50IHRvIENETi1ZOyBX aGlsZSBDRE4tWCdzIHNvbHV0aW9uIGlzIHRvIHNlbmQgMSBzdHJlYW0gdG8gQ0ROLVkgd2hpbGUg Q0ROLVkgbWF5IGNvbmR1Y3Qgc29tZSBhZGFwdGF0aW9uLg0KQ29tcGFyaW5nIHRoZXNlIHR3byBz b2x1dGlvbnMsIGZvciB5b3VyIGNvbXBhbnkgYW5kIENETi1YLCBhYnNvbHV0ZWx5IHRoZSBjb3N0 IG9mIENETi1YIGlzIG11Y2ggbG93ZXIuDQpGb3IgQ0ROLVksIGluIHNvbHV0aW9uLTEsIGl0IHNo b3VsZCByZWNlaXZlL2ZvcndhcmQgMTAgc3RyZWFtcyA7IHdoaWxlIGluIHNvbHV0aW9uLTIsIGl0 IHNob3VsZCBvbmx5IHJlY2VpdmUgMSBzdHJlYW0gYnV0IG5lZWQgdG8gdGFrZSB0cmFuc2Zvcm1h dGlvbiB0byBvdXRwdXQgMTAgc3RyZWFtcy4NCg0KV2hpY2ggc29sdXRpb24gaXMgbW9yZSBjb21w ZXRpdGl2ZS4gaXQgaXMgU29sdXRpb24gMSwgcmlnaHQuIFJlbWVtYmVyIHRoZSBwcmljZSBmcm9t IEJCQyBpcyBzYW1lIHRvIGJvdGggeW91ciBjb21wYW55IGFuZCBDRE4tWCBvciBCQkMgd291bGQg c2VsZWN0IG9uZSBDRE4gcHJvdmlkZXIgd2l0aCB0aGUgbG93ZXIgcHJpY2UuDQpJZiBhIENETiBw cm92aWRlciBtYXkgbm90IGdldCB0aGUgY29udHJhY3QgZnJvbSBDUCwgaG93IGl0IG1heSBzYXkg aXQgaXMgbm90IGEgY29yZSBmdW5jdGlvbmFsaXR5Lg0KDQpXaGF0IHlvdSBhcmUgZGVzY3JpYmlu ZyBpcyBhIHBvc3NpYmxlIG9wdGltaXphdGlvbiB0aGF0IGEgcGFydGljdWxhciBDRE4gbWF5IHdp c2ggdG8gaW1wbGVtZW50IG5vdCBhIGNvcmUgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCB0byBlbmFi bGUgY29udGVudCBkZWxpdmVyeSBiZXR3ZWVuIGludGVyY29ubmVjdGVkIENETnMuIEkgY2FuIHRo aW5rIG9mIG1hbnkgb3B0aW1pemF0aW9ucyB0aGF0IGEgQ0ROIGNvdWxkIGltcGxlbWVudCB0byBk aWZmZXJlbnRpYXRlIHRoZWlyIHNlcnZpY2UgYnV0IHRoZSBpbnRlcm5hbCB3b3JraW5ncyBvZiBh biBpbmRpdmlkdWFsIENETiBhcmUgb3V0IG9mIHNjb3BlIG9mIG91ciBjaGFydGVyLg0KDQpTbyB0 byByZXBlYXQgbXkgcG9zaXRpb24gZm9yIGEgZmluYWwgdGltZTogQ29udGVudCBhZGFwdGF0aW9u IGlzIG5vdCBhIGNvcmUgZnVuY3Rpb24gcmVxdWlyZWQgdG8gZW5hYmxlIGNvbnRlbnQgZGVsaXZl cnkgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5zIGFuZCB0aGVyZWZvcmUgZ2l2ZW4gdGhlIHdv cmtsb2FkIHdlIGFscmVhZHkgaGF2ZSB0byBzcGVjaWZ5IHNvbHV0aW9ucyB0aGF0IGRvIGFkZHJl c3MgdGhlIGNvcmUgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCB0byBpbnRlcmNvbm5lY3QgQ0ROcyBJ IGRvIG5vdCB0aGluayB3ZSBzaG91bGQgYmUgdHJ5aW5nIHRvIGFkZCBtb3JlIHdvcmsgaW50byB0 aGF0IHdvcmtsb2FkIGFzIGl0IHdpbGwgb25seSBkaXN0cmFjdCB1cyBmcm9tIGFjaGlldmluZyBv dXIgZ29hbCBvZiBwcm9kdWNpbmcgZGVwbG95YWJsZSBzb2x1dGlvbnMgd2l0aGluIHRoZSB0aW1l ZnJhbWUgd2UgYXJlIGJlaW5nIHRvbGQgYnkgb3BlcmF0b3JzIHRoZXkgbmVlZHMgc29sdXRpb25z IHdpdGhpbi4NCg0KQmVuDQoNClNvLCBpZiB3ZSBhbGwgcmVhbGl6ZSB0aGF0IGN1cnJlbnRseSB0 aGUgbWVkaWEgdHlwZSBpcyByaWNoLCB0aGUgQ0ROIHByb3ZpZGVycyBzaG91bGQgc3Vydml2ZSBp biB0aGUgZXhpc3RpbmcgZWNvc3lzdGVtIGFuZCBzdXBwb3J0IHRoZSBtZWRpYSB0eXBlcyBhcyBy ZXF1aXJlZCBieSB0aGUgbWFya2V0Lg0KDQpCYWNrIHRvIHRoZSBjYXNlIG9mIEdTTS9HLjcxMSwg aXQganVzdCB3aGVuIGNvbmNlcm5pbmcgdGhlIGludGVyY29ubmVjdGlvbiwgdGhlIHRyYW5zZm9y bWF0aW9uIHNob3VsZCBhdCBvbmNlIGJlIHNvbHZlZC4gT3RoZXJ3aXNlIHRoZSBpbnRlcmNvbm5l Y3Rpb24gbWF5IG5vdCBiZSBvcGVyYXRlZC4NCg0KQnIsDQpaaGlwZW5nDQoNCg0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZW4gTml2ZW4tSmVua2lucyBbbWFpbHRvOmJl bkBuaXZlbi1qZW5raW5zLmNvLnVrXQ0KU2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEyLCAyMDEx IDEyOjE5IEFNDQpUbzogWmhvdVpoaXBlbmcNCkNjOiBwaGlsaXAuZWFyZGxleUBidC5jb208bWFp bHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbT47IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11 c2UtY2FzZXMtMDAudHh0DQoNClpoaXBlbmcsDQoNCk9uIDExIE9jdCAyMDExLCBhdCAwNToxNiwg WmhvdVpoaXBlbmcgd3JvdGU6DQoNCkJlbiBhbmQgUGhpbGlwLA0KSSBsaWtlIHRvIHJlc3BvbmQg eW91ciBjb25jZXJuIGluIHRoaXMgb25lIGVtYWlsOg0KDQpCZW4sDQpJIGZlZWwgd2hhdCB3ZSBh cmUgbm93IGRpc2N1c3NpbmcgaXMgd2hhdCBpcyB0aGUgImNvcmUiIGZ1bmN0aW9uIG9mIENETi4N CkFzIHlvdSBzYXksIENETiBpcyB1c2VkIHRvIGRlbGl2ZXIgY29udGVudC4gVGhhdCBpcyBhYnNv bHV0ZWx5IGNvcnJlY3QgdGhhdCB0aGUgZGVsaXZlcnkgY2FwYWJpbGl0eSBpcyB0aGUgY29yZSBy ZXF1aXJlbWVudCBmb3IgQ0ROIHN5c3RlbS4NCldoaWxlIENETiBpcyB1c2VkIHRvIHByb3ZpZGUg dGhlIGNvbnRlbnQgZGVsaXZlcnkgc2VydmljZS4NCldoYXQgbWVhbnMgc2VydmljZS4gSXQgc2hv dWxkIGluY2x1ZGUgInRpbWUiICJsb2NhdGlvbiIgYW5kICJtZWRpYSB0eXBlIiwgZXRjLiBUaGVz ZSBmZWF0dXJlcyBhcmUgYWxsIHRoZSBjb3JlIGZlYXR1cmUgZm9yIGEgc2VydmljZS4NCklmIHdl IG9ubHkgY29uY2VybiAiZGVsaXZlcmluZyBvbmUgZGF0YSBibG9jayIsIEkgYW0gbm90IHN1cmUg d2hldGhlciB0aGUgaXNzdWVzIHN1Y2ggYXMgImxvZ2dpbmciICJnZW9ncmFwaGljIGNvbnN0cmFp bnQiIGFyZSB0aGUgY29yZSBvZiBDRE4uDQoNCkZvciAid2l0aG91dCBleHBsaWNpdCBrbm93bGVk Z2Ugb2Ygd2hhdCB0aGF0IGNvbnRlbnQgYWN0dWFsbHkgaXMgIiwgSSBhbSBub3Qgc3VyZSB3aGV0 aGVyIHRoZSB3b3JkaW5nIGlzIGFjY3VyYXRlIHNpbmNlIGdlbmVyYWxseSBhIENETiBtYXkgY2xh aW0gaXQgc3VwcG9ydCBkaWZmZXJlbnQgbWVkaWFzLg0KQnkgdGhpcyBvcHBvcnR1bml0eSwgSSBs aWtlIHRvIHNoYXJlIGEgdXNlIGNhc2U6IGEgY2FsbCBmcm9tIGEgR1NNIHBob25lIHRvIGEgUFNU TiB0ZWxlcGhvbmUsIHRoZSB2b2ljZSBzdHJlYW0gc2hvdWxkIGJlIHRyYW5zZm9ybWVkIGZyb20g R1NNIHZvaWNlIHRvIEcuNzExLg0KRm9yIHRoZSB1c2VyLCBoZSBkb2VzIG5vdCBuZWVkIHRvIGtu b3cgd2hhdCB0eXBlIG9mIGRhdGEgaGFzIGJlZW4gdHJhbnNmZXJyZWQsIGJ1dCB0aGUgb3BlcmF0 b3IgaGFzIGRvbmUgc29tZSB3b3JrIHRvIGludGVyY29ubmVjdCB0d28gc3lzdGVtcywgcmlnaHQu DQpJIGxpa2UgdG8ga25vdyB3aGV0aGVyIHlvdSBtYXkgYWNjZXB0IHRoYXQgbXkgdXNlIGNhc2Ug aXMgc2ltaWxhciB0byB0aGlzIGNhc2UgYWJvdmUuDQoNCkkgZG9uJ3QgdGhpbmsgeW91ciB1c2Ug Y2FzZSBpcyBzaW1pbGFyIHRvIHRoZSBhbmFsb2d5IG9mIG1vYmlsZSBuZXR3b3JrcyBiZWluZyBp bnRlcmNvbm5lY3RlZCB0byBQU1ROIG5ldHdvcmtzLiBJbiB0aGUgY2FzZSBvZiBjb250ZW50IGRl bGl2ZXJ5IHRoZSBuZWdvdGlhdGlvbiBpcyBkb25lIGJldHdlZW4gdGhlIFVzZXIvQ2xpZW50IGFu ZCB0aGUgQ29udGVudCBQcm92aWRlciBhbmQgdGhlIENETiBpcyBqdXN0IHVzZWQgdG8gZXhlY3V0 ZS9wZXJmb3JtIHRoZSBkZWxpdmVyeSB0aGF0IGhhcyBiZWVuIG5lZ290aWF0ZWQuIFRoZSBDRE4g aXMgbm90IGludm9sdmVkIGluIHRoZSBkZWNpc2lvbiBtYWtpbmcgb2Ygd2hhdCByZXByZXNlbnRh dGlvbnMgdGhlIENvbnRlbnQgUHJvdmlkZXIgZGVjaWRlcyB0byBvZmZlciB0byB0aGUgVXNlci9D bGllbnQgb3IgaW4gd2hhdCByZXByZXNlbnRhdGlvbnMgdGhlIFVzZXIvQ2xpZW50IGRlY2lkZXMg dG8gcmVxdWVzdC4NCg0KQXMgZm9yIHlvdSBzYWlkIHNlbGVjdGluZyBtZWRpYSBieSB0aGUgInBv cnRhbCIsIHlvdSBtYXkgc2VlIHRoZSB3YXkgIiB1Q0ROIGRlbGl2ZXJzIG11bHRpcGxlIG1lZGlh IHN0cmVhbXMgdG8gZENETiIgaXMgbm90IGdvb2QgdGhhbiAidUNETiBkZWxpdmVycyBvbmUgbWVk aWEgc3RyZWFtIHRvIGRDRE4gYW5kIGRDRE4gdGFrZXMgc29tZSBhZGFwdGF0aW9uIHRvIHN1cHBv cnQgbXVsdGlwbGUgbWVkaWEgdHlwZXMiLg0KDQpOb3cgd2hhdCB5b3UncmUgdGFsa2luZyBhYm91 dCBpcyBhbiBvcHRpbWlzYXRpb24sIG5vdCBhIGNvcmUgZnVuY3Rpb24gcmVxdWlyZWQgdG8gYWN0 dWFsbHkgZGVsaXZlciB0aGUgY29udGVudCAoYW5kIHJlcG9ydCwgYmlsbCwgZXRjLiBmb3IgdGhh dCBkZWxpdmVyeSkuDQoNCk15IHBvc2l0aW9uIGlzIHRoYXQgd2Ugc2hvdWxkIGZvY3VzIG9uIGhv dyB0byBlbmFibGUgdGhlIGludGVyY29ubmVjdGlvbiBvZiB0aGUgY29yZSBDRE4gZnVuY3Rpb25h bGl0eSBvZmZlcmVkIGJ5IENETnMgdG9kYXkgKHdoaWNoIGlzIGFsc28gbXkgaW50ZXJwcmV0YXRp b24gb2YgdGhlIHNjb3BlIG9mIHRoZSBDRE5JIHdvcmtpbmcgZ3JvdXAgYXMgZXhwcmVzc2VkIGlu IGl0cyBjaGFydGVyKSBiZWNhdXNlIGRvaW5nIHNvIGlzIGEgc2lnbmlmaWNhbnQgcGllY2Ugb2Yg d29yayBpbiBpdHNlbGYuIExldCdzIG5vdCBzdGFydCB0cnlpbmcgdG8gYWRkIGluIGFkZGl0aW9u YWwgZnVuY3Rpb25hbGl0eSBiZXlvbmQgd2hhdCB0aGUgbWFqb3JpdHkgb2YgQ0ROcyBzdXBwb3J0 IHRvZGF5IGFzIHRoYXQgd2lsbCBqdXN0IGRlbGF5IHVzIGdldHRpbmcgdXNhYmxlIHNwZWNpZmlj YXRpb25zIGludG8gdGhlIG1hcmtldCBpbiBhIHRpbWVseSBmYXNoaW9uIElNTy4NCg0KQmVuDQoN CkEgZ29vZCBxdWVzdGlvbiBpcyAic2VjdXJpdHkiIHNpbmNlIEkgaGF2ZSBkb25lIHNpeCB5ZWFy cyBvbiB0aGUgRFJNDQphbmQgbGlrZSB0byBwcm9tb3RlIHRoZSBEUk0gYWxsIGFyb3VuZCB0aGUg d29ybGQ6KSBJZiB0aGUgY29udGVudCBpcyBuZWVkZWQgdG8gYmUgcHJvdGVjdGVkLCBnZW5lcmFs bHkgeW91IG1heSBrbm93IGFsbCB0aGUgc3lzdGVtcyBzaG91bGQgYmUgZ3JhbnRlZCBieSB0aGUg Y29udGVudCBvd25lci4NCkhlcmUgSSBhbHNvIGxpa2UgdG8gY2xhcmlmeSB0aGF0IG5vdCBvbmx5 IHRoZSBtZWRpYSBpdHNlbGYgYnV0IHRoZSBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHNlcnZpY2Ug aXRzZWxmIChzdWNoIGFzIHRoZSBnZW9ncmFwaGljIGNvbnN0cmFpbnQpIHNob3VsZCBiZSBwcm90 ZWN0ZWQgYWxzby4NClNvLCB0cnVzdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgbWVkaWEuDQoN ClBoaWxpcCwNClRoYW5rIHlvdSB0aGF0IHlvdSBmZWVsIENvbnRlbnQgQWRhcHRpb24gaXMgYW4g aXNzdWUgZm9yICJSZXF1aXJlbWVudHMiIGJ1dCBJIGRvIG5vdCBrbm93IHdoeSBpdCBpcyBub3Qg Zm9yIFVzZSBjYXNlLg0KSSBsaWtlIHRvIGNsYXJpZnkgdG8gVSB0aGF0IGl0IGlzIGltcG9ydGFu dCBmb3IgeW91IG9wZXJhdG9yIHNpbmNlIGl0IG1heSBzYXZlIGludmVzdG1lbnQgaWYgdGhlIHN5 c3RlbSBtYXkgc3VwcG9ydCBkaWZmZXJlbnQgc2VydmljZXMuDQpGb3IgdXMgdmVuZG9yLCB3ZSBh cmUgaGFwcHkgb3BlcmF0b3IgbWF5IGluc3RhbGwgYSBzeXN0ZW0gZm9yIHRoZSBtb2JpbGUgc2Vy dmljZSBhbmQgYW5vdGhlciBzeXN0ZW0gZm9yIHRoZSBGQkIgc2VydmljZS4NCkJ1dCB0aGUgcmVh bGl0eSBpcyBhbGwgb3BlcmF0b3JzIGFzayB1cyB0byBwcm92aWRlIGEgc3lzdGVtIHRoYXQgbWF5 IHN1cHBvcnQgZGlmZmVyZW50IHNlcnZpY2Ugc3lzdGVtcy4NCg0KRnJhbmtseSwgQmVuIGFuZCBQ aGlsaXAsIEkgcmVtZW1iZXIgSSBoYXZlIGV4cGxhaW5lZCBzb21ld2hlcmUgdGhhdCB0byBpbXBs ZW1lbnQgdGhpcyBpcyByYXRoZXIgc2ltcGxlIC4NCkF0IGxlYXN0IHRoZSBVc2UgY2FzZSBhbmQg UmVxdWlyZW1lbnQgYXJlIGluZm9ybWF0aW9uYWwgdG8gYmUgcmVmZXJyZWQgaW4gZnV0dXJlIHdv cmsuIFNvIEkgZG8gcmVhbGx5IGZlZWwgeW91IG1heSBhY2NlcHQgaXQuDQpPZiBjb3Vyc2UgSSBs aWtlIHRvIHJlc3BvbmQgeW91ciBtb3JlIGNvbmNlcm4gYW5kIGNvbW1lbnRzLg0KVGhhbmtzLg0K WmhpcGVuZw0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHBoaWxpcC5l YXJkbGV5QGJ0LmNvbTxtYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tPiBbbWFpbHRvOnBoaWxp cC5lYXJkbGV5QGJ0LmNvbV0NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxMCwgMjAxMSAxMToyMiBQ TQ0KVG86IGJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPG1haWx0bzpiZW5Abml2ZW4tamVua2lucy5j by51az47IFpob3VaaGlwZW5nDQpDYzogY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJFOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1j YXNlcy0wMC50eHQNCg0KQmVuLCBaaGlwZW5nLCBhbGwsDQoNCkkgdGhpbmsgdGhhdCBDb250ZW50 IEFkYXB0YXRpb24gaXMgbW9yZSBhbiBpc3N1ZSBmb3IgdGhlIFJlcXVpcmVtZW50cyBkb2MgdGhh biBmb3IgdGhlIFVzZSBjYXNlcyBkcmFmdC4NCg0KVGhlIGtleSBxdWVzdGlvbiBpcyB3aGV0aGVy IHdlIHdhbnQgdGhlIENETkkgaW50ZXJmYWNlcyB0byBiZSBhYmxlIHRvIGNvcGUgd2l0aCBhIHNj ZW5hcmlvIHdoZXJlIChzYXkpIEhEL1NEIGNvbnZlcnNpb24gaXMgZG9uZSBpbiB0aGUgZENETiAm IHRvIHNpZ25hbCBhYm91dCB0aGlzLg0KDQpJIHRoaW5rIHRoYXQgY29waW5nIHdpdGggdGhpcyBz Y2VuYXJpbyBpcyBhIHNlY29uZCBvcmRlciByZXF1aXJlbWVudCwgaWUgd2Ugc2hvdWxkIG5vdCB3 b3JyeSBhYm91dCBpdCBpbiB0aGUgaW5pdGlhbCBzdGFuZGFyZHMtdHJhY2sgd29yay4gSSBkb24n dCBrbm93LCBkaWQgd2UgZXZlciBkZWNpZGUgd2hldGhlciB0aGUgVXNlIGNhc2VzIGRvYyBpcyBy ZXN0cmljdGVkIHRvICJpbml0aWFsIiBzY2VuYXJpb3MsIG9yIHdoZXRoZXIgaXQncyBhbGwtZW5j b21wYXNzaW5nLCBpZSBjb3ZlcmluZyAiZnV0dXJlIiBzY2VuYXJpb3MgYXMgd2VsbD8NCg0KU2Nv dHQsDQpSZWFkaW5nIHNvbWUgb2YgeW91ciBleGFtcGxlcywgdGhleSBzZWVtIHRvIGJlIHZhbGlk IGV2ZW4gaWYgY29udGVudCBhZGFwdGF0aW9uIChIRC9TRCkgaXMgb3V0IG9mIHNjb3BlLg0KLSBh IGRDRE4gbWlnaHQgZm9yIHNvbWUgcmVhc29uIGJlIHVud2lsbGluZyB0byBkaXN0cmlidXRlIEhE Pw0KLSBhIENTUCBtaWdodCB3YW50IHRvIG1ha2Ugc3VyZSB0aGUgZENETiBjYW4gdXNlIEhMUyBl bmNhcHN1bGF0aW9uPw0KQnV0IHRoZXNlIHNvcnRzIG9mIGV4YW1wbGVzIHNlZW0gdG8gYmUgc3Rh dGljIHBvbGljeSB0aGluZ3MgKHRvIGRvDQp3aXRoIHRoZSBjYXBhYmlsaXRpZXMgJiBwcmVmZXJl bmNlcyBvZiB0aGUgQ0ROcyAmIENTUCksIHJhdGhlciB0aGFuDQptZXRhZGF0YSBhc3NvY2lhdGVk IHdpdGggYSBwYXJ0aWN1bGFyIHBpZWNlIG9mIGNvbnRlbnQuIEluIHRoZQ0KZGlzY3Vzc2lvbiBz byBmYXIsIEkgdGhpbmsgbmVnb3RpYXRpb24gYWJvdXQgc3RhdGljIHBvbGljeSBzdHVmZiBpcw0K cmF0aGVyIG91dCBvZiBzY29wZSg/KQ0KDQpPbiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgYW4g aW50ZXJlc3RpbmcgcXVlc3Rpb24gaXMgd2hldGhlciB0cnVzdCBpcyB0cmFuc2l0aXZlLiBEb24n dCB0aGluayBpdCBuZWVkIGJlIC0ganVzdCBiZWNhdXNlIENTUCB0cnVzdHMgdUNETiwgYW5kIHVD RE4gdHJ1c3RzIGRDRE4gZG9lc24ndCBtZWFuIHRoYXQgdGhlIENTUCBhdXRvbWF0aWNhbGx5IHRy dXN0cyB0aGUgZENETi4gSG93ZXZlciwgaSBzdXNwZWN0IHRoaXMgY2FuIGdldCBhcmJpdHJhcmls eSBjb21wbGV4IC0gc28gb25lIHBvc3NpYmlsaXR5IGlzIHRvIHNheSB0aGF0IHdlIHdpbGwgb25s eSBoYW5kbGUgY2FzZXMgd2hlcmUgdGhlIHRydXN0IGlzIHRyYW5zaXRpdmUuDQoNCkJlc3Qgd2lz aGVzDQpwaGlsDQoNCg0KUGhpbGlwIEVhcmRsZXkNClJlc2VhcmNoIGFuZCBUZWNobm9sb2d5IFN0 cmF0ZWd5DQoNClRoaXMgZW1haWwgY29udGFpbnMgQlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBi ZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5k aXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlvdSdyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGlu ZyBvciB1c2luZyB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgbGV0IG1lIGtub3cgaW1tZWRpYXRlbHkg b24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4gV2UgbW9uaXRvciBvdXIgZW1h aWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5b3VyIGVtYWlscy4NCkJyaXRpc2ggVGVsZWNvbW11 bmljYXRpb25zIHBsYw0KUmVnaXN0ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRv biBFQzFBIDdBSiBSZWdpc3RlcmVkIGluDQpFbmdsYW5kIG5vOiAxODAwMDAwDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNkbmktYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 Y2RuaS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmDQpPZiBCZW4gTml2ZW4tSmVua2lucw0KU2VudDogMTAgT2N0b2JlciAyMDExIDEyOjA0 DQpUbzogWmhvdVpoaXBlbmcNCkNjOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNh c2VzLTAwLnR4dA0KDQpDb2xsZWFndWVzLA0KDQpJTU8gU2VjdGlvbiA1LjEuMyBzaG91bGQgYmUg cmVtb3ZlZCBmcm9tIHRoZSBVc2UgQ2FzZXMgZHJhZnQuIENvbnRlbnQgQWRhcHRhdGlvbiAoaS5l LiB0YWtpbmcgaW4gYSBjb250ZW50IGl0ZW0gaW4gb25lIGZvcm1hdCBhbmQgdHJhbnNmb3JtaW5n IGl0IHRvIGFub3RoZXIgZm9ybWF0IG9yIHJlcHJlc2VudGF0aW9uKSBpcyBub3QgYSAiY29yZSIg ZnVuY3Rpb24gb2YgYSBDRE4gd2hpY2ggdHlwaWNhbGx5IGRlbGl2ZXJzIHRoZSBjb250ZW50IHRo YXQgaXMgcmVxdWVzdGVkIHdpdGhvdXQgZXhwbGljaXQga25vd2xlZGdlIG9mIHdoYXQgdGhhdCBj b250ZW50IGFjdHVhbGx5IGlzLg0KDQpMZXQncyBub3QgZm9yZ2V0IHRoYXQgaW4gYnVpbGRpbmcg YW4gZW5kIHRvIGVuZCBjb250ZW50IHNlcnZpY2UgdGhlIENETiBpcyBvbmx5IG9uZSBjb21wb25l bnQgYW5kIGlzIHRoZSBjb21wb25lbnQgdGFza2VkIHdpdGggZXhlY3V0aW5nIHRoZSBkZWxpdmVy eSBvZiBhIHNwZWNpZmljIHJlcHJlc2VudGF0aW9uICh2ZXJzaW9uL2NvcHkvZm9ybWF0IGV0Yy4p IG9mIHRoZSBzZWxlY3RlZCBjb250ZW50IG5vdCB0aGUgY29tcG9uZW50IHRhc2tlZCB3aXRoIGRl Y2lkaW5nIChvciBhcHBseWluZyBwb2xpY3kpIG9uIHdoaWNoIHZlcnNpb24vY29weS9yZXByZXNl bnRhdGlvbiBvZiBjb250ZW50IHNob3VsZCBiZSBkZWxpdmVyZWQuDQoNClRoZSBkZWNpc2lvbiBh cyB0byB3aGljaCB2ZXJzaW9uL2NvcHkvcmVwcmVzZW50YXRpb24gdG8gb2ZmZXIgYW5kIGFsbG93 IHRvIGJlIGRlbGl2ZXJlZCB0byBhIGdpdmVuIGRldmljZS91c2VyIGlzIGltcGxlbWVudGVkIG91 dHNpZGUgb2YgdGhlIENETiAoZS5nLiBieSB0aGUgInBvcnRhbCIgd2hlcmUgdGhlIHVzZXIgZmly c3QgbWFrZXMgdGhlaXIgY29udGVudCBzZWxlY3Rpb24gcHJpb3IgdG8gdGhlIENETiBiZWNvbWlu ZyBpbnZvbHZlZCBpbiB0aGUgZGVsaXZlcnkgb2YgdGhlIHNlbGVjdGVkIGNvbnRlbnQpLg0KDQpC ZW4NCg0KT24gOCBPY3QgMjAxMSwgYXQgMDg6MjAsIFpob3VaaGlwZW5nIHdyb3RlOg0KDQpGb2xs b3dpbmcgU2NvdHQncyBjb21tZW50cyBvbiBzZWN0aW9uIDUuMS4zLCBJIGZlZWwgU2NvdHQncyBk ZXNjcmlwdGlvbiBvbiB0aGUgdXNlIGNhc2Ugb2YgSEQgYW5kIFNEIGlzIG5vdCBleGFjdGx5IGNv cnJlY3QuDQpJZiBvbmUgbW92aWUgaGFzIHR3byBmb3JtYXRzIG9mIEhEIGFuZCBTRCwgdGhlbiB3 ZSBoYXZlIHR3byBjb250ZW50IHdpdGggZGlmZmVyZW50IGlkZW50aWZpZXIuIEluIERSTSBzY29w ZSwgdGhlIGJhc2ljIHVuaXQgaXMgYSBjb250ZW50IGNvcHkuDQoNCkhlcmUgdGhlIGZpcnN0IGJ1 bGxldCAiYSBzdWJzZXQgb2YgZW5jb2RpbmdzIGRlbGl2ZXJhYmxlIHRvIHNwZWNpZmljIGRldmlj ZXMsIiBoYXMgbGlzdGVkIHRoZSBjYXNlIG9mIGNvbnRlbnQgYWRhcHRhdGlvbi4NCkluIGxhc3Qg bW9udGgsIEkgaGF2ZSBjb250YWN0ZWQgdGhlIEF1dGhvcnMgb2YgdGhpcyBkb2N1bWVudCBhbmQg dGFrZW4gc29tZSBlbWFpbCBleGNoYW5nZXMgd2l0aCBHcmFudCBhbmQgUGhpbGlwIChCVCkuDQpJ IGhhdmUgc2hvd24gQlQgd2l0aCBzb21lIGluZm9ybWF0aW9uIHRoYXQgSSBrbm93IGluIHRoaXMg Y2FzZSBhbmQgYXJlYSB0byBleHBsYWluIHRoZSBjb250ZW50IGZsZXhpYmlsaXR5IGlzIGN1cnJl bnRseSBhIGJhc2ljIHJlcXVpcmVtZW50IGZvciBDRE4gc2VydmljZSBhbmQgcmVsYXRlZCBuZWdv dGlhdGlvbiBpcyBuZWVkZWQgaW4gdGhlIENETiBpbnRlcmNvbm5lY3Rpb24uDQpNZWFud2hpbGUs IEkgc2hvdWxkIGFsc28gaW52aXRlIHlvdSBpbiB0aGlzIGdyb3VwIHJhaXNpbmcgeW91ciBjb21t ZW50cyBvciBxdWVzdGlvbnMgb24gdGhpcyBjYXNlIHNpbmNlIEkgaG9wZSBteSB1c2UgY2FzZSBt YXkgYmUgaW5jb3Jwb3JhdGVkIGluIHRoZSB1c2UgY2FzZSBkcmFmdC4NCg0KSWYgeW91IGhhdmUg YW55IG1vcmUgcXVlc3Rpb24gb3IgY29tbWVudHMsIHBscyBzaGFyZSBpbiB0aGlzIHRocmVhZC4N ClRoYW5rcy4NClpoaXBlbmcNCg0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBTY290dCBXYWlubmVyIFttYWlsdG86c3dhaW5uZXJAY2lzY28uY29tXQ0KU2VudDog RnJpZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMTEgODowMiBBTQ0KVG86IGNkbmlAaWV0Zi5vcmc8bWFp bHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0DQoNClNlY3Rpb24gMi4zIE5vbWFkaWMgVXNlcnMN ClRoaXMgZGVzY3JpcHRpb24gZmFsbHMgdW5kZXIgdGhlIGNhdGVnb3J5IG9mIEdlb2dyYXBoaWMg RXh0ZW5zaW9uDQp5ZXQgdGhlIHRoaXJkIHBhcmFncmFwaCBzdGF0ZXMgdGhlIGNhc2Ugd2hlcmUg YSBkaWZmZXJlbnQgZGV2aWNlIGlzDQp1c2VkIGluIHRoZSBzYW1lIENETiBjb3ZlcmFnZSBhcmVh LiAgVGhlIGludGVudCBvZiB0aGlzIHVzZSBjYXNlDQpuZWVkcyB0byBiZSBjbGFyaWZpZWQuICBQ ZXJoYXBzIHRoZSB1c2UgY2FzZSBpcyB0cnlpbmcgdG8gYWRkcmVzcw0KdGhlIHNjZW5hcmlvIHdo ZXJlIGEgTm9tYWRpYyBVc2VyLUEgd2l0aCBhbiBhZ3JlZW1lbnQgYWxsb3dpbmcNCmFjY2VzcyB0 byBjb250ZW50IGZyb20gQ1NQLUEgdmlhIHVDRE4gbW92ZXMgdG8gYSBkQ0ROIGluIGEgZGlmZmVy ZW50DQpyZWdpb24uICBUaGUgZENETiBpcyBhbGxvd2VkIHRvIGRpc3RyaWJ1dGUgdGhlIGNvbnRl bnQgb2YgQ1NQLUEgdG8NClVzZXItQTsgaG93ZXZlciwgbm90IG90aGVyIHVzZXJzIGluIHRoZSBy ZWdpb24gb2YgdGhlIGRDRE4gYXJlDQphbGxvd2VkIHRvIHJldHJpZXZlIHRoZSBjb250ZW50IHVu bGVzcyB0aGV5IHRvbyBoYXZlIHN1Y2ggYW4gYWdyZWVtZW50Lg0KDQpTZWN0aW9uIDUuMS4zIENv bnRlbnQgRW5jb2RpbmcgUmVzdHJpY3Rpb25zIE5lZWQgdG8gY2xhcmlmeSBpZiB3ZSdyZQ0KdGFs a2luZyBhYm91dCB0aGUgcmVzdHJpY3Rpb25zIG9uIHRoZSBkZWxpdmVyeSBvZiBzcGVjaWZpYyBj b250ZW50DQpvciB0aGUgcmVzdHJpY3Rpb25zIG9uIHRoZSBhYmlsaXR5IG9mIGEgQ0ROIHRvIGRl bGl2ZXIgc3BlY2lmaWMNCmNvbnRlbnQuICBJIGNlcnRhaW5seSB1bmRlcnN0YW5kIHRoZSBjYXNl IHdoZXJlIGEgQ1NQIHdpbGwgcmVzdHJpY3QNCnRoZSBkaXN0cmlidXRpb24gb2YgY29udGVudCB0 byBhICJtYW5hZ2VkIHBhdGgiIGlmIHN1Y2ggY29udGVudCBpcw0KSEQgd2hpbGUgYWxsb3dpbmcg dGhlIGNvbnRlbnQgZGlzdHJpYnV0aW9uIHZpYSBhbiB1bi1tYW5hZ2VkIHBhdGggaWYNCnN1Y2gg Y29udGVudCBpcyBTRCAoc2FtZSBjb3VsZCBhcHBseSB0byBlbmNyeXB0aW9uIG1ldGhvZHMsIGRl bGl2ZXJ5DQptZXRob2RzLCBldGMuKS4gIE9uIHRoZSBjb250cmFyeSwgdGhlIGRDRE4gbWF5IGhh dmUgaXRzIG93bg0KcmVzdHJpY3Rpb25zIG9mIGJsb2NraW5nIHRoZSBkaXN0cmlidXRpb24gb2Yg SEQgY29udGVudCB3aGlsZQ0KYWxsb3dpbmcgdGhlIGRpc3RyaWJ1dGlvbiBvZiBTRCBjb250ZW50 Lg0KDQpvIGZpcnN0IGJ1bGxldCBtYWtlcyBzZW5zZSBpZiB0aGUgZENETiBjYW4gcGVyZm9ybSBh IHN1YnNldCBvZg0KZW5jYXBzdWxhdGlvbnMgZm9yIGEgcmVmZXJlbmNlIHNldCBvZiBtZWRpYSAo ZS5nLiBITFMsIEhTUywgYnV0IG5vdA0KREFTSCkgbyBzZWNvbmQgYnVsbGV0IG1ha2VzIHNlbnNl IHdoZXJlIHRoZSBkQ0ROIGRvZXNuJ3Qgd2FudCB0bw0Kb2ZmZXIgaGlnaCBiaXQtcmF0ZSB2YXJp YW50cyBvZiB0aGUgbWVkaWEgbyB0aGlyZCBidWxsZXQgbWFrZSBzZW5zZQ0KaWYgdGhlIHBvbGlj eSBhZGRyZXNzZXMgUW9FIGJ1dCBJIGRvbid0IHRoaW5rIHN1YnNjcmliZXINCnJpZ2h0cy9hdXRo b3JpemF0aW9ucyBhcHBseS4NCg0KU2VjdGlvbiAxMCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0K DQpBc2lkZSBmcm9tIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBXSVRISU4gdGhlIHVDRE4g YW5kIGRDRE4sIEkNCnRoaW5rIHdlIGNhbiBkZXNjcmliZSB0aGlzIGluIGZvdXIgY29udGV4dHM6 DQoNCmEuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQ1NQIGFuZCB0aGUgdUNETiAodGhl IHByaW5jaXBsZSBjb250cmFjdA0KYXJyYW5nZW1lbnQgZm9yIGRpc3RyaWJ1dGlvbikNCmIuIFRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdUNETiBhbmQgZENETiAodGhlIHRyYW5zaXRpdmUg dHJ1c3QNCnJlbGF0aW9uc2hpcCB0aGF0IGV4dGVuZHMgdGhlIGNvbnRyYWN0IGRlZmluZWQgaW4g KGEpIGFib3ZlKSBjLiBUaGUNCnJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBVc2VyIGFuZCBkQ0RO ICh0aGUgcmVjb2duaXRpb24gb2YgcmlnaHQgdG8NCmRvd25sb2FkIHByZWRpY2F0ZWQgb24gKGIp IGFib3ZlKSBkLiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlDQpVc2VyIGFuZCBDU1AgKHRo ZSBjb250cmFjdCBhdXRob3JpemluZyB0aGUgdXNlciBhY2Nlc3MgdG8gdGhlDQpjb250ZW50KQ0K DQpUaGUgdXNlciBpcyBub3QgaW50ZXJlc3RlZCBpbiB0aGUgYS1iIG5vciB0aGUgYi1jIHJlbGF0 aW9uc2hpcC4gVGhlDQp1c2VyIGlzIG9ubHkgaW50ZXJlc3RlZCBpbiB0aGUgdHJhbnNwYXJlbmN5 IGFuZCBpbnRlcm9wZXJhYmlsaXR5IG9mDQp0aGUgc2VjdXJpdHkgcmVsYXRpb25zaGlwIGJldHdl ZW4gZC1iIG9yIGQtYyB0byB0aGUgcG9pbnQgdGhhdCB0aGUNCmF1dGhvcml6YXRpb24gZ3JhbnRl ZCBpbiBkLWEgaXMgdmlhYmxlIHdoZW4gdGhlIGRlbGl2ZXJ5IGlzDQppbml0aWF0ZWQgdmlhIGVp dGhlciBkLWIgb3IgZC1jLiAgQXMgYW4gZXhhbXBsZSwgdGhlIHVDRE4gbWlnaHQgdXNlDQpVUkwg YXBwZW5kZWQgdG9rZW5zIGZvciBhdXRoZW50aWNhdGlvbiB3aGlsZSBkQ0ROIG1pZ2h0IHVzZSBV UkwNCmFwcGVuZGVkIGhhc2hlcy4gIFRoZSB1c2VyIGRvZXNuJ3Qgd2FudCB0byBrbm93IGFib3V0 IHRoZSBkaXN0aW5jdA0KbWV0aG9kcywgYnV0IHRyYW5zcGFyZW5jeSBpcyBvbmx5IGFmZm9yZGVk IGlmIHRoZSBtZXRob2RzIGFyZQ0KaW50ZXJvcGVyYWJsZSBjbGVhcmx5IGRlZmluZWQgd2hlbiB0 aGUgZGVsZWdhdGlvbiBmb3IgY29udGVudA0KZGVsaXZlcnkgaXMgZXhlY3V0ZWQuICBDbGVhcmx5 LCB0aGUgY2hvaWNlIG9mIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBpcyBkZXRlcm1pbmVkIGJ5IHRo ZSByZXNwZWN0aXZlIENETidzLg0KDQpTY290dA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8 bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NkbmkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYub3JnPG1haWx0bzpDRE5pQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNETmkgbWFpbGluZyBs aXN0DQpDRE5pQGlldGYub3JnPG1haWx0bzpDRE5pQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFp bHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NkbmkNCg0K --Boundary_(ID_xpIuX+soGX65496WnIyqkQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAw IDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7 DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2 IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglsaW5lLWhlaWdodDoxNTAlOw0KCWxheW91 dC1ncmlkLW1vZGU6Y2hhcjsNCgl0ZXh0LWF1dG9zcGFjZTpub25lOw0KCWZvbnQtc2l6ZToxMC41 cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFuLmFwcGxl LXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFw cGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3Bh Y2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6OTgxMTE0NDk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0xNDcwMDk1NjY4IC0xNjk0OTc2ODA2IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtdGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs NA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC10 YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwxDQoJe21zby1saXN0LWlkOjM2MTI0ODk0NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MTU3NTgwOTY2IC0yNzQ5Mzk3OTIgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7 fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJ e21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZl bC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ e21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNO IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3Jk Oy13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTstd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHRoZXNlIGRheXMgSSBhbSBi dXN5IG1ha2luZyBhIHN1bW1hcnkgYW5hbHlzaXMgb24gdGhpcyB0b3BpYy4gQXMgUmljaGFyZOKA mXMgcmVxdWVzdCwgSSBsaWtlIHRvIHNob3cgbXkgaW5mb3JtYXRpb24gYWx0aG91Z2ggcGVyaGFw cyBub3QgY29tcGxldGUgcmlnaHQgbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4xKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2ZSBkb25lIHNvbWUgd29yayB0byBjb2xsZWN0IGRp ZmZlcmVudCBjb21wYW554oCZcyByZXF1aXJlbWVudHMgYW5kIG9waW5pb25zIG9uIHRoaXMgZnVu Y3Rpb25hbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxh bmc9IkVOLVVTIj5PbmUsIEkgZmVlbCBtb3N0IG9mIHVzIGhhdmUgYWxyZWFkeSBiZWVuIGF3YXJl IG9mIHRoZSBzZXJ2aWNlIG9mIGNvbnRlbnQgYWRhcHRhdGlvbiwgYW5kIEkgYWxzbyBzZW50IGFu IGVtYWlsIHllc3RlcmRheSB0aGF0IFZvZGFwaG9uZSBub3cgaXMgcmVxdWlyaW5nIHRoZSBzb2x1 dGlvbiB0bw0KIGVuaGFuY2UgdGhlIHBlcmZvcm1hbmNlIG9mIGl0cyBtb2JpbGUgdmlkZW8gc2Vy dmljZS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJF Ti1VUyI+U2Vjb25kLCBoZXJlIGlzIGFuIGFydGljbGUgYWJvdXQgQ0lTQ08gOiDigJxDaXNjbyB1 cmdlcyBtb2JpbGUgb3BlcmF0b3JzIHRvIGFkZCB2YWx1ZSB0byBDRE4gc2VydmljZXPigJ0gaHR0 cDovL3d3dy50b3RhbHRlbGUuY29tL3ZpZXcuYXNweD9JRD00Njg3MDU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4 LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXNpZGVzLCBJIGhhdmUg Y2hlY2tlZCBtYW55IENETiBjb21wYW554oCZcyB3ZWJzaXRlcy4gTWFueSBjbGFpbSB0byBzdXBw b3J0IHRyYW5zY29kaW5nIHdoaWxlIHNvbWUgbWF5IG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0 ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4 LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciB0aGUgd29yZGluZyDigJxjb250ZW50IGFkYXB0 YXRpb27igJ0sIGl0IHNob3VsZCBiZSBjbGFyaWZpZWQgaGVyZSB0aGF0IGl0IG1heSBiZSB0d28g a2luZHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9 IkVOLVVTIj5PbmUgaXMgb25seSB0aGUgdHJhbnNmb3JtYXRpb24gb2YgZW5jYXBzdWxhdGlvbiBm b3JtYXQuIEZvciBleGFtcGxlIHRoZSBILjI2NCBzdHJlYW0gaXMgZW5jYXBzdWxhdGVkIGluIEFQ UExFIGFuZCBBZG9iZSBmb3JtYXQgcmVzcGVjdGl2ZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3Rl eHQtaW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPkkga25vdyB0aGF0IENvbWNhc3QgaGFz IGEgcHJvamVjdCB0aGF0IG5lZWRzIHRvIHBpY2sgdGhlIEguMjY0IG1lZGlhIGZyb20gdGhlIFRT IHN0cmVhbSBhbmQgdGhlbiBlbmNhcHN1bGF0ZWQgdGhlbSBpbnRvIGRpZmZlcmVudCBmb3JtYXRz KEFQUExFLEFkb2Jl4oCmKSB0byBkaWZmZXJlbnQgZGV2aWNlcy4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu MHB0O3RleHQtaW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciB0aGlzIGtpbmQgb2Yg dHJhbnNmb3JtYXRpb24sIHRoZSBjb21wdXRpbmcgY29zdCBpcyB2ZXJ5IHZlcnkgbG93IGFuZCBt YXkgYmUgbmVhcmx5IG5lZ2xlY3RlZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50 OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBvdGhlciBpcyB0byB0cmFuc2NvZGluZy4mbmJz cDsgRm9yIGV4YW1wbGUgdG8gc3VwcG9ydCBkaWZmZXJlbnQgYml0cmF0ZXMuJm5ic3A7IFNpbmNl IGVuY29kZXIgaXMgYSBoaWdoIHZhbHVlIGZhY2lsaXR5LCB3ZSBzaG91bGQgY29tcGFyZSB0aGUg Y2FwaXRhbCBjb3N0IG9mIGVuY29kZXIgYW5kIHRyYW5zcG9ydA0KIGNvc3QuIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTguMHB0O3RleHQtaW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPkp1c3QgdGFrZSBh IHNpbXBsZSBtb2RlbDogY29udGVudCBpcyBkZWxpdmVyZWQgZnJvbSBOb2RlIEEgdG8gTm9kZSBC LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMi PjwhLS1baWYgZ3RlIHZtbCAxXT48djpzaGFwZXR5cGUgaWQ9Il94MDAwMF90NzUiIGNvb3Jkc2l6 ZT0iMjE2MDAsMjE2MDAiIG86c3B0PSI3NSIgbzpwcmVmZXJyZWxhdGl2ZT0idCIgcGF0aD0ibUA0 QDVsQDRAMTFAOUAxMUA5QDV4ZSIgZmlsbGVkPSJmIiBzdHJva2VkPSJmIj4NCjx2OnN0cm9rZSBq b2luc3R5bGU9Im1pdGVyIiAvPg0KPHY6Zm9ybXVsYXM+DQo8djpmIGVxbj0iaWYgbGluZURyYXdu IHBpeGVsTGluZVdpZHRoIDAiIC8+DQo8djpmIGVxbj0ic3VtIEAwIDEgMCIgLz4NCjx2OmYgZXFu PSJzdW0gMCAwIEAxIiAvPg0KPHY6ZiBlcW49InByb2QgQDIgMSAyIiAvPg0KPHY6ZiBlcW49InBy b2QgQDMgMjE2MDAgcGl4ZWxXaWR0aCIgLz4NCjx2OmYgZXFuPSJwcm9kIEAzIDIxNjAwIHBpeGVs SGVpZ2h0IiAvPg0KPHY6ZiBlcW49InN1bSBAMCAwIDEiIC8+DQo8djpmIGVxbj0icHJvZCBANiAx IDIiIC8+DQo8djpmIGVxbj0icHJvZCBANyAyMTYwMCBwaXhlbFdpZHRoIiAvPg0KPHY6ZiBlcW49 InN1bSBAOCAyMTYwMCAwIiAvPg0KPHY6ZiBlcW49InByb2QgQDcgMjE2MDAgcGl4ZWxIZWlnaHQi IC8+DQo8djpmIGVxbj0ic3VtIEAxMCAyMTYwMCAwIiAvPg0KPC92OmZvcm11bGFzPg0KPHY6cGF0 aCBvOmV4dHJ1c2lvbm9rPSJmIiBncmFkaWVudHNoYXBlb2s9InQiIG86Y29ubmVjdHR5cGU9InJl Y3QiIC8+DQo8bzpsb2NrIHY6ZXh0PSJlZGl0IiBhc3BlY3RyYXRpbz0idCIgLz4NCjwvdjpzaGFw ZXR5cGU+PHY6c2hhcGUgaWQ9Il94MDAwMF9pMTAyNSIgdHlwZT0iI194MDAwMF90NzUiIHN0eWxl PSd3aWR0aDoxODcuMnB0O2hlaWdodDoyOS40cHQnIG86b2xlPSIiPg0KPHY6aW1hZ2VkYXRhIHNy Yz0iY2lkOmltYWdlMDAxLmVtekAwMUNDOTU5Ni44QUM3OTM3MCIgbzp0aXRsZT0iIiAvPg0KPC92 OnNoYXBlPjwhW2VuZGlmXS0tPjwhW2lmICF2bWxdPjxpbWcgd2lkdGg9IjI1MCIgaGVpZ2h0PSIz OSIgc3JjPSJjaWQ6aW1hZ2UwMDIucG5nQDAxQ0M5NTk2LjhBQzc5MzcwIiB2OnNoYXBlcz0iX3gw MDAwX2kxMDI1Ij48IVtlbmRpZl0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpPTEVPYmpl Y3QgVHlwZT0iRW1iZWQiIFByb2dJRD0iVmlzaW8uRHJhd2luZy4xMSIgU2hhcGVJRD0iX3gwMDAw X2kxMDI1IiBEcmF3QXNwZWN0PSJDb250ZW50IiBPYmplY3RJRD0iXzEzODEzMjc4NjciPg0KPC9v Ok9MRU9iamVjdD4NCjwveG1sPjwhW2VuZGlmXS0tPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQt aW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGFyZSB0d28gc29sdXRpb25zOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEpPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+QSBoYXZlIHRoZSB0cmFuc2Nv ZGVyIGFuZCBkZWxpdmVyIG11bHRpLWZvcm1hdCBjb250ZW50IHRvIEI8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lm ICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4yKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkIgaGF2ZSB0aGUgdHJhbnNjb2RlcjsgQSBvbmx5IGRl bGl2ZXJzIG9uZSBmb3JtYXQgY29udGVudCB0byBCIGFuZCBCIHdvdWxkIHRyYW5zY29kZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9t IHdob2xlIHN5c3RlbSBwb2ludCBvZiB2aWV3LCBlaXRoZXIgQSBvciBCIHdvdWxkIHRyYW5zY29k ZSB3aGlsZSB0aGUgYmFuZHdpZHRoIHdvdWxkIGJlIHNhdmVkIGluIHNvbHV0aW9uIEIuIEhlbmNl IHNvbHV0aW9uIEIgaXMgYmV0dGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50OjBj bSI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vdyBwcm92aWRlZCB0aGUgYmFuZHdpZHRoIGlzIHBhaWQg YnkgQiBhbmQgQiBzaG91bGQgZGVjaWRlIHdoZXRoZXIgdG8gaW5zdGFsbCB0cmFuc2NvZGVyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPihS aWNoYXJkIGhhcyBzYWlkIHRvIHNldCB0cmFuc2NvZGVyIGluIGVhY2ggZWRnZSBzZXJ2ZXIpPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYg dGhlIGNvc3Qgb2YgcmVudGluZyBiYW5kd2lkdGggKGZvciBhIGZldyBtb250aHMpIGlzIG1vcmUg ZXhwZW5zaXZlIHRoYW4gdGhlIHByaWNlIG9mIHRyYW5zY29kZXIgc3VwcG9ydGluZyB0aGUgc2Ft ZSBiYW5kd2lkdGgsIGl0IHdvdWxkIGJlIGJldHRlciB0byBwdXQgdGhlIHRyYW5zY29kZXINCiBh dCB0aGUgcmVjZWl2ZXIgTm9kZSBCLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50OjBj bSI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGZhY3QgSSBoYXZlIGludmVzdGlnYXRlZCB0aGlzIGlz c3VlIGZvciBtdWNoIHRpbWUuIFdoaWxlIGluIGRpZmZlcmVudCBhcmVhIHRoZSBwcmljZSBvZiBi YW5kd2lkdGggbWF5IGJlIGRpZmZlcmVudC4mbmJzcDsgQW5kIHRoZSB0cmFuc3BvcnQgYnVyZGVu IGJldHdlZW4gdHdvIGRpc3RhbnQgcGxhY2VzDQogb3Igb3ZlciBhIGJhZCBuYXR1cmUgZW52aXJv bm1lbnQgd291bGQgYmUgbXVjaCBoaWdoZXIuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5k ZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPkhlcmUgdGhlIHByaWNlIGluIFVTQSBtYXkgYmUg cmVmZXJyZWQgYXM6DQo8YSBocmVmPSJodHRwOi8vc21hbGxidXNpbmVzcy52ZXJpem9uLmNvbS9w cm9kdWN0cy9pbnRlcm5ldC9oc2kvb3ZlcnZpZXcuYXNweCNwbGFucyI+DQpodHRwOi8vc21hbGxi dXNpbmVzcy52ZXJpem9uLmNvbS9wcm9kdWN0cy9pbnRlcm5ldC9oc2kvb3ZlcnZpZXcuYXNweCNw bGFuczwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5n PSJFTi1VUyI+SW4gVmVyaXpvbiwgdGhlIHBhY2thZ2UgZm9yIDEwLTE1bWJwcyBpcyAkOTAgcGVy IG1vbnRoIChJIGZlZWwgdGhlIGJhbmR3aWR0aCBxdWFsaXR5IGZvciBidXNpbmVzcyB3b3VsZCBi ZSBndWFyYW50ZWVkKS4gSSBxdWVyeSB0aGF0IHRoZSBiYW5kd2lkdGggcHJpY2UgaW4gQ2hpbmEg bWF5IGJlDQogNTAlIGhpZ2hlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20i PjxzcGFuIGxhbmc9IkVOLVVTIj5JIGRvIG5vdCBrbm93IGhvdyBtdWNoIHRoZSBwcmljZSB3aWxs IGJlIGZvciB0aGUgYmFuZHdpZHRoIGZyb20gQW1zdGVyZGFtIHRvIFBhcmlzIChjcm9zcyBjb3Vu dHJ5IGluIHRoZSBzYW1lIGNvbnRpbmVudCkuJm5ic3A7IEJ1dCBJIGZlZWwgdGhlIHByaWNlIGZy b20gTmV3WW9yayB0byBQYXJpcyB3b3VsZA0KIGFic29sdXRlbHkgYmUgdmVyeSBoaWdoLiZuYnNw OyBBcyBmb3IgdGhlIEVuY29kZXIsIGl0IGFsc28gdmFyaWVzLiBQZXJoYXBzIHRoZSBwcmljZSBp biBDaGluYSB3aWxsIGJlIGhpZ2hlciB0aGFuIGluIFVTQS4gQW5kIGluIGZhY3QgdGhlIHByaWNl IG9mIGJhbmR3aWR0aCBhbmQgZW5jb2RlciBkZXBlbmRzIG1vc3RseSBvbiB0aGUgY29uY3JldGUg YnVzaW5lc3MgaXRlbXMuIEZvciBleGFtcGxlIHRoZSBwcmljZSB0byBIdWF3ZWkgbWF5IGJlIGxv d2VyDQogdGhhbiB0aGUgcHVibGljIHByaWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5k ZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ5IG15IGN1cnJlbnQgZXZhbHVhdGlvbiBpbiBD aGluYSBpdCBpcyBiZXR0ZXIgdXNpbmcgdGhlIHRyYW5zY29kZXIgdGhhbiByZW50aW5nIG11bHRp cGxlIHRpbWVzIGJyb2FkYmFuZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20i PjxzcGFuIGxhbmc9IkVOLVVTIj5Tb21lIHBlb3BsZSBoYXZlIHRvbGQgbWUgdGhhdCBmb3IgdGhl IG9wZXJhdG9yIGhpbXNlbGYgcHJvYmFibHkgdGhlIGJhbmR3aWR0aCBjb3N0IHdvdWxkIGJlIHZl cnkgbG93IGluIHRoZSBpbnRlcm5hbCBjYXBpdGFsIGNvdW50aW5nLiBCdXQgZm9yIHRoZSBpbmRl cGVuZGVudCBDRE4sIGl0DQogbWF5IGFub3RoZXIgdGhpbmcuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7 dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1VUyI+U28sIG15IHN1Z2dlc3Rpb24gaXMg dG8gbGV0IGRpZmZlcmVudCB3YXlzIGNvLWV4aXN0LiBJIGhhdmUgYW5ub3VuY2VkIHRoYXQgdG8g bGV0IHR3byBzaWRlcyBuZWdvdGlhdGUgd2hldGhlciB0byBhc3NpZ24gZENETiBmb3IgdGhlIGNv bnRlbnQgYWRhcHRhdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50OjBjbSI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50 OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGZhY3QsIGZyb20gQ1AgdG8gQ0ROLCZuYnNwOyB0 aGVyZSBhcmUgdGhlIHJlYWwgYnVzaW5lc3NlcyB0aGF0IGVpdGhlciBsZXQgQ1AgdG8gcHJvdmlk ZSBtdWx0aS1mb3JtYXQgY29udGVudCBvciBsZXQgdGhlIENETiB0byByZWNlaXZlIG9uZSBmb3Jt YXQgYW5kIGNvbXBsZXRlIHRoZSB0cmFuc2Zvcm1hdGlvbiwNCiBkZXBlbmRpbmcgb24gdGhlIGNv bmNyZXRlIGJ1c2luZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50OjBjbSI+PHNw YW4gbGFuZz0iRU4tVVMiPkJ5IHRoZSBzYW1lIGxvZ2ljLCBmb3JtIHVDRE4gdG8gZENETiwgaXQg bWF5IGJlIGVpdGhlciB0aGUgdUNETiB0byBwcm92aWRlIG11bHRpLWZvcm1hdCBjb250ZW50IG9y IHRoZSBkQ0ROIHRvIHJlY2VpdmUgb25lIGZvcm1hdCBjb250ZW50IGFuZCB0aGVuIGNvbXBsZXRl IHRoZSB0cmFuc2Zvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20i PjxzcGFuIGxhbmc9IkVOLVVTIj5DdXJyZW50bHkgdGhlcmUgaXMgbm90IHRoZSByZWFsIENETi1D RE4gY29ubmVjdGlvbiwgaGVuY2Ugd2UgYXJlIGJhc2luZyBvdXIga25vd2xlZGdlIG9uIHRoZSBy ZWxhdGVkIHNvbHV0aW9uIHRvIG1ha2Ugb3VyIHNvbHV0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8xIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4zKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIGZvciB0aGUgcHJvY2VkdXJlIG9mIGNvbnRl bnQgYWRhcHRhdGlvbiwgSSBqdXN0IGRyYWZ0IGEgZGlhZ3JhbSBhcyBiZWxvdzo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIj48IS0tW2lmIGd0 ZSB2bWwgMV0+PHY6c2hhcGUgaWQ9Il94MDAwMF9pMTAyNiIgdHlwZT0iI194MDAwMF90NzUiIHN0 eWxlPSd3aWR0aDo0MDYuOHB0O2hlaWdodDozOTcuOHB0JyBvOm9sZT0iIj4NCjx2OmltYWdlZGF0 YSBzcmM9ImNpZDppbWFnZTAwMy5lbXpAMDFDQzk1OTYuOEFDNzkzNzAiIG86dGl0bGU9IiIgLz4N CjwvdjpzaGFwZT48IVtlbmRpZl0tLT48IVtpZiAhdm1sXT48aW1nIGJvcmRlcj0iMCIgd2lkdGg9 IjU0MiIgaGVpZ2h0PSI1MzAiIHNyYz0iY2lkOmltYWdlMDA0LnBuZ0AwMUNDOTU5Ni44QUM3OTM3 MCIgdjpzaGFwZXM9Il94MDAwMF9pMTAyNiI+PCFbZW5kaWZdPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86T0xFT2JqZWN0IFR5cGU9IkVtYmVkIiBQcm9nSUQ9IlZpc2lvLkRyYXdpbmcuMTEi IFNoYXBlSUQ9Il94MDAwMF9pMTAyNiIgRHJhd0FzcGVjdD0iQ29udGVudCIgT2JqZWN0SUQ9Il8x MzgxMzI3ODY4Ij4NCjwvbzpPTEVPYmplY3Q+DQo8L3htbD48IVtlbmRpZl0tLT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3Ug bWF5IHNlZSB0aGUgc29sdXRpb24gaXMgcmF0aGVyIGNsZWFyIGFuZCB0aGUgbWV0YWRhdGEgbmVl ZGVkIHdvdWxkIGJlIGNsZWFyIGFsc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6 MGNtIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1p bmRlbnQ6MGNtIj48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0 ZXh0LWluZGVudDowY20iPjxzcGFuIGxhbmc9IkVOLVVTIj5CeSBteSBhbmFseXNpcyBhYm92ZSwg SSBraW5kbHkgaW52aXRlIHlvdXIgaWRlYXMgd2hldGhlciBpdCBtYXkgYmUgYW4gYXBwbGljYWJs ZSBhbmQgc2ltcGxlIHBhcnQgaW4gdGhlIENETkkgaXRlbSwgcHJvdmlkZWQgdGhhdCB0aGUgc29s dXRpb24gaXMgb3BlbiB0byB0aGUgdHlwZXMgb2YgY29udGVudA0KIGFkYXB0YXRpb24gYW5kIG1h eSBiZSBvcHRpb25hbGx5IGltcGxlbWVudGVkIGluIHRoZSByZWFsIHNvbHV0aW9ucy9idXNpbmVz cy4gSSBmZWVsIGZvciB0aG9zZSBvcGVyYXRvcnMgdGhhdCBuZWVkIHN1Y2ggZnVuY3Rpb25hbGl0 eSBpdCB3b3VsZCBiZSB2ZXJ5IGdvb2Qgd2hpbGUgaXQgZG9lcyBub3QgaW1wYWN0IG90aGVycyB0 aGF0IGRvIG5vdCBpbXBsZW1lbnQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6 MGNtIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQt aW5kZW50OjBjbSI+PHNwYW4gbGFuZz0iRU4tVVMiPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFdvdW5keSwgUmljaGFyZCBbbWFpbHRv OlJpY2hhcmRfV291bmR5QGNhYmxlLmNvbWNhc3QuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBPY3RvYmVyIDI3LCAyMDExIDc6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IFpob3VaaGlw ZW5nOyAnbWFya0BqZXQtc3RyZWFtLm5sJzsgJ2FsYW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29tJzxi cj4NCjxiPkNjOjwvYj4gJ2NkbmlAaWV0Zi5vcmcnOyBXb3VuZHksIFJpY2hhcmQ8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNh c2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7SW4geW91ciBjb21wYW554oCZcyB3ZWJzaXRl LCBJIGp1c3QgZmluZCBzb21lIGluZm9ybWF0aW9uPGJyPg0KPGJyPg0KSSBoYXZlIHRvIHN0ZXAg aW4gYXMgY28tY2hhaXIgaGVyZS48YnI+DQo8YnI+DQpUaGUgZ29hbCBvZiB0aGlzIFdHIGlzIG5v dCB0byBhbGlnbiB2ZW5kb3IgcHJvZHVjdCByb2FkbWFwcywgb3IgdG8gZXF1YWxpemUgYWxsIHZl bmRvciBvZmZlcmluZ3MsIG9yIHRvIHNwZWNpZnkgdGhlIGVudGlyZSBDRE5JIGVjb3N5c3RlbS4g VGhlIGdvYWwgb2YgdGhpcyBXRyBpcyB0byBlbmFibGUgdGhlIGludGVyY29ubmVjdGlvbiBhbmQg aW50ZXJvcGVyYXRpb24gb2YgdHdvIG9yIG1vcmUgQ0ROcywgd2l0aGluIHRoZSBib3VuZHMgb2Yg dGhlDQogQ0ROSSB3ZyBjaGFydGVyLjxicj4NCjxicj4NCkl0IGlzIE9LIHRvIGhhdmUgYSBkaXNj dXNzaW9uIGFib3V0IHdoZXRoZXIgY29udGVudCBhZGFwdGF0aW9uIG5lZWRzIHRvIGJlIHBlcmZv cm1lZCBieSB0aGUgZENETiwgc2luY2UgdGhhdCBkZWNpc2lvbiBpbXBhY3RzIHRoZSB1Q0ROLWRD RE4gaW50ZXJmYWNlLiBTbyBsZXQncyBmaW5kIGEgcHJvZHVjdGl2ZSB3YXkgdG8gZGlzY3VzcyB0 aGlzIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCB0byBjbG9zZSB0aGUgZGlzY3Vzc2lvbiBieSBJ RVRGIDgyDQogKGlmIG5vdCBzb29uZXIpLjxicj4NCjxicj4NCkNhbiBzb21lb25lIGRlc2NyaWJl IHJlYWwtbGlmZSBleGFtcGxlcyB3aGVyZSBkb3duc3RyZWFtIENETiAob3IgZWRnZSBjYWNoZS1i YXNlZCkgY29udGVudCBhZGFwdGF0aW9uIGlzIG5lZWRlZCB0b2RheSBpbiBhIHByb2R1Y3Rpb24g ZW52aXJvbm1lbnQsIG9yIHNob3J0bHk/IE5vdCBtZXJlbHkgYSBmZWF0dXJlIGluIGEgdmVuZG9y J3MgcHJvZHVjdCBtYXRlcmlhbHM/PGJyPg0KPGJyPg0KU3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVh bCwgSSBjYW4gZmluZCBhIGxvdCBvZiBleGFtcGxlcyB3aGVyZSBkb3duc3RyZWFtIGNvbnRlbnQg YWRhcHRhdGlvbiBpcyBub3QgbmVlZGVkLCBhbmQgYW55IGFkYXB0YXRpb24gaXMgcmVhbGx5IHBh cnQgb2YgdGhlIENQIC0gdUNETiBpbnRlcmZhY2UgKHdoaWNoIGlzIG91dCBvZiB0aGUgc2NvcGUg b2Ygb3VyIGNoYXJ0ZXIpLjxicj4NCjxicj4NCi0tIFJpY2g8YnI+DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTrlrovkvZMiPjxicj4NCiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij46IFpob3Va aGlwZW5nIFttYWlsdG86emhvdXpoaXBlbmdAaHVhd2VpLmNvbV0NCjxicj4NCjxiPlNlbnQ8L2I+ OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSAwMzo0NSBBTTxicj4NCjxiPlRvPC9iPjogTWFy ayBkZSBKb25nICZsdDttYXJrQGpldC1zdHJlYW0ubmwmZ3Q7OyBBbGFuIEthdmFuYWdoICZsdDth bGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbSZndDsNCjxicj4NCjxiPkNjPC9iPjogY2RuaUBpZXRm Lm9yZyAmbHQ7Y2RuaUBpZXRmLm9yZyZndDsgPGJyPg0KPGI+U3ViamVjdDwvYj46IFJlOiBbQ0RO aV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQgPGJyPg0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk65a6L5L2TIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGVsbG8g TWFyayw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5pY2UgdG8g bWVldCB5b3Ugb24gbGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkluIHlvdXIgY29tcGFueeKAmXMgd2Vic2l0ZSwgSSBqdXN0IGZpbmQgc29tZSBpbmZvcm1h dGlvbiB0aGF0IGFkZHJlc3NlcyDigJwNCjwvc3Bhbj48c3BhbiBsYW5nPSJOTCIgc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiM0QzU2NUM7bGF5b3V0LWdyaWQtbW9kZTpsaW5lIj5Wb2RhZm9uZSBz dWJzY3JpYmVycyBjb21wbGFpbmVkIGFib3V0IHZpZGVvIHBlcmZvcm1hbmNlLuKAnTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQt c3RyZWFtLm5sL3NlYXJjaC8/c2VhcmNoPXRyYW5zY29kaW5nIj5odHRwOi8vd3d3LmpldC1zdHJl YW0ubmwvc2VhcmNoLz9zZWFyY2g9dHJhbnNjb2Rpbmc8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsIGluIHRoaXMgZ3JvdXAsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBsYXN0IGZldyBkYXlzLCBleGNlcHQgdGhlIHB1 YmxpYyBlbWFpbCBkaXNjdXNzaW9ucyBJIGhhdmUgY29udGFjdGVkIHdpdGggc29tZSBwZW9wbGUg YW5kIGRpc2N1c3NlZCB3aXRoIG15IG93biBjb2xsZWFndWVzIG9mIGFsbCBkZXRhaWxzIG9uDQog dGhpcyBpc3N1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZp cnN0LCBhbHRob3VnaCB0aGUgbWFya2V0IHJlcXVpcmVtZW50IGZvciBpdCBpcyB2ZXJ5IGltcG9y dGFudCwgSSBmZWVsIEnigJlkIGJldHRlciBzaG93IHVwIG1vcmUgaW5mb3JtYXRpb24gb24gdGhl IHByb2NlZHVyZSBpbnZvbHZlZC4gSSBoYXZlIGV4cGxhaW5lZA0KIG1hbnkgdGltZXMgdGhhdCB0 byBzdXBwb3J0IGNvbnRlbnQgYWRhcHRhdGlvbiBpcyByYXRoZXIgc2ltcGxlIHdoaWxlIHRoZSB3 b3JkaW5nIGlzIG5vdCBlbm91Z2guPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIGFtIGJ1c3kgbWFraW5nIHNvbWUgY29udHJpYnV0aW9ucyBvbiB0aGlzIGFuZCBw bGFuIHRvIHVwbG9hZCB0byBFVFNJIG1lZXRpbmcgYW5kIElFVEYgQ0ROSS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ5IHRoZXNlIHdvcmsmbmJzcDsgSSBmZWVs IHRoZSBwZW9wbGUgbWF5IGNhdGNoIGEgd2hvbGUgdmlldyBvbiB0aGlzIGlzc3VlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2Vjb25kLCBmb3IgdGhhdCBmdW5j dGlvbmFsaXR5LCBpbiBpbXBsZW1lbnRhdGlvbiwgaWYgc29tZSBlbnRpdHkgZG9lcyBub3QgY2hv b3NlIHRvIHN1cHBvcnQgaXQsIGl0IG1heSBiZSBvay4gU2luY2UgaXQgbWF5IGJlIG5lZ290aWF0 ZWQgYmV0d2Vlbg0KIHR3byBDRE5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SWYgZENETiBkb2VzIG5vdCBzdXBwb3J0IHRoYXQsIGl0IG1heSBiZSB0aGUgdUNE TiByZXNwb25zaWJsZSB0byBjb21wbGV0ZSB0aGUgdHJhbnNjb2RpbmcgYW5kIGRlbGl2ZXIgdGhl IGNvbnRlbnQgb2YgbXVsdGlwbGUgZm9ybWF0cyBhbmQgcmF0ZXMNCiB0byBkQ0ROLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcmQsIGFsdGhvdWdoIENETkkg aXMgYSBuZXcgYXJjaGl0ZWN0dXJlLCB3aGlsZSB0aGUgY29udGVudCBvcGVyYXRpbmcgaGFzIGJl ZW4gZXhpc3RlZCBmb3IgeWVhcnMuIEFzIEkga25vdyB0aGUgY29udGVudCBmcm9tIFVTQSB0byB0 aGUgZG93bnN0cmVhbQ0KIG9wZXJhdG9yIGlzIHRyYW5zZmVycmVkIG9uIG9uZSBjb3B5IGFuZCB0 aGUgZG93bnN0cmVhbSBvcGVyYXRvciB3aWxsIGhhbmRsZSB0aGUgdHJhbnNjb2RpbmcuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVyaGFwcywgdGhlIGNvbnRlbnQgYWRh cHRhdGlvbiBpcyBtb3JlIG9uIHRoZSBtb2JpbGUgb3BlcmF0aW5nLiBCdXQgSSBmZWVsIGN1cnJl bnRseSBtb3N0IG9wZXJhdG9yIHdpbGwgYmUgYSBhbGwgc2VydmljZSBvcGVyYXRvci4gQW5kIGZv ciB0aGUNCiBDRE4gcHJvdmlkZXJzLCBpdCBtYXkgYmUgYmV0dGVyIHRvIHN1cHBvcnQgYWxsIGtp bmRzIG9mIHNlcnZpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5CZXNpZGVzLCBJIGxpa2Ugc2F5IHRoYXQgdGhlIHRlY2hub2xvZ3kgb24gdGhpcyB0b3BpYyBo YXMgYmVlbiBmb3IgbWFueSB5ZWFycyBhbmQgaGFzIGJlZW4gcmF0aGVyIG1hdHVyZSwgZXZlbiBz b21lIGl0ZW1zIGluIGlldGYgc3VjaCBhcyByZmMzNTA3DQogaWNhcC4gU28gZnJvbSB0aGUgdGVj aG5pcXVlIHBvaW50IG9mIHZpZXcsIGl0IGlzIGEgbmF0dXJlIGFjdGlvbiB0byBiZSBpbnZvbHZl ZCBpbiBDRE4gaW50ZXJjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1hcmsg ZGUgSm9uZyBbbWFpbHRvOm1hcmtAamV0LXN0cmVhbS5ubF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSA0OjIxIEFNPGJyPg0KPGI+VG86PC9iPiBBbGFuIEth dmFuYWdoPGJyPg0KPGI+Q2M6PC9iPiBCZW4gTml2ZW4tSmVua2luczsgWmhvdVpoaXBlbmc7IGNk bmlAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkhpIEFsYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+QXMgQmVuIHN0YXRlZCB0aGUgb3ZlcmFsbCBkaXNjdXNzaW9uIHJpZ2h0IG5vdyBpcyBhYm91 dCBkZWxpdmVyeSwgbm90IG9uIGFkYXB0YXRpb24uIEl0IGlzIGhhcmQgZW5vdWdoIHRvIGdldCBj b25zZW5zdXMgb24gdGhlIGRlbGl2ZXJ5IGFzcGVjdCBhbHJlYWR5IG5vdCB0byBtZW50aW9uIHlv dXIgcmVxdWlyZW1lbnQgZnJvbSBjb250ZW50IGFkYXB0YXRpb24gYWRkZWQgdG8gdGhhdCwNCiBz byBJIGFncmVlIHdpdGggQmVuIHdlIHNob3VsZCBzdGljayB3aXRoIHRoZSBkZWxpdmVyeSBhc3Bl Y3QgZm9yIHRoZSBmaXJzdCBzcGVjcy4mbmJzcDtJIGNhbiBpbWFnaW5lIHRoaXMgY291bGQgYmUg YSBkaXNjdXNzaW9uIGxhdGVyIG9uIGJ1dCBwbGVhc2UgbGV0IHVzIGtlZXAgdGhlIHNjb3BlIG9m IHRoaXMgYmUgY2xlYW4gYW5kIHRyYW5zcGFyZW50LiBJdCBpcyBvZiBiZW5lZml0IG9mIGV2ZXJ5 b25lIHRvIGdldCB0aGUgZmlyc3Qgc3BlY3MgYXMgZmFzdA0KIGFzIHBvc3NpYmxlLiBUaGFua3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TWV0IHZyaWVuZGVsaWprZSBncm9ldCw8L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+S2luZCByZWdhcmRzLDwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+TWFyayBkZSBKb25n PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5JbnRlcm5hdGlvbmFs IEJ1c2luZXNzIERldmVsb3Blcjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUt c3BhbiI+SmV0LVN0cmVhbSBCVjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUt c3R5bGUtc3BhbiI+RS1tYWlsOiA8YSBocmVmPSJtYWlsdG86bWFya0BqZXQtc3RyZWFtLmNvbSI+ bWFya0BqZXQtc3RyZWFtLmNvbTwvYT48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPk9mZmljZTogJiM0MzszMSAoMCk1MCA1MjYxODIwPC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5Nb2JpbGU6ICYjNDM7MzEgKDApNiA4MTEwODI2Mzwv c3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+RmF4OiAmIzQzOzMxICgw KTUwIDUyNjQyMTQ8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1z cGFuIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPi0gRXZlbnQ6PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1lZXQN CiB1cyBhdCBTdHJlYW1pbmcgTWVkaWEgRXVyb3BlLCAxNy0xOCBPY3RvYmVyLCBMb25kb24sIFVL PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tIEV2 ZW50Ojwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwO01l ZXQNCiB1cyBhdCBPbmxpbmUgVmlkZW8gU3RyYXRlZ2llcywgMTkgT2N0b2JlciwgTG9uZG9uLCBV Szwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LSBF dmVudDo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDtN ZWV0DQogdXMgYXQgQ0ROIFdvcmxkIFN1bW1pdCwgMjUtMjggT2N0b2JlciwgTG9uZG9uLCBVSzwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LTwvc3Bhbj48 L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5ld3M6PC9zcGFuPjwvYj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7UHJlLXJlcXVlc3QNCiB5b3VyIFRlY2hub2xv Z3kgV2hpdGVwYXBlciBub3cgYW5kIGJlIHRoZSBmaXJzdCB0byBoYXZlIGl0LCBjaGVjayA8YSBo cmVmPSJodHRwOi8vd3d3LmpldC1zdHJlYW0uY29tIj4NCnd3dy5qZXQtc3RyZWFtLmNvbTwvYT48 L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LSZuYnNwOzxiPk5ld3M6 Jm5ic3A7PC9iPkNoZWNrJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbSI+ aHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbTwvYT4gdG8gZG93bmxvYWQgb3VyICdTaXggVHJlbmRz DQogaW4gQ0ROcycgYnJvY2h1cmU8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tPC9zcGFuPjwvc3Bhbj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+QmxvZzo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNz PSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2 LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cuamV0LXN0cmVhbS5jb20vYmxvZy8i Pnd3dy5qZXQtc3RyZWFtLmNvbS9ibG9nLzwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlZp ZGVvRXhjaGFuZ2U6PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUt c3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48YSBocmVmPSJodHRwOi8vd3d3LnZkby14Lm5ldCI+d3d3LnZkby14Lm5ldDwvYT48L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNz PSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPlN0cmVhbXppbGxhOjwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5zdHJlYW16aWxsYWNkbi5j b20iPnd3dy5zdHJlYW16aWxsYWNkbi5jb208L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz PSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2 LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPi08L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5D b3Jwb3JhdGU6PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9 Imh0dHA6Ly93d3cuamV0LXN0cmVhbS5jb20iPnd3dy5qZXQtc3RyZWFtLmNvbTwvYT48L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAyNiwgT2N0LDIwMTEsIGF0IDg6MzMgUE0s IEFsYW4gS2F2YW5hZ2ggd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ QmVuPGJyPg0KPGJyPg0KSW0gYXNzdW1pbmcgdGhlbiBiYXNlZCBvbiB5b3VyIGNvbW1lbnRzIGJl bG93IGFyZSB5b3Ugc3VnZ2VzdGluZyB3ZSBhcmUgZ29pbmcgdG8gaGF2ZSBhIG51bWJlciBvZiB2 ZXJzaW9ucyBvZiB0aGUgQ0ROLUkgTWV0YWRhdGE/PGJyPg0KPGJyPg0KSSBzeW1wYXRoaXNlIHdp dGggd2hhdCB5b3UgYXJlIHBvaW50aW5nIG91dCBiZWxvdyBhbmQgZG8gYWdyZWUgdGhhdCB0aGVy ZSBpcyBzb21lIHdvcmsgdG8gYmUgZG9uZSwgYnV0IEkgc3RpbGwgZmVlbCB0aGF0IGNvbnRlbnQg YWRhcHRhdGlvbiBpcyB0byBtZSBhIGZ1bmRhbWVudGFsIHJlcXVpcmVtZW50IHRvIHdoYXQgY29s bGVjdGl2ZWx5IHdlIHNob3VsZCBhZGRyZXNzIGluIHRoZSBDRE4tSSBXRy4gSSBkbyBhZ3JlZSB3 aXRoIHlvdSB0aGF0IGNvbnRlbnQNCiBhZGFwdGF0aW9uIGlzIGFuIG9wdGltaXphdGlvbiBiZXR3 ZWVuIENETidzIGJ1dCBpdCdzIGEgdmVyeSBpbXBvcnRhbnQgb25lIHRoYXQgSSBrbm93IE5ldHdv cmsgU2VydmljZSBQcm92aWRlcnMgcGFydGljdWxhcmx5IHJlcXVpcmUuPGJyPg0KPGJyPg0KQWxh bjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJl Zj0ibWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZyI+Y2RuaS1ib3VuY2VzQGlldGYub3JnPC9h PiBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbiBOaXZlbi1K ZW5raW5zPGJyPg0KU2VudDogT2N0b2Jlci0xMi0xMSAxOjEzIFBNPGJyPg0KVG86IFpob3VaaGlw ZW5nPGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3Jn PC9hPjxicj4NClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5p LXVzZS1jYXNlcy0wMC50eHQ8YnI+DQo8YnI+DQpaaGlwZW5nLDxicj4NCjxicj4NCk9uIDEyIE9j dCAyMDExLCBhdCAxMDoyMiwgWmhvdVpoaXBlbmcgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhl bGxvIEJlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGUgVUUgbWF5IHNlbGVjdCB0aGUgY29udGVudCBmb3JtYXQgb24g dGhlIENQIHdlYi4gQWZ0ZXIgdGhhdCB0aGUgdXNlciBvbmx5IGRlc2lyZXMgdG8gZ2V0IGhpcyBz ZWxlY3RlZCBjb250ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ1dCBob3cgdGhlIGNvbnRl bnQgaXMgdHJhbnNmZXJyZWQgdG8gdGhlIGNsaWVudCBpcyBub3Qgd29ycmllZCBieSB0aGUgdXNl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgQ1AgbWF5IGNyZWF0ZSBhIHNwZWNpYWwgZm9y bWF0IGFzIHJlcXVpcmVkIGJ5IHRoZSB1c2VyIGFuZCBhc2sgdGhlIENETiB0byBkZWxpdmVyIHRv IHVzZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hpbGUgQ1AgbWF5IGdpdmUgYSBIRCBmb3Jt YXQgY29udGVudCB0byB1Q0ROIGFuZCB0aGUgZENETiBtYXkgdGhlbiB0cmFuc2Zvcm0gdG8gdGhl IGZvcm1hdCBhcyB0aGUgdXNlciBzZWxlY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KTG90cyBvZiB0aGluZ3MgbWF5IGJlIHBvc3NpYmxl IHRvIGRvIGFuZCBDRE4gcHJvdmlkZXJzIG9mZmVyIG1hbnkgYWRkaXRpb25hbCBzZXJ2aWNlcyBv biB0b3Agb2YgdGhlICZxdW90O2NvcmUmcXVvdDsgc2VydmljZSBvZiBjb250ZW50IGRlbGl2ZXJ5 LiBIb3dldmVyLCBvdXIgb2JqZWN0aXZlIChiYXNlZCBvbiBteSBpbnRlcnByZXRhdGlvbiBvZiB0 aGUgQ0ROSSBjaGFydGVyKSBpcyB0byBmb2N1cyBvbiB3aGF0IGlzIG5lY2Vzc2FyeSB0byBpbnRl cmNvbm5lY3QNCiBDRE5zIHRvIGRlbGl2ZXIgY29udGVudCBmcm9tIGEgQ1NQIHRvIGFuIEVuZCBV c2VyIHRoYXQgaXMgdGFyZ2V0ZWQgYW5kIGRlcGxveWFibGUgd2l0aGluIGEgc2hvcnQgdGltZSBm cmFtZSAoMTgtMjQgbW9udGhzKS48YnI+DQo8YnI+DQpDb250ZW50IHRyYW5zZm9ybWF0aW9uL2Fk YXB0YXRpb24gaXMgbm90IGFuIGVzc2VudGlhbCByZXF1aXJlbWVudCBpbiBvcmRlciB0byBhY2hp ZXZlIHRoYXQgYWltICh3ZSBjYW4gZGVsaXZlciBjb250ZW50IGZyb20gQ1NQcyB0byBFbmQgVXNl cnMgdmlhIG11bHRpcGxlIENETnMgd2l0aG91dCBuZWVkaW5nIG9yIHJlcXVpcmluZyBhbnkgQ0RO IHN1cHBvcnRzIGNvbnRlbnQgYWRhcHRhdGlvbikuPGJyPg0KPGJyPg0KSW4gbXkgb3BpbmlvbiB3 ZSBoYXZlIGVub3VnaCB3b3JrIHRvIGRvIGFscmVhZHkgd2l0aG91dCB0cnlpbmcgdG8gZXhwYW5k IHRoZSBzY29wZSBvZiBvdXIgd29yayB0byBpbmNsdWRlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRz IHRoYXQgZG8gbm90IGhlbHAgdXMgYWRkcmVzcyBvdXIgY29yZSBvYmplY3RpdmVzIGFzIGxhaWQg b3V0IGluIHRoZSBDRE5JIGNoYXJ0ZXIuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHRoaXMgY2FzZSwg aXQgaXMgbm90aGluZyByZWxhdGVkIHRvIGhvdyB0aGUgdXNlciBzZWxlY3QgZm9ybWF0cyBvbiBD UCB3ZWJzaXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlNvLCBpdCBpcyB0aGUgQ1AgYW5kIHVzZXIgdG8gZGVjaWRlIHRo ZSBjb250ZW50IGZvcm1hdCBub3QgdGhlIENETih5b3VyIGFzc2VydCBpcyBub3QgY29ycmVjdCBh bmQgc2VlbXMgeW91IHRha2UgdGhhdCBhc3NlcnQgYXMgeW91ciBiYXNlIGZvciB0aGUgZGlzY3Vz c2lvbikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+QXMgZm9yICZxdW90O3RoZSBjb3JlIENETiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgQ0RO cyB0b2RheSZxdW90OywgSSBoYXZlIGV2ZXIgcmFpc2VkIGFuIGVtYWlsIGJlZm9yZSB0aGF0IHlv dXIgY29tcGFueSdzIHdlYnBhZ2UgaGFzIGNsYWltZWQgc3VwcG9ydGluZyBtZWRpYSB0cmFuc2Zv cm1hdGlvbiBhbmQgbXVsdGktc2NyZWVuIHNlcnZpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ UGVyaGFwcywgSSBsaWtlIGFza2luZyB5b3UgbGlzdCBzb21lIGZlYXR1cmVzIHRoYXQgeW91IGZl ZWwgYXJlIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdGllcyBieSBleGlzdGluZyBtYWluIHN0cmVhbSBD RE5zLiBUaHVzIHdlIG1heSBjb21wYXJlIGFuZCB0YWtlIGRlZXAgbG9vay48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpJIHRoaW5rIHRoZSBj b3JlIGZ1bmN0aW9uYWxpdHkgbWFwcyBwcmV0dHkgd2VsbCB0byB0aGUgQ0ROSSBpbnRlcmZhY2Vz LCBuYW1lbHk6IFJlcXVlc3QgUm91dGluZywgTWV0YWRhdGEgY29uZmlndXJhdGlvbiwgbG9nIHBy b2R1Y3Rpb24gYW5kIGNvbnRyb2wgcGx1cyBjb250ZW50IGFjcXVpc2l0aW9uIGFuZCBjb250ZW50 IGRlbGl2ZXJ5Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGd1ZXNzIG1hbnkgcGVvcGxlIGhhdmUgdGhl IGV4cGVyaWVuY2Uva25vd2xlZGdlIG9mIGNvbnRlbnQgcmVsYXRlZCBzZXJ2aWNlLiBUaGUgdXNl ciBhbmQgQ1Agb25seSBjYXJlIHdoZXRoZXIgdGhlIENETiBwcm92aWRlcnMgbWF5IHNhdGlzZnkg dGhlaXIgcmVxdWlyZW1lbnQgd2hpbGUgbm90IGNhcmUgdGhlIGludGVybmFsIHByb2Nlc3MuIEp1 c3QgYXMgR1NNL1BTVE4gaW50ZXJjb25uZWN0aW9uLA0KIHRoZSB1c2VyIG9ubHkgY2FyZSBzdWNj ZXNzZnVsIGludGVyY29ubmVjdGlvbiB3aGlsZSBub3QgY2FyZSBob3cgdGhlIHZvaWNlIGlzIHRy YW5zZm9ybWVkIGluIHByb2Nlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+QmVzaWRlcywgSSBsaWtlIHJhaXNlIGEgY2FzZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5H aXZlbiBjdXJyZW50bHkgQkJDIHJlY3J1aXRzIENETiBwcm92aWRlcnMgdGhhdCBtYXkgc3VwcG9y dCAxMCBtZWRpYSBmb3JtYXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uZSBjYW5kaWRhdGUg aXMgeW91ciBjb21wYW55LCBhbm90aGVyIGlzIENETi1YLiBUaGUgdXNlcnMgYXJlIGxvY2F0ZWQg aW4gRnJhbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvIGJvdGggeW91ciBjb21wYW55IGFu ZCBDRE4tWCBzaG91bGQgY29ubmVjdCBhIEZyYW5jZSBDRE4gcHJvdmlkZXIoQ0ROLVkpLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPklmIHlvdXIgY29tcGFueSdzIHNvbHV0aW9uIGlzIHRvIHNlbmQg MTAgc3RyZWFtcyBvZiBkaWZmZXJlbnQgZm9ybWF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+b2Yg b25lIGNvbnRlbnQgdG8gQ0ROLVk7IFdoaWxlIENETi1YJ3Mgc29sdXRpb24gaXMgdG8gc2VuZCAx IHN0cmVhbSB0byBDRE4tWSB3aGlsZSBDRE4tWSBtYXkgY29uZHVjdCBzb21lIGFkYXB0YXRpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q29tcGFyaW5nIHRoZXNlIHR3byBzb2x1dGlvbnMsIGZv ciB5b3VyIGNvbXBhbnkgYW5kIENETi1YLCBhYnNvbHV0ZWx5IHRoZSBjb3N0IG9mIENETi1YIGlz IG11Y2ggbG93ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIENETi1ZLCBpbiBzb2x1dGlv bi0xLCBpdCBzaG91bGQgcmVjZWl2ZS9mb3J3YXJkIDEwIHN0cmVhbXMgOyB3aGlsZSBpbiBzb2x1 dGlvbi0yLCBpdCBzaG91bGQgb25seSByZWNlaXZlIDEgc3RyZWFtIGJ1dCBuZWVkIHRvIHRha2Ug dHJhbnNmb3JtYXRpb24gdG8gb3V0cHV0IDEwIHN0cmVhbXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hpY2ggc29sdXRpb24gaXMgbW9yZSBj b21wZXRpdGl2ZS4gaXQgaXMgU29sdXRpb24gMSwgcmlnaHQuIFJlbWVtYmVyIHRoZSBwcmljZSBm cm9tIEJCQyBpcyBzYW1lIHRvIGJvdGggeW91ciBjb21wYW55IGFuZCBDRE4tWCBvciBCQkMgd291 bGQgc2VsZWN0IG9uZSBDRE4gcHJvdmlkZXIgd2l0aCB0aGUgbG93ZXIgcHJpY2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+SWYgYSBDRE4gcHJvdmlkZXIgbWF5IG5vdCBnZXQgdGhlIGNvbnRyYWN0 IGZyb20gQ1AsIGhvdyBpdCBtYXkgc2F5IGl0IGlzIG5vdCBhIGNvcmUgZnVuY3Rpb25hbGl0eS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpX aGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyBhIHBvc3NpYmxlIG9wdGltaXphdGlvbiB0aGF0IGEg cGFydGljdWxhciBDRE4gbWF5IHdpc2ggdG8gaW1wbGVtZW50IG5vdCBhIGNvcmUgZnVuY3Rpb25h bGl0eSByZXF1aXJlZCB0byBlbmFibGUgY29udGVudCBkZWxpdmVyeSBiZXR3ZWVuIGludGVyY29u bmVjdGVkIENETnMuIEkgY2FuIHRoaW5rIG9mIG1hbnkgb3B0aW1pemF0aW9ucyB0aGF0IGEgQ0RO IGNvdWxkIGltcGxlbWVudCB0byBkaWZmZXJlbnRpYXRlDQogdGhlaXIgc2VydmljZSBidXQgdGhl IGludGVybmFsIHdvcmtpbmdzIG9mIGFuIGluZGl2aWR1YWwgQ0ROIGFyZSBvdXQgb2Ygc2NvcGUg b2Ygb3VyIGNoYXJ0ZXIuPGJyPg0KPGJyPg0KU28gdG8gcmVwZWF0IG15IHBvc2l0aW9uIGZvciBh IGZpbmFsIHRpbWU6IENvbnRlbnQgYWRhcHRhdGlvbiBpcyBub3QgYSBjb3JlIGZ1bmN0aW9uIHJl cXVpcmVkIHRvIGVuYWJsZSBjb250ZW50IGRlbGl2ZXJ5IGJldHdlZW4gaW50ZXJjb25uZWN0ZWQg Q0ROcyBhbmQgdGhlcmVmb3JlIGdpdmVuIHRoZSB3b3JrbG9hZCB3ZSBhbHJlYWR5IGhhdmUgdG8g c3BlY2lmeSBzb2x1dGlvbnMgdGhhdCBkbyBhZGRyZXNzIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdHkN CiByZXF1aXJlZCB0byBpbnRlcmNvbm5lY3QgQ0ROcyBJIGRvIG5vdCB0aGluayB3ZSBzaG91bGQg YmUgdHJ5aW5nIHRvIGFkZCBtb3JlIHdvcmsgaW50byB0aGF0IHdvcmtsb2FkIGFzIGl0IHdpbGwg b25seSBkaXN0cmFjdCB1cyBmcm9tIGFjaGlldmluZyBvdXIgZ29hbCBvZiBwcm9kdWNpbmcgZGVw bG95YWJsZSBzb2x1dGlvbnMgd2l0aGluIHRoZSB0aW1lZnJhbWUgd2UgYXJlIGJlaW5nIHRvbGQg Ynkgb3BlcmF0b3JzIHRoZXkgbmVlZHMgc29sdXRpb25zDQogd2l0aGluLjxicj4NCjxicj4NCkJl bjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5TbywgaWYgd2UgYWxsIHJlYWxpemUgdGhhdCBjdXJyZW50bHkg dGhlIG1lZGlhIHR5cGUgaXMgcmljaCwgdGhlIENETiBwcm92aWRlcnMgc2hvdWxkIHN1cnZpdmUg aW4gdGhlIGV4aXN0aW5nIGVjb3N5c3RlbSBhbmQgc3VwcG9ydCB0aGUgbWVkaWEgdHlwZXMgYXMg cmVxdWlyZWQgYnkgdGhlIG1hcmtldC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5CYWNrIHRvIHRoZSBjYXNlIG9mIEdTTS9HLjcxMSwgaXQganVzdCB3aGVuIGNvbmNlcm5p bmcgdGhlIGludGVyY29ubmVjdGlvbiwgdGhlIHRyYW5zZm9ybWF0aW9uIHNob3VsZCBhdCBvbmNl IGJlIHNvbHZlZC4gT3RoZXJ3aXNlIHRoZSBpbnRlcmNvbm5lY3Rpb24gbWF5IG5vdCBiZSBvcGVy YXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Cciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5aaGlwZW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Gcm9tOiBCZW4gTml2ZW4tSmVua2lucyBbbWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVr XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMiwgMjAx MSAxMjoxOSBBTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRvOiBaaG91WmhpcGVuZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkNjOiA8YSBocmVmPSJtYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29t Ij4NCnBoaWxpcC5lYXJkbGV5QGJ0LmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYu b3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlN1YmplY3Q6IFJl OiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5aaGlwZW5n LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9u IDExIE9jdCAyMDExLCBhdCAwNToxNiwgWmhvdVpoaXBlbmcgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZW4gYW5kIFBoaWxpcCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgbGlrZSB0byByZXNwb25k IHlvdXIgY29uY2VybiBpbiB0aGlzIG9uZSBlbWFpbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+QmVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBmZWVs IHdoYXQgd2UgYXJlIG5vdyBkaXNjdXNzaW5nIGlzIHdoYXQgaXMgdGhlICZxdW90O2NvcmUmcXVv dDsgZnVuY3Rpb24gb2YgQ0ROLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+QXMgeW91IHNheSwgQ0ROIGlzIHVzZWQgdG8gZGVsaXZlciBjb250ZW50LiBUaGF0IGlzIGFi c29sdXRlbHkgY29ycmVjdCB0aGF0IHRoZSBkZWxpdmVyeSBjYXBhYmlsaXR5IGlzIHRoZSBjb3Jl IHJlcXVpcmVtZW50IGZvciBDRE4gc3lzdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+V2hpbGUgQ0ROIGlzIHVzZWQgdG8gcHJvdmlkZSB0aGUgY29udGVudCBkZWxp dmVyeSBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hh dCBtZWFucyBzZXJ2aWNlLiBJdCBzaG91bGQgaW5jbHVkZSAmcXVvdDt0aW1lJnF1b3Q7ICZxdW90 O2xvY2F0aW9uJnF1b3Q7IGFuZCAmcXVvdDttZWRpYSB0eXBlJnF1b3Q7LCBldGMuIFRoZXNlIGZl YXR1cmVzIGFyZSBhbGwgdGhlIGNvcmUgZmVhdHVyZSBmb3IgYSBzZXJ2aWNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgd2Ugb25seSBjb25jZXJuICZxdW90O2Rl bGl2ZXJpbmcgb25lIGRhdGEgYmxvY2smcXVvdDssIEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUg aXNzdWVzIHN1Y2ggYXMgJnF1b3Q7bG9nZ2luZyZxdW90OyAmcXVvdDtnZW9ncmFwaGljIGNvbnN0 cmFpbnQmcXVvdDsgYXJlIHRoZSBjb3JlIG9mIENETi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Rm9yICZxdW90O3dpdGhvdXQgZXhwbGljaXQga25vd2xlZGdlIG9mIHdoYXQgdGhhdCBj b250ZW50IGFjdHVhbGx5IGlzICZxdW90OywgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSB3b3Jk aW5nIGlzIGFjY3VyYXRlIHNpbmNlIGdlbmVyYWxseSBhIENETiBtYXkgY2xhaW0gaXQgc3VwcG9y dCBkaWZmZXJlbnQgbWVkaWFzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+QnkgdGhpcyBvcHBvcnR1bml0eSwgSSBsaWtlIHRvIHNoYXJlIGEgdXNlIGNhc2U6IGEgY2Fs bCBmcm9tIGEgR1NNIHBob25lIHRvIGEgUFNUTiB0ZWxlcGhvbmUsIHRoZSB2b2ljZSBzdHJlYW0g c2hvdWxkIGJlIHRyYW5zZm9ybWVkIGZyb20gR1NNIHZvaWNlIHRvIEcuNzExLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIHRoZSB1c2VyLCBoZSBkb2VzIG5vdCBu ZWVkIHRvIGtub3cgd2hhdCB0eXBlIG9mIGRhdGEgaGFzIGJlZW4gdHJhbnNmZXJyZWQsIGJ1dCB0 aGUgb3BlcmF0b3IgaGFzIGRvbmUgc29tZSB3b3JrIHRvIGludGVyY29ubmVjdCB0d28gc3lzdGVt cywgcmlnaHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGxpa2Ug dG8ga25vdyB3aGV0aGVyIHlvdSBtYXkgYWNjZXB0IHRoYXQgbXkgdXNlIGNhc2UgaXMgc2ltaWxh ciB0byB0aGlzIGNhc2UgYWJvdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBkb24ndCB0aGluayB5b3VyIHVzZSBj YXNlIGlzIHNpbWlsYXIgdG8gdGhlIGFuYWxvZ3kgb2YgbW9iaWxlIG5ldHdvcmtzIGJlaW5nIGlu dGVyY29ubmVjdGVkIHRvIFBTVE4gbmV0d29ya3MuIEluIHRoZSBjYXNlIG9mIGNvbnRlbnQgZGVs aXZlcnkgdGhlIG5lZ290aWF0aW9uIGlzIGRvbmUgYmV0d2VlbiB0aGUgVXNlci9DbGllbnQgYW5k IHRoZSBDb250ZW50IFByb3ZpZGVyDQogYW5kIHRoZSBDRE4gaXMganVzdCB1c2VkIHRvIGV4ZWN1 dGUvcGVyZm9ybSB0aGUgZGVsaXZlcnkgdGhhdCBoYXMgYmVlbiBuZWdvdGlhdGVkLiBUaGUgQ0RO IGlzIG5vdCBpbnZvbHZlZCBpbiB0aGUgZGVjaXNpb24gbWFraW5nIG9mIHdoYXQgcmVwcmVzZW50 YXRpb25zIHRoZSBDb250ZW50IFByb3ZpZGVyIGRlY2lkZXMgdG8gb2ZmZXIgdG8gdGhlIFVzZXIv Q2xpZW50IG9yIGluIHdoYXQgcmVwcmVzZW50YXRpb25zIHRoZSBVc2VyL0NsaWVudCBkZWNpZGVz DQogdG8gcmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkFzIGZvciB5b3Ugc2FpZCBzZWxlY3RpbmcgbWVkaWEgYnkgdGhlICZxdW90 O3BvcnRhbCZxdW90OywgeW91IG1heSBzZWUgdGhlIHdheSAmcXVvdDsgdUNETiBkZWxpdmVycyBt dWx0aXBsZSBtZWRpYSBzdHJlYW1zIHRvIGRDRE4mcXVvdDsgaXMgbm90IGdvb2QgdGhhbiAmcXVv dDt1Q0ROIGRlbGl2ZXJzIG9uZSBtZWRpYSBzdHJlYW0gdG8gZENETiBhbmQgZENETiB0YWtlcyBz b21lIGFkYXB0YXRpb24gdG8gc3VwcG9ydCBtdWx0aXBsZQ0KIG1lZGlhIHR5cGVzJnF1b3Q7Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPk5vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0IGlzIGFuIG9wdGltaXNhdGlv biwgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBhY3R1YWxseSBkZWxpdmVyIHRoZSBj b250ZW50IChhbmQgcmVwb3J0LCBiaWxsLCBldGMuIGZvciB0aGF0IGRlbGl2ZXJ5KS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NeSBwb3NpdGlv biBpcyB0aGF0IHdlIHNob3VsZCBmb2N1cyBvbiBob3cgdG8gZW5hYmxlIHRoZSBpbnRlcmNvbm5l Y3Rpb24gb2YgdGhlIGNvcmUgQ0ROIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSBDRE5zIHRvZGF5 ICh3aGljaCBpcyBhbHNvIG15IGludGVycHJldGF0aW9uIG9mIHRoZSBzY29wZSBvZiB0aGUgQ0RO SSB3b3JraW5nIGdyb3VwIGFzIGV4cHJlc3NlZCBpbiBpdHMNCiBjaGFydGVyKSBiZWNhdXNlIGRv aW5nIHNvIGlzIGEgc2lnbmlmaWNhbnQgcGllY2Ugb2Ygd29yayBpbiBpdHNlbGYuIExldCdzIG5v dCBzdGFydCB0cnlpbmcgdG8gYWRkIGluIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBiZXlvbmQg d2hhdCB0aGUgbWFqb3JpdHkgb2YgQ0ROcyBzdXBwb3J0IHRvZGF5IGFzIHRoYXQgd2lsbCBqdXN0 IGRlbGF5IHVzIGdldHRpbmcgdXNhYmxlIHNwZWNpZmljYXRpb25zIGludG8gdGhlIG1hcmtldCBp biBhIHRpbWVseQ0KIGZhc2hpb24gSU1PLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QSBnb29kIHF1ZXN0aW9uIGlzICZxdW90O3NlY3VyaXR5 JnF1b3Q7IHNpbmNlIEkgaGF2ZSBkb25lIHNpeCB5ZWFycyBvbiB0aGUgRFJNPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hbmQgbGlrZSB0byBwcm9tb3RlIHRoZSBEUk0g YWxsIGFyb3VuZCB0aGUgd29ybGQ6KSBJZiB0aGUgY29udGVudCBpcyBuZWVkZWQgdG8gYmUgcHJv dGVjdGVkLCBnZW5lcmFsbHkgeW91IG1heSBrbm93IGFsbCB0aGUgc3lzdGVtcyBzaG91bGQgYmUg Z3JhbnRlZCBieSB0aGUgY29udGVudCBvd25lci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkhlcmUgSSBhbHNvIGxpa2UgdG8gY2xhcmlmeSB0aGF0IG5vdCBvbmx5IHRo ZSBtZWRpYSBpdHNlbGYgYnV0IHRoZSBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHNlcnZpY2UgaXRz ZWxmIChzdWNoIGFzIHRoZSBnZW9ncmFwaGljIGNvbnN0cmFpbnQpIHNob3VsZCBiZSBwcm90ZWN0 ZWQgYWxzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvLCB0cnVz dCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgbWVkaWEuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlBoaWxpcCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo YW5rIHlvdSB0aGF0IHlvdSBmZWVsIENvbnRlbnQgQWRhcHRpb24gaXMgYW4gaXNzdWUgZm9yICZx dW90O1JlcXVpcmVtZW50cyZxdW90OyBidXQgSSBkbyBub3Qga25vdyB3aHkgaXQgaXMgbm90IGZv ciBVc2UgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgbGlr ZSB0byBjbGFyaWZ5IHRvIFUgdGhhdCBpdCBpcyBpbXBvcnRhbnQgZm9yIHlvdSBvcGVyYXRvciBz aW5jZSBpdCBtYXkgc2F2ZSBpbnZlc3RtZW50IGlmIHRoZSBzeXN0ZW0gbWF5IHN1cHBvcnQgZGlm ZmVyZW50IHNlcnZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Rm9yIHVzIHZlbmRvciwgd2UgYXJlIGhhcHB5IG9wZXJhdG9yIG1heSBpbnN0YWxsIGEgc3lzdGVt IGZvciB0aGUgbW9iaWxlIHNlcnZpY2UgYW5kIGFub3RoZXIgc3lzdGVtIGZvciB0aGUgRkJCIHNl cnZpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CdXQgdGhlIHJl YWxpdHkgaXMgYWxsIG9wZXJhdG9ycyBhc2sgdXMgdG8gcHJvdmlkZSBhIHN5c3RlbSB0aGF0IG1h eSBzdXBwb3J0IGRpZmZlcmVudCBzZXJ2aWNlIHN5c3RlbXMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkZyYW5rbHksIEJlbiBhbmQgUGhpbGlwLCBJIHJlbWVtYmVyIEkgaGF2ZSBleHBs YWluZWQgc29tZXdoZXJlIHRoYXQgdG8gaW1wbGVtZW50IHRoaXMgaXMgcmF0aGVyIHNpbXBsZSAu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BdCBsZWFzdCB0aGUgVXNl IGNhc2UgYW5kIFJlcXVpcmVtZW50IGFyZSBpbmZvcm1hdGlvbmFsIHRvIGJlIHJlZmVycmVkIGlu IGZ1dHVyZSB3b3JrLiBTbyBJIGRvIHJlYWxseSBmZWVsIHlvdSBtYXkgYWNjZXB0IGl0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T2YgY291cnNlIEkgbGlrZSB0byBy ZXNwb25kIHlvdXIgbW9yZSBjb25jZXJuIGFuZCBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOiA8YSBocmVmPSJt YWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tIj4NCnBoaWxpcC5lYXJkbGV5QGJ0LmNvbTwvYT4g W21haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb21dPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5TZW50OiBNb25kYXksIE9jdG9iZXIgMTAsIDIwMTEgMTE6MjIgUE08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRvOiA8YSBocmVmPSJtYWlsdG86 YmVuQG5pdmVuLWplbmtpbnMuY28udWsiPg0KYmVuQG5pdmVuLWplbmtpbnMuY28udWs8L2E+OyBa aG91WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2M6IDxh IGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U3ViamVjdDogUkU6IFtDRE5pXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5CZW4sIFpoaXBlbmcsIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+SSB0aGluayB0aGF0IENvbnRlbnQgQWRhcHRhdGlvbiBpcyBtb3JlIGFuIGlzc3VlIGZvciB0 aGUgUmVxdWlyZW1lbnRzIGRvYyB0aGFuIGZvciB0aGUgVXNlIGNhc2VzIGRyYWZ0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUga2V5IHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ugd2Fu dCB0aGUgQ0ROSSBpbnRlcmZhY2VzIHRvIGJlIGFibGUgdG8gY29wZSB3aXRoIGEgc2NlbmFyaW8g d2hlcmUgKHNheSkgSEQvU0QgY29udmVyc2lvbiBpcyBkb25lIGluIHRoZSBkQ0ROICZhbXA7IHRv IHNpZ25hbCBhYm91dCB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5r IHRoYXQgY29waW5nIHdpdGggdGhpcyBzY2VuYXJpbyBpcyBhIHNlY29uZCBvcmRlciByZXF1aXJl bWVudCwgaWUgd2Ugc2hvdWxkIG5vdCB3b3JyeSBhYm91dCBpdCBpbiB0aGUgaW5pdGlhbCBzdGFu ZGFyZHMtdHJhY2sgd29yay4gSSBkb24ndCBrbm93LCBkaWQgd2UgZXZlciBkZWNpZGUgd2hldGhl ciB0aGUgVXNlIGNhc2VzIGRvYyBpcyByZXN0cmljdGVkIHRvICZxdW90O2luaXRpYWwmcXVvdDsN CiBzY2VuYXJpb3MsIG9yIHdoZXRoZXIgaXQncyBhbGwtZW5jb21wYXNzaW5nLCBpZSBjb3Zlcmlu ZyAmcXVvdDtmdXR1cmUmcXVvdDsgc2NlbmFyaW9zIGFzIHdlbGw/PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlNjb3R0LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+UmVhZGluZyBzb21lIG9mIHlvdXIgZXhhbXBsZXMsIHRoZXkgc2VlbSB0byBiZSB2YWxpZCBl dmVuIGlmIGNvbnRlbnQgYWRhcHRhdGlvbiAoSEQvU0QpIGlzIG91dCBvZiBzY29wZS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gYSBkQ0ROIG1pZ2h0IGZvciBzb21l IHJlYXNvbiBiZSB1bndpbGxpbmcgdG8gZGlzdHJpYnV0ZSBIRD88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0gYSBDU1AgbWlnaHQgd2FudCB0byBtYWtlIHN1cmUgdGhl IGRDRE4gY2FuIHVzZSBITFMgZW5jYXBzdWxhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkJ1dCB0aGVzZSBzb3J0cyBvZiBleGFtcGxlcyBzZWVtIHRvIGJlIHN0 YXRpYyBwb2xpY3kgdGhpbmdzICh0byBkbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+d2l0aCB0aGUgY2FwYWJpbGl0aWVzICZhbXA7IHByZWZlcmVuY2VzIG9mIHRoZSBD RE5zICZhbXA7IENTUCksIHJhdGhlciB0aGFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5tZXRhZGF0YSBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIHBpZWNlIG9m IGNvbnRlbnQuIEluIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ ZGlzY3Vzc2lvbiBzbyBmYXIsIEkgdGhpbmsgbmVnb3RpYXRpb24gYWJvdXQgc3RhdGljIHBvbGlj eSBzdHVmZiBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cmF0aGVy IG91dCBvZiBzY29wZSg/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucywgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24gaXMgd2hldGhlciB0cnVz dCBpcyB0cmFuc2l0aXZlLiBEb24ndCB0aGluayBpdCBuZWVkIGJlIC0ganVzdCBiZWNhdXNlIENT UCB0cnVzdHMgdUNETiwgYW5kIHVDRE4gdHJ1c3RzIGRDRE4gZG9lc24ndCBtZWFuIHRoYXQgdGhl IENTUCBhdXRvbWF0aWNhbGx5IHRydXN0cyB0aGUgZENETi4NCiBIb3dldmVyLCBpIHN1c3BlY3Qg dGhpcyBjYW4gZ2V0IGFyYml0cmFyaWx5IGNvbXBsZXggLSBzbyBvbmUgcG9zc2liaWxpdHkgaXMg dG8gc2F5IHRoYXQgd2Ugd2lsbCBvbmx5IGhhbmRsZSBjYXNlcyB3aGVyZSB0aGUgdHJ1c3QgaXMg dHJhbnNpdGl2ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCB3aXNoZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnBoaWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5QaGlsaXAgRWFyZGxleTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+UmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgU3RyYXRlZ3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhpcyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJl IHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRp dmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91J3JlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBub3RlIHRoYXQgZGlzY2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5n DQogb3IgdXNpbmcgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UndmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIGxldCBtZSBrbm93IGltbWVkaWF0ZWx5 IG9uIHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFuayB5b3UuIFdlIG1vbml0b3Igb3VyIGVt YWlsIHN5c3RlbSwgYW5kIG1heSByZWNvcmQgeW91ciBlbWFpbHMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ccml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2lzdGVyZWQgb2ZmaWNlOiA4 MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUogUmVnaXN0ZXJlZCBpbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RW5nbGFuZCBubzogMTgwMDAwMDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOiA8YSBocmVmPSJtYWlsdG86Y2RuaS1ib3VuY2Vz QGlldGYub3JnIj4NCmNkbmktYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzpjZG5pLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+T2YgQmVuIE5pdmVuLUplbmtpbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlNlbnQ6IDEwIE9jdG9iZXIgMjAxMSAxMjowNDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VG86IFpob3VaaGlwZW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5DYzogPGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNk bmlAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5T dWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMt MDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNvbGxlYWd1ZXMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPklNTyBTZWN0aW9uIDUuMS4zIHNob3VsZCBiZSByZW1vdmVk IGZyb20gdGhlIFVzZSBDYXNlcyBkcmFmdC4gQ29udGVudCBBZGFwdGF0aW9uIChpLmUuIHRha2lu ZyBpbiBhIGNvbnRlbnQgaXRlbSBpbiBvbmUgZm9ybWF0IGFuZCB0cmFuc2Zvcm1pbmcgaXQgdG8g YW5vdGhlciBmb3JtYXQgb3IgcmVwcmVzZW50YXRpb24pIGlzIG5vdCBhICZxdW90O2NvcmUmcXVv dDsgZnVuY3Rpb24gb2YgYSBDRE4NCiB3aGljaCB0eXBpY2FsbHkgZGVsaXZlcnMgdGhlIGNvbnRl bnQgdGhhdCBpcyByZXF1ZXN0ZWQgd2l0aG91dCBleHBsaWNpdCBrbm93bGVkZ2Ugb2Ygd2hhdCB0 aGF0IGNvbnRlbnQgYWN0dWFsbHkgaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxl dCdzIG5vdCBmb3JnZXQgdGhhdCBpbiBidWlsZGluZyBhbiBlbmQgdG8gZW5kIGNvbnRlbnQgc2Vy dmljZSB0aGUgQ0ROIGlzIG9ubHkgb25lIGNvbXBvbmVudCBhbmQgaXMgdGhlIGNvbXBvbmVudCB0 YXNrZWQgd2l0aCBleGVjdXRpbmcgdGhlIGRlbGl2ZXJ5IG9mIGEgc3BlY2lmaWMgcmVwcmVzZW50 YXRpb24gKHZlcnNpb24vY29weS9mb3JtYXQgZXRjLikgb2YgdGhlIHNlbGVjdGVkDQogY29udGVu dCBub3QgdGhlIGNvbXBvbmVudCB0YXNrZWQgd2l0aCBkZWNpZGluZyAob3IgYXBwbHlpbmcgcG9s aWN5KSBvbiB3aGljaCB2ZXJzaW9uL2NvcHkvcmVwcmVzZW50YXRpb24gb2YgY29udGVudCBzaG91 bGQgYmUgZGVsaXZlcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZGVjaXNp b24gYXMgdG8gd2hpY2ggdmVyc2lvbi9jb3B5L3JlcHJlc2VudGF0aW9uIHRvIG9mZmVyIGFuZCBh bGxvdyB0byBiZSBkZWxpdmVyZWQgdG8gYSBnaXZlbiBkZXZpY2UvdXNlciBpcyBpbXBsZW1lbnRl ZCBvdXRzaWRlIG9mIHRoZSBDRE4gKGUuZy4gYnkgdGhlICZxdW90O3BvcnRhbCZxdW90OyB3aGVy ZSB0aGUgdXNlciBmaXJzdCBtYWtlcyB0aGVpciBjb250ZW50IHNlbGVjdGlvbg0KIHByaW9yIHRv IHRoZSBDRE4gYmVjb21pbmcgaW52b2x2ZWQgaW4gdGhlIGRlbGl2ZXJ5IG9mIHRoZSBzZWxlY3Rl ZCBjb250ZW50KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDggT2N0IDIwMTEsIGF0IDA4OjIwLCBaaG91WmhpcGVuZyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gb2xsb3dpbmcgU2NvdHQncyBj b21tZW50cyBvbiBzZWN0aW9uIDUuMS4zLCBJIGZlZWwgU2NvdHQncyBkZXNjcmlwdGlvbiBvbiB0 aGUgdXNlIGNhc2Ugb2YgSEQgYW5kIFNEIGlzIG5vdCBleGFjdGx5IGNvcnJlY3QuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIG9uZSBt b3ZpZSBoYXMgdHdvIGZvcm1hdHMgb2YgSEQgYW5kIFNELCB0aGVuIHdlIGhhdmUgdHdvIGNvbnRl bnQgd2l0aCBkaWZmZXJlbnQgaWRlbnRpZmllci4gSW4gRFJNIHNjb3BlLCB0aGUgYmFzaWMgdW5p dCBpcyBhIGNvbnRlbnQgY29weS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhlcmUgdGhlIGZpcnN0IGJ1bGxldCAmcXVvdDth IHN1YnNldCBvZiBlbmNvZGluZ3MgZGVsaXZlcmFibGUgdG8gc3BlY2lmaWMgZGV2aWNlcywmcXVv dDsgaGFzIGxpc3RlZCB0aGUgY2FzZSBvZiBjb250ZW50IGFkYXB0YXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIGxhc3QgbW9u dGgsIEkgaGF2ZSBjb250YWN0ZWQgdGhlIEF1dGhvcnMgb2YgdGhpcyBkb2N1bWVudCBhbmQgdGFr ZW4gc29tZSBlbWFpbCBleGNoYW5nZXMgd2l0aCBHcmFudCBhbmQgUGhpbGlwIChCVCkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgaGF2 ZSBzaG93biBCVCB3aXRoIHNvbWUgaW5mb3JtYXRpb24gdGhhdCBJIGtub3cgaW4gdGhpcyBjYXNl IGFuZCBhcmVhIHRvIGV4cGxhaW4gdGhlIGNvbnRlbnQgZmxleGliaWxpdHkgaXMgY3VycmVudGx5 IGEgYmFzaWMgcmVxdWlyZW1lbnQgZm9yIENETiBzZXJ2aWNlIGFuZCByZWxhdGVkIG5lZ290aWF0 aW9uIGlzIG5lZWRlZCBpbiB0aGUgQ0ROIGludGVyY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWVhbndoaWxlLCBJIHNo b3VsZCBhbHNvIGludml0ZSB5b3UgaW4gdGhpcyBncm91cCByYWlzaW5nIHlvdXIgY29tbWVudHMg b3IgcXVlc3Rpb25zIG9uIHRoaXMgY2FzZSBzaW5jZSBJIGhvcGUgbXkgdXNlIGNhc2UgbWF5IGJl IGluY29ycG9yYXRlZCBpbiB0aGUgdXNlIGNhc2UgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB5b3UgaGF2ZSBh bnkgbW9yZSBxdWVzdGlvbiBvciBjb21tZW50cywgcGxzIHNoYXJlIGluIHRoaXMgdGhyZWFkLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTogU2NvdHQgV2Fpbm5lciBbbWFpbHRvOnN3 YWlubmVyQGNpc2NvLmNvbV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+U2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMTEgODowMiBB TTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5UbzogPGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlN1 YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0w MC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlNlY3Rpb24gMi4zIE5vbWFkaWMgVXNlcnM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBkZXNjcmlwdGlvbiBm YWxscyB1bmRlciB0aGUgY2F0ZWdvcnkgb2YgR2VvZ3JhcGhpYyBFeHRlbnNpb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+eWV0IHRoZSB0 aGlyZCBwYXJhZ3JhcGggc3RhdGVzIHRoZSBjYXNlIHdoZXJlIGEgZGlmZmVyZW50IGRldmljZSBp czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij51c2VkIGluIHRoZSBzYW1lIENETiBjb3ZlcmFnZSBhcmVhLiAmbmJzcDtUaGUgaW50ZW50IG9m IHRoaXMgdXNlIGNhc2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+bmVlZHMgdG8gYmUgY2xhcmlmaWVkLiAmbmJzcDtQZXJoYXBzIHRoZSB1 c2UgY2FzZSBpcyB0cnlpbmcgdG8gYWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50aGUgc2NlbmFyaW8gd2hlcmUgYSBOb21hZGlj IFVzZXItQSB3aXRoIGFuIGFncmVlbWVudCBhbGxvd2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hY2Nlc3MgdG8gY29udGVudCBmcm9t IENTUC1BIHZpYSB1Q0ROIG1vdmVzIHRvIGEgZENETiBpbiBhIGRpZmZlcmVudDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWdpb24uICZu YnNwO1RoZSBkQ0ROIGlzIGFsbG93ZWQgdG8gZGlzdHJpYnV0ZSB0aGUgY29udGVudCBvZiBDU1At QSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5Vc2VyLUE7IGhvd2V2ZXIsIG5vdCBvdGhlciB1c2VycyBpbiB0aGUgcmVnaW9uIG9mIHRo ZSBkQ0ROIGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5hbGxvd2VkIHRvIHJldHJpZXZlIHRoZSBjb250ZW50IHVubGVzcyB0aGV5IHRv byBoYXZlIHN1Y2ggYW4gYWdyZWVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VjdGlvbiA1LjEuMyBDb250ZW50IEVu Y29kaW5nIFJlc3RyaWN0aW9ucyBOZWVkIHRvIGNsYXJpZnkgaWYgd2UncmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGFsa2luZyBhYm91 dCB0aGUgcmVzdHJpY3Rpb25zIG9uIHRoZSBkZWxpdmVyeSBvZiBzcGVjaWZpYyBjb250ZW50PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPm9y IHRoZSByZXN0cmljdGlvbnMgb24gdGhlIGFiaWxpdHkgb2YgYSBDRE4gdG8gZGVsaXZlciBzcGVj aWZpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5jb250ZW50LiAmbmJzcDtJIGNlcnRhaW5seSB1bmRlcnN0YW5kIHRoZSBjYXNlIHdoZXJl IGEgQ1NQIHdpbGwgcmVzdHJpY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+dGhlIGRpc3RyaWJ1dGlvbiBvZiBjb250ZW50IHRvIGEgJnF1 b3Q7bWFuYWdlZCBwYXRoJnF1b3Q7IGlmIHN1Y2ggY29udGVudCBpczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IRCB3aGlsZSBhbGxvd2lu ZyB0aGUgY29udGVudCBkaXN0cmlidXRpb24gdmlhIGFuIHVuLW1hbmFnZWQgcGF0aCBpZjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5zdWNo IGNvbnRlbnQgaXMgU0QgKHNhbWUgY291bGQgYXBwbHkgdG8gZW5jcnlwdGlvbiBtZXRob2RzLCBk ZWxpdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5tZXRob2RzLCBldGMuKS4gJm5ic3A7T24gdGhlIGNvbnRyYXJ5LCB0aGUgZENETiBt YXkgaGF2ZSBpdHMgb3duPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPnJlc3RyaWN0aW9ucyBvZiBibG9ja2luZyB0aGUgZGlzdHJpYnV0aW9u IG9mIEhEIGNvbnRlbnQgd2hpbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+YWxsb3dpbmcgdGhlIGRpc3RyaWJ1dGlvbiBvZiBTRCBjb250 ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+byBmaXJzdCBidWxsZXQgbWFrZXMgc2Vuc2UgaWYgdGhlIGRDRE4gY2FuIHBl cmZvcm0gYSBzdWJzZXQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+ZW5jYXBzdWxhdGlvbnMgZm9yIGEgcmVmZXJlbmNlIHNldCBvZiBt ZWRpYSAoZS5nLiBITFMsIEhTUywgYnV0IG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EQVNIKSBvIHNlY29uZCBidWxsZXQgbWFrZXMg c2Vuc2Ugd2hlcmUgdGhlIGRDRE4gZG9lc24ndCB3YW50IHRvPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPm9mZmVyIGhpZ2ggYml0LXJhdGUg dmFyaWFudHMgb2YgdGhlIG1lZGlhIG8gdGhpcmQgYnVsbGV0IG1ha2Ugc2Vuc2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+aWYgdGhlIHBv bGljeSBhZGRyZXNzZXMgUW9FIGJ1dCBJIGRvbid0IHRoaW5rIHN1YnNjcmliZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cmlnaHRzL2F1 dGhvcml6YXRpb25zIGFwcGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VjdGlvbiAxMCBTZWN1cml0eSBDb25zaWRlcmF0 aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+QXNpZGUgZnJvbSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgV0lUSElO IHRoZSB1Q0ROIGFuZCBkQ0ROLCBJPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoaW5rIHdlIGNhbiBkZXNjcmliZSB0aGlzIGluIGZvdXIg Y29udGV4dHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5hLiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIENTUCBhbmQg dGhlIHVDRE4gKHRoZSBwcmluY2lwbGUgY29udHJhY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YXJyYW5nZW1lbnQgZm9yIGRpc3RyaWJ1 dGlvbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Yi4gVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB1Q0ROIGFuZCBkQ0ROICh0aGUg dHJhbnNpdGl2ZSB0cnVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5yZWxhdGlvbnNoaXAgdGhhdCBleHRlbmRzIHRoZSBjb250cmFjdCBk ZWZpbmVkIGluIChhKSBhYm92ZSkgYy4gVGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBVc2Vy IGFuZCBkQ0ROICh0aGUgcmVjb2duaXRpb24gb2YgcmlnaHQgdG88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ZG93bmxvYWQgcHJlZGljYXRl ZCBvbiAoYikgYWJvdmUpIGQuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VXNlciBhbmQg Q1NQICh0aGUgY29udHJhY3QgYXV0aG9yaXppbmcgdGhlIHVzZXIgYWNjZXNzIHRvIHRoZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5jb250 ZW50KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIHVzZXIgaXMgbm90IGludGVyZXN0ZWQgaW4gdGhlIGEtYiBub3IgdGhl IGItYyByZWxhdGlvbnNoaXAuIFRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj51c2VyIGlzIG9ubHkgaW50ZXJlc3RlZCBpbiB0aGUgdHJh bnNwYXJlbmN5IGFuZCBpbnRlcm9wZXJhYmlsaXR5IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSBzZWN1cml0eSByZWxhdGlvbnNo aXAgYmV0d2VlbiBkLWIgb3IgZC1jIHRvIHRoZSBwb2ludCB0aGF0IHRoZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5hdXRob3JpemF0aW9u IGdyYW50ZWQgaW4gZC1hIGlzIHZpYWJsZSB3aGVuIHRoZSBkZWxpdmVyeSBpczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5pbml0aWF0ZWQg dmlhIGVpdGhlciBkLWIgb3IgZC1jLiAmbmJzcDtBcyBhbiBleGFtcGxlLCB0aGUgdUNETiBtaWdo dCB1c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+VVJMIGFwcGVuZGVkIHRva2VucyBmb3IgYXV0aGVudGljYXRpb24gd2hpbGUgZENETiBt aWdodCB1c2UgVVJMPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPmFwcGVuZGVkIGhhc2hlcy4gJm5ic3A7VGhlIHVzZXIgZG9lc24ndCB3YW50 IHRvIGtub3cgYWJvdXQgdGhlIGRpc3RpbmN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPm1ldGhvZHMsIGJ1dCB0cmFuc3BhcmVuY3kgaXMg b25seSBhZmZvcmRlZCBpZiB0aGUgbWV0aG9kcyBhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+aW50ZXJvcGVyYWJsZSBjbGVhcmx5IGRl ZmluZWQgd2hlbiB0aGUgZGVsZWdhdGlvbiBmb3IgY29udGVudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5kZWxpdmVyeSBpcyBleGVjdXRl ZC4gJm5ic3A7Q2xlYXJseSwgdGhlIGNob2ljZSBvZiBhdXRoZW50aWNhdGlvbiBtZXRob2QgaXMg ZGV0ZXJtaW5lZCBieSB0aGUgcmVzcGVjdGl2ZSBDRE4ncy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNjb3R0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DRE5pIG1haWxp bmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48YSBocmVmPSJtYWlsdG86Q0ROaUBpZXRmLm9yZyI+Q0ROaUBpZXRmLm9yZzwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk8L2E+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5DRE5pIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0ibWFpbHRvOkNETmlAaWV0Zi5vcmciPkNETmlAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2RuaTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCkNETmkgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNETmlAaWV0Zi5v cmciPkNETmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZG5pIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2Nkbmk8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpDRE5pIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDRE5p QGlldGYub3JnIj5DRE5pQGlldGYub3JnPC9hPjxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2RuaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --Boundary_(ID_xpIuX+soGX65496WnIyqkQ)-- --Boundary_(ID_LrroFSWRXtXISoZEEmpZOA) Content-id: Content-type: application/octet-stream; name=image001.emz Content-transfer-encoding: base64 Content-disposition: inline; filename=image001.emz; size=1636; creation-date="Fri, 28 Oct 2011 09:25:11 GMT"; modification-date="Fri, 28 Oct 2011 09:25:11 GMT" Content-description: image001.emz H4sIAAAAAAACC7VXb2wUVRCf3d7BWa/HWahWBHrFYis9pEkvtTVQ9q5ixBSsLdJAMEJTElTkjxJL YhOXinwwxjRaNdQa0RRT/gQ1Fu0HJCQSNRGUGD6gYlQQ8INKI5oompy/3+7Oer1SILVM87uZnTdv 3rx5s2+nhoisAQwPt0OogKyUd5NITUAkNn/hXbT6OSrSisEcNfD49qDIFigtzP80a0xOBsTKyxE4 kDgQA+Cu3IDxFMhRwIwe/IYxbPJA2/UA16JthWU6dggFZM8rsgISdmSRaVbQl6daIpOgDwEmMBvI tcQuAS8E0iCu073tOovoX7YjtWHXzali6DinBaBf2nAOgfXmOixLpv8ZgBeHrTL82EugrwBoQ9wP xAGkCXP41282BAn3SeeOx1yVYerE7cWQxLNHti/TN3PVB/QAzFXIEtOCnACYVzD5nD+gI4cP12pM yqlXO4jpkGXk3A1hjqdnzCTmK3wonuo4uzOlXPOonHoxDGMz7AtwvlHwAEDiPry9jJjPB2FTDTD/ 5CTl1I5zVcN+NWecpzLi9s+BeqIZmAVwT8PPoN/UuaM5hzL4ZC1wHZ7JALAH4JnMtNy9F+JZZDDl ME/W3IUsc9yd0FUDznk8fyojTyIToF8sC2ShzJcmicki8GbwRrkXuiSeRaos07bAEwDIqXXGQyTF PvpqrbzfUIvEzOOwS5lyPlS6B8ZKmXQ9QJm6RmA9HNLnebxPYD51Ugkaj1NfLA/Jo7JKHhfGukra wBtlHXQrZa1rdpnfgMjqP9JbZz1XE95XaU6FNc8/zDV+ddfdhIOqBqjrBUx6PJFOf7D8pRqx3GoJ n8kXe3qH44PjvLvygAgw4TbX9zH45xo3xDpqJkNfCiCL5uBpZoRn+WJ7bEPC3A9fScg/TYgYD4An 7kmYK+IJ80foV9Z21Ox5LGF2wa5noNIJxfnBfPLO3krz+BuV5jvbK81c7/lQK+JaFzFieOa8Qu4N FAVvfcK5kvx65tBiD4yP9TAbYF44NuWTd5MEx3BtO7p68Ezi/UdqgDLpDWjNIyc269YCWD+s23I8 aA3kWsPv0eq3W+q+zN3r36MlmEfA1VyHZcnMg65HI5VDkJdAUQGcBIJAFTbF/VEujzQDZ8wlEwnK zb4fHL/vB6Z2Rgy6Rap9mTFwn31AD3A170zm58gjNakFe7t9znxp3nR8LO5M7qsaIClnFbhvgavP /NXcZ54Jcu2fww8wDgDaE7jnMPQMeCbqZzTnUAb/rC89k42QVwOXuzM1f5e671Jit7w2Bved7g/l 6L9/ITzk4zkCHgPnmL5/HJvm6S71/qVgQ1L/+v5th64LyH7/xuK7noBf5pzfF+3h+D1/69t9yXNv Lqu748MjPmdN/p9vOM9U61D5aOqx2Yu5CbwAOAHwfmP8DcE1xu68Hgeax7Gow+X0Dbh3g5EzB3IF wLzxnSCdenlpXdWBviRrsXTWF8mmlqV1RU2/JVWP/G2eZBl2FLbenHQJZAKv2Yj3YylGCwHmL5N0 f9RPBMIA6071Ie/djUP3FcBcnQKKAK7fnddolEdeN17JO21Q1nnM18X8YcoV36UJGJcBzFeuNfw7 sePZQF391o7kQFVVStJPJWnL+LmX0eQEnzDM/G/v9KP70TxUQLcFiALvAcVAEFgQGmcA5vRrHVAe kgv1A9Mr3v8AjPcAF7u3ju4f3D3/4GA5+75Ff/6e+qtpcpL3FmPbBID8Pg2xS0zq0CWtlY3omfgr M/vnyn1FtRL5xeUPp2qd50VPuvzGbpef3eny0o9cvu07l4/Q7eVjLa2hQk8GG9LrlWXYNEJej4Jj zV3dvu9CWm6ZKEH0fXH0ZOyVYkAXCpVND2NqxYH3AtRXI2kQxSoQcfq+Ts5wibFKJ38KnLi/hwRz pxamggfOGBIAj6PPuwY8hj5O5IX2Fejt2Cexx7uwzW533yb0jd12+/iS3K/7Pp4sMet8m/Z97QcS pgD/eP1i17l8Od79dHsU9vTDeaf/PtfGeU5M+K2fUXyMcivW/Kx8sI3+6Hukvg9ByDNAFGA96zdG vzscmwJwf/VAJjEG0nIos+srBzruneklmA/2DJRJ+j7o94lrRIHs7xPXbAW4J0L7t+znW2UXRpUy //vIlHV8KJ+OxzDAvbCHy4zFtNwxqJ3efhIFUBSg/C+hZ6b87BAAAA== --Boundary_(ID_LrroFSWRXtXISoZEEmpZOA) Content-id: Content-type: image/png; name=image002.png Content-transfer-encoding: base64 Content-disposition: inline; filename=image002.png; size=1019; creation-date="Fri, 28 Oct 2011 09:25:11 GMT"; modification-date="Fri, 28 Oct 2011 09:25:11 GMT" Content-description: image002.png iVBORw0KGgoAAAANSUhEUgAAAPoAAAAnCAYAAAAmTFXMAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAN7SURBVHja 7Z2xattQFIazeNAiG2NDvWWxXyBLhwx5BPsNAt46ZfADJINng8meQoaOIVPdpYIuHWowdCmhg+mS bAnGpXRz9YuccBFKsdIS3UjfgR9Jlq8x557vnHNl2d45OTnZQQiVWzgBoaqAHlujVqv9jLebqisI ghsCA5UV9N12u73eYAnsBAYCdEBHnqvT6bxptVoL1Pqobh3QAb2UUpBPJpNNFEWVVq/XW8fxfADo gF5a0BXoVbe9vb07QAd0QAd0QEeADuiAjgAd0AEdATqgAzoCdEAHdATogF5R0OO3dhgr8kjvAB3Q c9vl5SWg/x30Y8/iaAnogJ7b9vf3N+PxGNBzgH51dbU5Pz9PdH19nRwDOqB7C7omRRVdsAP6dqAP h8MEcDPtPyVRPgWI+zGAnrL5fJ7omRPuywF9NBplBi+gZ4OuIM5Kim6AaT99bMFodnp6mvh+vV4/ PMc9ry7Bxti+jVmtVj+K9EdsR7H6PoEu32he5C+boyKh9wp0OUSVSBVd26Kr+pbfW/8cK9pSF7GO c6ivyUkrDp639h7lJ0uOaROQdk5ba+u73W7iYx0PBoOH8wa6HreKZHOgrYLXTSw2xgPQz+7nYpEG vsiK7sav5sl8XXnQ0+2mHFXk+mqbih7b6ywYH1E/J+gXWQljOp0utwFdj7tVWYC7W5kFn17H/C+/ KxFYwhX8Vp2yxtze3t6l3vdhDp8c/EfQNw7wB76AruRqPq086HJCOmB1LAdZO+kj6D607i64ZlbN VYXdxLkt6Naeu2NzgH6Wo8uJcv7yzzJj/M0jz43CMPxeJOh2kVQ+K3IpyufoLxx0ma5nSAankqat yy1RKtgt0Ax0q9QynVNisOfZJx8u/Aa6vaaNmc1mN8/Ypu9mdAXvMyAX/EfNZvOrD627jrMSMqAD eu6P12wN7ZrgF5B2IUiA2gU1SfvWMbltvlUiN1D1mDveGbP0ZI0ufdPSwbc1uuaGNTqgc8PMv4Me ZV15LwJ063bswrLd31CkATqglwH0V9wwA+hlBJ173bkzDtDLDjoCdEAHdATogA7ogA7ogA7ogA7o gI4AHdABHQE6oAM6AnSvQG80Gr+q/l9VEqADeplBb4Rh+Il/n2wtYj98ABZALyXoCAE6oCP0olSv 17/oL4MV6FVWEAS/AR2VVo98f72SevAJgYFQ+fUHmwDuDhLGdmcAAAAASUVORK5CYII= --Boundary_(ID_LrroFSWRXtXISoZEEmpZOA) Content-id: Content-type: application/octet-stream; name=image003.emz Content-transfer-encoding: base64 Content-disposition: inline; filename=image003.emz; size=29493; creation-date="Fri, 28 Oct 2011 09:25:11 GMT"; modification-date="Fri, 28 Oct 2011 09:25:11 GMT" Content-description: image003.emz H4sIAAAAAAACC9SdDXAU55nnR6MZaST0BZJA8DYgQOIVXthlE9lrNsJRjNgyteLCJWLX3IoKewtV oSLO7EW+jS+iok3kPQQjECABkkYgG2HzIWyciMTYIiaJfGtfxIarla/si1hTG3yJLxISRpgvfdzv EXpHoxn5nVQuvttt15/up7vf//yep3t6+uOVO8blcpWhmHEdd7tch5AZ/scfu1x7V7hc2avX/oms 9dX6GNc701wuj1lhfNzidbmqYl2uQozeClvm+mePqzA51oWBaynKRtj9XgwrO0ynIXfaxZ8LwzfG JetuR5uRrLu80D223oPPrfz8/EKPK4llMswr9Aan5xa6XBnM8yFJo55/EgtdlTlMZ6FRBvmcv/P/ dFXyyZLC9n93/PG/PrXo8QXMkzb/HomvrCNtRC5X5cqxUdi0+OeicY5KM41P5Z8xfzk6hBFlcf1v xssYUybXf5z9COp0N88TyfQjQZ942hofVh3jHmf4AvH4UBmcFgap1QkUQFIrX6HLXch0PpK6MnL9 g/zDcKmr6zFpEyqZb9ZjctRXGBP7BBMF4/OFWQapWeyt5Y9/9heDwbHU0NTSLHfFxMT8LWXJZPum 0c4jjRkkj/FcPrGeX2GdRxHlGhszCo5lbpzMmGIwNZN2Zhru4HZgtx3L+deMf591JKfwbSCxafvb bIc8PM2+I9ukC11Esk0eKnyQexaxyzXw+NhofNrUz1fojitinuQ/tj32/CKkTi5XKvNLXGtca12r XV92Zbv+DeM/Z/wl1xeZ9wVil+uRQndlCeMnEMPYvk7KY/vgKleRrPPIisdc31/3WKX/22Nj1/On H4xdlZ8fazP2T+j0DOaYvIRfpmWYiWRa5n0JbeeD5LNu8h1jFBxqZSZDPHtCiWura5tri+vrLuHf 4vobxl9yPcW8v3T9hwerRf1X9t3KD2a4dqKr6DDa5GPmvdHRy3x2OZMZSOaJZH2B+kFp/YqxaUJB kmNBGuNaJHHauAbwe3/Nt1ds9z7mbvU85p6V/e0V2SwT8a1wy3IZXnUdqKh9uMDd8b9mUP0DFVlp KTEbGftSCtxPpn/OfY35f/nYt1fk/VGBO+2RAvdy39hXb4xHPltYfnVzpXv5jZVu38BKd+J43Ln5 2yuSnkqJySaWdlkCx5DHePN/GjtMBfdxWSTbexM6Q5DG+O8Zz2Msy5y/f+ULIlnmEMuxqBiFDsIi g/g82Ee2uhKYFh4ZzHcimbLLfl2JypHs179XOLE/PMR0DvOz0Cft47J/FrI0X1YJ2T+FdZmr8gfd v4N90fCKZ8m43iZIY/qnjMNrI8ukNrL+J9VmHcvk+C2D8f+06/EZV+XJX35K9bg0Xo//PkU9ZNlv Uo/PPChHRD0KmS/bN3z/SCyM/B2+mp9R1NgwvfDV8d9h2X9E7GUhx76JafnOmPrLSmbax/SfMWM5 WsdKsl4r/yxl7EUpubmo3b3iIZFM5wZ9fptjvXwPTqAA+jR/c6U+SZ1LH/+jq3nBsdTL1M0s/138 5krNHkUymLF8K+IezIr419Re2plpah3cDl9kgXyn5JxSvjsPtsPkbSDbxLT9bbZDHr5JSBhkm1Sg 7Sjab66pnxyPnmD9AsQQ/L0Uv/X8vlZu3/XgG/h337N+E2ewvnBIvlnj04wm/UaaPGUdOS49if6a D5Lf9b9lPJexLDPHbFmmiBlZj0vC+UnH6rdo24HCv4tyjigMkvvYuQbjf5APZ/ikc0TPg8VfYBMX Is4WKgtNWxZ94nnjlT+6Ona++J//6/urHlpWtOqllvdXbf9vL62S+LN/PLRKlvd/JrdI9mEQ/q/O G6VWjz7gDI5dMx6ch47PnjQy20TaaZSF5DcydDDryPx0JNtZ1v8c8iHZRmko1XG5OlnwSEicT6Mn ifORGR782o6Oyvcq1VkRO80piI1HbjSqVqD8WOMxirl42jxG1UV3rNPhjkdJKNW5iDrdcgAN5UuB 71l4jLeJbd4pTjV8/tg45EYjaieqCvKNwCfXfTaPEVVJ2wpyrMCrIjbFqUTPxk7F1x3ClwxvETud zTvZWeNJdIo9XhSDhtUaVOQxOQqfeNo8RtTl2Binixy7YhNRinMZdUfwCU89PMbbxDbvZKfBk+AE PB7kQsPqMKoL8g3DVxclx2FVS25+cvTj5fckO7Wo3hNevyT4roXwSVziteee5Gzw+pxSrweNqlLv kNqASrwmxyH4xNOW45C6Sm495NgDX48nybmKrkXwTYPnODzG28Q272nOSW+80+aNRSOqzXtfnUSt Qb778LVGyfG+aiG3AB4Bcg14pzkt6Lg3vH7CMxjCl0i8Oc6ee6KzNS7OKYtzoxFVFndPbUWb40yO wieethzvqwFy64Wvl1x7YRtAgxF8wnMOHuNtYpt3gnMevo64GDSsOuLuqvPwtQf57sHXHiXHe+os bdvIsQ2vtrhE5yw6FxdevwT4PPyIGz4fcTmxjc/nPBPvdSriXWhIVcTfUc+g8njjcRc+8bR5sE78 sBoixyH4huLgiE9wPPHhfMLzZhifxDZvn/N2vMfpgq8r/r7qgu1t1BnkuwNfZxSPO+oiuXXg0UGu HfE+5yJ6c0q+DN9E/eLhrSK28cU71b5Yx+8bVX7fPXRbVaMqn6mf8ImnzeOOSvPdV0k+l5Pk8yCf k4YyfOH1i4PnHbyMt4lt3nHOe/D1+EZUD3w9vo/Ve6g7yPcxfN1R+G6ry7TtIscuvLp88c5lX5zz zpR8OVy4Gj4vvHXENj6v05DgdgIJwyqQcBfdUg2oLsF4CJ942jw+VtkJ95STMILcjpMQ52SjnITw +gnPB2F8Etu8vc6HCTFOH3y9CXfQLfUhuhbkuwXftSget9RVcuvBowevKwle5yr6IILPA18+J5Im d4lbiW18HudkostpSxxSbYm30aA6iVoTjccgfOJp8xhUyxPvqKV4LE2McZYmepzlKD8xvH6x8NwK 4TOxzTvWuZs4qoYT76sh+IYSb6q7aDDIdxO+wSh8N9UAbXvx6CXXvsRYZwDdmpKvaNpE/dzwthPb +NzO+WkjqmPaPfQx+kidR+3TTP2ETzxtHjdVIW0Lpt1HoyjWKURF08LrJzzepMl8Etu83U5C0ohK TrqrkpJuoY9UAvIkGb6P4PNE8WAd2g6R4xC5Dk+DI8nteJPC+WLgKwnhk7gzineM83bSsOqCr4vP 6Eq6od5GnUG+G/CJpy3HG2odbYvxKCbX4qQYZx0qmZIvM3mifsInsc07xpmdPKzmJt9VTvIguqFm o4xkUz/hy4jicUOlJVN7PJKS2RbJMU4aykyeqn6bw/i6o3i7nPfg60m+gwbRgHoPvu5JfOJpy/GG 2kTbUvhK8SqFbRPaHMEnN5VyUybqZ2Kbt8tZkjKslqVwfEgZRANqCcpJMfUboH45eNo8BlQ2bZ0U tgFec1NcTjbKTQmvn/CUh/Fdi+Ltcj5MGVK98PXyGb2wfYiuTeITTzvfdtqW4VEGXxls21H5lHwP c7PA5C68Etu8Xc6K1CG1MvWOKki9iQbUCpSfajykfvlRPAbU8lRqj8dSvJalupzl6OHUqepXFcIn 166DUbxH1V08h1I5NsM3lNpP3K8GJ/GJpy3HAVVJ2wr4KvCqgK0SVUXwCc/qtIn6mdjmParWpN1X a9Nuq+K0m6ifuF8VpZn69eNZhKfNo18V0rYgjW2QxrZIGyUeVavTwusnPHVhfJ7pdu9RlTCdc7fp t9FHqJ+4X3mmh/KJp52vFj4/Ofrh88NWi+qm5FsPj/EWXolt3qNqA3wb4SuFrxS2DahkEl9JFI9+ tW46tcejGK+100eJR9X66VPVrzWET679M2bY+UbU7Bn3lTPjY/QRuk58XWXMMDnK9hVPW479qoXc AvAF4AvA1oJaI/iEZws8xtvENu8RtXXGPbUNvjL4ymDbijYH+a7juTlKjtfVJtqWzmAbkOvGGSPE I2rLjPD6Cc+5ML7cdHvuI2pJ+j21LP1jtTT9BrpOfF3lpJscha89Kt9Z+NrIsQ2+M7CdReem5Hsa HuMtvBLb6/cMfDvSb6EbqgK2Z1D5JL7yKB7X1fZ0ak+OZXhtSx8hHlFPp09VvzdD+OTezsMZdr5h tSLjnlqZcQvdUAUZfcR9Kj/D5Cj164zKd5HcOuC7AN8F2C6iNyP4hOdZeIy3iW31G1bVGXdVDXw1 8Plhq0ZVQb4+PKui5NinKmlbgccOct2RMUw8rJ7NCK+f8LwTxrc6M1r91mTeVWszb6EB1KfWoNWZ JkfhE09bjn3qMnyX4LtErpdgu4zemZKvHh7jLbwS27yHVQN8zZmDaEAFYGtAdZP46qJ49KnaTGpP jjV41WRyPxDVZ05Vvw/C+NbPjMa3YeZdtXHmLTSA+tQGtH6myVHqJ562HPvUVXK7At8V+K7AdhV9 MCXfcXiMt9RPYpv3sDoJ3xn4zsy8gfqI+9TxSXzRPPpUC22b8WjGq3nmMPEwHlPV71YY35ZZ0fi2 zuKYMOsWuoH61Fa0ZZbJUeonnrYc+9QAfH3w9cHXB9sAujUl3zl4jLfUT2Kb97A6D98F+C7AdwG2 8+jcJL5oHn3qLG3P4HEGrzOzhomH8QivnxyPvVkTfGPHZ2Ib34h6JotjQtbH6Abi+IyezjI5yvFP PG0erEPb4Vkfo3uIz80aUd6sqfjexMt4C5/ENu8R9TZ8l+C7lPURuk58Xb05iS+ax3V1kbYX8LiA 1wXYLqI3p+TLnD2Z71liO1/17PuqZvbH6CN0XVWjZ+lR9uCZlNRPPG0e11UabZPxSMYrefYI8YjK nD1V/d4J45PY5j2i3sPzCt5X+IwrsL2H3pnEF83jurpM20t4XMLrEmyX0TsRfHI+mjtnon4S1xPb +EZVw5z7qnnObfQR6ifuV/VzTP3k/E88bR79Kpu2c/GYi9fcOaPEoyp3Tnj9hOeDMD6Jbd6j6kM8 +/Dum3MT9RP3qw8m8UXz6FdXaXsFjyt4XYHtKvpgSr6HYTS5C+9xZOc7qYbUGXUb3UT96iQ6royH 1E88bR79ajltl+GxDK9lapR4VD2swusn17u38DLeJrZ5u5y7eA6rO+gmGlB30a0gn1z/iqfNY4AW 1B6PPrw4oju0cjhj4zvmQzQfe/4rPKtRKN85Ypu3yznvDKkLzh10Ew2o8+icYzyETzxtHgOqkLYr 8ViJ10rH5RSi1c5UfN65k/kktnm7nIS5Qyp57h00iAZUAvLODeWL5kEOtB2Gbxi+Ydjo6uB4507F tz6M782ofG/PHVaX4LvEZ1yC7W305iQ+8bTlOKDW0XYtHmvxWgvbOrQ+gm/sft+8ifqZ2ObN/b95 3HOadxcNIu7/oUx6/T7YZ+T+XyaeNg/u/9E2GY9kvJLncf8PZc4Lr5/wbAnjeyeKd4zzHp5X8L4y j/M32N5D70ziE0873yb4NuKxEa+NsG1CW6bky50/uX4S27xjnCXzR9Sy+XfRLXRDLUG580PrF83j hsqm7Vw85uI1d36Mk41y509Vv6fh2cC2yUFmMP013MyIcXbOdzsfzLcxu50P+Zy++fcQ53TzP1If og/m23xvqJ3k9bTV94bajt828tiG/zZy2I6ejshD7vM/nD1RZxPbmVdkj6qV2VyLZn+MPlIr0MPZ ps5yn188bR4fqeW0XYbHMryWZbud5ejh7PA6y3ObZ0P4xp7jRPHmOU62yxnOvq+Gs28jnuOgW0E+ eU4inja+m6oSvh147IBvR3asU4mejeCT516rF0zUz8Q2b4+zZoHLWbtgSK1dcBsNqjVo9QJTP3kO Jp42j0FVSNuVeKzEa+UCj1OIVi8Ir5/w1IfweYm9C+3eXidhYYyTvJDjx0KOIwtvqQTkXRjKJ552 vtoFd1QNfDULYpwa2GpRfQSf8KyHx3ib2ObtdTYsdDsb4dsI30bYNqD1QT75jRZPm8cttY62a/FY i9fahV5nHVq/MLx+8tz6eAifxJmL7N5xzuxFsc7cRRw/Ft1DH6vZKHORyVGeE4unje9j1QJf88IR 5HaaF8Y5Leh4BJ88998Cj/E2sc073tkK37ZFo2obfNsW3VZb0ZYg3234xNPmcVttou1GPDbitXFR vLMJbVkUXj/hORfCJ/0qcnPs3j5nSY7HWZbjQpzj5dxRS1BujslR+MTTznd2EfcH4TuzyOOcge0s OhfBJzxPw2O8TWzzph9KjtfZAd8O+HbA9gx6Osgn/SjE0+ZxR22n7TY8tuG1LcfnbEdP54TXT/rJ vBnCJ/14Hs61eyc6K3LjnJW5bjSsVubeUyvQw7kmR+knI542vrvqInwXcmKcC/BdyElwLqI3I/iE 51l4jLeJbd6JTjV8NfDV5I6oGtiq0bNBPulnJJ42j3uqkrY78NiB147cRKcSPZsbXj/heSeET/pt rV5s957mrFnsc9YujkWjau3i+2oNWr3Y5Ch84mnnuwzfJfgu5cajROcyeieCT/rd1cNjvE1s805y GuBrXuxBo6p58ZBqQPVBPumHJ542jyFVS9saPGrwqlmc5NSi+sXh9ROeD0L4konXa7t3srNBJzgb tRe50LDagNZrk6Pwiaed7yp8V+C7At8V2K6iDyL4hOc4PMbbxDbvZOckfGfgO6NjEPcN0fEg39i9 xig5cl+Qts14NOPVrJOdFnRch9dPeG6F8Ek/2i159txTnK1505xteXHIjXiug7bkmRyFTzxtOXL1 Cl8ffH06ESU7A+hWBJ/0Qz4Hj/E2sc071TkP34W8eORGo+o8Ohfkk3sB4mnzGFVnaXsGjzN4nclL dc6ic3nh9RMe75LJfGuJbd6pzpeWJDnrl8SjWDSqvoTWLjE5Cp942jxYh7bD8A3DNwyba0mq411i +ApcD67nP884C12IcbkeYvwTxvI3selMJyHC4N87MBn8G5R4pjkEm79f+QKT48Pkv9fMY674YDn2 NwsdjM8i83ckJUw/gdzmbzflAxl+1/3yd++aN/Y3Jf/z384rivurVasGH5tXdOHvXlol8R9mDa2S 5f8S+uVzWB6rVyxjsw2kdp9DPsSmH7v/cprvTzsLzD5xijiHRk+yPB+ZwVzPxTHjlM6LfVEvjX0e HUGNxI16UazxaMLje3jaPJr0y+6jus19DJ1Ap4lP63a32a8Mn/CUw2O8TWzzPqW/EfuCroh9DjXr b8L2N+jrQb5GPL8eJcdG/RS5fY0cy8i1LPaU3o7KY6fi6wzhO4l3vsee+0n9qOe4LvA8hwKogbhB f9ZjchS+n0Tle4PcOuDrINcO2N5AnRF8J/Cqgsd4m9hWvxN6p6dV+z0tKKB3ew7r/4K+E+Q7jOd3 ouTYoL9F22+SYwW5VnhO6krPCV3lCa+f8HSH8L1IXOS11+9F/YS3VRd7j6ImdIj4kC7ymhyFTzxt OR7WP4Ovixy7yLULtp+h7gg+4amDx3ib2Ob9oj7sPaYD3iOoUTfBdggdCPIdwvNAlBwP6b3ktpsc /eTq976oa1GdN7x+L+B1LYRP4pI4e+4v6CfjntelcUdQAzpIfFCXxJkcD4572nI8qN8ntx5y7CHX Hu8LxC/oaxF8ck7SCo/xNrHN+7g+EfecbotrRof16bh64np9LMhXj+exKDke1EfJrYkcA+QaiDuu W1BrXHj9hGcwhK+VeHO8vX6t+qvxLbosPoAOozriOr053uQofOJpy7Fe95NbLzn2kmsvbP1oMIJP eNrhMd4mtnkf06/C1xHfhA7p1+MPENfp7wX56vD8Hp42jzr9MrmdJse2eLZFfKs+i9rjw+t3DC+P b4JP4nJim/cx/Q3fUV3ha0QH0QHiA7rcZ3I8MO5p8zigR8ltiByHyHUo/hjxMe3xhfM9j1dnCJ+J bd7P67d9R3QXfF2+ev1T3379FvpJkG8/nj/B0+axX79Bbq/72Abk2uF7Xl9EnVPyZSRM1O85vKuI bd7P6Z0Jzdqf0IDq0D7ifboq2L9d+MTT5rFfpybU66SERnQEPU/8vM6I6N/egld3CJ+Jbd4t+r2E gO5JOIzq9M8TavW76B+DfLV4/mMUvn36Z/D9lBy7yLUr4Tl9OaFFd0/Jl5M4Ub+jeNcR2/iO6sOJ AR1IPIQOoL3Ee3VdsH+78ImnzaNWz0+s007iYRRALcQtOieif7vwXAvjk9jmfVR/mNikexMPov36 17D9Cv0iyLcXz19E8dir3ye3n5NjD3w9iUf1VXQtgu8IXvnTJuoncSuxje+IPjGtUbdNO4j2oT3E e3RrsP/9nnFPm8ce/QfT9uuleCyd1oSOEB/R+RH975vxGgzhM7HNu1nfndagh6bVo1p9f1qNvoNu Bvlq8LwZJcc9up/cfg1fL7n2wjYwrVkPTslXxIWJOXYJXzuxne/VpAbdkVSPalGNfhW1B/vfC594 2jxq9OeT9ukCPArwKkhqJm7WRRH974XHkzyZT2Kbd0AnJB/WScl1qFZPS/ZrX3KNjg32bxe+2Cge NXoUvvvwDcE3BJsruVl7Ivq3B/AqCeGTuDOKd0C/lcxxAb4u+Lrgewt1Bvn84562HP36i7QtxqMY r+LkAHFAl0zJl5EyUT/hk9jmHdCzUzgupHB8SNmrVYpfZ6H0YP924UuP4uHXqSnUPoVjdEoDCug0 lBHRv114NofxdUfxDuh34euBrwe+HtjeRd2T+MTTlqNff4W2pXiU4lUK21fQ5gg+uRbMSZ2on4lt 3k16SeohvTT1ANqrfy91t85Di4L926V+i/C0efj1/NRarVLZBqlsi9SAzk5t0jmpK7l+9SGF0pDw lIfxXYvi3aR/hWcvfL3w9cL2K3QtyLd73NPGt1s/RdsyPMrwKoPtKVQ+JV8+oOb4IrwS27yb9Iq0 Q7ogbT/aoz+Xtls/ij6bZjyE77NRPHbrP0ij9mlsg7TDqEkvR/kR/duFpyqMbzCKd5O+A98Q3kPw DcF2Bw1O4hNPW4679bdoW4FHBV4VsH0LVUXwybV00fSJ+pnY5t2o10w/qIun70d79J9O36WfQKuC /e934bkKT5vHbv356Xv156Yf0AXT2RbTm3Th9EZdND18/xOeujA+zwy7d6P2zTiok2bsR3vQLuJd 2hPs3y584mnj26X3kpufHP3w+WHbi+qm5CuBx+w7wiuxzbtRb4CvdMY+VKP/ArYn0Zcn8X05iscu /UVy+1NyLJ5xCDXqdagkon+78LSG8WWkR+PLSj+onfT9qAbt0lkoI93kKPUTT1uOu/RRcgvAFyDX AGxHUWsEXwNem+Ex3ia2eTforen1uix9H/Lrr6VX66+ivwryVeP5V1Fy3KW/Qm5/QY6l5Fqa3qg3 pTfozenh+5/wtIfx5WTYc2/QeRn1emnGPlSDqomrdU6GyVH4xNOWY7V+Gb42cmyDrw22l1H7lHzl 8Bhv4ZXY5t2gn4GvIqMW+fU3YfsG+vokvq9H8ajWT5Hb18ixLOMgatDbUXnGVPXrDOPLz7TzHdaP ZnLellmL/GgncbXOzzQ5Sv3E05ZjtX6D3Drg6yDXDtjeQJ0RfHIvrAoe421im/dhXZ3JdSV8/szd ejd8O9F3gnw78fxOlByr9bfI7ZuZ+3QFuVZkNujKzMO6KjO8fmP36sL4imbacz+sn5hZr4tncv42 0492Eu/URTNNjsLXHYVvp/4ZfF3k2AVfF2w/Q90RfLK/1cFjvE1sq1+DPgxfYOY+5EfVxNW6Lsgn 21c8bR7Vei9t/Xj48fLPbCBuwCO8fsJzLYyvZJbdu0E/Oatel87i+DyrBlUTV+uSWSZH4RNPO9/7 8PXA1wNfD2zvo2tT8rXCY7yFV2Kbd4M+MYtjAnxt8LXBdgK1TuKL5lGtj9I2gEcAr8CsBuIGPKaq 32AY3+asaHxfzeKYkMWxIasGcXxGm7NMjlI/8bTlWK374euFrxe+Xtj60WAEn/y+tcNjvE1s827U r8LXkbUf1aBdxLt0e5BPft/E0+axS79M2zY82vBqy2okbsQjvH7C45k9ma+c2ObdqL8xm/t+s/cj zuFm7yLepcuD/duFTzxtHrv0KHxD8A3BNwTbKPJE9G8Xvs4wPolt3o36rdmHdBd8XfB1wfYW6pzE F81jl36Dth14dODVMbuRuBGPqeqXMWdy/aqIbXxNeuccztnmHECcw83ZTbxLVwX7t0v9xNPmsUun 0jZpDueQeCXNaSRu1BkR/dvl/L47hM/ENu8m/S6ePfD18Bk98L2LuoN8cv0hnjaP3fpntO3Cowuv rjlNxE14hNdPeHK4mDPfD4nriG3eTfqw4t6f4t6f2ot2E+/WdcH+7cInnjaP3Xq+2qMdPBy8HNVE zPVlRP924bkWxiexzZvrS8X1Jd698PXC9it0bRJfNI/d+n3a9uDRg1cPbO+ja1Py5TsT9ZP7Ca3E Nr6APuEc1m1OHdqL/MR+3Rrsfy/1E0+bB9eXtF3qcH2J11KniZjry4j+98IzGMYnsc07oO/gOQTf EJ8xBNsdNBjkk/sH0Tz8up+2vXj04tXrBIgDeITvf8JXNHdy/dqJ7Xyvzj2sO+bWIe7/zfXrV1F7 sP+98ImnzcOvPz93ry7AowCvgrkB4oAuiuh/L3yeeZP5JLZ5B7RvHvec5nH/b14t4v4f8gT7twtf NA+/HiW3IfiG5nL/D7ZR5Ino3y58JSF8cr+yMwpfs34Lvq55nLfB1zWvhrhGd07iE09bjtz/o20x ORbjVTyP+3+oJIJPeDLmT9TPxDbvZp01v0E78+tRLaohrtEZwf73NeOeNo8anUrbJDyS8Eqa30zc jEf4/ic8m+Hb4OKYhcxg+mu4mdGsv0Pbbms/+Wb97nye5/J5PfM5p4P3XdRt7X9fo6tYZ7PVt0Zv Io9SfEvJoxSOr6DNEXnIc4ec7Ik6m9hWoyM6L7tRL83mGUI216LZe4j36Jxs81sgzyHE0+axR8+n rYOHg5eTfYT4CB7hdRae8hC+sec6UbyP6l9l8xwn+xDiWJ7Ncxx0bRKfeNr5tmfv12XwleFVBttT qDyCT3jyF0zUz8Q276P60QX0P1nA/akF3KdasJd4r84P9r+X50ziafPYq5fTdikeS/FauuAo8VE8 wusnzw2rQvgkHozi3aLvLGjWQws4fizgOLKglrhWDwb55DmdeNr4anUlfBULDqMAatHfQlURfPLc tWjhRP1MbPN+Tj+xsFkXL+T4sZDjyMJ9xPt0UbD//b5xT5vHPl1I2wI8CvAqWPgc8XN4hNdPeOpC +OQ5tmeRPffntW8Rz3YX8Yx3EfcLF+0n3q89i8z3Q/jE085Xu5DrT/j8C4+g5/ReVBfBJzwl8Bhv E9u8n9dPLjqqS+Erha8UtidRSZBPnmOLp81jv15H22I8ivEqXvQ88fN4hNdP+iW0hvBJP4oMDpg2 71adldOinRye7+ZwjpdTR1ynM3JMjtJPQTxtHgd0C3yBRU3oKDqmj6LWCD7h2QyP8TaxzZt+KPCV wVeWwzME2L6KNgf5pJ+HeNo86vQm2pbiUYpXaU4rcSse4fUTnvYQPuk3k5Nr9z6u83LpI5jbjBpQ PXG9zsk1OQqfeNr5zsLXBl9bDv1QYDuL2iP4pN9TOTzG28Q27xf0N+CryD2CGtBB4oO6PMgn/aDE 0+ZxUG+nbRkeZXiV5b5A/AIe4fUTns4QPulHlr/Y7v2ifnTxMV2w+ChqRIeID+n8xSZH4RNPO9/F 3EbdAV8HfB2wXUSdEXzCUwWP8TaxzftFvRM+P3z+xU3oEPEhXRXkk35u4mnzOKQraVuBRwVeFYtf JH4Rj/D6ncCrO4RP4iJk8z6hn9DHdbFuQQHEfUNUpE2OY/ceo/Jdhq8Lvq7F9BOE7fJi+glG8J2E RfZn421iG99JaI5D9hyS/7hviOqCfHKvTDxtHg26lpZ+PPx4+fVJ4pN4hNdPeK6F8J1iuiTP7n1K P5n3gi7No69gXjNqJOYZTJ7JUfjE0853VTfrHvh64OuB7Sq6FsEnPK3wGG8T27xP6RN5L+o2+Nry jqBGYp7BBPkaxz1tHo26hbYBPAJ4BfJOEZ/CI7x+p/EaDOGTOFr/+9P6S0tO6PVLjqGjqIm4SU/0 v5d7A+Jp42vSA/D15h1DL6LTxKf1YJCvwDW5//3fcMK/hHk7GH+a/e/z+QzQx/rfJxZGvqNC3rcQ +q4oWTcJxSIO+aa/v5R5fKgMToPuojST/r/yXM+MrcfhLuhjpn38DcGfMX85krbyGevRMuRFuexV ufwf4dd5RTL9r+PdUVJDeXfUt3958nEzlpqa2prl/xLfYxFD3WVb/Dn6ffRgO4Rvg9/Nu6Pkc/4E VaDtKNp7LEz9bO+xWOVax45WPPb+isrbuz+V91hwC3SsD4p8N7hdMek9FrKM21xjNSxmHDqYa/t1 zBTOhPGF5vuQzPdB6lGJylH4eyweKnzw/ctiWfg7h0Jrw2rmb0CC7/iQ7foHdJv5Xbz/yvCKZ8m4 HmKchuS7G14TWSY1kfVtNYFvbDD+ph47mVuBftt6PEHbgjHnye88+bLsK1tff7CvJP38U9lX5DuU hv4YhddFlkld5Htgq4twxrOODOG1KWRePgqvTeIUx/bvdC9bJfvJ93+L9w/Jsdl8ti/kuH2G+cIv LzNZytiL/ikxF7W7E9JEMv2v4/1DUh95/1B/YWVwLPUydTPL/yUet9tkGyA3/8h38MF2mLwNZJuY bcj+VGmmWb0yh39ETH5hbBQ2Lds4DyUhc9zeyXQFinbcNvX7//W+PpOn1EeOV5tQJ0pF/4TmIllm 3kUky3jUM3Y+Usw4dDDHcPEZf8fg7/z9caH1KuRz8h8ATDqWf5rvj7vK50lt/hmF10aWSW2kXp9U m3Usk31QBlP7ZHas3/a37Tepxx9+iu+Pu0YeUo9fovB6yLLfpB5/yHoyhNfjLeZ1oPDjt6/Q9f/s nVVfLP/9sfPUFR8+9Li8s6rntSWPyzurJJZ3Vsly29/GmuPCb3qN8BXyfRTJ+jKWwYx/k/dXSTuN spAci0IHU1+Zn46SkEx/DvmQbKs09GNmdqJHQuJ8jJ8kHv++MfXgvZnynY9j+sfuFbE/dBfEvobO oe8Sf9edH2s8vjvuafP4rvui+/vuDvdr6A30Y+IfuyPfX/UjvKrgMd4mtnn/yF0Nnz/2PDqHXiF+ xV0V5Htl3NPm8Yq7krYVeFTgVRH7I+If4bGS/H3I1E94ukP4LhIXeez1u+he4+lwF3teRe3oLPFZ 98T7q4RPPO18l2Pb3V3wdcVeQD9yX0bdEXzCUwePqZ+Jbd4X3Q3wBeALeL6HzhKfdU+8v+rsuKfN 46y7lrZ+PPx4+T0XiS/iEV6/N/C6FsL3Q+ISrz33H7o3eF93l3q/j76LXiJ+yV3ClfGDffrlcU8b 38vuq/D1eH6AOtAbxG+4r0XwCU8rPMbbxDbvH7pPel9zt8HXBl8bbCdRa5DvpXFPm8dL7hbaBvAI 4BXw/pD4h3iE1094BkP4LhBvjrPX74J7a9x5d1ncOXQWnSE+494cZ3IUPvG08w14X3H3wtcLXy9s A2gwgq8Dr3Z4jLeJbd4d7vPwdcS1o7OojbjN3R7kaxv3tHm0uc/Stg2PNrza4jqIO/AIr5/weDgJ NHyvE5cT27xfdz8T/6q7Iv576GV0mvi0uzzeeAifeNo8WCf+rHsIvqG4VxEc8R3uyPdXCU9nGJ/E Nu/X3W/H/8DdBV9X/EvoNPFpd2eQ7/S4p83jtPsibTvw6MCrI/514tfxCK/fa3hl+CbqJ3EVsc37 NXe17/tuv++76Aw6RXzKXeUz9Ts17mnzOOVO873kTsIjyfcD9Brxa+7I91edx6s7hM/ENu/z7vfg 6/G9gs6gk8Qn3d1BvpPjnjaP/8Pe+UBXVZ1p/7JJSAjZECDRAAECBAg2WFY/7Og00TQX/bATWuqA ErgBAgHy54a/AQKEmrZYsQ3VNWKrNZZAAgRIICH81SDR0qnaUPlarNqGEdeHHe2Egana5cyE4fu9 996TczmX7BsZcdq1vrN82Oc55+znPvs9+557zj47vnvUGeq2odGGVlv0cfhxNJzxEz8pDIBYbT8G 3wo3aR9Tz/Q9pKr6NoJ6UAevU3b+KvEnmiaNPSqZukl9m8BhcBx+XIXmrxI/Fxz+hJu0j6kP8NeB v46++0AdvE7Z+avqApomjTp1nrrtaLSj1d73GPwYGs74HUVrcowdP+G1cJP2UbUnplnVx+wHe8Fu +G5l56/aHdA0aexWk2L2qbSYA+AQOAo/qkLzVx1B66MgfxY3aR9R/x5zUHXirxN/nTG74LuUnb9q V0DTpLFLXaZuBxodtLUj5gj8CBrO+IkfyTVl9b/D8ENwk/Zhdbxfk2rp1wDqwE74TmXnrxJ/omnS 2KUy++1R6f32g4PgCPyICs1fJf9vlwhuXi1/Fjdp87Qf26RiY+tBHaiF1yo7f1VtQNOksVO5qNtJ Gztpa2c/4hJ7CA1n/MTPDIe/U3CT9iH1amyjasNfW+xuUAuvVXb+KvEnmiaNWjUdf9loZNPWbLxN B6H5q8RfvL42fsJN2ofUEN2okjTXB70b1MJrlZ2/SvyF06hVcdSNRSMWrVh9CH4IjevFLz/In/x/ d86G8des3kazXXN94DPadQ28Rtn5q8SfaJraWKvmU9eDPw9aHrzNB6H5q8RPSn87fhY3aTerCf0b VVp/rg/9d4MaeI2y81fVBDRNGjUqmbpJaCShldS/Gd6MhjN+4qfU4e8C3KTdrD7of0B1oN3Rfxeo gdcoO3+V+BNNk0aNWo4/LxpetLx4Ww5C81eJv8kMGljfX4ubtJvVXQMOqPQB+8AuUAOvUXb+KvEn miaNGjWJumlopKGVNqAZ3ozG9eK3KcifPLt+FEb7oPp3NDsHcG3mMzoH7IDvUHb+KvEnmmZ/FdQt x185WuV4qwCh+avEz5Q4O34WN2kfVPfHHVDZcXvBLrADvkPZ+at2BDRNGjtUJnXT0UhHKz3uIPwg Gs74iZ+tDn8RA81tP6j6DuTebeBesBPsgO9Qdv4q8SeaZn9P4K8Sf5Vx+8FB9QQIzV8l/mbgx+p/ wsPlrzqocvDnwZ8Hfx685QA7f5X4E02zv+nUzUYjG63sgQfVdDBjoDN+8qxfG+RPePwgs3aTGjJo v0oatAfsBNvh25Wdv2p7QNPkb7uqxl/VwD1gP2iCN6nQ/FXiJzh/lcVN2k2qcFCDKsGfF39evBUC O3+V+MsP08btaj51PWh4aKtnUBO8SYXmrxI/wfmrhIfLX9WkJgxuUBMH71Fpg2vBdvh2ZeevEn+H wvprxF89/uppawPeGkFo/irxE5y/yuLm+K3D30b8bcRfOd7WATt/lfgrHWzuI9vVcup60fCiVTK4 Cd6kQvNXyVhOcP4q4eHyVzWqu+IbVEZ8HahV6fHV8Gpl56+qRuNUGH/VqhV/LYPr1An8nRjcCG9U ofmrxE9w/iqLm+LXqB6Lr1db8LcFf1vw9hiw81eJv03x5vhVqwrqlqOxEa2N8Y3wRhWav0r8BOev En5vglmb8b6EejUtoQ7UgGp4tbLzV4m/cPmrqtWZ+Bp1Gn+n8Xcab2dAaP4q8SP5qqzrn8XN8XsG f88l7AY1oFo9A55KsDTE39YwbaxWT1B3C23cgtaWBMYDQWj+KhmrC85fJf5m3hIufjm31KvcW+pA DahWOcDOX7UtoGlq4zZ1Hn/naOM5/J1LYDwQhOavEj878WO13eIm7Ua1B38N+GvAXwPe9gA7f5XE TzRNGtWqmrrPofEcWs/d0ghvRMP5+yF+Pnb4C5e/qlEV3so14dY6UAuq4dXKzl8l/kTT7O8y/i7i 7yL+LuLtMgjNXyX+gvNXWdyk3aiO4+8E/k7g7wTejgM7f5X4C5e/qlo1UrcBjQa0Gm5thDeicb34 Sa4p6/z6rs9wk78mtS6R63Mi1+fEWsD1Gdj5q8SfaJo0OIa6V/B3BX9X8OZKbFSh+avEj+SaCvYX LvdUk3oVf6fxd5rPOI23V4Gdv0p+P8JpbFet1D2Bxgm0TiQ2wZvQcMZP/EmuqWB/j8BNbed9zJD9 asuQPWAn2A7fruz8VeJPNE0a21UcdTUaekgDaII3qdD8VeJPck0F+xNu0m5Sb+PvHNrn+IxzeHsb 2PmrxF84je3qDHVPo3EardN4OwNC81eJP8k1ZfmT+9On4CZ/B9UzQ/er54buBTvBDvgOZeevEn+i adLYrpKpO3zoHrAfNMGbVGj+KvEjuaaC/Qk3aR9UH6B5EX8X+YyLePsA2Pmr5P45nMYOdZ6659A4 h9a5oQfhB9Fw9j/xJ7mmgv3thJv97Rl2QDUM2wt2gR1qD7DzV4k/0TRp7FCTqDsRjYnD9oOD8IMq NH+V+JM8FsH+hJu0eb7E3xW0r/AZV/D278DOXyX+wmnsUJepexGNi2hdxNtlEJq/Sp7H702y/Qk/ DDf5a1bHkw6oE0n7wC5QA69Rdv4qef4VTZNGjcqkbgYaGWhlJDXDm1Vo/irxEzn8Wn/CTdrNqu/w A0oP3wd2gRp4jbLzV4m/cBocQ90r+LuCvyt4cw1vRsPZ/8TfTIe/n4f19+rwRnUaf6eH7wY16lVg 568Sf6JpamONmk7daWhMo63T8DYdhOavEn+Sa8rqfxY3aTerISMa1fAR+8BuUAOvUXb+KvEnmiaN GhVHXY2GRkuPaIY3o+GMn4xPSq4py5/wN8JoH1Jvo3luBPdtfMa5EbXwWmXnr5LxP9E0+WP8j7q5 aOSilTuC8T8Qmr9K/ATnr7K4SfuQmjCyUU0cWQ/qQC28Vtn5q8RfuPxVtSqZusPRGI7W8JGH4Mxa C/m7U/ETLn/VIbV55GFlzl91WH0wskldHNkAuKcbuRO+kzo5vFNPAdZizfviY1216NYqc/6qWrUc vRLaUUI7SmjDchCav0reO9yRbPcDi5vifFjdlXxQZSTzLJq8B+yE71R2/irG8H2aJo2dahJ1J6Ix MbkJHIYfRsPZT+U9ySNB/oR/DDdp8x4nuVldSd4PuJYn8x4H2Pmr5D2JaJo0dqkK/G1EYyNt3Zh8 BH5Eheavkvde946y42dxk/ZRdf+oZjVtFNePUXvBbvhuZeevkvdgomnS2K0yqZuBRgZaGaOOwo+i 4Yyf+HkqyJ+8V4wcbdY+pvqOPqT0aK4fo7mOjK6D1yk7f5X4E02zvydG7VNb8LcFf1vw9gQIzV8l fmbix7oOWdykfUzljD6scvGXO5rrCN5ygJ2/St5ziqZJo05Np+40NKahNW30MfgxNJzxk/fEO4P8 CU8YY9Y+roaMOaKGj2kCDWAPfI9K6Pr7VHlPLJomf3tUNf6eG90EDoPj8OMqNH+VvPdfhB8rfhY3 aT+vCvFXMuYg4Hl0zF74XrWoy5/MAxBNk8ZeNZ+6uWjkopU75nn482g44yd+Dgf5k3kVY1PM2i+o CSlH1cSUZsA9Xso++D5l568Sf6Jp9tc4Zr9qwF/DmKPgedUIDof4Ez+r8WPFz+ImbeahpBxTG/G3 MeUAYB4KsPNXyTwP0TRp7FPLqVuCRglaJSkvwF9Awxk/mSfz8yB/wu8Ya9ZuUXeNPa4yxpIVY2wj qIfXqzvGWm1kDkzY/FX1qhV/J1IOgWOgBd6ifh7iT+Y9PYIfS9viprafUI/hb8vYw6ARNMAb1CNd /hoCmiaNBlVB3Y1obERr49gT8BNoOOMnft4I8ifztu4dZ47fi+r+cc+raeOOgINgP3y/urfr71PF n2ia/Z0Z26RO4+/02OfBCXUGvBHiT/w8hR8rfhY3ab+onhn3gnoOf8/h7zm8PQOe6vIn88hE06Sx Xz1B3S1obEFry7gX4S+i4YyfzBN8L8if8JnjzdonVc74FpU7/ihoBgfgB9TMrr9P9Y09hvHHuCD+ zo07Cl4AzBME74X4a8XPTvxY8bO4qe2tag/+GsYfA82AcUOws8sfY0I+TZMG44LUfQ4NsqmAVngr Gs74iZ+Pg/y9BF+Uao7fS6ow9YQqST0ODgPe64BFXX+fKv5E0+zvMllxLuLv4vgToFVdBh+H+BM/ h/Fjxc/iJu2X1PHUF9UJ/J3A3wm8HQeHu/w1BTRNGry3oW4DGg1oNaS+BH8JDWf8XkYrcoLtT3i4 v599WT0w4aSaOeF5cAQchPM9nmC1UcYGRNPkj2MmHFZXUp8HLwI+d8LLKnKC5S/dde3fzxJCX/6q 2yl/jP5gyljQC3Cp8K1TdP3NSxTrXNYD9/jh/+alN8feB1pAI5D5+tGZrs9tjv6kLzzk+5ukoqkP uiV/1W86Z7olf5VwyV8l+01z9IPaKiEMLNf+7e48tt4JpK1SymKVPZ2Xb8WaU9B1DmT9KyAaMATk m3+/QfOukR1WnxCewgfPYv9kYC3Wc1cfNqzXqb3X6rTeK8FSUAQv1nb+qmI05DnfpFGsD6hlzH5Z BcrABvgGZsBIUIL9rUerFD+WP4ubtNfrst5rdDn+yvG3AX9lwM5fVYRmuPxVRXoZdYvR8NJWb+/1 8PW6NGR+u/g5FeRvHXxyhLnt6/SdEat1esQK4AWF8EJt568Sf+HyVxXpk71LdAv+WmhrC95OglMh /srQ2oQfK34WN8WvTG/GX2XEcuDVP4gogBdoO39VAZrh8lcV6oepu4E2lqNVHrEOXqY3RWQ4zq/4 ORvkby18SqQ5fmv11MhSnR25DBSDJfAlekrX/HbxJ5qmNhbo1/HXRhvbIkpBGbxMnw3xJ3624seK n8VN2mv105GrdBX+qiKL9LN4exrY+auWoBkuf9US/Tht+wEalWhVRq6Fr9VbQ+a3r0HrQpA/4TP4 kpr8rdGz+qzUnj5LQSFYDF+sZ3TNb18c0DRpLNbv0Lb2yKVgFVgDX6MvhPhbjVYtfqz4WdykvVrX 4a++TwkoBIvgi7Sdv2oRmuHyVy3S26j7LBpVaFX1WQ1frWtD5t+Ln4+C/JXC8/lRMvkr1QVRK7Q3 ygsKQD48X+d3zW8Xf6Jp0likL/Up0B346+izAqyGr9YfhfgTP4fwY8XP4ibtUn0sarluwV9L1BKQ D8/Xdv4qmZvYHKaN+foAdevRqEerPqoUXqoPhcy/X4VWRLTtT3gp3ORvlS6LXqbLo4vBYrAQvlCX ds1vXxjQNGks1Ffx1xlVDJaDVfBVOiJkfvtKtE4F+bO4SXulfiV6qW6LLgKLwQL4Am3nr1qAZrj8 VQv0Seq2oNFCW1uiV8JX6lPX9Rff147fCrQ3wU3+VujNfUt0Zd9CsAjkwfO0nb9K/ImmSWOBHkDd 2L5FYClYCV+p40Pmt4ufsw5/wk3ay/Vb+GvvWwDywXx4nrbzV+WhGS5/VZ5+nbpttLENrba+K+Ar 9NkQf8vRSomx47cMvhVu8rdMPx3j1VUxS8BCMA8+T9v5q+YHNE0a8/XImHydFFMASsBy+HIdmr9K /Fxw+BNu0l6m348p1h3464hZAObB5+kLXfmr5qEZLn/VPP0ObWtHo522tscsgy9DI8Px+yv+Jvez 47cUXgs3+Vuq6/oV6fp+i0EemAufq+38VeJPNE0a8/QX+y3Qaf2WgGKwDL5Mh+avKkHroyB/Fjdp l+hP8NfZbxHIA7nwXP1RV/6qXDTD5a/K1Zeo20EbO9Dq6FcCL0EjwxE/8TOFBxzr+iz8ENzs71hs oW6JXQTmg1x9DNj5q8SfaJo0cvU9sXk6HY10tNJjS+AlekrI3weInwgQ7E+4SbtER+tCHavzwXyQ C8/VEV35ocRfOI1cfZW2deKvE3+deLsKQvNXedGaEeRP+Clg8ufVr+CvDX9t+GvTHrhHn+ry5wlo mjQ8+hvUzUYjG61s7YV7dWj+KvET39+On8VN2l6d2J/rQn+uD/3nAw/co+O78kOJP9E0aXj0AOrG ohHbn3PR3wv3opHh6H/iJ9/h72wYba9+C3/taLf3nwc8cI+281eJP9E0+5uHPw8aHrQ8eJsHQvNX ib+UoPntFjdpF+vUAQU6bcBCMA/MgXt0Sld+KPEnmiYNjx5J3aQBnAO0kgZ44V40Mhzxk2fV0iB/ wi+E0S7W76PZgb8OPqMDf+8DO3/VnICmyd8cvYy6XjS8aHkHFMOLdWj+KvEzOc7ufxY3aRfrO+OW 6PS4hWAumAOfoyfHWdcA8SeaJo05+otxxB6NtDjORVwxvBiNjOvEb5PD30dhtIv1J/jrRLsTf514 +wTY+avEn2ia/T1M3XI0ytEqx9vDIDR/lcRrysBr4yfcpF2kpw5corMHLgBzwWz4HD2lK3+V+Aun MUffQ930gZwDtNIHFsOL0XDGT571twb5Ex4xKJy/6EFLdOygBWAumK2jgZ2/anZA09TG2fpx/FXS xkr8VQ4sghfp0PxV4mcGfqy+Y3GTdpGeNWix9uDPMygXzIbP1jO68leJP9E0aczW36Bt2Whk09bs QUXwIjQyHP1P/NQ6/MUPNmsX6cTBi3XS4AUgF8yGz9Z2/irxJ5pmf9toWxX+qmhrFd62gdD8VYVo 5ePHip/FTdqFugB/3sF5IBfkwHN0/mBLIyegadKYredR10MbPWh5BhfBC9HIcMRP/Bxy+EuJN7e9 UKfGL9Jp8XkgF+TAc7Sdv0r8iabJX44+gL962liPv3q8HQCh+avEXyl+rLZb3KRdqMvwV46/8ngP yIHn6NJ4S0P8iaZJI0cvo21eNLxoeeML4YVoZFwnfqcc/iYnmLUZ70vgvi2B+7cED8iB52g7f5X4 E02zv5O0rQV/LfhrwdtJEJq/SsbCNuHHarvFTdqM9+GvMmE+8IBZ8Fl6U9f8+1kBTZPGLP0wdctp Yzla5QkF8AI0nPHzjdU5/E25xdz2Aj31lkU6+5Y84AGz4LO0nb9K/J0Ncw5m6dfx10Yb2/DXhrfX QWj+KulvW/Fjxc/iprYX6qfxV4W/KvxV3ZIDz9F2/io5v6Jp0sjRj1O3Eo1KtCpvKYQXouGMn/i5 4PA341azdqGedesi7bk1D3CNuDUHnqPt/FXiTzTN/t7BXzv+2vHXjrd3QGj+KvEnuaaC4yfcpF2o 627lmoC/evzV460O2PmrxF84jRy9jbpVaFShVXVrIbwQjYzrfH8/CvInvyfh8lcV6YJErs+JCwDX iMTZ8Nnazl8l/kTT1MYcfQl/HfjrwF8H3i6B0PxV4ic4f5XFTdpF+hj+WvDXgr8WvB0Ddv4q+X0L l79qtj5A3Xo06tGqTyyCF6GR4Yif+JFcU9b5FV4KN/srG8K435AFgHu4IbN1GbDzV4k/0TRpzNZX 8deJv078deLtKgjNXyV+JNdUsD/hJu0i/cqQJboNf234a8PbK8DOXyX+wmnM1iep24JGC1otQ3hf A0LzV4k/yTVl+ZP71U1wk79ivXko92xDFwLu4YbOgc/Rdv4q8SeaJo3ZegB1Y4dyD4lW7NAieJEO zV8lfiTXVLA/4SbtYv0Wmu34a+cz2vH2FrDzV8n9cziNOfp16rah0YZW29BieDEaGY7+J/4k11Sw v61ws7+nhxXoqmGM/Q2bB+bop4Gdv0r8iaZJY44eOWyuTkIjadgSUAwv1qH5q8Sf5JoK9ifcpM3z Jf460O7AXwfe3gd2/irxF05jjn6Huu1otKPVjrd3QGj+KvEnuaYsf/J8Xgs3+fPquqQCXZ+UD+YB D9yj7fxV4k80TRo8X1I3LYnnS7TSkni+BKH5q8SP5JoK9ifcpO3Vn6DZib9OPqMTb58AO3+VjB+E 0/DoS9TtQKMDrY4kL9yLRoaj/4m/KcOv9XcIbvZ3bDjjf8PzAeN/wz36GLDzV4k/0TRpePQ9w+fp dDTShxcAL9yrQ/NXiT/JNRUcP+Emba+OHsGY0wjGnkYwBjXCA/doO3+V+Aun4dFXaVsn/jppayfe roLQ/FXiT3JNWf5kvPJUGH8l+hX8tY3gvg1/bSNy4bnazl8l/kTT1EbG/6ibTRuz0coewfgfCM1f JX6C81dZ3KRdohNHFuqkkYsA438jc+G52s5fJeOnomnSyNUDqBuLRixasSNL4CVoZDj6n/gJl7+q RH+Xuub8VSX6rZG8z+Xz2kdyT4fft4A5f1Wu3sQx5vxVuXo+eh50PbTDg495IDR/lbx3SEm2+4HF TTFaqlOTi3Ra8mLAs2jyXPhcbeevmhvQNGnM1SOpm4RGElpJyUvhS9Fwxln8lAb5k/cmF+Ambd7j JPMeJ5n3OMlcy5N5jwPs/FXiTzRNGnP18mTuM/HnRcuLt2UgNH+V+JFcU9b3yOIm7WX6zlFenT6K 8alRjFONmgefp+38VfMCmiaNeXoSddPQSEMrbdQyOO9xQubfy3u64PxV8l4xXP6qFfqTUSW6cxTX j1FcR0blwfO0nb9K3tOFy181X1fgr3xUAfCC5fphEJq/SvxMGW3Hz+Kmtq/QU0eX6OzRXD9G8zw6 Og+ep+38VfKeUzRNGnk6k7rpaKSjlT56BXwFGhmua+dBiZ+tQf7kPXbEGLP2Sh09ZpmOHcM73jGL wQL4Am3nrxJ/omn29wT+KvFXOXopWKEfB6H5q+S9v+SasvqfxU3aq/Qs/HnGFAPGqMYshC/Udv4q mQcgmiaNhXo6dbPRyEYre8wq+Co0MhzxEz+Sa8ryVwqPTzFrl+rElOU6KcULuMdLyYfnazt/lfgT TbO/6jG8Z8ZfFf6q8LYNhOavEj/5+An2J9ykzTwU/Hnx503hHQLeCoCdvyo/oGnSyNfzqetBw4OW J6UUXopGhiN+Mk9Gck1Z/oSnjDX7W61TxzJHcGwJKASL4Iu0nb9K5smIptlfI/7q8VefsgKU6saU 1To0f5XMe5JcU5Y/i5u01+gy/JWPXQoKwWL4Ym3nr5J5UKJp0lisl1PXi4YXLe/YNfA1aGQ44id+ JNeU5U/mkYXLX7VW3zlulU4ftwwUgSXwJdrOXyX+RNPsr3Usc1Dw14K/Fry1gtD8VeInOH+VxU3a a/XmcaW6En+V44rBEvgSbeevknlu4fJXLdEV1C1Hoxyt8nFr4WvRyHDErwyt4PxVwqeMN7e9TE8d v1pnj18OvIBxQ2Dnr/KNPY4zaxToM/hrG8c8Qfy1jSuDM08wxN86/EiuKev8WtwUv3X6afxVjV8B mI8ynnFDYOevKgxomjQK9RPUrUSjEq3K8evg69DIcMRP/ATnr1oPD5e/ar2elbpGe1KZK5haAniv A+z8VeIvXP6qQn1+PHOB8NeOv3a8nQeh+avET3D+Koub2r5e16Wu1fX4q09dCorgvIPpmn9fFNA0 aRTpaupWoVGFVlXqevh6NDIc8duAVnD+KuHh5t9v0A9MKNMzJ6wCy0AxvFjb8+/l2Ttc/qpifRl/ HamrwFqwAb5Bd5+/6iy+J4DfgZs5/34r+puBNf8+k/XJQMW1/p7C9Sv5h+V0W9vdijIYst06jtWr 0Zm9ekvd1MD23pSyxK67Lcu993+7/+XXX3f3vnBvVyl5PxIye/nmr0f4D/X9/UCKb92eS8+fFshp 9C3y+fPAnUD0pZTFKuUvFPr4N4X8yyXW93cLUs9aj0T8Ibh4lnifAv8HvArkuL1qQ+y/xs7zwaoT FfR3DxxyQ3/34KHidOCPe6/e6axPAhJPKxZZx6e5j1d8zf3MOw+6Xzx9r/v1bdPce6Z91W1tJ37f js/sVRFHvUCdqxI7Aba6Yha8LvGz2iHrg0Es6BW0PZoKD8LTwGnwEngT/BLI57TH7oldqnNjfxeb ECvrlp7E5Xp6VOlRjO7jwMlAzoXEJSbTXy8RLn+3IB57v/Zo1siWL7u3rPy3LDZ+VY4V/9KWnrR9 PMeJnhwvC7K+0mpDcHyi8S1xmATc4Ag4ASQWkeCeCG8/oF/r54Os97N0JBbWOof2uP2lHFwApP23 ZfrbJH59+anep4kC1+WsNyctzXoqbpJbcsBwmPU3HtfkNCGWnT/KcH1z5N0YuEc0/Evw+iA2Wedf PkfWZbkFyLpsSw2sS/wfAMtZkfUPreCxLssTspElyhVBXphCV4lrkWuVK9n1dcq1lA+4lrEtz7XU f1iYf9NV44x01Z+jUuOeLI+L7N/r972eLJdEFecHfEXdF+GvPunfMlQyq97LGXLqXPXvDXL9Mm/T XdFCXK7M2D8MclWM/s5dmyLk8pXg+05rdsj5G3B7pW97JK0RuTTqxlEmU8fl+ofy+a4ny6Xf5VL+ xzMV5VJfFv2TivKyiTERT/9iqCs588O1Fzg+724+Y2a6+gTPnejIsvXSINdbP/lueRzHi47Ue+8/ L62Vev5Q9XLtTxg1XNbz0fjlFy6vFT3Rzl/j+/OZru+qHDMjgCmUR8H94OdA9lm5dmTfzwLbsimD F/Egy3Q2Tg7ssPooMfHlk9nMdhrq639fyLT7w22sp7A9EZj64lT2pvuOuTY32O2uZJdrQcTdvt54 NtlfdtMrJXqxQNolnyfrsgT3Scu3FZdZ7P87IHH5OnDGRfZJXOgExjw74rM3x8hifYYVm8l8WCqQ 7+aNxOYjNN/3KduxGQx/gO/HCtdq37ellM9fzPdkJaWbcimZ6xb5/nXdl+GLWsXWTf7y7HP+8r7n /eWx3/rLTy75Slf/3vf4ov1xjK+sGDjIX35/mL/82QR/mf6/fKUr5299Zes3p/nL78/xlz8r9Jd7 V/jLr33LV57/6vd85X/v2mLFmLD6+nerLx7+8/gi687z+ADb5DxK3LJB8OLv3VevlrKxhzH15Zrq w/Fcr32Q9UgQAaQfSCn7LN43wK1tVl02h/SXCraJlxvtL5nUnQxYrrmup7pcGV+6u6Ljybs/29jP 4IOmg1+AvwdvADkv1rVlOuu/CWzrLvZyDP58i3Vure9PHVurwI3Go4C6Hp+yHQ85VzNd9/Jtud81 xeUaNcsfl3FP+cs/HPWXI//RXw582192c+VxuW7k2uP1efDHbTXrzrjNZJvETbx2F7dZ7AtqhysG Hg2sPshqSP/azLZycKPxnErddMDS1b/k+phGNDMH97pHeljrF6N9ZXc97UbiJW0tA9LPNgBnvGSf xEu8dBev6ewTnxIfWcaCWHCz+9o0rslruLdZ5MrMHuCPzI9T/eWZL/vLvvf6y8vZ/vIz72sP006J 3XbgjJ3s60lfs9vhj5tczwQRQBZnPCvYVgputK9lUncyYOnqa70gE7ltzLkJcZqB9g4gcaoFzjjJ PomTeDD1Mfz5ls8rHvT9vgtvUjx20RKJx17gjIfs60k85Lspy+cVjwkuV9aKmxSPetoh8TgAnPFo YFtP4oE/3+KMx1tsbQPO70t0pktlsl2+C9bYya9Yl6WnYyxejp0PpL7cj8jSNHhe1h1L3816YXZH 1pmod7P+mP837m+dPJ/1ZPEG9z1Pnc/al7zdHf/Y+axhH/7c/Z8/OZ81ZGKH++PXzmc98M99p6gh 72a9UzxiyphH3s2SMRnf4nL1+0sZm8mkfV8Gy8AGfhRWUkq7N/aOjVoY1Tdqbb8+UUcHREaNjY+M OpkYGfW94VFR60f3jXp2vI6yzgvXtgprnao9eh5P5cBY0BvcBzxgOpBzKmNd6axPAnIeIihl6f3s wqwX73wra9L6tKwZj76bteXkwqxh2/6YZW2/3piN9Tk0zfeMleJT6n78Zjz7E4EcH7xY7ZPtg4F4 l+ubtT2adj8ITwNfAF5wF1gDxP/jvV/uc1DpqMd7zwQv97HqSeyup0eVHsVRYif9XdopsYvJDB3X af/XYvftj7Vm5dcmuT/PcZ1/wdN88BiB+jZlJDjZP7IPiP5+og+yfk0srLhwaI/bX8rBBUDaf1um 41n6/OGRrriEanmuzv7RQvfQLzVnmcZ1vuRyffLXO66z579cFXN6f29i5V35jMkMISbR4Dzxz+zj z+sdR3knSGZ7Kp1Z+nNyPM+EnqforhUw/0IVaCr/JPj6ueuQv4/JtYE+64r4gz2uI9/hHo7rRDrH dfIfvlu99a27P4txnUjTuE4HHueDy2ApkPZZz16yT76vsi0bBC/Wc+90NtI3fIvVR6374c1sLQfO 36Oe9sWp1E33Kdv3b3JefOM68wPjOr++OeM6H/I588GfgTMusk/iIl5McTGN68RKUMGNxqaN6q2A pevedgDk2vEbGf8MHudxTQmM5zwZGM+J3O4fv1l7wl/ee9pfPvIHX9m6oZd//GVBX1+Z+XCcf/yl bIy/TJzkL795t7/8fra/vC3HV7Z+Jd/PP9PnkTra+R9gPphBDJ3nR/bJ+ZF4dHd+ZH+YWPl+7+U7 7fteU3J56Frvzbp8561tcoysy7VcFud3oYJtcj2+0fOdSd3JgKXrfEsXSnW1jvbehBjPQPsBPmA+ 5czrxFj2SQzFQ3cxns6+VCCLMx5yDqvAjcajgLoewNIVD4m9/YzZ+uxqX1wyVz3q74uP/9DP65/y 823P+Eou5/f4dHz/BK8PYksskDYmBtYpjGPCXvY/RIX5lOsonX1T9skx4jUbBC/WNXUWG+12fMbP yp/yd3+iq/XStpsQJ+lf6wNxKr9OnGSfxImi2zhNZ99/+1n5U8ajzJVZX3uT4vGtQDy+c514yL6e xKOMmMji/L5VsO1mXH8muFpf2XeT4rEpEI9HrxOPR3oYjwkSDBZnPKrZthU4rz+mZ+XFi3dlym9+ MKBdz9Ssdjsf4W9HPei+4s11t69+0/2bQruUZ9+b8cz792LsOosVB/n9stYjuQQ+BE8FvwZvg2bi +y6lHLdQv6kvDfXDqsPvXYW1ziE9eiYR/diA5n2UHjAdyDno7tl21P2/dWedWexec+Ad94+I239N /a17Te8Zbmv7X8qzbT3xOktbWin/mTICvDa0pP+fh72pXxv6VVDS34qXxG4w+yUWHN51HljtURwl dpOBxFNiF5MZ+mz74w82uRcXz3T/8F1uc64+/LnNWehLg97A1w8o/0AZCX4a95AG/esTfZB1HRwL a51De9z+Ug4uANL+2zIdz7bJY5JdAp5tn22pcLef/LpxzsId/O8sf/xXO2fhH1ytX3/val7g2TaG mCSAskiCuffq1WxuKmZxwZJ3yATEtYntUNf5RVev+p5tN8k3nL7IXACZsyDPx9az7Wi29wMyZ0G2 96O3Sr+WOQv04Z4+2/ZxPtt6P7xbnf/TZ/Js28f0bBsT6Iv9Kf8vfim6nm1l37uBbdmUwYt1Hzad jfQN3zKWf+X7+qmfbbvpi1PRSvcp2/evcl7kmdHlDTzb/tPNebYdSNvf4LPiKZ1xkX3vsk+8mOIi Pv09x75+WbFJR2MScP629vR72slnXwYsXff28ZCpvANbwrc+2fVNZi7kcT9UyD3NOvi1T3Ku6YGn 3BOP+p9mf/Bjf3ml2V8uO+Mv6/7JV7reCcxaSPTPVnAdG+G/o9k2zl9+73Z/WfJlf7lriq+sePnv fGXmC3P95Uf+J7HMiRt8PPn73/aXv/M/gVT/2f8Ewjfzuk8cg2ij9DFC1+PnjVNyLBXkfD5O6Tyf su9d9kn8ujufpezraWzl+hIB5PsvkD4g22Rdnn9lnwVrvzU2Jlz2yXGyLovze1XNtq3A2XdM92U9 fYcxGd1UIGPnVt9N6/Wg+2tV33bf/tPfu8c98p2u8mbdl0nbr7dYcRBf1nqky74vO8t2xbk8DqKA HJfH/1OpdNg3fbDqENfP5b7sxQG/d9/+NxXuytp33Ou2fMf9lT6/d794ZpPb2v6Xcl92hFjJF6oV yDVf+t+CYVFxHw97IC5v2LNxsh4cu8Hst76D1nY29fi+xOpj3d2XPfve99zvTih1VzKXNPpznEuq aftHNORRygRA33Kdi3MPAAMLE32Q9QFWm2+kH92HZikoANe7Lxs75dK+lvsu8RroctYdx7/jfuhb Jcb7si//Vc8l9f+GVnCvtBmcB0+D+RJ4llZuMu7kS/wnfmiT4fexXX5z+wO5L5PvN6fJB7kfYZUl QeYOXx3KWiaIDyD4nYP03R6+c4hy3pcVfHbvHKJM92VyPyZ9cRClXNOkndY7B9knG6To7vdqOvvo G77F6q/WvcdmtpYD5++H896ju744lbrpPmX73kPOi+++7CbPJZXvpcRFfrOdcZF9EhTxYoqL6b5s MvVTwY3GRry9D1i67svkenntO4b/P5c0iRhLrDbL+QL819W/ZZ9skLh1dx5L2dfDmHb7DiICDbmG SGnddwn/NPdiFRwvXm60v2RSdzJg6eov0vzUmziXdCgfEAFkgrtcX/ivK/ayLy6wrbvYT/f741/7 Psy6ttSxrQrcaDwKqOsBLF3xkJ+DoDmY/2NzSUcSF4nbPcAZN9kncROv3cVt1rXt+Eznkn7aa3Wa K/mmzyXNIh4Sr3uBM16yT+IV7lotPuU7KYvzd+xm9TX7vdL/3FzS+4mNxK4YOGMn+3rS1+x2+O/X 5RpnXeeuF88KNt6Ma9nEmziXVOIjcSq5TpxkX0+uZfjzLc7+VcHWmxGPsps4l3R5IB6l14mH7OtJ PPDnWz6vePD+6abNJV0TiMe668RjbQ/jgb/rxqO7689nMQ6TzidOAsFzGCN/eN794W0n3Akdf+oq T374pnvMLRfcUv4ljcek4f0k8ZW4vw8Oggi2DUradevcEYKrQ7+bdHWo1cdu5Fk6Fb1YIL8P8lzt AdOB3Ht0967swT0X3JWZv3O3DDjvi5nwD3e94ba2/6WMybQSr33gNXA4ELsfJd0/TBGzHyUdBvcP C47dYNotseDQrt9JVj+zMZmHv/G8u/JX/+heX5b3ub4rk+vYFvAQNwo/pYykUV+79XeJYMiCsT7I emJwLKz1T9N+uc4XAOk7t2U63pWx3b9czuoYfcT9i7KfGcdk7uJr+9f7rsx/T+Yck/kkcBOWTSDk ddgfQTLrSXyp5R6uNcf/roxT1LXY6/55oCnske9sXADBYzIi38MxmWjnmMwTv+VvjMFn8Pe90aYx mdU06IdArmlVgP+6nptk308C2yRG/6+6awGMojrXQ9hAEgMEEiCBGFdESIBatFFQA0x2VozKYwsR Qo0lSC6ggkYJ8oo6UtSoWFPeVJCo4YpQBRWtWNS1YuuDekWtvGpJNSJXUKkiilq533fOnMlmyCzj knDxkI//vGbmnO/85/GfeWyk434UXQiR0A3hlI4qu6kSsRXAsewmeTT/b6iLBYjJk4lHWC6C7SL2 ZP7Lule2rXnulVXgYuTlVsDJC9PIy7HW+SynpWL2+KW4ycXxXvZkZPX5f0NuDiJmr0y0uUlFuOEd MT/ulpUCZVjzjQOuFm/5+vE6t7xTpi2Wz4NqCfJ5UG2WfB5UK5DPg2qV8nlQ7Wb5PKhWKp8HNc0U cYfL9J8q5ZjeUh7uJ+U5g6XMGCblxl9JWX2VlHdeI2V4hpDhit8IicG90TtkmGNRt2QAtHm+RxZG 3jk4gO24D3C2I9PYjuTNTb85hnrk1HWPBcOJ0INWkLRVlGQ8/ZSEsmXgPUpfTMSVA7H2JR3H5gJw tr6g6hy7TpF3KZuW+0Kcm5yT+88AJ/dM8zK2oHzCOccW9p1MIFY+2Hf+IU9t80EdK8Vz0xPQV6bh LnO55kfPGYd3gMaJ70vw7fgb8ZUJ86/3SG2tmy9lrnyi1DywQoRN3XpS8Mq1MhxaJ/MFnxJSf/sZ IcOfPS/lwM0y/rtXpbzsf6S8YqeUa2uFDD9QJ+Vnn1jxnwvp1nKx9JlnwcHn4JXt9ksMcM52Yxrb jed26zNlHnlUfYG6H9knGOa46Uzn/WbVX5RE1AnrKzmaP/erqIzHNk6xr5Brcl7YCOcjEOelr7jZ dNU4/0LA2Vei2XTH88xjy3/vNq7bsMdI79MlaD5dL5vLlhuJujXm1JhBXVL+eHSW0QhzXNkEvl8D poDfrZDMd6Trtsx7ekioY6CHpvIjiyf7g+fnfMVzDgaKgRDANnCz4zYuygheEveB8VFBVvB+8LYG 4fWT9hkq/mSx4yaAr83gaxbkNkj21wk98jMX9NyWOaHHdafSr/gid6lIJxfIarcDvJ54JHe5APkk d0m6PC4dYa4/ec6ZK/9jpD79gfGHrr/Bd5pO3DOP3+HirwD8GtB7kNAtbcNpozOBU/92hgD9DbhQ vCCr5/pXIHMZwPr30hvacd9M+HztgQny3vqeGw8bw8buFnZcAfLnAXD2/IZiamdzB0ZZcmoN7bLq 6oD8qt3IN/10nQD6GZdt+dkOI4AyeOhv3u81vXnkwKrdGt/rK8TziZwXugD8zdsQCjcPejEPlb0K 8CN+fiu5Vu+703qvL6ezKCPLSR3SxrDl5D32NYjMRCgD8AOR9lwi4/C8pIfvNSU67bm+/xwQV/1+ k9hziW72XBFK9j3KT51sjbq/A4k/255jGsc5JLnO3SGkUUdApXBKX5XdwnmkEnDOJb10b3pZiGML ADhbLzlGnqX58c+2S/40Rj6h97ObpHTR0Njm2xJcLxEkkKd2jfDENDUfDEHeSEd9oWM9rDKLMZ51 oHPytQlx64FY+arAsWUAnM0X26ahTWIOv0vylL9OyqfekPLMvVJ++bWQ5rIEsX4x3+7UDOuYGShX qsUrnyZ26h/TyCvL78Zr8VF1+3H3rrfj+C2Ak+9oax2vzxFOxnlLAO5fcyygu/k/YwOBHxYFtLf2 B4YuWxz4y8p+Rk36ksAT/z3bGFyxJFAy8EEjd/OSwHcpfzGmHFgSyLlsv/GFtjRQfigx+PJXSwJZ s7OCu99cclJ/C+ES1LMCbTcMkvU2W673TWz9tG/WKRt9f2q3yZed9qLv5fSw7+5Tw75buoV9K3u+ 6FP9AG19QtZOSTeXBh7LXRnoVPqzwPSdiwJdnigNjHlzXkDFnyxrJ34LgWuaC4AQ4APmt/zW90zc Ot+ClhN99Edy19xrpycPvBC44IU7A7O1XSd0D3ws6m0AnaBXHEvjgW/iB/qA+KLTBehvwIXiBVk9 r53KkXkS0Nja6fYVH69dvOJj8Vzie4MfDwx5szwQ7VsIZ2vacz/dbyEcOmK+28peM3EMzgI200OJ OS0BbVGN8dmPcBXiEdRK0q01U02cWEsgWa6Z6uiTa6Zc+LoDpwI8Z+SaifOixzVTknPNVBTIi9uS 3yTfuExyWzNR90qAIDAeGAGwZuq5xBL4QwDj3OYspp8N0CkdVeulSsRVAM75qJfecL3kposFODYP gLPnf7YL1x5avrUH/lTz7IFPxHXIyzWAkxemhQCWJRovLCd1gM7JzWbEPQvEys1cHDsDgLO5SUCA z9BNxF73VOzgccdOO9Pa7Z5r7XZvXiFXRefJr1lqvtfl6qhnrZRfya9ahn/vi7pK6oBrJQPUjXTL D9HAPlJ1Zp5CgLowBSCvywAnr0wLAayHG6/FSHPWkfMyzByxtvJBxgOUjKNT5VB6aSKuHIiVex3H 5gJwNvesI75LkNo2KmuxrdkLce7fA0FgBeDkjWkhgGVw443p2QCdk4/tiNsCxMrHUhw7D4Cz+UhC 4HItX+Mu8o248zIBOjkZGhme11muwjv3EVJ/SBcy/MLFUn59uZRlY6V8dIqU3aZLmXirkCUzot81 iUU/K1HmBwDyvA1w8sy0EMC6ufFcgrTG6s1jCI4HmF6Efirps8IQR7UNy1QBxNo2BTg2D4Cz2yYO gT5omZJX7xJcVo+6V0gsLRq9AxULl0W4xnaAXO4CnFwyLQSwLG5cMp3ldBtDvd5HdJtfDuL8ewE4 m5tUBKbiDsh48c7dOPFd7akI3Qjd5feB/Yi5WpsFf21dldTIKYuF1O+Wd0D0nQ/L+ENrJKu3Py7l 3zcIWXvlc0L698s7INq0l2X6K68Jad72ppRb35Xy9F0yfeAHQupbPhLSf/k+IasL5J2Q6qXNsT8f Bh+7AbZjfouj25FpIYC8ubVjOdK8cSrHbvYLNZ6z7ennmE4/JcM+S0bmY5qKh/eE9qXqvd+J1qi9 6YiQTd2XDHDPNhjcSBswLYS04+lLeThHXyDWceZ7XP8AAGf3pTQE+A1X3le8XuM7EupuoupDfvE+ K9cqVXNa6PyK9lsp8UJWJbWW4aVJUobbCJkyvL2QfTulCllW3lHI9W93lvLbLlLO8Uu55gwh/df3 ELJ2UraUVb2lfPYsITWzr5DhmecIaU7NFfJAv34yvQnHxs3g5VJwzfbkc3QjICHsdTfTQgiTv2h9 yiu3ap5x9isfzk+wD3FuoozsQwyzz6l8TKM7E0gG1HqqEv4KIFbdKcCxeQCcrTvUZY79688+X/D/ 1jcXNHk7FOEa5D8I+TSksx2YFkIay+LWDkyPNkel4RwJQKzcvIvzvwrA2dykIMA+wzmJd+f9ol9x vV/fnw68mCf4Kpk7SEj/Lfky/A9DSt/FUva5VMoNw4U0Z/9SyPCOkVK2GC3jvyuS8oxiIas/uVLI krqxQvr/OU7IqodKhWzK8e8PqO/GFrKdWqExnO3EtBDypABu7TQZacfijPqtdJ26T6g1G+MZVtJL v1iO/FVArG1fjGNDAJzd9rz+WeJfjhZaPkFwXTZ+kuS+1zVCrv/3tU3eBqW4LvdIgpDcy3a2AdNC SGP53NqgEGmq7ORPAd6jxpRqxC0EnNwl6FqcjvhcgHvREE3y20mPzOodeGd3ivHBtGHGRR/Wy+a6 b09dasypsZXcKD/00r5vn4P4+4C3gAUA8z0e1zZxb3I7AXUMxnpT+ZHF055hNjImW+ccDKn0j23g dt9+0fChxqpLko11c0YZZeBtPMLbKzoaKv5k2Xv+G+ozD9gGLAaop39PfiXh6jbtEv+eXAS8kqD4 InepSCcXGFrsdoDXE4/kjvpJPsldki6PS0eY9894zi0vzg+E8Z2ihefuOqG/r3QJrm0CfwQeBKBb 2mJfuwQgqewUAfobcKF4QVbP9S9H5kkA699Lb7jf9/Dz+9aufH6f2Hsu7TInMHnywUC0vedfaNqY /nLXymUV5m1fJRvlUW3K8asMDcG2aN779Q/9YN5wbhzv15fjfj37fSawH0pG57P2nktQED/CtciA oVSrxs1Z8a2i7oNFGVlO6o5WxzPIvedkRLI+B/CO/daCOTh//beKqN8e955Pce49N+E78adE23se jTLeBlwBcExjHdXeM9PuteKGQEY68kAXQiR0Qzilo22go+x/lUAF4Jw/vOpiAY7NA+DsuZftIvae B9wg90q33RFVKzsgP9uH9Uq3/BBR90iLkH4lQF5KACcvTCMvLEs0XqLtPdfh2O1ArNzU4NilAJzN zSkIyHd6h2Idyieu+ew1pZmySLLU4wUp98idZu00udOs70wRFrM+61Qpx50pZYtzpLxA7hDqO+V3 dvWXCkU8GnqQKIP4L9IfC+9VOEspQN7XAk7emUbeWU833pmncQ7kOjIB6S0B6gR7sc+SHApUGF57 vmlj6bKJuHIg1vbScWwuAGe3F3UyG0usxQOa5/eNLsX5fwcMBVYCvJ7q20xbYcW5cRlCOsonnLNv r0bsciBWPibh2GJx5no+OA9GvJNe/IHkZYwhfsfInDxXylXzpVyyqpl+32gYykHergOcvDGNvLGs brwVIS2iHsJ+SUAc9Y76RufksxJxFUCsfBbg2DwAztYvjk+0i7XH3pRM7flHVMZi6bOs6w0A+WL/ cPLFNPJ1rLEymv2+HcdvAWLlZimOnQfA2dwkISDvEYRgudffG9FO2yc40rskyV9iWZUlpPnSmULq C86VMnmQlBcNlfKFUVKu+rWU8yYI6TZCxsJ1Jco8AyDXTwBOrplGrlm3IUCkk7P1kSMliGys3jyG oI5yLKSeKkm/m96aSGO7x9o2Oo7NBeDstmmBQI6m95kalUFv603Vz3jOQgtPQpLDpwEnh08hzsu4 SBuQTp2/DRqaa55qYCHg5CNB1+J0xLOuTWkzv7FttNHmlseNKSt3GQcnrLPlyWYzv4d6X4FG4D5R CUA9u6XNWx3Lu34qoHiEzpnKjyyebJ1sZEwGeE62QTEQAtgGbjZz6/a7jMPpjxlvrNptFF2/zihr vcu468knDBV/stjM/I7cr4AwUAr4UK/xXWs6ftX1s47juvbrRL/ii9ylIp1cIKutm/B64pHcUT/J J7lL0o+2mdNS7jHWLVhjhLa8E0gZP++Efd+3Eyp0OXAbMBGIRxmvaj+y41XtJ3dqkU7QP7IBF4oX ZPVc/3JknmTVv5fe0GY2Bu5fu8rY35vvQgbr7jA+GfCIeNYd2Rodw/rj1iae17ogZyAKMAiZLBfp 9zIPZOM41aYj4C9D/fHXzDZzshYe+b/293074nqcH2bE4b8PYQPDFaMRMgE//NsRzyTtL9b3fUsZ kOXk3CM1V76z/C7iMwGu4xOAyOe1EhH2aDMnN6PNnBzNZu4M8kcBXQH2SfzZ62qmXWXFDUF8pFNz cAiR0A3hlI6q+aMSsRWAc/7opXvTxQIcmwfA2fMp20XYzEV4Xova+Dqe14qilR2QPxlgvdItP8Qx bWZ++4q8+AEnL0wjLyxLNF6i2czNxQ3X6loentECJ+ZT+HZvM3DTHXUnN7mAkxumeeGG5WQfpHPq zWrELQdi0ZsEPa5VNo7NBMTa5LcfDoDXdmyze64YOTza/mCG35y6Jipz3tZrLIfSvRHwl4Eb/LmN dXfw99dZNmQ5DufTsmq+Ft+3JL+bpupx8X3mnU/JcBfgm5v0OIb98G/BXt+ey+ecD6+I/xZpzJc3 Ji+OZZ1broOyjloYcinSWJ/+kK8CfabX7w8y3uNY18Y51s3AtXi9Jvg+Q5toY915qNBooD8wHsCf PdYxzctYl+HHQXBOnfX6DnVj8y51Nohz9gca09l2iC/E7yQPRZ8Zqfnx7sBF2mjIEdpwxOWLdwnO 0+PMGuRbCsDZ4yXnpanI60fOhvto2ugP5Sgx67CQ4R0tB3G00A8lCanld5fyX32lfLW/lJMukvLB kVLml0iZPUnKn+D6IFUrG9dC4/f/54pv9MsZPrMF+gTWB1xLLkQvOAD44Wc8vNqBv1rrg3/HC11C lJQz6ZN76txjYX/iej4eiFwfYJ702mfaOvtM2qV5cesvaZI+09atz1ShfAbqyrHeBJxjPdPYZ461 h+mif4IP8kJw/GgF+CxJe12F4T2qv1UjbiHgnCMSdC1OR3wu0JS26R9XX2V0eWyZMffh3UblhfXy ZLNN/4V6n402eQk4FyC3vduel/pV12wBNW6dKNu05PXxxjNjlxij40YZK55aZux4Z7wx7PD9hoo/ WWzT98DTWeCrDpLzA/VwQNv9Hca16Zc6sK2ZSn8kd6lIV3O7ikeUZ9uM+sn1gZttmnFwrvG7tHuN 92ZrRlXfwQHm5fU47nS3gMtFrG3q/czTE0gH6KcTZgukKivjlT8BJxqFcF8gEXXvAtwDDAHiEbcy 5eH2K1M2pT2STtD/cHt1bCx6NBjnLAcmAax/L72hPaBlJtYIwDYtetU0trxwV1TbtB9+Juena5vu PGJ+N8R+l4h8ZwLLQWy4M3hCw1WgHfoAfsRzI5Nt559tvUukt9KQZP/2DN/h5tyj2p1pXJd1Bw58 VL9ew2m8zj3tnHPP5rT8uP5AE6zX2rnNPYUoXxIKT7u0LZAD4M9erzGtpxU3BPGRLtI27WclKH39 sbapmy4W4Lx58tz2WoucC9t0tGWbvtY8tml71Ju8pAFOXphGXliWaLxEs03X49gawDm3eu2nZTi2 FICzueFcfrFYgfrF/STtQmmjaspG/bJaWlwvrZfyW9zdpQ3bDm9dN7ENW4aypIMjcjgIcHLINHLI MrtxWOSoD9d4zO8DOOcyTOfUu9WIWw7Ewm3T2LbhifEnfp3e5LYtx69I25bhLkDy9MZtW8a3BZiv Mdu2BvYs1+N5kNsBfXr9WPkj1ukpzrGyCW3blGhjpQ59pV0SAGiL4s8eK5nmZazM8OMgOKfO8nw8 d6w6G8Q5+wMnzrY1d5wudFzfh7fCMHqEW+fKcPcLpe5fj2c+OKq0GyflIct2XTxNhM2P8atTHH36 Vcr03vOk/MnbttyT5hjF9lS2bRomizLAb8Vz7jhe25Z7Fh73g9o7+0wT2rbt3fpMFco3FBxwDrgb cM4BTGOf+f+wbU2UrRyIpb9xH0jHsbkAnD3/oiq0N744a6B55++P8x6OGh94zkILnRDgGjUDuADA nz3+MK2/Fec2n4aQH+UTTp1frdVWIzbWOZN8TMLxxfLUNh/xCEc81/JeoeDFNBdIqT8j5czNUl67 TUgYSoPkifh/pL8DwskA651u+SGi3meYjHTqH3m7EHDyxjTyxrIO4ckinFrjFiEuoh5i3ZGAOK5B 2M/pnHxWIq4CiFW/CnBsHgBn88kxo4/m16B8g4SGXdlaygYs1TMWC1+s60DwQb7yASdfTCNfLIsb XyGrnOSHzslNHeK2A7FyU4NjlwJwNjccQxp7TgVszWwrWNJ9Z0i27usnpLl2oIy/eZiUh0ZL+XM8 iYP+q6++Xsr7pkt5061C+k+5Q8iGulnPurf7FooTUCn6dxVkEAHyfivg5J1p5P1YY2XjHMi1MtfL bBOuz6i3StJPcG1Np8qmxoZcXDcbiLW9DuKce8WZ69srFWGP75cejh9ovoFfwNTPkbL7tVK+/Vsp g2ulvHmjlM+/LaRZu1fKjK+lfKDVIJ7HHJgq5R8zpRydI+XXeFKL6X2DQmpDLxMy/OtRUl6EJ7WQ Hv7oGpnu0utia/8w+KBdmQdMBS4F8GeP70wrAMibW78rR5pHTsV4x/Znm1NSL+iPt/yUytaijMzH tGj6shzpVUCs+lKMY0MAnN2/eT31HlL4dvRItIT+0C1CluyeI2T1FPRMxLv1zFjGw1Jc9ybwzna5 DXC2C9PYLiyfW7sURpSdPCvAe1Rfq0bcQsDJXYKuxemIzwWacs89Y+QeI7Hjt8aakVnBoR3q5cm2 5/4GOP4SmI2J5xAkOXwj0zhtUU8JNWZBl03lRxZPe8XZyJgM8JyDAaV/bAO358HO37PH6Pfq18ae I7uNPPA3FuGt4743VPzJsuceBlefA28ChwHq6fuZh7M0cPd+5r3A4SzFF7lLRTq5QFZbN+H1xCO5 o36ST3KXpMvj0hHmWorn7J2w13gn9ZAxq3f6Cf1+11u4+H7gaujPfyA5hrU49eUs4LS5PQTob8CF 4gVZPde/ApnLANa/l+7Yc5+z5iHt+6RufB5sw/sfGm1f+ELsuRcgfx4AZ493KCa+0XR2/Re81LeT XGadDsiv2o1800/XCaCfcdmWH9UX74KWwUN/875L1fA7Xgm43unAXHrg+B2vAlS2FgXxIxxCPOte ku79O148jueMvO9LPfdoG3dw2salTff7oh3cbOMilG8r6kyd3AV8C+DPnu+Z9g1ALoYAkU7ZJSFE Ukc4f9MpfVXrtoWIqwScc0kv3ZteFuLYAgDO1kuOkdzX9uNy1leqloyR7wglNte3T/8JHshTHeDk iWnkieVy44n1sMos8jEvnZOvEM7DdXasfKXgWB8AZ/PF/mfgLtw4vB0yEXvz/mN8XcMccJdk8+fW l1EftL6M+q86EW8+qok3qcwP5FerzDld5ZtVK7tJub2vlC/iSRJ8m0P7Rv6yhbYUT5IwvBW7cZDm p9iNo5xwo5S7ZwsZHjRXyuH3SblykZDV2fcL6c9cKeXkVUJiaGzUWvcyHin+SRnb6C1gLwJs60lQ fGdbM41tTU7d2noG0n4M39yrY/9pZUnlp47Q77OkSmc84wjG0aaijAdUHLxH6dZqxC0HnLrVFOu6 PJy3L8B1IctA93r7WmP1/b7gzuu/sGVbrUPw42WYdyBPpvVdH5T3RbRre7T5x5CXQrIeLTN7nj4s izC7l2ea3ZW+oF1M5Uc2T3NzNjIm85zAYKAYCAFsD7c1Xpef1RnTeqQGb1uwW3DG8OodKUEVf7Ks 8cidAc5egxxqcXdH5uvdv+xqdr8jsx/wegPuUlFvcoHstp7C64lHcpcLkE9yl6QfvcY798w/G9Om JAY/ydFP6BpvLip0Jup/EXAewD55UXpxN+CMgu4C9HdTuhOLHrH+FUAZz93YGg/x0h0IXP7t88b8 P7cOcn+0AJF5MsGeG1BEzN7n4GMx1ldaC3BPm2P0cYypSs/ZtiOAMnjob9413qM/aOYVLfm+fCme jcjA9TgmluDCOjwXwJ8C2R/ww78a8ay7P81a42kmQtKxrJrJWshn/7UNUtc4FrM9I9d47Mse13ip zjXepqvy4/oCTfB8RWq0Nd7tqFAPVLYKMheS9VPv1DLtHMSRiyFApGu4xjvHdY1XiYOoj855pZfu WOPZJ/eml1wvaX2sFd4D1grvOPRS9TnWvxAoAuYjQG4WQTq5YZoXblhO6gGduoZa/+biHNlArNwc xDn3ijPXr+c4djb8lr3rb5alyPWweRhPXXClde3zUr6/Q8q1/ytkeFoLsZIKP95OykXya5v6k1ki rI/oLeU950vZW67o9FLcX8V59cuKpdwnV3T622UyvHGGkP6ZvxGyetHdQrqNLrHvWy4Dx2zHOMDZ jkxjO5I3Nx0v987pSfebZZFjvI565AJw9hiP6mOurD3jt83APftRC3BL7n2NcM80cs8yuHEfEuXD f3DO/lOHuO1ArP2nBscuBeBsPnj/Qn6hk19CuwFf7bxafBOtVCupnS84Kum7TEh94wNCmhc/JLnz PSJl4WMyvmyDDN/7Jxk2X5ThAZut+NeldBm1YtP3KpS/FTgl5zrg1HemkfNj3adpnIN6W4Jjmo/X Ajj3EQyrOHiPai8TceVArO2l49hcAM5uL+pOjmY+urUZuCzEuckhueT61cllPuK86G8OSwzn1N9q xC0EnHxEs7mO53fE9M61xjXnZwY7X9kl+GnLetlcttZI1K0xp3igDil/PIb90QhnA5vQqJPB7XXA NID5Wma267m0RwsBdQx0zlR+ZPFkH/D8yTwfMBgoBkIA28DNznr0tYxg4NdZwdqZWcHnfugafPbl jGDq2oygij9Z7KyJ4GoCwN8RI3yo19QeS3uu7Kn1vKHHtT3oV3yRu1Skkwv2IRUPryceyR37Ivkk d0n60XbWiD8fMjIyuwSr/JtO6O+IfYoKcX9mCDATiEcZd2Td2QPo+Vx3Afp7qDrHokesfwVQBrD+ vXTHejZ7Xo22PweXOBAoXfyF0e+G9GPYWb/AxpJlZ/3qp2pnNfwuGXgVv2HRJwEeOH6XjHvp1Wgf P8J+ZEDwuL9Lxvb1aGelOe2sGWvy4/Y+2iR2Vlo0O+szSyd5j+smVBrCtrOYVo44cjEEiHQN7axf uNpZnEcqAedc4lUvC3FsgbywPbdyjKT94scjN5altd6ytLo11176d+CCfZdrQydPTCNPLJcbT6yH VWY5byBMp/q6sr3qELcdiJWvGhy7FICz+eKaahhWjdPBWEMbTLv0LmlTjX1SypXWrvnTB0VYm27Z WNeniXVMeHU3KfneJWyoMN+7pOR7l5R87xISg3Wju9uxrx194Jf8c5/OyX884sj/sdaOLhzYe9Hc k2Ybqr1tjhM+QK0l4T2qvTIRlwI424t6UApANQRqUL7FgDOco61BDuXcWFPpDWU3BJMB9kWO+5Fl idNlGqK1tkAaPXApAP3/B7rqGMFolQEA --Boundary_(ID_LrroFSWRXtXISoZEEmpZOA) Content-id: Content-type: image/png; name=image004.png Content-transfer-encoding: base64 Content-disposition: inline; filename=image004.png; size=21111; creation-date="Fri, 28 Oct 2011 09:25:11 GMT"; modification-date="Fri, 28 Oct 2011 09:25:11 GMT" Content-description: image004.png iVBORw0KGgoAAAANSUhEUgAAAh4AAAISCAYAAACDAcYxAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAFH3SURBVHja 7Z1PaGVZft8LDKYwGISxobzTRqQbhiAwhFpoIchiKqsukcXUpolAmyIbF40WAzFYYxAe48UYWmSW NYkWs8hiRriZ9myiOIOnFxE0WQyNFpkibls1iUMKI2YKB4eb91W9b+VXp8/99959790/nwMf9HTf /XPueefd3+edc+499771rW/dAwAAAFgHFAIAAACsXzxm6b0Z+3DvARUjU1Fm9ePXfu3X/s/sbzF1 fuu3fus/UCfGXde5Dt6xTX1YHl0vuG7eK+bx47234qFge//+/de/93u/92rKfO1rX/v7ra2t/8aX JXsx3lcZFRNPl5eXxW//9m9/Tp0YL7pATv1aKH7913/9l9SH5dH1QteNqSfVKcWRKB7bv/M7v3M7 9YJ58eJF8Zu/+Zt/x5cF8UA8Jl3XJx8klFQO1AfEA/FAPBAPxAMQD8QD8UA8EA/EA/EAxAPxAMQD 8UA8EA/EAxAPxAPxQDwQD8QD8QDEA/FAPBAPxAPxQDwQD+o64oF4IB6IB+KBeCAegHggHogH4oF4 IB6IByAeiAcgHogH4oF4IB6AeCAeiAfigXggHogHIB6IB+KBePRLPG5vN5cNxGN94nF8fFycnp6+ 5ezsrLi+vi6Ojo6Kg4ODu/f1WsuV9J7W07JYV/S+lufqzdXV1d2+9BfxAMQD8RizeFxcXBR7e3vF +fn5O8t0zdT1U8v1vpYJXWN9fR2NeDiIOKjoJBUA9AEoGOi9GFictH4amBxsXHAOSio8xGN44qHP MMqABcKfv+uAkpZrfaednZ27zz/KRZVYpMdCPGCd4qG67GuZ6rKDQJlg67ug65zeizIdA0hO4vW9 0DaIx7RbPFQPcnWw7P11tsSsXDxubm7eCRY+QQeAGAxSQ9NrFVQMFvEL5YLTl1KvdSzEYzjiYXnM iWpOPPyZu47oIhvrDOIBfRWP3C9KS3OdYOt1+j1Jvxf+3rh+py2CiAfiUSUeOYkdtHi4pSNNNvhU PLyuPhyJhL+EXj8Gjlhwet1lUEE8Vi8eObGoez/WEUupPntfdBEP6Jt46DqWCwJtBNutwlXiEZPq OeKBeNSJR9qTMBrxqLvY+xerPgy9dqtFLCAVigop/cXgVo70FwLiMRzxiF0li4iHkltOYktaHC+C eMAmxUN1rur6VFfP/R2JrXt14uFrKuKBeFSJh1PXQxV6IR5VBe0vUxoQYpeLC0brpl0tdb9yEY/h dbW4davsl2D8pejkbhfEA8YqHqr3vub5PQ+oTrevExPEY/ziEX/I14nHutNaulqqftXmgoG7Wfw6 BqS0e2VVCfFYvXgoSSSjHESRTC+oqkexLuUu1nS1wFC6WqrEIwp2rPP6AeYm8jLxSH+0IR7TFI90 XFHaCpbWyVHd1SJZSFs99OXJjfHIBZQmg0sRj+GKhyu8xwL5s/Yts7HlItq76pCWx0FRqlNlA4xV /7R+l02KiAfi0TTlbv92XawT7PSHm++MKQs27nLsMpAgHsMTD19bXZ/SGByvr2JUd7X4S+YvXgwg DgYysXi7WDR2raP//WXzti64VfVNIR7rE4+hJsQD8WiT/LwE4etWnWD7GpkGhVyQyO0L8Zi2ePQ1 8eRSxAPxQDxgDeIx5IR4IB6IB+KBeCAegHggHogH4oF4IB6IByAeiAcgHogH4oF4IB6AeCAeiAfi gXggHogHIB6IB+KBeCAeiAfigXgA4oF4IB6IB+KBeCAegHggHogH4oF4IB6IByAeiAcgHogH4oF4 IB6AeCAeiAfigXggHogHIB6IB+KBeCAeiAfigXgA4oF4IB6IB+LRQ/H43d/93dd/+Id/WGyS3//9 39/o8Q8PDxEPxAPxgFbioevGlK+bQvHjK+LxG7/xG/+w6Yx94xvf2Ojxnz17hniUX4y3ZpxsmO/N eNGDfDymToxbPKZ+LRSIR2f16XEPrlkv5tfPTedj6614zAvncMMZ+rMZr3pQMPt8Wfrb6jLjkrKA FdezTV8LRYFgQ4d1+rJPsa1PBbMtK6OSAOIB1HVaGwDxQDwA8QBAPADxQDwA8QBAPAAQD8QDEA8A xAMQD8QDEA8AxAMQD8QD8YAmdWSLkfaAeAC0rk+PfSsr4vHVwtmlkgAAgYJrIYy4flMIAAAAgHgA AAAA4gGw0Qp779425QAA0Oq6uYt45Avm/oxHVBKoqCMMLoWp1HXqOXRZnx4pxiIeA7AyAACuhQAj Fg8AAABAPAAAAAAQD5hghWVwKQDAoK+bfSoYBpdCXR3hkekwlbr+mHKADuvTiz7JB0EFEA+Anv06 ZfoIQDwIKm8pimJrxj6sn48//vjZBx988DllAWPmxz/+8ZOvf/3rLymLd3iAQCAeUxYPfQlIJBKJ tL50iEAgHhsXj03NtFcE8bi4uKj8ptze3hZXV1dvubm5Wegbd3p6uvC2uXR5eXm3P+fLycvSY11f X6/saqJ9qxzPzs6K4+Pjt+Xm16tO6zzWOpM+47r6uUyZqU7WLVskKc9d7GfVZaTvifPZ1bkPOcXy 6KruaT8hIR6Ix2bEYz617/MZr7T+psTDwWpvb6/2y6P1hL6YR0dHCwW5JoLTNJ2fn78VC+Vf/8d0 cHDwlW2U7+Qi0FnSvl1OMS87Oztru2iu81jrShK6VQpjrk42+T40qQuqB6vMexdlpO9zPN+q72jb Y7T5Pq86Nc1LLI+6cm1aHtpnuCYgHojH+sQjkY0isDHxyF14ypJ+BfiXgLbpOshp37HVoipJOKL4 KP/ptqkYaRvJSE5Ilk1VZYh4DC8tW0eG9Dk0/f5L2Nu2hqziu7bqz3RV5aHr0fyHEuKBeKxOPOa3 1T6Z8f2MbAxaPPTXv+qU1L2gL6K+3P4VoPe1by3Tay2PgqB9xG10sdaXU79M9OtAv7zceqDXel/b aH0tjy0XTcRDedS+tZ9cd4+P4RYg/XWedVwHk9jq42NqmfPn/eSCUCynsqRj6pyF9qdtvH78DLxO bGFxHpS39KKo/Wq5t/E+lB+fU0zpe9pe+9Ty+HnGsknPL55L3MatZ7lysIDqPX1e8Vz8Wn9dZ3N1 LxdMlEe/78/W9cnr+PyqPjPVnVh30+TtY13wcfSeu+L0ns7PZSj02mVeVoZdl1H8/sfySI9haS9r MUzrrdbzufvcnLfcOXnfPr7yrG381/t1GaV1Ju7f1wftS59XzEvT8kjLtW155Org/HuHeCwXX58w V0u+YCQc35jxRYVsrJPP5yL0DvO7KlqJh76IDvzxgqNlvmg5IMeLpL7oURDi+w54UR58MY7dQDEY pKLRRDx8AdHysl8qOoYuKlFQ4oXOF0uft/OWlmFOPBxwfJFMu4ZiPl1eOkbcd+x/9gVaefX6zn/u F54CnYOd8xQvnGlTdPpe3J/zEMsmd36uF5YTl6eb83P1Tsu0ngNClC3n0Z93ru6VpdjN5vKKZRvP Lwbs9Jy0H4trHM+T1qPca//q1fn7GFH60u+A85Urw67KKK1ffl11jCb1Np57+v3InZPLMZZBlEJv n2tpSPcfuz29rvPSpjziObctj7KWlE8++eTb8x+nsBi7vRKhntrZwxnfnfFyUy0e+qByH6Bu6Vyk xSNdPwZDJ3dr+MvvC368qLiVwAE4d8Epu5i3FQ8d3y0n+tukW8T7TPMVf+GUXVhzgadNV5KOEyUt FY8oPWX5L2tN8K+/mO/cuul7ue6DtAUrPb/cfus+Z7cY+PNLL/AKFFEcml78HXDioGOfo4N5mu/c OcVyKPvulImH8qC8xzoYj5Erm1WXUZl41B2jrt7WiUealF8LWZV45M4nN07FLXupeLQpj7SFsW15 5Pb70UcffZH7IQiNeY54tO+CyUnIoLta0iCYtg7EpkxfVHzh119fENILltfx/tKgGgNC7iIQxSP9 VVrWRJoL3DFf6S/c3IWxLPCk25Z1Czhf8SLsfcc7JWLrhlsQqsQjBjiv5+1yrUDpe7F1Ixcoc+en PHg/+t9dC1XiEd9zkHDetC/XO+2rrO6VJXfz5IJMrrWo7Jx8HP11gG8iHrn60kQ80jLssozKxKPq GE3qbZ14xHMK3RCdiEeuazK2eDQtj3RcW5vyqBAaulrG1PUzsH6qR324q8WC4D7N3BfTFzBdzERs ytUXz+/517GbI/2/1/M2Op4vNPGCY5lx/68uFL5AeQxIDHK5u1jiuAQH9jimIYpIPOcYJLS9W0gc KGNwcZ7c8hDLUP9bptLXPv/YipDu2+Xg84jl5q4n9zH7mA6E8Vixnzr+onT5az2PHfG5phfg9D3v 03nOlU16fv7cYsB3HlIJSaXS63s8SOz2il11ad1Lx2ikLQWx3jhIxru7LFmxOyg9pzSPMfmclc+0 3rpp310MHmcQyzMtm1wZLltGqWC6DOLr9Bjap8vFXa519dbdsrlrTDwn/+866lZSbxO31zpp90i6 /zjWyeccu4iblofLNVfmsTxinvyjKSc48+8K4rFc7HwP8cgXzFYbmejDczzStMhtcPELrC+oA5mb l3NpmVsNc/35sQ92keRfvXXPGlnmGHHfvtjXrddkX13kp8l7dcdcZJtlyzcXPJYpi7T+5/K/jttk q/KwbBkt+zmUjVFqc5wun+nTZb1fpl7GuhNfB0lFPJaLr4cMLi0fXNorK2srHsum+MyPsuboZZP2 3fWDpdZ9G+SqHow15aTgsKpntZDeJLfmkJql5AcR4kFXy3QpVvzIdA+MHMoFKvadk0gkUlcpaUFD PBCPSYvH9owTAABYG7vEH8QDYFPdccxSCQDQ7tq5jXjkC2ZrU3eqwGC+PId9ux8dYEWC/YiygA7r VIF4EFSAOgJQVs9bzdQNgHgQVIA6AoB4AOKBeADiAYB4AOKBeBBUgDoCgHgA4kFQAcQDAPEAxAPx AMSDsgDEAwDxIKjAGurINrdcA+IB0D6+Ih75ghnEXC0wbIqi2OIpkJPj2QADxS7fVxitCFEIMDHx 2GYWjMmlF9R9AMQDYGPioQn49vb27mbVLZumPKbT09O7WYP1VzMGHx0dbSyCKr/Ku/KjfKxiBuO2 +dFkXs5PmjST8MHBQeuZb3Vey5ybPuMwizHiAYB4ACxQWd88Vn97WfFwQFPAlHxo+u2ypICaBkAt a5skLV1tozzH103kqasU86TXnkFUMxQrL6lgSDokSptIystcPhAPmPq1s1fDGPpUMNv0a0KDOrK/ rHjE6bYVFMvEQ8tjkI+/puMvegV+70PBTmiZhUWvoyAoSGs7/yJvsk2ZeCj/cR3nJ5dHt05IGHQ8 v3Z56By0bhQtb+v8OU9aV1LhpHOSkMVl2kb7iuJhGXCe9b/y4Pw67y6TmI+yFhAt1z6Up7gvi8/Q xIN5q2AFdeop4rGiX7MATcQjBq2qbhMF06pf69rWQdsC4+DrwKwgGPcTfoXfLdP7ddvkxEPvK8jG /Dv4uiUnbZXw/rTMLRc6tvYVWzPcyiP0nrb3a+/DwT6Wld+3hHnf3sbl4+39Om5juXDXVmxhcrdN 7nNyy1Uqatr3z372s78ZWJBgoD2MW4QoBJiqeMSWikXEIwZBB+sY1PU3BmQvc1B1y0PdNjnxkJyk 3URa3/uycMQ8+nXZ8fS+31PZKNDHFpX0PHLiYRmyBMRtouTElhut531ZyuL+c+cVy8/CkpMSbfvT n/70b6n7AIgHwEbFw4GyKpV1teTec7BuIh5h0GOlCFSJR64FQK9jN5LyGPdRJx5x7Ir2IxTYtV3a elEmHs6f9xW3SQfDxrzpdXwvFY+YcuKhss8NYkU8ABAPgMUra0eDSx1k9Td2feTGEKTdGQp6Xj8G Oq+TC+q+i0YioPU9CFPH87iEqm2qxnjouHFb5cktDzGgRwlRkNb5u0XE5+PxGx5/ou0sMu4CiucR xUP/WzxintJuJstPzKO3ieITyySKT+4z8piZVLR8/l9++eVf8/2BiV87dxGPfMEwuBTq6siJWFY8 YpeIm+79KzqXFNQU+ERZa0UcHBmFwt0UWuZt9VeB1v832SbmJW01if/7dl/nR38tF7F1ROtYMixP Wje2SsRuoDgGI4qXZczLXZZe7lYgH8NlmY7F0LGjZLlMvC+Xf9ngUm3vzzDum8GlADwyvapgah+Z PkuPtM6MV1QmxGNR8SgmmnJjIJZJUVr6mJS/uYANTTx4ZDogHpsUj/mX8LszXqrwDJUJ8UA8mid3 q8RbTbtIvi23bylpQUE8APFAPKrFY5Ye5mQD8VjqQjYGvjdn4X18+OGHT6ba4jHV9Ktf/erlwOr5 sxmfj+h7u8V1GPHos3j8ZMaLMtmAhbkcCS/mLLyP999//zNC8bTSzc3N64HVc0nHqxF9b19xDd48 iEdFi8d8kKmM/7OhFCLQ1ULqdaKrBWjxQDyqu1rCsgd61OvcmhEPvjyIBwnxAEA8ViceVRJCZZrk l2e3i+d4EIcRD8QDJnbtfIx45Aum8cOhJCFUJkA8SCMVD+ZqgXGLEIUAiAcJ8QAAxAMA8SAhHgCI B8DGKuubO562EQ8S4gHQ6tq5i3iUB5VeFQ707svzEPEgjV085gPp9/nOQ0f1SWOGDhGPfOEsPfMo AOJBGoF4bPEjDEYtQxQCIB4kxAMAEA8AxIOEeAAgHgAbq6xvxgFtIR4kxAOg1bVzF/EoKZhVj/GY XYCezTiBlfB4DXXked8GSQGsSLB7FShg8PWpV/Ldp8JZeh6OBuLxgh9/K0vPEQ+ATup55fQRAIjH SMXj/Py8ODg4uKMs3d7eFmdnZ8Xe3l5xeXn5zrLj4+O716enp3f7uLi4uOPo6Ki4vr7OHitNNzc3 d/vW+8skHU/7QTwAEA9APBCPHoqHhMFyIFG4uroqXVfvpUFdy7xN7n0JRZp2dnbuJCUm/a/ldYLU JFUJlM616hwRDwDEAxAPxGPFLR4x+FeltuKRtnY4qYUklYxUPLQvt5x4GwmFW1skIWptScVExDzE 9SRZes8tNMqf9p/uB/EAQDwA8UA8ViweCvx1XRRNxMOtGabsWGpdcQuGAr9EwOIhubBw6HgShLg/ CYjFRPuxmKh1Je4nt5725/x6PW3bsosH8QBAPADxQDyWbfFQcHaA7qLFw60TOfHQe17XQmER0P+S AcuG1o3iIcHQsaIsxe4Vv86tF8XDLR5av661B/EAQDwA8UA8OhaPuvERHgDaZoyHWiDKunR0LImO x4FE8XCLR9zG20lKfFwdL82XzyFdLxUPredBsT0Uj/1ln+MBgHjAxOqT5mp5hHiUW9lKg0ob8fBY DHU3uJVCgT83RiMGbgf3shYRBfVUIKJ4pHe4xK4WvdZfdcNILHz3jO9a0bE8nsPL3F2i1x7Pka7n u24sK1pP8uNxH30RD4CJBArmrYJx1/EpnWzR4q4WtzBEodCyssGhsSvErRXajwJ8HN8h0mDuwZze t/9qeWzp8LiMKC7Ok9fVsWP3i9b3ccvW83gRjy1xXloOMO1EPHhwEgAA4jE58SAtlLoSD43jeMFY DgAAxAPxIK1LPIo57wjILL2n/kq+uAAAra6ru4hHvmD++Ywn8wGEK+FXv/rVS/xgNennP//5px19 Tp8G8XhHQBhcClMJEnQ5Qof1icGlFYXzb2b8ZMblqri5uXmNIqwm/fCHP3zZ0ef0MiMelo99LiQw gUDB4FIYdx2f0skWdLWsMq2iq6VgvAcAAOIxePHQnSa6a8OPHI93k/iJnXrtW0p1J4iWpQ8S8zqe +M23qGobU/bAMCftO50IrmwyuXibbpp0HD8DRLR95LmO6X24TOLtt7mUHKNr8UA4AAAQj+GLR7yd NfeQrPh/+n4uAKfrxLlVHLhzz+2IKTcRXJoviUndhHFREtrOalv2aPgq8UhkqCvxOCkTDgaXAgC0 vqZqjMd7iEe+cHZX3a/55Zdf/nV8OFdb8Sh74miZeFgY6uZ7aSIeCvBxLpcm4uFHq/uhY8q/nt/h FpxUaixl+t/nGvfpbWNLhyehK9bz5NJLxnnABAKFHqb4kLKAjuqTBuVfIh75wln5PBx/+qd/+r+q xCInHp6zxI8abyseniRuGfFQt4cFokpi3Mrh9SQK7k6yTFi80ieqOg9p90p8HR/PbvnQe/N9Ih4A 3dTzlU8fAYgH4rEm8fiDP/iD/91WPPy/Wws2IR5xfhWtW/b0VItH+rRV78sTy8X1va+Yh5x4WDC8 P7eYBIFBPAAQD0A8EI8q8cgNGK0Tk7bi4VaTuvEVqdSk+YwDOstmy82Nx4j5S+eBicdtIh5xcKu7 YhAPAMQDEA/Eo4S/+Iu/eBkDepwUzcE0Btfc4NK0taFKPGKXh6Uh11oRuy4sCL4bJic+OkZuvEmd eHgdb5ubjK5MPLyO8qZxHh4wq/fmIoR4ACAegHggHpFZcHyRtj54grQ0+Ht5Sm7bdAI2k95Kq2Vl t7l6ptl4C673H/fj7pJ0kGlcHkVK+4138viW4ZgPb6v8xwny4mtvm96qq9fz/CEeAIgHIB6IRyoe fl7FJpIHiY4pBRlDPAAQD0A8EI9UPPwLP9dVseq0iWOuMiUS9XxNX6AtLiaAeAA0rk9bffvB1qfC ebDqh0MVPDJ9lek5X3KAzgIFgg3jreMUAgAAACAeAAAAgHgAbKyy3ru3SzkAALS6bjJXS0XhPKZf E2rqyCMmiYMJ1POHfQsUMOj6xODSisLZRjwAgEBxN9D+AWUBo63jFAIAAAAgHgAAAIB4AGyssjK4 FACg7XWTwaUVhcPgUqirIzwyHaZQz/WE3m3KAjqqT4d6MjjiQVAB6ghAWT1f+fQRgHggHgQVoI4A IB6AeBBUAPEAQDwA8UA8APEAQDwAEA+CClBHABAPQDwQD0A8ABAPQDwQD4IKtKwjzNUCiAdAu/q0 3bdnIPWqcKgkAECguJurBcGG8dbxsZ5YURTbM05go2zxJQMAgKmIx35B2nSiFQsAAKYnHhcXF8Xp 6WlpdLy+vi6Ojo6Kg4OD4vj4+O61lvUhKd/n5+d3eVtkW52P/p6dnd2d15DFg7laAABaXze3+jaU oU+F0+lcLRaP29vbt8G3Lkh7HQX6vb29tUVnSc7V1dVXll9eXr7N083NTat96pwlG+myReRliW26 Fg8Gl8IUAgVztUCX9YnBpVWFs4oWDwVBBfU24qGAH8VDQV+tJjGQe5kkRetHSdDruK7XcyuK/roV RmKkY0kK9NpJr9XKIbSt9yO0f+dB78VlXr6zs5MVnDTvUXKEljnveq39eD2Vo/PQcBsungDtr4UM LoVx1/GxnpjEQ8FPQbapeCj4K5Aq2MdA7m3diqB9xkDr92Owd9eI3tP6Egm/H99TknjkWjzSVhgH fHWZWBy0z1Q8tK+qFhsfP66nc9Ny5VV/3Qrj97V/H1/L9H7dNogHAABMRjz+/M///F8qMCoQKkCn LQplQV7rxS4Jba+g6vctGhaFKDU58VAQ9raxhUPy4O6TJuIRRcJyVCYYVeIRW2aiRMRj+fzifuJ4 EeH9VG2DeAAAwGTE42c/+9m/iDKRtmLUBXmvq0AaRUTiIGmI71eJh/6mwqP/tY3Wl3w0EQ+t664S ras8lAlGWVeLW07iQFVtr/WbiIdbPHL5W4d4MLgUAKD1dZPBpRWF86TLfs0i3NWSdrWkgy7TIKoA r8BtYfCYBY9v8OBTj7GIwqJt4uBUvefWiRik3b2hY+l97TcdQJoGdr9W/iU+VS0bWjfexaJ8xa4S n1vs9kklQnnzeep4KgePXymTlbjNCsTjBYPuYAKBotOB9jD5+nQiEI81BJUoHgqybqFwa0M66NJB 1K0KHkyq/327bRQWB/bYdaFtLBPuVrEoxFt0fSyLgNdPW0W0XcyT//d2HqBaduuv8yNia4XHZ8Tz 8QBRC4UHlGpZPJ7HlzTcZnuBerBf9vh8xAMmEiiYPgIQj6GLxypTk4GrE06Likcx5zP9+kM8APEA QDwQj9Bts8jzMRCPRuJhPp93xSEegHgAIB7TFg9SeXr//fc/m19ExauMULTlFvEAxAMA8eiqcP5u xp+5kALfD8GrMR988MHnhP7Npg8//PDJvAVjv+lguZIWj8/my2nxAMQDAPHorHD+R4l4xODVmI8/ /vhZ20BZ9ZyPoafc7bptUttHts/T9gL1YD/pYnm8qlYxAMQDEI9pi8dGu1p8R4afBhrvFIm3zGpM hx+65Wd8pEE9ruPbS/3wLU9CV5V8O298pLmTluduB65LOu6C8nCXdJfKAvKyqHi8IxzhvcdcSADx AGhVn5irpapwutxfG/HwY83dMpA+G8MPxip7P20pSddJHxDmZ3tUJb2fHsdStGzrxaJpgUG0i4gH c1TA5AMF5QCjruNjPbE24hEDfFvxyD0NtU483HJR9vwNB/ncnDFxX9o+fbaHpUYy5Kes+m98Rokk Jtfy4snp/DwSb+9zbdnawgUUAAAQjypJaCIekgY/mCv3DI+m4lHVchEnrHPQd7eNt0sffW6xiMeO TyvVdmrZcfeQpCLXiuH8S05ia07d5HOIBwAAIB4rEI/4fq7VoqsWD28r6Yj/WyDiMeLjy7VunM02 bhfHpfgR5x6TEuUlnSyvD+LBXC0AAK2vm8zVUlE4K5urpY14WArajPFIBaJOPOJcLnXi4XXd5RL3 FfPpGWOVPE19OgutzyN2sSjvatWI56gUB8j2SDwecyGBCQQK5mqBTn+wMbi0vHA6DVKLjvFQivOy eJxD7LqIQdwTx8XkdeL+JRBa37PDVrUs5LpR4msfL863ko7XiMdIhUWv3c2SG6NiYdF7cUK5dKZe uloA+n8tBOhdHR/ribURj9ytpp6DJQ3MFo5IrhXF3SEirpsex10dMXkbr+vAH/flpPyl4lPWCpPe IlzW1eP9uyXE+VjgllwuoAAAgHjk0qYmenOrSd+TJGSBfCIeMNVWC24LB0A86tMyD9gae1rw2SGd igeDS2FA4nHIg8CgJ3WRwaUVhbORwaWklaauxaP3j0yn3vU6PV+zePjR/60EhMGl0HFd5JHpQw4q QB1pKh65O4XSFNeJA3g9rkbLqroA9X7Twb4aRyQWadXzeCcfc5luSY0r8gPv/JC7CYhHKwGhpQQQ D4IKUEdai4fuGvLdQ1UpfQhdekdU3bia9NbvnDREOfEzXtqKR1meqp5Fk6Z4t5jzskgX3iKyMt9m 0+LRSEAQD0A8CCpAHWklHrrTqGlwjw9+ywX5ulQnHno/beXILWsjHk46z6atH2WP6G8jLi6vtrIS tumLeFQKCOIBiAdBBfpRPzQG6JczPptfmHvJBx988Lkf+tZkQr8q8YiTCfpR9362irfRMfRaQT2V gDJh8PZxGx0nPoo/Pq4/lyfP6RPXdcuK85oes0zGtL5vXfcx1aqSnptnbda+dXw/nTc+qbdqm+9/ //u/WGNd+KKBeGQFBPEAxAPxgM3Xjd0WF/GNsr+/X9ptUiYefsqsUID0NmnAd+COT5RVUHXXQzrj cZ14ROlxq0CUhvigvLI8eXs/LdetG2mLSm7agNgF4/XVFePj584tfRBeWmZV2zx//rzv9edOOBAP QDwQD9h83Xg2RPHIyUCbFo/42r/s033GrpaceOS6Ytz6kBMPB//0Cb114hFbSnLdL9qmbGbjmMe4 /9y5lU2SWFUeAxKPYn4d/C+IByAeiAdstm48mPFyiOJRd9dJU/GIQhBbE6rEw0E3Pn1XrQE5cYgT By7S4uExH2VdKsp3Ln9uKXEe9deCUicecayKtx+weOj6dziv77R4QNctxr2KrX0qHKQDqurH/Xkz dK/5+OOPnynQxXl0LA3p4EpJgJYJdw/Eyfnc6uDxDHqtYOr5ehR0PcuxhSB3x4fHhniCQAdubeeW iHRMhPOhbWM+4muLRrzLpaqFx91Kfsx/nA/JY0ziOJHcuXn8hparTLSOtq0qD28zW+c/r7EufLut cHAthMlczykEgO4oVvQAMQXZ+KyPts/ScJBOx1mk8wEtm8q6U9IuoFxqe4fLAqlPd7V8RTgAEA8A 6I146Fe9grpnOF5kfh/PtJybkbiL/MVBoj1NfRAPhAMQDwoBBlNZBzBXS7HCR6aXzXDchySpGcBc R5sUD4QDNnXd3O7bI/j7VDidztUCo/wCPR6AeOzOuIRe8s0NiEdr4WCuFuj6BxuDSyusjEoCACO5 2D9atIWDayGM/vtBIQAAAADiAQAAAIgHwMYq6wAGlwIA9Oy6yeDSisJhcCnU1ZGCcoAJ1HMGl0KX 9YlHplcUDo9MB8QDqOc8Mh0QD8QDEA8AxAMQD8QDEA8AxAMA8UA8APEAQDwA8UA8APEAQDwA8UA8 EA9APAAQD0A8EA/o3xfo8ZDyWxTF1owT2CiDu6YgHtBxfWKulorCQTpgVCjo9X261gmkwQVwroUw ehmiEABWLx5nZ2fF+fl5cXt7Wzqt/NHRUXFwcFAcHx/fvdayPqTT09O7vCtvi2yr89FflYHOC/EA QDwAYIXioWB7cXHRKEgLJQX6vb29tUZoHTNNl5eXb/N0c3PTan8SDslGumwReVliG8QDAPEAWLCy DmyuFomHAnfTloIoHtouFQ/JSxrItUzCoL9qIdH2alXx63Q9t6Lor5Z5HQmB8qnjOmk/WiYsJdpG xPWUp6urq3fyJknZ2dnJtuykebLQaJ9Cy7wvvdZ+fHwdx3louA3iAVO/bjJXS0XhMFcL1NWRx0MT D7V2CAV4iURV94m7JSwrMbi7pUAB1yLjZQrclhT9VXD2a+9X60gkLAPeh8UjSk9VK4wDvltxdD7a pyXCSXmoarHR9u520nrKn+VHr/VX+477UXn4+C7Lum0GOsaDuVqgy/r0HoNLK6yMSgJjQuIRRaBu jIODvIJp2iWh/fh9oX1GUbBIxOPFZXFbBXwtU17c2tBEPKJIxJacXMtGnXjEViB3ycRj+RzjfuJ4 EeFuoKptBioeXAth3DJEIQCsTjwUYC0C+ttEPBzkY4tHGsTVuhDlpEo89Dcd1Kr/dSxJg+SjiXho XbfYxHPJiUdZV0vuPQ9ebSIe6ViZMYoHAOIBAAuLhwKlBUHB1TKRjtVIg6i7MCwMvtvFYykcvLW/ GGjdBaJl3l77tADFIO3WBh1L+/TrqsDu11rf51ImGFo3ipbyYnGIXUleJycRyo+7YrS+z9llULcN 4gGAeAAsXlkHOLg0NyDTMpAOunQQdfD3YFL/n3bBeLyHgq1bN3xbriXD27qbx//7WLEFIa7vfLoL JO4nbufujtg6kw5+db7LWiu8bw8QtVB4zIiWeVv9jXcJNdgG8YCpXzcZXFpROAwuhbo6MqhHphdr fIDYIs/YmEjqpXjM0rOysRwMLoWO6xqPTK8oHB6ZDojHAsktHmUPJ0M8elmX9Vj0Ysbz9LrHI9MB 8UA8oEfisSJezy/2nfL+++9/RtxHPGrEo0gFBPEAxAPxgJG3eKiLTxf6rvnwww+fEPc3bB37+wrq r1Yhlg34gS/6GV6USLAE5DPEAxAPxANGLB6roligq2XM3SW+zXfR1PaR7XYPjZdYhVg24HFL8Xg1 f+8niAcgHogHIB4rFw/fkeFHfsc7TPycCyXdseEndyqY+zbbmOKtp5IZT0Dnh3D5KZ9VAqR1cs8d 8fK2kqTjLigPb8WlyZw3A+xqeTkPDlvhPcQDEA/EAxCP1YmHH2vuAJs+MMwPxip7PycB6UO64i28 FpO6PPkBY7HVwU9C3USKz0IZgXi8nN/dcj/zHuIBiMcaCkdfwgdUFKioI4/HKh5RJNqKR1kgrhIP HzP3ILO4TfrskPjo9bgstsj4gWWSIbe2+G98Rom2ybWouLXFDzRLW1da3jrcV/F4VPb4gPkYj4d8 56GjurbLXC3lhUNrB4yKpuKRikQT8ZBUWArKWh+aiEdVy4XndYn7yc2pEh9wZpGJ+Y8TuynvnhDO j11P56WJZSA5SVtz6lpqhiAeXAth0jJEIQAMTzzi+2VjNbpo8VDy7Lpet2ziuJgvyUSczTaKRxyX 4kece9xKnME3N1neFMQDAPEAgLWKRy641o3xyMlHlXh4rpeqwZ5e3+vm5myJk9JZKLyNB7PmxCN2 sSjvatWI5+jWlSgiiAcA4gGw3so60Lla2o7xcCuDWxg8ziF2XcQg7rlg0nEScZI5tx5ofU9pH+c/ yY2biMfU+5aU2BLhuVO8PIpMeudMlBS9djdLboyKhUXvad3Y3ZKWFeIBUH3dZK6W8sI5pJJATR0Z VBBpIx65W0090VsamC0ckTT5Vtu0NcHL0pR2uXgbr+vAH/flZVpH3Spp/tPjpMfWNmXdRD4nH8/7 Vln4tuMRj/Fg3iroWjy2EY984fSqYADWKR7xV/66k4J7y2C+sbRAPocoHlwLYdwyRCEA9EM8PDaC VFS2goxdPAAQDwBYm3iQOk+IBwDiAbBgZeVpjgAAba+bDC6tKJxDKgnU1JFBPTIdYMF6zuBS6LI+ Pe9bfCWoAOIB0K96zrxVgHgQVIA6AoB4AOKBeADi0TOKotjSgEboJYOYhBLxAMSDoALUkTbisc+N JL1Nvbr4Ih6AeBBUAPGYpHjo6aHpI9cRD8QDEA/EA/gCDUQ89FhvT6TmqeWrktb3/Cd6dHnbp3P6 eNrWx/Iy/fVrz+mi/cdHpHsytmWTjq195Wa8ldzkHv++iCTl5pVBPAAQD8QDVlFH9ocgHnHKd02E VvU0UklAnIxNqS6w5oK3xCFdHvcbJ2izbDgpf121eCgPuVlvdU51ctNUSqrKR/JTUd6IB0zxuslz PCoKhy8aDJ60q6VOInJTvKcTp+l/B1MJg8QmbUVJxULJM8iWve/U9FHknniuqgVH7+uco/Qo78pL Kh5V55Wb/M7Hj2WarqfjxhYjbRPKcyjiwbUQxi1DFALAasRDQTXX7RCDZi4YezZWoSCqYKz1HMAX FQ/tS+tU5aksuZvGM+ZWnZOnsnfS+vFc685Lf3Us5dPH0vo+vmUtXc/7s3hIULRMMjJvTRmEeAAg HgCwkHgoIFZ1s+TEQ4FSgVV/FUwVNBVgFUQVZD1uJNfVskrx0DbuNqpr8XAXk/OpbeO51p2X/re0 eZvYyuHXufViOeh89X7IC+IBgHgAtKisAxnjkRtjkUsKirmuFi9zS0FMZeKhYJyOkWja1dI06bjK W9XgV4uHz815TcWj6ry0f0uSW0SioFk80vXS89T5x4G+iAdM9LrJGI+KwuGiAKMRj1w3Szp2w3KS CorFQ0HVQVbB1HeG5O6U8RiJNJiXiUdbCbFs6Lyqxq3EMRdxrEeUg7rzcheJWjS0jVuB4n5jV0pc L56nj6dyGZJ4MFcLdH3dnPEe4pEvnG0qCQwdi0fazVJ1G6iCooNj2qLhQZmWCgf+3F0oHieR7kO/ +i0BXieVlCZdLb5lt+zuE4/P8G29bvlwt1Fslak6Ly1TXvVay/ycEa/v/ZSt5y4hLXN+5gI0FPHg WgjjliEKAaB78SD1Mg1CPAAQDwBAPBAPAEA8YHKVdWCDS0mIB0APrpsMLq0oHC4KUFdHmKuFNHrx YHApdFyfeGT6kIMKUEcQD8RjDfWcR6YD4kFQAerIasRDd2L84he/eHsbqm+T9V0het+v/b+fbhpT XEevvU58rkaTvKTr5o6lVHU7rraPx14kxYeKxceq525JRjwAEA/EAzZWR3S/+oyTGY/6Lh5+vLiS n+YZUwy64VkUb99LU7xNNj77wo85r5s3Jj6OPC5LHxiWPtArl/ykVN8G20R8nFwO3j7uc8mHoCEe gHggHogHLF9Hgmx8oXXmbOSL1kY8ogjknkiaikbVHCm5dVKJyD2sLJWMVChyrRaSG+27qvUhfZBX Xd5jyj3NFfEAQDwQD9hoHSmRjWIo4uEHYC0iHu5KaSseuRaNRcRDXR7hoVyNxEOtFxYfv6e8uhzc qqK/ftS6zjHdj1/7QWZ+cFiT9Mknn3x7/hTHvnODeADigXhAT+pIjWxEtM7luvnggw8+bxIEU0lo Ih4Ksn7Kae6X/zrEwxOvVbVMWBLik1Sdv/ik0igucV/xdU48/BRYl0ndnDhOH3300UbqxALczvgn fOcB8UA8YPN1ZH9+T/p35s3RVeKxkV+3H3/88bNViceyXS1qIVhWPDwVvR9TXjZhXK5bJOYvnVsm rl8nHm4toasFoFF94jkeFYXDFw0W+UKVSchGgkzTrhbPfVIV9OvEI+1iqBMPiUI6cV3d+AoJho8j cYnztOh12SDTOvFwN0rMW5sWj7ht2dwxAxYProUw7ms3hQAjlZBei4eCZ9pFoP89Zbz+ujVBYzr0 nrsXcnfAeB2h127d8PpxHIWDeE5CPBZDeYhy5Fljo+zotY6RtnpYDNL9e1K3eL5ax9Pbx31aJjw+ JH3tsSLKU4s7ZgYhHgCIB8AwJWS3z+Lh4FnW5bHq5Onkq7pd1pHa3GbbwbaIBwDiAdBKKPb7nsei 5QPE6ro+VpWqpGPECfGAqf4Q20I88oXDRQEmJx4kxCNTz5mrBRCPNRXONpUEhg7igXhwLQQYiHgA IB4kxAMA8QCADYpHeuvoWFLurp5lUsMJ6RAPAMQDoEVlnegYj6qHfg05LXNHSy7pVtuax6cjHjDF 6yZjPCoKh4sCVNWPbT2jY8ji4SnmdSurp453AE6fjxF/vVs8yn7Re/vcdPY6Vlk+0mVx+3Q+GL1O g3pum/Rcqo7r9bw8bbXI5bMu1czAO4hrDINLoeP6xCPTKwqHR6bDaMXDjxn3w8E8bb3Fwd0pnocl PlI8Pggs7Z7Qtgq22p/3kR4rJu1T62r/el/be5mnr9f+PAeKgr/3of+1X62j1oXcNlruZTE53/6r fTq/fmia9u0y0TLtI320el3KHXuA4sEj0wHxQDwA8VhOPDybq4KiWyFiF4p/qcdf7G4RyK2XSo2f +GlpSY8Vt08fxe5WBR8vPtrcj3JX8Ne2nvRN+/cyHT9uE/cZhSA+4TQ+It551P9+YqnOxU86rWnF +MpxKlpJEA9APBAPxAOmIR4OyPER46lQlA0krRMPBWi3mjjopseK3SEK5nrPs7xWzamSazXJiUWd ePhYPr90bpo4i22DLhPEAwDxQDwA8agSDwuAuyXSsRsOwm61iNtUiYfWdVeEWwxyx4otL963Ar1b R7wvd61YArQPHd+tJ2rd0Lbeb26bnHjEOVY8lsPnrDzHfFqi/HTVOI9LOjA17VbRdhUDTBEPQDwQ D8QDpiEennBNf92dELsq3OLhgOzJz9xSoG3iemmQ9lgIHyM9Vhxr4fcctLWdx5FILtzF4S4Qj9uI cqB13AXj/93y4mPkuni8PJ6Lx4ZomfYRyyGKhMdvaF0f1+NORja4FPEAxAPxAMRjOfEgrT5ZzhAP AMQD8YCu6sg+4kHKJbXOjOUBYogHdFyfeI5H1S9aKgkMHcSj12ko4sG1EMYtQxQCQKfisTWXD+gf D6ijAIgHAAAAIB4APaysAxjjAQDQs+smYzwqCueQSgKIB1DP7x0yVwt0WJ8eIR7lhbNNJQEAAgXX Qhh5HacQAAAAAPEAAAAAxANgY5V1RGM8iqLY5vbWzmFcBMBXr5sP+zZmqE+Fc0glgYr6MYhHprcQ jxOe59V52h5JXX/Kdx46rE+XffvR1qfC4ZHpgHisIKUzuCIeva/rXAsB8eDLBojHasRDs8TWTGz2 drbWOCutl2mOkvh+XO7kmWGXTZ4PJe47yk3Ze22S8r9EXhEPAMSDLxsgHmXiISFQoBaa3r0qadr6 tOXC22h7ve8kAZDQOGkaec3c2kXSMXNTz2vKek9VXyUuTeSmamr7mn0gHgCIB182QDzKxEPBOrZK 1IlHmmLLQPp+DNANZm1tnHRMHSuKjF7Xtarovab5qCqLmnIajHjM0g9mnOQe7MS1EBAPxAN6JB7z x/+eVPBUX7IN8V4b8VALgeRDQTl2oywrHmrhaJvcKqI8VQmCjql1YwuNttFy50fnonW8nv5X/rSe hEh/LStuxfH6LhPvN66n19qPj6Plfn+A4qFgUMx4lQoI10JAPNZTMFv6AlJJoIF47NeIx3fnX7RN 8MU8mNRycnLytusitnwsIx4O/nXdNmUtCW7FqOrO8DHd9SMkDFE83Prh1hGto3O00Dh/Fha9H/Ns kUjXi+Wgbdy1431/+OGHT/oqmhXiUaQCgngA4rGegnkwpmZ0WFk96dWXZxk8xsO/9rvsallkgKcC twJ4XT58TAtO/D+KR24MiMVDg2nduuEWlHgu3j5dLz1PD8z1vt9///3P+iqaLZCA/APfd+jwuslz PKrkg0oCUyGKR5MxHjFwWy7iANJUTNqO6/CdNTHIV4mHj+k8pOLh/ambRXmN+fe5ehtLT1oW6Xrx PLVN2uIx0K6WyPN5yx7XQhi3DFEIAJsRD49hEB6XoUCe6ypRYHV3iFsB4uDO2NUSA3XbrpaqO2B8 x4kFwnnwXTnCt/cqP/FOF7eQ+D3/7/Eb+usWFG1XtZ726fdVXuE4QxSP1zO+w8RwgHgAwMrFY5G7 ShRwV/VAsK7323Z/dQNsG6Qhicenc+GgdQMQD4AeX6z3py4epNGIB/PKwLrqGmM8KgqH+QkA8SBN Qjy4FgLi0Y/CockRJsMsSB7OuIROGcU1hGshjF6GKAQAAABAPAAAAADxANhYZR3RGA8AgDVdN3dz cwIhHm8K5xmVBCrqx6gmiQOoqOtPuesFOqxPejDdIeKRLxzmJwDEA6jrb+Yk2qYsAPFAPADxAEA8 APFAPADxAEA8ABAPxAMQDwDEAxAPxAMQDwDEAxAPxAPxAMQDAPEAxGONhfOaSgI1dWSfcoCJiAeP TYeu6hPP8agoHL5oAECg4FoIY6/jFAIAAAAgHgAAAIB4AGyssjLGAwCg7XWTMR4VhfOUSgKIB1DP 7+Zq2dedfhvgks8A8ZiSeDCgCgAIFBu6FnLLOkxOPAAAYKPCg3gA4gEAAIgHIB4Am7ow7lMOAIgH tPpcGeNRUTjPqCTARRGo63eDS+/zHYOOPlcemV5ROMzVAlwUgbq+obla+I4hHogHABdFQDz4jgHi gXgA4gGAeADigXgA4gGAePAdA8QD8QAuigCIByAeiAcgHgCIB98xxGPS4vGaSgI1dWSfcoCJiMeD DRwX8RhnfeI5HhWFw1wtAECgYK4WGHsdpxAAAADxAMQDAGBOURT7sFp+/OMfP/n617/+krJYPYgH FzUYzi+yyX9hJyweJNJo0pqvm4zxqCicp1xgAfGAMvG4vLwszs7Oipubm0YXd61/enpaXF1dFdfX 170MQLe3t3d5XFVSGVxcXHSyn5hUnnX51jbn5+eNj6+yOD4+HqVopPUP8ehPUGFwKQBkUfCSdCg4 7e3t1V7oDw4O3gZLiYr+X0QK1rFNk/OpC2Rl+dB6y0qX5CGVPe2/qky1vsWkjUzs7Ow0Psc+CESb pPq7CfHo5Y9ILmoA0HdikFNAixfxNB0dHd0Fy6pf7E3SIrKyjm3qgr5bebpIEogycajKgz6fRVpy LB5157iJ5Ba0ZZLqJuKBeADAAFCrgH9t6uJfFQAUvMq6Y9RyIikRCqgKcAoGQv+79UFBRvvxcRRI tUzBUPlosk1sMdD2WtfdDhIDraf3HGzT9XQc7dvH8HG0nbbxeaTb6L14bs5P03OPScujtMXtvb6O 6eXal6VBaJnLy9s5ADtfWs+i5LKI5xhbG3LlUVZu3kfZ8Z0HrWupiGUQP/N4TlqWnnPumH4/1gfL FOLBRQ2GUlkZ4zFZdPHWBV4BKgatuub6ql/pDiLalwOS/qZBUEFE62o9/fXxq7ZJg7dESEHRgS3m w8ty6+mvZcWBXMeq28b5iZLW5txj3rxMx/Ev9rg/l42DrrtZovAIBe8oFn4/ttD4/XiOaX7S8igr AwtT7vix9SLmxWVgkbGMWCBiWabnHI8ZW+Vi94zLc83XTcZ4VBTOMy6wUFNHeKz+RPEF3AGpqq/d vzjT5F+lsUsiUhUEU9Gp2yY9roKQgpeO7yCVBvB0vTKJiEG56TZtzz0nHmW/3nNdImmrlF67RWhZ 8cidW1UZ5I4fP9NcXnJlUSZxubx5nXTZhsSDR6YTVIA6AouIh3+pxl/dueRfqmnwj794vZ7vzqgK gmnQ9q/lpuLhIBWDqdbzANA0gMf10kCrY8f3m2zjfLY595h3L0tlIObbrRAu57ryybUyLCIe7gqp K4Mqmczl1S0esf6k4pGeczxmbG2J54F4IB6AeMCAxMN9+WUtGOkgPnfNxFs63TQfm9r1f+z79zEU XOJyHUvLPOCybpsYoN09o8CnY3ucgpvylb/cenpP+05bXbw8t427pVQ+MZ9tzj2Oc4jjLOLx3PLk cSUef+H9eryH9uHuCq2n//3Z6bX3p3KNrVV+PxWPtDyqys3nkB7fZVRVBh5HYrHxfuNYGp+zxcPb evxOOiB1E2M8EA+CClBHYAHKBovW3b5adndH02eBLLtNk/1VnYN/IXd5a2nb80hbmMry0na/Tc5/ HeWxTFm1eT/eYox4EFQA8YABtHhMMaVjBDaRdPwuHkI2lvJYNMUyRDwIKoB4AOLRy6Qgu8hDySiP fqU0z4gHQQUQD+i/eJxMhT/5kz959eWXX/7Zuo+rY+rYUyrrTYF49CeovOYCCzV1ZJ9ygAnU8y80 Rf0Gjrs94wWfwejqE8/xqCgc5moBAALFhq6FiAdMTjwAAGCjwoN4AOIBAACIByAeAJu6MO5TDgCI B7T6XBnjUVE4T6kkgHgA9fze4Yz7iAcgHqsvHAaXAgCBgsGlMPY6TiEAAADiAYgHAAAgHoB4AGzw wrhPOQAgHtDqc2WMR0XhPKOSQE0d4ZHpMIV6/rRqcKkCCeIBLT5XHplOUAHqCEBlPX+Re2T6/G4X vfcc8QDEg6AC1BGAlYhHEI5iDuIBiAdBBagjAN2KR0Y4zKca77QCniAeiAfiAUAdgWmKx5MS6RAv Z1yuiD/mM0A8EA8A6ghMsMVj/jrX6vGccgLEg6AC1BGAzsUjLHs843PEAxCPbgvnNZUEaurIPuUA E6jnX+TuagkC8oxyghb1ied4VBQOc7UAAIGCayGMvY5TCAAAAIB4AAAAAOIBsLHKyhgPAIC2103G eFQUzlMqCSAeQD2/u4X2PmUBiMfqC4cBVQBAoOBaCGOv4xQCAAAAIB4AAACAeABsrLIyxgMAoO11 c7vsgXSTFw8NLmVAFdTUER6ZDlOo54d9GwwIg65PJwLxyBfOi75ZGSAeABuo55e07gHigXgA4gGA eADigXgA4gGAeMDo68QDTQ64yHAExAPxAMQDYNTiURTFN2dcjojv9KBOaIBoMeNlWwFBPBAPQDwA xi4ez4txpcseiUfRVkAQD8QDEA+A0YvH7e1tcXR0VJyenr4TwY+Pj4uzs7Pi8vKycdS/vr5+uy9t q31cXV1NXTwaCwjiUS8ePCoYqurIYC/GAC3F4+HQWzwkClE8JA+SCKWDg4NGEf/m5qbY29t71wJm 0tJWPHTcJbbps3jUCgjP8aguWKQDABCPe/f+qSR7qPz85z//NCceOzs770hIk1aPXKuJklpULCEX FxfF+fn52/fUKiJh0XaSB60reVFLibfTNlqvyTaz8/mvPSjXJzXiUSw6BmTS4gEAgHTcPTysGDLP n78Z4lElHul7ZUnBv6ylQqIgMbA46LWkQceRiEhK3LIS9+NtJB96v24bLRvg59BrAeHLDgDQH/F4 iXi8Kx5lLSPpWA/vPx4nJx567eM7D1XbDFQ8ooA8QTwAFr8oP6YcYOR1/AdjFY84VkOvPd6jrqvF LRS592J3ifffRDzSNFLxcKvHP2OMR/kX7ikXHqipI7uUA4y8jutBUf9xxl/OB5kOjh/+8Icvc+Kh 1+re0PiJOLg0ykNuLEfa6uF9xG4RCUJV64X+ajt1z+i1W0t87KptfvSjH/19D8r1s0W7WRhcWvOF 48IDAMjHsK+FuqtFrRkK6sIDOpU0jiIOBNV7dV0uXsctHJKHKCGSCO9Tx9W6khLhwaJeHrtp3JLS YJsh3NUymIGlvRIPAAAYPgUPEFu3eAxGOBAPAABAPIYrHoMTDsQDBgeDSwEQD8SjnXBobBxjPMoL 5+kQzQ3WWkd4ZDpMoZ7rWR5blAUk4rFQCwePTK8uHOZqAcQDqOcDn6sFVlIn7i/6wxzxQDwA8QBA PGCd9QnxQDwA8QBAPADxQDwA8QBAPADxQDwAEA9APAAQD8QDEA8AxAMQj0GLxxeIB9TUkV3KASYi Hg8pC+ioPm337fbsPhUOc7UAAIGCayGMvY5TCAAAAIB4AAAAAOIBsLHKylwtAABtr5vbfRsf16fC OWSuFqipI7368gCsSrAZ5wEd1qctJokrLxy+aABAoOBaCGOv4xQCAAAAIB4AAACAeABsrLIyuBQA oO11k8GlFYXzlMGlUFNHeKw+TKGeP2GcB3RYn3hkOkEFqCMAlfV8oblaiqK4hNHzCPEgqAB1BKAv 4jGpdHt7O8XzOEQ8CCpAHQHojXicn58Xe3t770Sqq6ur4uDg4O5vm3RxcVEcHx8Xp6enxdnZWXF0 dHQXJLX/tvtaRUrPU3lb5Dxjurm5uStDnbfOedXp+vr6Ls+IB0EFEA+AXouHxoDMx8Vd+jvhyLSz s5MN0m0CsqRDohGTBGSRfa0zKY/L5E3C4e172qKCeBBUgDoCsB7xSGSjCHQuHrn1HYj13uXl5V2L gATFSS0FsZVA/+sXfbqeXgvtQ++7pUHL0lYGvS+Z8Pbaxq/jut6nZMn5zu3T2ytvadJ7KjvJh147 /xYu/e9lXt/78zH0Nx5PeXHeYl61T5WnW1i8rZYbl3dyDogHQQWoIwCrE48K2VipeOT2Efel4Kyg 6e4Od3E4+LtLJl0vyokFJram5Lo4tD8HZ+1f+1bwdx6jSMSulnSfyodeO8j7da6cnH+LhKXAy71f n6v++njKg/IXJUnbxG4VvafjxK4xn4Pei8fwOc63RTw6/rJ9QVCBmjqySznABOr5pzP+dY1sRD7T uusUD+/LgVRBXcsUfB00c+t5vEgMxh6D4l/6aWuE9h23T/MYx0i4qyW3z9iN0qSc0jJTXrUfb+fz 9XHja7/nMTJCQqH/lS8Ll9aLY1UsNjpn5yG2gnz00UdfzOtFG34y418hHvkvG/etAwDiMb8Wzh/8 9GzG5zXioed+7Hfd1eLg2EQ8HNRjIM2t5xYMD1x18I2tD7mxFdpe27ibI55nDNRRPNJ96rixNSUd nFolHrG7o414xC4W58PyovdS8fB5luXxk08++bY+6wXo1TOy+KIDAPRfRqokZFvrtBGPNIjnxjvE gB67AnJC4WXuOtC+c+u5W8RyEPOs5el4iHjsNAj7PCUUHggr2fD26T51Ts5HlIYm4uGWGnfxeHxH lXh4zIjHw8SuHotMFI/Y/ePuJOXXUjcXn8NR1Ge+1AAAg5aQt+LhgYuxtcIBMgZ0/V8lHu5aUNAT lg4FRO/LAy89lkGvFVw9FiK3nlsi3CVjYdA6aYtEmmL+4z59Ph4L4mW5fbqlJTe41PuMg0q9nv/3 YFl3u/icPQ7E5x/HpLiFJw4gjeM5vF+Xl6XELT/+DBYdXIp4ACx3wX1MOQB8RULuxxaPPqf0Ft11 PCtjZOlwwTqyi3jkC+eQuVqgpo706ssDsCrBXmTM2xCipn7pu/sg19VBWol4bPXtxo0+fdkYXAoA iMeC10JiMuIxmDrOFx0AAAAQDwAAAEA8ADZWWe/de8Q4IACAVtdNBpdWFI4Gl25RUaCijvDIdJhC PX9MPYeOY+tzxCNfOAtNBQ2IB8DI6vlzBQvKAhAPxAMQDwDEAxAPxAMQDwDEAwDxQDwA8QBAPADx QDwA8QBAPADxQDwQD0A8ABAPQDzWLB4PqShQUUd2KQeYiHg8oSygo/rEXC0VhcNcLQBAoOBaCGOv 4xQCAAAAIB4AAACAeABsrLIyVwsAQNvr5lbfbtzoU+E84Y4FqKkju5QDTKCe7894j7KAjurT/b7V pz4VDgOqAIBA8eYXKi17MN46TiEAAPTuF+oP5o8YWCfPER5APAAApikfD+ddLuvkJd3dgHgAvHsx ZnApwOq+XzwZeJyfK4NLKwrnMZUeauoIj9WHKdTz/U0MpEY8Rl2fLhGPfOEwPwEgHkA9v3fvRCAe gHggHoB4ACAegHggHoB4ACAeiAcgHogHIB4AiAcgHogHIB4AiAfigXggHogHIB4AiAcgHmssnO9q vhYqClTUkfd4jgdMoJ5/UyAe0NHnylwtFYWzRSUBAALFXaC4v4HjIh4wLfEAAICNCg/iAYgHAAAg HoB4AGzqwrhPlxwA4gGtPlfmaqkoHOZqgbo6wuBSmEI918y0DxEP6OhzZXBplZVRSQCgC4qiOJxx OUT+8R//8S/Fuo/7V3/1V69/+ctffjbUctsA3+e7NnDxAADoUDxOinm6vb0tYrq5ubmjadK6V1dX 2X31KV1eXq5s3z7/ZVObcl9F0vGvr68X2k6fffL5v+C7hngAALwVDwWYg4OD4vT09G2kOD4+Lvb2 9u44Pz+vDTjaXusp8Oqv/m+bFpGVttsofzqnVR1H5basNFxcXGxcPJQH0TYdHR29la+zszPEA/GA yVRWBpdCyxYPSUcUD7cKKADu7OzUSkfaihCCTqugtY5t2kqRyiCWTS5Id9XSoXJsInp9TSonl0Uo t0GIx3yMxyPEI184T/o2AAZ69wXisfqwlHjEVNVCoNaSnJi4hUBBWYFULQFuuvexhCVAr7Uf50Hb eLum2zh52yglCoaSIbfkeJm21XrKm/Ks126x0bpaptfaxoIRt/H5638FWi/PnXvcv5b53FIpiq0d WieWg1uU4nFi0Hf56D0fP5ZDzJP+6n+Xp157Xe1H5ZWWSe6z8fpapnKKEjbfZijiwSPTCSpAHYFN i4d+gVc1udd1XTiQKYBZUBy4Y9N83I8Dm5cpD3Xb5ERJgdEtLw6aCup+3wFa+/H7es8BNx7bZVO2 jYNtfJ07d++/TOiixLkLzOv6f+0vNwbDZeSxOTp/5UXL9Dq2pvi80mNGqfP77m7T8co+G7d4xa4W b/vTn/70bxEPxAMQD4BG4lHXZaIgU9YVowAV9+mgHI/lpvkoEf717OUKtHXbpK0wyrfHrcQgm3a1 OI/eTxSH2MoSt6/axq/Lzj2um+vyScvSsqDl3m+ulSf9DLWuxUOoTPx/bO1pKh6xTNLPJn4GsasF 8UA8APEAaCUeTccaKHClgyH1v4JmDEq5oFYmHlF4PFagqXikx1E+YpD3a7cexP3kgmza4lG1jV+X nXsb8bAsxO20TOWhbVMpTMUjdrF4X/5MlxGP9LNxawzigXgA4kEdgYXFw2MQ0ub7XLD0OAE3t+uv Xztouek/PZaW+S4Oj6PwgFa9F8ccVG2TBm/nyXnXMgVMLdc2/qWuZW69sCx4f86vx0n4/XQbvaf/ FXxzEhLPPX0/vVsmlm/sznArh46lbTxWIxWPOO5C28ZuFu9H2/kcvJ72p2XOUyoeLpOyz8bnpWVR TBjjgXgA4gHwFfHwL/j4S9X/p8vLnoGhgOSAlrZ+aHncLu4zvvav+bg//99km/jr3r/A4zgI5y3e dRH3GcczpEG9apv42q0SVefugaaWklTi4rG9jvGg0dxdNOln5ePH/LjrJrZ4uKzT83BXSrrf9LOJ +03HnczlBPFAPADxAHi3xYNUfKVFYlOp6tbdrlIUj1Wl0BKFeIxAPL5DUIGaOsJcLYB4tEzuYljk iZ1dp1XnIddV02VKWnIG8wCxWdpFPPIFc5+gAgCIB2kgiSeXDl08AABgoz/+mJ0WEA8AAEA8APEA 2NSFcZcLIwDiAa0+V+ZqqSich4KKAhV1ZJtJ4mAi9fwx4gFd/mhDPMqtjMGlAECg2IBgIx4wOfEA AICNyg7iAYgHAAAgHoB4AGzqwsjgUgDEA9p9rgwurSgcPdZ1n4oCFXXkRFAWMPJ6rif0PkE8oKPP VYOVe/WwM4IKIB4A/arnh5qXCPEAxIOgAtQRAMQDEA/EAxAPgHGLx7yf/tmMzxAPQDwIKkAdAViJ eATheDmjWGUAQTwQD8QDgDoC0xWPf58IR4F4AOJBUAHqCMAq6vnxjNtEONbBK6YkQDymJh7fFFQU qPkCcWGEsdfzJzP+3YzvzHi9rhYPGHWd2kU88gXDXC0AAN/6/3O1zNKDREAQDxh+/aYQAAB6LyIW kC8oD0A8AABgXQKyRTkA4gGwvosuc7UAALS/dj5GPPIF81BQSaCijjC4FKZSz3sVKGD4P9oQj3zB MLgUAOBbdKnAyOs3hQAAAACIBwAAACAeABurrG/6vncpCwCAVtfOx4hHvmDe0xP7qCRQUUd4ZDpM oZ7rmR1PKQvosE4ViEe+YL4yFTQA4gETrOf7My4pC0A8EA9APAAQD0A8EA9APAAQDwDEA/EAxAMA 8QDEA/EAxAMA8QDEA/FAPADxAEA8APFYY8E8mfFdKglU1JEtJomDCdRzzVv1KWUBHdapXcSjIrBQ SQCAQMG1EEZcvykEAAAAQDwAAAAA8QDYWGVlrhYAgEWunY8Rj/Kg0qvCgd59eRhcClOp54eUBXRY p3r1g613XzgqCQAQKLgWwojrN4UAAADQexl9OuPZjPuIBwAAjJqiKPZnnEAj9lckHnqAYjHj5Yxv DrlVjC8VDMn4GVwKsBnxUEAlNUsnKxYP82q+bKvBto8Rj/KgcsiXHCrqCI/VhynUcw0ufdY38bi9 vS2Ojo6K09PTtxH26urqbtne3l5xfX1dG5G1j/Pz8+Lg4ODutdPFxcXdfprsoy5pH87n2dlZcXx8 fJfPEYpHYwGZpRd9Gpjfpy8b8xMA4gHU8zc/wl70scVDwTyKx+Xl5d1fyURcXpckKiKmNtuXpZub m6/sV3lsKx6SlyW2Wbd4RAH54xkPEA/EAxAPgFGKR2yxsIQ0SWqFUKuEyImH9qfWCr/We24t8Wsd T+/FlLbIxJYW7yvmVaKifep/b6d1JS/Ko15rnZifum2+973v/cQTWnbMf6oRD/N6xneigCAeiAcg HgBldfz+jH874/82DDJr4eTkpCgTDwXhnZ2dVi0ECtBu+dD2UTz8noK9umSUtH+3KniZAr8kIG1J KcuHjmNRkaDotfNuibBcxP3EfOn9um1UVj353N4KCOKBeADiAVBWx5/1STiaiIeDetrF0UQ8JBKW Fu9X+/FxYtBXoPf6ZV0z2ras5SXmT+tIYHRcL0/zoP+F1nNedJ512/RIPIpwF8zfIB6IByAeALk6 /nyI4qHklog24uGWDclEDOBlA0bVuiC0btrN4paMuO+YdAwPXvWg2CbiEfenLpUBicfbQae0eCAe gHgAlNXx3Rn/cyji4e4IdXnE5e5+aCIe/t/bS2B8J0rcT2zNcKtHbixH2uohQdHymHft14NOcxKh PGg7nZeO5W4aUbfNH/3RH/21YtkK+KKtcIR6hXiUfOEezviUiw9U1BH1f79HWcDI67n65P/7/MfY OnhQlycNLlVrgVscPFjT3Q+x9cFBvix5bETaJRL/l3ikchKP4XEhZfKh/buFJI4DSVtLnBedWxy4 qv99DrG1peE2Jyv84VU3puOPc7fVMldLdcFuceEBAOSjX9fCggeItUnrFo+v3MXS+/rNlxwAABCP wYnH4IQD8QAAAMRjmOLx3SEKB+IBw6usb0Zn71MWAGsXj+3izURxUM/2CsXj+SKDRJmrpTqoHPIl h4o6wuBSmEpdf0Y5QIf1aRfxqJAPKgkAECi4FsKI6zeFAAAAAIgHAAAAIB4AG6usb8YBPaEsAABa XTsf96n7rm9B5RmVBCrqCI/Vh6nU9RPKATqsTzwyvaRgtlU4VBJAPIC6fq+gHADxQDwA8QBAPADx QDwA8QBAPAAQD8QDEA8AxAMQD8QDEA8AxAMQD8QD8QDEAwDxAMRjjQXzYMYXVBKoE1TKASZQz19R DjDW62bfCmeLSgIABAquhTDi+k0hAAAAAOIBAAAAiAfAxirrm8fqP6YsAABaXTuZq6WicJ5RSaCm jmxTDjCBes61EEZ73ezdL1oqCQAQKLgWwojrN4UAAAAAiAcAAAAgHgAAAACIBwAAACAeAAAAAOb/ ART7TqCIYvHgAAAAAElFTkSuQmCC --Boundary_(ID_LrroFSWRXtXISoZEEmpZOA) Content-id: Content-type: application/octet-stream; name=oledata.mso Content-transfer-encoding: base64 Content-disposition: inline; filename=oledata.mso; size=64847; creation-date="Fri, 28 Oct 2011 09:25:11 GMT"; modification-date="Fri, 28 Oct 2011 09:25:11 GMT" Content-description: oledata.mso AAoBAHic7NR1UB3flyBw3N3dLUGCuzxcghPcg7u7S3BCcCchWPCHu1twdye4Wx4O29/ZnaqZrdqd +f25VXu6Pt237Z5bdU7dqUnsrfwakm2o/y1EoWChXt+QoRD+wzMYAPS/32BBAe/f3v4Z/vv1n6AF vP3/+H8mXgD/1A8WqBscAB7wT80RAUgAZAAKABWABkAHYAAw/2cLQGEDcAC4ADwAPoAAQAggAhAD SACkADIAOYACQAmgAlADaP5XD/2zFnpgzABgBDAB3gHeA5gBLABWABvgA4AdwAHgBHABuAE8AF4A H4AfIAAQBAgBhAEi/9bbUFBiABBAHCABkARIAaQBMgBZgBxAHqAA+AhQBCgBlAEqAFWAGkAdoAH4 BNAEaAG0AToAXYAeQB9gADAEGAGMASYAU8BngBnAHGABsARYAawBNgBbgB3AHuAAcAQ4AZwBLgBX gBvAHeAB8AR4AbwBPgBfgB/AHxAACAQEAYL/be1OwOEO1EIamNcdmOufP/77QQB0zL/3EvR/8S07 dbu/RuoY9H/cL4yBCnIBlfrnzAlUjR+oHt+/kJ8ICgb6n9z/7E1v/2He/1v8862Q+P85P/+/lv8/ 7Xf/nX/oAIxd/0KS/yL+1fz/KZKAPsk59UM20BjagIwJMNJVyGNgeeKCCLDpawmawqVPFLCiFrQ+ gsQNwpBW9FKiTLAbtjyfWnciNJ17Qlda8Y7VG0jnyisraZhQFOrpkGJoBDYVCYo2IAurfkEXdx2b d+hdkW4TYzm6bzdBeZmwHg3Pg7myOU4h2r3OIBhyM4wx3wFx2tsQRChT/wUONLMYy9ege0p8X6yK eDd+GENdJO+JZSQyODc4VLiPcMxmnYmHIzwZUFu0U0iNSJ5IECQYOEQ4WThGOCs4QjhtOL5wUSQJ OOxQoVDEUEYJY7gPcE5wlHDG4YFIgUgv2M/YCFRoUkggLFo0CSQpJAkkGSRxJGkkSW9YajJT9l6s 8HykvttG9GA48RisEKxorC9YDqeb2YPl50EnY8934fw/pMQyrdlkgn0Os6A3gubxn2epQARm72N7 ebcUD//YoQ3T+h0oiTXxCQX+afomdfd+BAsxBG0M+t2bem5HGDyVycVr+7mf5yBz9CM56k63NRYs zqvEi/AufH4nWdiFX66X86KPf5+IVFoJnJu4IEmkOfuJcdX3V9SXoTMlvg0zUsbuj35D3h4vf/hn H4c6exGePV/eusDKr07ovwmQJpgh04H7N0Gg1SvYrY1B/4BHfpAExRaIUoUCevo0mQBhNcjjzIyN SMxNL8I1hJNHg9tlPzRTYXp4/0L5CLnvkt96ClTDJMr6TsQiZCPltga2gCuJYDyHz2zrh/gP2ufZ h+qVC/zQ8MBu7AhoZphqYSQGndfESn3d8f7y/hm0mhV2a+n6Our73wsSJgqLHN4iOF1PbNHXYoH0 b+XQXZOhb/eiRmbxD/RnKhY27dcNZFObJddWHF9hEUQHjpygwyLUocLeMmDROrdFTLa2YUy2dtC7 wRReUH1ZwlBoOX4oRAt/8M0EnuRgm0gMT8TW/njJWtCzKmQ+cKKTnPDYtLFbb2lqgGX6yb9yxsjE UUa7mXSlrpQbaCyFkOREHqf/vPvQKUjU9I6qgeGvebCAQXhwzAmmmmUFsnfzS3vWydSSF1oOH7lp K0e1jsLhDfGxpny4usJFwm1Acq3RWps8emeuGRluBS5LIehLA/wCrUw2YjbfVRGRplO6zMSHmzh3 vs5kNLRAjIMjO7gyp6XRifb2ob0nolGeo8+Dh6EdvqlmrbJ75Qwwffc4Mr/jzXpnDvrENKVYUPtG 7+29Cce7RtwTSKfLHbA7ViA7eexft0XDKwc5duWgQyJkq5Mvvf/4b5LeBN2dNfUpOXBC345Etg0m SrjisR8ykU1yMmy51AseUGau1orNuPPEVyPzU4CQ0vOfIdYbPltF6B0T/IwwYXm0cdpTJzGyLXei RV7s8cTTJ3nzdhSKnmLIRPVFphRGuWHvdzYzETeNHLrdronZK0yFGQPV+56+Pq5l/U63sDaKo5ZV yJDOfkw4+FNQbPTHfGsHrtBkkJYVN0FLG61VWWKRv/DdIO0X0rAZyaJwFM2i7354RBpdHDTBZY6j zs4snvxGuh2+QFKED2fLVxZvf/U2R4gII79hoL/49z9rxeKREiKRjvvCZETjqaDo/HCyQ9EpdGLW EpeXC+tUDvZFn7nDQA+dHSVkWCsKOXxtPb3bwvo2CGvyXud7x/H1/peIdSQ9Y9lGlpQ8l4Um1Kfl t0ecC7kIKGzfCw0zEozMw2W2Jn9q2RMY7q7WQ/J5Jjy+F7bzDvRbqgUrUvsNhM/t9Ch0ET/rl9ob pcsIJEn91ShOzZw3WJ0DIB5wzwgQN0NtB6oJ2O6Lg9J3XtNPJfOY1s6Ovo7NqTMIlhS4UGt5GkK8 R6s8HfgNVvkbmi+DjbhxlxwrsBA/x8EH1w5nOhjYkhaiP4MdnD8ZRLBQ0fx+buzRflUzbUuFCXsx aTv7EGAD23VgvMmfQ+axvDOF+vYoaPc86b/vYKLzPX9qSsx/c9MSR4KLY5rALOn1ISh0sv/Pzfrp 5e/pSN6u5p0rzvjsdy9i21zyl4v+DMiBm1YbnI19hfhoN5erAt2Tb8jfo1eDD+hwqdGfWya54zfF brwSQantZ2JbF4FOLy4/tg1PqaW2mk4wS/5CB3W+KpL7erycQSGw3h8/PqksWYNdxlyEbRS7hTub Xq2lVquaChC+v54P4K/uviFD+IeX9r1NLm/5gnu6tv1rKgTAa77lFG/yQjmhowgMm1Dy7VUDgy5c 8dKzmwyyXwJrPsCs/pwMXom63x1W672HIGkIk3RZeKr/OuYJjCvN6yoTMiZnJnNCfV36/nn8oc5l LSt4WxijyaLOg+zUSQNGrLET9Srgouap49rIi+xqKdMeLWH9wkXGhhqfx1Hasd8qPz8xeDj63mto 16PBm4L9VPx9yLYwzlPdNBlXFMhb5zjk4o1V6JFrXdtLQUP0p8ws5eaQu4eUaLzX125RtKYzETMv xVfU5C65IMdwlVP1264Q43l2dnF+siVhbgMraYxFYzNRdoNcXtIq1id07e91ESfFCH1/MYW3T+57 Nh4hXSqwnSxhR5oqiDPhC7ZQWrSGES5W7ncwiRxn6VxWt4sbmxzgr/3JYowlDthG6Ka87cbOxp8v pregZ9xPFutZUSQnyKrjP3/iXbD38RVpZtM3nXPRcRJdLRzhPVI6GS87dTEi4IOQu0LTHBVIMwQs IqGRqJrOJRt2zWyt7O8tC6dQpodttq2uNyJ1yRLp++ZXPxmuLcQe5jo92hFsXzsvBxVCu0g/bBWJ ZN8P9ovzo9upPV9TumBBXKpXCCFB+93OGD0ICMamgoyn6xi42pmQv9Wu+FVuvtUC7DYt2t+fQmqN WJ9o015ftkztUc9Hyx2ofRvgJzuOyDKs2r/DIhRA6I+e4vWTMDin+AtP/CxDZKDe0KRLLwqa8QKM 0Xy44hujNn0yV55y4X/loHV8zaxqerJ5bP9gpuQT+VOHLNLNoj3qzcG+9jVlI4VTcnOQ5RPj1yEB dbXyWlVj55aQR99XJkwbYS+KeEsB/L17bVjRoMFGKwSjt+ds7v0hUxqSJngkBax4dvQG66rhgg4t 5xfUg03vjZKJgIbAWSTzwwDVYtHzSZFERD2fjA+Xgt7rj+9MwPJkOnIdW6J/BK+a0oMa8DsHX91e vzy6+PnIIFrzR/xVItpUMRf2aGhkL9QhGWTCPF6Uvq0k+j2GsGVofXm1tLjdYT9O3ZeH/wT64LuM SknUtkzB3bgaFsuUG0ZagsKvC97+2JzzuHeVGL8Jmr3pO6rUm7kKFHr/WcCEookroZXHfqkInlmz Ug+6CIdKZRfuE9qv0lLo8fFxtPvztguQhYUF6VK7T52QasgnBh78OEoxCrg9OHhoKysr2pLXm0tB n90JW/TZqppPdgYXIitXFWHjmnYUdtlCQ/XuqmHzWdYNCKHhWN4XiWWGQllPGE2Gq0siSLxexQ2N 7j8qkG3RoXGuyeez8tEn+brRmeApVsJVKhDVWRoGKxQrTct5yBoGDSprmNyKK+ZI7BoGi4vMXnaK q0IIkQWSlq22ZgjqO5OopwSmvfJVQUgPSt+okgdhDMt5uyJs5x1ray36Y88wOnzsXIxKd1HVV9Z8 oHGcVq5lHGgYkIVPxYNKBrgz3/Pvmn6kxz33rPgcsrw4AONZE6wxYKyY3XbHil9vq50jKZ1oBZ3e JWnDO5K2zje9UGRsb9ZkGSpFxeLq8XP4MzQ93qmA0ofi8SxygtlT/FeyTfxXL/Jc61h7p1HRjVX7 j5XHz5UDh4PFy8p9SXKHmB/Ubf3YqlWCv0vxjWhdP6SEUAa5NT02SoU3gw1nG7l6k/x6dwLaBIN0 DlSwPF7NcydzgouMzCRjHxnCZYwbjO2cjFj4L1ZPa82QEXn1losVOulyTxdWCAUqG7THD5sWXuvB C0UfXTf6ohtZmAl08FErYuF5B2DYfLfwUe8HYFp1TFabMjbL1jUiHwnhRJzEGs7VcPAYhQOjDsA9 pu5i7HGEMpJfclR/R16P9lorUFu927VEEWizJHJqq6DZL6ugf6xJ2zrTTrnqs+6UUGbebbRAacmV cKz+hornGqn1Za1G6vwTi7NysYLA3ys2rx2C2SoTuY1b5l/qnTq8IxSnnTLyHToGRvfhSZluEWtx sF47z46DPXVcUXVcv4VcKleiVBxV3WZ6GXNy5stENuQEmmy/6yzHSJXCdOV8CmGM5OK2clUOT/ht COYW8dSfoog8c4y1sXXgtUs4ibQczvGg/VBycWmQ7SBq6dA4sGI/KoJRuTLr9cuqcoX2xsqWDr4R HrvR6fc+uoerDu6c/eISFgsjQQWD9r0G87Mu87PZDayCoah4/H1vJlfPCFuo3Ed5JlcPgZFsLny2 xASSWtO/4VoOf2HnMq1uUk0Ch7MhTowT8gZZOjnNzDUSDCK0QulLLCdJuoqeP89i4B8g9e0ykh11 EweVdaojcTdGQTa+WwdJHmVh6QvnpITuPnedFpEE4N10z40OsJf48EvfqMJCevBM0h/6dIWqdGEW 04WYU1bMC5fVuox98tW28TRj35gNMMb6Up6YRROi4ZnVugg9k8iequ+ImnuN+yKvPmM1qmRxdYPX O4LmR3zUtRj4AOuHAYyvN9/2PJJCV8aN471ldwIJQJ0+ase6zebOhpKXrd8eb0wIH/++663yb7w3 odbPUSVirbVCROZfkB2vTDBqAIvaCpwzqTBtMa5mR55bYDbl6krmfpmsF2pUf39ju3A9l/YVXckQ OTaAQWAtYOwGeudjW/Hw5Ft9lwoZUinB4sl9Ci+9V0Rybp+Ubpa9S4rCHNhXqubghbKAZBc9v1Er cEG2sjJhRYdyD+NP6qdAy2X/X8cZQaqco+ts3oo1VHSrQinWEDB6glyM/fyEoGyl3dLs1KW/mcZi Ip8/A7y8logn5srGa1StdY19hBNdd9p3DGMrTroZ4eFNuqeNJUgzy006YoWxHtPV+InrRG7z8PzC n/AsY4RdVqHAs8jltS2+DI648bDQdojdEdf2vRqpuuij+HACg+hH5cOhIG70Ykz8XndfVZc4Uu11 i6CzSO6e9e8n/kWES1uIgSd3WucQ99+PELuKEEOfy7nMwxCzjmJfbzK7Dohk53uHYG+BaxmJDqEy YT4/U7AnDEeDye2ZnVhFxsW9pXbecfca7KwWB8lFGSr2K+82fre0K1twUFDFLm+BpS8RG2GKwldM I87BrpuCCMFzh/MKKxrmO8wMHkVkjbeCc7q+dGgVYi83td2IlK2JwN7M2isJo5/Oq6qpLyXnAW59 DA7tPvj+x52e9W0vutuaprGXpVOcUM3wcHBScP2IhXD+jLrEYHoof2ERZV5DyHOlZ8v4WHzt3RoI 3CiZQjhT8pDb1JF6xvm+RvnbodDet7bJ9cqdvZAqNsJ9YzWyb8+GPnzzJcNq5FOyw6lYW45lQc5y vLFIwwySBIap6Tcd4Qk4PX61EssGpl+hKhraUykN2JEuL8IaTGZdSlwDJ/fuUr6MtFaOSI6AhykZ 4NL4OU06+3b7oVFxI7rN39cSh/OwKRhkNtNfmXz22NkIrk4rP05pwj+TNv5wqCa433yApdv/AVMu E991V5POblJ0aKp8tCvwO/JxiYv835fb9kVyI3xhhU9ChOZV8Dw7bgcvGF6UvJvi5x5ltUvk+kuX +ebJhfuWCNtb37pybFtnlBasSX/zPvFS/p022DwVIvyYgJOeg7rzCdUksDcnd++29/sJwVHthl/b yMUa8fykx+hnDVeu8s4W6dD10TLh+sUdx4kPBwfmkmVMJWXHa+lWyk44nYwseIKO+OrSATGgt+7e 6cjN5VWOhkNifLxcrBPX6hFT3bHTkTpnj8SPclfa/csJg8aGf2YL2Y7f7bw66Kiu/yoUULKA7VRy acts14SJ4Ot/vZcqZVEjpwA7z81v6xIIVeMKOX4TCswK9N7eDu2bGY9s0Ez1G/+at0o9KazpR7Qm +HwI5p+vcdVxC5JZn5oFnaXedmMqfzxvWk8i8x2RA2FxhYYwKjuPrig32DSHYy0JvHnvhuUoKmny yB5VPL9HJEvMTaX2+hD7zGuQqpr9GBA/cA7un9ZoXNSjmFSEu5CrnuNd9JzXS5OqFs5QgSz/al0G R+kO24txK52uejqW5NzHiIr9dFBfHeNdOMIuyLsSJ3fLJt43zOT2hPr+9ENPu3Jn3nduYutrheFA rqbfEs37VnDjQtL7apEAyMmopaM2i89MHSW60P1c4iShL0qBpEHAsUaYQmeadQmuTxjZLElFy2fi HsEWDnx0Lia8lQZynM5pT11v2XudX7awboTrt6ekWCRgrhJOK+VgMUK0g0HX5JbMNVLoLoQUFxWX nrs1GUchPsMk5mUq4rWDrUgq3qAyZ7B9zqmhbull82US1mlqAINZuH8X7orS/N58Sblmw3xT2RAj A8OEikGetSf3Dw4wU6v15w3EuvS5kQHOeve7OYonV53Ou4TEa3C5mNzjK83D38A/GsOiZwHMo/Fi TwQHF12+QfguTjw+F33+Rcdme4F78nsh1wGidubf61GvfVOMCWee2rvSK1vcfork5CpqnKyGKsik GNi2bSBQNF4JjRHJDiY8FP/aBYdCqyiMYb7FL5eM5xpPC/Bv5HVuOm7O8dxHIATX1yyrbiCWsjbs BzRY1ujRyio2GFQOa9jp8NVfJ/riy9L0eF6oHddhgGxXHZrRZsvi8fX4PM3E03lzZrUrkUG2GNE8 5aqO9V/Ifu7oCS7weOxV0hE9/B5sZFwX+djWMqOydPKB22bTj/MWdfig4jiR4GE+Ucgs4E6uk6Mg NKz5lyJdJl1TS1OeQ3iu3vQLJPbhF2uB1gXduzZB+UJ28Smz0nfp3SChxuzgtpQNNx96q03la4hG LlJ0EqVvv2WhJNZLj8LhT5ONZiPzliXKOLNPIu+DpsjrkqNvECcZHiYvJ6Gx3VgJTxhEwRbP4r4j 7TavoLuCs/GfMzYJZs/Tea4SErCTLdGv02mZQj2U4TBB3f0Fuf1o9SXNWbu0JOsqdDfYX8IaPkfL ClRrlo+VoPwovzX07PgLV72qwneTLbS5IV9Mvke5h5gEhgJ5zwXy+r/q9BnLM/02dthkO9CtCsc6 om5KBa9ImIrijBEz6s2hFw8ce3FkJtK2q2upXwcTQ6NPpvN5iMfmmouQ9SYgj6hvOhGKSGhoJeC9 aTG0ojrkcJPEMG89usLqWqsvcKGd6mlCxaaJmWrBEoevSUTQceO22KwNrM2vna2hnM9w7ZdPp5kJ zIYxjNqP3C4PR4/VxFEmD7gspnG2Ruu+WWBLRv2VXSKVPbLKKzgHuTnlL6gyvb1APFk3V8j2kSsv hEN0Jml1f8f4L8wNkCrT5ax1qA75890tqo0uObvuHGgNh9Zv4+EcQXqG6crGG7ZbUMpMdJsFOHmS fuiY8etPZW9qYvmi2oAYeuUc9ZrkMxIZb/XuINGWWpKEJ7V0vHPtEFJXE3w6HXYYiWNFMT9e6U+9 1I1D1KRj+J9A78txmKTuKMgdU8DuedzLKt0xlj2scGg4vw5ruHNAfrW1X8O8cvQafPoSlV5OPePR ahC08L+pwsfBgvRkLqpAV0aRVYkiZ1lD/oZNhlEWKiD4/B9XDHxW0HJSfuOJyMHEUZBlm98Ermsh jEjQO+wJkfm28WylMOM2QZafZObQbGof4hhptlaN5zDPuqoQInzgOlhJLhiyEPLMoYpUC6X85irG mqTVbqSIqURWC7hs8q33haeFQVGrxxbJdebnalyPD/3Yn0t/aT7J49sufNKPh4VbgOQ5R0Zt7LVE glxglQU0V3Dy9JkwtgsSw+tKljQ1SlTb795tl4Syx9ItlXU0mKFZ4d9SQErJ4dTrdw+0VVkOsycp SGfWiEdDY09HK6cxfpXa7fKoZ5G7+3xLfYmfIs13MGKH2VX+sY3XQ+DbdVYkngpxEarSFebwo5ru ULPCZJgWNKE/4WodeLVlpyZi/vhNE4Y9pBHZJalzgLDDp5vZuaKFascz034kY7RWFDuoZJtAsCku T//LijpoXJmF0nW4urQ8CD7RmSwQTJufRJEbwJ7/xciVZjt4qAZlKOtUXN+sZKnBR9RTHTrmBjf4 pz3HHUolla3P8CtX4c8PInJfhMYoPskEieQPiJ6W9JdMGKZulbaPhKmqOmftbs8MvSMnzZ3F8A4g 5lZ9mDs7CsdE6Ek55DG/as8NSGCKQEnCcRKxqzHWZk/teicKk6WRif1tcsV4u9la49nsaej5MboL cjaF/EFQcNmvtqO7DVrDH6/zfKe5SUp9mn7UerLii5QygiJDcgtN2vu71o7UHdQdfriD1KY88kvf H3NFWi3aPmU8YWXn/L3mmmVN3LaijDswUG5jTG7ew+ShFteal4c4359pkyaXK1dSO61qyx8cR1GZ yXCr1Da/PGEUJW2tHe7OgrQzhRg2LmLxd5G5UOHFyw4f19YUfOfJh4SJBC2DpoctsObwUqdV0sgv aZrEzFrScgyRnxdER4zNVRwrKLNqK32VXosNJ6hDsmMiwGPpVlKg2OUf+wXw3xpIF1Kmz3mF+IMO SoL3lWOTj7Qnf/FYd0xKtjlc9iNi3a1qEPpTS5FSIVDeBfivfXnwhCRBzKF+VJXABqP71A3JMWCL X6+q6LKSZ9A8B8WHNLFC/dZFh77H/vHKRf4bdlyyWoysekEqtAbq1KWNHSEvB2XJWTCz6RT33bPF +ymbohWItYU+WjsHvjCdGfUSjHGkm57gNzHBs3IxKVDnF8LVS3/OnDhMZKy/Uq6C2HenuqVeLPMZ fs0zrpBHsjGRKF/lOqIxkQxfz4vEuSyLbD4P0/3lDzYyc2GZVgjiaXU6tkqderOiU2nHpKG84TwZ sTEfh/cs4+aamdveqwnGfVcxVhcIFC2C86sYPSGbfWL5nR402OWnSIVlhLufGDbEueaXwFbVL6Wl EPgXn4bzBCqfz31a7nRbSqixLVhoxQyTrKc1SGJ7aSbfqjbP7zNXYx+dL7plbdTxcdHrDxGPkqdx xqgCz9ZYc7BO0+bsb8u4xPFn0m7WTHUXgoFIanUh+lYj9/mOtVzxnIh3SppnmDlmnoPzfuMWcRUE k0S6rKWpOAm8uKNMLvxYCa7oBkycNStt9pv6C7CSjmLri3N/Pd+Vulart5DKK+3BSyoWap23qLqr qtjqnkfNsQSqZ8j+xZ0sxy4Jlp8FWYq5RMgi/eTeBMnXS03aEBSZI1FmtNwl6PFgPbyTsj3LaoR8 jsj8mcw+5pafZNravH96UCggd2tO5JAs4D0CM+YWcbSwx75uK8OJlYIG16CowjfLSST82b23iixa +d7g1x+90DaSj0inVIiHdGIcaPnQlBx0nJTnthEz7IoJlml7JBE7nGTFJvh9x+rQSiJW8ExMn7Uk 66ryQn1+WOPDoqbRsu3h0YiO4zKBpkcCqIIwf1Fhwvj0iIJ3mHTdYzTdKTjh0ZbhY64zENQLYJgd QzjPnx7e9cNOwaNcWyZHwys6ip/b12JdviqX1kZ/apaBfpu4/ZEKIR1s+Jwx9cCLbKmxQuAVlLdR VYSThJvAQUzA4YN6csOZYYDtjYmNPKAIgW9Ls9wt5oAP23T67ltnLT+xGxjF/SqgL7aQx1XrgTVK xuFnVRhSSSqtNhYyUbRq9klSVpOwGoxeJ2PvsF2yIPfX/ix2WVAc3hjcQExvJau+z0qun9W6kQCF Br2rznK6wu7QVJvAWpMi7PUkzky8vPaQc9wiLdBv5Ik5Mhx4zaVGCw8OPiSNum/Tm9ycBxMEOr7C T5dZwCpuYMafxv9uMzgwgB/Ggrarh5r4KBGeoKMf4r8tbohDtzw/ZcvPzayv4sbbkuXg6vyLqpai PJjGjlRFfEPekTY485wFvY7lpXNbf1EADXT6KhIQLapiuF13MRPPfUunCXvfAjpQgx5f6lQhG9Ws r2uzgt81cGXf3Dg0cSyNcfZ0mt/3Mo2n+gt13U1EONzxvv4iCY3+Ziv66Qzu1U2bf9VOFj0NtdwE NWPPcA92i5dOCWopYvixmG1Ww1aVfT28flj2goUAXjTV3VfyvPu9BB4NGBnV8z4Oo0RgP6QHI6Wg XwVGEq6u9zN9D/UNmYyFghaajCB8sv9SfqekZGXjDFw+ycGpaDLBOMqaDOLs6iEzRZvK0V+FYsYZ 5g3s1tfpoJ/ax+tcUnJVY98QQiO3dcAGJfgvshwyHTQkr9gjkbcj9jZ6Ulaq+e7P3kfchTLpTBbq FdqcqEUaBY0fE40EsDLrtVe43NrwTlJ9de92K3KQCrV3ogJ33G3KPU+IlLfIC+WJw8I6aExhuAw+ jHl1ODOr0bAeEY1/rQwQ/fyMyeLTILVLRd2M398Tx7RKksuPETHYR8wj2OWpH69TwwITWL0nn6yr X0R6SLKwa5EKJpDzuOLOxLLKpPePLOEkFEMp3iBTLh8r2Dm7Zmg/ac7Li0SIsCBQqavd2FPyyCLc pm6FqmKupbDDKxOlOaoqcVxdz/a55/e+26FrfjUUUvJwSRMgKjeh9/MPVXF2kHaqigzOZFdAOSlM L4B8knKtv02QhClgUt7KJmkzmEx++R+8t/c723/0N95SI1asGo2REFRRpWrvmdRqbbVajb0q9qqi RswkNkWL1lu1qL1VUbFbtapGEdQm9r5f38/1ve7ruu8/4P7hXLnyPOf1ch7P83g8TnxsXwpsf684 5nUv96h8JnCVSZKsablaPPp17orZwMyP0QOelluhGVcMS9UUNyRxe4ZiyFrI/NAXA4ye68aHyIHk 4IoAsYNXq6YmAl2uzm5DngVmYldGxpmp/4yxjNeL3AWKBdpFB49OJ2hHq5K5QPu0BuNdvyN7PQ1G jjm3UqfU9HsQ4zuBfPt5JcQ4jJNL8rdE60HUh5oSM3Fucf6VpWJd8n/icR7Uj2tM79mAxFSvXYi6 mz1lHczWyVweOswyfGSeNtgXsyIKv/wwerR0aLnaOqIgFs1+XSnB6HhXyhrZLkIzDMcrOb5Rx3vb GExTFSxPe8WGtdk+Ajk1DO/wYKWgq/E6LqY52/sV7BbvEZTaX+X22M83NWQLIwlvdhi2vcuk7w/5 pFhKUoXat/WXhJD0LoOPOh3t2IRCpu1CunW55lp/WgUn17rVURlpiVrcoP94G7Q1Od5EqpQz0jLO aaJhJ8D2H97V24vuOAjLVbAk25sh0fOCHL0md5hmPorNLJ2V99cN/adAFTnrtTaCuBS8depO5g2y Xorus0xOVyHdnvlDjp/HP6/87jA1yxsapPWC6D0iMT2w8fLtNgkF9oGk1NT2syhLtwfri7/8EVPf d/vlG9p2Rn8+of/MVc5Csn53QnjDT+5fM3xH23B0u9d78b9EpIpEXn1BDufo8HUPujcEHUg1VRjd gtP63htqDhfaa+geQ77raMKKZ2I0/Tv/a10C2aZie7hvZAJsKjIcHiGdjYccFv/d0LCEsvFo5u6e bS67Jn1+qXJXB0ICj+a41zqCZj9lOn580OHBTfCu81V1ZGws2/5wMy3tuk2B5suRw1Qi2pgdphnj XjqeWFRW9Hba8qrdWreQknFu+eE7STpGHgJ5qow8kcxYwLlsWN1muKc7t81r/kol5PHNEbViBpCY hgedwINR6UOh3v6pLJ/y539BJlYleU+iXJur3ejSwnkp3UdzqFEyMvI75pUt5m2MFz/tRC/GoFqT e1DKIZ1NDvqdTGkuH/LuaVUJia/7m0nRgiH/6LXbvetOBjvDdUR2r0DJIRzkKY0cl1dQA97UWPuh triOZ4vkmt9cB51ksqyG4/pd6WMX6nytjdzy93wK/2rBa/PGcgr4lRpYGt+mPPFZe2ZA19JF/jTp yS8WlVSOeFGSSEnBtdtPNBGjOXLgR1W8d9pVP2ez0haO3VIQ+O9sMjHal2xdrG8rJbcMXLHXmnIz caqMFyHS2GqbSGfqxnrEoxQ+/s6D6u0kzXEuDGcTFuWy4TmRk7rYsHvtqZiKUcVSPacydVsKEVoa LyVS5/jlqBLSXL3D3mGX+Q7572wh6q1p557bzq3xU/M1TEhK5eiwEBGf2a9mbw1ORKFwtntHoUyC 9xCXfKHTUtpfl4VoOmYsrESQeEbkyxj3a6OPvvbHfoK9pPzdPpfxUfVj+xxbX7lpsxlKxGOrZWm8 GKeIbl5p+Aoaxxek/8yQygULqykVLztaklj5iIW+Dr4vZGCHT6ODK6vKr7u0q9f4/JVlS3AffLyc OeeT/xnywqW+4jLXdmmmXydsAmwNbd96aX5aXV/gZPX1VJn+bbSRUXIQ01YSa8l8o4DdjFf8RZs6 vFOrLm4nPSoZW5k9GPVILq64wCrS82uFzkOuTYqPPx2vXZu5JdFg8NXpSZ6VUs2jmnljQfNdvnse gZ/n01zm3tarSxlv/IInCJR17s6bhx6MbOLj1R6XLwS1GQX1Ib0/lMkuhiJoeu4e3qo/CK8NEH/6 eAwE+Xrl1HBn8tWCAz3FTSa/LkipcO8LY3OmdF325xosN+M1r79npbgpLiyS4fxSy167yU3wicVy kpSZzH0JAQ+PNCOSdDGV5k7k0NHlyitS3eb77RP/s7uDey0pp4sDA8+WlXyGOIflwsNaL9G10+gj 91pqKzB/W0UeL8ev0yNY1EQFQ8C3gj/WEwxX7n1x3f3aFEncbJO9vUsGTz3fus3RUbH3eCuQ2Sgo NNbwCNU1lm+s31SA+mtuHE9WB0xQxk+rtre5ka9MDZmcn65QDpkkjplCCut7PN2W/64dWSx054wf OtYO//f2n3fEItnwzBM7uXL0NG1R7DP1Db+2jfvKoaUrS2sO7zen23ZlA9bH0T3+hvq2jeHqBf4F 8naVmxmKD2BSblNb73k+1w8pXo6p17MLZUxiSj6E4Ud9SMaTpiofZBuGTCR1kjGclpElutRKa8Hz 2v+Uzkbx5gxHc0y+I8xPz4l/056vk4Ra1k9+1ix575XkCl0Iv/VIGZOTEKt++OdASlnG8enZ+yIF r86i21tMpr0SYjKbOZKFY6sR8c67D8O7dbllivbodOqz4w3nagbL7ypYJWZDWF0vmrS4A6R7j2d9 V+hav1SefDqR+LxYJ8BpvuLe15hlnWt2ttCN6la2szByHAxwbX36+PKTD0+63K/MQMHXMZ+s7q9n n68Gid+IlW1wZHgzn+napzJ++OcHrcxD40JbbjbZnlroB4fgHrKSDB+PEDb4Df31mmWLy8bznPPk x95i4woN0lbWf/+uyY8JGdxg12Y3EAtdVZo4Kd/Le8KQHW6gEvRoLm36a3XAFy27xIslt+vN/v7K E0pv/wU0RhzT9Uw5Euis2lfZPW84QiYot6itWf/MGW5QTzOePdztmKx4XtE13qOcBldMPRWIhq9K LqQ6CjkIfdZljvVhgB+ItWJ97/e2jyp1ymg8cNREdTlYy77wyR1W1P2h3O0s5d/+SfwOnWyD4uJg 4rfEC846Icm2gpI961RGVOYv6ZKQZA78ffmSpsDv8cNsYv0SmbOEn9zC9S4F5o5TZ2gCpAQtWYEp dLg8mT/xm8Dv8dZ96gVXxtmcBEU3ixWwrtHM0LTSUt2MB4uGV4WaZVkeuz6TuSg6fRzs3VRZ9Sjc Xuftc++zBXOV7wWXvGde4D+cadw10i9yy7ybs55sbI+7t88dgj6nKkpvPNgiTNfWH3RXHbWW0zdI L1S5uezzHjodiLaGOk/KNM8h93ZbzR+TOpuKGRYWGsXutxFc3lG2sDZ591EfPdMINqEK5PAMlzCV +GeI2TsbDuXaljdd9f3eMLON+9E+GvA73Ducd91pfCbn5OMB//oj068LsxGzPLPPi5b9B69Ct1cf dPd28DZPdaVxF8Tf3Ms11uYqvw2aPO8Z3zZclb5I/WSZsdGW8nHPc4Z+Jy/QiGnmoKdkhbL8RXNO LLNjndQtpyO7w/+CvfRVBMSfur261LUpWV3ZSD5slf6bey237LoFf9uJaUVF8uacrTKhTHJxdj+l PEnJp69h8UkjycOueXuPJmC8ZICONCY9JxbbRnsvWHH9yHL+4+P311c02qRi2QJoOM4JX/DDm1Nz OxMFceCWzF9kChFo3h9vwxV/d9pjwG9eTpWFpUsYe02NXX4XvLh/utq3HKYLLi7WDJNbNvm0J/L8 I+vMXmHS5fHA4doNw7Fxwa9Du+pUzYkGYv3BF0ulj3BzonIrhNspEbRi8wel/vftdUQTbbib91V7 dCf+mIudwoZ0RGWfHk3uFobpHmSWN38XMyH/PnridfUsFlYOndrLUbxRkXfwr+pLL7kNZFjSU7Fv 8sHUEbo2yU+FM1ft5+ctL4dnB5iUKzq9OeQKVNMpiObyQh9WUjC99rHOk2qmDWcLKe/a2uK7YQbr CCjbqx7nSN+monH3BjX2CphXqSizVO2qPuRnjmy22yjk3jhlgdwJ395C0xYaKTeb/xKjDkrJ4tWf OT7rX0xsWfuWXsf92iK6dh20ywkvf1pc1Zjgb1v1Mzij/T5PbWam/9irL+M+5wlQzNH7XbaZ+l0F hQLdCavm5wIeVU83705s019BpD5UP4+r97T3fYteDfYzrZm1B9VbnVhXe237ZpYdDyXHF7q5Xdwd 9i9/GbQnYmq3KRde7QSxqVFzWm9wqFPu7O1sG1muzuRW8NwZT1p/f1zTZp1UG5VXHjsTx1OXshrW lXr62qzW9HsNw58DkQPIvtbptme79+Vy4Q/pJu/6g+TWP0fS+2wBJVljvfGKyB584gwRw/c4LSTe WWIzQx6ZJtSrcSa65oxjdKlKm7CinLRm+OdhXnJDb8fY12Dy8U+t23W28aGMjfW8wqLiz3pOLXHw 2YdSlk/WWvfJ97Mnn9ZNCst3d9g6lcjStagcsPDxq+mxGGtZ2wxaCQvqKoSBLxqt0GiJysY3t0fl 7Tjp9xyqsqz38w7sezf6x7KTncTHLVif0TGx2XgNEKJOAqkCnlz6viBypHYj5673Rwwurc2A5ez/ ICZty8eDbh9+08aY8OgpmlnsnFk6waU2Mm55VNV00EaHvD+Rr1NrjabNoM3zfKVfo79oo91/dW2v SymWNqFlSk1xy+5BL8ql4qqtzkJoPHOuVIV1G/2FUkSMOz70o/UK6gs7g7yCTt7nwJ0BGJ/GbMiH wA5Uaf2lZ7T8l82h2n1jUBgxj1uMPqCuBw38z6/xWdx3Rpdvl8qPj235o4tgQm5by0tMa6VSyJZZ G2O++ce0ZTaFvLyk1qQk+vwdqvUZE9Ni6oQWwShFwSnJm0f6XQo3N4M0kqqZhP3WNFPfLwbUJ7Hc mI3S8Vvxkp+UnQqR61vhKidoQD7TZ8c8dC+4PTd9/6hvxeLj/W35vnr1XVa+zh7jklb2JK8Y6YqM QMUVvfMPYSw1RtRWXkrj7+SfrWxPyv52ZhJxcnPNiw+Y0jVI/31zO3/zx5mxJiYxe7weNKys3mbt OPYvKakyBhljVVBmzbPJGaAb1iufSvITLij6dzmvpx3HwLI+akl2/zZvowDbI68L/qaYE0h5q+Xu uAbSKUd0dVymLDQ5y9lsGyWtXKMlpbgfJdkXy8DCQyL0H8uP2XuP8W4Wsn/TujyVfzepfHwQm4AO Ond3zTuNDBRQGzrJDskf73XXTG2kzohOjd0UpO7vink+U1/iMtjZ/C5e/qesCtvPeyr6bCPz4D4F OrEdRAZVmWt0gbHySvmdmhC3irQUp09bFWyf50n6iDQdoavpIW2Q7qLEacm9xYBRqYRbsFm9pmi2 om9OW2InHU0oK/aN5nEBKyev5ysRJ/UddASlu5kFsl8uvbYxefiCrWymvsPyqVMo4c4qdqp8qqRW 8AGjuNdmlo8+84rO7faD8fLLQiQFKr/e36BCUIKWLy2gtVak29mIUm5dzK5QG2TF8c5384ONhHYq M8JdZjNYMufYSeu2W5OLOf5nMTW6MNf/bqpgjBZTfGqKv3a8IAX2pfLUl9WcBvHkR4WhNSJzznha 5N7PcssizB6e2gEyI0KLfvOhNFbWb6I8pwi5NkL93uvow7AtKKiq2T8dor9gm/xo9l+5Da0OCwtR fCb3cutxP1+amdItu4LvB9sRiNyBhaCpudjnIEQlj/7dLnrRKAtD7fnOB8+r/KXqkeksg9Z/+oOz 82NARAkyTlI1nauRl2/dwotzBf7u09851iUZ/XVClpWo2qxAnbF8V4vpH72Xu6eTVH44iAYpDSfF 5BZ2Hr7sX9RqWT7v5GJ3T+Uu+EP7+2ALcJXn+eG/iT/iYdX5qZeRv9xjj6MWdzIarSCRreGNh+kr oOg5o/7PPT0TpcfekPWUpXDOge47TM0vClP4mmG8WjxqRWFFTmK2VaGvkSSWwcIp55UBQrW10Scn CIFqJHuM0eQHfvrFRmtULTspxOQcrp7vmmavlMBnWZNlYj7oI9oege2PfnNrWJA38K50n+Ai6Av+ EX5XFux44Nn5SflOmvJR+KP7ZYH57zOxdlEFgyDnQCm79ZRvxNPnOX7vsuH2S3QDTUXBT0ZTdl1C m2mGf5D5hhuQLy1HvrlC6G3CZJiEriQ3x4fq8pyVOu1HxCXI22dftl6otPaaztiFrQUd20NcflSU Ndl5tZ9verH7QsdRL6/2g8VVCWeKp9vitdOp2ZLHHXKVJLa3v/i80IZFqHnZ7om3eT63XNNPA7Tv RNHTOxU/6fZYRDgUq51puzWY9r2osGjKvP5L0fDX6xoGM0n6KdtHUU9zAuimTpKmWu3ZONPBdFMB jhFmmKhQTeaokM0PJ8guqYJfUqVYI7wvAYQXJQjj3Qky8EYsGq9ICMKTEbTwYoz3kb35iKUcteZv SYfN7M9urdjql/wm94YJRzTguCJq+IWjGlKzoPnwm4zi+IdxYCR9l6oReFXDvnnyv2OcrAYlrkHt HDkN02YWR1BjrktGdoGZtRfAnLrMZBg+UJQikpkCA8NE6EExUV04uPoC0giGga9iV+GWWBOgmwSg G1+8IkIQeR2egKJFCSOZ4Lln5Ja9FxFEdDjUrVEFq7gFRikdURl9vYg4jzgj//3tIsJ98VJU4o7W NC/BAEiCj6hIIKAASJxnn5HLAZ9ci5eqfQ0q2IpGFUYWIC0GpDsuIqwXLlXvAEfpZ+Sl85eqnsBf OJjmjTuvKkWGQ+vgVtBkuBajE16JkR3PHAfpZUIo4CXjFDAgoOvru3ylr4+xo6p08AOsMrxOd/dE Y4GOU3OBclfIO5YD2QKFwSkJ1MwqCA6MCkoUSQ2Ph9OR4EhWeAycUjICzsCsg6fGCCGj4fhijQ+p KDUjZBVMHE9UH0GSoNnTvAi2I6qqtDPy3uVLVTOS4nP9vPU/vhe2EQd/Ke0215Smgn/4exVXzZk3 b9UJ3pzMkN0ss/EzaTaX5in5Zv7n5c8Pwq9Gf/GHzHvnHI2Xz8xU+gH9CndwMWzqh8XcwI3+/R17 4NkkwBLbg3nb0xsJP/SUH6bAarXWlsm5VHVzvPu0/TmMdnpnI2vZ2WvzIQ29lX7gocj+hiDBFE+D eIAUKM5Y4UTnFvOgU7oOHYr4Uqw8qzZUN5DT0EFg9GBcoNoTPAfUA3EO3USew7iR6tA85DfoLPwx lgcuwWiHl0Wo4DUJ1/AmhKcAEx/hRRGMSGkUB/IuCo7kgb8pvsasVkVBkkUyoRR7efZPspX1612O nua4SOmD4NlEahQbkhMljQFJphSTVb0qZq7KKqasSizmqYrs8s9+HJQOobDsTIpsGUqK/LSorSb9 oggKaXyMHZy+TTDzZCWGAaHhyYpil6GpSoFQyH1NiuQiaqsx+BRBdYCyRaAMCZRIydCgM4B0T1Kk 9V9ttXLgLeYA+1y3wMUZZ+SNgxcR0wCpfMNKVRhD8LcQPvhggga8rn8Xqb5A56KxQOliuMCwilig WNWzfxWYeqwWjD3WCAVu4gLxDUqOKIRGIe2hGsgFqBocg30GL8XiABW8AG7iBlKa6I23JgQCmrwP p8A6IetUP2BZ1fL5f5NnaxuRIQXlyLK1jCiz9e0jB/hLX4n+vVRl8wmH9gP0vjld4B56+QLQCfBl AujWD5AEJSAJfoBMgBR+911EtAxfRIQSLiI2AO4feodDqYDSKKDs2RaYePuICv0GUAygtjcA74YA PawAaVogfRNI3wFUA+AeBY7rgZeHAFIp5z2gsjc0IncxMAIHxXUdHh2fw7xjamDeUTWADHzhu5G+ ghKqLchzqBLiHNYGh2Ffwp9hrwNM6IBLYN/BvbFQgAn3ACYg8L4IWSQbPBIOASZ/F6WI5CFyAp5U DcjQGBEPHcZtROjxC0fAU7kiBviEowYEJdSWcSaqbADcBKAbB6BJmq1hmv/H+FX+D/zSVAUq8CGs NNwTewjfwibDbbFDcMo4GQxvMRVGpSsTfmMkBU4n+QpOI5kF2EAaYAOaeGpObTwNJxLPABLqjdTE ojR4hHqjE4V6oxQ1jK4FZQAuSINkIsrhlbAucAEsCs+PtYQ7YH/DBQmKeBoCGQBPAoCXCLhkx4Ul ZpgXOKAHPE4eOEwGMAM+6U68VJUGOGIFdH0EBBgIGwCUMgDqGoAZC2AeAFxy6VI1GSgTOmmdhJS+ 2Zrbv3JAS+hzA0qIhVB8eVFk5poJ9xq5HUfeyxPHggRpGqJvjMQX041kdN0IyiomW1AzAq2qG5Gv agMbAWl/Fv94VX+BbtVwgZITscDAqb5AAYJKqEYCZOgEbKEIoQ59DogBB5BBCGEPNUztUrNHMsNS EUYwY+QIbBgwRTyiCiYMrAQpQAxceDIEZS8bQR3AB9h7FTCoXsC0zYAZVgDhBYz9BMD0BwhBAJfN 1nCZ9nsA2ckrIOKAiwBGxwqgKwDGFwtMdRi4BCOg8AZwAfFAScwZufAKMHSghB3YCfeB4yRA6EPA wIHXBzSoMNIeUdnvUR9QLahWUS1oGpH9BKhYA1CxRkBCjUew9FUg1kS9CVgJTbhRjWD8ZPm3FTDm frEKBoKCYhRQ1Bh2+KuuayDB3Sg6od3YRD5QRCIMFKWJ11TLh2IiFPWZqTACyNd6fMhoPQFkrKIh ngLJ1xtTjAV2AoIE9UHQQDkBLdACbQsAGNFbYHgsMPNugNLfgQDWGRFo3QuIXABdQKNK4/E5cD/K gD8oA1z3BxLdwHMlQMAA2D6AkQH7RQ547g2QbgNK+4BX7wFprS1wF0AHa8DfyoGn/j8RcQNHwB6d pHt7qcqFOFR9g3gIDQaYaAYwsQ5gYifwewCMf4hgB6xQBh+MMGT+M/Y/VrAv5B1FB/eOpYPtRt7A ckA74C+x8/BL7GPACiQAK0DgbxNYACsoAazwC2CFSMAKSwErXEFWQZHw31hWvDXiVvvHM750OfIc z+fmHPxpteQ1u6ZSvZ2tyT9aaaA9iDpgtT8HVvtzRpYAOpJYAJ1RB3eU9UKy2h3gKF2BsnQ+Wc0T 3QM9OHf9JHGHRHwjyB01iW9Q4wJ21RDclpGdmbwrqQs8ktzFu2DATLYLB0UF4jTVQgFOUgKrihev GceLvIP6EYaTCWppVTz+oe18p+I16Uh777L0Z+jSJPxz11XSz5YlSxQJhQqiTOWK1rc1doBLPnTm xyWyTZmafqfe1Pvrra6wJ2vkXFSqSRt06720fDHX5wNhlCKp5seQ7iU3KfGHdl3OKz3WKerC1NfS fRhF8YfJGfKmzkWZvV+clziGh2k9Rk3lvkZyzaglN0twZ0cQJFSMXksv/NZDseEFax6/Iv7HW42T U4esOtyVBPeqSuJOCGSodz/Kyfh1QiwTRZmmnKvE+fuxSwhpUgiKAh/1SdNWzVbLDORR/GWMcIv4 ACVG4iWsEyDqENi2PoobL17zs3dWXRrqxU9BUCBoo1J/aI+d8fP1+AWZO/PDWmPdtWhwHgR/Yti7 JGvj1xuqyprKzFP/kLz8zdgZdciFv3gVWJht6r/OMya578MlCBBJiAhFI5yLRvrud4H5C/h1sOKv pY2eCKPpTpjl7hIbiVP/NdmBgoQRmwNdFdHS9uMumgx5gjoQhag3Wn3R0k3DAeqQ9zuKRhGhKdaq d/kysf2Em12JJnwqUHOcW1y8CYxUU7iOoEeTl2qtYXMJYkRpNFWpzhbfEeN6Ja/F8U3NEgIu4cu5 CBplL3oVF1WYpDdB55IsCxtC0GpBSg0qnPkjCQl0NZpPYJ4It2L6ETaX2HNKlxTFxAZ+bmxyHNUC xlddnt+GUbxYZCHJVyMUu4UAFwvZqwbD2hBexeAR9tXYfZ1zrA6rhyZUbuQvlPgYdU/yxq4Oj0YM 3/V4adILKPPrG/ywOMUkPw4+wyLuiHM2Tkyi+jfsT4SsJCVnQqIGHxYBp8Fo8+jkq+Zr5qt/5zfk lyBsA+9Ls0CRSTIFsWW/7oKRNC+ECSZwHqRqvka+DjOOHeuCwBcm5TwgR2obYU1QgpK0SA1bTVt1 R34frC8K4AKOPYSgucxPi42O9/vL9oUaIINaBt//cCGuZWB1G3cTkVyYNHRAQ7pTRdOrZcbvhp3A 1hIAV+X3ggYRcgnycF7LlJZod9VZbRrGIDKSNoqFREVMITgSbVC0JJ6qm8KadbA/uCMcGMuHoiLB SExVLCccv6M3tA+hIbgwhAQJVMUr9yo0Pg0ars7AF4tV4S+AxeKGcfwEdsLjYla5mFAMl44B1IFg TkASWUkPSOxEKb7Yj9IwJ2w1Qo4kRuJGM8ilmEDR/8ppCVpEZjRnY2QW7iGRingHTY9b6TODjRH8 iikbI0b5/Aj6Wrat9P0q///w02LezVcuZGpIrBKp78eJ2cdO8jPE8Y/8z+TRG/tsBI0425K8ss34 /2vwuKgWlf89+dJUdq4OUoqvWgu2PE5mhH5XrYlfCZsfd301+pivFaeMsCvmHeHd1eBRo4SS49QI RYSnKOqFFMUYi9j6LrGps7Mn3Z+GJMtcHB+calXnuJit5I5ROJoG/SnWrj9pM7MVHrD+NV48237r 4X2CSss9a32DSjSH2zaE+zN7TIJIskmT7a3bT+h+2pQa6T2YYjNfzGB7ufKdqh63QrDzDM2qSuJP SIe6XyPQ9tFvvhf5+v2PRZDLTYWgIDn2dYoBoo7xr1zb8zIvbfide+qNTBUedFrn/QW7K7OJCOnl e3xqf+hGl3e27a5tz13J99EPBg8s6Qw/aA0dvCrOfaPR/pb6/evlFwYYA9sag42W8pjwBMObkOop a9vHXnczEqXc9X2lLdsOfoF/qZS2+1UUer6v/k9S1GzhILP8DCVXUfem97O81/7qQujLi98Bfrkb Mko1yk+dBnQHB9csMv82PalPeODzJ2tso/gpRcJC9u0g+s06xwcXzRPf0iWr14JsvV0tfbvHlhzX pdmqXWniOezMFWDm4hU0Fqtrkr8umnImeKyeX/KUc0K07yh8mcMT0c3ZupWWg4NcJVyT6UR7L7Ok QnI2GV2HBuYobnxXGUnKQ7zatYGJ59N5UHr/ncxYm9m9fyizOUxI/9LInUz/z025Yy2DXo2y4j7e wZ8dZEQzj3uaFDOP52o23Myeix59S1+edPvtO/WJZ24N1qZdncjJ1Be4UcvVXJ5/S+Q0e8wEbHgV MQm3M1tnFiDbAc0nB1w67PugUzzzNAZMO/LtlGUKy7ImV9nDOq9Ocqejqi8g4ZkhSfyOBnq5b95e /KHgzLsnLCcs4PLwY4nfvuw6X47l3kYIrCzl3LnjrKc+hK0x/eOZSGbh2VpCBSmU19/yIKfon0tD renWz98XBKJZyjRzWkgNqVdIatp8y6NXyaqRXYD9Su/dZndfK6PcZl3MnNaWKaF1xvB1XYnIETNx wVvPOYSAFnmiPMvrfnm5Tgy68iMl5igKv3xiZD8y+rpXOL8D2UY5XGkSJB/pV3Gu7ia0vpcQc3Jc qqLQ5Pyrb+LymKr1lEax/PxsNpeXCxeeuReGDnEJqtCo1+0/+l/snPc/m3/479tqdRmlNUKNVq2i 9g7pQlu1qq0tLUpbm9pyt7aiVmrULmrUnkGRooTaNWLHKEEQKxKRcKKf73k8zt9wzrkfj+SXO3lf 9/t6va/ndb1+uZ3H/bKrzZV+vN4ZUoKiIAO8995I7f9IKxY7JI8NGrqhfpNlHZsIC64c72e8g4M2 RSBeFA3ciaD31MSjJGcIcf/oh/NRaibEELxcQQldQnXHrj387i3lWWeeZ4U6VLihsIaYywk8JXCv xLAT/9GKL+kqJzsbFwsvJxsXr5KK3HZL5WUR3sZFnaR0qDNybR1ykuPK8sL/FfoHnDhxIpD2CTrx 3ztY/v/1/9Z14u6p4/d/pDObj6BhRDzVVfLoqDBref9rwWzLU8OhFLnSicpwWLxdXR09wqYt33NE Qr29XSFXJ2PecNRK2NfgqX5AZLZVNstl+IvLlx8/jjCrnJ9XmI5n48hkQ9ucuXPmKBCMb6O24Q+7 1MS197AELp+mSGgdtu0gDYPPODiwYFLLx/C4A/0X4YeZEssLYrUik+tflcyqF+0NXhDZChVS50qc mRkZ95vXPiBDvx4dkiS3pM/lN6Gk4EGFbz16rPnZ5/l5WflZ4vlBT8D5HxwZokJcY+lXpHiFbtM/ Dn7I/zP4cTKDIf/FvFa5ZKbxWDrZ23dv9QSrzrpLXbRtS9/0SabzauGYjZTi2Aj1m9V2kewJwnyQ bPM3lvJ3mnSAhoBJOnXM7HfVxQPLWo4+HMydJGVumumfiJxDzN0xPoWkg4aFZV1KbMW34lvaNs9R 1Cknr7TIkKCbjMZMmGBIsHPLBePz70+/Z4hpvUnCbDqKhI5sCm9yFgfgf3rNuYoECM/6bcK8WTMC j+ggH54YXzziAM69atuI2YKeR1mx1AvaFLLnHHE6u5Mzcav1mQpdnIfk8/0IpC1sbXum7RvzSPXk CNitdW4/JT1OnHeDIHwQjgB54vbBE55vZvoNdv3O52ye0KrZvEyhPLW986NXVjF6D6va8mzhy8P1 NJ8Y16doKab3Sv65Rx581pA7RyN6lgtUhO8M90y/emDm0ap9A/Zovd8zhYyP6V8Ocm8JZ1SB3EJ6 iAdnJKU68o0Wcx8CARK/M95G1nSvFIamC/Cx4ZWJQZkHqzUvtr47w4gVKL6DnPhijAWB9B1VaXmA NSxpE47Kb8SVqmJt1HaXFdHF/v6kp1yHq+n7GOoS0YjaxYfxQVvUNvtIAsIkipr1/XF8+asxpI22 3LBsv9NBenCMKvry5REGFYVrKWJfzuzdX3CLmq59Y07xxhCdmQvt2QUcJkV438svb7XwfW8a4p2w VEP1lU3C9juCYvJ4J1jtD9L8V6jKq/YK/bhCcrMvTF8iaRK8E5aCGakuWHKU1yo+SzAvrvXJiPmk 0O9eOb7k01czAe5Hyc6k0RlkoJ/jh7m2nUf2DoWb96kJRZrNxPxNAZL05yCVVkgAZOeQcmHsBHfL mYTy8wr32BwCSsp7cSZ0ky/PrgWbFgT5utyjWwucnjlcC2gqZ055AQEz9hcc/rzjzc7kcwDjzAjC zp1rPCHZqj1wSmsuf1Om8RRq9pl3r6olas7Du21JWQ8TjJi1G6AXnuufk5x19D57yAowrbtcOLww U+Oz1Ng1Y5+HJPCGVW16bRI3eRuZj04gPzApnT06xzcGxgY2bB4KkwTftZ4h2ZHY/M/xtSB/ln29 2DB3ffe2pHlgt8sZchZfaat8HZPirNBU4EnOpzNSlLsviWlh7RnvmaoyL78JW3x3qHorQ8GdJaHm 9RZ6WGAYN4oRjkozao7R1B1z60OCf9hNnVI/7HrZrR3B1cypj3YxuT2FXQMbW1zOC4zznedYxUJW NNQ8P/W66+Tyqgr3cwJpWGwizONRhjWJ8AD2uM+dfJT+BevjaIRtWNVkPLqcaSdmiE5c9R1WxY4D 8+T91tygEB8JJPKoGQ9WpTYXziismooPqrKPW5J8LmqqyG47J0g21TcfZF/Da7tEC6KIztvdwzVz V8deEsHYo/aN+rxn/US8buPZiajQrgi/UHuoWcbRq+b3YucjJ51NpyhHCo3WBRn3nPCcHUvjDKF2 JBWTTwjfKagP3/vvTVSxUEQ6c+qi63f7Cp89EQ8dMObAI5/I/VY8h4ydIrZD9/YhRRWETxX4A4Uf 04f5sX2ufMqJOdx2Hk3+ZUQM0RcJlB1V7H04eIoLc+5h6EamJy5k3WobJgKOxCkj7+h7s9L6BOSi 0l/Tq8PSBjud51OxyVNx2DeZ0pTlmQNNGV/8zieoQwZLOh6HVOFNBd6AhPtrjK8ZlUfWJ8LC7dDO O/tEEsWjVJTDPSxnw2ijS/b3MGGdmiF0rxn7Q+Ushxu2zXrjC5FtUi/J/1sPIWeuv7YpDJzpU2vi a7tPNJ7sVM6QlhFqI77/OFNW6JcjPyPdLHPFG2a6CPvzy0Xoilt+VcrBB1QY1cjtKF7e37kyRTUX UvFpqU3d3yJlWnlUwav3K57NktO+m/zafgW+JznJq/OMaDH5SPFQZ5oI9irouSc5/N65r1+I0a9Q 2vgosUGbWikR6Snpi8xXf1QwBLxb9jN5L+BQkd+++dcDAjVzvUNQH1fvHXu+uuJVabE1AxGaxO40 CS6qYSQPElDXklAFPlpqtTPNJbscL6p8Nji4k/plh629zzAeJH8XsPLuc/P4VFNTQhps/IWKX1+U jEGIZo52TLwsYzsK7CeG5pd92LFYlAxr8+y/esDh2Y9r5vLckbQk6YSQM1Z4ggKzWAgWAuzk/rj5 hGYiXTEk0j5WxsMyaRxMzFptPDSf6dyXSnE3T88EO3g7VZr06bU7mI1326mHuEt7O1zBe6OWsC87 lnjwY2MCUb3xL5GQRjzGHdz8QkyVVNT/Gqzrg1ooa4tCFRpEozgcmEuYFHmbD0/HaNWhsTvuQ9u4 t6i/TfMwGG+vffCGvNfHOR9z+Fw9k4E7zE2XqZpzZ0P/LwP6iM3SfYR0o7a3Aa+Ndadmjnjvd/QS qXoL8oq/97os3XMc5qDufHKapfIwtHoL6vZIZod9qZs+6r5Onr0DGW2OIRViM52nHBOxmb8tf+Ps x1MYM+xm9SwjSI8pN/rveUBJPG07DYf5oVg1Q9yOPkzPm49vxacADHEqfY5eLqkdwGarQGHo84c7 IwcqVFdsETHNijLy+RvZMlExxZ00ldTHDOU4zIQcvZjjqdrhUEeTWlrl3+9P3X32fkuRnv07nuh/ TRia3rYnhS3Hc8bsmU57qU86vuzDVmSsufCN+rR7NfERpGMMoHx23MoZqzA7QmtxdNJvvZenHGXB eIOD1XqDDGt1dDxWNXqwLeYLR8KLvpiIk3Shv8DJ3IvdnKwZPQ9A9+aDWV7VcknHnhNdOv9alv30 vuBC1a23v/qNtH7rKohtumtoBJ1EtPuKEA+m2TP82h6AEBogR+0Va1GTbwZdtqDiyAtYr475pPvp +PC0dBv12XDFi1d1y9uyvE9s8zxHypoihww8q9LVa7Xa71X6cPUFk0QzubSyoJ9Gy0ZZ7Bp4mMpb ssbOjwDIO61F8qCg7Ijm+uWcSPEkga7iQC6tcuh19XR2yDMOFQE74ZQYJeve6/l0offj3G+DT4Xo Qjs+bNpo/ua8hF0xOwtb+1nWFvc6I6zvEvK0/56qFsXfI3ft9E6WbIeDp2aL4+BaoyDTXTgGzz6n kxJllh3XXN/lMmSEkG1xCKb2uQAwdqT3KttgXNVC77PBQVvX6pMIDdddnYoLz++bUcnVQNNuyUXk LfJEiJnkbghtEzmDAYCWPOC6JE0xzVmXEjHNcQ63JtWQqE6sM9lddaLRA7Vf1BXgI1d5nHkDcgZb AFeSkpUmxapQ2+q6HSpFr12p9w8nN0P4n2TcvKjIx61XU5eO9QAL2eozDKBOUuizt8I/yvJItwC/ sTaxmIclGFVppioe5F6yWTYPwiurF+9l0dufEoWbPw2zF8xJaK7t+JUiPGtjjKweY0Fyrm6PdY5L 22o4fF6J4GEtHUt10Xl626d4RFIH7mqR2zHD+rFCQVZ69GSF7c3cdvoDjQX30XlskcArrVT8AprF z+zdLO37WSOzHQUwGqEUd9UJ6Q7V0mSEj/ByW2dE03p/KKE7mnvL/YkRSqPPM6XGNXQlmvvKRh33 gOTbryp9q0klXXU3K+edLshuKHDmgTgcbe94mpdnbtdf+ut1B0c0SJte6ygT21DZjYzJGsKjy5bs dDSRSnoYlc5lfpx52hCYmeMu5eqqryDwS29EZyuuimepxTt1/CqEP2Wh7E6m0jmdreYo9bmuqM+D wku/oBxVnclszop27ao9ylKK6mOSFzKByMyy6M88r2bC+ViDthC/TgB0W0a/GJd3DiwMdqqEFiKW vzlygCx2a1TVf6+FHJYD++cFAHoP7bt/HdrAiS5m1UJTwUUuJleDEk8XQZtpv+/MWacEm0mdNrDl /St8+kCUz84qK/O7wEG74Az7w4+K962sIObsrrMPdl+ZP6cFCEINeH5QZxpAt5wGnLJfqlwOoq6t +rbP568q6NRO+wu76lcvoPv6X+s13pgJUEBiBI834/pQ/KvjSdCZ3Rr+QadbAa3lwMrDAOB79Jqi 9Bt9G6HpS7ZP+MxZL1+T6FpNyuuqu/EEzuknwwpXYn/oKcv2B966X3JuWzWnq/YLTca4dzzkLKPG GMyXE0g2U+RitURrWXjx9anEtohLEAK9oe52OC1Da4qyPvo9urbAg40gS+nLlXAYqOktMGqzGyE+ kdJ1la5SBu5oy/73RtiO2Plt3DAZ9hnM37CJm7d7N7fH8o6elPCaOjpQmxxlRYlwNaMTfEnd0D2/ a+hhg/QRpbO689tDGrJ4YTfCR0qxfVXRCD4otpQrtWfTc93eM6I3jc4rP3hHDEEq9EOr6+zF1t1Z un3BXRagE1UbVsuW/FlmjjPSnHxCedR1s72E4fc9yuf+7OHbkGdae378hETjNF+dK7mWAbyrvHGZ q93Lx6LmaP0d9ARuovgTrONU7qvdYP8WulPEtO0eNbjf/mluwrFHvo6BtnardMeqUQmhqLVfg8+C VO9SFLhaDmijTpMlRshqgRgZSsSmWOs6iwjDptiwzW64oDUtyRc6TcG24b4PxHku95V1zedvUIc6 VjeowtFNgj0VRnMy5rnNIn86TKkp1cCn3d5PmdwQRadPA1fm8/2fRzPumhUSzOT38ow/QaWB9rqS QDYAGXmcZfMr3W/M5BKtb0OTPjXpwMyKr3L34V/HQvuU0jE9rorta65G7cWuSbPXCRpxan2r6GyC aiBUFubQgZdy0pp9bYwU7jhDVvtK8LuArFkgz8WLtK+LipzfFBukrWzfIb23W5FcPLLgZIhh14u6 iPX6M58/M1mvqkOc6WusTrW6YwoxZ90Zaij80T4lVwRNHcXTYNKOVwJQrqonhY/z3VB9G+lhioyo 5s5mRT6imNc9u12PKTM7Jo+TAU0bmdE/6Jo3QcNBVhamSsiqO0DkHw+AORdzKXLo4CvH8cLZ74ow JiWYNxTdOa+I5ozWdbk0RpwRnHfZKIdQ1F52rYnZN4QbYVrAtFk0avMu8vu7jgz15/HPvqg/UBN5 +6dt3+LctpmKJZbYSeK2GicByyFOq04V7xpH8IGjeDBMNQyjTOmb8+S9FUyYhKgPOCNH8fxA2JYq +JD1naFXJPUk0BDlNPhgkl6Gq/MtJ+SB2gNNJeQhPzLh8jugSEhK+PFymPaAzrTEc91yMsGe6ruF 6yjjRjpN+X6FFGMGz9MgXwOgNlWjMa6U6AVPhmh60opMQzvLBK/QgpRJmDDDE+Z4FqdDd9vTvf2g iX3lIOVrCzfNTy3ZeV9vUzlSlgeBQ2uDLpe26sxibafY+6LKd9z/gzkpvRX/tONV3QOYQRrD5tAr KcjQnhII1aUSPXleCTQqCbPKwjR8VEFGfETcX/xV5AK69QR6BSdkSv0jD+LQuOkI73xwXezNvOPq 5HWY1b/M29UAeLhP9Jo7Jcq9ronZjo7yDsTR/mYi4/rCFZN8F1VGu3uUYQK0L/cnbijlYQNuaOIh 4n5brr0LyLfA737vDRwBGk0rIJtBBXjU40oZYUYD5o9pD+cot07vWwyQYfdtFcen4aW3mT1i6i7N 5ncvs2Df+EVHudukt62Dzc/hvBDndicl3wFn2z8oiZe2sC1/3WA5CBnBO+loxiTfmxy36RGyr+XM 5mX1inQhJlGvbx4ioHBHWedYZZHSNrZlNsUsDD5/Q9ID1FT9Yq1rWSgSNJSbMM436hwHWvYaHt7n kT37y3VHxTzA0pUhOuU5UiMlyjJOa/KMjTi/fcAb2Z0XcaC+/i+g5fzVTsD1C9110R2V3Ttl4XR2 eSN6SS3Wr1XDMfxAUN24jGOerGwa5g8/Em6K9JI52y5K0d2S1Z3bY6LpYPadYHZ3st1GXMhe2kn7 xZtwzOYBDB40c5RaDDty3s7qTPOnI8/GJ59boWFylSpv0SEY92jyhkx856MUB0XDazA3JWTC/yEF vB5oW4cpcc8inuAQV5GvbMQF7EFO3S9fGSPTRP/juvtvR2m/34y0Y2gl9PdxBXlF5tZH8Qnb+LiH z5eu/PhyRtmwdV9Nun3HCzb+sjL0SGjUHNIuJfn4IyVjX4uStiGqGGDfIJrUruXy8lHulLaVGtX3 utWGYEVo48iutfx+0Uobl/f1XL5VGPVH1SkM1sjDButjcs/qDjsx28RorjL5rJfdvszwAaUhqtuK ydEOLp1aPG4Sqnx2o+8C0S/egx05h1l4XZnTw22i4C6FS+TsaaA/bqLEg0IMvHjIxpzlFalE0FoC sK/K7pEx5pjPB/A1r9/O4lue8ohOvlSXGrG9laHCz67XRA+bP2ksN5L0FWDO616+7FNtcbvjVCX7 Y49kn/LXb5WQXJGZZLVs95QNYrjr0JrtH7mlmDc9AkNkjatK+SbUt9XAM8OyyEeUm/kTvY+mvmcJ /dLbF09nX0Y8xRE75drMQ2nUTpzbOydOOChEv7bQRBr/j45bcvn1pxN1LxL95qm0UTJfD03l9Zvf FZF1V9lB7aa6PHscvLvSzECg3eZCFmWzIEPfIFqkuPM0Uj+VQ37pUWfeL+7+9DghJg9IL92kPNfj Yy3aMlOjphifEaMC6GD1hRRj3cl/wo7vcrorF6fx9uEL2vVKzDq7Rktykr+sS9nZTX6wb1zD0fS1 MaNGv6VGP0YKMi14eTe0gaMmWZS4aD0io5Np1+8ujvi0dsg8EmNKGZ3fuwKeIxriRN6B0O1cE6VC 1vImRVXWvfKb9z3rPGSEJYC3PP3Tyg0emjtu2b1nlOkZIs4oK7aD61RRSV9Hu9KGSdOXhDdVMxwV Yxa8wKp94P/hedo/nl+g3Nwq6qmXuOla9MEDgNT0PUhyNfw86CkBsu8yTb3snNjSkOYC2NGCTI9m gxo8bJh7wuU5+sMDr1V4d0hsnRBPeUlQLSKofsLQqmfx1+1G2mgfSir08JKXPYWeG3lNYe01pXDZ Kr14INfDealGf4G2k813ILrsiNoEm6fxz5QFBosDU0A0uBhThlU6vj1BRG+xgOxuwXVpfsD7dOKj IsyZEowPjexeTEj3uvSwi9eA33ZIht3JMgKtkF9SmLRVGSKCyjF4RYpljpC1vtyf2oAo+koum/jx cwevlJC04c8U0SCj6OZZWX9TscU8nZuRfoq96MWr0pEyKA4dCVUEpmV443ssl5m3DHHRMUv0pffU v29pS8fMeYEV6Rk4WVGzBRi9Jo4smlHSeu2XHNVmw9OnIx3zc3DKBej7EgBE2q1SmtVlB81VZOmz Xzzw52Hvryb/D/BJjPOK4amOthEraSs7qXhqMTvJ7qfrD+xR5l87z35ML3kUMDuib7fdPwhJfr+I kSxIKxsH2xNixjQP83IH9vBVmu8XQrva3mttMyNllSFks4sce7BXbodbmWCE/ojXKwbxp5iYak3M H3T/O4vD12gM3/z+kJXJ+yNxj1rbdWKVjOIqSFnsreRaoMqqivI0srkpIypJDofHLe50OI07rAXR uYSTYx3Om7wv83+UfYr6qBrQ01ST0M7Zux1EOemECUNRAQ8bcGlXATxmEOE8hLIim14lFJvTCV7D TSbopbbj+QnmWn/XgrYtUYAypuLslL62hRhyuZxMfYwj0tNmiDKaIZnfo68OIfHwF01J//MWfLE4 Hp0/i69PI6aWx0SPGIA14uTDjhh5UM12WDX1JEz8W9m36KDKHtfbiWHFzkbqduJAvz7WfhSACOC9 FLpOYZ0KwniGVW2ah1a9NBcQhs2RUFWYQ37Zel3TRbu7lM96NbIDZaY4xFC9XkP6jyzd0YVautp9 qmdshQ684p5TnjP3Sk5kc0Naf+fNAiYTzKGcyT9vqanVB5iqX20yYtfAB5qO6TZZsJPRCGeirebv sVuQLGee3YqgZk+lzDzA1JN2xnFhecssECiPqB8SfKlJS0FL8aeuj0hDaIPmxs7BSGyFHrzCYiPP mbA7qAOdHjx4JSAXUow0Uqf5S6FVtpSaFZ3twWRNk6sLoen6OhYSRr+MqWQ5QL4yrNljEPXPXzL/ 85eJybeR7J8w6vsXgBJpQvm9ZvaqTw2mzX+JRcfeIsdUXQ/DNIha4ozWeAwHn5K4hsMT4xbDebYM PR4W9+G7xqYr5WqZatsUVh0rfyGbYamKsk86FJTvY+iXF07AeMLHtZr0VO6OIvDPdqraj83+jBjm 47Tg5JZ9TEkcJGb6JiY0c59a+33fBF7xrPkOxjJykXMAPTrWtH26OoSgXVXsjMlZsuud2FVzg5kH vWsfuSvv8HXmevdCMfAmJapERrBUU6hjpOXWmHaTUV5IsbPzU/fCf3GcPuNR9a+0pnQLEpHhRfH4 FgyZ+r2TZKbTwb5/C4Dkx6zv1qg5xYB50CL9wYTuWlqgkn+Bpt3sGs0aFrx+Kow9bjJ5jjKjVsqD nrk98q+RW/AK5OYq5H7l2Un2XBwC/UUXEg5Emi09253DSrbRdbBzyN0DR6GFpJSo3m068t5F8lgA VIvi5MOrco/iWYhLCGaBPFMUvN83I8h8Y7hrKXi9/IyCgXO8ziGBmNr4JU5Goatf2CGB5jAT9Jl/ FHh11dOyzT1s/nZrZySukvvvp2BT5Vh9umfbz+9+a2QyogAJNuaDZMIAArqA1oD+cMHpvI6FvaRu X6ajmsrZY7n/in2sqZSvoP+eFd/wpPaGKXVbHpSwXfTR7K+/zBJcHlIR0HBnKez40ETn3oaE2To2 mHUIrn/++HBEX/ByvLmMQuETTUETarYcKMHtHNKMxDir+CFVovDOsZ4/RggR7XojjqZIBDyZY9Me VcaDRHztxWO3acfZpevsG7PbmidNzjx0eosQZ8AlJV5dTsozSd1IvAz/whH/hS9eUTtuLR4kdWt8 VVEXPhcv2hUFk3F/5yZR9+pmbshxUYoFUvpeU2fayuiQTBQVFz/mvtOkEtp4GFSrYXMl7lnwpOIL jfDMBo4emnLEkTg8o13eWmzVk9oW2/36z59kOPLyjal59jLmbo8eJVwRvRp0JVojwsz223D3Wixh /Xf+jc4yQxzx2hcLksccOmQybGCFOLncG/W5wkBdc9JKJqLrZse6tMh5nKKi/IDeSBx16dtG7I4h olVof3H407Ylyer7CD4yJerT9k5hFIzmAz2Eh7uVpRRtYD+2RZm3cUNkC5Tzh7WTFHqXH0ywk8Ci KZLvT+3nqCeVj1wPrn0OoznRFf9usieUZ3+GHCA9+aoluaT84eFoMuM2YLwMfY8MiAo5Xr3IWqFb MmZcCBszZxxVmORjvWoDHB8+Q56/2IFiaim8whrR/avC7OVlh6wZfh7rEmCEC8noJgtzH9TiAG5N KdzzMEa2VgQAIaZIrU0xrh9nbi7yze5Jga/MEmOFrIP8Y5up7DBxzh90q39ZRRhMMKX+KYGUP3L2 SJxNR936n6sItpsv6Qj0XxRonjCXMKmDmSLVrxRxI6ZpjtOoaOnJf3togj9beGuzVScxG4/hNbrG F+K8T73ZSUqkRaDQww7oyMb3oZEdI12LC28XI/7lX7BTUlUHm5T6XMDum2PAo4Ks0tjxN89pJIKG +PMibcljUVBZp/572sbIeJozZC3BGJIS8p4FaB+eQAjPbZ1AouRBbNvS5D1HsnFaLc/bRS6R88cP PxFIWXo7CuA/E/PcpxMtz9wy1rO4hs0zo05UA84DiOcU0xV7MSfn22bhmb6SxVOVzdNGWntFD7DN rBAjsmY9C5KwaY3E+BIOM4Vy7h7SksMPizxuFys1leKwfHFmE4w6xdIiFnronY6hLtjbtHiXYjp+ vFAj+H6BzPzrFpb/dQtaPSC85h6HZ6pkjCzQxTjXdJQ93/jVrwZcrMsKbLj7PAbBC7XQDJl6bMYB ulVpvmBfaN91DosG/TUqMEm1FOPL0BeIFJKC6BUEX1i9YKLUsnrMmhPHpbCJ+7lOt8yAQ8tdGyh7 iPN6ccr9FNBLkl/wPJFyimbF2NwUHadt6rrc9Aq+lQoKpEGhsZgIhnRMDqjnPKiHEZTwk8IgJlMM wEyRvJSGTVxr2UUE7/LFLcMyOwlQQJmzBBdS5bgZgMy+siroO8dKAEjGnM4x/sx8R1lQr4283bAB Oo6lr19aeqDsfpVCk666susP8fQ6trrQ1LoA3yDxL68J7q9lFDqvUeg3uX86n0Bccwk+rmjHO8Ax LoQ3YtdJNQvo6MnJAXaavxvjx2Q5ioFKbGp0i3NKBWgPPJF7G+lGI7FvPcCKdoDXnkS7wBWeOMcu wv9Bn1EmpPYjvC70hpjrEx6P9McXacKXYvsfX2hshuQQ/GJ6aEkigXhITWftKAC3VlyFQbP2pKfM RNfbzKd6FnqaYwfaLMtGJbQ0S3pF8PyRoCFj7EGTwfOLRdBaIeuctOsKD+EMcHHDYUP396DKZhgJ kPkHi6+zh/FrtygNLgeXVI49L/fi2ep1/pygYqYp9Q995YB7708icwoNvNPbH+oNFVJHykHmw7fG bUypS29l6pC56+LwA+1K2y+E4Slo6L9WfedYBJwN06ziz37On+squ/tU85xOly7eCc+4QY3nSSt5 nnCWPkkIbdzQqPKckYB2TYmayRZ9vXC8bvwbQjfapu6vkaxi975Nj7A9kJc6IbFzbxQjxof6+795 rlua8BH+3z9Wkh0IQ6/q/l6C0VThr2KfGnaSaW0+stsyxOvVvqH1l0lSjd5SAyNyrythOKFS4meZ Po7I73hx2ZoGcvj0sJMJ5/9iwkoDoWy7sCVElvQie0VkK4bsS+Q1SglJ1gxjzU7ZjSVZskskskRF hsaSETFDxpp930LJvgzZx/bdg763P/OD+znPua9znes65wELRNf7E4R3D/vapBujBEu7Xt8l19O+ +UCwe3ceL6weryOoa5t6A8pj+EyXPZej8eR02fWSfYzKfjLahudjgnMcXvNDAtduZYygSfePHe7X zz7vY+4mrSYzMz4SnnQj6PzrxLgn8HWCo5C4SG7SDxoGYcO03X+Nqf6y7m0yNBwO8u3M1+xJtUQH IHbe61g6PNe1tX9u/tzKejFrVA0qgz0TObaMd706+GUyzHC9WNieSuyljeP7URF58l0wedoXo5vh u3+UfUVX6VEOJaG1N19z7DI+bS5pNWcp0LHwlU/J63mgv95MbKmTnENtPBYshiXvl96PakI/j3Un Gu/e+57T5PSiP0eqMehDyzndV+rv7+voNylhYYlg8oEmitSiHs/dcVHN3j1U+bEvU8Z9ZTtzNwZ9 f+11s1vWHG+baG3n+G1g+8bQ+CK1qU4PJbbVppRrjgzr3OJft/WMd3vw0VwppWO+VgtrD8Rdfbgc wgp6jN9ZVPSCuVNfMnpHa9ek26OGu5wtDyxbWj/WlLHXC8Zquz2/8Rx9UjQXAJMIl1r9/fKnaApL pjg9MYTouqn41wJd22KwPjE9HKxw52YbjO5q8SDv9xrs7ekVb/3/9DYYnuHro7gQinCTvhqyRYeS b6I3Csta92XCAvhKPK9Lupea/NhEcqtBS03uDPOIRzQKNTtlOfHwLsgxgXVIOqHAcKcKNjW1kFji xp7JYpdrb+kR04tSm/c8gbXeTSnZVP7HPcEBVGA+XUNkfhjh/nYhZzJhK3Fq4WgsTtraQ8fyWHwx UT1y4jbvFMJDgEupIdjhisslHs83LqUVabVlFHHMmVGt08t6hvaiNOc9eXLuoH/2R8CEnS5lXgZr +4v2k2vC/YSChvaQDHuo4kLm6IVve/7yAHLVpM4jM7ZRUN2jZTPvpzbavZcm6j7Pin+5YxXkcEJ6 4e2o4Ore/LCnjwTvTlo9mG422DSXaddJvflxWgU796ZXFVVA3sEDCw0ODLkHdh/srUrHUB5MbKXF EUlXxE0sy3+pzAVbPl2d/wTwRoaUx5dkJDJMK12OdNu8Tg4ktOmrCRKW04evdIjj2nIf7w8a9p6h BaTULA/y1zTCkpe3NwKsHnmqAIlz+L3TG82TfUeqq08zNFXEc6mkp/0540JO381Nw917BcYBATf8 EVOk5Y+nlAbo1nvW3Sz3EFXSEr99Sau23CeXgm3GT69fGJzePGUacICoLVGfMZooeRBwrX9HsnRf SanFn9munWTe/y5mQwcd8F3pLuYAtv0mE/E231cQZ7Rxd3kRlr3Blea4uvAuzkJ3B1rKdut1hG/l esC+4uUe1rw9Ev81ZPDmthISsh5dgN/JqE9nMT/oM2PyNTJoF55PZ8FUXfBvlyqOvTcD2Xq8Ef87 LeEdunPx4Q8O7A1fI5F7Xwb5Wbw8AivQKxKD3dcXc1/MLaovj4rP+b7XxOaE/I46Jcd/8yB0zyPf orbWb/Vutb98ho0R4erGV5qysTauUcgrLuvbS4XRTti09oAWr/wy77Z4LTnuc54fFd62JeqhvNsS cTA//unmtFHX7WixCbccx8fTEb+jtpOLzE+Gxq7bbvAQVl4Nnur9vLv2z4Lamuvqhjl+YmEjvip8 H6JEZRT1+Z5am8sezHz0/kT2PjT/EqrlwDD6pfOI39hBu4yztC/WxmDDnFaJMm//6rTj/Kp416NO af8DHd/NkOFbH1unBl/eWDRPeXjKzzQPTz1su/mcY9B41Of1/uVH5e6VXgYD5bslI7eWKj0d9gVb Bl5vxkT7i5YHjK18npcYufWxW54bSyPBnZbNGftFyVphFL3XgIetmzWl1fZ/WFWqmFAqDdBrQErg dXf0Pxgtwt5hrqXsIaG+saddr6F1dtPy7aa/tBcGtFj09PPu7S0YQ8f39fL6FmHrSRDROXcL/x6k C5PpW/9O1kHsnJoqNqA3sp56IgeKXBGqJHXWwVo9XYKtv/8xaD+Xnil3dyMVSuH/MdcCPJLpX0N8 JETHstLsxXEnZY++9U+IcvHv20PeYSUQfxhkjKLJGoQ7yNRzY1l5d/SrzGY2UT41Mly98E8T/dzu nOCJ7pPfsRrbuVXvl6jzeHd6f07Xty96Ucdon4NAN1By4hFRvFBmxweWnxvdZO9oZ5znHcDT8boc 5PXT7e3roThiZWASEa+vhZz9ITs3HRW/h0yXXtvRV3R+3YCqXRH/9JWjx5n1zY6+YAa/TWaGE/5D f3Rwm340aKsV+/rF81ELsPURAfF0CfaH8/y1mknD23Lr86BjS5Zg7iMdePBjwIxoEYhRolEfF1s3 t7A8yJumBe9tZ6tqOxt15XB2Kjh7fRNlJ6ngq/n9n3tg6ZSM+dHP/p1MPfNVxSCAKA/YSGs945BU Quft+48eC7sLs/3YzQdQWBOhaPUSmmLOvjrF58VNr3NOHNzYTgrkv5KczFtP4k/eiSLhhhRAZ/b1 mnMuN2qVbfbY18tDRDnA9NSgQBWWy8AGQOViV6u/MHHC0bjJlg8pOSU51994csO39+QIVqO3Yg9p KikED7D7DIc9rV0WWS+pbwTps4PqpEvetciQONN0IwrBZvrOv3frYAFxyuRew/cN838ZfzF4qavV yfMnD/k9dKqz9dDME+TnR/E/iQw836+mraMDeX71odPAlv3oCIQn88mTkUpz5YfwoYt1uKmu5BPI WXv2brNPzs8x72v68a/SStJLfJMkkCdLYddWfcV3FpZ2N2UPZOVtrNtEYjuxeUHUqA8c3z8bLlBu QNZKNz5S5AXSLNO839bX82LMfsKl8p0FZ6uSnzRKN04X/uNmxijW7lzCjv6ihSgBD1fbl1Tm06Y3 bbt6kEfDv4nKM/uRyzEFO7VAyV7NkdyJjZiXnX2vNaVYGougRjh29E9hyQWoRG1SAvTKz0KaB6l7 HNWi7uPs1seoMAyQkfXFyQnm73hd2Zfb+otWzKTr+eJmlwq5Bigx0Q/39YZ7kq0h6KImUnkDS2XJ wlMDpzAv2faQG2I/JN2zOaQjq8IQ57Qbht6guAhD5OgnzlYpAb33ReEOVjY6ZXSQIZd8R1Lf6s3z oZcQPgd5328vwUpTJdc+WEUj8gLdzE5tsYAbO1q5HeQVOBhl0LD02lzSplogHauN2tfbdf6yNeef MffLugjSzZBvFRSUqCyrTWlaD24tDt5gTjOHnmAdds1fRMS9rH4AUBrjlEaIH+Q9WCioZu8jQ1wO Gg4UXxb3aFTLaMHmRbWGYmxx4fVFUNVhh+oZWN067Xl9hDj+wwOHk72FYtcPlA9Pg3wSvRmzo0Iy nc7DT/DcP79INhbCmr42u4fcGvsev63fWxLLWJLYcW1cwugDU+ULxHiW1hRMr/6Mdj8lQgpXrGJM ZraG+ulTT1k+l+Ct1VvyTEVSRPzknmqHVCY4DhB9Z4oTsAIFC2U1D2dmucdgGgvCT1bMJhBjiwbn GXLAyygcKTRqbg3ePEu8z90kcoQHrpA3iWvIjSQ7gLn/kWohUunV5j3FL3yfU9Qo8CRosnfj726v ooTWeaCCqVEV8eGMzwzia9bH14+4E9H+wGpfz33BF+fAAB2LardluEIqaj5WMQPemVhM1tMahvHD NYehyQ5xcTlkZjnm1YVeETlL+UJmAXAYkOfZWYjGwNWe6OtRArgImg/kKFVaLcLavt7rb7vIueQA WNR3ghMVmoRvnI+Yijko6hk0KYHmDUrMElTVtAHU1KT9NeYjwRLkIkJJcOiwCVbi+FRH8shkrWkX qTHg0BMNjbLFRSwZU5mGsS4RtkxgeFhdOSheEt1sWULIOpIETZJaIy3RirWTAN3gaF3Xod9TRjZA 3fOkX5yITPYmys3tEWJ2L8+AZW3wTTu946xycaTSq4Be66TACilc4Q8Dxz27GvtXxCYZXHxPLN03 /g0UPIGgX9i4b1VtvdwKkv9JTDHVkG5N7zqML6aUZsiO5K/oyEzny2sFIRg/W2OKX4cYOlrL5tqr 08rDrdZRFCgr6IEQJgkc/mkCwtc6sWnXvacVoGo26AmEL8MBwZglygP0IPahmPr9yXxqQgqhP7Bf 7K8XaNHmWs6/cVZcKwhDXwpUP0QnwpB0boq33ghnJJ9JWRkKWvBzOsN34n/sBlqCEh36qt0ymQQo Ra1BoSAAG+YSXnKNQfMZeVpE2JvFk4ecBLW64/QRrzYzLOPCoU3DFHy2xObBYfBByp4HsRYmsQbz VH1HucCQOyOaxL4JraPNs3QNbg66m8lamQz4m5o8grX7R54U0eAS1ZCJH6i2W7az/i88ioyQl4mi AT8FZB0gdFW4TkuEjicv3OHf/Ohgu2r7Q4HabjsK/o4BmiH2mVOAPKIm8hVAq+XXvl7dgshaWiim u8OTfaiNDID5UR0Pm/w1RWDPRAG0wM8Qe+D3KwRLSIQh3dz9C1BmuB7dR1KU+Z+jMxmq7/YeCRCm tdfa31iREGyUAR+t3Q6EKqnc21XHvGfkGRw1bOkkCPquis6fZ4ltWlyWiRdb46q34QxFl5EAfpWc hUiVWPc4Xo/ix9nRFBxVlRj9iI+KEMtLxtfekg2QOVCOtQBFaiVK26uQzCsXKOk+kP2h2HYHuKZv XhKCFtFweodVaYL1E4LWbyZLi8VCQv5JRRjjhBicKxTNG9iJbYaYss3JKSUCFSg6G7ZkyRH2XzMN EWFJNZSZoz9nRLpw4v/RRw6jxyCeJee8wV9Vmrj6CUFtu6/HBxTG/JL2JiucUzXfQnW+ev4Q884d fdcrq6g8C+baPMPewsXq+5knKp+CivKB3PW+8mcvXcQlX3X4r1c9nQiWo7rJsOtj3jil2HYZBscx 8rHymYQ6AXMbnc2r8NfQ/O4ODxYxgv7KNgqozKNXAXqK9ieR1prm8oEFyoJeYD1Garwawea90FT9 LhgOoSh6/7Q3uF/iL67v1yLZ6MZIHYh6RyTAnBrtX1VqXvY5pNbUsTyWhfYX1nZ4em0dimnVj0Pt bbbOXhLBJYdYpFE4lpD+FVsV2lP4g9eDZDjw7vJdorD7MGa/OCzRBZboXCqUDbFR93OOGrU0EhGV 3AA1Gwltl5HKoq2MAsBYEYEB0i5ND/l5WtgJd2X5QQtRIWf2kK9HTMZw8ZIOXY0amYC+ohag714B dzUARVKP+hEu6ffrz+nGXaRHUYP6kvXUvt6XwZe89oOz8Xok9Y95ywKdzcHfrMKN61v2kM0G9D+t fsgUu3AayoRyEpUYL797cWRd6cT0VIozNcpC9yvkLB2KBA2eAibLQrTABB3PM/DbNCgKj2C8NbiN f8YvnTSlNmwCbrQWw4Cyma71JJv5Vlt27MtgVhhqpgHyBc+vK/pIN0aOCQNCsoUQrQpITEitG/1m HZNnUwJ9c8Ba+n//rwwviv5/9aKGjuz/M3dVADM2VgBQs2FXHQ+/yr7XYLvGm/2t5hsoYml00x4S XUSX7VG43lHGTehTHaas/g83WMvMdxF6wk9o9rkgNCuxNzd5oLKp0RUlpy1Y4K3sVQx+50Bvruzg fA6E2oBx0Tk0Jis6bCUbZdLkkqDMANIUQOH0CuFAyCpYBuiuBkoTJQuLRxHrXjKwYyi3ZhX9gVzs HFcJl588ICHal9FC/pbydxlcuGr+Z8hOzeYfDv7cEQBajyp+ZrFZfNNinjRqpX6JZKwGdPQisaPT eqMGm4Ce2bWYml3b8v9L55x7BxAOwAe4jOkWjh7gMsUN1LhpS5+CFJ8Wtl9AjqOInjR26dgJehud 2Pqr30cNU/SQJI4ngrbOswQeqdFHi9C08CTdCYQuQ4nxd9IPX8Dy5ZkiKWK+YZHSLlBoWYg4GYK5 JII5c8kIZxBpYN8gGSQN+f8l0OASVAMtKzuD+Su+gXJml7buEJ+AAKNhlhf/mMQViqmd2CDXHNf8 m8CREzArjjfOvGuOT9FnSYHq5ZyFeBTT5X7hhvTx9hFWqKoZxA6vkHt0Bfe4utu2lq7/bJCtK0t6 SQJg84jdnZIWiLGY2CRDkVHVMBzeWf/DUSVa84Eb8C+QzwWxL7ODhHrBcBvKnL0ExQ2EG3Bcuhos /V8d7oNKY81nGTVFhLNIB+iIlt4KHAJQyW5gkPrLwMMZecU31LaUztZ/WwIPfSH/jP0TDL+tPQmo gZEovKeYvafgepQQLi9ii27LmSh9+Mg+ovbt7C3YL2CeUQ2OPNsJUlTmksE0nA24ZtwAxNWrHfd9 wQ/nP04S2J62xT4/gKUJm9+iYz/Q1NPf9U/Cy2J1t6e39TUxG6QNzrHi1iPOk/t6+LL2UuAqbeUB zAF7Gtv67tYwTNkOvj8OGcA8DQa3XqZOCz61DQMaEUrxaombq6jmi6Ae/HolDnmW3wIVzOi22MUJ +gX8+gdCl6T7X/ZbUEyqwpTWCoIwCqArms+Dw5RW2U788AHX/A1uZI1+wrGMF5CBWb0gKxXxUvcF /kw1/dvgnIQpUFZg5eIzZrEidk8xUE573k9cJ4COe/+aA1BZF63OuM4Ir7WSLqy9cGb3Yge9/fDi Jkojxz33C2VDcqzBNgZZvdp4zI77z4HJ87XOvLrVqVgSdPs8s0IiQPfq8x39d51fOvqfWDistFL8 /u88kU2nFF/qMK4xr7dkvnyzSAFuoMEHbiCkGG3hSwOhYUQWTmssJ1quoYxUPh4Njfc7Kk1vNfXZ Q+Lo3wbmxE3BEq+DhmCSi7GwXyxnNaDMJ4GpQA/yJo8v8FJXdk1vo5msK0htPPLGKsroX3Ba7RO1 OwwaxYMTmivl9JM91ia9K4A2boKtztSDewvK7HG06beB/vGA9C9nSVR15dIRhnwukyYFi176yy52 dt1yGQnse3eDLJctu3aRW6P/AkMT18t24oPf47n/DnbF6wqInxR/XF6rF/3yqb99bcgElc94nQF4 3iTimXWqo3/pJfUvkm/VL+M7sXaC5QR92XLDhXdr1vi6ni558hukLE9EL4JmuwByZOlS6XH8NwpU ywL/bvxW0zGcSXEAfmrFpQy1kP3Zap7zjArxAP4QEN/oRk0ux0wGqQhl0hNRPmL2q0GpYMDVo+cK wdw/uHqe7QaJFoguFA9Y/Wztyhx6nNX4NLIugHrrDCDbJOCmnhR4cfFsCIk8M8VbspvKCl4KIHlq YvKZ8aRNTCxxlJaksuOylkSxu3PovFbdHwJv2wVj0IEhxONplbmi6SD+ymPOhr4I1gKZvr5Ah2UH ceJABda8OmKetycR4rnFWjRxJ0VIYMpAsyvZu03GYgkibxuVPijzx9Gla4LairitHwqF4WN6wtCO CNmZIJllGcJGFkYG1Kquk63HsRaCvnDfOENkWeQ4/KElGH4SFUtjJz9LSq3M6cUJ0ncF74zI/hD0 jCmEVSecmTmZIl3tL53w0ZWjuCseR4ILaogXnV1vguM6KTiN5ddKVWHynx6QgDbxAJkQNc4qR/oN ioJglIkKcRiXAjRwAJGLOxVzOaJZO8OZNT1c5I9JBixz/hTddezpp/sXBEgLg4ZtleNMM0RCo5/o SJ+GkAV3sKgcH063JC6mQvLEEuGc6CKoQGRCNXEtbYaudNio0nLABzMvc4sdX/CSdAYH9ESOjqXL mdMMLVRlnQNmVUqGtBzR/34vNPtECg+hGK5ZJFbnkV7VERVvy4Ukg0U/tN02GKMbOAWTzADVWRXk cF8MN1cX8XXh9+L/K+kvshcTs64/D6So9lvefqwaDpKu9yPonHSLZY2/YBsZd3v59t9YvyLWhvEL WPDfLHIuFxyuU35GYRXb4fFANTrQ9H/lbdw+k6rRiThLdirQYHn7ahXqMHZKRIUOopMynLlX+h+F BAC230fUkaMkqlTtvLtrhg2pJjvPopAESG5ALHxXd4d+uIXIU8xXDNs4m+VfrmuKZSpWySiAcZ4+ xX2LuDjCcV2KMuijzX7zG0n7eWJP6E4RV7tElTd7ugL5B9fP04dTxPKBpkgCsBR9om64fwKhJtPH Yzt8gnUP2dXUi21uau2/05XZPnqNMZwcXm0hsJ2FYRWF4+4qzA25RIG9fr2dROtQLEq+ETcXoTQe SpGsRtJnypynyblVAb1pQVPBc9kJQq5RiR361I69gcdiLVtejlGY+RaG2SWVOk+pEOr2gJi0tlRM awyrB66Y4QbVUeBHjUeBnbjDXYeVo8YohwJZl1kBAeE3lmDMqlSuDtEd/ScR0R0ep4kTd6nYYTFR 0Yr0iBDyf0g4xBj8uBXddMYUROEt2e65qbEWLer5u0EPxx8C/Nzye8uJjfyuM0olUsBHm8eMfCqo nReoEDfIe+pY04MwLLa+Z4nRN3qIiXvvYEgQah36AK1gAArQ3IgVHiitYnRFSLhOuEFIcFdN96Fk vX7cfQnofY538Nl4RxeeQCW4C60XLWhLCLEt30x09NMgCsCPY8Pf8/lkcOclZRgf2LKNZbWnwFLE Gyr1xokRznThfuf44+XHf0jovxcHJEjbCGx0HSEkhPAOg2WD/+Nik4kCag5+htpI/mr4DRUY75rk dRjvp0VyIquItZScu88D5YPrhVoH2sQdbVw/8w554q16VyCg8TqJxecLReNFb7f164D/CSVdUYb9 LREm7RekiV+MaH0e3RAqVYadWitVHk6tvnAWUcxa9Pi0OwdjNmMRe5jl/6Mf7XNWXROqEGuOlBNm tNKPlbb8iKnfBKnfAkouw2RxA0fDmUKarkJMfpr88AW35SKSAVwR7bYh6GxiO49Fsq7OPuhxVIli wdmxpVCn3/xrGxVKMGVNgqrVPg/0MjsKP5UA7EMpmhMd+PU0r4OBUNzRAw1+XcSFkWb11oy96oLU jH0wWrf6JjH71VmZOTQPVBheen3YFYzqk8laoeVt7aD5PYQYbmU3F1qe5wYCBwiQgqp/0SKqIy1O u3oLF0Fbu3vmsPvHKohr9OAsJxwN4FLK5hpqI00JSGyNZJWSC65wDO8MNXA0/086iaIlJL/IkX4n ujYh6EQ1pROgYjMUDFMcmlzcWjrhjJIKdIXBw01/bQ14xlkmGR5gb8eybIorPNbwCYPhN4vEz25u +QezayvrN4EdslRRIy7zijkFY5IYXcddHzceqe1mptPVGAh7UZb6wJGEHuuK6GNLuZBokxMXScBh Yv29GXljjnScUdjFksWL5TBzYuA9MvdW4J8zM420dnXTpTG4ZHqfWDKwx7munRy1AHVVpw63UTXh iKml5FohisCYZwexmbYR4eHLtBG0WqRiZ+lgJJhAQEsKU5yBMq+ONC3k62lhET/IFvwP5xsQnDcX HOSY0286/vhAQvi97LXsJTdL3HdLA92+QtqeKsnDB99c5gDoyy5NRLn1XlpNb36fqj4oaHdPKO4E LrgBTITMeLUor5Q/3wOzi2tKiIDiu4kfMxFguOk9IyctFDmkDha+EH/LezxePP8fBMDaeC6RciCI 04iK9T/nSIXIRWapZx+wRm/PzPy7/C+ow5mq8Pgb3drSNJCs08J2a2eW+f7AuospagHzzzp3gmaQ hXggk9mFrevEBwD3E29wZKJOE2jURSmTOroPQdrs3zmck6yuMhAcLMSDmM5TKzwDEF0UhV/s/PNl kLuE1o/tD4fG1C+AKfldR5Esk1QfvVmUtBSbwiviE8BB+HRWku8JPcHwzAg/QWsSP68U4S3zh5WY PmCuzpSoZiAcjodCveKzkOeCpO6O4eaqIsMDJssmoAIrCPFj7/smCB+5G8H5kuIteWT12XiAfjiw kKZ75Agg8rIe1HGnMK+JfjaWMEr0EDgqE0j9uTLWG1R3q3VBu2gAvaSZzPzIBVkItzpXRuZH8V/2 /GCEvSkdC4PqTJQE0R6P2EzEEVt79TMtcYafsX+Ktv5rcx6bmHj0AcDWYEP2YfwDoOk7H0beRBpt 6XOQ34zCAbtH87Xbwj89sxNEc1WX4BfJmaGWDeS6Qa4FOkwoGiT/8PEJglH9NEm5MrcXN3H9x2gd rf+maqLKsM6nfOA0sCRw+nsk6+wnUvdTjNmni2gu5ZPB/kxUdZsFzWB8764MZ7aMNKCxJAUmTcwG yI5Q2p3bjVn3Z+zBqGMrT/oXd4RjDW4C0NiKWBuBS4PwtZGsbPeiKtTCdZ4aqDEerzfHq9pwADZ0 KTVZ/dGlK+TFQWAg6doYsyFqckLbdZgxTtyMr5DSj859AbYexLOLVNKp8DjYCxD66vlTYztwJNOf MmB01pD58xx7pPtOez6syrOstKFJ/kqShv4CcvPrqioWle7rr5BpN7WtdGKX1OsWYswDzb88X+1F 9fFpf5gEXsoM/bPlixbD6H5Cb6XsI/OHyVaOAp+/EX6u7BRQ0Y+ZIzy7Rezr8ocL2qbjsWGUt1cF OybxT6S3V9dSyfa8e43XVX7sS4QFjZGcI8XqX8uRLORxgdRR+J+REYu71jf9Lnu1J5VzpVKmPSNm t8enci/ZynIium/91oF1TUKZ/OpctklKRkr39PiT1IyUHIVljyIy30B+ybO7nhd1EYsIEp8vseS7 rhlthN+/yB5qUHGL5SjLLm9lN0Vebg+9jU7x9hov35h+L7AZs/A2LEyiwWQCoRwT67UbLeE9h6Wz u7vnktSi05UoYhVffJtafwlafmYSoSGVfusei/Do7qnfbK3pTdOL7i+e+Mm0e+fAYqW1Nh7Z0u1m ZZzZn0St8i6nu7jsj75EpDcdMLlABzY7XCZxsxlyFUIXHDPFC/qVwzz8uVf7uzD7gqkbvueoxgIH FNp4M1bzd+WuqXjzZ2R4ugocrMBVlFDtB523KLbL7tCw6i/vi/H5DUkLp2U0VeWk4CPg1DEE8sRH sE3dGMxa5O7pyoyGH+tKBz9aNEy11jKUNBbe6pCXo6V1pjf70x80TawMNAlzviSP3RfsDqqqvj1O V9d7LQS7UcGzqeVqmnNlmCM/+JFr6M9BjgW5T9jijk2phsEtlS1Ha5t30tNvLzkXZiC9y4dVTf0/ ToXc/P3VXQ5lvFReTkrK63flmvTYz15dp/Ife5OILX8RnSR5zOXyrV0mP62krE9ZJlE2LLL7qBHZ uvjSJwd+/74458A0mbajVo6PzVLwhFpK5zbcU99+EJgtMjOs9UKL/p/J+X/U2NYDcDtwJ/cXrZtt ZyYTVtW2fSoEykQZJx8wyDX/U3bgZje9w7Lp4XD/33O1wyuBYR6VWo4N+/yLyfOIO1ymun6V4zlP rk0h5PEMPrnvMmJ25kfnkcj5WT9B7co16wqcP9feyot5Z2Fb3/enKl9Zk2N1P6unZ/nNJPnuD+1E VDo/mzl/bjJiStZTdnu8Xy3VWMnLuFVvSflb26+9n7nePKITGcyTsI0It1/OaoObE1caUx8wKiEV nL8p/nL8mFKWzu+dOu3DSX8g4U/qkh6c/ntQD+F+8d7tebxEok3etjqontWC286cgiTMXuGXsFbr y3xUzNVZ5Jc5k9SQfQuKeqnIFw87a3gk2tXDfzdGZ61hVV/YZGtKeG5PD8lJeqYq/nJK+/m9/D1X Q93KXJ1Sq67SqRcfZ7/xmw8wd1N4/xTQWb03dUGLL8ITMfjWqY2qDXHw9kpzw33Jc8OKvyyQL7cb 56f8zO44GXapbefeW9VZvHBOz3TKAk61LUPzyauxIdHA4gdC+Qmhsnv1MzqgcvJS5LWSSvZha9mf m68mUU3ShucUvL7+vj3FPt9jo2Xg8dQZTe/186nVgLSzQYDX7FOrxrdS857OGYUjmyEHj6V+SXxb aWHsblAgvKrb3qR3GUF8TCplSxfF9CXR5deEiejhZBwcY5WxF68FYBMRPtuLdEuz0k7KWtjgN4p7 /rIj7c7rtgHYl5fiYJ6owTUv2Sa38anspCYk7+VH3P8DQyC83/vMsv5gkmXYpr9anM97WrPp7BqG ew69Wde5VhHXkluAFaqWp3u81quOkd/TPeb68cfdua7T+nWm9bonmi3JZWHW7lzX+UoR36Un8IaH FHHdPBjUsxfQ+8lQB/jjXp05j6TrOid2j1RCBhbzx9HPJVmHXl9vMesTr1eUc/+66zpajAu6z/n2 ZD+F0BiFn/dz4OTMH5aFq69tf+01R+k8fv6Pr9Pwzsm+7sxKvtYyaFBIDD+W2af6KW1f9FOeWX9m 5aBBl7WuM958XSfIpxPrOuPN1nXaFHEungUWK67XI/6aXZFfj65Xn7vsuUIH56Lpuk6Cuq7zXtes 63yj5uXvHvLyjZqXzqzrBKoHdLm54df5ZrfccH9j17WGcLc1CWW6up7zjLqe03OzKFc2ifKOw6J8 9C+OsnmNj1h/WejvKKetCxHrL3ljRBk6WZT33ibKJ6NFeU2MqPfT5C5Yr+HzrH+o7TPHx9g+/1Db J9ikfezyXHW47qJfl/G0juOpvQsUL8eql9gvRyjNo+1dkGOO+3xEjud6yDF/zZu+odPrMh3kQz5X bn55uThnlz0mzsWnfyV45bOCb3qxC/LGc/KAmrdVHvL2gJq3f9pc+RLPr0lK85lNXXR+rVbzlO8h T6u9PL86PVe+xHzkKdMqy7ooHw+q+XjYQz4e9DIfnZ4rX2I+JirNb+7oonw8oubjMQ/5eNTLfHQ0 V8YBOvYhXMpcOSVl67TL3Y9w66j7reftcdbW5R9Z30/Xyq7aj/Afiud/sv0I7wEfA/VI7Gfq+5Lo IzozVKC757ajZv7RajmSYl1Rfdz6HPL1vzP+aF3RY47V+fzVMret9BH7Z5pRfqFqeXtoVtDfh31E bw+9nfjj7pzbPv/lI9aUzLnWX32GYc6Fdd02t/X3EetaT6H8iyKuc6+EPEBAUGWoA/xxp84j6dw2 fEy4A3j8cmOBtfXg3abrfT9RlJDn/43mtoUe5rY8htvcdv4VmttO6MK57QSzuW2Aei7ynRz/pbhe PwLU/k12/fiJ+txlz207OBdN57Z2dW77p66Z2/ZV8zLAQ176qnnpzNw2CjEmezO37SA37YpYj9Dn ZoDC/0ZvupKKb324ci9maYm4/qejH1ilGO6wz1ZnuU2PifKp50V5vl6U2UdEWf4nkd/j6q6FULFb Qdk3QpSbxovyl9eJMutGUW6dLnYxvPZzMaN4dYEovxUzsWmT1jjK8CcfEuUnYgZS/PdfmY6ULqc9 D/Hn1fZ82kN7hqrtOcCkPXMvIbf8HjHvA5zzEX4OBCja/NdXB+frl7J/oVi59HFZZ/aJRvrcb72r 6CHrda98ah3/6MMXy6ttnygfWzC0ZQPg5yPel0g3hOQOu9eB7h6XHQj+1HrdTQXWwrLj1lXrH7b+ tNen1gNHHrE6n79axmV71A6Ej8t4n8+1LBzmF/LdsPtCEoe9HMIfd+e47OXPf2n9bGKutXDp3yy9 u/GeA+GFbxUxl+IXUj4uOxZiDQb6poc6wB8Hd+W4bNz0Mzsa7zxzLX/8k4aHrQ88mGU6LrvxX3ov 6aWPy26ec8hRDlDB/3kYl8VdoXFZRBeOyyLMxmVB6rnYz0f0afrrVZDa+LJx2Y3qc5c7LuvoXDQd l3XxXtKBal5CPeRloCqmM+Myb/eSdpQbru2UW27+/15S13Zs5m2mtuPjHtoxTE3c/0t7SS+1X4/o wr2kQ/k1HhjuI/oXfe75ayFe9C2dvWfRUT46umdxNewlHanmbaqHvI1U8/bP2kt6qX11d+wltaj5 usNDvixqvrpjL+mlnmtXw17SmWruMj3kbqaX51pX3R+71L6sK/eSZqp5yvKQp0wv+7LO3h+71Hzk deFe0hw1H7ke8pHjZT46e3/sUvPRlXtJV6j5WOUhHyu9zEdH98c66n+uxDqMp/WEnr86Yf3mmibr wLb/vlge/OYj65hBJx3l1bQew9cVDqp5PwXU+QhN/cK2Dl4wguPC0F+EXRja3Wsy91ectBZO+8Ta GHzCkTPOv9n6odX5/NWyJsPXYnYAbwO71dw9FzZzGEPOngvbPZQ/7s41mXX37LcWvvNb6+q8xG69 V8b7sfXAAwjyinrNu2vwJ6HAkIXjHOCPQ7v0XtnFf2ctbaP3WH+X97ppf3YLwv473StL8+5eWfwV WpOZ2IVrMhPN1mSWo8Kv1D6tyO1awl97yYtryS3qc5d9r+ziP9dz0XRNZpG6JvNR16zJ5Kt5Wech L/lqXrpjTaaj3HS0JuO+tzFRSQZy8DgRSHe8iuzNFGsyynNiTUbpLfaDKqvFflBlhtgPqjwu9oMq a8V+UCVZ7ActKBD7QQvCh4sy5lpRfn+TKK+/U5RD7hZlQ6woixeK8rEMUTbnibWZ/F900ZrMw2o7 fuWhHR9W21G2JuNlTqX7Rp28l9t79PfNOv373g7OF7ytozWZPo910T6ur9Tcf+0h91952bd0tCbD vzthnfj+8O9Oq1s++HEmo5VT0K7LMWPlbZ2Dx0sBfu3gZ8BSXIUKfveUyNjJX4vyBrGjtODsRlFO U3cKxokdcgWzqwWfXi/uE7+3R5z1XzeJ8rZD4vkf3hTlz98V5fxPRLnjhHjfKyfVen9Vnz9zxe8r 7wPOqO12LzO22xm13fqZtFuOl3nU3zvWfyec3xf31wPceGfn/B2dG3hbB3O68Bu+66LvCs81z/kc Dzm/j3n3Xbla9jz2+Ntx6+Jdf7GGRg6dXrBbK6+2PY+NSOhbQBY+5A8+4n0Xhn0U9tR4ge6exzU8 O2T6TPZn6+czRkx/GfnaDl6T9pXV+fzVMo9LQaBDeHE1yo/UeVzK+NvDnpnwUVjK+MXD+ePunMet 2nTe2n/3n62Vw35h6c553A944Q1gCoL8UZ3H7Rr5QBgw/PAYB/jjTp1H/Pj5GDpH8TyPO5dyZsfZ FLEu9Zel31vvjj9uOnb+MVfunMk5x9CduH78q8zn7vduPpd4heZz17jP53h/dYXmc9d0NJ/j85Z2 9Zz0w5Pvu11H+Gt/8GLews+Rjsah/DrC53Wya2tH5yXXOUP9SGdb8D6Sz5XCtXnJqzGinLTC9Ay9 vOttAuDPRJ6CPeTJX3c96ChPczTNjvd1NM9rBGo6kS/nd1+fL942rnOSgnueEHm6vVqU9b8X5bhT ovzmf8Q99hd7ixHpe4O6YBzD19j7q3m9zUNe+6t59TPJq81wbJd27/qo0r1/C2Ht+XiL5X+ftShH 2iyzXnzO8ttNN1nLQp+31G5dY70z/3lLwm2brTccet7yQ8hvrVlnn7dM/Hmb9b+VFyy5f/ef/vp3 z1tGrBkx/fg7z1/VfwuB/+23fCb+1hk/7oIeNb6pfrt9V/dp8H01uNE3YsBB39dDm32fHN7s++Do Zt9NEw76dvfYKWBtsqXqhk2WQcmTLCs/edYytDbZEvNOocX5/NUydrpWPaZb1WPiWn7d4x++e1i1 7zM9Un354+4cO9WdPWC59cBjljXKp926Bs7PV/53Lgcx0XfwsdO5nrf5Aj3njXKAP+7UeSRbA390 4xc7ntv4haPP/eOdOy3R7+Sa/ubtx4qy/99pX+K32YfUz9f6Ww9jpqQrNGa6tgvXwK81WwNPUMTf uUxS20N/zeKvzVbkc+8fq89d7hp4R+ei6Rr47er4vb5r1sBT1bxkeMhLqpqXzqyB87NrXydy84hy 8b7+xdz0VsQeulScp8vUlSZlnDqqfERd7T4kdiAqN4odiIrv22J0NOGEKL8TOxGbX/K94utr/FzI UvP6ooe8Zql57W2SV5uHY9TvB+TfPedeQOd1/3LXyC61j4xQmvsHddEa2Utq3jZ6yNtLinff047W kzsaN3qbjxfwaqFbPvh65Vzldsfq51L01SloLzv/CwWFg8UofHCkWMctmSbWdQ/8TJT/M1eUOfGi rMgS5eiVovRf5ygT8szvmlxOnnl/9Yqa54885PkVNc8BJnlO6OC4A9R6zrVdX8V1zbej9dyu6kP5 PryEN58Qv9G6f/0VzyXvQ4+qufzUQy6PKt71oWb7Bb29j9hRbjq6j7hMWY7rIf9dWKJjzLEMbCna cJHjXtcytOhqPD5xcoM4I7OeE2fyk+IOyLRPSsXzf98usvroTlF+uEvswY7bL34h1ybugCjLXxfl G2+Jb8ZD74jyDx+IctSn4vXb/izit3wu6s/9SrTeDHEnpPiFrlifbwaOq+14u4+xHY+r7Si7j+hd TkXfrb9P6Lx32FN93FNxvQ+if5+s3+/K71LxqR9E66640CXfJauPaIM7PbQBf2220rnvkre/X+0o N+2K59+v8v2q/H5YtsL38zvvgjnbO9zxm0t+Hd/wsM80nrcjIT0d5YYAP8FfCBBlMznKkHv6OsrJ g/o7ypzcgY6y5r3BovzHUFE+HC7K7WMcZXj2eEd5Ii1ClBuuFeW+6xylUjDZUTavut5RFiy7wVGe vemmaVe6PfnY7y61Pes8tOddansOMGnP3EvIrf56o/++OK87+vuL+u9QL7f39ezg3OnK71XNj28R 7X/u1iveDvPU/PN22O2hHequwPeK/968dye+Vx/g1TfdchOiKI525f0nb/NwR9vnurT52YNRjnwl PDJVnP8P3i54q1WUvj8TZeRdotx1jzjv19wrvgcf/4cofR4Qz/8wT5RjbI6y+K9xot7JeBH/T4ni e1uSfMXbqVIRvwHm7dSLGdupQW2nEJN2snuRM+e5rz//nWM253PO0pvvRRGwQbn8tneu/enbnn/e dY7/Jiqzi1JEH5iUJnJ/TYbo8/6WecXbIBnozUQb9PfQBvy12aq+jtpgjk67875BR9+bYqV7fxO/ bfW1lvePh1j/vPxu6x3/pZVX0x5srpnvc3gaOAI8o75vJwvyPxUY7EB3rz0/e88s65aZgdbqh++3 5iBfSf+XvS8Ba+Ja3z9nkrBjyEDCKgk7KAqyupJA0KIWg0C0rgRUQFERBbeqRASLK7j2WhdcoFVQ oYLaWhXc6tYWtK61CIqCgpYEAUGF+Z/JDK3lAlIVr/d3//M8h28yk5DJe8583/t+cxb0+tYirrjl +MeSeybXVyI1KqnrNtPXcl3nnMZUXbbmdZ3PNMn9D5l7/il/vU/BPSDe6H7ng66vRD7PkANq3Y9d gPJdm5lsDVS0ZmmrCrmv8S7t6E255z0nqrLSTlSp/N1kkwSf6dNrO8yruAIwpu97eBb6X5N7Nj1D f/Ivn9NG7nkK+VveQ+7ZsQtzz44d5Z5Jn7YUlXGA8mmvxxPy3Brw5pyWK33sbTlpe22xw9zzoBgq V3pzeZfknifQuMjawGUCjcu75J4fACo387bYpKOz/2qFjTZoGQvrr+rlSPUTJq1cbxOFku1JypZT mWbApzLNot+o/tSihVR/alGoDWWhC2X7i+i8CjXPruhUcBfkOVIBxXFI3LPawH0yjbt2B7hPbheD v48NJr+3dd/P99Gn85/6VeQPN24e1DXj9Iahsg6QY1YBSGuFJXluO3j7fPVe0Llxwu3hQcal8a3w YIG/jeUef5/CZYxYNfZcPj2RshnrKftlRheNSR9B4zazDdxG0LixOsDtM9B1Y9L/qa8kdTE48As9 qv/3DhF7W18ZQ+MV2wZeMTRe76LfO/tspD1sOn42EvC3ZwSAX6XCSGSiRY2ezTBXWfkpG5UVbXCn rI6QsoP9KXtyFGUzJlJ2dfh7H/9PtpH5NNbftoH1fBrrzj0bCXgvz0bkoGv8ogMQOc7povHLh2gM D7eBYS7onF98n33d30UzX745Wqy75KB4RtodcW149p/2Y9PMN1AZB6kckgxS71uiW8SNNX2qKh9a M6tz7ogbjQ6IL2eUiD+LzhbPUr8jXnHoW3HL8Y9FM5PzyI2F1NjlyZC6lkmm6dw60z+4oaaePHL/ Q2pmA71V4uwNmeKAn3710Zu0+oNpZiSrVOsBLEUlAlLxN4wTxA3jTOdBI7KQ+0Hv1I7epJnFXk+y MsRPVD7M98FyceWgbzocr4Pum0ebB4H+Dv8jmrlv5/q4R7wnzdyrCzVzr440syH6wChUTOl78vX4 QZ4Lg2+OHy0+9W15YHttsUPN/BnTS9UaLwm8OmqVb8sDu9O4CNrApTuNy7to5q7ChuTqYOAgFSby 3C+6BBtrGhu3NrCx7iQ25HVqtYNNZ/VYW9hoiBhqpI8h7x8V51hb9pr/pq5r1bggiYeI0a6vMxbI 52R2iFyX+LrlpK8jrw280/bPfZ1I55jKvs7XWnwdtXFVPo28TNKRzEeft1xaPW9sr7fydb270Nf1 7sjXeUBqXZm+qExq1W49OunrjGnQWrfZzo6hbq/Nktqa9KNttVm26vqHAn90zwSpYuBgMFoVAyXo mLdK45Ptub08Ghk328ghjS6jvMTCRpUtuM0QklZUr6WywNuasvecKXuhL2UjB1N2VxD9Phll7SOF /738oOW+a33PIJzavGccO+AH1PbXPUPad7xnnFrfM6TvfU/3jFN790wqoPoJkb5e3oavF9P3zJty mO20vz/7YL1NDnMn+LDa9OjeMLHJgS3ixD0l4uQBf9mPTZveQ6UPqpNTqLjT2rRnNw/9OlN7VfnQ 2lR2aZL4SMiX4tHYKPH23C3i279OEo9o3CpuOf6xaFNS0/eG1LOMvrQ2HdTtCR6q66nv1U2uT+5/ SG1qXJsoXmewRnzjcyBOdR7i86G0Kbn2DDnHK7n2zKe0Nk3T28NJ0ztu8I0RWcj9PZyu1KbATDNd VdD+Zxfk4p9OrhB3xNc8ASj/v6hN24s9v1SfVVltupCbKn7p/U2bTn1P2tS5C/ma85vWniF1KTmf uUOr2EOes+sEX/Okj72t/mqvLXaoTUfT2vRi12hTDo2LQRu4cGhc3kWb5qCS/g7YzALUs8/XsSHj 2ScqBiCgNOoASqOCFo36bCdlT+VQ9sVJip2yH713DMnrM6IxFLaBoRGNoVoHGH7W6ve8Pp9Oy3ou bWHbWW3bFrbvR9sWRLA+PE//j2lbMPcHlWnpf0lurXn667/1HXl6ny70lX068pUiWn+S82bbt2rP ok76ynfVtu212Q+vbeW3LSgtW+WosgXqbtRr6wFU248Opiw7lLL1tHbdHKey8oqllPVMpo73XP0/ pG0FH1bbunShtnXpSNv60zFgZRsxwJ++Z/4T2lYOOjnn2j/kyaj91fT2kn/xVRc8hyafaTmiYoxK /1ZYkuf6dsL/2LeDx7vETBIPUmeMb4VHq/45N4JVuMjlGygrOkLZBWcpG3WzC3CbDqj2R+I2oA3c TGnc/lP9c/4p9yX7vaDGJ1QhNUFd2BFib8t9vWi8vNvAy4vG613655D6/9Y7YNNenGqrnwpCa0E3 FUoiphWFVoqnysqzvKjji0dQtn40ZZ3CKbs3mrIp8yg7N15lBdrLO0T97fsy+tK4x7eBuy+N+5v7 MraFAehUf532xmB2eu7fduqrFrzLmF3QyPKSX77rBUQulLWOouzVtZT1zaLs4u8pe+KqyspLH1HW +Dlld6gJVdZLn7JHzSg72oGyz90p6+yrssB/uMoWTBxF2cETKftwGnX+vY/ZJXUlOaZzDqTGGrbW nH7wv2PMLhlHUsHbt5eWnOfr7YX8vpZxSAVJ81Q1INq9RGVlJQkqu3PG8g5r5m3qhbyn5tL1srSN eplL1wuzg3oJBh/vGCrjoHKxJveFODPI3Ncf/8t+bDn3ywjjZ6h8jr6kHlLvu2wm5m+yo8qHzrn3 Ky8Xe154Li4nSsQDEX4h6PWV0FfiluMfS86d7AdGzoH8CyqNdDstNms0Bwi7YrM1fHL/Q+bce2o8 Ev+qXy9e2NPog87fVYROPEFlKvonTTTfg93PmKPCT7RVFXLf/F3aEfn7Sc43C7STc0/I3A1eaVmS +3nFZeJuJ2s65Hp9Xp/By/t/Z+7TSJN/H0vVRu496j3l3l27cO5T147mPr1Ct8k7qLxoFVfIcw2d 4NlkG3nXuU/ba5fkdfrRX9nSLl+b+7Rllqov6blPNbtq7tO7NE4P2sDpLo3T+5j7NABSHPxt8dKD 1DpXr+NF/jYx4mPk3RKh4uIdzwAhH0TPjOpEz4y6i54Z9d4DavzaPkDNMHOfmrVKnmBKrwFvSdlb zpTN70vZBmplC/CvIMpeCaU+9zSSsuGzKVtCrQVfIEykrCSFsmmbqJlq7LdSM9iYpVF2esZ7nzOl CFDrVJF1HYn9e10/ouua10Fdz/+HeLfM1drCb1v2W+ukfzIHR1ttq738SletU3aJUyreu5Xp+1t0 zZ+2G8B9K7aUqezHxO9InkKuU8ZBX1BBcmyMfsZjZmcxwpwscutYM7n1h+Z4Jr0eiONs9X2XbihR YUa+3ntbz7fl+MfC8UjsxBi1NoA/jd1ys0vWz0zl1svNPK3J/Q/J8dxtTovjZmj6VjqIPijHS0Qn bNA/GIyKB0bdk4ONxluiYuVnrSrkvmWXcrw/N4WP9MUJ8frT6r4dczwXRBpojuf3v8PxirI/wVqu nUcfa6Pv/4z3xPHcupDjuXXE8ZLQB2wxCm837O/xjDzngnWG47m0y/E6nWf+c+tcu1T1sXCkGd6O MV0yZn49jc2mNrBZ30ls3veaZa9j017espPra+lRfFjeuJOyUdRaZfLi25TNekzN2hpHrVVWcJBN 2U3UbJuiQ+aUDaTWKhOt6kfZnhSjE00OpldfGk/Zqkh6taZZlP2eWqtMsICadXPnppVdNNfgFroe Mezf63ELXY//V9cse729oLe180yw1GptF80xCzEKe2Yb2JPnXLC3fybY6ec07eDR3nMaKjNNZqVj QByqW3JvMpCVUquTyZy30O13B6VMPtlNYcf8hrLBB6jjs6i5OcGaH+g1/vKp14PO0scvddGcE2o0 5qI2MFejMX/Tc5q2Mfh7Dv719v36s5r2NIYcdE37dQDyfVe6qP2KaCzFbWDp3cn2+7GsIyYyLBVP 62fmazjBxPcp4y/7Ma4jNh19wUxU4jA6J2LGtvuXLVSVD62z9l009vWZaO5busDc91izqe93Z4x9 9bOMfVuOfyw6KwKj1hJbSBfyWubY/ssuzQ7YxdhG2ZL7H1JnBZ6uFxubmfimCo5/0HXEntL5mU9R WUDrrNvmX9iiYnfMWlXIfdsu1Vn2q9PBEwcb1fwQm2vEnjFGb9BZrgA8oXXW2P8dndWtc2Oso9+T znLvQp3l3pHO+oNuk+Qzrrmt4gh5LrZTOsv13XPp7bTLN+TSvWillUMrLcuuyqW/pHEiuWFrnF7S OL2PXHqnuWM7eLXHHVvum1Zrbg2jsubykEOUTaOz5odrKTuP1ljRBpTdS2XLC+5R2fKCC1S2vIAc d0naXUFdxB1Jnk7i798G/iyMwv9N3LEdDP7MRbf08/kn65CZAarraev6Iq9jMvjLf6Sj69uM/ftr B5D52tW2h1rbmyV9LeTva30t2GvX0g1Q82sD+rwB+M/4aAaQgDAwDQxFR8LRuX+64QAjbz9VfRCt rqW9rUXbktso1dzHpCb2RWUS0g8z/mwDndnM0PcTr22d+cxVVDZvav39LQjMVuHTotPftFmiWmjp f9TZ72cCql2QGwsxX/I3z1Ct0bzgH1+FPf37Nf7B95PXq0e3E3LROwwVBqSe97FQUUNFHVLzhpPj +8ixU9qo6KCiC6nxVWxI/Q+yLxeOij6kxheRwY7sv0vOBUKOiyH795LjA8m+qeSYgGZ0jXzaNhP/ f/tPb6OmzpkaLbAP9ncQ+M4OnTd1ZoQuPRRJm7pHEqHKN/neGwH7IuIwEVL+h+RKgsfrF9kPMlW1 O5JD2eBL/+RQAV9xQWkNFzij8xpk45Q7/ZC88RRcxvyt/ttNl2HL66eTK5UMo8c16F8sA0R9DfHs pUIdNijBCnmlkseU85DPMgZyAhQUFIDy8nIC/PzzzyA3N7cafPXVVxZADsKJ8HDg7+8PXONdXYGJ iQkdjzveOvMeqUmVgqhRaFcpzB492/miVp1dpahXltcNq6hl9q9S+FYpIAh2h4+eyWuUQ9nj2DXK 0pd9YHldZGVFLXprcJUCA8FJRlWKgSWvNsKN6Aw8uIXkJL2ZrCqFWmaVQr1KoVGl0KxSaGWaMHWq FLpVim4VtRsWljX0voBJkdQ+DZdUIP8aBkGzMf4Q8nkYn1MGMUbocNBcqUwqYFYqt+joE84LDQ5+ cm9hYobwJENUXnceYp/o6/ltwUbzLLmgp/FCnBHOO2ipzwzDLAxYqTy1S6k89VSeRh5nIa5pYZ3B q1QuP4v+FeMMYHN2Rqv56atbh+ibOgSUvlSMFPL4KWbGOCOVx+Tz0k/gC3G1csOFuPpyRw375Y4P jYxxrUW22ua22/UzdIocdZ3RTrdyAwVLKMS/uMCs4rL1zJ16CJv99IXfj+/95eWH+feFAoDahqJ6 l7c2+5jWAoMiR1jkiGFFjowiu+lOS2yGe6RYB3v4Xueu42qm8s7Zl5vuXKwBS3X0w4WnGMYG67gp xuu48giHddwT/ELTBuE5S2NcOzOVp5PK003ldUvlsdELvVQeJ5WHp/L0rVM5lcr0IvT7XKHV/Ubd pmiMqdEvaIDVoP6euAMYpOeJQ5kUk0kHcjI9caZMypJJ1WRS9YJBejskOSOuSyp865WY3j5ZJscT 58ikuEyqnymTGsikXJmUJ5MaVsqkRmlS41SeSRgzQ6M4yPRB4ELcDAxInHwNfSnHWeLHBXtuMUU2 LLZev5FpU6cPuBsIHgT2uBsIz0RgZyIYDwIrld7f/M6cHtlv5A/TKpVHS5kmlcrnOvoCQTivR3w4 z0pDY2D8mHhvO4EFb8msgO2u6YY7ui/EmesWsdLNvlAL01g/5OqsnVbrFmkOW7dIa90i7XTDSuWJ B8wXlcpvY6YqhMn6yd76fSUzBxobrnEtNygtcZNic1YzljsylzuyljsGJDllmH6DLuKkicZIHQNv LHJKcIqZ6WG96RPgYqnfgI2rR1Yq85+gH/MiJhrEpH3CHRsyPWRJSGrI7pAciei05GxIuaRBojXG GDdI5SVxcWmBgjluvd1nZ6CI+NR2w8XJLt8L18sPXAAHIPjfXLf3U9ere/YuPTiHJb246+H5r+ek Pc5emrYhDWSkHU27mHYn7WkasU7A1c5O756+ENc78vV2fU7GcXzjerSjf+64QTqy3GkPj/Myjhtm HDcSXMjYvV3f2Ob8gMnruKapPLMeqbzuqTxzXHqhVsNkwLIiYXLhVz8OHie0OAMgRzMl/Axc3L+o xG29e/E5sBv9OYTK7iR15wMr1Z2DV/oKuOquPA3dw5q6h69r6R7W/vSwHp/HCeNqenyt7qU/tYB5 Br5Q7tzGlGvms5aFV9RuLGsIXmg32vBhvZ4dcL64e5L03M195oHAPd+5uJnDVE5JiDA2MBwliZQs FMsFJasHp1o9viEukZZ46Ov00D2sq3u4m+5h9iC9tNzvtMsP5h1xdA1jWRi4DUvluS+y9cDKLfX7 eYf6VCqnnWWuL0kvKXm1qazh2752o12Fq+otXHfUPGNqVWiXw77BsOJm9h1itlCUKNws3Nt3e31m 7G9PWL9VMJ3v3pFqPAgck6/7KV/xW6/EpUdvXYliu/UlhhHdniQn1tyaNRX6+22csvZKNMcX+y4s 2IHzbBKcNZAPZ+F9Ukd0Z1c1cG9dieQ9vF1kLzqvDq5wKn/RseDi7htqbrF6NyTC46d9ew+3mWBp eaTy1pUkeWQv52XIG/FV7ij3bNRcN+VIbELy0Pu3riyPMfqkIVG+f8b+SasIhW3eeW/Hbv1ygKnw rBPn8XDhfaKKaCLYbJAhPNp/8TDHurUlRez77GkvBDoWnxNriDSi+EbzDwRHAqwk7K9SfDZOcatz 4E+V+PP1QvjbB8q5hyysEzxHb7p7HRyyWDfUgnuGf51fwW/kazuB7k5OTt5OQU5TnH4WrnDa6gS+ nBwomSx59VmNtNvUTZL53YGbslaQ6G5ePm6sbXSNhBlSxAuxH3/Qwu7hNudlLmam52OuyfYLf41+ GG5XZlTlZB7NFmLgYbijm/siFua+iOE+77o0i2PDfxYC5ktWSmbw43lgnfa9JLfkPoDzGKwDW44a Z3Gars6PXhldtC36YLTnmC+CXdKMCBBjOCak19zgATCM6VMOPEvnhawI2RpyICQ/5GunH5fJi6Lv y2pSLs1pijaKt4jH4rDfnjAkOsiR5zFY6XuNPK4vu7SAcHVQmIbbHzpn80AvDx7G8k2SY9eBAuez 53pkv8zW3Mn42jhPa0/AypIvhFuEBXdnY4aGScuYZddeMgqUJYxqbrVd1eEE+0UPLmQcxi6aJAfK 58Ck4Om7svC5t4vmNcfNH5vX4+xp+e2ipQFTEmLzLt9jgD1L8yyVtwLvxmRx4hdBZkp8Xt7ZU6dP bOHP56/kG23jM1PMU0BPl5VDs8d9XTsh5QXT1Tc4wPRRnuHSEVG5Z+DqFFP31B+xM2v9r6+xK6tK aUphbx7kWuQXOr0ss9dPU7rfDdsmBF4lATeeR0enybN7zfW77hWntesOtvN3xs6bk7PnZidni77K Vublfq12+OxOaezxwmxwL/tZtnO4Ue6g8p5EVUlTCfNrYRP8/ITwcfU94cFGQghcicEEPHaMnVl9 vFrBxvjAwOTGt5/Hxyry8jWiTaJ/jAffSs5IkLuX+PzUTx5cGP5LgdYez5Ch43cUah+NDQHjRNcK ywsbCrXTfFccSGKYb5LfLZlHrCB2HJzkbF99dpcU+xE/N7h6dPXUataJwX4vOKCIuE8Mss0NHd6L w36S35wv1yu0LIxgDylcxZ5WmK0l9l1ZWKjNzCo8cebSVbXu17T1RGfWDjrQaMTh8K34vu5mdsXh rmmXhMrJWGIfo8gSXbazBGP9sCkcwQxW8g2qD/L7Vl/lP+DX8+XVYMa8u1bWTh5Ou+Jz46c7ObKB FzuAHcaOZf/u9IdTJvs4G/zCLmXXsGcJE4Qbhf3ND3wBApIm8PtLPpVMlGTwj/Iv8sHXku8kBJ/T 45hyS35W/ol8eWH+vXz/kJCQmJBlIWqHnUpdUnxTRiV+HrW4UOosQbdueuGRU4OSbG/4SD2vXxFa /yb843Fpo3Cv8rGO9qbb9qlJ+64/XoU9Ws149EVStPzL6H3RP0Tvz9prt0byTQ0vsSn60kp8r+0v kjUPjtX0Uw/DmRuqXdMGp12svlMNnlZzatUII6IHcTklLVtGgOdpmtmbib3KhJicuv5BXPxxDbes wf53BQBpN7dBac8qBaNKsaBKsbBKIUWRalmVIrFKwapULn5RpVApF0TXONIhKkqH3un76Fn4i1rA UNZ0YxNEpTKAr1v6kmR3kV4a1lUKJ0TtEHPT8WD7akkhYnIVtevLGhJXYIR0SGn185dNS16yRd+o bzhfppz/fOBJ4fes/CFaSfk+uwLs04WX1Zhurmz0PxF/Et5n33uxCdYpBY9rLiShC/NbvYvBNCgS +vCDeU3aiiwhdDFQ785jL8HTr67Q2LuLcb+xWYAYypUmZzWGoSv++QpoKiP63knRXugIPiXkTXJH 8HLELiLQEbwY7RjhGA+8Z2gvbB71RJ9wBLOmzJzkCJpv6N9NyZhUP8LRCcwZGVyiZ1KG39AnZox0 BB7AERBBSFZGIIF5PdROMNRBILET9APrnIWWWXqVyugkZjI0E01UL9YdaXO/8StOed3YXYzIw5zD HBcGTEaC8TA3Cr6qV3BWYDLGH/pjs/S0V0CIyFH3FTBfS6Y5BEz/VDDvJZgUoJK0sT6DbaasYEqd IpxKXi0ra4BauxjFcABnhGtc1eMawTNUf8WI/m8jfBuQ6lQomGwe257twkKVsoEgYMOqZJiy7Dmx GkggZK8kGJhiFDuSvZC9mr2DncNeclpzNdIfy4gmVFlq4ydHhYUQR2bfCHMOvLWEaB4V9y+tEZiz Kq+3yU9V8xpVtajutaoUTPT+xzU1So6uJkzk6z54Dklyjzgiy+dFWYOeFxb8w565zcTPM/7wW6oO x4R8rxPGi/RiIsbOdQtjoG8zK3klh3KY2U8TQ00PY7KGaWxFn/w5B1O1kBLURAjhXd1qITHkmIr4 3j9WzippYF0VBnhoFl5m9M6DGAt6Q8g87cBVZ2K5cID+UagOZvByIDMuF8gEj55llwpZzVY4w4HH 8mXBrRh05cnx4TgciVux4o6CccaVykQv1KZud7/FcNcFOjkQkzt9CoAoE9+Tg47bHLzFaKpR1HOa Xxq4azc55WAynMx4xM8BISAIDAkGRG/VEKsZIN4CWAF34Oxp+dSjStEcmoPqtCfhN1scIQrTjHgu APY9BQ5IjF138bR0HSvw7y6YBJ7PBtF8ATk4Ly52rEA8UzAbzFpkWRc6VzB1pmAmwJyriyVj4iQW 4ggHu0DMWSSoVH6Thy5rgr7CEAJdrhXcKcB3W6Vj6Fiv48a5+pjVVqYGZqcQ9lMfb5DPPI6O2x7n H+J5aoXCSuW9ncM0VkHbQYcMIBCh+z8mh8mC9knqw93L6wJYcB43SxfJobKGIbcYokWuV/vocH/3 +N2j2gZ6g4SROBzP24rv07/YJ5cbuPOW1nO1J8LmvkVcMBpvBjoS86EV3OtuGG+4JFiSC8BIvJu7 segzjuCT/TYuwzV53vczJeOHXZWYe/+Kw614QiY+Iw9dSzIzKiRrwMUeZQ09c7Dgo/DzncG5+NBF B4Ir8MXHgvdbHskxKljUZ1vAeINqq3pjOWBq3ARQsMiZfQ2XYYV6YY4RIsEpS4bMAi7qk4lfGlnB 9bwZ0mjSkAsapXmWmIwJJwmfLqmfUrvJJHK/zSnX3tGN3RtHft4HTvFdw0iducv6W9lAXmjIvRcV 3PXJEzhbgryhJjPWG3JY+3KM5m0JqufWc4pH/WFd28y/YGTMtVK3AROdxtvJ7C2cAz8TiAQXtX2t 4uZi8bNhGCOMLWDJE+5wdWQnsaMQnIu+92K/zZPo5vA8izyrKkWfvAdGMEwebisSx2h4nwdguhpT E160gGCpdBU8vNgu6Vvh9+qVyhX2pxflc7ovW5ljFHyL+XM/+4HMUDjDN+wEaM5NGBbU4+RyxjE1 LRnGkOPFCQm5+KoHRonQY9i+lB+WQlCQkok/X7rfhrHjBcss7cwK0GPds6R5XMam4oFTtuevSdqy 28TdZUvKAJbmstneUCsKFKydA1l7YEEmbtFtp8avnCmgvE7rh1nXT1cp0P0+E0lv8NwOYI9rwuec 5CM1RJA51C+PmhI/RS2uCQMANjfVArAxMWqYcDTmKr3fyKqoJUPEtj9GwGotAOJXQ3KuL/T7iVrk gT5HH3/qX6XwAcMBOGt+fhi8MAGow8mMxKXfiGDFBNCsFClr8qKrR8DHE8BTRgAEW2FnYk5FLfJH J+xVGQXkW/QCSl6NgWPIjAEKPT4adSj2pK9QOZZ8MvawRVnqG+LJ2INCzwkWQcYeMvTsSRcWqi3S LGsgI88+YTkKPWTkicAYWSxWlSKpSlHTW59p7Y7UYQEZi1IzGMvUCBEt0a4Low39Y/CLcqPvx6eR HuvqeqNZ5nOSpN9xHh7h8fi3+ImM/sMJ9qNnF1aQgSyD8eOPKJDpOvFtoalCyIWjDNQteOyhlulw MOvxMZlRRa0qkjU9clZTNxyNryEjmXd+/hJHUBO+y+LucxSjdlkIJDC1eZ8VHc0IOpo5loB7kmjZ GXTcEwW144I7KdctsiwIFNPIkCbPdwQmI3YFFtvMIOioFkTQUS20kuk8VM1ZwnTuB5z9zFzmClqi 2kR1+3u6vd3vN+4taxibwZBb5Mkt6KAmt4HuLUEty2qu4IAqqMVZoKCmdVOmKXZwnlngPAWMngRi HZxnW7qjkGbvIvQVqmKaVgbDnQPULHqKV/VGfgoFtRpFdU0qQYxvFhLEK340QTSwNdVfMTRBiBVB KMs0QSMLEK8I4mVzPPGyihD2Bmm9QSHR9JKo6A+eEc38hnhhM/8Vv5mtDR4qtCEwgBqgWXiTIDAF WEswUPNhryaYCoJoUkzTXkMw2YQGkbyKYDXIgaJYYzlITiFWQ7WGpuSZIGUVAZOXoViqsRLF00Se DKSs2AuS0kEO4wCQJu8Fyw8zUo6zUs5BIplgNICURKKEoZCD5fdAJntB0hTsCWgAyYlRjJBkIiE5 IYqxEuj9ypQvwsLhGhn8lWhCd9rfIq4OQXjEdAtWG1+98OX3s2qUzOCwkCPEbK0RiXOLE2cTCQIw HwUSJjHGHuxeMjshkkjuv6Bmwt2UxfFjHFDQ6Dha1yvP0tHalaWJInudDxWtSwViYn/dkh0j5AP9 8lOX63vqomit1aNKIVJFa3syWgfL4Z/RWo0pVfdhalbUbi1rWOANCAxIRSSxqybDdqX6kcXawlfd ryiFQ8rrXjGb7jENA65auMYven4bKxABmIxZu6D4na+K3/mwEH6veRKrVKoDMng/paM3Ct5ZzSZ5 kOHOYw3lwZmhKOCjqC1DvvBAcyhkqOdDHS+olrkB19hiprbF0DAHi6uXA1ncdj0Z40FYNQbUms/g ME67x2WObpFhLxTdf8Ev4ueY1zjqD/FSHFox5L04CaDZMgeqqds/N8qS4yYWVjlQ46Kh5o5SQ01t ubeJRaUyqYHkCCJLIHUZYSp8lIdEmHAgIxEee1yDMQEGYJTNzgKSLqyCFWCabZ4dgNsx8kHAdjJY 322OtRJRDOYlJiqzUzmLeS6NwjpbyO6dhwnced083Qy/w/vhGpouboZMI2EPIXTnTfMMELq5zzT0 ixUu7494ChnkPQ9aD/TQ2YZjmPxTE4upuGCay3bcDd+OX7Pcc1zFV2KtEF+x9W7u6fsGvlJsMVuA 6EqEyAU87UcSlju4rKcfQfMVgdda9D7EV6JEkd51ritF/v4icvD44miJiOQrsStFE8Q7RIiv7PcJ /VrUNHWHiOQrxZKXY+LivRFfCcQcnGeJKpXbhmm4PECclKAc7DUh4TLb7HyM2fl7IUJRWu1Q9YDC V4P9r7Ck+UKBoRBj52AHZov1C5qdA6FHEIwoaO5Ro69wli31hr8o9URhrG2ijXgBa8zSXFgIRM1B OCM4UDuOP05Prun8zI35iRcu1xQHGSSOnGi0AZ+JgGGpBeGsuIl6E4xnelsKzoM7srh6hUxuLhDt buy+w6Jcj8wN71kYCjdMNFDkp8ZpguEyVpjlN2Q6V1/wyQYIiJF+IlgkuipOz/HRUOI3BriImRou nygMEqx+cMj/ScP2s+jjDv3V9SYa+Iu+ZXhDsyT1i+79NBNyZmwsa5gPr7ud4Yxj2m0FLoRPzPHF 4QaDLTR0p/iElr5kuqodtt1glmEJZ+UxcyHJhrbF77GrVHIuljUYCw6BYG8o1hcytDmZkfZ3Ls2p ktTGC2EPtzBFoD4Y091YFBRhMboGFNQOYXkFYR7jGhmDR53BNWRqjNVE7JSa8Pwl/hLGzPhZIif8 JLYdFTGu44bnQi3ghL/wnOYixjVm4hkJUZYxGPNadHl0ySsWIn/ji63Z5itsV9hGTtHzhlYpUzhB OFyBTxT0i8XCLCOOI8q4Pj7w80Pxj2ug+aU5uTDCIsK2V2iv0GuWGXmR9pMvzdGZIuztDafHzNn8 BRycg8WOHKdXX6mMDbRKVwvTAN9o7rZ7OWYqZ4NFttqp1DDLx+uu2TgHvdxkKzrL2h1liVgRC6ZA ihWFwp3bK1dkayJWNL6sYeUcKYQ2YSsj7aFbsXV5HYunuUe6cS0vauPGtXilMmO3/UTT7XXiB/td F5Q1KISbBQNfjMQugut6HlKWUe4NPWbz2F5hcPERWGA66esr9nopcMhRhlE/NbXHLvbLwiw1u1lG rlsW/KXm9Vsq8oPUbx5NfkxWnuTXISeoYj/7mogor9L6U7fJDiam4NGzUKNNfrNH3yTq7jeqUezH rGYEnMRBwuyJOUV+tr2K94YSfQCQO37uA5BDPvv7cFgiNgAgMFQtb6mdCG6KJsnP74SypsTt2Qj4 ZTQYyAIB8ECn6M+bJLfwNcm9mqQ9+Yj3CEt+PI7lEzT1Sc8gZff/I+5MoJrI2nW9KwNhziAgOBAC CKhgmEQcqwAnFAlBYqOiCYra0moARXGsACoCLSGK2PqrwQnnDjhr2xaDOGtAwRFNmFHUhDkypG4F 7L//c9Y9956z1r3nZK2sSnYqtXeoqvd73m9/Rf3lulcP2G6oU0shbPejQd99nNLcXg7f/OG7B2z3 mEHfnW5822C7Rw7SyqDt7h+klbPhEC5yBwY7jaEEuBho5d2QXnegZv5bXlEaeOUto4c5CCxfGe+l ppxq5r8HFtb/FlgmOgRPduBNdDAAC/9fbDgBLB8slo8aBJbj5GvMq//iwv8GluohFxiX/nbhA8Cy 1GFdp8MgsCx1SPjJ4MHPruJuHjThhAenAn8rkU/LqUFeASBXr2nbiy+VoDiOYyiuJ6N4X48Z0JkZ bqtO68DJaHcHDe3uviZ3AGwHigR4kPHt28abxw3txkXBpI82EI6L2AsAjKvw7ak4JIKgYoN/T02C 0MxuHOqOBtIM3Ahv9/fxwdEMw3QfmYxL03Gc1k4cDWQc1aTj1LQsQEtLwwnLj9NQ+veP2dAuHELz gBTID2XTcel5ICfhh74vAeeMcJAFbtC0+hIaWYprU30gZWqqT8ot0hBoN9hPIZeCRGjXEygb4Cly AJ0Dd4E5k8S2YktVuM9+H9jdRmvSfQjA9jZaXK7Vz2KmJRnF4bi2IWk/MFrKqAYZOAlFtakgE6e4 MDRSArYohBvALVKPgqv/P5GHOoA8jgTykCjadqaFsabDyaTkn+mJf0Ue5zevcKZV6pDQVIsY7G7t 6mBDgsKEQJ4pA8jjbECenL+Rp6vVKHxgytGHSjDPzB/MY5NZtkxTGNkHN9LuRI1TEFG+rdsI01Fq 13VTa7EwP1MSQTALSV2tBtLpajWfRlo7/O8EBU4wjqHYERHox7LIXjbUyTbQDNZ8A+bw7K0JLBlh s2jREMsCiBZ90s64wPrSCIJxTFMYiTBDhBGMQyBOkS10IdHsOdPi5YihBOFYVbCesig6W/JXVjPL 0vnF59ajBnrJKiAJkPE3e6i3e0gkJMR1+igyRB/Lmk4az1rnOmZkkkc65GVzwpUsGnHRjYja9Qac oakpZvZEuMYH4jURrhd3BFM8lXCPcwVp/GQMHjEMATYPhoQMv6b38IYkI/Rj8CEhn1MYRLD2iGIs o4LtCZ9bybQiKhGtYyUACfQhC70T2SmMIMm4KBtPFsyaNJTs4R1AyfL294+GYobALKqHtxM1MYwx YeLn1jwDPYkyoTrg4zLFCAbceZ/aDpycY/z7VAPjjA/Qd0wiIOcH4+CGMhQD4/QTkDPIOPhaMJiT +eC5kaAcfwPk6OsMlGOAHMxAOcAtFhk9HzhsQTYF+BxC5kUhncvFnuKlyGBO5hASdMnAOH8EdkZf Q1ZfQv6Zk8kK+JGTQQnGORVovNrzfi1kTLoCvXWaGkAC7ynGAbO08EQjYyeWCXmnYZp5LJhuMu+o 62yYdWxC+Q++4Br44htjQQCkQmqCMNJDYxd/oberv0mYVRTBEkgAdJ+5hzKPOtHk5hICJuKSoMkR egNNAO8+x/nxd+wWBFI5rAgsi+84gBO0mY+8aYKfPrdCq65SbgwQxSlx54TPrdYEUTALSARQbOZv nv+YiGyv3OgvlodZuSAZUwMgX8c1JGJ9IuySARF2YealtbdWK6ifW9+m/76mjhDLzmiQsczLzXcq EXbRRAkkIqV4+S4LAg+9Z/keI3ZyJnjllpT43VK2dZPDiS2f489E/x1E3aHBIJqVTgTRoT+C6MWl eBWjtdTcC4BuCIzUtwPLYy+EIUO/eRYMRNF+IuiZd4VCy4bhBEYP5BD6iTharZwN4cM3ATCBBwbC KG71YS7kN5IIxcSpGUOenoJAe+r/GUmdu0OHQxlikEUeCKT2n9pMWrRDBrLcgi0t2q0t2m0t2u2G FPjpDS1aX00Hccw3dUC40+yO5dc22SB4MKVptm+PNfKiTkdiE3vMjFAFFhoEXeAAMIz4apAHyV2O QGUTAMmRsDLk6g6BzV+dpLZoqcTP32XY/F9VQ0PBv3RFJVRF36KFBnvDbZDB3uZaI3/3ht8bMQdi OBKaZdWiJXqrPzEHEjhPAJYt2gACwKo7BivVe8BgddF/0BO59//yo6xOonMgCdENsd3tAR6kPqKb rAlGhCMjujCUr/j+u1p5y/9E+cd/5YEQz1NfQqEHnMFbXIcPtFQTLd6OgzfVDP9/3ON/9WEYj9XX UOiIo+EfEf81HipxjE+pxgeS7pb/8Zv/jj/hDOK5kxgg7jRQyUkM0NByh2gxd/6r5X/2YRhPBzEe u38zHmEe8Ydxa9Gu0WhzvuP13QToMij0po5HxLmR82sQ9NAUPAGuLdpAR/oCOrC/SyjKt1Do1TCw t6dFO3816WJrKPSSbgeAdBNpL11OL6SrS+lV9Cb6d3osdKQzFINsiYNq/yYSrG9vJQ6oOmIHfrDV aMPA9BZtyFdFKOTi7GZNIc5WIsxb9FCs/o+/4T9X+UT1bdG6Dex8c4H1AJYQFlvU3N7X09HaBkC2 OXA3Iigbq8bVvW0Ek4TQ5wNgIPmZA4nMo4OlUZsJtiRLAo2yLai0UzR1b6KhNupbshEAzv8sjTJX 9b2B3hgSnZUfSM3tBPDfoTHIgED+f8oKPHDC48QZP1NKsL/GkPP0t8ZmmqKD4A/PsXGnMYVsEDbE HI5m1/TgEE4GlCngyKtdENVlMO0JrF0LbcYU2owttGFBV4cIPAptxhXacAttvAptBN6FNj6FNr6F NuMLbUb5Fdr4F9qcZ1EK2CVsUMluZOvYptwR3HHcMKfPrav/QbH63CrbRdBIY+f97x5a2Gwq8F9v BynryIxdkBmLxoQoNtc/EIRkxhA5EC6vQj/Nu5c025sa6k1NdHsDIgk0KDK2zW53MmHpacwfydeW W/D5qY/+8L8VNU5pyLw+878wbb2A1O7V0OoX6EPj7bdXgSYKU0yxXeilphir+syY5OAxUdYGY9Bu 4Im0gMOFZIjGgKC0ADKrT2MGAPMD4Q0C8AF/AoB+3WkEkKCeVv3ID39N1Pkihok65eBEXVFRQNyM KGsJbx/vVPBHKY9wPDuu8x4GBPkignVI2IqXyAZfJOHDjNErjK2+ta75QItQ4V/bzuIWb6BEyFDQ RsBlRvB0QzVbi3YMvwmyyGjREoJMb9FO8zobwBozEFasmjoIA1LI3+nEqIZmN3TV8KOsv0aMAp1L zYhlCEe3uJf6NWIBZ49u8T3ihVvn0qP8T5Gjic+PE0sR8flpYhnLAbrFITO+RrAg3eJLRMMOQ0Mh 8WIPscYYYrmPY6xb3ERswbNz6Z/E+yOGFYqJF/nECmXEssDQMM3rU+RtouFswKfIexyJbnEF8clz oqGKWE7I61z6VvA1YgpH99MjnXHG7zQGCYR9a/3Sov2a+5bCHGrGsDVjWEczvRpatA+SQzjMXBqj Mjl3AYdpZ8YYZsZIimauqGzRVrVoD0UzN9EYv/YmizjMABrDWBbLYXrdojGsZSyIuYXGcJTd38Fh HqYxuLI9HObFSBpjimwfhzncjDHCjHFfEs+cTWMskB3hMC/Z0hjLZfkc5kgzRpysgLOc6UljbJfd 5jDzie1nyO5xmAoa46DsOYe5wt6MwTZjrEpmzqExQKFsCsdm1z35K3mzvEdurgD2iq751VBIgI6/ nZIIhQSBamI3trVGnl6lKDChMUPmxS3jf249zpfEEzahDkLqoNrvx/kXVqQL96xK/2KJ5HkeTW1y e8vv4jZ0ZRrb6unXsotFnrbmjdoRE9xu9FIn3f1jj/XvtMQXValW4wrvUel3N2IgYwUdq+kph2jM RKia/s007x7RVS+1kdPYOePO1SqcE304rMwCQfANJ9uezoCtkatrsICrrzZcK4O5k6SBUaydTW6x nO9nVs0atsJ7eggnEYKep5wpiWKd0Rk7V/E7p0N3wi8ikCQ+3RuKN7ZKhJKiP1/tTLxjQn1GkQkG Zgcl8TnY8qISDLiGKUzdK6Ks/avW3uGpolUUAAgg99/3CjPrmMm3Fxf1cE+o/nHP+OKDiw+PlkBk zbVS94peqgP6fvH98CK16kL12ioKjSn5Wvj56j5Ns+u+XY2du0oj9r2Btj6oj2Jtq6w3Y22n1NT3 ktbZN+7W/KY5r3kcISpV05iX+Jf4NCZz1eEI8F1jho/Euf1V/Cq+GSspWn1hxRTO54LGwo/9ak03 1tu/QwPfLveuTYZjLzUWFvOfrgj1XvNTkGkSCN3u4F0QruNbR09WgLnTraMjFXz6NkWWIk9xWQHu KV4pmhU9ipuYPeaJBWIgApOokrBW+hHsd6yP/gJT12NdmLFymDKfZSy/0c3IGIIUgT/gJ2S/2Ygy XBmj3Kg0FM2Bn6I5dZku15UPle+UX5R6JWCoHFW+qpmqaE2sapsqSwUC4MuqeyoJnA73vMrkWjeA FpirCdDM17yAN2kW4r/gYDuOaSo0dZpOzTfer7zdOJiK8/DZQiBkCQ/i5/TW0ZK7eDkebmId3fb9 SjzJWEByKzK1XeYXfQ5ypT/dmRENpkMOK7jiZRaXTHaYVLnmkBj13C6u8cQKukDo20I/x66daXX6 pP+0+JfR5zIj8bnM0RQEmb1TbggMOdlWvCXaKjh/fP7BPSPKY8YuQufyZu+1QmYORcFdu+TkLHIl 6xAdTa0Z2dWq9oNc+ZBHHeTx2CvnJk0zPMc4blYiOnTWeuM4vVgQZusxPaKX8/47ZqqG9iQtI5Oi lMmuAoLtD+5JGvMMHtedzL6cXRPndR8HtoMZ9smQeVcyCcQ9H9LRtlSUBgGJWZnnlqRsM0S/KAUS SROyloz6ag3Wcg8qnTQnOV2dCm6xw1JZ20PHI2Lj0WWf2/jPet0XG2/cCf+rhb3QETw3W4kcqAg+ gJ2D9ZvWLdh1PskJT/UuDR0enrpzOWqT70UCTGjm8UxB/vgpyiHvknlL0OvbzQyTGayNNt5iHH+X HHeXku+FCB2OmOaPXyW0F27gn4/yH10aHcGVixUmNTleEKm/oz8x31Pk4NhbyGb3Fqpg6kOXDzPg +KIXVl/tto0SLmTAAZspCBSAwSG8WUN8BSaK4QoPBWk2y/5sUL5XkixJdswxRTCmn3U1yp9+NsjB KTFnAujlUwPI4vEUaoCDWI9NF4MF4p/FW8S/io+JC8Ql4kpxX6NYt2peuFXBKy+tMToMdUenbbwR /9s88sTceagQjUdT0QPoGbTv1nY7lz8vUL+ZHwVVRVZV6FCrl+0oNZMaMFTaNzrdzuW2pXLkyUOS mjg7V/5eNpS1a1zjRikEPDT/kF6SYtIUbg63U0qT99nJ5SWkZa/0tBjgJ58tXyRfI98hz5afkF89 Bs7UGCpSb/afqYEUIdhSDExQBCsWK9bm9X+bQt+vOK0ANxSPFO8VXxWrxt+uomMcDPhgbwfKGLdi ezE5VoiB0utSvoOsEvs1oopjUXzbGjxi0585HHB9tp8PvwwomaMCI59QJlZx/PkJysxP2coTSlKs c+ZJ//hRYr8Urvn4I+PApBkZrovK4se94QaNiue6qIzPWWWkHiSZW7nHVqnt1pX1pbztbHgqe+xz LXDHHc9B4RymjlKO85xXBoe5jZbaBjK216wela55nj7m/W7qzNuNYF3ZE80HNX5cYpTaOuHBQZLD TOUKOPZREV03ruyC6zc6SJu9ehR+WuluKInLCkjthGJq5/zp+YFOEcrrLWdZziZVpkArhLfqsgLW ldXM/dPP+KpnoFBnvha998prCFtumePHbhgfkVK8dXTMK+9tzn4xqW3bg2JiWet2G38Wgj6hpZhB d6TQrBeL14pRsYNs7TLr1LbrTNdR/vvI15n6hmeDGV8NDv8ongmGn468zrQsav6FHPFpBRoEwgAX zI+LA0srjjNTk4+y2TmpybfZV1Dwka1lk7hWXBeuP3cON4oLhsES7j7uKe51bi3vHXe+FOi5DHip 1BeeCUfCsfA2WG+8LyZP+2RNXN+0/RJCCv1mn4CvwuA+/Ab+DB9rVMrSyV9zbXlgDG8KL5Qn4iXw dvJyeWd5oFT4lPeRp+WdVFgJXYS1CtCiiFrwVb5JMA+TCU8KrwmBL/ZW+If4mVgl5oh9xDPE4Cdx mPIb1iyWiwvF55XLlGCD8rvYbIdrjQPqjV7d7Fqji9hMlcVsmU64Rg8y8EqKS49H+fTkdDSmEoxN LonfU3VQdW87PV29ecIZh66EmYpIRew5H6mAv3OetNJM7ll/WqIb519/LpMbSchhkFHOpa7+rZla OLUzX3JTBkm9xuKLfuggQDUOhzbHa9cfJPWilXVBR4si4yvjgztXHZqRLJ3klUO/SehgEFA0TGtS 1PUFgYqyQR28wfmO/QqgPeoX5FsklD+CMOxHJTeTdvw6dVAHg7X6/X4/dHATDJlTKggdnHzyzoKE h90GHXQt2GLt41qgL2mDHuLv9NgB0FmllH+HdwmpxyMTmQqnvAYv19NHKpIyxxMy2P3MfXFco0EG 8RE/ZPAneUfwFaA8S60opAZh8Mru8vsLmdadTqvIad6hw2+3f3k5rXFRDckJQGeZl60XNUw5WRoI 6Wkffuig+5bGwyocD4TipuxcVIOcUNa/W9TwSClRnmOed28uyfSJOEh/zT5SPLUQIvUINyQuUg/o IDyog2Py4TLJmZrNVp1vnyYWP0pQnPtEISMBHCK+etXllsWzU9mUA2zvWvt3pYtq1JAaursvor7M r+SqezP9XalDZgOYekNc4Qz9onq5wRnao1oJg4uqu6pyVa2qQ2WksdWM0eimaEI1oqYBHazxitOk aHI0+Y2EDtLmTcy9pnmgeatp0fRrdHSc0781d0AHoaOIdtsMs1nbghbja3udIR2Ky75vzR3QQehQ sHbrwVv9Je269twFH3EIOiAk063prvR6eZd8CV0npifTaYEDOgjFGOrqSuiV9Ea6jm7KBiPsW/le 7CC2w/ZW/mr2VS64z5WzC9ml7CrGinWn0F42sOCyuV7cIK6Am3LaUbCJCwwl1gHofHQFWsft5NJg ih081s99auUUWL9TAPvIwebJSJUUPg5fgcvg1/AnWNsLP87ZGeLEEyDoFbp9U1/367w9UkOJtpH+ UBdMnG1z9hZDMnSnhBKAHjpcXDvjOa+eN7rzMB6U6LD7sxZG8IZwi/KLlZaIbraCnM/PD+uA86lK hLMbFrdu3k8mNUOyEOEzmQt1OuIwpjvx+e0TBZbZ2J7ex/de5Tnj8pOR/StTwu5YLx4qradZIlBd cv2izeu7hU5i7XjxLPHC1ZTfkffnK3DVl/VtMLLpIAbmho17A7+8Wjvz/bWHcN+ZuI1N4ghIBvRi Bhr0DJL5ocnS/dI1KNiBZqNVjBKMoniEvo9/sh9SN6I61FQ6Qho9tuX3eVIglMZLE5So8oz0lvSJ 9IN0jibTcqf/IvnLnDLfaLXQcMnmCnp5YqC6ez3YME1tuDhQkDBNHRSuXheiXhFV22kqzhZEiQw3 dPgwHWQ7gHnh6o3gwOpAtUeOdvSJQBOZB8ibbnKkRptV7ygv1WyefD8YiOQJ8p3yXPlZ+W35U/lH uV4rFyANVWmW3/E0gCDLUwuy0gT1khM/sxVeCqOgOtihOxFVDEnlLVNAvvLXIyro3/cU7lfsvjK2 s++C4s8zVxZxz68U40YIcn76RWm3fBYLQerf9b/pIOvV3WFfTMbiU1eTP06j3pLVWN/4vfDh8D4E 2woH3hlO+kdn3Afs5WXt1O73d7RTqU1fb37NpZ6K7ThwS3yx+KFy1dGCapFoUQcbEyBYx4GXxyfi EwtyNA2LatvWQhEcFs5YT7dGEOwkrX9K31qwAPsZ24L9ij0+9mea4maUg1XSsviLb2ENG3KBSB3J 8C10MJrAFuoG9Qu1Zvpuby6AcLCLZaw8US6r4Sh9lHs8ZDVgofKU6rpKqjyuvKIsK3pC11lMa1G+ S8DCI03PkcUfTFTDVR4qWDUuM9USxKlSVDmqG9x73MeqatU3lQPQsDTODapoz2bvKbULW1jwV7ck TV3t6itWJzjR8FnHHp/OjgM5ybrIg0OHjnvjwnAFkPMd/GZhrRngXOvAfJOj2sKnH8+LuHxthgN+ gpPUsS9WcdVtCSyGJRcPvHLbfXDodpfcm0KOT2V4+5Sfpi6AIFDG9FrotNBMPGmsMeNszRCS8Qxm mPcvX90ShDuFrFdue6zMD1tDHsTB0CcDVHnh1T7ZZc0z8Ux5s6ZHA8xxe9wTD8Qj8JV4Ep7RjbJz U7Vz7DRmCsYlHMMDTh9bj4cp2nrra4BvcpPv56nONfWf5JecqHPpuADJL9hj9vwLTkWQP9PQil0P +BZILXp0Y/sZ6R329MesjxaU230ya2yH6601HZPlXSFzC1SRdcWPf16fPHSVZv0DhysbJI7uU8lv TqyX7GTnss+yb7OPYboC7NiOl5ejMtphBGUv8320f66y/sqEqIy6zQcw+HCa6bA+Jyrb2jO3b9kj bkD+OPsTeYGM5Yk8bkRuPFjJTeIOv5Qbf4z7Ce6FK7mgkavjlhWJ5MdQL1ivFMAgTLxMnAkvPHIR vguXw1MUklCFSGHLGwzww79NOu/RMn5K7ewd6lXdWocLgD9THd0vWh2i3kxZoMmL4R4R/74quPiO eKsSqMVtYgpqg7qhk9AQdCmqi0NT0IzuwHjuts/QsFPodfQh+m5jyMtPaCsONqiTrttVPHgUW+xE h9PmSe/OrGz+Np3U8oskEt33LH3OHVMkW9U391UmLfH5zJSTGeqTbXlGwcVXpAK7ao/y7oyC2a8l 1/cdut679Km9+uCtxOkX+ws3SHpk0BK/i5Bpu5QqHyofLZ8snyefq/oWv48Qq3rzL+trGV3GM+qd ImvlEcHF3+VmCpDZH1zspdiGZWGrFJsVmQpg6mmKh6j+8o7mGLDHyH0wxseWYxdxg0fLM1wOYLga QBS6KGGuX5RVSe5cB7AyDUnwVN6+USSgeBICFIe4A4eifB6vlFsYS1hWbvi4y6ChZp3SfGzpA0+m dsgJZWyx5M7LuyUPVGPG1j16XdauFHyHjtVZqARIiH23cGmf803sphHUUvI9c+Ibu6rPv2z8tq90 xJNVB++7tpS94eKL2L99llVj911fl11ygcdxfZ/Bt+84WE+iFFRxo32baDHQg0flNdxoyS+jVwcE pHvs6n0bCUUnN6iyw/2WPdwg+bYFf3wqigUhSAg8kHd7NHVCma/qFoZo9TZeT7GqsJ/HWjdBpDI/ ScBtO63ekk8iJzaoRRaJXJGIQgta3sCsOlSxIzp5VPyZzc/KN0jwj2PCQre+JyEocrqgv60LI5r6 DqR3bd2nh+dC9HMpZG4hSiKfS5FBq2blNfRdG1uo8WQNc182s74VMlPMNH+oeaeJ/dJ0qrv5p8og Y9JrmVvW+qfQy2zjpzStpMuT9Vznbb4hdCbgFm5Zv9MkQOdtNiGqreF9VeSBHn3NKJx07tkx22c4 hqytahafGs8EiZJtB3bN12b+9vPollIQUuOx69HOnvt3W35xLb0fjn+P4Bb+3H/HIIKvG9pgdgxm zsVxYuPvoNOtnsxGeoKlCbu2J2y8dVaCrvB12VLqk4lWJed9nji4FMW4FMVdZESfv8hYfYLlcKMo 5ixjZbhLUeKFogPMOJeiBJcik7VnGROLE/YxlEx+8dcaME/Jy/laE6sMRrOUntzLSnBP+UrZrOxR 5nHtVZ6qwNeo6JrK5ecrzfNVjBWqTar0qmGput9U599XMIkh/RSzaG1f4W/j61RvX/eqCKHJuQXc ozpwJoKMi+8Q+bFP9sDIUtFeu92Tm9DHSYsOXTc2Dfms+1qzRCP+JPWPDf24/Y/96vzgVtlSTTKu XvDU85GpNQIj13/r5lpqJMc0RQWaEo2S16jRaYZlIVdhwUnskFfjMUFOmOm3/a+ORT603T9L5858 X9XvdGG/94DUZHLzJe3QTSOrsAUiiKJK1AkjMNlqfCt+8BImA8fxhWI9fbv4E96LW4BqORgm9aXP pEfSY+nb6Fn0qiNAQS+mv6TfVDxWVCuGsz3YbjCbz15u75w43CtdgkVT5OyR670P+LK3Jfkoiv1R UKM8s/Vc+kZ0D3oYvYjeRbXlaC3agRpJBYhdgmbqVvM9mWFEsE7LEtTPrS1TIdLwjAnomMyDuYoh yCop2JzhI1sI/zJpuaBwb3BV5wz9M+KL1bOo+mh8PRGrawWyBt7Z3UOQLlVWPVn/Gg9LWlzx0G/k YrX9YUUx9+BDGTATIG7y0Jj0iuFzkT9exn1Lna8WWf4apRbp1ccir9TbXSwf5Xk6dHizdCDn8fuN bKMwkS6pcqJ8V3lvp2C1/Q6jvLUJsWsrM35VY+7Np3/eylyRHYlOvLlke8oQJE4eliLPkefLbx5N e/RblNepCQTgW4KLsAWdbfQeIv1SDN9yW1YLZ0QXqbVFGmNkDj2wCgcn26IUXQWK4kRFmiLfQlEM Lil0mKmyTtGpoGF2BZ80urH2hHZd/itYL8HEWDK2Hzv9x/Fv4B72CmvGqui1dHulpzJQOTtCuVKZ PuN28jMsOjyvSLBKLVpvtMHtljZAt0yQcLhopVq0Jq/IXSc6vb5NtDzEsyJ6/RPH5Ql60Yq8kqec 1WDLA+fRG9WilmixTrRSv/LLKJkDs/y802OnDTWOULzDbP0yebHNhHFB3vR4oBYhL9qLIJSNvONX OYzKkb+Jj7zWbRGw+SWBAGzKwjt2Z5UlgPOyEjNbGRbnPKG8c8ZygBdBSQ6Ox2Mf5Wxl72WPqT7Q Ybyb+NY/jEJ4HJ+fA9vLJxiZrYRAXWvZxBsT5bxIs3nT7pWSjJe3lu77xczW2Ihny+sw3uP95Wan 4CQ7HvKxRcds4vLLldHCKNRIBWxVY1RTVKEqkSpBtVOVq9rBSBsX3bb8Qm1HdvZF3jOVSuW+umul lKFxByRXnH9pYRg/QPNH2grNwlSUGiRJkzdrl2SzrRYPrx3flJy01mul3uJgU790U4jUWmt/mMvn ygMO/eZ8LRJ3/VAFI1/GHuzd3UqOr5/y0r8TX9gHI5X99gXQC3LcCfwqfh9/g9+UP5brvdcZaFsV o9P3ijYdHGDt8TC0U22y6yE8JtHuLGktPYLL30nPpcfv5fLv0AGNa8dto1PYNmy7Ai3qLQY8dji2 nl3P6+KdY3/a9pgNqtnf2Pukp6TXpX7c2dxF3Ig1XPHzsOQnPvtKBGr1TwQ25xVtoHnG+HjHR18u usqJPx4Mprc7kq47hf05Zo7PBL5jjY9QtQE41oQJmxQbhLuFvwnPC+8Ii54L1cI2IUVsI3ZbdXo1 O8tFUv1toniueImYoqm6eUW/Q5wtPiG+Kr4v7nsjTmgO8Onb8aDHQEvTnoy8FfagiIL0YTeun2uy vE0f+pvp78Uv7jY61gShO9Z/37fr2Ya4tM1xmP/LW/dXlmcU3cJPykpfFVogCBpUmnxhUgElFZUY 0mG30CfoB/QGBqU0/6/27gWu5vv/A/jne04llFPEVqIQ00RL5bJFRebWvZNt5hZFWUQKEYXMrckl hkVYbhNpsrlkseU2GRHGDjG5nqxTSlL6/l+f862c926/+f/2+//+v8fj9308Xpuefb7nfM73+/7e Tt/Li5jqMbu+d5zbAZun5gsexFjEr7x0zJXtO9E1Kapx+9s+SUFJlTfa32aLki6mFqUeTTqfdDvp Sfz0QnYwxyLVLrVvqm/q2NSo1AgVW5O6I/VQKj8cdSkRMlpkbO6Y0TNjbrd9mas795q43dzU+nq7 aRl7tjl/ldHvPXOBXckYquC7DtLXzsqcW+NzZuYszUnJ6Tyhe+w7Cu8hFiU5Ofk5d3IiQmSWLUS9 863OejpMcR9W/sGLY4vaeToMPR98aeCJCeexn9+6pd6O54/mHfOMS0o4YbKpkdsYq5rWrXacsp/Q YmvpzAVTXMfe6jHdXDhzPjBmeaFwMvjHQTFT0jUlWyYp1paZRNhuq269pPb4464T2jSXb29Uv6vu VziusKa11aKLebHYpzySOjS+4+snLOI1He58XNnxguvrbwy8t6504IkOtXs6dMcKDeuzyx8VXxJs nsoOWcuYIJxxP1yoLDMXLhfeL1zfh5kLxiXvixPF/iWBJRNKnsSzm/aWVptLvizJLblSot2rvmrX WuwquoqHXfNcb7ouEn3Xi7vFo+Lgvcs/3N1z4lb3gdO3PhH53tfG3dYmbLT2aVetj1ln+T7a5jft gW/kzs0hbHK3Mn+sY3Zu7tZk7O4dQg8LxekdrYPeVnhFjFJMUbD5imTFdsVBxfcKleIXBbOq3fu1 qU//Cd0OPLDuYOVsNdCq4kDbac9CrWZZ3Uq02mTF/6IZnpd60Vl8vqoCm9GPj4sLjW/PrHB1UzwL ntNm+o5Tjx+OSv/xO2dr6zdbBznY/3TG/KuSkA+vHxWPjW/nUF0c+2Rq9+8PnuwlGuGQa3vQ9W6K ATEVrpH2CfZr7Xfaaw7b59m3nbvo4qBtT11Ft7qd9l/WXRq07V7VwhxXX6HYcmEbV3tXd9cA1+9+ ah3EZrgucf1sY+ugDNfnPkaj77qyStfGPjG3biW1jevno/QZ76O9mDrF51riUZ/zPrd9slPjf0i9 lWo7+p3R/KLU87X9Im9XO6zaV1pqzfq3PhYYVOs74ab/9Ou+wTd9oyNSfMcX+AaxSTd99eQhpvo9 ewd3CHcJOr//yLx4twi9s2smTNnyYH9UhEuQHVs2QR20PswlyObMgbBdIScingQKUQsKI/hOaU6l dqf09Hah7OjYZU1nqkP4TumiVZZne+/45tTRkAvnRdfh2p3Sb07tCpm77aS0U5p1TM/4+vzopg/G 5Oc/T4vasj6MbZ/nlT/uzI+lx2P2ROfHhG6ZO9J0mWZsbv7XE6zFB/ntrfwPq13rr8U5E+t89WiB dre0Wf57eTm+Y862rNwiO3rlp3h3g/ja1yq3yKN7HIkfE+11YYyeeKn3wmd3Qj6aOtL07IWvG/V5 cWyCdcHplLE4IC91dRtq0mze+BcZE6w7NzeKubpmcNG0+Dfay/Mzk7bK32i/Uhh9f/rCHyu6LEpy +9LCbvi98pVC0x33jDYl7Uua+O2itHOL38u7Yyh7b0X20M0/bpMxPUPVDk2vFWvdvtRcxG7psM35 mS1mTRNuay42ta85vfBM9PMrHZ9fO6HdLZ3x+rmckvahz6urEvuHPj9ywXjtmDNHx+V8MdNtoE3e +ORl406tGT82VZmfWTtzo3aP9G6Zs+trejl650UxP/PRFnZg5ZQtTzPm7zXPKdsw4EDLL5XT/XaF +C882n2Vf/8rvlsm7/V94feZX2bAlL3+UR7XfXME6yVjSgKq/Kbe8+0Y9sw/2GRsh6BelhHdJjC5 qUuEs9WYiM7nEyLWRuyMOHY4Ii9i3XlNhCzObMZKJ0WqWdh3NnE94gbFDZ/ODDqExc2O+yQuNS4z 7ru4y3NylGnjJt57pp4SKqbJA9ZsuOTqVrrCs6t+J9NF+fkdJy0K7x3Vfqnc1DFpwJKKEqev51X2 vr2ivaKyTfWHKutue9Utqv1Mw+LdOj1bbC+/dmla0sKkT5NOlhxJOpdUq2/vloWdzmtnbR9XLb7u eKPpugt6zlaptQ7rpOPa7az/pkST2tsPxUlr5KYxqctS2QIvuWlmqp+iWU60Qnso12bzaVcDe4+M YRmhGbMyEjPYpozjLjkZ+Rl3MtJ8vvI57RPfJadPjk9OUM60b9y+W3rQscnaLO+T+2YcbramXf2N ++pvXmoauPxhmVx7tU1jtSawRcMpZvhhoVoj/Sn7rlpTwf8Crta8hfED3W3ZIFs2xJbNsGWBs2zZ Wlu2wZZtxw/ptmyPLcuwZYds2ejXZIy9PpKZj2SBFiNZ65HMciRrM5Lptx3JrEbWn3XCfnXeV4e/ coZZuvEAodkgxipmas8wc9k2RAj8WOcMM34+TKtfnd9SfyqTG1JT5S0kD9I9Ses3pz790ej8hKDw 596C2WDdE4L4GCN+1bp+CvObI6VhjHadGFO1Y+wSOwOxQZ9fDMT013aJ32MuF536eRC/PSG/5awH /uvExxpcL/VDoEP9yfWdHzxpaanWGKlE9rSUn4pTdwq9T3tDj06yoEB34cGTstJAhSh666+Y2PhW tS0/G6e9oSDIXtOed683R7GsyaPSy9l3nnVpJQu0k+kZps9SxDW1MiiWn1li2HZrJ5lfV6Fzy4dl Bvxcozf1B72p10fRmb2vCGvxtNRtRptMxQrFVkWW4vbzz+48WziglczvucLQ3sLezp69GK/WhGA6 uDMxkoWxIBbOCq1ZIJtcpRnHCiP4M21EjRcLC1CJhTViD/lDV3v9SsF1jJMga2qgpy/zF/RsBP4i /KqkACbGsElsLItgW8JVYnOFjaKHIv5Rqb6oL8iERgYyfaFRz4bW77G4MO3zc4Iry7dMU4mvK95U /FzFm7OeTXijAdp+xdX1SyWqTBTtFWzRrIdl8YY375eLAnPzYKLMHh152Y9tAn+MV/8AH5XYVNFG 8eCJ/GHZkWaG9yoEpvewTGYlGDC5ECC8bOzLRHw+bUcGeFZpAlViK0wojDWjm2Gr++UCM8GSJ5P1 kAfK60fx4hfq8+efDmRiBItioRi/dJxKtFDcfZojY5sLq2tOhZrcL09F71DIVwtlTUUD1kimbyjT Yy/f2YPF8bGj2SSVWKP9bBkytq+6JPZq2Ft8ZEOxbmSDRqjV+j4P0E7oyhgW/lgTxEJY6WSVaKYo rFlkwPRu/lyVypj1o1Khiagv05cbyOVyvOFj7WgaDZvGxCjtw4kmM5E/tyicf2VtXaEJlrNplZog ldj29nO3MQzzoLfszrNGckMDG0P+ngMFfj8+bYVMRklkBvGZe6O2cLZYFv/CkM8KwZqxuM7WMmle 1M8Mqa9iKN4zGp/UIUwqCqbXSaHWNJIxfRfD+mZebLT2aUqVGsxpG94qviPmnl7fhhZKFhetnU14 90F8cqk1bp0UD8vqmgzUvlchv0VhcJUmpVf7P9Nv2HcMOe0gzHGbIUlY5XyaDXNKUURJsW8SUpJD ZMxpk9gooqQ0Sk5fIjlEaTRRao6RRKNEzqeJPHff54fnD3j2el37bPd13feuz/V+X+/rM9thewvv nf7i1eRBe3K/xmPX/fkPEjZv3fHj/8W8mN23EnL/wFPr2jXLNHda1VDuMaM7wiUH+xZWdHWqG3Ji PdM2i8xzd7V4nz5XZCvjvMsy7LDe2VZLi9WTK6diN+PL9KguDx3eYZ5h09Y2bctrn+XenVoutNR9 Tuyi6Gns6Bsxw15OPhp1W1HBvePnb7Xqhj8/9jIFfWTnGh8LlBJjU2xKvvrLvY99cIYzyLn5M8jc a/WOTSCyQGxsc/VWpddTh1iNF2E9naU/ImvPJj9e8FdUe3K4bfeYYu11lcCcoF+ULetGUqcEd8P9 R4uS8ldNuzz2YEiypUXA4h6fxjciot9SiMMJsV60pBkVdHm5ulbKSUX0SNnRzPkofmsdVj0uFZmO R0wPIdUmRUT9kOmSrnye5kdNUjxg3cL8rVfYw5KZ4vpLpDL/hOcYIVE86poCRrx60K2hpAoTLi6Y 6HePU16jbp/wee3mhfN7aBNv+K39dNtNDhCxLClOIy5NVlgUdarBT91KlmFwkO5HPyQJqzWyev69 6PdsG8Qv5NSNFVgTxmo+aTkYsotUXzfr77FPEnIoesClYOPXXB3/4vrdek6LyHlVV0jZtbCLwtm4 IM1bx+vbk4h1yGMBkQ9/XPHmwbWnFeejc1kLVxBHi0rOVbbFrxtfyAsfUfAs0eL2qaB8O7BST/qJ ISsXLo5Ccg63/ciZaI2oWzc/7v/vx6GBbW18UlJ4TlBDGGpGrymQdKvdIdr/w0bW0rbpZqOIRSOv KO6GtcvGmWzP89pc7zLWOLrG8MtKBUfmfMhPr5JXlScCyO90g+8lOKPJd1XDiyc4pfOmW0Q5p3Pi upktrUbNtvCDoVPFLZtnO3pq6tgTuhi3QLPDFF/SiKSfYsA0xWeONrq+9LvUBR/du3u/ioenbXTZ iwpop3DIjYhvumYipv+gIvFBmERi0/vOiubH0+dDNJr65q8vThlfbqtI86mI3t9RO9vXEECe6KhT zaoVf2dkkBdx+mptu1evUuvQepTWl1fyvR/cIpobX/5Wjet3j5HT5466jcQ0LPdY9GIkzHndqj8D nyheznQPkG1x83QfGv1zGd7UOqXbHe4RhFD2rLSMbcnJDyeZ/2H2rP8qjWioCIvYEPcjBIj9aFcw 1nvT8ujLzyejCW3zHS9VPyLaK9L9+gVeC93u2vfNavcT6PWYskunW0eXs8kD86mXP+Re2f7+26fu CWYaeiRP8xDZJP7Ug6fOnnVv8r5wHF8s+m/6yAy2REf22T/cr7gdE260PXrouseph8vFW9F9U/Op TzduOU5JP+Eda/wEV3xnec/5/dC7Je3mCsra3KVPcyuzBT/A37zVHI5HbvG28p97uAjBtxmC25GC Q24m4yWjNpHTLgrf6iRNY8Omp1iGk+SozpSDYiF/nlzPeD3XUl+1f27bMnLpZbJhhEFIJKezJeDr qEYa+feEoNP61z1ZrSKxNXNVvS7Pv2mbL/vFuduSJKAOMdMqmoW3douSh6S33aPuu9+U7+xyiSgj 1FSt9gTDL3z0ubia1UyjYySDk3/b5yw7+BXpRsCtt5hz5SO1mcJimpk3qorXp1Y1FYPH7e+cJAow zNi+aGE6Ab2HvRNtQyeh2+hXCG9RWoTzyDs0prLrzgC6gWSBt26Hs9GhIXncIYh+wl2Ur5ixHWtH pgtLKjSXCucqQOXYkmgV+jDBDBVB242SpqXFmWnAJLTUYVIlSJhwCRomHoXD8KPXpx3QhAIilqnP kKHqMw5QtRhhREe0J+Qy+hPdgBCK+kXl4kxgWnGDsCO4BpgWxQiilWwE10pZ1nAVnMITQpLufD3E EsXGUREkPagjVQ6qSFWFmhKRUE22COEkUo0WaUWhRlpbU3ejzhBsrTSgYslOIAmaBkyYhoKJ5+Ix /NiMfmkSqlyVDfOypLuc27Jy52zElz1YEfR0mRapZgCnOHAaAKd3TSwyGgRgA7aspD5sxCsVrgga O0z7q/dbAo8m8LwHq3cfrgh2PFoRrHeaFgm90S/N3QG2B4PtjSBIGmxV6dmIvwl+4ygIPvpxI77p /oogVIC4ZbVMw+AV4Pbx8nD7hNsw+5QaTKawvmamZAAeI8dJJ6ow1RgCVB3oLqY2A00VZPhS9zNC iSHog3QLwrL7mS3830Ksipz4+Yq/YXjtZJDIaMLxqo1fp6EkE1YTjlKly5BBmlOcFUrlK59aWA2R S4avziqiSZke/aZlMqFIWcngIOQA9faDFBeitA7qFqFwfraPvyEaqxKZb+swMiCWXOP2c9WYf9GA eSWhl8kTj3eY0tW/Em167qmVljmltCIlcu2oumc4sgB+iTKDHBf45MwSzMSx4NUFVNjiQQaUrkag oIwJrahRKI1yF1DA2BHDH3qPiObCGCT2MbQWvYDKxO2kMfGzkA7KZ3DjR+AdSTchHd9uWTHjPATA jecRoQSMqwRDJPMfEQ6VKMnUgr7ou0ChUNV/1tvcn7Uohw6FIYO7kCEfqpDe1EGrGdogTolmhLsK uxTfhGcJjjuw4ByQDpbOFmUfRr+CqKLH6HzoI/Q1KsvaApPJh3DGQLHpRCxJgCHDtiNwkFACB9VD JeHOQjqSuzQyxWlqmSKeVky+aip1Z3UaEYqhEfVJB8t3sx/VFCILPqY6tOclUqHcywBvZYB3I8Ab C4ixCjCPcQaESOyXxqQAUpiCADcQ4A8C3gPnScCleodpkUV4uSoRtSVzfHyWrr5Pbvq7ZnzDm3M0 +U6SfIk+FQGymgZZZYOs+gnVSANCNSqfxrWeAW3yBe3KdwldSFlGuwpdQrlKXFJzlVpAugoiCKyA Oy1fjZ2uMsNH3CMl0xvtFdWIAtD9oM+zQZ8b0HcRZpAdBDP9ln7Jnnwfm9s+pilT73U1065Q0iYE jEHZQtObsRhQttBcULaD6Fd0RYBiHY2Am4XRksxA2aKcMFBXB8Ic1fWxfHGjSGaaQeoaUdnaC2Kf 0GSLUebkEWVZqUQDpiDjJFuRsAiwkQHYPEamE1KR5jQZ/BeUq9QlddDSLoQQnWemhDQknnYbF0NN fHhVELkq2fMBFjyZZWBAzwB4ZsMuUfZqjgt42rAEq7OpmiRBqDoJDuhVDug1PPUoLgaH2VmdQ9zL dUSL0SupGGspuH1yDF5756IOwMne6wh9LsAGF3t/l3A9UXtnaJK7DNcEOJyBowA4Zj+mUswKdwnz gIOZ5t776EKrG3B9B/jWEvaiqtfst6wkqIO4PIg9Xtkg2idC52eiwRZRUY7dSDBD4oHaNAHJ+wPU JhmojYQmTAphg9mJzSbuJZkxhNgENI3eQchEMQiuyJ6p3rgudKZUruOjPf2xS6hfCsXHZYdiDg2R 8OGQjqQZjUyRDqQr3ycXgjAvb+fkAGOtaK59Ov34x0k5TntQY8th28kA/aGwjbheFNcZ6MAFwnJ/ vdgITR53FchykzMLxsmhSjKBIoLc7oLcnls1AUXcpEVaJ0OPWCfDEfwgN3mQmxHIbTfIrQrkBkMy CDBUDxCjs1D7+C71zB25LhjlRX3GXrYrkOUJIMulgG/9QJaDkIWUIMC3Tw5M+ep8QGtxQOsXNbH9 fu+AeC7uAsp3BqyEgA5oLgJiaQ8WzcGiNGC+XMDWafv6xfhZDpdmcCMlK5UiD194qfAy7Pmswmmh oTDNYArKnJqI/wK0esoRI8vJIApwvUH1UKB6X0D1/oBGeE1l4pPhHZQ0dKYkwhEjh71HVCGhGQJs EnoPEcNAs8PA/PIE8+syrddqEv5xOE49iQolaQH2hwL2HyMEIQMBpww+RMWf/3TgbpD2x0l0wDeB eutS4dD8Q8ea3r8bY/780L6Md71CzwaQdtGE8EMQsZQaNZAUESPrCySMc4uIZsWDh81c4k6mISM0 psJC9eehggM1uQ5DTHwhjYTzpZLwkwDQLjXfutc+x9cfzB6QaHeNmsePFGGl/bwfukn4jcSFhZxz izNIhTLdUTpUGdwpNVeJAGemkq8NcwcnnvrF3ygU5Ss0Zc2S8HXBCF8LV3ow7O9YI4YCon0G9G8W 1QhXDFSOAF+IY0EWErtQhYldaliBajpRjyTGuMjWJBQitWks636IfVyZZqboJyIGUZ10SJ9tgA6g ewM9iQYqh6WR8FIgUSV0poixA5Mv9C5oDiHQHAjQAZdBB/CA5QTYFN1vBZ1y4UMq5bOGr1i9I4CV DtDXB9qlBUwY2F/sARsgZzAlqlQLxmmiH3oM4oc+AnEDJMsGJJsEJAumYvBDgGRhmMwdVeqZUlMO GPFxK4ziuBOYeHfAxJMGE88UuovEB6A8jW6D6KInIJaA6Vboq4ojidJUeZwtTD9BCFqVmAipik+E ViU4oceFch1YwjAwfWB4FhybAuT+/zviRULvgtsTAkEIEHQZBPGA5UyFfTEkPDdwXTvxQSgoSTW9 d0v2gGywhO3UM3v8HfeHYcNcayW7qdiHx+PK7w3sHpl7kxa+IV71MGxtX6pevwU2W2QoxqWdM5x4 kLPbdYwuR+hCtp5zHYNcA5rcDjBtBz1bDJ5idEDPdoGeHYIcsR6CIvgB8eQB8ZQA8WQA8fYC4gkA 4hGIqugOSASYo/ygMxLAHG0CkG4C7gmAEWGBzBRB2DP5YASCsBjKVUgM8CuXwFTC1uLWX7rc52qq vs1lbrrGCGrkPzhHPXCWE8XnnLssFxVba7p9p4Viv/Ku8mTIe2ZK/W39qSB8bJ9Zy92CAp2X29bd pbe2ve9tj+Tr8gfnhv2JP5i16s1boShHtulPfSbEBiNbFP7d73u9iRY2tvKGqY3h+SxHvWhJmp/2 Wo8tfKaQG+as3hKUWMB7W3mR66GyGCg0OlbbwZxG8o4lbnpF1zWUvKyUnenWvmXvEdrcySwVFdGf yt2Hpz9ouoBoaTrWcCZOOquifc2P07fNn+ZDeXsc+S0Hu1TajYhWffXA4HW89Ot9z1e/8G1mixyX QbRgL0rAEtNs2lGvRFsMLplh+cVsWuk0th3RCCuWm0ZAutFLiBisJM26kDHFliBpwBK6rM+qVbGV SPtgKSy1JTqPLYDh96TGpO21llVzpBexsRgoT8gzHYPSpt9i7yEdzEwrw/WjC9DT9BX2Du5+jPAn apC1K+MdW5akvWicmRyEf6ZmSs9n7+OKkwwz02dwq2gE2wID58E+ZZBQIvRKeiUjgY3i6oUKddim o0eRxmx9rtGizqJy5vW7VofQj+g9oi2Or9fYnhhp45TNuLt2+5A8tk373Pe4Ipn6rnW1AmZpAplQ gRpgFEB2hQrW02TQdfRhdjdbmSlaf/0zflZNmp7CViPckFHLYPjQYYSEebcZXsdvF3ooUyAq9Si6 m75Hw5xUolCCO4WspVLnk3ysSFSlj/j1fLgE3ZaK4sgHUA7sYoocRKi9gwj7Um6j3zFkqQgOLCCp Kbkp/baaLDGQBQtIqLEpgwQmjqYyzTn8VTgTdD7dkP6eqrOowRGuwjegRyDRiaPJLP6pdKOdnITU dcSYOf0eUZdpuGiwKDVOWcZtoCuoiuPpy/gNNRXRlpub3ok+by1EEWkSuGT0Parc+I11ZDNVdTxD COmAgSCSm1KaMmLiJOwsCLZINcYR9jnS/0Ht2R5JEoClJqLgjAz6RRIMi6BZFSPdGESSAiyJoNbD QLCdMDtyk7psfRnG7JMYKZrdJGqJIUwUqIbw5D0T99pmIx0Z/4iSMRua7FCMmGd8GcEdVcogkSSr ZXkynilldgbIApQWZZlY40zc01pQUCP8KTUmnYna1OAbZiizD5HkFoWrFe3tVpHRDAmSaiYthjZj V00XZHuwB9g4LiRU3phCUrNjhNCVuPKhSjxZnlSHzSGkJsONHcCVWDQPle3Av0dZIr8zxIkWodD6 RBlkDkObfYxrx1UIVeaJHUEZ0u8QUaHi9Tc20z7jUumNbHOuxSJfFNXMupeovyjPE9bCrfcpFhER i0JadnvojyirY2EzuS8LllMnVEtsz9PliDpodMxrXSSWkP4DtUHl54jqExTUnOnFVKhv2gG8DHYq VqyYeJkp7JtcQ/BCDQ3/QU5ShTkKVYQhZDBUm6UQkFJjZ4I0INox4Ys7OIgqmy+EBmQ40YOp6JvR lGSEHIHascQu2V5FmjNOEUO4wVxllvBUwvKEqZm8gOnItT2PD/b05SHOO391qtU4VZ77qL/LIzCx +1jeS/eIgsWUwJJOH7cAhVmnXvlF6TknUvZnH3olq+tc6Yv9DLtnrj8GKzT3x9pd3Zdf8+ZYy6Ok 7s/zz01jC1JTVnSzmkKI6XrRRaufwmevNb4Ncr1EHYAHOl6LJavBfy01rz+xjzj8L3nlazJp7P7D YYcAf/a2z5/0SpPnqLYfY9W3OBfu9762JLePbG+FcU3z1MJ54nnHti3vXVobjl/TQ5jH4K4amXq0 Fyy0S1l8jBxt9bKp6D/w8U0oVsSxXWLGucaDVseMHnXvkz1WoedbFK4q/iBVxMUk4t7lI5+ripfT T3xHdcwZzX7W6Yn5/UOcl352zbBRJS2gsH89b5l8lNc7ExulXauhX9ji9XL88dHAjaqB5iOBviHR 4sLnb9Qupn+oicou6XiaXU6onXzSKffnlssbjPbtNrnzzlUltAm4c6pw4/F3J8uc6qSgUgavYj0T 7f2y/hy/O165ITZqe1v+8cELMzaKe0Pbvli3pD8Rag/JPv2wX8b8d++J58+HWJwmnkpp+LU+hc49 IQ+CajumdZ4ETRRrOnmNPWcGfHr0bvSx7KHbQl9f3kf3NtUneGXV9fk8v7s0SErxunypctfvqmde xCU5GSPrwcgxWnvOFY8cL0+7nNMZ5Ck3uPrl8oMGNldiOwekQ5o/fsGXV70iZBt6mj/2O2w69fK6 KrVPNXEhXlWmTzmmbSkBHov8p/U7faDRu+G5fcs3QUurMRGotTfn33ue2r9/dT8b8j4/ZeVUeeGz z/Yd1U3JVKk8KExjq2u0WzvoJIlVQ1040v+6tTjJ5lzOAZ9G9ruEAa5Yky42v3k+gfC0gXznx2Zj 7ONdvPfFM4bH3tiE8z5P3LxQ7uxOPs9uGDz2a0Lk7EYLtvnpq4iXef3Xnulf+Zbc/8LQUn7c8ZJZ lpQt75VQSGNlheXm1zjVGhU/Dv90QMDG+YifPP+vppWbK+Fvt2NMPA2dNAP/YT//0AEdg8JbrYs9 1zJ+nPX/hdjVJe3Oe7XyItu5dq7758ZC9HZIIPqFQcGq3FrEldOR3n/mHnavfl8gL8X6dJj5DK70 Li0lvenJOGXi83hrr88/3CJHy/DLF1kPko6MTPeurYzHlkhb5y90P9IdWU4eVXGKHi3ZrdS6SHbh WMD1dog0ZyHI3MTVfvWh4euEc9Jm0ymnbpsUvp+/g+CZCm6jX83UPd0kmzf9/L098pq8+NunpIu3 0CrtwdN/+swgcvxT59CkT/Pm1frx4MKfsZNjnZ/Ojb5SeWguEi3967uKntUwhSx84Kq8f4TLBB85 JGKCLyRCN/aMw9Yi95ShhWpYjuaCj965gaP9+bdOPetXYeD2t2q46F1Avzjh9iybfCL+oUrzhcWX O4o9qsMuagRPeWGnU0p9TdcCyn8NEJ+ZPPNbiqrifH/d4I93DC8tU48WbzHkigc0bTHaOt4kCV8d KDhb8WrMeqQ7I6HKZ23jNZZhuX4qxkvDoqT/AOzerWr1hQyHE1Ntda0KrLtt12cGq/xmvryIRptG zCoNt5DJYsP/nsGbdmUtjK8vdHV2XjduNzbBiotfb1nGDJB7J8l81Ed1G3xCfHx8eydg/12RkzDw nhlzmi8rZhu8vMF1Izcuho9vF9/fl2ReXEykzk7Y7TcKfEirpQguiD9jQTEmkS0EBmMtBDYnYP/F 3ZyD8Q3mJcRAQPzfc/7um/g9F/F3H/9/Efx8FbtQyn8/k8AZndrzEX/P+3s2KZxP9G+EOjCJ/yL5 +I4COw7sI/gyA2wY2Ab///qU3lTh/tpf3zowAbDmBOx/APHPRhg= --Boundary_(ID_LrroFSWRXtXISoZEEmpZOA)-- From flefauch@cisco.com Fri Oct 28 02:27:49 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A64A21F8663 for ; Fri, 28 Oct 2011 02:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[AWL=-1.042, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCArgjRfUBmg for ; Fri, 28 Oct 2011 02:27:48 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id CC31721F863E for ; Fri, 28 Oct 2011 02:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=19047; q=dns/txt; s=iport; t=1319794068; x=1321003668; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Kd5X9WrxDGsXR2X+EhVbB/9YPIDIYmz3lrhbX7EW6WA=; b=VlQ38jJuWjD3mP9F+MIDZZE5WqQ/SAHzCALd1oZRtkb0cS6buE+KuXrN gm3CydR6z+wK5i5VWFUYKnvqxznruyXWsgwbKHlSfG5ubqViptcCqwQdF fQ29PGkIn5a2wdZZFfltNZiMB+ifVvNMKwgoO7vnWNN0mY7AXX5KsjIud 0=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,417,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147";a="10898696" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 28 Oct 2011 09:27:47 +0000 Received: from sjc-vpn5-1573.cisco.com (sjc-vpn5-1573.cisco.com [10.21.94.37]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9S9RbLG012977; Fri, 28 Oct 2011 09:27:45 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-130-2470437 From: Francois Le Faucheur In-Reply-To: <2A0AF3CA-36D1-4F0E-8D09-3E29EFBC72A6@niven-jenkins.co.uk> Date: Fri, 28 Oct 2011 01:52:50 +0200 Message-Id: <12F21DF9-18CA-4916-8681-8919A4735C89@cisco.com> References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> <2A0AF3CA-36D1-4F0E-8D09-3E29EFBC72A6@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] =?utf-8?b?562U5aSNOiAgUHJlcGFyaW5nIGRyYWZ0LWlldGYtY2RuaS1w?= =?utf-8?q?roblem-statement_for_WG_Last_Call?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 09:27:49 -0000 --Apple-Mail-130-2470437 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Oct 2011, at 12:59, Ben Niven-Jenkins wrote: >>=20 >=20 > I took another look at the draft and my proposal is to add a couple of = sentences to the bottom of the first paragraph of the Introduction = (Section 1) as follows: Works for me. A few suggestions below: >=20 >=20 > OLD: > This creates a requirement for interconnecting standalone > CDNs so that their collective CDN footprint can be leveraged for the > end-to-end delivery of content from Content Service Providers (CSPs) > to End Users. However, no standards or open specifications = currently > exist to facilitate such CDN interconnection. > NEW: > This creates a requirement for interconnecting standalone > CDNs so that their collective CDN footprint can be leveraged for the > end-to-end delivery of content from Content Service Providers (CSPs) > to End Users. However, no standards or open specifications = currently > exist to facilitate such CDN interconnection. For example, a CSP = could The "for example" does not flow very well (it suggests this is an = example of why no standards exist - aka the previous sentence). So I'd suggest: s/For example/As an example of scenario involving interconnection of = CDNs/ > contract with an "authoritative" CDN for the delivery content s/delivery content/delivery of content/ > and that CDN The same CDN is referred in the same sentence as "that CDN" and the = "authoritative CDN". Might be better to always refer to it the same way: s/that CDN/that authoritative CDN/ Francois > could contract with one or more downstream CDN(s) to distribute and > deliver some or all of the content on behalf of the authoritative = CDN. > The formation and details of any business relationships between a = CSP and=20 > a CDN and between one CDN and another CDN are out of scope of this=20= > document. >=20 > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-130-2470437 Content-Disposition: inline; filename=image001.jpg Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-130-2470437 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com --Apple-Mail-130-2470437 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Transfer-Encoding: base64 R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-130-2470437 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-130-2470437-- From flefauch@cisco.com Fri Oct 28 02:27:57 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B5921F8610 for ; Fri, 28 Oct 2011 02:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[AWL=-0.686, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3r7kiMIe7mf for ; Fri, 28 Oct 2011 02:27:56 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0C34B21F863E for ; Fri, 28 Oct 2011 02:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=43027; q=dns/txt; s=iport; t=1319794076; x=1321003676; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=hqyvfsL/TvgeRuC7aPSOtHtOPOGhakCr3bET9iz4vJA=; b=ZKyPpL9tEEsDAiO7AvANkQPWp6wj6Irfi/SE+LFYPMTvDpGeU4sZbR9b PhgNATBnoz1fvOcZyrV8Sf/1rlcStBm5x1w69RWA0HXxV2cFN40XdY94p eX660KAUCcJTZmpF4K8u+wC5LKv8e8jDrtkZIoi39fKAmq+hByUqFh6jC E=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,417,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="10878135" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 28 Oct 2011 09:27:55 +0000 Received: from sjc-vpn5-1573.cisco.com (sjc-vpn5-1573.cisco.com [10.21.94.37]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9S9RbLI012977; Fri, 28 Oct 2011 09:27:53 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-217-6677352 From: Francois Le Faucheur In-Reply-To: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> Date: Fri, 28 Oct 2011 03:02:57 +0200 Message-Id: <58F25507-696C-4B8F-9DA6-9B7315CE32AC@cisco.com> References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 09:27:57 -0000 --Apple-Mail-217-6677352 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Ben and all, (As an individual) A few additional comments on problem-statement: 1) Appendix "A.2. Prioritizing the CDNI Work" I would propose that we remove that appendix altogether because: * the terms introduced there of "Base/Operationalized/Enhanced = CDNI" do not correspond to anything really meaningful anymore for the WG = now that it has been establish (ie there is "in scope" and "out of = scope") * the requirements document is defining a specific notion of = priority with High/Medium/Low priority. 2) In last paragraph of section 1 (just before section 1.1), the = references to the Appendices are incorrect (ie "Appendix A.2" shows up 3 = times). 3) section 3: OLD: The CDNI model and problem area proposed for IETF work NEW: The CDNI model and problem area defined for the IETF work 4) section 3: OLD: The CDNI model and problem area proposed for IETF work is illustrated in Figure 1. The candidate problem area (and respectively the non-goals) for IETF work on CDN Interconnection are discussed in Section 3.1 (and respectively Appendix A.1 ). NEW: This section discusses the problem area for IETF work on CDN = Interconnection. The CDNI model and problem area defined for IETF work = is illustrated in Figure 1.=20 5) section 3.1: I would propose to remove this sentence : " [I-D.jenkins-cdni-names] presents one view on how CDN data types/objects could be classified such that the problem space of their naming and referencing is not as large as it might at first appear because there is significant commonality between the different data types/objects required for CDNI. " I feel that the referenced document has served its purpose in providing = some thoughts on metadata but its detailed content has received little = review/comments and is being revisited as part of the work on the = metadata interface. 6) section 4.3, 4.4 and 4.5 (multiple occurrences) OLD: a CDNI WG NEW: the CDNI WG 7) section 4.3. As discussed in 3.1, the Request Routing interface is likely to cover = two capabilities: * allow the upstream CDN to query the downstream CDN at request- routing time before redirecting the request to the downstream CDN * allow the downstream CDN to provide to the upstream CDN (static or dynamic) information (e.g. resources, footprint, load) to facilitate selection of the downstream CDN by the upstream CDN request routing system when processing subsequent content requests from User Agents. However, section 4.3 only currently discusses candidate protocols for = the first capability. So I would propose we add something along the = lines of: "As discussed in section 3.1, the CDNI Request Routing interface is also = expected to enable a downstream CDN to provide to the upstream CDN = (static or dynamic) information (e.g. resources, footprint, load) to = facilitate selection of the downstream CDN by the upstream CDN request = routing system when processing subsequent content requests from User = Agents. It is expected that such functionality of the CDNI request = Routing could be specified by the CDNI WG with significant leveraging of = existing IETF protocols supporting the dynamic distribution of = reachability information (such as BGP) or supporting queries by = application element for topological information (such as ALTO). Cheers Francois On 17 Oct 2011, at 13:07, Ben Niven-Jenkins wrote: > Colleagues, >=20 > At the last IETF I said I would try to prepare a version of the CDNI = problem Statement (draft-ietf-cdni-problem-statement) that is ready for = WG Last Call before IETF82 in Taipei. >=20 > As part of that I have reviewed the complete draft and made some minor = editorial clean-ups to my working copy. However, there were a number of = other areas where I think changes need to be made to the document that I = think warrant wider WG review/consensus and I have listed them below = along with the changes I am proposing. >=20 > Could you please provide your feedback on the areas/proposed text I = have highlighted below as well as any other areas of the document that = you think require additional work/cleanup before you consider the = document is ready for a WG Last Call. >=20 > 1) Section 2: Update the last paragraph to reference the WG draft for = CDNI use cases and remove reference to draft-watson-cdni-use-cases, i.e. >=20 > OLD: > Use cases for CDN Interconnection are further discussed in > [I-D.bertrand-cdni-use-cases] (which contains a merged set of use > cases previously presented in [I-D.watson-cdni-use-cases] and > [I-D.bertrand-cdni-use-cases-00]). > NEW: > Use cases for CDN Interconnection are further discussed in > [I-D.ietf-cdni-use-cases]. >=20 >=20 > 2) Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) = that are each just a couple of sentences, so I propose merging them into = a single section and changing the first two sentences of section 4 = appropriately, i.e. >=20 > OLD: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols. First the "reuse instead of reinvent" design > principle is restated, then each inetrface is discussed individually > with example candidate protocols that can be considered for reuse or > leverage.=20 > NEW: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols before describing each CDNI interface = individually > and highlighting example candidate protocols that could considered = for > reuse or leveraging to implement the CDNI interfaces. =20 >=20 >=20 > 3) Section 5 is currently title "Gap Analysis of relevant = Standardisation and Research Activities" but following the agreement at = the last IETF to move the generic descriptions of other activities into = an appendix Section 5 no longer references any research activities so I = propose changing the title to" Gap Analysis of relevant Standardisation = activities". >=20 > 4) After the general introduction in Section 5 there are only sections = that outline other research activities for Content Acquisition (section = 5.1) and CDNI Metadata (Section 5.2) but there are not sections for the = other CDNI interfaces (Control, Logging, Request Routing). >=20 > The reason for the lack of text is IMO because there is no current or = past standardisation activity addressing those areas but the document = currently does not mention that and therefore gives the impression of = being incomplete. >=20 > I therefore propose making the following change to the last sentence = in Section 5: >=20 > OLD: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. > NEW: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. Section 5.1 > summarises existing interfaces that could be leveraged for content > acquisition between CDNs and Section 5.2 summarises existing = metadata=20 > specifications that may be applicable to CDNI. To date there is no > existing standardisation activities in the areas of the remaining > CDNI interfaces (CDNI Request Routing, CDNI Control and CDNI = Logging). >=20 > 5) I also propose using the following text for the third bullet in = Section 5 unless someone can suggest more appropriate text to summarise = in a sentence or two any CDN metadata related work in other standards = bodies. >=20 > OLD: > o > NEW: > o CableLabs, SNIA and ITU have defined (or are working on) > definitions for content related metadata definitions and = specification > for its distribution. However, they do not include metadata = specific > to the distribution of content within a CDN or between = interconnected > CDNs. >=20 > 6) Section 10.1 lists a number of "normative references", if we adopt = the proposed changes above it will end up containing "normative" = references to: > - draft-ietf-cdni-use-cases > - draft-bertrand-cdni-experiements > - draft-jenkins-cdni-names > - RFC2119 >=20 > After reading through the text of the Problem Statement again, I am = not convinced that the Problem Statement references any of those = documents normatively as the 3 CDNI related drafts are referenced in a = context where they are for further information and the Problem Statement = does not make use of any of the capitalised terms defined in RFC2119. >=20 > Therefore, unless anyone objects I will move the references for the = three CDNI related drafts to the "Informative References" section and = remove the reference for RFC2119. >=20 >=20 > Thanks > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-217-6677352 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-218-6677352 --Apple-Mail-218-6677352 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
I would propose that we = remove that appendix altogether because:
* the = terms introduced there of "Base/Operationalized/Enhanced CDNI" do not = correspond to anything really meaningful anymore for the WG now that it = has been establish (ie there is "in scope" and "out of = scope")
* the requirements document is = defining a specific notion of priority with High/Medium/Low = priority.

2) In last paragraph of section 1 = (just before section 1.1), the references to the Appendices are = incorrect (ie "Appendix A.2" shows up 3 = times).

3) section = 3:
OLD:
The CDNI model and problem area = proposed for IETF work
NEW:
The CDNI = model and problem area defined for the IETF = work

4) section = 3:
OLD:
The CDNI model and problem area = proposed
   for IETF work is illustrated in Figure = 1.  The candidate problem area
   (and = respectively the non-goals) for IETF work on CDN = Interconnection
   are discussed in Section 3.1 (and = respectively Appendix A.1 = ).
NEW:
This section discusses the = problem area for IETF work on CDN Interconnection. The CDNI = model and problem area defined for IETF work is illustrated in = Figure 1. 

5) section = 3.1:
I would propose to remove this sentence = :
"
 [I-D.jenkins-cdni-names] presents = one
   view on how CDN data types/objects could be = classified such that the
   problem space of their = naming and referencing is not as large as it
  =  might at first appear because there is significant = commonality
   between the different data = types/objects required for CDNI.
"
I feel that = the referenced document has served its purpose in providing some = thoughts on metadata but its detailed content has received little = review/comments and is being revisited as part of the work on the = metadata interface.


6) section = 4.3, 4.4 and 4.5 (multiple occurrences)
OLD:
a CDNI = WG
NEW:
the CDNI WG

7) = section 4.3.
As discussed in 3.1, the Request Routing = interface is likely to cover two capabilities:
* =  allow the upstream CDN to query the downstream CDN at = request-
         routing time before = redirecting the request to the downstream
      =    CDN
*  allow the downstream CDN to provide = to the upstream CDN (static
        =  or dynamic) information (e.g. resources, footprint, load) = to
         facilitate selection of = the downstream CDN by the upstream CDN
      =    request routing system when processing subsequent = content
         requests from User = Agents.
However, section 4.3 only currently = discusses candidate protocols for the first capability. So I would = propose we add something along the lines of:
"As discussed in = section 3.1, the CDNI Request Routing interface is also expected to = enable a downstream CDN to provide to the upstream CDN = (static or dynamic) information (e.g. resources, footprint, load) = to facilitate selection of the downstream CDN by the upstream = CDN request routing system when processing subsequent = content requests from User Agents. It is expected that such = functionality of the CDNI request Routing could be specified by the CDNI = WG with significant leveraging of existing IETF protocols = supporting the dynamic distribution of reachability information (such as = BGP) or supporting queries by application element for topological = information (such as = ALTO).


Cheers

=
Francois


On 17 Oct 2011, at = 13:07, Ben Niven-Jenkins wrote:

Colleagues,

At the last IETF I said I would = try to prepare a version of the CDNI problem Statement = (draft-ietf-cdni-problem-statement) that is ready for WG Last Call = before IETF82 in Taipei.

As part of that I have reviewed the = complete draft and made some minor editorial clean-ups to my working = copy. However, there were a number of other areas where I think changes = need to be made to the document that I think warrant wider WG = review/consensus and I have listed them below along with the changes I = am proposing.

Could you please provide your feedback on the = areas/proposed text I have highlighted below as well as any other areas = of the document that you think require additional work/cleanup before = you consider the document is ready for a WG Last Call.

1) Section = 2: Update the last paragraph to reference the WG draft for CDNI use = cases and remove reference to draft-watson-cdni-use-cases, = i.e.

OLD:
  Use cases for CDN Interconnection are = further discussed in
  [I-D.bertrand-cdni-use-cases] = (which contains a merged set of use
  cases previously = presented in [I-D.watson-cdni-use-cases] and
=   [I-D.bertrand-cdni-use-cases-00]).
NEW:
=   Use cases for CDN Interconnection are further discussed = in
  [I-D.ietf-cdni-use-cases].


2) Section 4 = contains an introduction and 2 sub-sections (4.1 & 4.2) that are = each just a couple of sentences, so I propose merging them into a single = section and changing the first two sentences of section 4 appropriately, = i.e.

OLD:
  This section expands on how CDNI = interfaces can reuse and leverage
  existing protocols. =  First the "reuse instead of reinvent" design
=   principle is restated, then each inetrface is discussed = individually
  with example candidate protocols that can = be considered for reuse or
  leverage.
NEW:
=   This section expands on how CDNI interfaces can reuse and = leverage
  existing protocols before describing each CDNI = interface individually
  and highlighting example = candidate protocols that could considered for
  reuse or = leveraging to implement the CDNI interfaces.  


3) = Section 5 is currently title "Gap Analysis of relevant Standardisation = and Research Activities" but following the agreement at the last IETF to = move the generic descriptions of other activities into an appendix = Section 5 no longer references any research activities so I propose = changing the title to" Gap Analysis of relevant Standardisation = activities".

4) After the general introduction in Section 5 there = are only sections that outline other research activities for Content = Acquisition (section 5.1) and CDNI Metadata (Section 5.2) but there are = not sections for the other CDNI interfaces (Control, Logging, Request = Routing).

The reason for the lack of text is IMO because there is = no current or past standardisation activity addressing those areas but = the document currently does not mention that and therefore gives the = impression of being incomplete.

I therefore propose making the = following change to the last sentence in Section 5:

OLD:
=   The following sections will summarize the existing work of = the
  standard bodies above against the CDNI problem = space.
NEW:
  The following sections will summarize the = existing work of the
  standard bodies above against the = CDNI problem space. Section 5.1
  summarises existing = interfaces that could be leveraged for content
=   acquisition between CDNs and Section 5.2 summarises existing = metadata
  specifications that may be applicable to CDNI. = To date there is no
  existing standardisation activities = in the areas of the remaining
  CDNI interfaces (CDNI = Request Routing, CDNI Control and CDNI Logging).

5) I also = propose using the following text for the third bullet in Section 5 = unless someone can suggest more appropriate text to summarise in a = sentence or two any CDN metadata related work in other standards = bodies.

OLD:
  o  <TODO: Add a sentence on = ITU>
NEW:
  o  CableLabs, SNIA and ITU have = defined (or are working on)
=      definitions for content related metadata = definitions and specification
     for its = distribution. However, they do not include metadata specific
=      to the distribution of content within a = CDN or between interconnected
=      CDNs.

6) Section 10.1 lists a = number of "normative references", if we adopt the proposed changes above = it will end up containing "normative" references to:
  - = draft-ietf-cdni-use-cases
  - = draft-bertrand-cdni-experiements
  - = draft-jenkins-cdni-names
  - RFC2119

After reading = through the text of the Problem Statement again, I am not convinced that = the Problem Statement references any of those documents normatively as = the 3 CDNI related drafts are referenced in a context where they are for = further information and the Problem Statement does not make use of any = of the capitalised terms defined in RFC2119.

Therefore, unless = anyone objects I will move the references for the three CDNI related = drafts to the "Informative References" section and remove the reference = for = RFC2119.


Thanks
Ben

_________________________________= ______________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni



Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-218-6677352 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-218-6677352-- --Apple-Mail-217-6677352-- From flefauch@cisco.com Fri Oct 28 02:28:27 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF01721F863E for ; Fri, 28 Oct 2011 02:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.253 X-Spam-Level: X-Spam-Status: No, score=-5.253 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRKMvRxAcmHP for ; Fri, 28 Oct 2011 02:28:26 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 732CE21F8610 for ; Fri, 28 Oct 2011 02:28:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=36785; q=dns/txt; s=iport; t=1319794106; x=1321003706; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=azJATrePRCyQnq1K1+Z4KiWrTOwy5zoKBHxCp7xWcZ8=; b=jmZM+kGmqXkkQfdLzgyF5Y65A58EyIccxpL1hZdXK/c16uQwiqWQ5f4d Yud6Y/1XUuzN8cheHqpyHH+1GtyE/+xXKQveOcvUfz4SHFxy8Gmsc/fPK 4wceTOtB00GJwx0EhbR4EM2JBienIFSd/msUl9skmtEmx0qdV1foVmHb4 E=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,417,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="10910912" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 28 Oct 2011 09:28:26 +0000 Received: from sjc-vpn5-1573.cisco.com (sjc-vpn5-1573.cisco.com [10.21.94.37]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9S9RbLQ012977; Fri, 28 Oct 2011 09:28:23 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-339-36961256 From: Francois Le Faucheur In-Reply-To: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> Date: Fri, 28 Oct 2011 11:27:41 +0200 Message-Id: References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> To: Ben Niven-Jenkins X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 09:28:27 -0000 --Apple-Mail-339-36961256 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 HI Ben, Comments below: On 17 Oct 2011, at 13:07, Ben Niven-Jenkins wrote: > Colleagues, >=20 > At the last IETF I said I would try to prepare a version of the CDNI = problem Statement (draft-ietf-cdni-problem-statement) that is ready for = WG Last Call before IETF82 in Taipei. >=20 > As part of that I have reviewed the complete draft and made some minor = editorial clean-ups to my working copy. However, there were a number of = other areas where I think changes need to be made to the document that I = think warrant wider WG review/consensus and I have listed them below = along with the changes I am proposing. >=20 > Could you please provide your feedback on the areas/proposed text I = have highlighted below as well as any other areas of the document that = you think require additional work/cleanup before you consider the = document is ready for a WG Last Call. >=20 > 1) Section 2: Update the last paragraph to reference the WG draft for = CDNI use cases and remove reference to draft-watson-cdni-use-cases, i.e. >=20 > OLD: > Use cases for CDN Interconnection are further discussed in > [I-D.bertrand-cdni-use-cases] (which contains a merged set of use > cases previously presented in [I-D.watson-cdni-use-cases] and > [I-D.bertrand-cdni-use-cases-00]). > NEW: > Use cases for CDN Interconnection are further discussed in > [I-D.ietf-cdni-use-cases]. Agreed. >=20 >=20 > 2) Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) = that are each just a couple of sentences, so I propose merging them into = a single section and changing the first two sentences of section 4 = appropriately, i.e. >=20 > OLD: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols. First the "reuse instead of reinvent" design > principle is restated, then each inetrface is discussed individually > with example candidate protocols that can be considered for reuse or > leverage.=20 > NEW: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols before describing each CDNI interface = individually > and highlighting example candidate protocols that could considered = for > reuse or leveraging to implement the CDNI interfaces. =20 Fine by me. >=20 >=20 > 3) Section 5 is currently title "Gap Analysis of relevant = Standardisation and Research Activities" but following the agreement at = the last IETF to move the generic descriptions of other activities into = an appendix Section 5 no longer references any research activities so I = propose changing the title to" Gap Analysis of relevant Standardisation = activities". Agreed. >=20 > 4) After the general introduction in Section 5 there are only sections = that outline other research activities I think you mean "standardization activities" > for Content Acquisition (section 5.1) and CDNI Metadata (Section 5.2) = but there are not sections for the other CDNI interfaces (Control, = Logging, Request Routing). >=20 > The reason for the lack of text is IMO because there is no current or = past standardisation activity addressing those areas but the document = currently does not mention that and therefore gives the impression of = being incomplete. >=20 > I therefore propose making the following change to the last sentence = in Section 5: >=20 > OLD: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. > NEW: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. Section 5.1 > summarises existing interfaces that could be leveraged for content > acquisition between CDNs and Section 5.2 summarises existing = metadata=20 > specifications that may be applicable to CDNI. To date there is no > existing standardisation activities in the areas of the remaining > CDNI interfaces (CDNI Request Routing, CDNI Control and CDNI = Logging). Fine. Just a couple editorial suggestions: s/of the standard bodies above/of the standard bodies listed earlier/ s/there is no existing standardisation activities/we are not aware of = any standardisation activities/ >=20 > 5) I also propose using the following text for the third bullet in = Section 5 unless someone can suggest more appropriate text to summarise = in a sentence or two any CDN metadata related work in other standards = bodies. >=20 > OLD: > o > NEW: > o CableLabs, SNIA and ITU have defined (or are working on) > definitions for content related metadata definitions and = specification > for its distribution. However, they do not include metadata = specific > to the distribution of content within a CDN or between = interconnected > CDNs. That works for me. It would be good to get that validated by someone = aware of the work of these bodies. >=20 > 6) Section 10.1 lists a number of "normative references", if we adopt = the proposed changes above it will end up containing "normative" = references to: > - draft-ietf-cdni-use-cases > - draft-bertrand-cdni-experiements > - draft-jenkins-cdni-names > - RFC2119 >=20 > After reading through the text of the Problem Statement again, I am = not convinced that the Problem Statement references any of those = documents normatively as the 3 CDNI related drafts are referenced in a = context where they are for further information and the Problem Statement = does not make use of any of the capitalised terms defined in RFC2119. >=20 > Therefore, unless anyone objects I will move the references for the = three CDNI related drafts to the "Informative References" section and = remove the reference for RFC2119. I agree we don't want normative ref to the other cdni drafts as the = problem statement is setting the stage for the other documents. Thanks Francois >=20 >=20 > Thanks > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni Francois Le Faucheur Distinguished Engineer Corporate Development flefauch@cisco.com Phone: +33 49 723 2619 Mobile: +33 6 19 98 50 90 Cisco Systems France Greenside 400 Ave de Roumanille 06410 Sophia Antipolis France Cisco.com =20 Think before you print. This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --Apple-Mail-339-36961256 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-340-36961257 --Apple-Mail-340-36961257 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 HI = Ben,

Comments below:

On 17 = Oct 2011, at 13:07, Ben Niven-Jenkins wrote:

Colleagues,

At the last IETF I said I would = try to prepare a version of the CDNI problem Statement = (draft-ietf-cdni-problem-statement) that is ready for WG Last Call = before IETF82 in Taipei.

As part of that I have reviewed the = complete draft and made some minor editorial clean-ups to my working = copy. However, there were a number of other areas where I think changes = need to be made to the document that I think warrant wider WG = review/consensus and I have listed them below along with the changes I = am proposing.

Could you please provide your feedback on the = areas/proposed text I have highlighted below as well as any other areas = of the document that you think require additional work/cleanup before = you consider the document is ready for a WG Last Call.

1) Section = 2: Update the last paragraph to reference the WG draft for CDNI use = cases and remove reference to draft-watson-cdni-use-cases, = i.e.

OLD:
  Use cases for CDN Interconnection are = further discussed in
  [I-D.bertrand-cdni-use-cases] = (which contains a merged set of use
  cases previously = presented in [I-D.watson-cdni-use-cases] and
=   [I-D.bertrand-cdni-use-cases-00]).
NEW:
=   Use cases for CDN Interconnection are further discussed = in
=   [I-D.ietf-cdni-use-cases].

Agreed.



2) = Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) = that are each just a couple of sentences, so I propose merging them into = a single section and changing the first two sentences of section 4 = appropriately, i.e.

OLD:
  This section expands on = how CDNI interfaces can reuse and leverage
  existing = protocols.  First the "reuse instead of reinvent" design
=   principle is restated, then each inetrface is discussed = individually
  with example candidate protocols that can = be considered for reuse or
  leverage.
NEW:
=   This section expands on how CDNI interfaces can reuse and = leverage
  existing protocols before describing each CDNI = interface individually
  and highlighting example = candidate protocols that could considered for
  reuse or = leveraging to implement the CDNI interfaces. =  

Fine by = me.



3) Section 5 is = currently title "Gap Analysis of relevant Standardisation and Research = Activities" but following the agreement at the last IETF to move the = generic descriptions of other activities into an appendix Section 5 no = longer references any research activities so I propose changing the = title to" Gap Analysis of relevant Standardisation = activities".

Agreed.


4) After the general introduction in = Section 5 there are only sections that outline other research = activities

I think you mean = "standardization activities"

= for Content Acquisition (section 5.1) and CDNI Metadata (Section 5.2) = but there are not sections for the other CDNI interfaces (Control, = Logging, Request Routing).

The reason for the lack of text is IMO = because there is no current or past standardisation activity addressing = those areas but the document currently does not mention that and = therefore gives the impression of being incomplete.

I therefore = propose making the following change to the last sentence in Section = 5:

OLD:
  The following sections will summarize the = existing work of the
  standard bodies above against the = CDNI problem space.
NEW:
  The following sections will = summarize the existing work of the
  standard bodies above = against the CDNI problem space. Section 5.1
  summarises = existing interfaces that could be leveraged for content
=   acquisition between CDNs and Section 5.2 summarises existing = metadata
  specifications that may be applicable to CDNI. = To date there is no
  existing standardisation activities = in the areas of the remaining
  CDNI interfaces (CDNI = Request Routing, CDNI Control and CDNI = Logging).

Fine.

Just a couple editorial = suggestions:

s/of the standard bodies = above/of the standard bodies listed = earlier/

s/there is no existing = standardisation activities/we are not aware of any standardisation = activities/



5) = I also propose using the following text for the third bullet in Section = 5 unless someone can suggest more appropriate text to summarise in a = sentence or two any CDN metadata related work in other standards = bodies.

OLD:
  o  <TODO: Add a sentence on = ITU>
NEW:
  o  CableLabs, SNIA and ITU have = defined (or are working on)
=      definitions for content related metadata = definitions and specification
     for its = distribution. However, they do not include metadata specific
=      to the distribution of content within a = CDN or between interconnected
=      CDNs.

<= div>That works for me. It would be good to get that validated by someone = aware of the work of these bodies.



6) Section 10.1 lists a number of "normative = references", if we adopt the proposed changes above it will end up = containing "normative" references to:
  - = draft-ietf-cdni-use-cases
  - = draft-bertrand-cdni-experiements
  - = draft-jenkins-cdni-names
  - RFC2119

After reading = through the text of the Problem Statement again, I am not convinced that = the Problem Statement references any of those documents normatively as = the 3 CDNI related drafts are referenced in a context where they are for = further information and the Problem Statement does not make use of any = of the capitalised terms defined in RFC2119.

Therefore, unless = anyone objects I will move the references for the three CDNI related = drafts to the "Informative References" section and remove the reference = for RFC2119.

I agree we don't = want normative ref to the other cdni drafts as the problem statement is = setting the stage for the other = documents.

Thanks

Franco= is



Thanks
Ben

__________________________= _____________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni



Francois Le = Faucheur
Distinguished = Engineer
Corporate Development

Cisco Systems = France
Greenside
400 Ave de Roumanille
06410 Sophia = Antipolis
France
Cisco.com

 


 Think before you = print.
/9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --Apple-Mail-340-36961257 Content-Transfer-Encoding: base64 Content-Disposition: inline; filename=green.gif Content-Type: image/gif; name="green.gif" Content-Id: R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --Apple-Mail-340-36961257-- --Apple-Mail-339-36961256-- From flefauch@cisco.com Fri Oct 28 02:49:24 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5815721F84DB for ; Fri, 28 Oct 2011 02:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gjmhk0WN94qD for ; Fri, 28 Oct 2011 02:49:23 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A01F721F849B for ; Fri, 28 Oct 2011 02:49:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=6056; q=dns/txt; s=iport; t=1319795363; x=1321004963; h=from:subject:date:message-id:cc:to:mime-version; bh=2Igst1rUWIG0CCvbbF93JVGc+1iFVZnieSwH87zz4Zo=; b=VdEkjiWmkJJkgyNFDLs5PQASLKUf9217oHTBlCdvZuairH1CPYg0z9fR yrvTWRAfhnJoq2kJXTUf1iSUuOOBdlCdmHW29G/2y3egFYBNjnpW9GQEL gJxHSBOUFGHak/eXXJGGkXRawBSduNbYZeF0inKj6AxipD1ho5al3wQr2 4=; X-IronPort-AV: E=Sophos;i="4.69,417,1315180800"; d="scan'208,217";a="10881143" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 28 Oct 2011 09:49:23 +0000 Received: from sjc-vpn5-1573.cisco.com (sjc-vpn5-1573.cisco.com [10.21.94.37]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9S9nKmB023410; Fri, 28 Oct 2011 09:49:22 GMT From: Francois Le Faucheur Content-Type: multipart/alternative; boundary=Apple-Mail-341-38258030 Date: Fri, 28 Oct 2011 11:49:17 +0200 Message-Id: <78BCE9D8-7C4F-4162-9F6B-867240993EE1@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] Content Adaptation X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 09:49:24 -0000 --Apple-Mail-341-38258030 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Folks, Speaking as a co-chair. I have been through the recent exchange on content adaptation (aka the = poorly-titled "Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt" = thread) and wanted to share a few thoughts. First, some messages might have given the impression that content = adaptation was required for a CDNI solution to be able to deal with = multiple types of terminal/resolution/sizes etc. So at the risk of = restating the obvious, let's be very explicit that this is obviously not = the case. A very simple/common way to support multiple types of = terminal/resolution/sizes in one CDN, or in a multi-CDN environment, is = to have different contents/URIs for each profile. So content adaptation is not _required_ to be supported by CDNI, but is = a candidate optimisation to do some of the same things in a different = way. Second, some messages suggested that content adaptation was a very = strong win (aka transfer 1 flow instead of 10 flows across CDNs). As = Richard pointed out already, this ignores a number of considerations = such as the cost associated with performing the actual content = adaptation downstream. Anyways, I think content adaptation may be better = seen as a trade-off that can indeed be positive in some environments, = rather than an obvious huge win. Also, without the content adaptation optimization, while the content = maybe passed across CDNs multiple times (in different formats), it is = worth noting that the smaller res/size/quality representations may = actually amount to much smaller size/bandwidth than the highest = res/size/quality, so it is not quite a multiplying factor.=20 Lastly, while the content adaptation optimization may reduce further the = inter-CDN transfer from 1-10 flows down to 1 flow, the base CDNI = solution allows a content to be transferred across CDNS 1-10 times total = instead of once per user accessing the content (as would be the case if = the uCDN pumps the same traffic to every users because it cannot = interoperate with the dCDN) which can result in a gain factor of 10s, = 100s, 1000s,..... I have the impression that the key arguments have now been exposed (some = of them even repeatedly) through the long thread. So I would suggest to = pause that discussion, unless _new_ arguments need to be brought into = the discussion, and then we can poll for consensus in Taipei and then on = the list. Thanks Francois PS: Please think of using specific Subject lines for the various threads = and don't hesitate to branch off with a different "Subject" when an = initial thread morphs into a different topic. This helps the discussion. --Apple-Mail-341-38258030 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
First, some messages might have given the = impression that content adaptation was required for a CDNI solution to = be able to deal with multiple types of terminal/resolution/sizes etc. So = at the risk of restating the obvious, let's be very explicit that this = is obviously not the case. A very simple/common way to support multiple = types of terminal/resolution/sizes in one CDN, or in a multi-CDN = environment, is to have different contents/URIs for each profile.
So = content adaptation is not _required_ to be supported by CDNI, but is a = candidate optimisation to do some of the same things in a different = way.

Second, some messages suggested that content adaptation was = a very strong win (aka transfer 1 flow instead of 10 flows across CDNs). = As Richard pointed out already, this ignores a number of considerations = such as the cost associated with performing the actual content = adaptation downstream. Anyways, I think content adaptation may be better = seen as a trade-off that can indeed be positive in some environments, = rather than an obvious huge win.
Also, without the content = adaptation optimization, while the content maybe passed across CDNs = multiple times (in different formats), it is worth noting that the = smaller res/size/quality representations may actually amount to much = smaller size/bandwidth than the highest res/size/quality, so it is not = quite a multiplying factor. 
Lastly, while the content = adaptation optimization may reduce further the inter-CDN transfer from = 1-10 flows down to  1 flow, the base CDNI solution allows a content = to be transferred across CDNS 1-10 times total instead of once per user = accessing the content (as would be the case if the uCDN pumps the same = traffic to every users because it cannot interoperate with the = dCDN) which can result in a gain factor of 10s, 100s, = 1000s,.....

I have the impression that the = key arguments have now been exposed (some of them even repeatedly) = through the long thread. So I would suggest to pause that discussion, = unless _new_ arguments need to be brought into the discussion, and then = we can poll for consensus in Taipei and then on the = list.

Thanks

Francois

PS: Please think of using = specific Subject lines for the various threads and don't hesitate to = branch off with a different "Subject" when an initial thread morphs into = a different topic. This helps the discussion.
To: Francois Le Faucheur , "cdni@ietf.org" Thread-Topic: [CDNi] Content Adaptation Thread-Index: AQHMlVbjkrelRHW/30KgzwKHb064PJWRtmZA Date: Fri, 28 Oct 2011 13:06:59 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136D0BEA@PACDCEXMB05.cable.comcast.com> References: <78BCE9D8-7C4F-4162-9F6B-867240993EE1@cisco.com> In-Reply-To: <78BCE9D8-7C4F-4162-9F6B-867240993EE1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136D0BEAPACDCEXMB05cabl_" MIME-Version: 1.0 Subject: Re: [CDNi] Content Adaptation X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 13:07:05 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1136D0BEAPACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Francois, both as co-chair and an individual. :) From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: Friday, October 28, 2011 5:49 AM To: cdni@ietf.org Subject: [CDNi] Content Adaptation Folks, Speaking as a co-chair. I have been through the recent exchange on content adaptation (aka the poor= ly-titled "Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt" thread)= and wanted to share a few thoughts. First, some messages might have given the impression that content adaptatio= n was required for a CDNI solution to be able to deal with multiple types o= f terminal/resolution/sizes etc. So at the risk of restating the obvious, l= et's be very explicit that this is obviously not the case. A very simple/co= mmon way to support multiple types of terminal/resolution/sizes in one CDN,= or in a multi-CDN environment, is to have different contents/URIs for each= profile. So content adaptation is not _required_ to be supported by CDNI, but is a c= andidate optimisation to do some of the same things in a different way. Second, some messages suggested that content adaptation was a very strong w= in (aka transfer 1 flow instead of 10 flows across CDNs). As Richard pointe= d out already, this ignores a number of considerations such as the cost ass= ociated with performing the actual content adaptation downstream. Anyways, = I think content adaptation may be better seen as a trade-off that can indee= d be positive in some environments, rather than an obvious huge win. Also, without the content adaptation optimization, while the content maybe = passed across CDNs multiple times (in different formats), it is worth notin= g that the smaller res/size/quality representations may actually amount to = much smaller size/bandwidth than the highest res/size/quality, so it is not= quite a multiplying factor. Lastly, while the content adaptation optimization may reduce further the in= ter-CDN transfer from 1-10 flows down to 1 flow, the base CDNI solution al= lows a content to be transferred across CDNS 1-10 times total instead of on= ce per user accessing the content (as would be the case if the uCDN pumps t= he same traffic to every users because it cannot interoperate with the dCDN= ) which can result in a gain factor of 10s, 100s, 1000s,..... I have the impression that the key arguments have now been exposed (some of= them even repeatedly) through the long thread. So I would suggest to pause= that discussion, unless _new_ arguments need to be brought into the discus= sion, and then we can poll for consensus in Taipei and then on the list. Thanks Francois PS: Please think of using specific Subject lines for the various threads an= d don't hesitate to branch off with a different "Subject" when an initial t= hread morphs into a different topic. This helps the discussion. --_000_1CA25301D2219F40B3AA37201F0EACD1136D0BEAPACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Francois, both as co-chair and an individual. J

 

From: cdni-bou= nces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur
Sent: Friday, October 28, 2011 5:49 AM
To: cdni@ietf.org
Subject: [CDNi] Content Adaptation

 

Folks,

Speaking as a co-chair.

I have been through the recent exchange on content adaptation (aka the poor= ly-titled "Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt&quo= t; thread) and wanted to share a few thoughts.

First, some messages might have given the impression that content adaptatio= n was required for a CDNI solution to be able to deal with multiple types o= f terminal/resolution/sizes etc. So at the risk of restating the obvious, l= et's be very explicit that this is obviously not the case. A very simple/common way to support multiple ty= pes of terminal/resolution/sizes in one CDN, or in a multi-CDN environment,= is to have different contents/URIs for each profile.
So content adaptation is not _required_ to be supported by CDNI, but is a c= andidate optimisation to do some of the same things in a different way.

Second, some messages suggested that content adaptation was a very strong w= in (aka transfer 1 flow instead of 10 flows across CDNs). As Richard pointe= d out already, this ignores a number of considerations such as the cost ass= ociated with performing the actual content adaptation downstream. Anyways, I think content adaptation may be = better seen as a trade-off that can indeed be positive in some environments= , rather than an obvious huge win.

Also, without the content adaptation optimization, w= hile the content maybe passed across CDNs multiple times (in different form= ats), it is worth noting that the smaller res/size/quality representations = may actually amount to much smaller size/bandwidth than the highest res/size/quality, so it is not quite a mul= tiplying factor. 
Lastly, while the content adaptation optimization may reduce further the in= ter-CDN transfer from 1-10 flows down to  1 flow, the base CDNI soluti= on allows a content to be transferred across CDNS 1-10 times total instead = of once per user accessing the content (as would be the case if the uCDN pumps the same traffic to every users be= cause it cannot interoperate with the dCDN) which can result in a gain= factor of 10s, 100s, 1000s,.....


I have the impression that the key arguments have now been exposed (some of= them even repeatedly) through the long thread. So I would suggest to pause= that discussion, unless _new_ arguments need to be brought into the discus= sion, and then we can poll for consensus in Taipei and then on the list.

Thanks

Francois

PS: Please think of using specific Subject lines for the various threads an= d don't hesitate to branch off with a different "Subject" when an= initial thread morphs into a different topic. This helps the discussion.

 

--_000_1CA25301D2219F40B3AA37201F0EACD1136D0BEAPACDCEXMB05cabl_-- From flefauch@cisco.com Fri Oct 28 06:49:51 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CA321F84DF for ; Fri, 28 Oct 2011 06:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.272 X-Spam-Level: X-Spam-Status: No, score=-6.272 tagged_above=-999 required=5 tests=[AWL=-4.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6, MIME_HTML_ONLY=1.457, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqVh68UHkbK7 for ; Fri, 28 Oct 2011 06:49:48 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 1A79221F84FB for ; Fri, 28 Oct 2011 06:49:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=159608; q=dns/txt; s=iport; t=1319809784; x=1321019384; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=dG7zSnmpKJZnW0lWdVUWtOYyW1DMJKkytB43F3Bp+tw=; b=i5TJGDaOARrsJmGb+14I3bYMlBX+9nUS87nSp5irl6rh6aQH4JKhidBN PoScMiJQOCPULOffs0DaSShSqxtBG+WITDz1JKcaFBFP6C+ZfByh6G3f8 uFIGhvY4f5VR2q+Yg+1u0xQ02T0DZjueSt9Yyy/F+nTr7G579GWKmygJW A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsAAGqyqk6Q/khN/2dsb2JhbABCgk2CKpUbRIc6AYYHSwJ5gQWBcgEBAQEDAQEBDwEHCSYlBAcMAgILEQEDAQEDAhwBBgMCAhYRHwMGCAYKCRQFAQEHh2iWBwGMSoFqj3ACgS6GPzNhBJQNijeHKg X-IronPort-AV: E=Sophos;i="4.69,418,1315180800"; d="scan'208,217";a="1973162" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 28 Oct 2011 13:49:40 +0000 Received: from ams-flefauch-8712.cisco.com (ams-flefauch-8712.cisco.com [10.55.161.195]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9SDnWBA006836; Fri, 28 Oct 2011 13:49:34 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/html; charset=utf-8 X-Apple-Base-Url: x-msg://454/ X-Apple-Mail-Remote-Attachments: YES From: Francois Le Faucheur In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> X-Apple-Windows-Friendly: 1 Date: Fri, 28 Oct 2011 15:46:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <817779F3-8F95-42BA-9DA3-34EF81DFDB71@cisco.com> References: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> X-Uniform-Type-Identifier: com.apple.mail-draft To: ZhouZhipeng X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 13:49:51 -0000 Hi again Zhipeng,

There is one = other point I should have brought up in my previous = message:
The question is not so much whether there are = benefits to allowing content adaptation for some environments, nor = whether one particular individual could conceive an approach for content = adaptation that suits him. The question here is rather whether it is = justified for the Working Group to focus energy on that problem right = now in order to develop a consensus-based approach that suits the = community as a whole, while we don't even have the base solution in = place.

You have made it clear that you feel the = WG should indeed dedicate energy on that problem right away and = explained your rationale. Thank you. Others have also expressed their = opinions.

Cheers

Francoi= s


On 28 Oct 2011, at 11:25, = ZhouZhipeng wrote:

Dear = all,
In these = days I am busy making a summary analysis on this topic. As Richard=E2=80=99= s request, I like to show my information although perhaps not complete = right now.
 
1) I have done some work to collect different company=E2=80=99= s requirements and opinions on this = functionality.
One, I feel most of us = have already been aware of the service of content adaptation, and I also = sent an email yesterday that Vodaphone now is requiring the solution to = enhance the performance of its mobile video = service.
Second, here is an = article about CISCO : =E2=80=9CCisco urges mobile operators to add value = to CDN services=E2=80=9D Besides, I have checked many CDN company=E2=80=99s = websites. Many claim to support transcoding while some may = not.
There are two solutions:
 
 
>In your = company=E2=80=99s website, I just find some information

I have to = step in as co-chair here.

The goal of this WG is not to align = vendor product roadmaps, or to equalize all vendor offerings, or to = specify the entire CDNI ecosystem. The goal of this WG is to enable the = interconnection and interoperation of two or more CDNs, within the = bounds of the CDNI wg charter.

It is OK to have a discussion = about whether content adaptation needs to be performed by the dCDN, = since that decision impacts the uCDN-dCDN interface. So let's find a = productive way to discuss this on the mailing list, and to close the = discussion by IETF 82 (if not sooner).

Can someone describe = real-life examples where downstream CDN (or edge cache-based) content = adaptation is needed today in a production environment, or shortly? Not = merely a feature in a vendor's product materials?

Speaking as an = individual, I can find a lot of examples where downstream content = adaptation is not needed, and any adaptation is really part of the CP - = uCDN interface (which is out of the scope of our charter).

-- = Rich

 
From: = ZhouZhipeng [mailto:zhouzhipeng@huawei.com] 
Sent: Thursday, = October 27, 2011 03:45 AM
To: Mark de Jong <mark@jet-stream.nl>; Alan Kavanagh = <alan.kavanagh@ericsson.com> 
Cc: cdni@ietf.org <cdni@ietf.org> 
Subject: Re: = [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt 
 
Hello Mark,
Nice to = meet you on line.
In your company=E2=80=99s website, I just find some = information that addresses =E2=80=9C Vodafone subscribers complained about video = performance.=E2=80=9DSee:
 
Hi = Alan,
 
As Ben stated the overall = discussion right now is about delivery, not on adaptation. It is hard = enough to get consensus on the delivery aspect already not to mention = your requirement from content adaptation added to that, so I agree with = Ben we should stick with the delivery aspect for the first specs. I = can imagine this could be a discussion later on but please let us keep = the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. = Thanks.
 
Met vriendelijke groet,
Kind = regards,

Mark de Jong
International Business = Developer
Jet-Stream = BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214
- = Event: Meet us at = Streaming Media Europe, 17-18 October, London, UK
- Event: Meet us at Online Video Strategies, 19 = October, London, UK- = Event: Meet us at CDN World Summit, 25-28 = October, London, UK  Pre-request your Technology Whitepaper = now and be the first to have it, check www.jet-stream.com
- News: Check http://www.jet-stream.com to download our 'Six Trends = in CDNs' brochure 
-  
On 26, Oct,2011, at 8:33 PM, Alan = Kavanagh wrote:

 

Ben

Im assuming = then based on your comments below are you suggesting we are going to = have a number of versions of the CDN-I Metadata?

I sympathise = with what you are pointing out below and do agree that there is some = work to be done, but I still feel that content adaptation is to me a = fundamental requirement to what collectively we should address in the = CDN-I WG. I do agree with you that content adaptation is an optimization = between CDN's but it's a very important one that I know Network Service = Providers particularly require.

Alan

-----Original = Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: = ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 12 Oct 2011, = at 10:22, ZhouZhipeng wrote:

Hello = Ben,
The UE may select the = content format on the CP web. After that the user only desires to get = his selected content.
But how the content is transferred to the client is not = worried by the user.
The CP may create a special format as required by the = user and ask the CDN to deliver to = user.
While CP = may give a HD format content to uCDN and the dCDN may then transform to = the format as the user select.


Lots of things may = be possible to do and CDN providers offer many additional services on = top of the "core" service of content delivery. However, our objective = (based on my interpretation of the CDNI charter) is to focus on what is = necessary to interconnect CDNs to deliver content from a CSP to an End = User that is targeted and deployable within a short time frame (18-24 = months).

Content transformation/adaptation is not an essential = requirement in order to achieve that aim (we can deliver content from = CSPs to End Users via multiple CDNs without needing or requiring any CDN = supports content adaptation).

In my opinion we have enough work = to do already without trying to expand the scope of our work to include = additional requirements that do not help us address our core objectives = as laid out in the CDNI charter.

In this case, it is nothing = related to how the user select formats on CP = website.
So, it is the CP and = user to decide the content format not the CDN(your assert is not correct = and seems you take that assert as your base for the = discussion).
 
As for "the core CDN functionality offered by CDNs = today", I have ever raised an email before that your company's webpage = has claimed supporting media transformation and multi-screen = service.
Perhaps, I like asking you list some features that you = feel are the core functionalities by existing main stream CDNs. Thus we = may compare and take deep look.


I think the core = functionality maps pretty well to the CDNI interfaces, namely: Request = Routing, Metadata configuration, log production and control plus content = acquisition and content delivery.

I guess many people have the = experience/knowledge of content related service. The user and CP only = care whether the CDN providers may satisfy their requirement while not = care the internal process. Just as GSM/PSTN interconnection, the user = only care successful interconnection while not care how the voice is = transformed in process.
 
Besides, I like raise a = case:
Given = currently BBC recruits CDN providers that may support 10 media = formats.
One candidate is your company, another is CDN-X. The = users are located in = France.
So both your company and CDN-X should connect a France = CDN provider(CDN-Y).
If your company's solution is to send 10 streams of = different format
of one content to CDN-Y; While CDN-X's solution is to = send 1 stream to CDN-Y while CDN-Y may conduct some = adaptation.
Comparing these two solutions, for your company and = CDN-X, absolutely the cost of CDN-X is much = lower.
For CDN-Y, in solution-1, it should receive/forward 10 = streams ; while in solution-2, it should only receive 1 stream but need = to take transformation to output 10 = streams.
 
Which solution is more competitive. it is Solution 1, = right. Remember the price from BBC is same to both your company and = CDN-X or BBC would select one CDN provider with the lower = price.
If a CDN provider may not get the contract from CP, how = it may say it is not a core = functionality.


What you are describing is a possible = optimization that a particular CDN may wish to implement not a core = functionality required to enable content delivery between interconnected = CDNs. I can think of many optimizations that a CDN could implement to = differentiate their service but the internal workings of an individual = CDN are out of scope of our charter.

So to repeat my position for = a final time: Content adaptation is not a core function required to = enable content delivery between interconnected CDNs and therefore given = the workload we already have to specify solutions that do address the = core functionality required to interconnect CDNs I do not think we = should be trying to add more work into that workload as it will only = distract us from achieving our goal of producing deployable solutions = within the timeframe we are being told by operators they needs solutions = within.

Ben

So, if we all realize that currently the media type is = rich, the CDN providers should survive in the existing ecosystem and = support the media types as required by the = market.
 
Back to the case of GSM/G.711, it just when concerning = the interconnection, the transformation should at once be solved. = Otherwise the interconnection may not be = operated.
 
Br,
Zhipeng
 
 
 
 
-----Original = Message-----
From: Ben Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]
Sent: Wednesday, October 12, 2011 = 12:19 AM
To: = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Zhipeng,
 
On 11 Oct 2011, at 05:16, ZhouZhipeng = wrote:
 
Ben and = Philip,
I like to respond your concern in this one = email:
 
Ben,
I feel what we are now discussing is what is the "core" = function of = CDN.
As you say, CDN is used to deliver content. That is = absolutely correct that the delivery capability is the core requirement = for CDN = system.
While CDN is used to provide the content delivery = service.
What means service. It should include "time" "location" = and "media type", etc. These features are all the core feature for a = service.
If we only concern "delivering one data block", I am not = sure whether the issues such as "logging" "geographic constraint" are = the core of = CDN.
 
For "without explicit knowledge of what that content = actually is ", I am not sure whether the wording is accurate since = generally a CDN may claim it support different = medias.
By this opportunity, I like to share a use case: a call = from a GSM phone to a PSTN telephone, the voice stream should be = transformed from GSM voice to = G.711.
For the user, he does not need to know what type of data = has been transferred, but the operator has done some work to = interconnect two systems, = right.
I like to know whether you may accept that my use case is = similar to this case = above.
 
I don't think your use case is similar to the analogy of = mobile networks being interconnected to PSTN networks. In the case of = content delivery the negotiation is done between the User/Client and the = Content Provider and the CDN is just used to execute/perform the = delivery that has been negotiated. The CDN is not involved in the = decision making of what representations the Content Provider decides to = offer to the User/Client or in what representations the User/Client = decides to request.
 
As for you said selecting media by the "portal", you may = see the way " uCDN delivers multiple media streams to dCDN" is not good = than "uCDN delivers one media stream to dCDN and dCDN takes some = adaptation to support multiple media = types".
 
Now what you're talking about is an optimisation, not a = core function required to actually deliver the content (and report, = bill, etc. for that = delivery).
 
My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO.
 
Ben
 
A good question is "security" since I have done six years = on the DRM
and like to promote the DRM all around the world:) If the = content is needed to be protected, generally you may know all the = systems should be granted by the content = owner.
Here I also like to clarify that not only the media = itself but the information related to service itself (such as the = geographic constraint) should be protected = also.
So, trust is not a problem for the = media.
 
Philip,
Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use = case.
I like to clarify to U that it is important for you = operator since it may save investment if the system may support = different = services.
For us vendor, we are happy operator may install a system = for the mobile service and another system for the FBB = service.
But the reality is all operators ask us to provide a = system that may support different service = systems.
 
Frankly, Ben and Philip, I remember I have explained = somewhere that to implement this is rather simple = .
At least the Use case and Requirement are informational = to be referred in future work. So I do really feel you may accept = it.
Of course I like to respond your more concern and = comments.
Thanks.
Zhipeng
 
 
 
-----Original = Message-----
From: philip.eardley@bt.com [mailto:philip.eardley@bt.com= ]
Sent: Monday, October 10, 2011 11:22 = PM
To: ben@niven-jenkins.co.uk; = ZhouZhipeng
Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Ben, Zhipeng, = all,
 
I think that Content Adaptation is more an issue for the = Requirements doc than for the Use cases = draft.
 
The key question is whether we want the CDNI interfaces = to be able to cope with a scenario where (say) HD/SD conversion is done = in the dCDN & to signal about = this.
 
I think that coping with this scenario is a second order = requirement, ie we should not worry about it in the initial = standards-track work. I don't know, did we ever decide whether the Use = cases doc is restricted to "initial" scenarios, or whether it's = all-encompassing, ie covering "future" scenarios as = well?
 
Scott,
Reading some of your examples, they seem to be valid even = if content adaptation (HD/SD) is out of = scope.
- a dCDN might for some reason be unwilling to distribute = HD?
- a CSP might want to make sure the dCDN can use HLS = encapsulation?
But these sorts of examples seem to be static policy = things (to = do
with the capabilities & preferences of the CDNs & = CSP), rather = than
metadata associated with a particular piece of content. = In the
discussion so far, I think negotiation about static = policy stuff = is
rather out of = scope(?)
 
On security considerations, an interesting question is = whether trust is transitive. Don't think it need be - just because CSP = trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP = automatically trusts the dCDN. However, i suspect this can get = arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.
 
Best = wishes
phil
 
 
Philip = Eardley
Research and Technology = Strategy
 
This email contains BT information, which may be = privileged or confidential. It's meant only for the individual(s) or = entity named above. If you're not the intended recipient, note that = disclosing, copying, distributing or using this information is = prohibited. If you've received this email in error, please let me know = immediately on the email address above. Thank you. We monitor our email = system, and may record your = emails.
British Telecommunications = plc
Registered office: 81 Newgate Street London EC1A 7AJ = Registered = in
England no: = 1800000
 
 
-----Original = Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf
Of Ben = Niven-Jenkins
Sent: 10 October 2011 = 12:04
To: = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Colleagues,
 
IMO Section 5.1.3 should be removed from the Use Cases = draft. Content Adaptation (i.e. taking in a content item in one format = and transforming it to another format or representation) is not a "core" = function of a CDN which typically delivers the content that is requested = without explicit knowledge of what that content actually = is.
 
Let's not forget that in building an end to end content = service the CDN is only one component and is the component tasked with = executing the delivery of a specific representation (version/copy/format = etc.) of the selected content not the component tasked with deciding (or = applying policy) on which version/copy/representation of content should = be = delivered.
 
The decision as to which version/copy/representation to = offer and allow to be delivered to a given device/user is implemented = outside of the CDN (e.g. by the "portal" where the user first makes = their content selection prior to the CDN becoming involved in the = delivery of the selected = content).
 
Ben
 
On 8 Oct 2011, at 08:20, ZhouZhipeng = wrote:
 
Following Scott's comments on section 5.1.3, I feel = Scott's description on the use case of HD and SD is not exactly = correct.
If one movie has two formats of HD and SD, then we have = two content with different identifier. In DRM scope, the basic unit is a = content = copy.
 
Here the first bullet "a subset of = encodings deliverable to specific devices," has listed the case of = content = adaptation.
=
In last month, I have contacted the Authors of this = document and taken some email exchanges with Grant and Philip = (BT).
I have shown BT with some information that I know in this = case and area to explain the content flexibility is currently a basic = requirement for CDN service and related negotiation is needed in the CDN = interconnection.
Meanwhile, I should also invite = you in this group raising your comments or questions on this case since = I hope my use case may be incorporated in the use case = draft.
 
If you have any more question or = comments, pls share in this = thread.
Thanks.
Zhipeng
 
 
 
 
 
 
-----Original = Message-----
From: Scott Wainner = [mailto:swainner@cisco.com]
Sent: Friday, September 30, 2011 = 8:02 = AM
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Section 2.3 Nomadic = Users
This description falls under the category of Geographic = Extension
yet the third paragraph states the case where a different = device = is
used in the same CDN coverage area.  The intent of = this use = case
needs to be clarified.  Perhaps the use case is = trying to = address
the scenario where a Nomadic User-A with an agreement = allowing
access to content from CSP-A via uCDN moves to a dCDN in = a = different
region.  The dCDN is allowed to distribute the = content of CSP-A = to
User-A; however, not other users in the region of the = dCDN = are
allowed to retrieve the content unless they too have such = an = agreement.
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
 
Section 5.1.3 Content Encoding = Restrictions Need to clarify if = we're
talking about the restrictions on the delivery of = specific = content
or the restrictions on the ability of a CDN to deliver = specific
content.  I certainly understand the case where a = CSP will = restrict
the distribution of content to a "managed path" if such = content = is
HD while allowing the content distribution via an = un-managed path = if
such content is SD (same could apply to encryption = methods, = delivery
methods, etc.).  On the contrary, the dCDN may have = its = own
restrictions of blocking the distribution of HD content = while
allowing the distribution of SD = content.
 
o first bullet makes sense if the = dCDN can perform a subset = of
encapsulations for a reference set of media (e.g. HLS, = HSS, but = not
DASH) o second bullet makes sense where the dCDN doesn't = want = to
offer high bit-rate variants of the media o third bullet = make = sense
if the policy addresses QoE but I don't think = subscriber
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
rights/authorizations = apply.
 
Section 10 Security = Considerations
 
Aside from the security = considerations WITHIN the uCDN and dCDN, = I
think we can describe this in four = contexts:
 
a. The relationship between the = CSP and the uCDN (the principle = contract
arrangement for = distribution)
b. The relationship between the = uCDN and dCDN (the transitive = trust
relationship that extends the contract defined in (a) = above) c. = The
relationship between the User and dCDN (the recognition = of right = to
download predicated on (b) above) d. The relationship = between = the
User and CSP (the contract authorizing the user access to = the
content)
<= /blockquote>
 
The user is not interested in the = a-b nor the b-c relationship. = The
user is only interested in the transparency and = interoperability = of
the security relationship between d-b or d-c to the point = that = the
authorization granted in d-a is viable when the delivery = is
initiated via either d-b or d-c.  As an example, the = uCDN might = use
URL appended tokens for authentication while dCDN might = use = URL
appended hashes.  The user doesn't want to know = about the = distinct
methods, but transparency is only afforded if the methods = are
interoperable clearly defined when the delegation for = content
delivery is executed.  Clearly, the choice of = authentication method is determined by the respective = CDN's.
 
Scott
 
_______________________________________________<= /span>
CDNi mailing = list
_______________________________________________<= /span>
_________________= ______________________________
CDNi mailing list
CDNi@ietf.org
In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> Date: Fri, 28 Oct 2011 15:49:34 +0200 Message-Id: <144D124A-E8A2-48DC-A98D-6F33B2EB1B90@cisco.com> References: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> To: ZhouZhipeng X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:01:26 -0000 --Apple-Mail-415-52674518 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi again Zhipeng, There is one other point I should have brought up in my previous = message: The question is not so much whether there are benefits to allowing = content adaptation for some environments, nor whether one particular = individual could conceive an approach for content adaptation that suits = him. The question here is rather whether it is justified for the Working = Group to focus energy on that problem right now in order to develop a = consensus-based approach that suits the community as a whole, while we = don't even have the base solution in place. You have made it clear that you feel the WG should indeed dedicate = energy on that problem right away and explained your rationale. Thank = you. Others have also expressed their opinions. Cheers Francois On 28 Oct 2011, at 11:25, ZhouZhipeng wrote: > Dear all, > In these days I am busy making a summary analysis on this topic. As = Richard=92s request, I like to show my information although perhaps not = complete right now. > =20 > 1) I have done some work to collect different company=92s = requirements and opinions on this functionality. > One, I feel most of us have already been aware of the service of = content adaptation, and I also sent an email yesterday that Vodaphone = now is requiring the solution to enhance the performance of its mobile = video service. > Second, here is an article about CISCO : =93Cisco urges mobile = operators to add value to CDN services=94 = http://www.totaltele.com/view.aspx?ID=3D468705 > Besides, I have checked many CDN company=92s websites. Many claim to = support transcoding while some may not. > =20 > 2) For the wording =93content adaptation=94, it should be = clarified here that it may be two kinds. > One is only the transformation of encapsulation format. For example = the H.264 stream is encapsulated in APPLE and Adobe format respectively. > I know that Comcast has a project that needs to pick the H.264 media = from the TS stream and then encapsulated them into different = formats(APPLE,Adobe=85) to different devices. > For this kind of transformation, the computing cost is very very low = and may be nearly neglected. > The other is to transcoding. For example to support different = bitrates. Since encoder is a high value facility, we should compare the = capital cost of encoder and transport cost. > Just take a simple model: content is delivered from Node A to Node B. > > There are two solutions: > 1) A have the transcoder and deliver multi-format content to B > 2) B have the transcoder; A only delivers one format content to B = and B would transcode. > =46rom whole system point of view, either A or B would transcode while = the bandwidth would be saved in solution B. Hence solution B is better. > Now provided the bandwidth is paid by B and B should decide whether to = install transcoder. > (Richard has said to set transcoder in each edge server) > If the cost of renting bandwidth (for a few months) is more expensive = than the price of transcoder supporting the same bandwidth, it would be = better to put the transcoder at the receiver Node B. > In fact I have investigated this issue for much time. While in = different area the price of bandwidth may be different. And the = transport burden between two distant places or over a bad nature = environment would be much higher. > Here the price in USA may be referred as: = http://smallbusiness.verizon.com/products/internet/hsi/overview.aspx#plans= . > In Verizon, the package for 10-15mbps is $90 per month (I feel the = bandwidth quality for business would be guaranteed). I query that the = bandwidth price in China may be 50% higher. > I do not know how much the price will be for the bandwidth from = Amsterdam to Paris (cross country in the same continent). But I feel = the price from NewYork to Paris would absolutely be very high. As for = the Encoder, it also varies. Perhaps the price in China will be higher = than in USA. And in fact the price of bandwidth and encoder depends = mostly on the concrete business items. For example the price to Huawei = may be lower than the public price. > By my current evaluation in China it is better using the transcoder = than renting multiple times broadband. > Some people have told me that for the operator himself probably the = bandwidth cost would be very low in the internal capital counting. But = for the independent CDN, it may another thing. > So, my suggestion is to let different ways co-exist. I have announced = that to let two sides negotiate whether to assign dCDN for the content = adaptation. > =20 > In fact, from CP to CDN, there are the real businesses that either = let CP to provide multi-format content or let the CDN to receive one = format and complete the transformation, depending on the concrete = business. > By the same logic, form uCDN to dCDN, it may be either the uCDN to = provide multi-format content or the dCDN to receive one format content = and then complete the transformation. > Currently there is not the real CDN-CDN connection, hence we are = basing our knowledge on the related solution to make our solutions. > =20 > 3) As for the procedure of content adaptation, I just draft a = diagram as below: > > =20 > You may see the solution is rather clear and the metadata needed would = be clear also. > =20 > Dear, > By my analysis above, I kindly invite your ideas whether it may be an = applicable and simple part in the CDNI item, provided that the solution = is open to the types of content adaptation and may be optionally = implemented in the real solutions/business. I feel for those operators = that need such functionality it would be very good while it does not = impact others that do not implement it. > Thanks. > Zhipeng > =20 > =20 > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com]=20 > Sent: Thursday, October 27, 2011 7:23 PM > To: ZhouZhipeng; 'mark@jet-stream.nl'; 'alan.kavanagh@ericsson.com' > Cc: 'cdni@ietf.org'; Woundy, Richard > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > >In your company=92s website, I just find some information >=20 > I have to step in as co-chair here. >=20 > The goal of this WG is not to align vendor product roadmaps, or to = equalize all vendor offerings, or to specify the entire CDNI ecosystem. = The goal of this WG is to enable the interconnection and interoperation = of two or more CDNs, within the bounds of the CDNI wg charter. >=20 > It is OK to have a discussion about whether content adaptation needs = to be performed by the dCDN, since that decision impacts the uCDN-dCDN = interface. So let's find a productive way to discuss this on the mailing = list, and to close the discussion by IETF 82 (if not sooner). >=20 > Can someone describe real-life examples where downstream CDN (or edge = cache-based) content adaptation is needed today in a production = environment, or shortly? Not merely a feature in a vendor's product = materials? >=20 > Speaking as an individual, I can find a lot of examples where = downstream content adaptation is not needed, and any adaptation is = really part of the CP - uCDN interface (which is out of the scope of our = charter). >=20 > -- Rich >=20 > =20 > From: ZhouZhipeng [mailto:zhouzhipeng@huawei.com]=20 > Sent: Thursday, October 27, 2011 03:45 AM > To: Mark de Jong ; Alan Kavanagh = =20 > Cc: cdni@ietf.org =20 > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt=20 > =20 > Hello Mark, > Nice to meet you on line. > In your company=92s website, I just find some information that = addresses =93 Vodafone subscribers complained about video performance.=94 > See: > http://www.jet-stream.nl/search/?search=3Dtranscoding > =20 > Dear all in this group, > In last few days, except the public email discussions I have contacted = with some people and discussed with my own colleagues of all details on = this issue. > First, although the market requirement for it is very important, I = feel I=92d better show up more information on the procedure involved. I = have explained many times that to support content adaptation is rather = simple while the wording is not enough. > I am busy making some contributions on this and plan to upload to ETSI = meeting and IETF CDNI. > By these work I feel the people may catch a whole view on this issue. > Second, for that functionality, in implementation, if some entity does = not choose to support it, it may be ok. Since it may be negotiated = between two CDNs. > If dCDN does not support that, it may be the uCDN responsible to = complete the transcoding and deliver the content of multiple formats and = rates to dCDN. > Third, although CDNI is a new architecture, while the content = operating has been existed for years. As I know the content from USA to = the downstream operator is transferred on one copy and the downstream = operator will handle the transcoding. > =20 > Perhaps, the content adaptation is more on the mobile operating. But I = feel currently most operator will be a all service operator. And for the = CDN providers, it may be better to support all kinds of service. > Besides, I like say that the technology on this topic has been for = many years and has been rather mature, even some items in ietf such as = rfc3507 icap. So from the technique point of view, it is a nature = action to be involved in CDN interconnection. > Thanks. > Zhipeng > =20 > =20 > =20 > =20 > From: Mark de Jong [mailto:mark@jet-stream.nl]=20 > Sent: Thursday, October 27, 2011 4:21 AM > To: Alan Kavanagh > Cc: Ben Niven-Jenkins; ZhouZhipeng; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Hi Alan, > =20 > As Ben stated the overall discussion right now is about delivery, not = on adaptation. It is hard enough to get consensus on the delivery aspect = already not to mention your requirement from content adaptation added to = that, so I agree with Ben we should stick with the delivery aspect for = the first specs. I can imagine this could be a discussion later on but = please let us keep the scope of this be clean and transparent. It is of = benefit of everyone to get the first specs as fast as possible. Thanks. > =20 > Met vriendelijke groet, > Kind regards, >=20 > Mark de Jong > International Business Developer > Jet-Stream BV >=20 > E-mail: mark@jet-stream.com > Office: +31 (0)50 5261820 > Mobile: +31 (0)6 81108263 > Fax: +31 (0)50 5264214 > =20 > - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK > - Event: Meet us at Online Video Strategies, 19 October, London, UK > - Event: Meet us at CDN World Summit, 25-28 October, London, UK > - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com > - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure > =20 > - Blog: www.jet-stream.com/blog/ > - VideoExchange: www.vdo-x.net > - Streamzilla: www.streamzillacdn.com > - Corporate: www.jet-stream.com > =20 > On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: > =20 >=20 > Ben >=20 > Im assuming then based on your comments below are you suggesting we = are going to have a number of versions of the CDN-I Metadata? >=20 > I sympathise with what you are pointing out below and do agree that = there is some work to be done, but I still feel that content adaptation = is to me a fundamental requirement to what collectively we should = address in the CDN-I WG. I do agree with you that content adaptation is = an optimization between CDN's but it's a very important one that I know = Network Service Providers particularly require. >=20 > Alan >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Ben Niven-Jenkins > Sent: October-12-11 1:13 PM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Zhipeng, >=20 > On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: >=20 >=20 > Hello Ben, > The UE may select the content format on the CP web. After that the = user only desires to get his selected content. > But how the content is transferred to the client is not worried by the = user. > The CP may create a special format as required by the user and ask the = CDN to deliver to user. > While CP may give a HD format content to uCDN and the dCDN may then = transform to the format as the user select. >=20 > Lots of things may be possible to do and CDN providers offer many = additional services on top of the "core" service of content delivery. = However, our objective (based on my interpretation of the CDNI charter) = is to focus on what is necessary to interconnect CDNs to deliver content = from a CSP to an End User that is targeted and deployable within a short = time frame (18-24 months). >=20 > Content transformation/adaptation is not an essential requirement in = order to achieve that aim (we can deliver content from CSPs to End Users = via multiple CDNs without needing or requiring any CDN supports content = adaptation). >=20 > In my opinion we have enough work to do already without trying to = expand the scope of our work to include additional requirements that do = not help us address our core objectives as laid out in the CDNI charter. >=20 >=20 > In this case, it is nothing related to how the user select formats on = CP website. > So, it is the CP and user to decide the content format not the = CDN(your assert is not correct and seems you take that assert as your = base for the discussion). > =20 > As for "the core CDN functionality offered by CDNs today", I have ever = raised an email before that your company's webpage has claimed = supporting media transformation and multi-screen service. > Perhaps, I like asking you list some features that you feel are the = core functionalities by existing main stream CDNs. Thus we may compare = and take deep look. >=20 > I think the core functionality maps pretty well to the CDNI = interfaces, namely: Request Routing, Metadata configuration, log = production and control plus content acquisition and content delivery. >=20 >=20 > I guess many people have the experience/knowledge of content related = service. The user and CP only care whether the CDN providers may satisfy = their requirement while not care the internal process. Just as GSM/PSTN = interconnection, the user only care successful interconnection while not = care how the voice is transformed in process. > =20 > Besides, I like raise a case: > Given currently BBC recruits CDN providers that may support 10 media = formats. > One candidate is your company, another is CDN-X. The users are located = in France. > So both your company and CDN-X should connect a France CDN = provider(CDN-Y). > If your company's solution is to send 10 streams of different format > of one content to CDN-Y; While CDN-X's solution is to send 1 stream to = CDN-Y while CDN-Y may conduct some adaptation. > Comparing these two solutions, for your company and CDN-X, absolutely = the cost of CDN-X is much lower. > For CDN-Y, in solution-1, it should receive/forward 10 streams ; while = in solution-2, it should only receive 1 stream but need to take = transformation to output 10 streams. > =20 > Which solution is more competitive. it is Solution 1, right. Remember = the price from BBC is same to both your company and CDN-X or BBC would = select one CDN provider with the lower price. > If a CDN provider may not get the contract from CP, how it may say it = is not a core functionality. >=20 > What you are describing is a possible optimization that a particular = CDN may wish to implement not a core functionality required to enable = content delivery between interconnected CDNs. I can think of many = optimizations that a CDN could implement to differentiate their service = but the internal workings of an individual CDN are out of scope of our = charter. >=20 > So to repeat my position for a final time: Content adaptation is not a = core function required to enable content delivery between interconnected = CDNs and therefore given the workload we already have to specify = solutions that do address the core functionality required to = interconnect CDNs I do not think we should be trying to add more work = into that workload as it will only distract us from achieving our goal = of producing deployable solutions within the timeframe we are being told = by operators they needs solutions within. >=20 > Ben >=20 >=20 > So, if we all realize that currently the media type is rich, the CDN = providers should survive in the existing ecosystem and support the media = types as required by the market. > =20 > Back to the case of GSM/G.711, it just when concerning the = interconnection, the transformation should at once be solved. Otherwise = the interconnection may not be operated. > =20 > Br, > Zhipeng > =20 > =20 > =20 > =20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Wednesday, October 12, 2011 12:19 AM > To: ZhouZhipeng > Cc: philip.eardley@bt.com; cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Zhipeng, > =20 > On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: > =20 > Ben and Philip, > I like to respond your concern in this one email: > =20 > Ben, > I feel what we are now discussing is what is the "core" function of = CDN. > As you say, CDN is used to deliver content. That is absolutely correct = that the delivery capability is the core requirement for CDN system. > While CDN is used to provide the content delivery service. > What means service. It should include "time" "location" and "media = type", etc. These features are all the core feature for a service. > If we only concern "delivering one data block", I am not sure whether = the issues such as "logging" "geographic constraint" are the core of = CDN. > =20 > For "without explicit knowledge of what that content actually is ", I = am not sure whether the wording is accurate since generally a CDN may = claim it support different medias. > By this opportunity, I like to share a use case: a call from a GSM = phone to a PSTN telephone, the voice stream should be transformed from = GSM voice to G.711. > For the user, he does not need to know what type of data has been = transferred, but the operator has done some work to interconnect two = systems, right. > I like to know whether you may accept that my use case is similar to = this case above. > =20 > I don't think your use case is similar to the analogy of mobile = networks being interconnected to PSTN networks. In the case of content = delivery the negotiation is done between the User/Client and the Content = Provider and the CDN is just used to execute/perform the delivery that = has been negotiated. The CDN is not involved in the decision making of = what representations the Content Provider decides to offer to the = User/Client or in what representations the User/Client decides to = request. > =20 > As for you said selecting media by the "portal", you may see the way " = uCDN delivers multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media types". > =20 > Now what you're talking about is an optimisation, not a core function = required to actually deliver the content (and report, bill, etc. for = that delivery). > =20 > My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO. > =20 > Ben > =20 > A good question is "security" since I have done six years on the DRM > and like to promote the DRM all around the world:) If the content is = needed to be protected, generally you may know all the systems should be = granted by the content owner. > Here I also like to clarify that not only the media itself but the = information related to service itself (such as the geographic = constraint) should be protected also. > So, trust is not a problem for the media. > =20 > Philip, > Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use case. > I like to clarify to U that it is important for you operator since it = may save investment if the system may support different services. > For us vendor, we are happy operator may install a system for the = mobile service and another system for the FBB service. > But the reality is all operators ask us to provide a system that may = support different service systems. > =20 > Frankly, Ben and Philip, I remember I have explained somewhere that to = implement this is rather simple . > At least the Use case and Requirement are informational to be referred = in future work. So I do really feel you may accept it. > Of course I like to respond your more concern and comments. > Thanks. > Zhipeng > =20 > =20 > =20 > -----Original Message----- > From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] > Sent: Monday, October 10, 2011 11:22 PM > To: ben@niven-jenkins.co.uk; ZhouZhipeng > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Ben, Zhipeng, all, > =20 > I think that Content Adaptation is more an issue for the Requirements = doc than for the Use cases draft. > =20 > The key question is whether we want the CDNI interfaces to be able to = cope with a scenario where (say) HD/SD conversion is done in the dCDN & = to signal about this. > =20 > I think that coping with this scenario is a second order requirement, = ie we should not worry about it in the initial standards-track work. I = don't know, did we ever decide whether the Use cases doc is restricted = to "initial" scenarios, or whether it's all-encompassing, ie covering = "future" scenarios as well? > =20 > Scott, > Reading some of your examples, they seem to be valid even if content = adaptation (HD/SD) is out of scope. > - a dCDN might for some reason be unwilling to distribute HD? > - a CSP might want to make sure the dCDN can use HLS encapsulation? > But these sorts of examples seem to be static policy things (to do > with the capabilities & preferences of the CDNs & CSP), rather than > metadata associated with a particular piece of content. In the > discussion so far, I think negotiation about static policy stuff is > rather out of scope(?) > =20 > On security considerations, an interesting question is whether trust = is transitive. Don't think it need be - just because CSP trusts uCDN, = and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the = dCDN. However, i suspect this can get arbitrarily complex - so one = possibility is to say that we will only handle cases where the trust is = transitive. > =20 > Best wishes > phil > =20 > =20 > Philip Eardley > Research and Technology Strategy > =20 > This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named = above. If you're not the intended recipient, note that disclosing, = copying, distributing or using this information is prohibited. If you've = received this email in error, please let me know immediately on the = email address above. Thank you. We monitor our email system, and may = record your emails. > British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ Registered in > England no: 1800000 > =20 > =20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: 10 October 2011 12:04 > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Colleagues, > =20 > IMO Section 5.1.3 should be removed from the Use Cases draft. Content = Adaptation (i.e. taking in a content item in one format and transforming = it to another format or representation) is not a "core" function of a = CDN which typically delivers the content that is requested without = explicit knowledge of what that content actually is. > =20 > Let's not forget that in building an end to end content service the = CDN is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the = selected content not the component tasked with deciding (or applying = policy) on which version/copy/representation of content should be = delivered. > =20 > The decision as to which version/copy/representation to offer and = allow to be delivered to a given device/user is implemented outside of = the CDN (e.g. by the "portal" where the user first makes their content = selection prior to the CDN becoming involved in the delivery of the = selected content). > =20 > Ben > =20 > On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: > =20 > Following Scott's comments on section 5.1.3, I feel Scott's = description on the use case of HD and SD is not exactly correct. > If one movie has two formats of HD and SD, then we have two content = with different identifier. In DRM scope, the basic unit is a content = copy. > =20 > Here the first bullet "a subset of encodings deliverable to specific = devices," has listed the case of content adaptation. > In last month, I have contacted the Authors of this document and taken = some email exchanges with Grant and Philip (BT). > I have shown BT with some information that I know in this case and = area to explain the content flexibility is currently a basic requirement = for CDN service and related negotiation is needed in the CDN = interconnection. > Meanwhile, I should also invite you in this group raising your = comments or questions on this case since I hope my use case may be = incorporated in the use case draft. > =20 > If you have any more question or comments, pls share in this thread. > Thanks. > Zhipeng > =20 > =20 > =20 > =20 > =20 > =20 > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com] > Sent: Friday, September 30, 2011 8:02 AM > To: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Section 2.3 Nomadic Users > This description falls under the category of Geographic Extension > yet the third paragraph states the case where a different device is > used in the same CDN coverage area. The intent of this use case > needs to be clarified. Perhaps the use case is trying to address > the scenario where a Nomadic User-A with an agreement allowing > access to content from CSP-A via uCDN moves to a dCDN in a different > region. The dCDN is allowed to distribute the content of CSP-A to > User-A; however, not other users in the region of the dCDN are > allowed to retrieve the content unless they too have such an = agreement. > =20 > Section 5.1.3 Content Encoding Restrictions Need to clarify if we're > talking about the restrictions on the delivery of specific content > or the restrictions on the ability of a CDN to deliver specific > content. I certainly understand the case where a CSP will restrict > the distribution of content to a "managed path" if such content is > HD while allowing the content distribution via an un-managed path if > such content is SD (same could apply to encryption methods, delivery > methods, etc.). On the contrary, the dCDN may have its own > restrictions of blocking the distribution of HD content while > allowing the distribution of SD content. > =20 > o first bullet makes sense if the dCDN can perform a subset of > encapsulations for a reference set of media (e.g. HLS, HSS, but not > DASH) o second bullet makes sense where the dCDN doesn't want to > offer high bit-rate variants of the media o third bullet make sense > if the policy addresses QoE but I don't think subscriber > rights/authorizations apply. > =20 > Section 10 Security Considerations > =20 > Aside from the security considerations WITHIN the uCDN and dCDN, I > think we can describe this in four contexts: > =20 > a. The relationship between the CSP and the uCDN (the principle = contract > arrangement for distribution) > b. The relationship between the uCDN and dCDN (the transitive trust > relationship that extends the contract defined in (a) above) c. The > relationship between the User and dCDN (the recognition of right to > download predicated on (b) above) d. The relationship between the > User and CSP (the contract authorizing the user access to the > content) > =20 > The user is not interested in the a-b nor the b-c relationship. The > user is only interested in the transparency and interoperability of > the security relationship between d-b or d-c to the point that the > authorization granted in d-a is viable when the delivery is > initiated via either d-b or d-c. As an example, the uCDN might use > URL appended tokens for authentication while dCDN might use URL > appended hashes. The user doesn't want to know about the distinct > methods, but transparency is only afforded if the methods are > interoperable clearly defined when the delegation for content > delivery is executed. Clearly, the choice of authentication method is = determined by the respective CDN's. > =20 > Scott > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-415-52674518 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi again Zhipeng,

There is one = other point I should have brought up in my previous = message:
The question is not so much whether there are = benefits to allowing content adaptation for some environments, nor = whether one particular individual could conceive an approach for content = adaptation that suits him. The question here is rather whether it is = justified for the Working Group to focus energy on that problem right = now in order to develop a consensus-based approach that suits the = community as a whole, while we don't even have the base solution in = place.

You have made it clear that you feel the = WG should indeed dedicate energy on that problem right away and = explained your rationale. Thank you. Others have also expressed their = opinions.

Cheers

Francoi= s


On 28 Oct 2011, at 11:25, = ZhouZhipeng wrote:

Dear = all,
In these = days I am busy making a summary analysis on this topic. As Richard=E2=80=99= s request, I like to show my information although perhaps not complete = right now.
 
1) I have done some work to collect different company=E2=80=99= s requirements and opinions on this = functionality.
One, I feel most of us = have already been aware of the service of content adaptation, and I also = sent an email yesterday that Vodaphone now is requiring the solution to = enhance the performance of its mobile video = service.
There are two solutions:
 
 
>In your = company=E2=80=99s website, I just find some information

I have to = step in as co-chair here.

The goal of this WG is not to align = vendor product roadmaps, or to equalize all vendor offerings, or to = specify the entire CDNI ecosystem. The goal of this WG is to enable the = interconnection and interoperation of two or more CDNs, within the = bounds of the CDNI wg charter.

It is OK to have a discussion = about whether content adaptation needs to be performed by the dCDN, = since that decision impacts the uCDN-dCDN interface. So let's find a = productive way to discuss this on the mailing list, and to close the = discussion by IETF 82 (if not sooner).

Can someone describe = real-life examples where downstream CDN (or edge cache-based) content = adaptation is needed today in a production environment, or shortly? Not = merely a feature in a vendor's product materials?

Speaking as an = individual, I can find a lot of examples where downstream content = adaptation is not needed, and any adaptation is really part of the CP - = uCDN interface (which is out of the scope of our charter).

-- = Rich

 
From: = ZhouZhipeng [mailto:zhouzhipeng@huawei.com] 
Sent: Thursday, = October 27, 2011 03:45 AM
To: Mark de Jong <mark@jet-stream.nl>; Alan Kavanagh = <alan.kavanagh@ericsson.com> 
Cc: cdni@ietf.org <cdni@ietf.org> 
Subject: Re: = [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt 
 
Hello Mark,
Nice to = meet you on line.
In your company=E2=80=99s website, I just find some = information that addresses =E2=80=9C Vodafone subscribers complained about video = performance.=E2=80=9DSee:
 
Hi = Alan,
 
As Ben stated the overall = discussion right now is about delivery, not on adaptation. It is hard = enough to get consensus on the delivery aspect already not to mention = your requirement from content adaptation added to that, so I agree with = Ben we should stick with the delivery aspect for the first specs. I = can imagine this could be a discussion later on but please let us keep = the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. = Thanks.
 
Met vriendelijke groet,
Kind = regards,

Mark de Jong
International Business = Developer
Jet-Stream = BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214
- = Event: Meet us at = Streaming Media Europe, 17-18 October, London, UK
- Event: Meet us at Online Video Strategies, 19 = October, London, UK- = Event: Meet us at CDN World Summit, 25-28 = October, London, UK  Pre-request your Technology Whitepaper = now and be the first to have it, check www.jet-stream.com
- News: Check http://www.jet-stream.com to download our 'Six Trends = in CDNs' brochure 
-  
On 26, Oct,2011, at 8:33 PM, Alan = Kavanagh wrote:

 

Ben

Im assuming = then based on your comments below are you suggesting we are going to = have a number of versions of the CDN-I Metadata?

I sympathise = with what you are pointing out below and do agree that there is some = work to be done, but I still feel that content adaptation is to me a = fundamental requirement to what collectively we should address in the = CDN-I WG. I do agree with you that content adaptation is an optimization = between CDN's but it's a very important one that I know Network Service = Providers particularly require.

Alan

-----Original = Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To: = ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 12 Oct 2011, = at 10:22, ZhouZhipeng wrote:

Hello = Ben,
The UE may select the = content format on the CP web. After that the user only desires to get = his selected content.
But how the content is transferred to the client is not = worried by the user.
The CP may create a special format as required by the = user and ask the CDN to deliver to = user.
While CP = may give a HD format content to uCDN and the dCDN may then transform to = the format as the user select.


Lots of things may = be possible to do and CDN providers offer many additional services on = top of the "core" service of content delivery. However, our objective = (based on my interpretation of the CDNI charter) is to focus on what is = necessary to interconnect CDNs to deliver content from a CSP to an End = User that is targeted and deployable within a short time frame (18-24 = months).

Content transformation/adaptation is not an essential = requirement in order to achieve that aim (we can deliver content from = CSPs to End Users via multiple CDNs without needing or requiring any CDN = supports content adaptation).

In my opinion we have enough work = to do already without trying to expand the scope of our work to include = additional requirements that do not help us address our core objectives = as laid out in the CDNI charter.

In this case, it is nothing = related to how the user select formats on CP = website.
So, it is the CP and = user to decide the content format not the CDN(your assert is not correct = and seems you take that assert as your base for the = discussion).
 
As for "the core CDN functionality offered by CDNs = today", I have ever raised an email before that your company's webpage = has claimed supporting media transformation and multi-screen = service.
Perhaps, I like asking you list some features that you = feel are the core functionalities by existing main stream CDNs. Thus we = may compare and take deep look.


I think the core = functionality maps pretty well to the CDNI interfaces, namely: Request = Routing, Metadata configuration, log production and control plus content = acquisition and content delivery.

I guess many people have the = experience/knowledge of content related service. The user and CP only = care whether the CDN providers may satisfy their requirement while not = care the internal process. Just as GSM/PSTN interconnection, the user = only care successful interconnection while not care how the voice is = transformed in process.
 
Besides, I like raise a = case:
Given = currently BBC recruits CDN providers that may support 10 media = formats.
One candidate is your company, another is CDN-X. The = users are located in = France.
So both your company and CDN-X should connect a France = CDN provider(CDN-Y).
If your company's solution is to send 10 streams of = different format
of one content to CDN-Y; While CDN-X's solution is to = send 1 stream to CDN-Y while CDN-Y may conduct some = adaptation.
Comparing these two solutions, for your company and = CDN-X, absolutely the cost of CDN-X is much = lower.
For CDN-Y, in solution-1, it should receive/forward 10 = streams ; while in solution-2, it should only receive 1 stream but need = to take transformation to output 10 = streams.
 
Which solution is more competitive. it is Solution 1, = right. Remember the price from BBC is same to both your company and = CDN-X or BBC would select one CDN provider with the lower = price.
If a CDN provider may not get the contract from CP, how = it may say it is not a core = functionality.


What you are describing is a possible = optimization that a particular CDN may wish to implement not a core = functionality required to enable content delivery between interconnected = CDNs. I can think of many optimizations that a CDN could implement to = differentiate their service but the internal workings of an individual = CDN are out of scope of our charter.

So to repeat my position for = a final time: Content adaptation is not a core function required to = enable content delivery between interconnected CDNs and therefore given = the workload we already have to specify solutions that do address the = core functionality required to interconnect CDNs I do not think we = should be trying to add more work into that workload as it will only = distract us from achieving our goal of producing deployable solutions = within the timeframe we are being told by operators they needs solutions = within.

Ben

So, if we all realize that currently the media type is = rich, the CDN providers should survive in the existing ecosystem and = support the media types as required by the = market.
 
Back to the case of GSM/G.711, it just when concerning = the interconnection, the transformation should at once be solved. = Otherwise the interconnection may not be = operated.
 
Br,
Zhipeng
 
 
 
 
-----Original = Message-----
From: Ben Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]
Sent: Wednesday, October 12, 2011 = 12:19 AM
To: = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Zhipeng,
 
On 11 Oct 2011, at 05:16, ZhouZhipeng = wrote:
 
Ben and = Philip,
I like to respond your concern in this one = email:
 
Ben,
I feel what we are now discussing is what is the "core" = function of = CDN.
As you say, CDN is used to deliver content. That is = absolutely correct that the delivery capability is the core requirement = for CDN = system.
While CDN is used to provide the content delivery = service.
What means service. It should include "time" "location" = and "media type", etc. These features are all the core feature for a = service.
If we only concern "delivering one data block", I am not = sure whether the issues such as "logging" "geographic constraint" are = the core of = CDN.
 
For "without explicit knowledge of what that content = actually is ", I am not sure whether the wording is accurate since = generally a CDN may claim it support different = medias.
By this opportunity, I like to share a use case: a call = from a GSM phone to a PSTN telephone, the voice stream should be = transformed from GSM voice to = G.711.
For the user, he does not need to know what type of data = has been transferred, but the operator has done some work to = interconnect two systems, = right.
I like to know whether you may accept that my use case is = similar to this case = above.
 
I don't think your use case is similar to the analogy of = mobile networks being interconnected to PSTN networks. In the case of = content delivery the negotiation is done between the User/Client and the = Content Provider and the CDN is just used to execute/perform the = delivery that has been negotiated. The CDN is not involved in the = decision making of what representations the Content Provider decides to = offer to the User/Client or in what representations the User/Client = decides to request.
 
As for you said selecting media by the "portal", you may = see the way " uCDN delivers multiple media streams to dCDN" is not good = than "uCDN delivers one media stream to dCDN and dCDN takes some = adaptation to support multiple media = types".
 
Now what you're talking about is an optimisation, not a = core function required to actually deliver the content (and report, = bill, etc. for that = delivery).
 
My position is that we should focus on how to enable the = interconnection of the core CDN functionality offered by CDNs today = (which is also my interpretation of the scope of the CDNI working group = as expressed in its charter) because doing so is a significant piece of = work in itself. Let's not start trying to add in additional = functionality beyond what the majority of CDNs support today as that = will just delay us getting usable specifications into the market in a = timely fashion IMO.
 
Ben
 
A good question is "security" since I have done six years = on the DRM
and like to promote the DRM all around the world:) If the = content is needed to be protected, generally you may know all the = systems should be granted by the content = owner.
Here I also like to clarify that not only the media = itself but the information related to service itself (such as the = geographic constraint) should be protected = also.
So, trust is not a problem for the = media.
 
Philip,
Thank you that you feel Content Adaption is an issue for = "Requirements" but I do not know why it is not for Use = case.
I like to clarify to U that it is important for you = operator since it may save investment if the system may support = different = services.
For us vendor, we are happy operator may install a system = for the mobile service and another system for the FBB = service.
But the reality is all operators ask us to provide a = system that may support different service = systems.
 
Frankly, Ben and Philip, I remember I have explained = somewhere that to implement this is rather simple = .
At least the Use case and Requirement are informational = to be referred in future work. So I do really feel you may accept = it.
Of course I like to respond your more concern and = comments.
Thanks.
Zhipeng
 
 
 
-----Original = Message-----
From: philip.eardley@bt.com [mailto:philip.eardley@bt.com= ]
Sent: Monday, October 10, 2011 11:22 = PM
To: ben@niven-jenkins.co.uk; = ZhouZhipeng
Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Ben, Zhipeng, = all,
 
I think that Content Adaptation is more an issue for the = Requirements doc than for the Use cases = draft.
 
The key question is whether we want the CDNI interfaces = to be able to cope with a scenario where (say) HD/SD conversion is done = in the dCDN & to signal about = this.
 
I think that coping with this scenario is a second order = requirement, ie we should not worry about it in the initial = standards-track work. I don't know, did we ever decide whether the Use = cases doc is restricted to "initial" scenarios, or whether it's = all-encompassing, ie covering "future" scenarios as = well?
 
Scott,
Reading some of your examples, they seem to be valid even = if content adaptation (HD/SD) is out of = scope.
- a dCDN might for some reason be unwilling to distribute = HD?
- a CSP might want to make sure the dCDN can use HLS = encapsulation?
But these sorts of examples seem to be static policy = things (to = do
with the capabilities & preferences of the CDNs & = CSP), rather = than
metadata associated with a particular piece of content. = In the
discussion so far, I think negotiation about static = policy stuff = is
rather out of = scope(?)
 
On security considerations, an interesting question is = whether trust is transitive. Don't think it need be - just because CSP = trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP = automatically trusts the dCDN. However, i suspect this can get = arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.
 
Best = wishes
phil
 
 
Philip = Eardley
Research and Technology = Strategy
 
This email contains BT information, which may be = privileged or confidential. It's meant only for the individual(s) or = entity named above. If you're not the intended recipient, note that = disclosing, copying, distributing or using this information is = prohibited. If you've received this email in error, please let me know = immediately on the email address above. Thank you. We monitor our email = system, and may record your = emails.
British Telecommunications = plc
Registered office: 81 Newgate Street London EC1A 7AJ = Registered = in
England no: = 1800000
 
 
-----Original = Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf
Of Ben = Niven-Jenkins
Sent: 10 October 2011 = 12:04
To: = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Colleagues,
 
IMO Section 5.1.3 should be removed from the Use Cases = draft. Content Adaptation (i.e. taking in a content item in one format = and transforming it to another format or representation) is not a "core" = function of a CDN which typically delivers the content that is requested = without explicit knowledge of what that content actually = is.
 
Let's not forget that in building an end to end content = service the CDN is only one component and is the component tasked with = executing the delivery of a specific representation (version/copy/format = etc.) of the selected content not the component tasked with deciding (or = applying policy) on which version/copy/representation of content should = be = delivered.
 
The decision as to which version/copy/representation to = offer and allow to be delivered to a given device/user is implemented = outside of the CDN (e.g. by the "portal" where the user first makes = their content selection prior to the CDN becoming involved in the = delivery of the selected = content).
 
Ben
 
On 8 Oct 2011, at 08:20, ZhouZhipeng = wrote:
 
Following Scott's comments on section 5.1.3, I feel = Scott's description on the use case of HD and SD is not exactly = correct.
If one movie has two formats of HD and SD, then we have = two content with different identifier. In DRM scope, the basic unit is a = content = copy.
 
Here the first bullet "a subset of = encodings deliverable to specific devices," has listed the case of = content = adaptation.
=
In last month, I have contacted the Authors of this = document and taken some email exchanges with Grant and Philip = (BT).
I have shown BT with some information that I know in this = case and area to explain the content flexibility is currently a basic = requirement for CDN service and related negotiation is needed in the CDN = interconnection.
Meanwhile, I should also invite = you in this group raising your comments or questions on this case since = I hope my use case may be incorporated in the use case = draft.
 
If you have any more question or = comments, pls share in this = thread.
Thanks.
Zhipeng
 
 
 
 
 
 
-----Original = Message-----
From: Scott Wainner = [mailto:swainner@cisco.com]
Sent: Friday, September 30, 2011 = 8:02 = AM
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt
 
Section 2.3 Nomadic = Users
This description falls under the category of Geographic = Extension
yet the third paragraph states the case where a different = device = is
used in the same CDN coverage area.  The intent of = this use = case
needs to be clarified.  Perhaps the use case is = trying to = address
the scenario where a Nomadic User-A with an agreement = allowing
access to content from CSP-A via uCDN moves to a dCDN in = a = different
region.  The dCDN is allowed to distribute the = content of CSP-A = to
User-A; however, not other users in the region of the = dCDN = are
allowed to retrieve the content unless they too have such = an = agreement.
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
 
Section 5.1.3 Content Encoding = Restrictions Need to clarify if = we're
talking about the restrictions on the delivery of = specific = content
or the restrictions on the ability of a CDN to deliver = specific
content.  I certainly understand the case where a = CSP will = restrict
the distribution of content to a "managed path" if such = content = is
HD while allowing the content distribution via an = un-managed path = if
such content is SD (same could apply to encryption = methods, = delivery
methods, etc.).  On the contrary, the dCDN may have = its = own
restrictions of blocking the distribution of HD content = while
allowing the distribution of SD = content.
 
o first bullet makes sense if the = dCDN can perform a subset = of
encapsulations for a reference set of media (e.g. HLS, = HSS, but = not
DASH) o second bullet makes sense where the dCDN doesn't = want = to
offer high bit-rate variants of the media o third bullet = make = sense
if the policy addresses QoE but I don't think = subscriber
<= blockquote style=3D"margin-top: 5pt; margin-bottom: 5pt; ">
rights/authorizations = apply.
 
Section 10 Security = Considerations
 
Aside from the security = considerations WITHIN the uCDN and dCDN, = I
think we can describe this in four = contexts:
 
a. The relationship between the = CSP and the uCDN (the principle = contract
arrangement for = distribution)
b. The relationship between the = uCDN and dCDN (the transitive = trust
relationship that extends the contract defined in (a) = above) c. = The
relationship between the User and dCDN (the recognition = of right = to
download predicated on (b) above) d. The relationship = between = the
User and CSP (the contract authorizing the user access to = the
content)
<= /blockquote>
 
The user is not interested in the = a-b nor the b-c relationship. = The
user is only interested in the transparency and = interoperability = of
the security relationship between d-b or d-c to the point = that = the
authorization granted in d-a is viable when the delivery = is
initiated via either d-b or d-c.  As an example, the = uCDN might = use
URL appended tokens for authentication while dCDN might = use = URL
appended hashes.  The user doesn't want to know = about the = distinct
methods, but transparency is only afforded if the methods = are
interoperable clearly defined when the delegation for = content
delivery is executed.  Clearly, the choice of = authentication method is determined by the respective = CDN's.
 
Scott
 
_______________________________________________<= /span>
CDNi mailing = list
_______________________________________________<= /span>
_________________= ______________________________
CDNi mailing list
CDNi@ietf.org
List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 14:39:01 -0000 --f46d044469f36e161304b05cd9cc Content-Type: text/plain; charset=ISO-8859-1 Hi Francois, Another factor is the DSP resources required to do content translation downstream in multiple dCDN's, versus upstream only at one place the uCDN, assuming a fan-out. Thanks, Vishwas On Fri, Oct 28, 2011 at 2:49 AM, Francois Le Faucheur wrote: > Folks, > > Speaking as a co-chair. > > I have been through the recent exchange on content adaptation (aka the > poorly-titled "Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt" > thread) and wanted to share a few thoughts. > > First, some messages might have given the impression that content > adaptation was required for a CDNI solution to be able to deal with multiple > types of terminal/resolution/sizes etc. So at the risk of restating the > obvious, let's be very explicit that this is obviously not the case. A very > simple/common way to support multiple types of terminal/resolution/sizes in > one CDN, or in a multi-CDN environment, is to have different contents/URIs > for each profile. > So content adaptation is not _required_ to be supported by CDNI, but is a > candidate optimisation to do some of the same things in a different way. > > Second, some messages suggested that content adaptation was a very strong > win (aka transfer 1 flow instead of 10 flows across CDNs). As Richard > pointed out already, this ignores a number of considerations such as the > cost associated with performing the actual content adaptation downstream. > Anyways, I think content adaptation may be better seen as a trade-off that > can indeed be positive in some environments, rather than an obvious huge > win. > Also, without the content adaptation optimization, while the content maybe > passed across CDNs multiple times (in different formats), it is worth noting > that the smaller res/size/quality representations may actually amount to > much smaller size/bandwidth than the highest res/size/quality, so it is not > quite a multiplying factor. > Lastly, while the content adaptation optimization may reduce further the > inter-CDN transfer from 1-10 flows down to 1 flow, the base CDNI solution > allows a content to be transferred across CDNS 1-10 times total instead of > once per user accessing the content (as would be the case if the uCDN pumps > the same traffic to every users because it cannot interoperate with the > dCDN) which can result in a gain factor of 10s, 100s, 1000s,..... > > I have the impression that the key arguments have now been exposed (some of > them even repeatedly) through the long thread. So I would suggest to pause > that discussion, unless _new_ arguments need to be brought into the > discussion, and then we can poll for consensus in Taipei and then on the > list. > > Thanks > > Francois > > PS: Please think of using specific Subject lines for the various threads > and don't hesitate to branch off with a different "Subject" when an initial > thread morphs into a different topic. This helps the discussion. > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > --f46d044469f36e161304b05cd9cc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Francois,
=A0
Another factor is the DSP resources required to do content translation= downstream in multiple dCDN's, versus upstream only at one place the u= CDN, assuming a fan-out.
=A0
Thanks,
Vishwas
On Fri, Oct 28, 2011 at 2:49 AM, Francois Le Fau= cheur <flefauch@= cisco.com> wrote:
Folks,

Speaking as a co-chair.<= br>
I have been through the recent exchange on content adaptation (aka t= he poorly-titled "Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.= txt" thread) and wanted to share a few thoughts.

First, some messages might have given the impression that content adapt= ation was required for a CDNI solution to be able to deal with multiple typ= es of terminal/resolution/sizes etc. So at the risk of restating the obviou= s, let's be very explicit that this is obviously not the case. A very s= imple/common way to support multiple types of terminal/resolution/sizes in = one CDN, or in a multi-CDN environment, is to have different contents/URIs = for each profile.
So content adaptation is not _required_ to be supported by CDNI, but is a c= andidate optimisation to do some of the same things in a different way.
=
Second, some messages suggested that content adaptation was a very stro= ng win (aka transfer 1 flow instead of 10 flows across CDNs). As Richard po= inted out already, this ignores a number of considerations such as the cost= associated with performing the actual content adaptation downstream. Anywa= ys, I think content adaptation may be better seen as a trade-off that can i= ndeed be positive in some environments, rather than an obvious huge win.=20
Also, without the content adaptation optimization, while the content m= aybe passed across CDNs multiple times (in different formats), it is worth = noting that the smaller res/size/quality representations may actually amoun= t to much smaller size/bandwidth than the highest res/size/quality, so it i= s not quite a multiplying factor.=A0
Lastly, while the content adaptation optimization may reduce further the in= ter-CDN transfer from 1-10 flows down to =A01 flow, the base CDNI solution = allows a content to be transferred across CDNS 1-10 times total instead of = once per user accessing the content (as would be the case if the uCDN pumps= the same traffic to every users because it cannot interoperate with the dC= DN)=A0which can result in a gain factor of 10s, 100s, 1000s,.....

I have the impression that the key arguments have now been exposed= (some of them even repeatedly) through the long thread. So I would suggest= to pause that discussion, unless _new_ arguments need to be brought into t= he discussion, and then we can poll for consensus in Taipei and then on the= list.

Thanks

Francois

PS: Please= think of using specific Subject lines for the various threads and don'= t hesitate to branch off with a different "Subject" when an initi= al thread morphs into a different topic. This helps the discussion.

=

_______________________________________________
CD= Ni mailing list
CDNi@ietf.org
http= s://www.ietf.org/mailman/listinfo/cdni


--f46d044469f36e161304b05cd9cc-- From richard_woundy@cable.comcast.com Fri Oct 28 09:50:01 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED21121F86D0 for ; Fri, 28 Oct 2011 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.542 X-Spam-Level: X-Spam-Status: No, score=-105.542 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvJzgKMYdkj7 for ; Fri, 28 Oct 2011 09:49:59 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id AAA1B21F861E for ; Fri, 28 Oct 2011 09:49:58 -0700 (PDT) Received: from ([24.40.55.42]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.144538979; Fri, 28 Oct 2011 12:49:54 -0400 Received: from PACDCEXMB05.cable.comcast.com ([fe80::a5b0:e5c4:df1b:2367]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0339.001; Fri, 28 Oct 2011 12:49:56 -0400 From: "Woundy, Richard" To: Francois Le Faucheur , Ben Niven-Jenkins Thread-Topic: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call Thread-Index: AQHMlVPXUQFpXawaFU6bJJUZa6nEgpWR9/ig Date: Fri, 28 Oct 2011 16:49:53 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136D12B4@PACDCEXMB05.cable.comcast.com> References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.191.223.245] Content-Type: multipart/related; boundary="_005_1CA25301D2219F40B3AA37201F0EACD1136D12B4PACDCEXMB05cabl_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 16:50:01 -0000 --_005_1CA25301D2219F40B3AA37201F0EACD1136D12B4PACDCEXMB05cabl_ Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136D12B4PACDCEXMB05cabl_" --_000_1CA25301D2219F40B3AA37201F0EACD1136D12B4PACDCEXMB05cabl_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiAgIG8gIENhYmxlTGFicywgU05JQSBhbmQgSVRVIGhhdmUgZGVmaW5lZCAob3IgYXJlIHdvcmtp bmcgb24pIGRlZmluaXRpb25zIGZvciBjb250ZW50IHJlbGF0ZWQgbWV0YWRhdGEgZGVmaW5pdGlv bnMgYW5kIHNwZWNpZmljYXRpb24gZm9yIGl0cyBkaXN0cmlidXRpb24uDQoNCkFyZSB3ZSByZWZl cnJpbmcgdG8gdGhlc2UgQ2FibGVMYWJzIHNwZWNpZmljYXRpb25zPw0KDQpodHRwOi8vd3d3LmNh YmxlbGFicy5jb20vc3BlY2lmaWNhdGlvbnMvTUQtU1AtQ09OVEVOVHYzLjAtSTAxLTEwMDgxMi5w ZGYNCmh0dHA6Ly93d3cuY2FibGVsYWJzLmNvbS9wcm9qZWN0cy9tZXRhZGF0YS9zcGVjaWZpY2F0 aW9ucy9zcGVjaWZpY2F0aW9uczMwLmh0bWwNCg0KRG8gd2UgaGF2ZSByZWZlcmVuY2VzIGZvciB0 aGUgU05JQSBhbmQgSVRVIHNwZWNzIGFzIHdlbGw/DQoNCi0tIFJpY2gNCg0KRnJvbTogY2RuaS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgRnJhbmNvaXMgTGUgRmF1Y2hldXINClNlbnQ6IEZyaWRheSwgT2N0b2JlciAyOCwgMjAxMSA1 OjI4IEFNDQpUbzogQmVuIE5pdmVuLUplbmtpbnMNCkNjOiBjZG5pQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW0NETmldIFByZXBhcmluZyBkcmFmdC1pZXRmLWNkbmktcHJvYmxlbS1zdGF0ZW1lbnQg Zm9yIFdHIExhc3QgQ2FsbA0KDQpISSBCZW4sDQoNCkNvbW1lbnRzIGJlbG93Og0KDQpPbiAxNyBP Y3QgMjAxMSwgYXQgMTM6MDcsIEJlbiBOaXZlbi1KZW5raW5zIHdyb3RlOg0KDQoNCkNvbGxlYWd1 ZXMsDQoNCkF0IHRoZSBsYXN0IElFVEYgSSBzYWlkIEkgd291bGQgdHJ5IHRvIHByZXBhcmUgYSB2 ZXJzaW9uIG9mIHRoZSBDRE5JIHByb2JsZW0gU3RhdGVtZW50IChkcmFmdC1pZXRmLWNkbmktcHJv YmxlbS1zdGF0ZW1lbnQpIHRoYXQgaXMgcmVhZHkgZm9yIFdHIExhc3QgQ2FsbCBiZWZvcmUgSUVU RjgyIGluIFRhaXBlaS4NCg0KQXMgcGFydCBvZiB0aGF0IEkgaGF2ZSByZXZpZXdlZCB0aGUgY29t cGxldGUgZHJhZnQgYW5kIG1hZGUgc29tZSBtaW5vciBlZGl0b3JpYWwgY2xlYW4tdXBzIHRvIG15 IHdvcmtpbmcgY29weS4gSG93ZXZlciwgdGhlcmUgd2VyZSBhIG51bWJlciBvZiBvdGhlciBhcmVh cyB3aGVyZSBJIHRoaW5rIGNoYW5nZXMgbmVlZCB0byBiZSBtYWRlIHRvIHRoZSBkb2N1bWVudCB0 aGF0IEkgdGhpbmsgd2FycmFudCB3aWRlciBXRyByZXZpZXcvY29uc2Vuc3VzIGFuZCBJIGhhdmUg bGlzdGVkIHRoZW0gYmVsb3cgYWxvbmcgd2l0aCB0aGUgY2hhbmdlcyBJIGFtIHByb3Bvc2luZy4N Cg0KQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIHlvdXIgZmVlZGJhY2sgb24gdGhlIGFyZWFzL3By b3Bvc2VkIHRleHQgSSBoYXZlIGhpZ2hsaWdodGVkIGJlbG93IGFzIHdlbGwgYXMgYW55IG90aGVy IGFyZWFzIG9mIHRoZSBkb2N1bWVudCB0aGF0IHlvdSB0aGluayByZXF1aXJlIGFkZGl0aW9uYWwg d29yay9jbGVhbnVwIGJlZm9yZSB5b3UgY29uc2lkZXIgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZv ciBhIFdHIExhc3QgQ2FsbC4NCg0KMSkgU2VjdGlvbiAyOiBVcGRhdGUgdGhlIGxhc3QgcGFyYWdy YXBoIHRvIHJlZmVyZW5jZSB0aGUgV0cgZHJhZnQgZm9yIENETkkgdXNlIGNhc2VzIGFuZCByZW1v dmUgcmVmZXJlbmNlIHRvIGRyYWZ0LXdhdHNvbi1jZG5pLXVzZS1jYXNlcywgaS5lLg0KDQpPTEQ6 DQogIFVzZSBjYXNlcyBmb3IgQ0ROIEludGVyY29ubmVjdGlvbiBhcmUgZnVydGhlciBkaXNjdXNz ZWQgaW4NCiAgW0ktRC5iZXJ0cmFuZC1jZG5pLXVzZS1jYXNlc10gKHdoaWNoIGNvbnRhaW5zIGEg bWVyZ2VkIHNldCBvZiB1c2UNCiAgY2FzZXMgcHJldmlvdXNseSBwcmVzZW50ZWQgaW4gW0ktRC53 YXRzb24tY2RuaS11c2UtY2FzZXNdIGFuZA0KICBbSS1ELmJlcnRyYW5kLWNkbmktdXNlLWNhc2Vz LTAwXSkuDQpORVc6DQogIFVzZSBjYXNlcyBmb3IgQ0ROIEludGVyY29ubmVjdGlvbiBhcmUgZnVy dGhlciBkaXNjdXNzZWQgaW4NCiAgW0ktRC5pZXRmLWNkbmktdXNlLWNhc2VzXS4NCg0KQWdyZWVk Lg0KDQoNCg0KDQoyKSBTZWN0aW9uIDQgY29udGFpbnMgYW4gaW50cm9kdWN0aW9uIGFuZCAyIHN1 Yi1zZWN0aW9ucyAoNC4xICYgNC4yKSB0aGF0IGFyZSBlYWNoIGp1c3QgYSBjb3VwbGUgb2Ygc2Vu dGVuY2VzLCBzbyBJIHByb3Bvc2UgbWVyZ2luZyB0aGVtIGludG8gYSBzaW5nbGUgc2VjdGlvbiBh bmQgY2hhbmdpbmcgdGhlIGZpcnN0IHR3byBzZW50ZW5jZXMgb2Ygc2VjdGlvbiA0IGFwcHJvcHJp YXRlbHksIGkuZS4NCg0KT0xEOg0KICBUaGlzIHNlY3Rpb24gZXhwYW5kcyBvbiBob3cgQ0ROSSBp bnRlcmZhY2VzIGNhbiByZXVzZSBhbmQgbGV2ZXJhZ2UNCiAgZXhpc3RpbmcgcHJvdG9jb2xzLiAg Rmlyc3QgdGhlICJyZXVzZSBpbnN0ZWFkIG9mIHJlaW52ZW50IiBkZXNpZ24NCiAgcHJpbmNpcGxl IGlzIHJlc3RhdGVkLCB0aGVuIGVhY2ggaW5ldHJmYWNlIGlzIGRpc2N1c3NlZCBpbmRpdmlkdWFs bHkNCiAgd2l0aCBleGFtcGxlIGNhbmRpZGF0ZSBwcm90b2NvbHMgdGhhdCBjYW4gYmUgY29uc2lk ZXJlZCBmb3IgcmV1c2Ugb3INCiAgbGV2ZXJhZ2UuDQpORVc6DQogIFRoaXMgc2VjdGlvbiBleHBh bmRzIG9uIGhvdyBDRE5JIGludGVyZmFjZXMgY2FuIHJldXNlIGFuZCBsZXZlcmFnZQ0KICBleGlz dGluZyBwcm90b2NvbHMgYmVmb3JlIGRlc2NyaWJpbmcgZWFjaCBDRE5JIGludGVyZmFjZSBpbmRp dmlkdWFsbHkNCiAgYW5kIGhpZ2hsaWdodGluZyBleGFtcGxlIGNhbmRpZGF0ZSBwcm90b2NvbHMg dGhhdCBjb3VsZCBjb25zaWRlcmVkIGZvcg0KICByZXVzZSBvciBsZXZlcmFnaW5nIHRvIGltcGxl bWVudCB0aGUgQ0ROSSBpbnRlcmZhY2VzLg0KDQpGaW5lIGJ5IG1lLg0KDQoNCg0KDQozKSBTZWN0 aW9uIDUgaXMgY3VycmVudGx5IHRpdGxlICJHYXAgQW5hbHlzaXMgb2YgcmVsZXZhbnQgU3RhbmRh cmRpc2F0aW9uIGFuZCBSZXNlYXJjaCBBY3Rpdml0aWVzIiBidXQgZm9sbG93aW5nIHRoZSBhZ3Jl ZW1lbnQgYXQgdGhlIGxhc3QgSUVURiB0byBtb3ZlIHRoZSBnZW5lcmljIGRlc2NyaXB0aW9ucyBv ZiBvdGhlciBhY3Rpdml0aWVzIGludG8gYW4gYXBwZW5kaXggU2VjdGlvbiA1IG5vIGxvbmdlciBy ZWZlcmVuY2VzIGFueSByZXNlYXJjaCBhY3Rpdml0aWVzIHNvIEkgcHJvcG9zZSBjaGFuZ2luZyB0 aGUgdGl0bGUgdG8iIEdhcCBBbmFseXNpcyBvZiByZWxldmFudCBTdGFuZGFyZGlzYXRpb24gYWN0 aXZpdGllcyIuDQoNCkFncmVlZC4NCg0KDQoNCjQpIEFmdGVyIHRoZSBnZW5lcmFsIGludHJvZHVj dGlvbiBpbiBTZWN0aW9uIDUgdGhlcmUgYXJlIG9ubHkgc2VjdGlvbnMgdGhhdCBvdXRsaW5lIG90 aGVyIHJlc2VhcmNoIGFjdGl2aXRpZXMNCg0KSSB0aGluayB5b3UgbWVhbiAic3RhbmRhcmRpemF0 aW9uIGFjdGl2aXRpZXMiDQoNCg0KZm9yIENvbnRlbnQgQWNxdWlzaXRpb24gKHNlY3Rpb24gNS4x KSBhbmQgQ0ROSSBNZXRhZGF0YSAoU2VjdGlvbiA1LjIpIGJ1dCB0aGVyZSBhcmUgbm90IHNlY3Rp b25zIGZvciB0aGUgb3RoZXIgQ0ROSSBpbnRlcmZhY2VzIChDb250cm9sLCBMb2dnaW5nLCBSZXF1 ZXN0IFJvdXRpbmcpLg0KDQpUaGUgcmVhc29uIGZvciB0aGUgbGFjayBvZiB0ZXh0IGlzIElNTyBi ZWNhdXNlIHRoZXJlIGlzIG5vIGN1cnJlbnQgb3IgcGFzdCBzdGFuZGFyZGlzYXRpb24gYWN0aXZp dHkgYWRkcmVzc2luZyB0aG9zZSBhcmVhcyBidXQgdGhlIGRvY3VtZW50IGN1cnJlbnRseSBkb2Vz IG5vdCBtZW50aW9uIHRoYXQgYW5kIHRoZXJlZm9yZSBnaXZlcyB0aGUgaW1wcmVzc2lvbiBvZiBi ZWluZyBpbmNvbXBsZXRlLg0KDQpJIHRoZXJlZm9yZSBwcm9wb3NlIG1ha2luZyB0aGUgZm9sbG93 aW5nIGNoYW5nZSB0byB0aGUgbGFzdCBzZW50ZW5jZSBpbiBTZWN0aW9uIDU6DQoNCk9MRDoNCiAg VGhlIGZvbGxvd2luZyBzZWN0aW9ucyB3aWxsIHN1bW1hcml6ZSB0aGUgZXhpc3Rpbmcgd29yayBv ZiB0aGUNCiAgc3RhbmRhcmQgYm9kaWVzIGFib3ZlIGFnYWluc3QgdGhlIENETkkgcHJvYmxlbSBz cGFjZS4NCk5FVzoNCiAgVGhlIGZvbGxvd2luZyBzZWN0aW9ucyB3aWxsIHN1bW1hcml6ZSB0aGUg ZXhpc3Rpbmcgd29yayBvZiB0aGUNCiAgc3RhbmRhcmQgYm9kaWVzIGFib3ZlIGFnYWluc3QgdGhl IENETkkgcHJvYmxlbSBzcGFjZS4gU2VjdGlvbiA1LjENCiAgc3VtbWFyaXNlcyBleGlzdGluZyBp bnRlcmZhY2VzIHRoYXQgY291bGQgYmUgbGV2ZXJhZ2VkIGZvciBjb250ZW50DQogIGFjcXVpc2l0 aW9uIGJldHdlZW4gQ0ROcyBhbmQgU2VjdGlvbiA1LjIgc3VtbWFyaXNlcyBleGlzdGluZyBtZXRh ZGF0YQ0KICBzcGVjaWZpY2F0aW9ucyB0aGF0IG1heSBiZSBhcHBsaWNhYmxlIHRvIENETkkuIFRv IGRhdGUgdGhlcmUgaXMgbm8NCiAgZXhpc3Rpbmcgc3RhbmRhcmRpc2F0aW9uIGFjdGl2aXRpZXMg aW4gdGhlIGFyZWFzIG9mIHRoZSByZW1haW5pbmcNCiAgQ0ROSSBpbnRlcmZhY2VzIChDRE5JIFJl cXVlc3QgUm91dGluZywgQ0ROSSBDb250cm9sIGFuZCBDRE5JIExvZ2dpbmcpLg0KDQpGaW5lLg0K DQpKdXN0IGEgY291cGxlIGVkaXRvcmlhbCBzdWdnZXN0aW9uczoNCg0Kcy9vZiB0aGUgc3RhbmRh cmQgYm9kaWVzIGFib3ZlL29mIHRoZSBzdGFuZGFyZCBib2RpZXMgbGlzdGVkIGVhcmxpZXIvDQoN CnMvdGhlcmUgaXMgbm8gZXhpc3Rpbmcgc3RhbmRhcmRpc2F0aW9uIGFjdGl2aXRpZXMvd2UgYXJl IG5vdCBhd2FyZSBvZiBhbnkgc3RhbmRhcmRpc2F0aW9uIGFjdGl2aXRpZXMvDQoNCg0KDQoNCjUp IEkgYWxzbyBwcm9wb3NlIHVzaW5nIHRoZSBmb2xsb3dpbmcgdGV4dCBmb3IgdGhlIHRoaXJkIGJ1 bGxldCBpbiBTZWN0aW9uIDUgdW5sZXNzIHNvbWVvbmUgY2FuIHN1Z2dlc3QgbW9yZSBhcHByb3By aWF0ZSB0ZXh0IHRvIHN1bW1hcmlzZSBpbiBhIHNlbnRlbmNlIG9yIHR3byBhbnkgQ0ROIG1ldGFk YXRhIHJlbGF0ZWQgd29yayBpbiBvdGhlciBzdGFuZGFyZHMgYm9kaWVzLg0KDQpPTEQ6DQogIG8g IDxUT0RPOiBBZGQgYSBzZW50ZW5jZSBvbiBJVFU+DQpORVc6DQogIG8gIENhYmxlTGFicywgU05J QSBhbmQgSVRVIGhhdmUgZGVmaW5lZCAob3IgYXJlIHdvcmtpbmcgb24pDQogICAgIGRlZmluaXRp b25zIGZvciBjb250ZW50IHJlbGF0ZWQgbWV0YWRhdGEgZGVmaW5pdGlvbnMgYW5kIHNwZWNpZmlj YXRpb24NCiAgICAgZm9yIGl0cyBkaXN0cmlidXRpb24uIEhvd2V2ZXIsIHRoZXkgZG8gbm90IGlu Y2x1ZGUgbWV0YWRhdGEgc3BlY2lmaWMNCiAgICAgdG8gdGhlIGRpc3RyaWJ1dGlvbiBvZiBjb250 ZW50IHdpdGhpbiBhIENETiBvciBiZXR3ZWVuIGludGVyY29ubmVjdGVkDQogICAgIENETnMuDQoN ClRoYXQgd29ya3MgZm9yIG1lLiBJdCB3b3VsZCBiZSBnb29kIHRvIGdldCB0aGF0IHZhbGlkYXRl ZCBieSBzb21lb25lIGF3YXJlIG9mIHRoZSB3b3JrIG9mIHRoZXNlIGJvZGllcy4NCg0KDQoNCg0K NikgU2VjdGlvbiAxMC4xIGxpc3RzIGEgbnVtYmVyIG9mICJub3JtYXRpdmUgcmVmZXJlbmNlcyIs IGlmIHdlIGFkb3B0IHRoZSBwcm9wb3NlZCBjaGFuZ2VzIGFib3ZlIGl0IHdpbGwgZW5kIHVwIGNv bnRhaW5pbmcgIm5vcm1hdGl2ZSIgcmVmZXJlbmNlcyB0bzoNCiAgLSBkcmFmdC1pZXRmLWNkbmkt dXNlLWNhc2VzDQogIC0gZHJhZnQtYmVydHJhbmQtY2RuaS1leHBlcmllbWVudHMNCiAgLSBkcmFm dC1qZW5raW5zLWNkbmktbmFtZXMNCiAgLSBSRkMyMTE5DQoNCkFmdGVyIHJlYWRpbmcgdGhyb3Vn aCB0aGUgdGV4dCBvZiB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQgYWdhaW4sIEkgYW0gbm90IGNvbnZp bmNlZCB0aGF0IHRoZSBQcm9ibGVtIFN0YXRlbWVudCByZWZlcmVuY2VzIGFueSBvZiB0aG9zZSBk b2N1bWVudHMgbm9ybWF0aXZlbHkgYXMgdGhlIDMgQ0ROSSByZWxhdGVkIGRyYWZ0cyBhcmUgcmVm ZXJlbmNlZCBpbiBhIGNvbnRleHQgd2hlcmUgdGhleSBhcmUgZm9yIGZ1cnRoZXIgaW5mb3JtYXRp b24gYW5kIHRoZSBQcm9ibGVtIFN0YXRlbWVudCBkb2VzIG5vdCBtYWtlIHVzZSBvZiBhbnkgb2Yg dGhlIGNhcGl0YWxpc2VkIHRlcm1zIGRlZmluZWQgaW4gUkZDMjExOS4NCg0KVGhlcmVmb3JlLCB1 bmxlc3MgYW55b25lIG9iamVjdHMgSSB3aWxsIG1vdmUgdGhlIHJlZmVyZW5jZXMgZm9yIHRoZSB0 aHJlZSBDRE5JIHJlbGF0ZWQgZHJhZnRzIHRvIHRoZSAiSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyIg c2VjdGlvbiBhbmQgcmVtb3ZlIHRoZSByZWZlcmVuY2UgZm9yIFJGQzIxMTkuDQoNCkkgYWdyZWUg d2UgZG9uJ3Qgd2FudCBub3JtYXRpdmUgcmVmIHRvIHRoZSBvdGhlciBjZG5pIGRyYWZ0cyBhcyB0 aGUgcHJvYmxlbSBzdGF0ZW1lbnQgaXMgc2V0dGluZyB0aGUgc3RhZ2UgZm9yIHRoZSBvdGhlciBk b2N1bWVudHMuDQoNClRoYW5rcw0KDQpGcmFuY29pcw0KDQoNCg0KDQpUaGFua3MNCkJlbg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWls aW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KW2NpZDppbWFnZTAwMS5qcGdAMDFD Qzk1NzAuMTYxNjA3ODBdDQoNCg0KDQpGcmFuY29pcyBMZSBGYXVjaGV1cg0KRGlzdGluZ3Vpc2hl ZCBFbmdpbmVlcg0KQ29ycG9yYXRlIERldmVsb3BtZW50DQpmbGVmYXVjaEBjaXNjby5jb208bWFp bHRvOmZsZWZhdWNoQGNpc2NvLmNvbT4NClBob25lOiArMzMgNDkgNzIzIDI2MTkNCk1vYmlsZTog KzMzIDYgMTkgOTggNTAgOTANCg0KDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlDQpHcmVlbnNpZGUN CjQwMCBBdmUgZGUgUm91bWFuaWxsZQ0KMDY0MTAgU29waGlhIEFudGlwb2xpcw0KRnJhbmNlDQpD aXNjby5jb208aHR0cDovL3d3dy5jaXNjby5jb20+DQoNCg0KDQoNCltjaWQ6aW1hZ2UwMDIuZ2lm QDAxQ0M5NTcwLjE2MTYwNzgwXQ0KDQogVGhpbmsgYmVmb3JlIHlvdSBwcmludC4NCg0KDQpUaGlz IGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVz ZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hp Yml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGF1dGhvcml6 ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0IHRoZSBzZW5k ZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2FnZS4N Cg0KQ2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1p dMOpZSwgUnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBT ZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40 NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNh dGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9uZS4NCg0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZv cm1hdGlvbiBnbyB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNp bmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KDQoNCg0K --_000_1CA25301D2219F40B3AA37201F0EACD1136D12B4PACDCEXMB05cabl_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT4N CjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2 aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwp O30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2Vu ZGlmXS0tPjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAx MSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6MiAyIDYgMyA1IDQgNSAyIDMgNDt9DQog LyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5h cHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bh bi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0K PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsNCi13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTstd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIj4NCjxkaXYgY2xhc3M9IlNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsNCmNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+ICZuYnNwOyZuYnNwO28gJm5ic3A7Q2FibGVM YWJzLCBTTklBIGFuZCBJVFUgaGF2ZSBkZWZpbmVkIChvciBhcmUgd29ya2luZyBvbikgZGVmaW5p dGlvbnMgZm9yIGNvbnRlbnQgcmVsYXRlZCBtZXRhZGF0YSBkZWZpbml0aW9ucyBhbmQgc3BlY2lm aWNhdGlvbiBmb3IgaXRzIGRpc3RyaWJ1dGlvbi48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDsNCmZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5BcmUgd2UgcmVmZXJyaW5nIHRvIHRoZXNl IENhYmxlTGFicyBzcGVjaWZpY2F0aW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8v d3d3LmNhYmxlbGFicy5jb20vc3BlY2lmaWNhdGlvbnMvTUQtU1AtQ09OVEVOVHYzLjAtSTAxLTEw MDgxMi5wZGYiPmh0dHA6Ly93d3cuY2FibGVsYWJzLmNvbS9zcGVjaWZpY2F0aW9ucy9NRC1TUC1D T05URU5UdjMuMC1JMDEtMTAwODEyLnBkZjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0 OTdEIj48YSBocmVmPSJodHRwOi8vd3d3LmNhYmxlbGFicy5jb20vcHJvamVjdHMvbWV0YWRhdGEv c3BlY2lmaWNhdGlvbnMvc3BlY2lmaWNhdGlvbnMzMC5odG1sIj5odHRwOi8vd3d3LmNhYmxlbGFi cy5jb20vcHJvamVjdHMvbWV0YWRhdGEvc3BlY2lmaWNhdGlvbnMvc3BlY2lmaWNhdGlvbnMzMC5o dG1sPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsNCmNvbG9yOiMxRjQ5N0QiPkRvIHdlIGhhdmUgcmVmZXJlbmNlcyBmb3IgdGhlIFNOSUEg YW5kIElUVSBzcGVjcyBhcyB3ZWxsPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0QiPi0tIFJpY2g8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IGNkbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRm Lm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+RnJhbmNvaXMgTGUgRmF1Y2hldXI8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDI4LCAyMDExIDU6MjggQU08YnI+DQo8Yj5Ubzo8L2I+ IEJlbiBOaXZlbi1KZW5raW5zPGJyPg0KPGI+Q2M6PC9iPiBjZG5pQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbQ0ROaV0gUHJlcGFyaW5nIGRyYWZ0LWlldGYtY2RuaS1wcm9ibGVt LXN0YXRlbWVudCBmb3IgV0cgTGFzdCBDYWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SEkgQmVuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Q29tbWVudHMgYmVsb3c6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMTcgT2N0IDIwMTEsIGF0IDEzOjA3LCBCZW4g Tml2ZW4tSmVua2lucyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q29sbGVhZ3Vlcyw8YnI+DQo8YnI+DQpBdCB0aGUgbGFzdCBJRVRGIEkgc2FpZCBJ IHdvdWxkIHRyeSB0byBwcmVwYXJlIGEgdmVyc2lvbiBvZiB0aGUgQ0ROSSBwcm9ibGVtIFN0YXRl bWVudCAoZHJhZnQtaWV0Zi1jZG5pLXByb2JsZW0tc3RhdGVtZW50KSB0aGF0IGlzIHJlYWR5IGZv ciBXRyBMYXN0IENhbGwgYmVmb3JlIElFVEY4MiBpbiBUYWlwZWkuPGJyPg0KPGJyPg0KQXMgcGFy dCBvZiB0aGF0IEkgaGF2ZSByZXZpZXdlZCB0aGUgY29tcGxldGUgZHJhZnQgYW5kIG1hZGUgc29t ZSBtaW5vciBlZGl0b3JpYWwgY2xlYW4tdXBzIHRvIG15IHdvcmtpbmcgY29weS4gSG93ZXZlciwg dGhlcmUgd2VyZSBhIG51bWJlciBvZiBvdGhlciBhcmVhcyB3aGVyZSBJIHRoaW5rIGNoYW5nZXMg bmVlZCB0byBiZSBtYWRlIHRvIHRoZSBkb2N1bWVudCB0aGF0IEkgdGhpbmsgd2FycmFudCB3aWRl ciBXRyByZXZpZXcvY29uc2Vuc3VzIGFuZA0KIEkgaGF2ZSBsaXN0ZWQgdGhlbSBiZWxvdyBhbG9u ZyB3aXRoIHRoZSBjaGFuZ2VzIEkgYW0gcHJvcG9zaW5nLjxicj4NCjxicj4NCkNvdWxkIHlvdSBw bGVhc2UgcHJvdmlkZSB5b3VyIGZlZWRiYWNrIG9uIHRoZSBhcmVhcy9wcm9wb3NlZCB0ZXh0IEkg aGF2ZSBoaWdobGlnaHRlZCBiZWxvdyBhcyB3ZWxsIGFzIGFueSBvdGhlciBhcmVhcyBvZiB0aGUg ZG9jdW1lbnQgdGhhdCB5b3UgdGhpbmsgcmVxdWlyZSBhZGRpdGlvbmFsIHdvcmsvY2xlYW51cCBi ZWZvcmUgeW91IGNvbnNpZGVyIHRoZSBkb2N1bWVudCBpcyByZWFkeSBmb3IgYSBXRyBMYXN0IENh bGwuPGJyPg0KPGJyPg0KMSkgU2VjdGlvbiAyOiBVcGRhdGUgdGhlIGxhc3QgcGFyYWdyYXBoIHRv IHJlZmVyZW5jZSB0aGUgV0cgZHJhZnQgZm9yIENETkkgdXNlIGNhc2VzIGFuZCByZW1vdmUgcmVm ZXJlbmNlIHRvIGRyYWZ0LXdhdHNvbi1jZG5pLXVzZS1jYXNlcywgaS5lLjxicj4NCjxicj4NCk9M RDo8YnI+DQombmJzcDsmbmJzcDtVc2UgY2FzZXMgZm9yIENETiBJbnRlcmNvbm5lY3Rpb24gYXJl IGZ1cnRoZXIgZGlzY3Vzc2VkIGluPGJyPg0KJm5ic3A7Jm5ic3A7W0ktRC5iZXJ0cmFuZC1jZG5p LXVzZS1jYXNlc10gKHdoaWNoIGNvbnRhaW5zIGEgbWVyZ2VkIHNldCBvZiB1c2U8YnI+DQombmJz cDsmbmJzcDtjYXNlcyBwcmV2aW91c2x5IHByZXNlbnRlZCBpbiBbSS1ELndhdHNvbi1jZG5pLXVz ZS1jYXNlc10gYW5kPGJyPg0KJm5ic3A7Jm5ic3A7W0ktRC5iZXJ0cmFuZC1jZG5pLXVzZS1jYXNl cy0wMF0pLjxicj4NCk5FVzo8YnI+DQombmJzcDsmbmJzcDtVc2UgY2FzZXMgZm9yIENETiBJbnRl cmNvbm5lY3Rpb24gYXJlIGZ1cnRoZXIgZGlzY3Vzc2VkIGluPGJyPg0KJm5ic3A7Jm5ic3A7W0kt RC5pZXRmLWNkbmktdXNlLWNhc2VzXS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWdyZWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQoyKSBTZWN0aW9uIDQgY29udGFpbnMgYW4gaW50 cm9kdWN0aW9uIGFuZCAyIHN1Yi1zZWN0aW9ucyAoNC4xICZhbXA7IDQuMikgdGhhdCBhcmUgZWFj aCBqdXN0IGEgY291cGxlIG9mIHNlbnRlbmNlcywgc28gSSBwcm9wb3NlIG1lcmdpbmcgdGhlbSBp bnRvIGEgc2luZ2xlIHNlY3Rpb24gYW5kIGNoYW5naW5nIHRoZSBmaXJzdCB0d28gc2VudGVuY2Vz IG9mIHNlY3Rpb24gNCBhcHByb3ByaWF0ZWx5LCBpLmUuPGJyPg0KPGJyPg0KT0xEOjxicj4NCiZu YnNwOyZuYnNwO1RoaXMgc2VjdGlvbiBleHBhbmRzIG9uIGhvdyBDRE5JIGludGVyZmFjZXMgY2Fu IHJldXNlIGFuZCBsZXZlcmFnZTxicj4NCiZuYnNwOyZuYnNwO2V4aXN0aW5nIHByb3RvY29scy4g Jm5ic3A7Rmlyc3QgdGhlICZxdW90O3JldXNlIGluc3RlYWQgb2YgcmVpbnZlbnQmcXVvdDsgZGVz aWduPGJyPg0KJm5ic3A7Jm5ic3A7cHJpbmNpcGxlIGlzIHJlc3RhdGVkLCB0aGVuIGVhY2ggaW5l dHJmYWNlIGlzIGRpc2N1c3NlZCBpbmRpdmlkdWFsbHk8YnI+DQombmJzcDsmbmJzcDt3aXRoIGV4 YW1wbGUgY2FuZGlkYXRlIHByb3RvY29scyB0aGF0IGNhbiBiZSBjb25zaWRlcmVkIGZvciByZXVz ZSBvcjxicj4NCiZuYnNwOyZuYnNwO2xldmVyYWdlLiA8YnI+DQpORVc6PGJyPg0KJm5ic3A7Jm5i c3A7VGhpcyBzZWN0aW9uIGV4cGFuZHMgb24gaG93IENETkkgaW50ZXJmYWNlcyBjYW4gcmV1c2Ug YW5kIGxldmVyYWdlPGJyPg0KJm5ic3A7Jm5ic3A7ZXhpc3RpbmcgcHJvdG9jb2xzIGJlZm9yZSBk ZXNjcmliaW5nIGVhY2ggQ0ROSSBpbnRlcmZhY2UgaW5kaXZpZHVhbGx5PGJyPg0KJm5ic3A7Jm5i c3A7YW5kIGhpZ2hsaWdodGluZyBleGFtcGxlIGNhbmRpZGF0ZSBwcm90b2NvbHMgdGhhdCBjb3Vs ZCBjb25zaWRlcmVkIGZvcjxicj4NCiZuYnNwOyZuYnNwO3JldXNlIG9yIGxldmVyYWdpbmcgdG8g aW1wbGVtZW50IHRoZSBDRE5JIGludGVyZmFjZXMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaW5lIGJ5IG1lLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQozKSBTZWN0aW9u IDUgaXMgY3VycmVudGx5IHRpdGxlICZxdW90O0dhcCBBbmFseXNpcyBvZiByZWxldmFudCBTdGFu ZGFyZGlzYXRpb24gYW5kIFJlc2VhcmNoIEFjdGl2aXRpZXMmcXVvdDsgYnV0IGZvbGxvd2luZyB0 aGUgYWdyZWVtZW50IGF0IHRoZSBsYXN0IElFVEYgdG8gbW92ZSB0aGUgZ2VuZXJpYyBkZXNjcmlw dGlvbnMgb2Ygb3RoZXIgYWN0aXZpdGllcyBpbnRvIGFuIGFwcGVuZGl4IFNlY3Rpb24gNSBubyBs b25nZXIgcmVmZXJlbmNlcyBhbnkgcmVzZWFyY2gNCiBhY3Rpdml0aWVzIHNvIEkgcHJvcG9zZSBj aGFuZ2luZyB0aGUgdGl0bGUgdG8mcXVvdDsgR2FwIEFuYWx5c2lzIG9mIHJlbGV2YW50IFN0YW5k YXJkaXNhdGlvbiBhY3Rpdml0aWVzJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjQpIEFmdGVyIHRoZSBnZW5lcmFsIGludHJvZHVj dGlvbiBpbiBTZWN0aW9uIDUgdGhlcmUgYXJlIG9ubHkgc2VjdGlvbnMgdGhhdCBvdXRsaW5lIG90 aGVyIHJlc2VhcmNoIGFjdGl2aXRpZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB5b3UgbWVhbiAmcXVvdDtzdGFuZGFyZGl6YXRp b24gYWN0aXZpdGllcyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5mb3IgQ29udGVudCBBY3F1aXNpdGlvbiAoc2VjdGlvbiA1LjEpIGFuZCBDRE5JIE1l dGFkYXRhIChTZWN0aW9uIDUuMikgYnV0IHRoZXJlIGFyZSBub3Qgc2VjdGlvbnMgZm9yIHRoZSBv dGhlciBDRE5JIGludGVyZmFjZXMgKENvbnRyb2wsIExvZ2dpbmcsIFJlcXVlc3QgUm91dGluZyku PGJyPg0KPGJyPg0KVGhlIHJlYXNvbiBmb3IgdGhlIGxhY2sgb2YgdGV4dCBpcyBJTU8gYmVjYXVz ZSB0aGVyZSBpcyBubyBjdXJyZW50IG9yIHBhc3Qgc3RhbmRhcmRpc2F0aW9uIGFjdGl2aXR5IGFk ZHJlc3NpbmcgdGhvc2UgYXJlYXMgYnV0IHRoZSBkb2N1bWVudCBjdXJyZW50bHkgZG9lcyBub3Qg bWVudGlvbiB0aGF0IGFuZCB0aGVyZWZvcmUgZ2l2ZXMgdGhlIGltcHJlc3Npb24gb2YgYmVpbmcg aW5jb21wbGV0ZS48YnI+DQo8YnI+DQpJIHRoZXJlZm9yZSBwcm9wb3NlIG1ha2luZyB0aGUgZm9s bG93aW5nIGNoYW5nZSB0byB0aGUgbGFzdCBzZW50ZW5jZSBpbiBTZWN0aW9uIDU6PGJyPg0KPGJy Pg0KT0xEOjxicj4NCiZuYnNwOyZuYnNwO1RoZSBmb2xsb3dpbmcgc2VjdGlvbnMgd2lsbCBzdW1t YXJpemUgdGhlIGV4aXN0aW5nIHdvcmsgb2YgdGhlPGJyPg0KJm5ic3A7Jm5ic3A7c3RhbmRhcmQg Ym9kaWVzIGFib3ZlIGFnYWluc3QgdGhlIENETkkgcHJvYmxlbSBzcGFjZS48YnI+DQpORVc6PGJy Pg0KJm5ic3A7Jm5ic3A7VGhlIGZvbGxvd2luZyBzZWN0aW9ucyB3aWxsIHN1bW1hcml6ZSB0aGUg ZXhpc3Rpbmcgd29yayBvZiB0aGU8YnI+DQombmJzcDsmbmJzcDtzdGFuZGFyZCBib2RpZXMgYWJv dmUgYWdhaW5zdCB0aGUgQ0ROSSBwcm9ibGVtIHNwYWNlLiBTZWN0aW9uIDUuMTxicj4NCiZuYnNw OyZuYnNwO3N1bW1hcmlzZXMgZXhpc3RpbmcgaW50ZXJmYWNlcyB0aGF0IGNvdWxkIGJlIGxldmVy YWdlZCBmb3IgY29udGVudDxicj4NCiZuYnNwOyZuYnNwO2FjcXVpc2l0aW9uIGJldHdlZW4gQ0RO cyBhbmQgU2VjdGlvbiA1LjIgc3VtbWFyaXNlcyBleGlzdGluZyBtZXRhZGF0YSA8YnI+DQombmJz cDsmbmJzcDtzcGVjaWZpY2F0aW9ucyB0aGF0IG1heSBiZSBhcHBsaWNhYmxlIHRvIENETkkuIFRv IGRhdGUgdGhlcmUgaXMgbm88YnI+DQombmJzcDsmbmJzcDtleGlzdGluZyBzdGFuZGFyZGlzYXRp b24gYWN0aXZpdGllcyBpbiB0aGUgYXJlYXMgb2YgdGhlIHJlbWFpbmluZzxicj4NCiZuYnNwOyZu YnNwO0NETkkgaW50ZXJmYWNlcyAoQ0ROSSBSZXF1ZXN0IFJvdXRpbmcsIENETkkgQ29udHJvbCBh bmQgQ0ROSSBMb2dnaW5nKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RmluZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBhIGNvdXBsZSBlZGl0b3JpYWwgc3VnZ2VzdGlvbnM6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnMvb2Yg dGhlJm5ic3A7c3RhbmRhcmQgYm9kaWVzIGFib3ZlL29mIHRoZSZuYnNwO3N0YW5kYXJkIGJvZGll cyBsaXN0ZWQgZWFybGllci88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+cy90aGVyZSBpcyBubyZuYnNwO2V4aXN0aW5nIHN0YW5kYXJkaXNhdGlv biBhY3Rpdml0aWVzL3dlIGFyZSBub3QgYXdhcmUgb2YgYW55Jm5ic3A7c3RhbmRhcmRpc2F0aW9u IGFjdGl2aXRpZXMvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KNSkgSSBhbHNvIHByb3Bvc2UgdXNpbmcgdGhlIGZvbGxvd2luZyB0ZXh0IGZvciB0 aGUgdGhpcmQgYnVsbGV0IGluIFNlY3Rpb24gNSB1bmxlc3Mgc29tZW9uZSBjYW4gc3VnZ2VzdCBt b3JlIGFwcHJvcHJpYXRlIHRleHQgdG8gc3VtbWFyaXNlIGluIGEgc2VudGVuY2Ugb3IgdHdvIGFu eSBDRE4gbWV0YWRhdGEgcmVsYXRlZCB3b3JrIGluIG90aGVyIHN0YW5kYXJkcyBib2RpZXMuPGJy Pg0KPGJyPg0KT0xEOjxicj4NCiZuYnNwOyZuYnNwO28gJm5ic3A7Jmx0O1RPRE86IEFkZCBhIHNl bnRlbmNlIG9uIElUVSZndDs8YnI+DQpORVc6PGJyPg0KJm5ic3A7Jm5ic3A7byAmbmJzcDtDYWJs ZUxhYnMsIFNOSUEgYW5kIElUVSBoYXZlIGRlZmluZWQgKG9yIGFyZSB3b3JraW5nIG9uKTxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RlZmluaXRpb25zIGZvciBjb250ZW50IHJl bGF0ZWQgbWV0YWRhdGEgZGVmaW5pdGlvbnMgYW5kIHNwZWNpZmljYXRpb248YnI+DQombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtmb3IgaXRzIGRpc3RyaWJ1dGlvbi4gSG93ZXZlciwgdGhl eSBkbyBub3QgaW5jbHVkZSBtZXRhZGF0YSBzcGVjaWZpYzxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO3RvIHRoZSBkaXN0cmlidXRpb24gb2YgY29udGVudCB3aXRoaW4gYSBDRE4g b3IgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO0NETnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYXQgd29ya3MgZm9yIG1lLiBJdCB3b3VsZCBiZSBnb29kIHRvIGdldCB0aGF0IHZh bGlkYXRlZCBieSBzb21lb25lIGF3YXJlIG9mIHRoZSB3b3JrIG9mIHRoZXNlIGJvZGllcy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo2KSBTZWN0 aW9uIDEwLjEgbGlzdHMgYSBudW1iZXIgb2YgJnF1b3Q7bm9ybWF0aXZlIHJlZmVyZW5jZXMmcXVv dDssIGlmIHdlIGFkb3B0IHRoZSBwcm9wb3NlZCBjaGFuZ2VzIGFib3ZlIGl0IHdpbGwgZW5kIHVw IGNvbnRhaW5pbmcgJnF1b3Q7bm9ybWF0aXZlJnF1b3Q7IHJlZmVyZW5jZXMgdG86PGJyPg0KJm5i c3A7Jm5ic3A7LSBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzPGJyPg0KJm5ic3A7Jm5ic3A7LSBk cmFmdC1iZXJ0cmFuZC1jZG5pLWV4cGVyaWVtZW50czxicj4NCiZuYnNwOyZuYnNwOy0gZHJhZnQt amVua2lucy1jZG5pLW5hbWVzPGJyPg0KJm5ic3A7Jm5ic3A7LSBSRkMyMTE5PGJyPg0KPGJyPg0K QWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHRoZSB0ZXh0IG9mIHRoZSBQcm9ibGVtIFN0YXRlbWVudCBh Z2FpbiwgSSBhbSBub3QgY29udmluY2VkIHRoYXQgdGhlIFByb2JsZW0gU3RhdGVtZW50IHJlZmVy ZW5jZXMgYW55IG9mIHRob3NlIGRvY3VtZW50cyBub3JtYXRpdmVseSBhcyB0aGUgMyBDRE5JIHJl bGF0ZWQgZHJhZnRzIGFyZSByZWZlcmVuY2VkIGluIGEgY29udGV4dCB3aGVyZSB0aGV5IGFyZSBm b3IgZnVydGhlciBpbmZvcm1hdGlvbiBhbmQgdGhlDQogUHJvYmxlbSBTdGF0ZW1lbnQgZG9lcyBu b3QgbWFrZSB1c2Ugb2YgYW55IG9mIHRoZSBjYXBpdGFsaXNlZCB0ZXJtcyBkZWZpbmVkIGluIFJG QzIxMTkuPGJyPg0KPGJyPg0KVGhlcmVmb3JlLCB1bmxlc3MgYW55b25lIG9iamVjdHMgSSB3aWxs IG1vdmUgdGhlIHJlZmVyZW5jZXMgZm9yIHRoZSB0aHJlZSBDRE5JIHJlbGF0ZWQgZHJhZnRzIHRv IHRoZSAmcXVvdDtJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzJnF1b3Q7IHNlY3Rpb24gYW5kIHJlbW92 ZSB0aGUgcmVmZXJlbmNlIGZvciBSRkMyMTE5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdlIGRvbid0IHdhbnQgbm9ybWF0aXZl IHJlZiB0byB0aGUgb3RoZXIgY2RuaSBkcmFmdHMgYXMgdGhlIHByb2JsZW0gc3RhdGVtZW50IGlz IHNldHRpbmcgdGhlIHN0YWdlIGZvciB0aGUgb3RoZXIgZG9jdW1lbnRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3M8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJhbmNvaXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KVGhh bmtzPGJyPg0KQmVuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpDRE5pIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpDRE5pQGlldGYub3JnIj5DRE5pQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZG5pPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIw IiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjU0MyIgc3R5bGU9IndpZHRoOjQwNy4yNXB0Ij4NCjx0 Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KICBjb2xvcjojMUY0 OTdEIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjE1NCIgaGVpZ2h0PSIxMDAiIGlkPSJhODA5OWEy ZS0yODY0LTRmNTYtODU2OS1lMzFkMmUzZjgyYzgiIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUND OTU3MC4xNjE2MDc4MCI+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyZxdW90Oywm cXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwv cD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9 IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTQzIiBzdHlsZT0id2lkdGg6NDA3LjI1cHQ7YmFj a2dyb3VuZC1hdHRhY2htZW50OmluaXRpYWw7LXdlYmtpdC1iYWNrZ3JvdW5kLWNsaXA6IGluaXRp YWw7DQogICAtd2Via2l0LWJhY2tncm91bmQtb3JpZ2luOiBpbml0aWFsO2JhY2tncm91bmQtY29s b3I6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDoNCiAgIG5vLXJlcGVhdDtiYWNrZ3JvdW5kLXBv c2l0aW9uLXg6NTAlO2JhY2tncm91bmQtcG9zaXRpb24teTowJSI+DQo8dGJvZHk+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj48L3RkPg0KPC90cj4NCjwvdGJvZHk+ DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxl LXNwYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0Ow0KICBmb250LWZhbWlseTomcXVv dDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjaztkaXNwbGF5Om5vbmUi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lk dGg9IjU0MyIgc3R5bGU9IndpZHRoOjQwNy4yNXB0O2JhY2tncm91bmQtYXR0YWNobWVudDppbml0 aWFsOy13ZWJraXQtYmFja2dyb3VuZC1jbGlwOiBpbml0aWFsOw0KICAgLXdlYmtpdC1iYWNrZ3Jv dW5kLW9yaWdpbjogaW5pdGlhbDtiYWNrZ3JvdW5kLWNvbG9yOmluaXRpYWw7YmFja2dyb3VuZC1y ZXBlYXQ6DQogICBuby1yZXBlYXQ7YmFja2dyb3VuZC1wb3NpdGlvbi14OjUwJTtiYWNrZ3JvdW5k LXBvc2l0aW9uLXk6MCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRv cCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAxMS4yNXB0IC4yNWluIj4NCjxwIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZh bWlseToNCiAgICAmcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiM2NjY2NjYiPjxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyYW5jb2lzIExlIEZhdWNoZXVyPC9z cGFuPjwvc3Ryb25nPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiM2 NjY2NjYiPjxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRpc3Rpbmd1aXNoZWQgRW5naW5lZXI8L3Nw YW4+PC9zdHJvbmc+PGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Q29ycG9yYXRlIERldmVsb3BtZW50 PC9zcGFuPjwvc3Ryb25nPjxicj4NCjxhIGhyZWY9Im1haWx0bzpmbGVmYXVjaEBjaXNjby5jb20i PjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij5mbGVmYXVjaEBjaXNjby5jb208L3NwYW4+PC9h Pjxicj4NClBob25lOiZuYnNwOzxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiYjNDM7MzMgNDkgNzIzIDI2MTk8 L3NwYW4+PC9zdHJvbmc+PGJyPg0KTW9iaWxlOiZuYnNwOzxzdHJvbmc+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiYjNDM7 MzMgNiAxOSA5OCA1MCA5MDwvc3Bhbj48L3N0cm9uZz48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRp bmc6MGluIDBpbiA3LjVwdCAxNS4wcHQiPg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7DQogICAgZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij5D aXNjbyBTeXN0ZW1zIEZyYW5jZTwvc3Bhbj48L3N0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzY2NjY2NiI+PGJyPg0KR3JlZW5zaWRlPGJyPg0KNDAwIEF2ZSBkZSBSb3VtYW5p bGxlPGJyPg0KMDY0MTAgU29waGlhIEFudGlwb2xpczxicj4NCkZyYW5jZTxicj4NCjxhIGhyZWY9 Imh0dHA6Ly93d3cuY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+Q2lzY28u Y29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPHRkIHdpZHRoPSIy MDAiIHN0eWxlPSJ3aWR0aDoxNTAuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ow0KICBjb2xvcjpibGFjayI+PGJyPg0KPGltZyBib3JkZXI9IjAiIHdpZHRoPSIx OCIgaGVpZ2h0PSIxOSIgaWQ9Il94MDAzNl9kZjJiMGVhLWZlMTctNDI5My04ZWQ4LTE3YjlmNzEz YzM0ZSIgc3JjPSJjaWQ6aW1hZ2UwMDIuZ2lmQDAxQ0M5NTcwLjE2MTYwNzgwIj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSI0MDAiIHN0eWxlPSJ3aWR0aDozMDAuMHB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0i cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJw YWRkaW5nOjBpbiAuMjVpbiAwaW4gLjI1aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ow0KICAgIGNvbG9yOiMwMDk5MDAiPiZuYnNwO1RoaW5rIGJlZm9y ZSB5b3UgcHJpbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6NS4yNXB0IC4yNWluIDQuNXB0IC4yNWluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToNCiAgICA3LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiM5OTk5OTkiPjxicj4NClRoaXMgZW1haWwgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgdXNlLCBkaXN0cmlidXRpb24gb3Ig ZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCAob3IgYXV0aG9yaXplZCB0byByZWNlaXZlIGZvciB0 aGUgcmVjaXBpZW50KSwNCiBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWls IGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2UuPGJyPg0KPGJyPg0KQ2lzY28g U3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwgUnVl IENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBTZWluZSBJbG90 IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKsLCAz NDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNhdGlvbjogSmVh bi1MdWMgTWljaGVsIEdpdm9uZS48YnI+DQo8YnI+DQpGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9y bWF0aW9uIGdvIHRvOjxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91 dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbCI+aHR0cDovL3d3dy5jaXNjby5j b20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3Rk Pg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_1CA25301D2219F40B3AA37201F0EACD1136D12B4PACDCEXMB05cabl_-- --_005_1CA25301D2219F40B3AA37201F0EACD1136D12B4PACDCEXMB05cabl_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=11041; creation-date="Fri, 28 Oct 2011 16:49:53 GMT"; modification-date="Fri, 28 Oct 2011 16:49:53 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== --_005_1CA25301D2219F40B3AA37201F0EACD1136D12B4PACDCEXMB05cabl_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=87; creation-date="Fri, 28 Oct 2011 16:49:53 GMT"; modification-date="Fri, 28 Oct 2011 16:49:53 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --_005_1CA25301D2219F40B3AA37201F0EACD1136D12B4PACDCEXMB05cabl_-- From zahariad@synelixis.com Sun Oct 30 04:29:43 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366E321F8483 for ; Sun, 30 Oct 2011 04:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.706 X-Spam-Level: X-Spam-Status: No, score=0.706 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlhEIeZQYDIQ for ; Sun, 30 Oct 2011 04:29:39 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 65EAC21F8468 for ; Sun, 30 Oct 2011 04:29:39 -0700 (PDT) Received: (qmail 21998 invoked by uid 0); 30 Oct 2011 11:29:33 -0000 Received: from unknown (HELO box521.bluehost.com) (74.220.219.121) by oproxy9.bluehost.com with SMTP; 30 Oct 2011 11:28:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=synelixis.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Reply-To; bh=aB2S+k+WqyIO3vWJtuu+Kok2vO9oBogSVcXWMcRBusM=; b=NM/UBc0kuketnBEMB1wvDN8fIMo3oo0Dw0fMvR6VwhhF1DaHa8SOzWuORbWgHFvB1E7PTrDy18Y+JNp6TPrzO79/Ng8Bj/CHJZ94whhGWvcwsMiIahEAdtc1oPIAtpSa; Received: from ppp-94-66-12-19.home.otenet.gr ([94.66.12.19] helo=acer) by box521.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RKTZ8-00012j-VF; Sun, 30 Oct 2011 05:28:42 -0600 From: "Theodore Zahariadis" To: "'Alan Kavanagh'" , "'Kent Leung \(kleung\)'" , "'Mark de Jong'" References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com><4E8506FC.1020701@cisco.com><260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com><853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk><9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net><260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com><1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk><260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com><166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk><1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> <2979E38DD6FC6544B789C8DAD7BAFC521024D515@xmb-sjc-235.amer.cisco.com> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34@EUSAACMS0701.eamcs.ericsson.se> Date: Sun, 30 Oct 2011 13:28:35 +0200 Organization: Synelixis Solutions Ltd Message-ID: <00bf01cc96f7$11feedf0$35fcc9d0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C0_01CC9707.D587BDF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyUIr+HmTxXW9tSQVutk3w35YQ82wC0/Z7g Content-Language: el X-Identified-User: {712:box521.bluehost.com:synelixi:synelixis.com} {sentby:smtp auth 94.66.12.19 authed with zahariad@synelixis.com} Cc: cdni@ietf.org, 'ZhouZhipeng' Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zahariad@synelixis.com List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 11:29:43 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C0_01CC9707.D587BDF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, I think that a good approach would be to proceed in cdni-use cases to ensure realistic/short-term use cases and then proceed to the advanced use cases that the Future Media Networks (FMN) cluster of projects have submitted under the cdni-advanced-use-cases ID. Best Regards, Theodore From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: Thursday, October 27, 2011 12:04 AM To: Kent Leung (kleung); Mark de Jong Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt So are we defining a limited set of use cases or should we ensure that use cases at the very least ensure that the realistic use cases both deployed today and ones planed are captured in the use cases document? Alan _____ From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: October-26-11 5:02 PM To: Mark de Jong; Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I also agree with Ben that content adaptation is an optimization that is out of scope. We have enough to do in the WG already. Kent From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Mark de Jong Sent: Wednesday, October 26, 2011 1:21 PM To: Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Alan, As Ben stated the overall discussion right now is about delivery, not on adaptation. It is hard enough to get consensus on the delivery aspect already not to mention your requirement from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for the first specs. I can imagine this could be a discussion later on but please let us keep the scope of this be clean and transparent. It is of benefit of everyone to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: Ben Im assuming then based on your comments below are you suggesting we are going to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that there is some work to be done, but I still feel that content adaptation is to me a fundamental requirement to what collectively we should address in the CDN-I WG. I do agree with you that content adaptation is an optimization between CDN's but it's a very important one that I know Network Service Providers particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: Hello Ben, The UE may select the content format on the CP web. After that the user only desires to get his selected content. But how the content is transferred to the client is not worried by the user. The CP may create a special format as required by the user and ask the CDN to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select. Lots of things may be possible to do and CDN providers offer many additional services on top of the "core" service of content delivery. However, our objective (based on my interpretation of the CDNI charter) is to focus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and deployable within a short time frame (18-24 months). Content transformation/adaptation is not an essential requirement in order to achieve that aim (we can deliver content from CSPs to End Users via multiple CDNs without needing or requiring any CDN supports content adaptation). In my opinion we have enough work to do already without trying to expand the scope of our work to include additional requirements that do not help us address our core objectives as laid out in the CDNI charter. In this case, it is nothing related to how the user select formats on CP website. So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion). As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look. I think the core functionality maps pretty well to the CDNI interfaces, namely: Request Routing, Metadata configuration, log production and control plus content acquisition and content delivery. I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media formats. One candidate is your company, another is CDN-X. The users are located in France. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. What you are describing is a possible optimization that a particular CDN may wish to implement not a core functionality required to enable content delivery between interconnected CDNs. I can think of many optimizations that a CDN could implement to differentiate their service but the internal workings of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core function required to enable content delivery between interconnected CDNs and therefore given the workload we already have to specify solutions that do address the core functionality required to interconnect CDNs I do not think we should be trying to add more work into that workload as it will only distract us from achieving our goal of producing deployable solutions within the timeframe we are being told by operators they needs solutions within. Ben So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: Ben and Philip, I like to respond your concern in this one email: Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN. For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias. By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711. For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to this case above. I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request. As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types". Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery). My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO. Ben A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) If the content is needed to be protected, generally you may know all the systems should be granted by the content owner. Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also. So, trust is not a problem for the media. Philip, Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it may save investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service. But the reality is all operators ask us to provide a system that may support different service systems. Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple . At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ben, Zhipeng, all, I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft. The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this. I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well? Scott, Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive. Best wishes phil Philip Eardley Research and Technology Strategy This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is. Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. If you have any more question or comments, pls share in this thread. Thanks. Zhipeng -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. Section 10 Security Considerations Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is determined by the respective CDN's. Scott _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ------=_NextPart_000_00C0_01CC9707.D587BDF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I think that a good approach would be to proceed in cdni-use cases to = ensure realistic/short-term use cases and then proceed to the advanced = use cases that the Future Media Networks (FMN) cluster of projects have = submitted under the cdni-advanced-use-cases ID.

 

Best Regards,

Theodore

 

 

From:= = Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]
Sent: = Thursday, October 27, 2011 12:04 AM
To: Kent Leung (kleung); = Mark de Jong
Cc: cdni@ietf.org; ZhouZhipeng
Subject: = Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

So= are we defining a limited set of use cases or should we ensure that use = cases at the very least ensure that the realistic use cases both = deployed today and ones planed are captured in the use cases document? =

 

Al= an

 

From:= Kent Leung = (kleung) [mailto:kleung@cisco.com]
Sent: October-26-11 5:02 = PM
To: Mark de Jong; Alan Kavanagh
Cc: = cdni@ietf.org; ZhouZhipeng
Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

I also agree with Ben that content adaptation is an optimization that = is out of scope.  We have enough to do in the WG = already.

 

Kent

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Mark de Jong
Sent: Wednesday, October 26, 2011 1:21 = PM
To: Alan Kavanagh
Cc: cdni@ietf.org; = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Hi = Alan,

 

As Ben stated the overall = discussion right now is about delivery, not on adaptation. It is hard = enough to get consensus on the delivery aspect already not to mention = your requirement from content adaptation added to that, so I agree with = Ben we should stick with the delivery aspect for the first specs. I = can imagine this could be a discussion later on but please let us keep = the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. = Thanks.

 

<= div>

= Met vriendelijke groet,

= Kind regards,=

Mark de Jong
International Business = Developer
Jet-Stream = BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214

<= o:p> 

= - Event:=  = Meet us at Streaming Media Europe, 17-18 October, London, = UK

= - Event:=  Meet us at Online Video Strategies, 19 October, London, = UK

= - Event:=  Meet us at CDN World Summit, 25-28 October, London, = UK

= -=  = News:=  Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com

= - News: Check http://www.jet-stream.com to = download our 'Six Trends in CDNs' brochure

 

= -=  = Blog:=  = www.jet-stream.com/blog/

= -=  = VideoExchange:=  = www.vdo-x.net

= -=  = Streamzilla:=  = www.streamzillacdn.com<= /span>

= -=  = Corporate:=  = www.jet-stream.com

=
<= p class=3DMsoNormal> 

On 26, Oct,2011, at 8:33 PM, Alan = Kavanagh wrote:

 

Ben

Im assuming = then based on your comments below are you suggesting we are going to = have a number of versions of the CDN-I Metadata?

I sympathise = with what you are pointing out below and do agree that there is some = work to be done, but I still feel that content adaptation is to me a = fundamental requirement to what collectively we should address in the = CDN-I WG. I do agree with you that content adaptation is an optimization = between CDN's but it's a very important one that I know Network Service = Providers particularly require.

Alan

-----Original = Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: = October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] = I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On = 12 Oct 2011, at 10:22, ZhouZhipeng = wrote:

Hello Ben,

The UE may select the content = format on the CP web. After that the user only desires to get his = selected content.

But how the content is transferred = to the client is not worried by the = user.

The CP may create a special format = as required by the user and ask the CDN to deliver to = user.

While CP may give a HD format = content to uCDN and the dCDN may then transform to the format as the = user select.


Lots of things may = be possible to do and CDN providers offer many additional services on = top of the "core" service of content delivery. However, our = objective (based on my interpretation of the CDNI charter) is to focus = on what is necessary to interconnect CDNs to deliver content from a CSP = to an End User that is targeted and deployable within a short time frame = (18-24 months).

Content transformation/adaptation is not an = essential requirement in order to achieve that aim (we can deliver = content from CSPs to End Users via multiple CDNs without needing or = requiring any CDN supports content adaptation).

In my opinion we = have enough work to do already without trying to expand the scope of our = work to include additional requirements that do not help us address our = core objectives as laid out in the CDNI = charter.

In this case, it is nothing related to how the user select = formats on CP website.

So, it is the CP and user to decide = the content format not the CDN(your assert is not correct and seems you = take that assert as your base for the = discussion).

 

As for "the core CDN = functionality offered by CDNs today", I have ever raised an email = before that your company's webpage has claimed supporting media = transformation and multi-screen = service.

Perhaps, I like asking you list = some features that you feel are the core functionalities by existing = main stream CDNs. Thus we may compare and take deep = look.


I think the core = functionality maps pretty well to the CDNI interfaces, namely: Request = Routing, Metadata configuration, log production and control plus content = acquisition and content delivery.

I guess many people have the = experience/knowledge of content related service. The user and CP only = care whether the CDN providers may satisfy their requirement while not = care the internal process. Just as GSM/PSTN interconnection, the user = only care successful interconnection while not care how the voice is = transformed in process.

 

Besides, I like raise a = case:

Given currently BBC recruits CDN = providers that may support 10 media = formats.

One candidate is your company, = another is CDN-X. The users are located in = France.

So both your company and CDN-X = should connect a France CDN = provider(CDN-Y).

If your company's solution is to = send 10 streams of different = format

of one content to CDN-Y; While = CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct = some adaptation.

Comparing these two solutions, for = your company and CDN-X, absolutely the cost of CDN-X is much = lower.

For CDN-Y, in solution-1, it should = receive/forward 10 streams ; while in solution-2, it should only receive = 1 stream but need to take transformation to output 10 = streams.

 

Which solution is more competitive. = it is Solution 1, right. Remember the price from BBC is same to both = your company and CDN-X or BBC would select one CDN provider with the = lower price.

If a CDN provider may not get the = contract from CP, how it may say it is not a core = functionality.


What you are = describing is a possible optimization that a particular CDN may wish to = implement not a core functionality required to enable content delivery = between interconnected CDNs. I can think of many optimizations that a = CDN could implement to differentiate their service but the internal = workings of an individual CDN are out of scope of our charter.

So = to repeat my position for a final time: Content adaptation is not a core = function required to enable content delivery between interconnected CDNs = and therefore given the workload we already have to specify solutions = that do address the core functionality required to interconnect CDNs I = do not think we should be trying to add more work into that workload as = it will only distract us from achieving our goal of producing deployable = solutions within the timeframe we are being told by operators they needs = solutions within.

Ben

So, if we all realize that = currently the media type is rich, the CDN providers should survive in = the existing ecosystem and support the media types as required by the = market.

 

Back to the case of GSM/G.711, it = just when concerning the interconnection, the transformation should at = once be solved. Otherwise the interconnection may not be = operated.

 

Br,

Zhipeng

 

 

 

 

-----Original = Message-----

From: Ben Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]

Sent: Wednesday, October 12, 2011 = 12:19 AM

To: = ZhouZhipeng

Cc: philip.eardley@bt.com; cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Zhipeng,

 

On 11 Oct 2011, at 05:16, = ZhouZhipeng wrote:

 

Ben and = Philip,

I like to respond your concern in = this one = email:

 

Ben,

I feel what we are now discussing = is what is the "core" function of = CDN.

As you say, CDN is used to deliver = content. That is absolutely correct that the delivery capability is the = core requirement for CDN = system.

While CDN is used to provide the = content delivery = service.

What means service. It should = include "time" "location" and "media = type", etc. These features are all the core feature for a = service.

If we only concern "delivering = one data block", I am not sure whether the issues such as = "logging" "geographic constraint" are the core of = CDN.

 

For "without explicit = knowledge of what that content actually is ", I am not sure whether = the wording is accurate since generally a CDN may claim it support = different = medias.

By this opportunity, I like to = share a use case: a call from a GSM phone to a PSTN telephone, the voice = stream should be transformed from GSM voice to = G.711.

For the user, he does not need to = know what type of data has been transferred, but the operator has done = some work to interconnect two systems, = right.

I like to know whether you may = accept that my use case is similar to this case = above.

 

I don't think your use case is = similar to the analogy of mobile networks being interconnected to PSTN = networks. In the case of content delivery the negotiation is done = between the User/Client and the Content Provider and the CDN is just = used to execute/perform the delivery that has been negotiated. The CDN = is not involved in the decision making of what representations the = Content Provider decides to offer to the User/Client or in what = representations the User/Client decides to = request.

 

As for you said selecting media by = the "portal", you may see the way " uCDN delivers = multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media = types".

 

Now what you're talking about is an = optimisation, not a core function required to actually deliver the = content (and report, bill, etc. for that = delivery).

 

My position is that we should focus = on how to enable the interconnection of the core CDN functionality = offered by CDNs today (which is also my interpretation of the scope of = the CDNI working group as expressed in its charter) because doing so is = a significant piece of work in itself. Let's not start trying to add in = additional functionality beyond what the majority of CDNs support today = as that will just delay us getting usable specifications into the market = in a timely fashion IMO.

 

Ben

 

A good question is = "security" since I have done six years on the = DRM

and like to promote the DRM all = around the world:) If the content is needed to be protected, generally = you may know all the systems should be granted by the content = owner.

Here I also like to clarify that = not only the media itself but the information related to service itself = (such as the geographic constraint) should be protected = also.

So, trust is not a problem for the = media.

 

Philip,

Thank you that you feel Content = Adaption is an issue for "Requirements" but I do not know why = it is not for Use = case.

I like to clarify to U that it is = important for you operator since it may save investment if the system = may support different = services.

For us vendor, we are happy = operator may install a system for the mobile service and another system = for the FBB = service.

But the reality is all operators = ask us to provide a system that may support different service = systems.

 

Frankly, Ben and Philip, I remember = I have explained somewhere that to implement this is rather simple = .

At least the Use case and = Requirement are informational to be referred in future work. So I do = really feel you may accept = it.

Of course I like to respond your = more concern and = comments.

Thanks.

Zhipeng

 

 

 

-----Original = Message-----

From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]

Sent: Monday, October 10, 2011 = 11:22 PM

To: ben@niven-jenkins.co.uk; = ZhouZhipeng

Cc: cdni@ietf.org

Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Ben, Zhipeng, = all,

 

I think that Content Adaptation is = more an issue for the Requirements doc than for the Use cases = draft.

 

The key question is whether we want = the CDNI interfaces to be able to cope with a scenario where (say) HD/SD = conversion is done in the dCDN & to signal about = this.

 

I think that coping with this = scenario is a second order requirement, ie we should not worry about it = in the initial standards-track work. I don't know, did we ever decide = whether the Use cases doc is restricted to "initial" = scenarios, or whether it's all-encompassing, ie covering = "future" scenarios as = well?

 

Scott,

Reading some of your examples, they = seem to be valid even if content adaptation (HD/SD) is out of = scope.

- a dCDN might for some reason be = unwilling to distribute = HD?

- a CSP might want to make sure the = dCDN can use HLS = encapsulation?

But these sorts of examples seem to = be static policy things (to = do

with the capabilities & = preferences of the CDNs & CSP), rather = than

metadata associated with a = particular piece of content. In = the

discussion so far, I think = negotiation about static policy stuff = is

rather out of = scope(?)

 

On security considerations, an = interesting question is whether trust is transitive. Don't think it need = be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean = that the CSP automatically trusts the dCDN. However, i suspect this can = get arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.

 

Best = wishes

phil

 

 

Philip = Eardley

Research and Technology = Strategy

 

This email contains BT information, = which may be privileged or confidential. It's meant only for the = individual(s) or entity named above. If you're not the intended = recipient, note that disclosing, copying, distributing or using this = information is prohibited. If you've received this email in error, = please let me know immediately on the email address above. Thank you. We = monitor our email system, and may record your = emails.

British Telecommunications = plc

Registered office: 81 Newgate = Street London EC1A 7AJ Registered = in

England no: = 1800000

 

 

-----Original = Message-----

From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On = Behalf

Of Ben = Niven-Jenkins

Sent: 10 October 2011 = 12:04

To: = ZhouZhipeng

Cc: cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Colleagues,

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

 

IMO Section 5.1.3 should be removed = from the Use Cases draft. Content Adaptation (i.e. taking in a content = item in one format and transforming it to another format or = representation) is not a "core" function of a CDN which = typically delivers the content that is requested without explicit = knowledge of what that content actually = is.

 

Let's not forget that in building = an end to end content service the CDN is only one component and is the = component tasked with executing the delivery of a specific = representation (version/copy/format etc.) of the selected content not = the component tasked with deciding (or applying policy) on which = version/copy/representation of content should be = delivered.

 

The decision as to which = version/copy/representation to offer and allow to be delivered to a = given device/user is implemented outside of the CDN (e.g. by the = "portal" where the user first makes their content selection = prior to the CDN becoming involved in the delivery of the selected = content).

 

Ben

 

On 8 Oct 2011, at 08:20, = ZhouZhipeng = wrote:

 

Following Scott's comments on = section 5.1.3, I feel Scott's description on the use case of HD and SD = is not exactly = correct.

If one movie has two formats of HD = and SD, then we have two content with different identifier. In DRM = scope, the basic unit is a content = copy.

 

Here the first bullet "a = subset of encodings deliverable to specific devices," has listed = the case of content = adaptation.

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

In last month, I have contacted the = Authors of this document and taken some email exchanges with Grant and = Philip = (BT).

I have shown BT with some = information that I know in this case and area to explain the content = flexibility is currently a basic requirement for CDN service and related = negotiation is needed in the CDN = interconnection.

Meanwhile, I should also invite you = in this group raising your comments or questions on this case since I = hope my use case may be incorporated in the use case = draft.

 

If you have any more question or = comments, pls share in this = thread.

Thanks.

Zhipeng

 

 

 

 

 

 

-----Original = Message-----

=

From: Scott Wainner = [mailto:swainner@cisco.com]

Sent: Friday, September 30, 2011 = 8:02 = AM

To: cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Section 2.3 Nomadic = Users

This description falls under the = category of Geographic = Extension

yet the third paragraph states the = case where a different device = is

used in the same CDN coverage area. =  The intent of this use = case

needs to be clarified. =  Perhaps the use case is trying to = address

the scenario where a Nomadic User-A = with an agreement = allowing

access to content from CSP-A via = uCDN moves to a dCDN in a = different

region.  The dCDN is allowed = to distribute the content of CSP-A = to

User-A; however, not other users in = the region of the dCDN = are

allowed to retrieve the content = unless they too have such an = agreement.

 

Section 5.1.3 Content Encoding = Restrictions Need to clarify if = we're

talking about the restrictions on = the delivery of specific = content

or the restrictions on the ability = of a CDN to deliver = specific

content.  I certainly = understand the case where a CSP will = restrict

the distribution of content to a = "managed path" if such content = is

HD while allowing the content = distribution via an un-managed path = if

such content is SD (same could = apply to encryption methods, = delivery

methods, etc.).  On the = contrary, the dCDN may have its = own

restrictions of blocking the = distribution of HD content = while

allowing the distribution of SD = content.

 

o first bullet makes sense if the = dCDN can perform a subset = of

encapsulations for a reference set = of media (e.g. HLS, HSS, but = not

DASH) o second bullet makes sense = where the dCDN doesn't want = to

offer high bit-rate variants of the = media o third bullet make = sense

if the policy addresses QoE but I = don't think = subscriber

rights/authorizations = apply.

 

Section 10 Security = Considerations

 

Aside from the security = considerations WITHIN the uCDN and dCDN, = I

think we can describe this in four = contexts:

 

a. The relationship between the CSP = and the uCDN (the principle = contract

arrangement for = distribution)

b. The relationship between the = uCDN and dCDN (the transitive = trust

relationship that extends the = contract defined in (a) above) c. = The

relationship between the User and = dCDN (the recognition of right = to

download predicated on (b) above) = d. The relationship between = the

User and CSP (the contract = authorizing the user access to = the

content)

 

The user is not interested in the = a-b nor the b-c relationship. = The

user is only interested in the = transparency and interoperability = of

the security relationship between = d-b or d-c to the point that = the

authorization granted in d-a is = viable when the delivery = is

initiated via either d-b or d-c. =  As an example, the uCDN might = use

URL appended tokens for = authentication while dCDN might use = URL

appended hashes.  The user = doesn't want to know about the = distinct

methods, but transparency is only = afforded if the methods = are

interoperable clearly defined when = the delegation for = content

delivery is executed. =  Clearly, the choice of authentication method is determined by the = respective = CDN's.

 

Scott

 

_______________________________________________

CDNi mailing = list

CDNi@ietf.org

https://www.ietf.org/= mailman/listinfo/cdni

=

 

_______________________________________________

CDNi mailing = list

CDNi@ietf.org

https://www.ietf.org/= mailman/listinfo/cdni

=

 


_______________________________________________
CDNi = mailing list
CDNi@ietf.org
https://www.ietf.org/= mailman/listinfo/cdni
____________________________________________= ___
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni

 

------=_NextPart_000_00C0_01CC9707.D587BDF0-- From daniel.negru@labri.fr Sun Oct 30 05:44:26 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB7521F84A6 for ; Sun, 30 Oct 2011 05:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51QAulHPSYuf for ; Sun, 30 Oct 2011 05:44:14 -0700 (PDT) Received: from iona.labri.fr (iona.labri.fr [147.210.8.143]) by ietfa.amsl.com (Postfix) with ESMTP id 482CB21F8B03 for ; Sun, 30 Oct 2011 05:44:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by iona.labri.fr (Postfix) with ESMTP id 7C80BDDE; Sun, 30 Oct 2011 13:44:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=labri.fr; h= content-language:x-mailer:content-type:content-type:mime-version :message-id:date:date:subject:subject:in-reply-to:references :from:from:received:received; s=mail; t=1319978650; x= 1321793050; bh=PfvC1M0exxxwLWroPgIvSnu8YVAm8SX/KSJ2rfMqXrE=; b=G RrnpqlJtRYVfzawurdK4UwEd928OhLGjufs4/agy1yrbFWjDVk13kNZXcvllzUBD 2hQkLW5bSN8B5AZb4rMnl06jeFjezVpQ+iZJOLpu0Q81h/8tP8FCJaau8uIVMnsc wXKzuY+eSxEgzQZcd6ky/B6n+6uvtn7+rIWTh+TYpk= X-Virus-Scanned: amavisd-new at labri.fr Received: from iona.labri.fr ([127.0.0.1]) by localhost (iona.labri.fr [127.0.0.1]) (amavisd-new, port 10027) with LMTP id U4A9gSXaqcQd; Sun, 30 Oct 2011 13:44:10 +0100 (CET) Received: from DanielVAIO (unknown [89.95.65.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by iona.labri.fr (Postfix) with ESMTPSA id D8C18ABB; Sun, 30 Oct 2011 13:44:05 +0100 (CET) From: "Daniel NEGRU" To: , "'Alan Kavanagh'" , "'Kent Leung \(kleung\)'" , "'Mark de Jong'" References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com><4E8506FC.1020701@cisco.com><260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com><853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk><9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net><260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com><1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk><260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com><166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk><1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> <2979E38DD6FC6544B789C8DAD7BAFC521024D515@xmb-sjc-235.amer.cisco.com> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34@EUSAACMS0701.eamcs.ericsson.se> <00bf01cc96f7$11feedf0$35fcc9d0$@com> In-Reply-To: <00bf01cc96f7$11feedf0$35fcc9d0$@com> Date: Sun, 30 Oct 2011 13:44:03 +0100 Message-ID: <068801cc9701$9c9dcad0$d5d96070$@labri.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0689_01CC9709.FE82DA30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGTiEw7TTxWMTuxzW9oyrtq8e8gDgIDwsUxAcKcKVIB5VUFIgGB+pjqAVbzciwB1bjORQLsIfdFAf1rD/cCfvlsbwISc+WHApxUkdMBxcjbsQMkRzNtlSwRMQA= Content-Language: fr Cc: cdni@ietf.org, 'ZhouZhipeng' Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 12:44:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0689_01CC9709.FE82DA30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 I would like to add to Theodore=92s email that we suggested within this proposed draft (draft-fmn-cdni-advanced-use-cases-00) a use case for adaptation. Maybe it could be used, if of interest, for future = discussions on content adaptation. =20 Best regards, Daniel=20 =20 =20 De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de Theodore Zahariadis Envoy=E9 : dimanche 30 octobre 2011 12:29 =C0 : 'Alan Kavanagh'; 'Kent Leung (kleung)'; 'Mark de Jong' Cc : cdni@ietf.org; 'ZhouZhipeng' Objet : Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Dear all, =20 I think that a good approach would be to proceed in cdni-use cases to = ensure realistic/short-term use cases and then proceed to the advanced use = cases that the Future Media Networks (FMN) cluster of projects have submitted under the cdni-advanced-use-cases ID. =20 Best Regards, Theodore =20 =20 From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Sent: Thursday, October 27, 2011 12:04 AM To: Kent Leung (kleung); Mark de Jong Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 So are we defining a limited set of use cases or should we ensure that = use cases at the very least ensure that the realistic use cases both = deployed today and ones planed are captured in the use cases document?=20 =20 Alan =20 _____ =20 From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Sent: October-26-11 5:02 PM To: Mark de Jong; Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I also agree with Ben that content adaptation is an optimization that is = out of scope. We have enough to do in the WG already. =20 Kent =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Mark de Jong Sent: Wednesday, October 26, 2011 1:21 PM To: Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Hi Alan, =20 As Ben stated the overall discussion right now is about delivery, not on adaptation. It is hard enough to get consensus on the delivery aspect already not to mention your requirement from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for = the first specs. I can imagine this could be a discussion later on but = please let us keep the scope of this be clean and transparent. It is of benefit = of everyone to get the first specs as fast as possible. Thanks. =20 Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 =20 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in = CDNs' brochure =20 - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com =20 On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: =20 Ben Im assuming then based on your comments below are you suggesting we are going to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that = there is some work to be done, but I still feel that content adaptation is to me = a fundamental requirement to what collectively we should address in the = CDN-I WG. I do agree with you that content adaptation is an optimization = between CDN's but it's a very important one that I know Network Service = Providers particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Ben Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: Hello Ben, The UE may select the content format on the CP web. After that the user = only desires to get his selected content. But how the content is transferred to the client is not worried by the = user. The CP may create a special format as required by the user and ask the = CDN to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select. Lots of things may be possible to do and CDN providers offer many = additional services on top of the "core" service of content delivery. However, our objective (based on my interpretation of the CDNI charter) is to focus = on what is necessary to interconnect CDNs to deliver content from a CSP to = an End User that is targeted and deployable within a short time frame = (18-24 months). Content transformation/adaptation is not an essential requirement in = order to achieve that aim (we can deliver content from CSPs to End Users via multiple CDNs without needing or requiring any CDN supports content adaptation). In my opinion we have enough work to do already without trying to expand = the scope of our work to include additional requirements that do not help us address our core objectives as laid out in the CDNI charter. In this case, it is nothing related to how the user select formats on CP website. So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for = the discussion). =20 As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed = supporting media transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and = take deep look. I think the core functionality maps pretty well to the CDNI interfaces, namely: Request Routing, Metadata configuration, log production and = control plus content acquisition and content delivery. I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process. =20 Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media formats. One candidate is your company, another is CDN-X. The users are located = in France. So both your company and CDN-X should connect a France CDN = provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to = CDN-Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely = the cost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while = in solution-2, it should only receive 1 stream but need to take = transformation to output 10 streams. =20 Which solution is more competitive. it is Solution 1, right. Remember = the price from BBC is same to both your company and CDN-X or BBC would = select one CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is = not a core functionality. What you are describing is a possible optimization that a particular CDN = may wish to implement not a core functionality required to enable content delivery between interconnected CDNs. I can think of many optimizations = that a CDN could implement to differentiate their service but the internal workings of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a = core function required to enable content delivery between interconnected CDNs = and therefore given the workload we already have to specify solutions that = do address the core functionality required to interconnect CDNs I do not = think we should be trying to add more work into that workload as it will only distract us from achieving our goal of producing deployable solutions = within the timeframe we are being told by operators they needs solutions = within. Ben So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market. =20 Back to the case of GSM/G.711, it just when concerning the = interconnection, the transformation should at once be solved. Otherwise the = interconnection may not be operated. =20 Br, Zhipeng =20 =20 =20 =20 -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Zhipeng, =20 On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: =20 Ben and Philip, I like to respond your concern in this one email: =20 Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct = that the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media = type", etc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether = the issues such as "logging" "geographic constraint" are the core of CDN. =20 For "without explicit knowledge of what that content actually is ", I am = not sure whether the wording is accurate since generally a CDN may claim it support different medias. By this opportunity, I like to share a use case: a call from a GSM phone = to a PSTN telephone, the voice stream should be transformed from GSM voice = to G.711. For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to = this case above. =20 I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery = the negotiation is done between the User/Client and the Content Provider and = the CDN is just used to execute/perform the delivery that has been = negotiated. The CDN is not involved in the decision making of what representations = the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request. =20 As for you said selecting media by the "portal", you may see the way " = uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers = one media stream to dCDN and dCDN takes some adaptation to support multiple media types". =20 Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for = that delivery). =20 My position is that we should focus on how to enable the interconnection = of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in = its charter) because doing so is a significant piece of work in itself. = Let's not start trying to add in additional functionality beyond what the = majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO. =20 Ben =20 A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) If the content is = needed to be protected, generally you may know all the systems should be = granted by the content owner. Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic = constraint) should be protected also. So, trust is not a problem for the media. =20 Philip, Thank you that you feel Content Adaption is an issue for "Requirements" = but I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it = may save investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service. But the reality is all operators ask us to provide a system that may = support different service systems. =20 Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple . At least the Use case and Requirement are informational to be referred = in future work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng =20 =20 =20 -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Ben, Zhipeng, all, =20 I think that Content Adaptation is more an issue for the Requirements = doc than for the Use cases draft. =20 The key question is whether we want the CDNI interfaces to be able to = cope with a scenario where (say) HD/SD conversion is done in the dCDN & to = signal about this. =20 I think that coping with this scenario is a second order requirement, ie = we should not worry about it in the initial standards-track work. I don't = know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" = scenarios as well? =20 Scott, Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) =20 On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and = uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility = is to say that we will only handle cases where the trust is transitive. =20 Best wishes phil =20 =20 Philip Eardley Research and Technology Strategy =20 This email contains BT information, which may be privileged or = confidential. It's meant only for the individual(s) or entity named above. If you're = not the intended recipient, note that disclosing, copying, distributing or = using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 =20 =20 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Colleagues, =20 IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming = it to another format or representation) is not a "core" function of a CDN = which typically delivers the content that is requested without explicit = knowledge of what that content actually is. =20 Let's not forget that in building an end to end content service the CDN = is only one component and is the component tasked with executing the = delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on = which version/copy/representation of content should be delivered. =20 The decision as to which version/copy/representation to offer and allow = to be delivered to a given device/user is implemented outside of the CDN = (e.g. by the "portal" where the user first makes their content selection prior = to the CDN becoming involved in the delivery of the selected content). =20 Ben =20 On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: =20 Following Scott's comments on section 5.1.3, I feel Scott's description = on the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. =20 Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken = some email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area = to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments = or questions on this case since I hope my use case may be incorporated in = the use case draft. =20 If you have any more question or comments, pls share in this thread. Thanks. Zhipeng =20 =20 =20 =20 =20 =20 -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt =20 Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. =20 Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. =20 o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. =20 Section 10 Security Considerations =20 Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: =20 a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) =20 The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is determined by the respective CDN's. =20 Scott =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni =20 ------=_NextPart_000_0689_01CC9709.FE82DA30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I would like to add to Theodore’s email that we suggested = within this proposed draft (draft-fmn-cdni-advanced-use-cases-00) a use = case for adaptation. Maybe it could be used, if of interest, for future = discussions on content adaptation.

 

Best regards,

Daniel

 

 

De : = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Theodore Zahariadis
Envoy=E9 : dimanche 30 octobre = 2011 12:29
=C0 : 'Alan Kavanagh'; 'Kent Leung (kleung)'; = 'Mark de Jong'
Cc : cdni@ietf.org; = 'ZhouZhipeng'
Objet : Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Dear all,

 

I think that a good approach would be to proceed in cdni-use cases to = ensure realistic/short-term use cases and then proceed to the advanced = use cases that the Future Media Networks (FMN) cluster of projects have = submitted under the cdni-advanced-use-cases ID.

 

Best Regards,

Theodore

 

 

From:= Alan = Kavanagh [mailto:alan.kavanagh@ericsson.com]
Sent: Thursday, = October 27, 2011 12:04 AM
To: Kent Leung (kleung); Mark de = Jong
Cc: cdni@ietf.org; ZhouZhipeng
Subject: Re: = [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

So= are we defining a limited set of use cases or should we ensure that use = cases at the very least ensure that the realistic use cases both = deployed today and ones planed are captured in the use cases document? =

 

Al= an

 

From:= Kent Leung = (kleung) [mailto:kleung@cisco.com]
Sent: October-26-11 5:02 = PM
To: Mark de Jong; Alan Kavanagh
Cc: = cdni@ietf.org; ZhouZhipeng
Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

I also agree with Ben that content adaptation is an optimization that = is out of scope.  We have enough to do in the WG = already.

 

Kent

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Mark de Jong
Sent: Wednesday, October 26, 2011 1:21 = PM
To: Alan Kavanagh
Cc: cdni@ietf.org; = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Hi = Alan,

 

As Ben stated the overall = discussion right now is about delivery, not on adaptation. It is hard = enough to get consensus on the delivery aspect already not to mention = your requirement from content adaptation added to that, so I agree with = Ben we should stick with the delivery aspect for the first specs. I = can imagine this could be a discussion later on but please let us keep = the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. = Thanks.

 

<= div>

= Met vriendelijke groet,

= Kind regards,=

Mark de Jong
International Business = Developer
Jet-Stream = BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214

<= o:p> 

= - Event:=  = Meet us at Streaming Media Europe, 17-18 October, London, = UK

= - Event:=  Meet us at Online Video Strategies, 19 October, London, = UK

= - Event:=  Meet us at CDN World Summit, 25-28 October, London, = UK

= -=  = News:=  Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com

= - News: Check http://www.jet-stream.com to = download our 'Six Trends in CDNs' brochure

 

= -=  = Blog:=  = www.jet-stream.com/blog/

= -=  = VideoExchange:=  = www.vdo-x.net

= -=  = Streamzilla:=  = www.streamzillacdn.com<= /span>

= -=  = Corporate:=  = www.jet-stream.com

=
<= p class=3DMsoNormal> 

On 26, Oct,2011, at 8:33 PM, Alan = Kavanagh wrote:

 

Ben

Im assuming = then based on your comments below are you suggesting we are going to = have a number of versions of the CDN-I Metadata?

I sympathise = with what you are pointing out below and do agree that there is some = work to be done, but I still feel that content adaptation is to me a = fundamental requirement to what collectively we should address in the = CDN-I WG. I do agree with you that content adaptation is an optimization = between CDN's but it's a very important one that I know Network Service = Providers particularly require.

Alan

-----Original = Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: = October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] = I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On = 12 Oct 2011, at 10:22, ZhouZhipeng wrote:

Hello = Ben,

The UE may select the content = format on the CP web. After that the user only desires to get his = selected content.

But how the content is transferred = to the client is not worried by the = user.

The CP may create a special format = as required by the user and ask the CDN to deliver to = user.

While CP may give a HD format = content to uCDN and the dCDN may then transform to the format as the = user select.


Lots of things may = be possible to do and CDN providers offer many additional services on = top of the "core" service of content delivery. However, our = objective (based on my interpretation of the CDNI charter) is to focus = on what is necessary to interconnect CDNs to deliver content from a CSP = to an End User that is targeted and deployable within a short time frame = (18-24 months).

Content transformation/adaptation is not an = essential requirement in order to achieve that aim (we can deliver = content from CSPs to End Users via multiple CDNs without needing or = requiring any CDN supports content adaptation).

In my opinion we = have enough work to do already without trying to expand the scope of our = work to include additional requirements that do not help us address our = core objectives as laid out in the CDNI charter.

In this case, it is nothing related = to how the user select formats on CP = website.

So, it is the CP and user to decide = the content format not the CDN(your assert is not correct and seems you = take that assert as your base for the = discussion).

 

As for "the core CDN = functionality offered by CDNs today", I have ever raised an email = before that your company's webpage has claimed supporting media = transformation and multi-screen = service.

Perhaps, I like asking you list = some features that you feel are the core functionalities by existing = main stream CDNs. Thus we may compare and take deep = look.


I think the core = functionality maps pretty well to the CDNI interfaces, namely: Request = Routing, Metadata configuration, log production and control plus content = acquisition and content delivery.

I guess many people have the = experience/knowledge of content related service. The user and CP only = care whether the CDN providers may satisfy their requirement while not = care the internal process. Just as GSM/PSTN interconnection, the user = only care successful interconnection while not care how the voice is = transformed in process.

 

Besides, I like raise a = case:

Given currently BBC recruits CDN = providers that may support 10 media = formats.

One candidate is your company, = another is CDN-X. The users are located in = France.

So both your company and CDN-X = should connect a France CDN = provider(CDN-Y).

If your company's solution is to = send 10 streams of different = format

of one content to CDN-Y; While = CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct = some adaptation.

Comparing these two solutions, for = your company and CDN-X, absolutely the cost of CDN-X is much = lower.

For CDN-Y, in solution-1, it should = receive/forward 10 streams ; while in solution-2, it should only receive = 1 stream but need to take transformation to output 10 = streams.

 

Which solution is more competitive. = it is Solution 1, right. Remember the price from BBC is same to both = your company and CDN-X or BBC would select one CDN provider with the = lower price.

If a CDN provider may not get the = contract from CP, how it may say it is not a core = functionality.


What you are = describing is a possible optimization that a particular CDN may wish to = implement not a core functionality required to enable content delivery = between interconnected CDNs. I can think of many optimizations that a = CDN could implement to differentiate their service but the internal = workings of an individual CDN are out of scope of our charter.

So = to repeat my position for a final time: Content adaptation is not a core = function required to enable content delivery between interconnected CDNs = and therefore given the workload we already have to specify solutions = that do address the core functionality required to interconnect CDNs I = do not think we should be trying to add more work into that workload as = it will only distract us from achieving our goal of producing deployable = solutions within the timeframe we are being told by operators they needs = solutions within.

Ben

So, if we all realize that = currently the media type is rich, the CDN providers should survive in = the existing ecosystem and support the media types as required by the = market.

 

Back to the case of GSM/G.711, it = just when concerning the interconnection, the transformation should at = once be solved. Otherwise the interconnection may not be = operated.

 

Br,

Zhipeng

 

 

 

 

-----Original = Message-----

From: Ben Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]

Sent: Wednesday, October 12, 2011 = 12:19 AM

To: = ZhouZhipeng

Cc: philip.eardley@bt.com; cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Zhipeng,

 

On 11 Oct 2011, at 05:16, = ZhouZhipeng wrote:

 

Ben and = Philip,

I like to respond your concern in = this one = email:

 

Ben,

I feel what we are now discussing = is what is the "core" function of = CDN.

As you say, CDN is used to deliver = content. That is absolutely correct that the delivery capability is the = core requirement for CDN = system.

While CDN is used to provide the = content delivery = service.

What means service. It should = include "time" "location" and "media = type", etc. These features are all the core feature for a = service.

If we only concern "delivering = one data block", I am not sure whether the issues such as = "logging" "geographic constraint" are the core of = CDN.

 

For "without explicit = knowledge of what that content actually is ", I am not sure whether = the wording is accurate since generally a CDN may claim it support = different = medias.

By this opportunity, I like to = share a use case: a call from a GSM phone to a PSTN telephone, the voice = stream should be transformed from GSM voice to = G.711.

For the user, he does not need to = know what type of data has been transferred, but the operator has done = some work to interconnect two systems, = right.

I like to know whether you may = accept that my use case is similar to this case = above.

 

I don't think your use case is = similar to the analogy of mobile networks being interconnected to PSTN = networks. In the case of content delivery the negotiation is done = between the User/Client and the Content Provider and the CDN is just = used to execute/perform the delivery that has been negotiated. The CDN = is not involved in the decision making of what representations the = Content Provider decides to offer to the User/Client or in what = representations the User/Client decides to = request.

 

As for you said selecting media by = the "portal", you may see the way " uCDN delivers = multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media = types".

 

Now what you're talking about is an = optimisation, not a core function required to actually deliver the = content (and report, bill, etc. for that = delivery).

 

My position is that we should focus = on how to enable the interconnection of the core CDN functionality = offered by CDNs today (which is also my interpretation of the scope of = the CDNI working group as expressed in its charter) because doing so is = a significant piece of work in itself. Let's not start trying to add in = additional functionality beyond what the majority of CDNs support today = as that will just delay us getting usable specifications into the market = in a timely fashion IMO.

 

Ben

 

A good question is = "security" since I have done six years on the = DRM

and like to promote the DRM all = around the world:) If the content is needed to be protected, generally = you may know all the systems should be granted by the content = owner.

Here I also like to clarify that = not only the media itself but the information related to service itself = (such as the geographic constraint) should be protected = also.

So, trust is not a problem for the = media.

 

Philip,

Thank you that you feel Content = Adaption is an issue for "Requirements" but I do not know why = it is not for Use = case.

I like to clarify to U that it is = important for you operator since it may save investment if the system = may support different = services.

For us vendor, we are happy = operator may install a system for the mobile service and another system = for the FBB = service.

But the reality is all operators = ask us to provide a system that may support different service = systems.

 

Frankly, Ben and Philip, I remember = I have explained somewhere that to implement this is rather simple = .

At least the Use case and = Requirement are informational to be referred in future work. So I do = really feel you may accept = it.

Of course I like to respond your = more concern and = comments.

Thanks.

Zhipeng

 

 

 

-----Original = Message-----

From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]

Sent: Monday, October 10, 2011 = 11:22 PM

To: ben@niven-jenkins.co.uk; = ZhouZhipeng

Cc: cdni@ietf.org

Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Ben, Zhipeng, = all,

 

I think that Content Adaptation is = more an issue for the Requirements doc than for the Use cases = draft.

 

The key question is whether we want = the CDNI interfaces to be able to cope with a scenario where (say) HD/SD = conversion is done in the dCDN & to signal about = this.

 

I think that coping with this = scenario is a second order requirement, ie we should not worry about it = in the initial standards-track work. I don't know, did we ever decide = whether the Use cases doc is restricted to "initial" = scenarios, or whether it's all-encompassing, ie covering = "future" scenarios as = well?

 

Scott,

Reading some of your examples, they = seem to be valid even if content adaptation (HD/SD) is out of = scope.

- a dCDN might for some reason be = unwilling to distribute = HD?

- a CSP might want to make sure the = dCDN can use HLS = encapsulation?

But these sorts of examples seem to = be static policy things (to = do

with the capabilities & = preferences of the CDNs & CSP), rather = than

metadata associated with a = particular piece of content. In = the

discussion so far, I think = negotiation about static policy stuff = is

rather out of = scope(?)

 

On security considerations, an = interesting question is whether trust is transitive. Don't think it need = be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean = that the CSP automatically trusts the dCDN. However, i suspect this can = get arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.

 

Best = wishes

phil

 

 

Philip = Eardley

Research and Technology = Strategy

 

This email contains BT information, = which may be privileged or confidential. It's meant only for the = individual(s) or entity named above. If you're not the intended = recipient, note that disclosing, copying, distributing or using this = information is prohibited. If you've received this email in error, = please let me know immediately on the email address above. Thank you. We = monitor our email system, and may record your = emails.

British Telecommunications = plc

Registered office: 81 Newgate = Street London EC1A 7AJ Registered = in

England no: = 1800000

 

 

-----Original = Message-----

From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On = Behalf

Of Ben = Niven-Jenkins

Sent: 10 October 2011 = 12:04

To: = ZhouZhipeng

Cc: cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Colleagues,

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

 

IMO Section 5.1.3 should be removed = from the Use Cases draft. Content Adaptation (i.e. taking in a content = item in one format and transforming it to another format or = representation) is not a "core" function of a CDN which = typically delivers the content that is requested without explicit = knowledge of what that content actually = is.

 

Let's not forget that in building = an end to end content service the CDN is only one component and is the = component tasked with executing the delivery of a specific = representation (version/copy/format etc.) of the selected content not = the component tasked with deciding (or applying policy) on which = version/copy/representation of content should be = delivered.

 

The decision as to which = version/copy/representation to offer and allow to be delivered to a = given device/user is implemented outside of the CDN (e.g. by the = "portal" where the user first makes their content selection = prior to the CDN becoming involved in the delivery of the selected = content).

 

Ben

 

On 8 Oct 2011, at 08:20, = ZhouZhipeng = wrote:

 

Following Scott's comments on = section 5.1.3, I feel Scott's description on the use case of HD and SD = is not exactly = correct.

If one movie has two formats of HD = and SD, then we have two content with different identifier. In DRM = scope, the basic unit is a content = copy.

 

Here the first bullet "a = subset of encodings deliverable to specific devices," has listed = the case of content = adaptation.

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

In last month, I have contacted the = Authors of this document and taken some email exchanges with Grant and = Philip = (BT).

I have shown BT with some = information that I know in this case and area to explain the content = flexibility is currently a basic requirement for CDN service and related = negotiation is needed in the CDN = interconnection.

Meanwhile, I should also invite you = in this group raising your comments or questions on this case since I = hope my use case may be incorporated in the use case = draft.

 

If you have any more question or = comments, pls share in this = thread.

Thanks.

Zhipeng

 

 

 

 

 

 

-----Original = Message-----

=

From: Scott Wainner = [mailto:swainner@cisco.com]

Sent: Friday, September 30, 2011 = 8:02 = AM

To: cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Section 2.3 Nomadic = Users

This description falls under the = category of Geographic = Extension

yet the third paragraph states the = case where a different device = is

used in the same CDN coverage area. =  The intent of this use = case

needs to be clarified. =  Perhaps the use case is trying to = address

the scenario where a Nomadic User-A = with an agreement = allowing

access to content from CSP-A via = uCDN moves to a dCDN in a = different

region.  The dCDN is allowed = to distribute the content of CSP-A = to

User-A; however, not other users in = the region of the dCDN = are

allowed to retrieve the content = unless they too have such an = agreement.

 

Section 5.1.3 Content Encoding = Restrictions Need to clarify if = we're

talking about the restrictions on = the delivery of specific = content

or the restrictions on the ability = of a CDN to deliver = specific

content.  I certainly = understand the case where a CSP will = restrict

the distribution of content to a = "managed path" if such content = is

HD while allowing the content = distribution via an un-managed path = if

such content is SD (same could = apply to encryption methods, = delivery

methods, etc.).  On the = contrary, the dCDN may have its = own

restrictions of blocking the = distribution of HD content = while

allowing the distribution of SD = content.

 

o first bullet makes sense if the = dCDN can perform a subset = of

encapsulations for a reference set = of media (e.g. HLS, HSS, but = not

DASH) o second bullet makes sense = where the dCDN doesn't want = to

offer high bit-rate variants of the = media o third bullet make = sense

if the policy addresses QoE but I = don't think = subscriber

rights/authorizations = apply.

 

Section 10 Security = Considerations

 

Aside from the security = considerations WITHIN the uCDN and dCDN, = I

think we can describe this in four = contexts:

 

a. The relationship between the CSP = and the uCDN (the principle = contract

arrangement for = distribution)

b. The relationship between the = uCDN and dCDN (the transitive = trust

relationship that extends the = contract defined in (a) above) c. = The

relationship between the User and = dCDN (the recognition of right = to

download predicated on (b) above) = d. The relationship between = the

User and CSP (the contract = authorizing the user access to = the

content)

 

The user is not interested in the = a-b nor the b-c relationship. = The

user is only interested in the = transparency and interoperability = of

the security relationship between = d-b or d-c to the point that = the

authorization granted in d-a is = viable when the delivery = is

initiated via either d-b or d-c. =  As an example, the uCDN might = use

URL appended tokens for = authentication while dCDN might use = URL

appended hashes.  The user = doesn't want to know about the = distinct

methods, but transparency is only = afforded if the methods = are

interoperable clearly defined when = the delegation for = content

delivery is executed. =  Clearly, the choice of authentication method is determined by the = respective = CDN's.

 

Scott

 

_______________________________________________

CDNi mailing = list

CDNi@ietf.org

https://www.ietf.org/= mailman/listinfo/cdni

=

 

_______________________________________________

CDNi mailing = list

CDNi@ietf.org

https://www.ietf.org/= mailman/listinfo/cdni

=

 


_______________________________________________
CDNi = mailing list
CDNi@ietf.org
https://www.ietf.org/= mailman/listinfo/cdni
____________________________________________= ___
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/= mailman/listinfo/cdni

 

------=_NextPart_000_0689_01CC9709.FE82DA30-- From zhouzhipeng@huawei.com Mon Oct 31 01:49:37 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8304B21F84D8 for ; Mon, 31 Oct 2011 01:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.775 X-Spam-Level: X-Spam-Status: No, score=-4.775 tagged_above=-999 required=5 tests=[AWL=-0.577, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z4Ci0Pstw4q for ; Mon, 31 Oct 2011 01:49:33 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4414A21F84D3 for ; Mon, 31 Oct 2011 01:49:28 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTX00FIK9U6SR@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 31 Oct 2011 16:49:19 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTX005DH9TVHZ@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 31 Oct 2011 16:49:18 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ30004; Mon, 31 Oct 2011 16:49:18 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 31 Oct 2011 16:49:16 +0800 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.117]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 16:49:10 +0800 Date: Mon, 31 Oct 2011 08:49:09 +0000 From: ZhouZhipeng In-reply-to: <144D124A-E8A2-48DC-A98D-6F33B2EB1B90@cisco.com> X-Originating-IP: [10.138.73.38] To: Francois Le Faucheur Message-id: <260A32EFD5C9EB47AD504929D005DF6217F6D1B3@SZXEML519-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hHpHkybtF26E+Cm0tV/cDw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65VyDPoAgALmZACAAEfzgIABUJOAgABR0oCAAZQUkIAADRgAgBYn8ICAAA1tAIABOe8g///B/QCAAfcmAP//xCQAgARjD7A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> <144D124A-E8A2-48DC-A98D-6F33B2EB1B90@cisco.com> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 08:49:37 -0000 --Boundary_(ID_hHpHkybtF26E+Cm0tV/cDw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 RGVhciBGcmFuY29pcywgYW5kIGFsbCwNClRoYW5rcyBmb3IgYWxsIHRoZSBncm91cOKAmXMgYXR0 ZW50aW9uIG9uIHRoaXMgdG9waWMuDQpJIGFtIGFsc28gaGFwcHkgdGhhdCBteSBwcm9wb3NhbCBo YXMgZ290dGVuIHNvIG11Y2ggdmFsdWFibGUgcmVzcG9uc2UvcXVlc3Rpb25zLyBjb21tZW50cy4N ClRoYXQgd2lsbCBiZSB2ZXJ5IGhlbHBmdWwgZm9yIGFsbCBvZiB1cyB0byBjYXRjaCBhIGNvbXBs ZXRlIHVuZGVyc3RhbmRpbmcgYW5kIHNvbHV0aW9uIGZvciB0aGlzIG1hcmtldCBkZW1hbmQuDQpX aGlsZSBJIGZlZWwgdGlsbCBub3cgdGhlIHRvcGljIGl0c2VsZiBoYXMgbm90IGJlZW4gY29tcGxl dGVseSBhbmFseXplZCBhbmQgSSBhbSBidXN5IGRvaW5nIHRoZSB3b3JrLiBJIHdpbGwgZXhwb3Nl IG15IGNvbnRyaWJ1dGlvbiBzb29uIGFmdGVyIEkgY29tcGxldGUgdGhhdCB3b3JrLg0KTWVhbndo aWxlIEkgaG9wZSB0aGUgZ3JvdXAgbWF5IGFsbG93IHNvbWUgbW9yZSB0aW1lIGZvciBwZW9wbGUg dG8gY29uc2lkZXIgaXQuIFBlcmhhcHMgc29tZSBtb3JlIHBlb3BsZSB3aWxsIGVtZXJnZSBpbiB0 aGUgZ3JvdXAgbWFpbCBsaXN0Lg0KQ3VycmVudGx5LCBzb21lIHBlb3BsZSBoYXMgY2xhaW1lZCB0 aGVpciBwcmVmZXJlbmNlLiAgSSBmZWVsIHBlcmhhcHMgbm90IGEgZmV3IHBlb3BsZSBoYXZlIHN1 cHBvcnRlZCB0aGlzIHVzZSBjYXNlKHRoZSBhdXRob3JzIG9mIGRyYWZ0LWZtbi1jZG5pLWFkdmFu Y2VkLXVzZS1jYXNlcy0wMCwgQWxhbiBmcm9tIEVyaWNzc29uLCBDaGluYU1vYmlsZSwgQ2hpbmF0 ZWxlY29tLCAgcGVyaGFwcyBhbHNvIEtQTiwgYW5kIG1lKS4NCg0KSSBoYXZlIGV4cGxhaW5lZCB0 aGF0IGZvciBDRE4tQSBhbmQgQ0ROLUIsIHRoZXkgbWF5IG5lZ290aWF0ZSB3aGV0aGVyIHRvIHN1 cHBvcnQgdGhlIENETkkgYWRhcHRhdGlvbiBzb2x1dGlvbi4gSGVuY2Ugc3VjaCBvcHRpb25hbCBh cnJhbmdlbWVudCB3aWxsIG9ubHkgYnJpbmcgYmVuZWZpdCB3aGVuIGJvdGggdXBzdHJlYW0gYW5k IGRvd25zdHJlYW0gYWdyZWVzIHRoYXQgYXQgdGhlaXIgYXBwcm9wcmlhdGUgc2l0dWF0aW9uLg0K DQpTbywgSSBzaW5jZXJlbHkgc3VnZ2VzdCB0d28gQ2hhaXJzIGFuZCB0aGUgd2hvbGUgZ3JvdXAg bWF5IGFsbG93IHNvbWUgbW9yZSBkYXlzIGZvciB0aGlzIHRvcGljLiAgIEkgc3VnZ2VzdCBhZnRl ciB0aGUgVGFpcGVpIG1lZXRpbmcgLg0KQnkgdGhlbiB3ZSBhbGwgd2lsbCBnZXQgYSBjbGVhcmVy IHVuZGVyc3RhbmRpbmcgYW5kIGRlY2lzaW9uLg0KDQpUaGFua3MuDQpaaGlwZW5nDQoNCg0KDQpG cm9tOiBGcmFuY29pcyBMZSBGYXVjaGV1ciBbbWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbV0NClNl bnQ6IEZyaWRheSwgT2N0b2JlciAyOCwgMjAxMSA5OjUwIFBNDQpUbzogWmhvdVpoaXBlbmcNCkNj OiBjZG5pQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtY2RuaS11c2UtY2FzZXMtMDAudHh0DQoNCkhpIGFnYWluIFpoaXBlbmcsDQoNClRoZXJlIGlz IG9uZSBvdGhlciBwb2ludCBJIHNob3VsZCBoYXZlIGJyb3VnaHQgdXAgaW4gbXkgcHJldmlvdXMg bWVzc2FnZToNClRoZSBxdWVzdGlvbiBpcyBub3Qgc28gbXVjaCB3aGV0aGVyIHRoZXJlIGFyZSBi ZW5lZml0cyB0byBhbGxvd2luZyBjb250ZW50IGFkYXB0YXRpb24gZm9yIHNvbWUgZW52aXJvbm1l bnRzLCBub3Igd2hldGhlciBvbmUgcGFydGljdWxhciBpbmRpdmlkdWFsIGNvdWxkIGNvbmNlaXZl IGFuIGFwcHJvYWNoIGZvciBjb250ZW50IGFkYXB0YXRpb24gdGhhdCBzdWl0cyBoaW0uIFRoZSBx dWVzdGlvbiBoZXJlIGlzIHJhdGhlciB3aGV0aGVyIGl0IGlzIGp1c3RpZmllZCBmb3IgdGhlIFdv cmtpbmcgR3JvdXAgdG8gZm9jdXMgZW5lcmd5IG9uIHRoYXQgcHJvYmxlbSByaWdodCBub3cgaW4g b3JkZXIgdG8gZGV2ZWxvcCBhIGNvbnNlbnN1cy1iYXNlZCBhcHByb2FjaCB0aGF0IHN1aXRzIHRo ZSBjb21tdW5pdHkgYXMgYSB3aG9sZSwgd2hpbGUgd2UgZG9uJ3QgZXZlbiBoYXZlIHRoZSBiYXNl IHNvbHV0aW9uIGluIHBsYWNlLg0KDQpZb3UgaGF2ZSBtYWRlIGl0IGNsZWFyIHRoYXQgeW91IGZl ZWwgdGhlIFdHIHNob3VsZCBpbmRlZWQgZGVkaWNhdGUgZW5lcmd5IG9uIHRoYXQgcHJvYmxlbSBy aWdodCBhd2F5IGFuZCBleHBsYWluZWQgeW91ciByYXRpb25hbGUuIFRoYW5rIHlvdS4gT3RoZXJz IGhhdmUgYWxzbyBleHByZXNzZWQgdGhlaXIgb3BpbmlvbnMuDQoNCkNoZWVycw0KDQpGcmFuY29p cw0KDQoNCk9uIDI4IE9jdCAyMDExLCBhdCAxMToyNSwgWmhvdVpoaXBlbmcgd3JvdGU6DQoNCg0K RGVhciBhbGwsDQpJbiB0aGVzZSBkYXlzIEkgYW0gYnVzeSBtYWtpbmcgYSBzdW1tYXJ5IGFuYWx5 c2lzIG9uIHRoaXMgdG9waWMuIEFzIFJpY2hhcmTigJlzIHJlcXVlc3QsIEkgbGlrZSB0byBzaG93 IG15IGluZm9ybWF0aW9uIGFsdGhvdWdoIHBlcmhhcHMgbm90IGNvbXBsZXRlIHJpZ2h0IG5vdy4N Cg0KMSkgICAgIEkgaGF2ZSBkb25lIHNvbWUgd29yayB0byBjb2xsZWN0IGRpZmZlcmVudCBjb21w YW554oCZcyByZXF1aXJlbWVudHMgYW5kIG9waW5pb25zIG9uIHRoaXMgZnVuY3Rpb25hbGl0eS4N Ck9uZSwgSSBmZWVsIG1vc3Qgb2YgdXMgaGF2ZSBhbHJlYWR5IGJlZW4gYXdhcmUgb2YgdGhlIHNl cnZpY2Ugb2YgY29udGVudCBhZGFwdGF0aW9uLCBhbmQgSSBhbHNvIHNlbnQgYW4gZW1haWwgeWVz dGVyZGF5IHRoYXQgVm9kYXBob25lIG5vdyBpcyByZXF1aXJpbmcgdGhlIHNvbHV0aW9uIHRvIGVu aGFuY2UgdGhlIHBlcmZvcm1hbmNlIG9mIGl0cyBtb2JpbGUgdmlkZW8gc2VydmljZS4NClNlY29u ZCwgaGVyZSBpcyBhbiBhcnRpY2xlIGFib3V0IENJU0NPIDog4oCcQ2lzY28gdXJnZXMgbW9iaWxl IG9wZXJhdG9ycyB0byBhZGQgdmFsdWUgdG8gQ0ROIHNlcnZpY2Vz4oCdIGh0dHA6Ly93d3cudG90 YWx0ZWxlLmNvbS92aWV3LmFzcHg/SUQ9NDY4NzA1DQpCZXNpZGVzLCBJIGhhdmUgY2hlY2tlZCBt YW55IENETiBjb21wYW554oCZcyB3ZWJzaXRlcy4gTWFueSBjbGFpbSB0byBzdXBwb3J0IHRyYW5z Y29kaW5nIHdoaWxlIHNvbWUgbWF5IG5vdC4NCg0KMikgICAgIEZvciB0aGUgd29yZGluZyDigJxj b250ZW50IGFkYXB0YXRpb27igJ0sIGl0IHNob3VsZCBiZSBjbGFyaWZpZWQgaGVyZSB0aGF0IGl0 IG1heSBiZSB0d28ga2luZHMuDQpPbmUgaXMgb25seSB0aGUgdHJhbnNmb3JtYXRpb24gb2YgZW5j YXBzdWxhdGlvbiBmb3JtYXQuIEZvciBleGFtcGxlIHRoZSBILjI2NCBzdHJlYW0gaXMgZW5jYXBz dWxhdGVkIGluIEFQUExFIGFuZCBBZG9iZSBmb3JtYXQgcmVzcGVjdGl2ZWx5Lg0KSSBrbm93IHRo YXQgQ29tY2FzdCBoYXMgYSBwcm9qZWN0IHRoYXQgbmVlZHMgdG8gcGljayB0aGUgSC4yNjQgbWVk aWEgZnJvbSB0aGUgVFMgc3RyZWFtIGFuZCB0aGVuIGVuY2Fwc3VsYXRlZCB0aGVtIGludG8gZGlm ZmVyZW50IGZvcm1hdHMoQVBQTEUsQWRvYmXigKYpIHRvIGRpZmZlcmVudCBkZXZpY2VzLg0KRm9y IHRoaXMga2luZCBvZiB0cmFuc2Zvcm1hdGlvbiwgdGhlIGNvbXB1dGluZyBjb3N0IGlzIHZlcnkg dmVyeSBsb3cgYW5kIG1heSBiZSBuZWFybHkgbmVnbGVjdGVkLg0KVGhlIG90aGVyIGlzIHRvIHRy YW5zY29kaW5nLiAgRm9yIGV4YW1wbGUgdG8gc3VwcG9ydCBkaWZmZXJlbnQgYml0cmF0ZXMuICBT aW5jZSBlbmNvZGVyIGlzIGEgaGlnaCB2YWx1ZSBmYWNpbGl0eSwgd2Ugc2hvdWxkIGNvbXBhcmUg dGhlIGNhcGl0YWwgY29zdCBvZiBlbmNvZGVyIGFuZCB0cmFuc3BvcnQgY29zdC4NCkp1c3QgdGFr ZSBhIHNpbXBsZSBtb2RlbDogY29udGVudCBpcyBkZWxpdmVyZWQgZnJvbSBOb2RlIEEgdG8gTm9k ZSBCLg0KPGltYWdlMDAyLnBuZz4NClRoZXJlIGFyZSB0d28gc29sdXRpb25zOg0KMSkgICAgIEEg aGF2ZSB0aGUgdHJhbnNjb2RlciBhbmQgZGVsaXZlciBtdWx0aS1mb3JtYXQgY29udGVudCB0byBC DQoyKSAgICAgQiBoYXZlIHRoZSB0cmFuc2NvZGVyOyBBIG9ubHkgZGVsaXZlcnMgb25lIGZvcm1h dCBjb250ZW50IHRvIEIgYW5kIEIgd291bGQgdHJhbnNjb2RlLg0KRnJvbSB3aG9sZSBzeXN0ZW0g cG9pbnQgb2YgdmlldywgZWl0aGVyIEEgb3IgQiB3b3VsZCB0cmFuc2NvZGUgd2hpbGUgdGhlIGJh bmR3aWR0aCB3b3VsZCBiZSBzYXZlZCBpbiBzb2x1dGlvbiBCLiBIZW5jZSBzb2x1dGlvbiBCIGlz IGJldHRlci4NCk5vdyBwcm92aWRlZCB0aGUgYmFuZHdpZHRoIGlzIHBhaWQgYnkgQiBhbmQgQiBz aG91bGQgZGVjaWRlIHdoZXRoZXIgdG8gaW5zdGFsbCB0cmFuc2NvZGVyLg0KKFJpY2hhcmQgaGFz IHNhaWQgdG8gc2V0IHRyYW5zY29kZXIgaW4gZWFjaCBlZGdlIHNlcnZlcikNCklmIHRoZSBjb3N0 IG9mIHJlbnRpbmcgYmFuZHdpZHRoIChmb3IgYSBmZXcgbW9udGhzKSBpcyBtb3JlIGV4cGVuc2l2 ZSB0aGFuIHRoZSBwcmljZSBvZiB0cmFuc2NvZGVyIHN1cHBvcnRpbmcgdGhlIHNhbWUgYmFuZHdp ZHRoLCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcHV0IHRoZSB0cmFuc2NvZGVyIGF0IHRoZSByZWNl aXZlciBOb2RlIEIuDQpJbiBmYWN0IEkgaGF2ZSBpbnZlc3RpZ2F0ZWQgdGhpcyBpc3N1ZSBmb3Ig bXVjaCB0aW1lLiBXaGlsZSBpbiBkaWZmZXJlbnQgYXJlYSB0aGUgcHJpY2Ugb2YgYmFuZHdpZHRo IG1heSBiZSBkaWZmZXJlbnQuICBBbmQgdGhlIHRyYW5zcG9ydCBidXJkZW4gYmV0d2VlbiB0d28g ZGlzdGFudCBwbGFjZXMgb3Igb3ZlciBhIGJhZCBuYXR1cmUgZW52aXJvbm1lbnQgd291bGQgYmUg bXVjaCBoaWdoZXIuDQpIZXJlIHRoZSBwcmljZSBpbiBVU0EgbWF5IGJlIHJlZmVycmVkIGFzOiBo dHRwOi8vc21hbGxidXNpbmVzcy52ZXJpem9uLmNvbS9wcm9kdWN0cy9pbnRlcm5ldC9oc2kvb3Zl cnZpZXcuYXNweCNwbGFucy4NCkluIFZlcml6b24sIHRoZSBwYWNrYWdlIGZvciAxMC0xNW1icHMg aXMgJDkwIHBlciBtb250aCAoSSBmZWVsIHRoZSBiYW5kd2lkdGggcXVhbGl0eSBmb3IgYnVzaW5l c3Mgd291bGQgYmUgZ3VhcmFudGVlZCkuIEkgcXVlcnkgdGhhdCB0aGUgYmFuZHdpZHRoIHByaWNl IGluIENoaW5hIG1heSBiZSA1MCUgaGlnaGVyLg0KSSBkbyBub3Qga25vdyBob3cgbXVjaCB0aGUg cHJpY2Ugd2lsbCBiZSBmb3IgdGhlIGJhbmR3aWR0aCBmcm9tIEFtc3RlcmRhbSB0byBQYXJpcyAo Y3Jvc3MgY291bnRyeSBpbiB0aGUgc2FtZSBjb250aW5lbnQpLiAgQnV0IEkgZmVlbCB0aGUgcHJp Y2UgZnJvbSBOZXdZb3JrIHRvIFBhcmlzIHdvdWxkIGFic29sdXRlbHkgYmUgdmVyeSBoaWdoLiAg QXMgZm9yIHRoZSBFbmNvZGVyLCBpdCBhbHNvIHZhcmllcy4gUGVyaGFwcyB0aGUgcHJpY2UgaW4g Q2hpbmEgd2lsbCBiZSBoaWdoZXIgdGhhbiBpbiBVU0EuIEFuZCBpbiBmYWN0IHRoZSBwcmljZSBv ZiBiYW5kd2lkdGggYW5kIGVuY29kZXIgZGVwZW5kcyBtb3N0bHkgb24gdGhlIGNvbmNyZXRlIGJ1 c2luZXNzIGl0ZW1zLiBGb3IgZXhhbXBsZSB0aGUgcHJpY2UgdG8gSHVhd2VpIG1heSBiZSBsb3dl ciB0aGFuIHRoZSBwdWJsaWMgcHJpY2UuDQpCeSBteSBjdXJyZW50IGV2YWx1YXRpb24gaW4gQ2hp bmEgaXQgaXMgYmV0dGVyIHVzaW5nIHRoZSB0cmFuc2NvZGVyIHRoYW4gcmVudGluZyBtdWx0aXBs ZSB0aW1lcyBicm9hZGJhbmQuDQpTb21lIHBlb3BsZSBoYXZlIHRvbGQgbWUgdGhhdCBmb3IgdGhl IG9wZXJhdG9yIGhpbXNlbGYgcHJvYmFibHkgdGhlIGJhbmR3aWR0aCBjb3N0IHdvdWxkIGJlIHZl cnkgbG93IGluIHRoZSBpbnRlcm5hbCBjYXBpdGFsIGNvdW50aW5nLiBCdXQgZm9yIHRoZSBpbmRl cGVuZGVudCBDRE4sIGl0IG1heSBhbm90aGVyIHRoaW5nLg0KU28sIG15IHN1Z2dlc3Rpb24gaXMg dG8gbGV0IGRpZmZlcmVudCB3YXlzIGNvLWV4aXN0LiBJIGhhdmUgYW5ub3VuY2VkIHRoYXQgdG8g bGV0IHR3byBzaWRlcyBuZWdvdGlhdGUgd2hldGhlciB0byBhc3NpZ24gZENETiBmb3IgdGhlIGNv bnRlbnQgYWRhcHRhdGlvbi4NCg0KSW4gZmFjdCwgZnJvbSBDUCB0byBDRE4sICB0aGVyZSBhcmUg dGhlIHJlYWwgYnVzaW5lc3NlcyB0aGF0IGVpdGhlciBsZXQgQ1AgdG8gcHJvdmlkZSBtdWx0aS1m b3JtYXQgY29udGVudCBvciBsZXQgdGhlIENETiB0byByZWNlaXZlIG9uZSBmb3JtYXQgYW5kIGNv bXBsZXRlIHRoZSB0cmFuc2Zvcm1hdGlvbiwgZGVwZW5kaW5nIG9uIHRoZSBjb25jcmV0ZSBidXNp bmVzcy4NCkJ5IHRoZSBzYW1lIGxvZ2ljLCBmb3JtIHVDRE4gdG8gZENETiwgaXQgbWF5IGJlIGVp dGhlciB0aGUgdUNETiB0byBwcm92aWRlIG11bHRpLWZvcm1hdCBjb250ZW50IG9yIHRoZSBkQ0RO IHRvIHJlY2VpdmUgb25lIGZvcm1hdCBjb250ZW50IGFuZCB0aGVuIGNvbXBsZXRlIHRoZSB0cmFu c2Zvcm1hdGlvbi4NCkN1cnJlbnRseSB0aGVyZSBpcyBub3QgdGhlIHJlYWwgQ0ROLUNETiBjb25u ZWN0aW9uLCBoZW5jZSB3ZSBhcmUgYmFzaW5nIG91ciBrbm93bGVkZ2Ugb24gdGhlIHJlbGF0ZWQg c29sdXRpb24gdG8gbWFrZSBvdXIgc29sdXRpb25zLg0KDQozKSAgICAgQXMgZm9yIHRoZSBwcm9j ZWR1cmUgb2YgY29udGVudCBhZGFwdGF0aW9uLCBJIGp1c3QgZHJhZnQgYSBkaWFncmFtIGFzIGJl bG93Og0KPGltYWdlMDA0LnBuZz4NCg0KWW91IG1heSBzZWUgdGhlIHNvbHV0aW9uIGlzIHJhdGhl ciBjbGVhciBhbmQgdGhlIG1ldGFkYXRhIG5lZWRlZCB3b3VsZCBiZSBjbGVhciBhbHNvLg0KDQpE ZWFyLA0KQnkgbXkgYW5hbHlzaXMgYWJvdmUsIEkga2luZGx5IGludml0ZSB5b3VyIGlkZWFzIHdo ZXRoZXIgaXQgbWF5IGJlIGFuIGFwcGxpY2FibGUgYW5kIHNpbXBsZSBwYXJ0IGluIHRoZSBDRE5J IGl0ZW0sIHByb3ZpZGVkIHRoYXQgdGhlIHNvbHV0aW9uIGlzIG9wZW4gdG8gdGhlIHR5cGVzIG9m IGNvbnRlbnQgYWRhcHRhdGlvbiBhbmQgbWF5IGJlIG9wdGlvbmFsbHkgaW1wbGVtZW50ZWQgaW4g dGhlIHJlYWwgc29sdXRpb25zL2J1c2luZXNzLiBJIGZlZWwgZm9yIHRob3NlIG9wZXJhdG9ycyB0 aGF0IG5lZWQgc3VjaCBmdW5jdGlvbmFsaXR5IGl0IHdvdWxkIGJlIHZlcnkgZ29vZCB3aGlsZSBp dCBkb2VzIG5vdCBpbXBhY3Qgb3RoZXJzIHRoYXQgZG8gbm90IGltcGxlbWVudCBpdC4NClRoYW5r cy4NClpoaXBlbmcNCg0KDQpGcm9tOiBXb3VuZHksIFJpY2hhcmQgW21haWx0bzpSaWNoYXJkX1dv dW5keUBjYWJsZS5jb21jYXN0LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDEx IDc6MjMgUE0NClRvOiBaaG91WmhpcGVuZzsgJ21hcmtAamV0LXN0cmVhbS5ubDxtYWlsdG86J21h cmtAamV0LXN0cmVhbS5ubD4nOyAnYWxhbi5rYXZhbmFnaEBlcmljc3Nvbi5jb208bWFpbHRvOidh bGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbT4nDQpDYzogJ2NkbmlAaWV0Zi5vcmc8bWFpbHRvOidj ZG5pQGlldGYub3JnPic7IFdvdW5keSwgUmljaGFyZA0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQo+SW4geW91ciBjb21w YW554oCZcyB3ZWJzaXRlLCBJIGp1c3QgZmluZCBzb21lIGluZm9ybWF0aW9uDQoNCkkgaGF2ZSB0 byBzdGVwIGluIGFzIGNvLWNoYWlyIGhlcmUuDQoNClRoZSBnb2FsIG9mIHRoaXMgV0cgaXMgbm90 IHRvIGFsaWduIHZlbmRvciBwcm9kdWN0IHJvYWRtYXBzLCBvciB0byBlcXVhbGl6ZSBhbGwgdmVu ZG9yIG9mZmVyaW5ncywgb3IgdG8gc3BlY2lmeSB0aGUgZW50aXJlIENETkkgZWNvc3lzdGVtLiBU aGUgZ29hbCBvZiB0aGlzIFdHIGlzIHRvIGVuYWJsZSB0aGUgaW50ZXJjb25uZWN0aW9uIGFuZCBp bnRlcm9wZXJhdGlvbiBvZiB0d28gb3IgbW9yZSBDRE5zLCB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0 aGUgQ0ROSSB3ZyBjaGFydGVyLg0KDQpJdCBpcyBPSyB0byBoYXZlIGEgZGlzY3Vzc2lvbiBhYm91 dCB3aGV0aGVyIGNvbnRlbnQgYWRhcHRhdGlvbiBuZWVkcyB0byBiZSBwZXJmb3JtZWQgYnkgdGhl IGRDRE4sIHNpbmNlIHRoYXQgZGVjaXNpb24gaW1wYWN0cyB0aGUgdUNETi1kQ0ROIGludGVyZmFj ZS4gU28gbGV0J3MgZmluZCBhIHByb2R1Y3RpdmUgd2F5IHRvIGRpc2N1c3MgdGhpcyBvbiB0aGUg bWFpbGluZyBsaXN0LCBhbmQgdG8gY2xvc2UgdGhlIGRpc2N1c3Npb24gYnkgSUVURiA4MiAoaWYg bm90IHNvb25lcikuDQoNCkNhbiBzb21lb25lIGRlc2NyaWJlIHJlYWwtbGlmZSBleGFtcGxlcyB3 aGVyZSBkb3duc3RyZWFtIENETiAob3IgZWRnZSBjYWNoZS1iYXNlZCkgY29udGVudCBhZGFwdGF0 aW9uIGlzIG5lZWRlZCB0b2RheSBpbiBhIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQsIG9yIHNob3J0 bHk/IE5vdCBtZXJlbHkgYSBmZWF0dXJlIGluIGEgdmVuZG9yJ3MgcHJvZHVjdCBtYXRlcmlhbHM/ DQoNClNwZWFraW5nIGFzIGFuIGluZGl2aWR1YWwsIEkgY2FuIGZpbmQgYSBsb3Qgb2YgZXhhbXBs ZXMgd2hlcmUgZG93bnN0cmVhbSBjb250ZW50IGFkYXB0YXRpb24gaXMgbm90IG5lZWRlZCwgYW5k IGFueSBhZGFwdGF0aW9uIGlzIHJlYWxseSBwYXJ0IG9mIHRoZSBDUCAtIHVDRE4gaW50ZXJmYWNl ICh3aGljaCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIG91ciBjaGFydGVyKS4NCg0KLS0gUmljaA0K DQoNCkZyb206IFpob3VaaGlwZW5nIFttYWlsdG86emhvdXpoaXBlbmdAaHVhd2VpLmNvbV0NClNl bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDExIDAzOjQ1IEFNDQpUbzogTWFyayBkZSBKb25n IDxtYXJrQGpldC1zdHJlYW0ubmw8bWFpbHRvOm1hcmtAamV0LXN0cmVhbS5ubD4+OyBBbGFuIEth dmFuYWdoIDxhbGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbTxtYWlsdG86YWxhbi5rYXZhbmFnaEBl cmljc3Nvbi5jb20+Pg0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+IDxj ZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbQ0ROaV0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KSGVsbG8gTWFy aywNCk5pY2UgdG8gbWVldCB5b3Ugb24gbGluZS4NCkluIHlvdXIgY29tcGFueeKAmXMgd2Vic2l0 ZSwgSSBqdXN0IGZpbmQgc29tZSBpbmZvcm1hdGlvbiB0aGF0IGFkZHJlc3NlcyDigJwgVm9kYWZv bmUgc3Vic2NyaWJlcnMgY29tcGxhaW5lZCBhYm91dCB2aWRlbyBwZXJmb3JtYW5jZS7igJ0NClNl ZToNCmh0dHA6Ly93d3cuamV0LXN0cmVhbS5ubC9zZWFyY2gvP3NlYXJjaD10cmFuc2NvZGluZw0K DQpEZWFyIGFsbCBpbiB0aGlzIGdyb3VwLA0KSW4gbGFzdCBmZXcgZGF5cywgZXhjZXB0IHRoZSBw dWJsaWMgZW1haWwgZGlzY3Vzc2lvbnMgSSBoYXZlIGNvbnRhY3RlZCB3aXRoIHNvbWUgcGVvcGxl IGFuZCBkaXNjdXNzZWQgd2l0aCBteSBvd24gY29sbGVhZ3VlcyBvZiBhbGwgZGV0YWlscyBvbiB0 aGlzIGlzc3VlLg0KRmlyc3QsIGFsdGhvdWdoIHRoZSBtYXJrZXQgcmVxdWlyZW1lbnQgZm9yIGl0 IGlzIHZlcnkgaW1wb3J0YW50LCBJIGZlZWwgSeKAmWQgYmV0dGVyIHNob3cgdXAgbW9yZSBpbmZv cm1hdGlvbiBvbiB0aGUgcHJvY2VkdXJlIGludm9sdmVkLiBJIGhhdmUgZXhwbGFpbmVkIG1hbnkg dGltZXMgdGhhdCB0byBzdXBwb3J0IGNvbnRlbnQgYWRhcHRhdGlvbiBpcyByYXRoZXIgc2ltcGxl IHdoaWxlIHRoZSB3b3JkaW5nIGlzIG5vdCBlbm91Z2guDQpJIGFtIGJ1c3kgbWFraW5nIHNvbWUg Y29udHJpYnV0aW9ucyBvbiB0aGlzIGFuZCBwbGFuIHRvIHVwbG9hZCB0byBFVFNJIG1lZXRpbmcg YW5kIElFVEYgQ0ROSS4NCkJ5IHRoZXNlIHdvcmsgIEkgZmVlbCB0aGUgcGVvcGxlIG1heSBjYXRj aCBhIHdob2xlIHZpZXcgb24gdGhpcyBpc3N1ZS4NClNlY29uZCwgZm9yIHRoYXQgZnVuY3Rpb25h bGl0eSwgaW4gaW1wbGVtZW50YXRpb24sIGlmIHNvbWUgZW50aXR5IGRvZXMgbm90IGNob29zZSB0 byBzdXBwb3J0IGl0LCBpdCBtYXkgYmUgb2suIFNpbmNlIGl0IG1heSBiZSBuZWdvdGlhdGVkIGJl dHdlZW4gIHR3byBDRE5zLg0KSWYgZENETiBkb2VzIG5vdCBzdXBwb3J0IHRoYXQsIGl0IG1heSBi ZSB0aGUgdUNETiByZXNwb25zaWJsZSB0byBjb21wbGV0ZSB0aGUgdHJhbnNjb2RpbmcgYW5kIGRl bGl2ZXIgdGhlIGNvbnRlbnQgb2YgbXVsdGlwbGUgZm9ybWF0cyBhbmQgcmF0ZXMgdG8gZENETi4N ClRoaXJkLCBhbHRob3VnaCBDRE5JIGlzIGEgbmV3IGFyY2hpdGVjdHVyZSwgd2hpbGUgdGhlIGNv bnRlbnQgb3BlcmF0aW5nIGhhcyBiZWVuIGV4aXN0ZWQgZm9yIHllYXJzLiBBcyBJIGtub3cgdGhl IGNvbnRlbnQgZnJvbSBVU0EgdG8gdGhlIGRvd25zdHJlYW0gb3BlcmF0b3IgaXMgdHJhbnNmZXJy ZWQgb24gb25lIGNvcHkgYW5kIHRoZSBkb3duc3RyZWFtIG9wZXJhdG9yIHdpbGwgaGFuZGxlIHRo ZSB0cmFuc2NvZGluZy4NCg0KUGVyaGFwcywgdGhlIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBtb3Jl IG9uIHRoZSBtb2JpbGUgb3BlcmF0aW5nLiBCdXQgSSBmZWVsIGN1cnJlbnRseSBtb3N0IG9wZXJh dG9yIHdpbGwgYmUgYSBhbGwgc2VydmljZSBvcGVyYXRvci4gQW5kIGZvciB0aGUgQ0ROIHByb3Zp ZGVycywgaXQgbWF5IGJlIGJldHRlciB0byBzdXBwb3J0IGFsbCBraW5kcyBvZiBzZXJ2aWNlLg0K QmVzaWRlcywgSSBsaWtlIHNheSB0aGF0IHRoZSB0ZWNobm9sb2d5IG9uIHRoaXMgdG9waWMgaGFz IGJlZW4gZm9yIG1hbnkgeWVhcnMgYW5kIGhhcyBiZWVuIHJhdGhlciBtYXR1cmUsIGV2ZW4gc29t ZSBpdGVtcyBpbiBpZXRmIHN1Y2ggYXMgcmZjMzUwNyAgaWNhcC4gU28gZnJvbSB0aGUgdGVjaG5p cXVlIHBvaW50IG9mIHZpZXcsIGl0IGlzIGEgbmF0dXJlIGFjdGlvbiB0byBiZSBpbnZvbHZlZCBp biBDRE4gaW50ZXJjb25uZWN0aW9uLg0KVGhhbmtzLg0KWmhpcGVuZw0KDQoNCg0KDQpGcm9tOiBN YXJrIGRlIEpvbmcgW21haWx0bzptYXJrQGpldC1zdHJlYW0ubmxdDQpTZW50OiBUaHVyc2RheSwg T2N0b2JlciAyNywgMjAxMSA0OjIxIEFNDQpUbzogQWxhbiBLYXZhbmFnaA0KQ2M6IEJlbiBOaXZl bi1KZW5raW5zOyBaaG91WmhpcGVuZzsgY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1j YXNlcy0wMC50eHQNCg0KSGkgQWxhbiwNCg0KQXMgQmVuIHN0YXRlZCB0aGUgb3ZlcmFsbCBkaXNj dXNzaW9uIHJpZ2h0IG5vdyBpcyBhYm91dCBkZWxpdmVyeSwgbm90IG9uIGFkYXB0YXRpb24uIEl0 IGlzIGhhcmQgZW5vdWdoIHRvIGdldCBjb25zZW5zdXMgb24gdGhlIGRlbGl2ZXJ5IGFzcGVjdCBh bHJlYWR5IG5vdCB0byBtZW50aW9uIHlvdXIgcmVxdWlyZW1lbnQgZnJvbSBjb250ZW50IGFkYXB0 YXRpb24gYWRkZWQgdG8gdGhhdCwgc28gSSBhZ3JlZSB3aXRoIEJlbiB3ZSBzaG91bGQgc3RpY2sg d2l0aCB0aGUgZGVsaXZlcnkgYXNwZWN0IGZvciB0aGUgZmlyc3Qgc3BlY3MuIEkgY2FuIGltYWdp bmUgdGhpcyBjb3VsZCBiZSBhIGRpc2N1c3Npb24gbGF0ZXIgb24gYnV0IHBsZWFzZSBsZXQgdXMg a2VlcCB0aGUgc2NvcGUgb2YgdGhpcyBiZSBjbGVhbiBhbmQgdHJhbnNwYXJlbnQuIEl0IGlzIG9m IGJlbmVmaXQgb2YgZXZlcnlvbmUgdG8gZ2V0IHRoZSBmaXJzdCBzcGVjcyBhcyBmYXN0IGFzIHBv c3NpYmxlLiBUaGFua3MuDQoNCk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQsDQpLaW5kIHJlZ2FyZHMs DQoNCk1hcmsgZGUgSm9uZw0KSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBEZXZlbG9wZXINCkpldC1T dHJlYW0gQlYNCg0KRS1tYWlsOiBtYXJrQGpldC1zdHJlYW0uY29tPG1haWx0bzptYXJrQGpldC1z dHJlYW0uY29tPg0KT2ZmaWNlOiArMzEgKDApNTAgNTI2MTgyMA0KTW9iaWxlOiArMzEgKDApNiA4 MTEwODI2Mw0KRmF4OiArMzEgKDApNTAgNTI2NDIxNA0KDQotIEV2ZW50OiBNZWV0IHVzIGF0IFN0 cmVhbWluZyBNZWRpYSBFdXJvcGUsIDE3LTE4IE9jdG9iZXIsIExvbmRvbiwgVUsNCi0gRXZlbnQ6 IE1lZXQgdXMgYXQgT25saW5lIFZpZGVvIFN0cmF0ZWdpZXMsIDE5IE9jdG9iZXIsIExvbmRvbiwg VUsNCi0gRXZlbnQ6IE1lZXQgdXMgYXQgQ0ROIFdvcmxkIFN1bW1pdCwgMjUtMjggT2N0b2Jlciwg TG9uZG9uLCBVSw0KLSBOZXdzOiBQcmUtcmVxdWVzdCB5b3VyIFRlY2hub2xvZ3kgV2hpdGVwYXBl ciBub3cgYW5kIGJlIHRoZSBmaXJzdCB0byBoYXZlIGl0LCBjaGVjayB3d3cuamV0LXN0cmVhbS5j b208aHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbT4NCi0gTmV3czogQ2hlY2sgaHR0cDovL3d3dy5q ZXQtc3RyZWFtLmNvbSB0byBkb3dubG9hZCBvdXIgJ1NpeCBUcmVuZHMgaW4gQ0ROcycgYnJvY2h1 cmUNCg0KLSBCbG9nOiB3d3cuamV0LXN0cmVhbS5jb20vYmxvZy88aHR0cDovL3d3dy5qZXQtc3Ry ZWFtLmNvbS9ibG9nLz4NCi0gVmlkZW9FeGNoYW5nZTogd3d3LnZkby14Lm5ldDxodHRwOi8vd3d3 LnZkby14Lm5ldD4NCi0gU3RyZWFtemlsbGE6IHd3dy5zdHJlYW16aWxsYWNkbi5jb208aHR0cDov L3d3dy5zdHJlYW16aWxsYWNkbi5jb20+DQotIENvcnBvcmF0ZTogd3d3LmpldC1zdHJlYW0uY29t PGh0dHA6Ly93d3cuamV0LXN0cmVhbS5jb20+DQoNCk9uIDI2LCBPY3QsMjAxMSwgYXQgODozMyBQ TSwgQWxhbiBLYXZhbmFnaCB3cm90ZToNCg0KQmVuDQoNCkltIGFzc3VtaW5nIHRoZW4gYmFzZWQg b24geW91ciBjb21tZW50cyBiZWxvdyBhcmUgeW91IHN1Z2dlc3Rpbmcgd2UgYXJlIGdvaW5nIHRv IGhhdmUgYSBudW1iZXIgb2YgdmVyc2lvbnMgb2YgdGhlIENETi1JIE1ldGFkYXRhPw0KDQpJIHN5 bXBhdGhpc2Ugd2l0aCB3aGF0IHlvdSBhcmUgcG9pbnRpbmcgb3V0IGJlbG93IGFuZCBkbyBhZ3Jl ZSB0aGF0IHRoZXJlIGlzIHNvbWUgd29yayB0byBiZSBkb25lLCBidXQgSSBzdGlsbCBmZWVsIHRo YXQgY29udGVudCBhZGFwdGF0aW9uIGlzIHRvIG1lIGEgZnVuZGFtZW50YWwgcmVxdWlyZW1lbnQg dG8gd2hhdCBjb2xsZWN0aXZlbHkgd2Ugc2hvdWxkIGFkZHJlc3MgaW4gdGhlIENETi1JIFdHLiBJ IGRvIGFncmVlIHdpdGggeW91IHRoYXQgY29udGVudCBhZGFwdGF0aW9uIGlzIGFuIG9wdGltaXph dGlvbiBiZXR3ZWVuIENETidzIGJ1dCBpdCdzIGEgdmVyeSBpbXBvcnRhbnQgb25lIHRoYXQgSSBr bm93IE5ldHdvcmsgU2VydmljZSBQcm92aWRlcnMgcGFydGljdWxhcmx5IHJlcXVpcmUuDQoNCkFs YW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNkbmktYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNkbmktYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbiBOaXZlbi1KZW5raW5zDQpTZW50OiBPY3RvYmVyLTEy LTExIDE6MTMgUE0NClRvOiBaaG91WmhpcGVuZw0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNk bmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Y2RuaS11c2UtY2FzZXMtMDAudHh0DQoNClpoaXBlbmcsDQoNCk9uIDEyIE9jdCAyMDExLCBhdCAx MDoyMiwgWmhvdVpoaXBlbmcgd3JvdGU6DQoNCg0KSGVsbG8gQmVuLA0KVGhlIFVFIG1heSBzZWxl Y3QgdGhlIGNvbnRlbnQgZm9ybWF0IG9uIHRoZSBDUCB3ZWIuIEFmdGVyIHRoYXQgdGhlIHVzZXIg b25seSBkZXNpcmVzIHRvIGdldCBoaXMgc2VsZWN0ZWQgY29udGVudC4NCkJ1dCBob3cgdGhlIGNv bnRlbnQgaXMgdHJhbnNmZXJyZWQgdG8gdGhlIGNsaWVudCBpcyBub3Qgd29ycmllZCBieSB0aGUg dXNlci4NClRoZSBDUCBtYXkgY3JlYXRlIGEgc3BlY2lhbCBmb3JtYXQgYXMgcmVxdWlyZWQgYnkg dGhlIHVzZXIgYW5kIGFzayB0aGUgQ0ROIHRvIGRlbGl2ZXIgdG8gdXNlci4NCldoaWxlIENQIG1h eSBnaXZlIGEgSEQgZm9ybWF0IGNvbnRlbnQgdG8gdUNETiBhbmQgdGhlIGRDRE4gbWF5IHRoZW4g dHJhbnNmb3JtIHRvIHRoZSBmb3JtYXQgYXMgdGhlIHVzZXIgc2VsZWN0Lg0KDQpMb3RzIG9mIHRo aW5ncyBtYXkgYmUgcG9zc2libGUgdG8gZG8gYW5kIENETiBwcm92aWRlcnMgb2ZmZXIgbWFueSBh ZGRpdGlvbmFsIHNlcnZpY2VzIG9uIHRvcCBvZiB0aGUgImNvcmUiIHNlcnZpY2Ugb2YgY29udGVu dCBkZWxpdmVyeS4gSG93ZXZlciwgb3VyIG9iamVjdGl2ZSAoYmFzZWQgb24gbXkgaW50ZXJwcmV0 YXRpb24gb2YgdGhlIENETkkgY2hhcnRlcikgaXMgdG8gZm9jdXMgb24gd2hhdCBpcyBuZWNlc3Nh cnkgdG8gaW50ZXJjb25uZWN0IENETnMgdG8gZGVsaXZlciBjb250ZW50IGZyb20gYSBDU1AgdG8g YW4gRW5kIFVzZXIgdGhhdCBpcyB0YXJnZXRlZCBhbmQgZGVwbG95YWJsZSB3aXRoaW4gYSBzaG9y dCB0aW1lIGZyYW1lICgxOC0yNCBtb250aHMpLg0KDQpDb250ZW50IHRyYW5zZm9ybWF0aW9uL2Fk YXB0YXRpb24gaXMgbm90IGFuIGVzc2VudGlhbCByZXF1aXJlbWVudCBpbiBvcmRlciB0byBhY2hp ZXZlIHRoYXQgYWltICh3ZSBjYW4gZGVsaXZlciBjb250ZW50IGZyb20gQ1NQcyB0byBFbmQgVXNl cnMgdmlhIG11bHRpcGxlIENETnMgd2l0aG91dCBuZWVkaW5nIG9yIHJlcXVpcmluZyBhbnkgQ0RO IHN1cHBvcnRzIGNvbnRlbnQgYWRhcHRhdGlvbikuDQoNCkluIG15IG9waW5pb24gd2UgaGF2ZSBl bm91Z2ggd29yayB0byBkbyBhbHJlYWR5IHdpdGhvdXQgdHJ5aW5nIHRvIGV4cGFuZCB0aGUgc2Nv cGUgb2Ygb3VyIHdvcmsgdG8gaW5jbHVkZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB0aGF0IGRv IG5vdCBoZWxwIHVzIGFkZHJlc3Mgb3VyIGNvcmUgb2JqZWN0aXZlcyBhcyBsYWlkIG91dCBpbiB0 aGUgQ0ROSSBjaGFydGVyLg0KDQoNCkluIHRoaXMgY2FzZSwgaXQgaXMgbm90aGluZyByZWxhdGVk IHRvIGhvdyB0aGUgdXNlciBzZWxlY3QgZm9ybWF0cyBvbiBDUCB3ZWJzaXRlLg0KU28sIGl0IGlz IHRoZSBDUCBhbmQgdXNlciB0byBkZWNpZGUgdGhlIGNvbnRlbnQgZm9ybWF0IG5vdCB0aGUgQ0RO KHlvdXIgYXNzZXJ0IGlzIG5vdCBjb3JyZWN0IGFuZCBzZWVtcyB5b3UgdGFrZSB0aGF0IGFzc2Vy dCBhcyB5b3VyIGJhc2UgZm9yIHRoZSBkaXNjdXNzaW9uKS4NCg0KQXMgZm9yICJ0aGUgY29yZSBD RE4gZnVuY3Rpb25hbGl0eSBvZmZlcmVkIGJ5IENETnMgdG9kYXkiLCBJIGhhdmUgZXZlciByYWlz ZWQgYW4gZW1haWwgYmVmb3JlIHRoYXQgeW91ciBjb21wYW55J3Mgd2VicGFnZSBoYXMgY2xhaW1l ZCBzdXBwb3J0aW5nIG1lZGlhIHRyYW5zZm9ybWF0aW9uIGFuZCBtdWx0aS1zY3JlZW4gc2Vydmlj ZS4NClBlcmhhcHMsIEkgbGlrZSBhc2tpbmcgeW91IGxpc3Qgc29tZSBmZWF0dXJlcyB0aGF0IHlv dSBmZWVsIGFyZSB0aGUgY29yZSBmdW5jdGlvbmFsaXRpZXMgYnkgZXhpc3RpbmcgbWFpbiBzdHJl YW0gQ0ROcy4gVGh1cyB3ZSBtYXkgY29tcGFyZSBhbmQgdGFrZSBkZWVwIGxvb2suDQoNCkkgdGhp bmsgdGhlIGNvcmUgZnVuY3Rpb25hbGl0eSBtYXBzIHByZXR0eSB3ZWxsIHRvIHRoZSBDRE5JIGlu dGVyZmFjZXMsIG5hbWVseTogUmVxdWVzdCBSb3V0aW5nLCBNZXRhZGF0YSBjb25maWd1cmF0aW9u LCBsb2cgcHJvZHVjdGlvbiBhbmQgY29udHJvbCBwbHVzIGNvbnRlbnQgYWNxdWlzaXRpb24gYW5k IGNvbnRlbnQgZGVsaXZlcnkuDQoNCg0KSSBndWVzcyBtYW55IHBlb3BsZSBoYXZlIHRoZSBleHBl cmllbmNlL2tub3dsZWRnZSBvZiBjb250ZW50IHJlbGF0ZWQgc2VydmljZS4gVGhlIHVzZXIgYW5k IENQIG9ubHkgY2FyZSB3aGV0aGVyIHRoZSBDRE4gcHJvdmlkZXJzIG1heSBzYXRpc2Z5IHRoZWly IHJlcXVpcmVtZW50IHdoaWxlIG5vdCBjYXJlIHRoZSBpbnRlcm5hbCBwcm9jZXNzLiBKdXN0IGFz IEdTTS9QU1ROIGludGVyY29ubmVjdGlvbiwgdGhlIHVzZXIgb25seSBjYXJlIHN1Y2Nlc3NmdWwg aW50ZXJjb25uZWN0aW9uIHdoaWxlIG5vdCBjYXJlIGhvdyB0aGUgdm9pY2UgaXMgdHJhbnNmb3Jt ZWQgaW4gcHJvY2Vzcy4NCg0KQmVzaWRlcywgSSBsaWtlIHJhaXNlIGEgY2FzZToNCkdpdmVuIGN1 cnJlbnRseSBCQkMgcmVjcnVpdHMgQ0ROIHByb3ZpZGVycyB0aGF0IG1heSBzdXBwb3J0IDEwIG1l ZGlhIGZvcm1hdHMuDQpPbmUgY2FuZGlkYXRlIGlzIHlvdXIgY29tcGFueSwgYW5vdGhlciBpcyBD RE4tWC4gVGhlIHVzZXJzIGFyZSBsb2NhdGVkIGluIEZyYW5jZS4NClNvIGJvdGggeW91ciBjb21w YW55IGFuZCBDRE4tWCBzaG91bGQgY29ubmVjdCBhIEZyYW5jZSBDRE4gcHJvdmlkZXIoQ0ROLVkp Lg0KSWYgeW91ciBjb21wYW55J3Mgc29sdXRpb24gaXMgdG8gc2VuZCAxMCBzdHJlYW1zIG9mIGRp ZmZlcmVudCBmb3JtYXQNCm9mIG9uZSBjb250ZW50IHRvIENETi1ZOyBXaGlsZSBDRE4tWCdzIHNv bHV0aW9uIGlzIHRvIHNlbmQgMSBzdHJlYW0gdG8gQ0ROLVkgd2hpbGUgQ0ROLVkgbWF5IGNvbmR1 Y3Qgc29tZSBhZGFwdGF0aW9uLg0KQ29tcGFyaW5nIHRoZXNlIHR3byBzb2x1dGlvbnMsIGZvciB5 b3VyIGNvbXBhbnkgYW5kIENETi1YLCBhYnNvbHV0ZWx5IHRoZSBjb3N0IG9mIENETi1YIGlzIG11 Y2ggbG93ZXIuDQpGb3IgQ0ROLVksIGluIHNvbHV0aW9uLTEsIGl0IHNob3VsZCByZWNlaXZlL2Zv cndhcmQgMTAgc3RyZWFtcyA7IHdoaWxlIGluIHNvbHV0aW9uLTIsIGl0IHNob3VsZCBvbmx5IHJl Y2VpdmUgMSBzdHJlYW0gYnV0IG5lZWQgdG8gdGFrZSB0cmFuc2Zvcm1hdGlvbiB0byBvdXRwdXQg MTAgc3RyZWFtcy4NCg0KV2hpY2ggc29sdXRpb24gaXMgbW9yZSBjb21wZXRpdGl2ZS4gaXQgaXMg U29sdXRpb24gMSwgcmlnaHQuIFJlbWVtYmVyIHRoZSBwcmljZSBmcm9tIEJCQyBpcyBzYW1lIHRv IGJvdGggeW91ciBjb21wYW55IGFuZCBDRE4tWCBvciBCQkMgd291bGQgc2VsZWN0IG9uZSBDRE4g cHJvdmlkZXIgd2l0aCB0aGUgbG93ZXIgcHJpY2UuDQpJZiBhIENETiBwcm92aWRlciBtYXkgbm90 IGdldCB0aGUgY29udHJhY3QgZnJvbSBDUCwgaG93IGl0IG1heSBzYXkgaXQgaXMgbm90IGEgY29y ZSBmdW5jdGlvbmFsaXR5Lg0KDQpXaGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyBhIHBvc3NpYmxl IG9wdGltaXphdGlvbiB0aGF0IGEgcGFydGljdWxhciBDRE4gbWF5IHdpc2ggdG8gaW1wbGVtZW50 IG5vdCBhIGNvcmUgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCB0byBlbmFibGUgY29udGVudCBkZWxp dmVyeSBiZXR3ZWVuIGludGVyY29ubmVjdGVkIENETnMuIEkgY2FuIHRoaW5rIG9mIG1hbnkgb3B0 aW1pemF0aW9ucyB0aGF0IGEgQ0ROIGNvdWxkIGltcGxlbWVudCB0byBkaWZmZXJlbnRpYXRlIHRo ZWlyIHNlcnZpY2UgYnV0IHRoZSBpbnRlcm5hbCB3b3JraW5ncyBvZiBhbiBpbmRpdmlkdWFsIENE TiBhcmUgb3V0IG9mIHNjb3BlIG9mIG91ciBjaGFydGVyLg0KDQpTbyB0byByZXBlYXQgbXkgcG9z aXRpb24gZm9yIGEgZmluYWwgdGltZTogQ29udGVudCBhZGFwdGF0aW9uIGlzIG5vdCBhIGNvcmUg ZnVuY3Rpb24gcmVxdWlyZWQgdG8gZW5hYmxlIGNvbnRlbnQgZGVsaXZlcnkgYmV0d2VlbiBpbnRl cmNvbm5lY3RlZCBDRE5zIGFuZCB0aGVyZWZvcmUgZ2l2ZW4gdGhlIHdvcmtsb2FkIHdlIGFscmVh ZHkgaGF2ZSB0byBzcGVjaWZ5IHNvbHV0aW9ucyB0aGF0IGRvIGFkZHJlc3MgdGhlIGNvcmUgZnVu Y3Rpb25hbGl0eSByZXF1aXJlZCB0byBpbnRlcmNvbm5lY3QgQ0ROcyBJIGRvIG5vdCB0aGluayB3 ZSBzaG91bGQgYmUgdHJ5aW5nIHRvIGFkZCBtb3JlIHdvcmsgaW50byB0aGF0IHdvcmtsb2FkIGFz IGl0IHdpbGwgb25seSBkaXN0cmFjdCB1cyBmcm9tIGFjaGlldmluZyBvdXIgZ29hbCBvZiBwcm9k dWNpbmcgZGVwbG95YWJsZSBzb2x1dGlvbnMgd2l0aGluIHRoZSB0aW1lZnJhbWUgd2UgYXJlIGJl aW5nIHRvbGQgYnkgb3BlcmF0b3JzIHRoZXkgbmVlZHMgc29sdXRpb25zIHdpdGhpbi4NCg0KQmVu DQoNCg0KU28sIGlmIHdlIGFsbCByZWFsaXplIHRoYXQgY3VycmVudGx5IHRoZSBtZWRpYSB0eXBl IGlzIHJpY2gsIHRoZSBDRE4gcHJvdmlkZXJzIHNob3VsZCBzdXJ2aXZlIGluIHRoZSBleGlzdGlu ZyBlY29zeXN0ZW0gYW5kIHN1cHBvcnQgdGhlIG1lZGlhIHR5cGVzIGFzIHJlcXVpcmVkIGJ5IHRo ZSBtYXJrZXQuDQoNCkJhY2sgdG8gdGhlIGNhc2Ugb2YgR1NNL0cuNzExLCBpdCBqdXN0IHdoZW4g Y29uY2VybmluZyB0aGUgaW50ZXJjb25uZWN0aW9uLCB0aGUgdHJhbnNmb3JtYXRpb24gc2hvdWxk IGF0IG9uY2UgYmUgc29sdmVkLiBPdGhlcndpc2UgdGhlIGludGVyY29ubmVjdGlvbiBtYXkgbm90 IGJlIG9wZXJhdGVkLg0KDQpCciwNClpoaXBlbmcNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IEJlbiBOaXZlbi1KZW5raW5zIFttYWlsdG86YmVuQG5pdmVuLWplbmtp bnMuY28udWtdDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIwMTEgMTI6MTkgQU0NClRv OiBaaG91WmhpcGVuZw0KQ2M6IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxtYWlsdG86cGhpbGlwLmVh cmRsZXlAYnQuY29tPjsgY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50 eHQNCg0KWmhpcGVuZywNCg0KT24gMTEgT2N0IDIwMTEsIGF0IDA1OjE2LCBaaG91WmhpcGVuZyB3 cm90ZToNCg0KQmVuIGFuZCBQaGlsaXAsDQpJIGxpa2UgdG8gcmVzcG9uZCB5b3VyIGNvbmNlcm4g aW4gdGhpcyBvbmUgZW1haWw6DQoNCkJlbiwNCkkgZmVlbCB3aGF0IHdlIGFyZSBub3cgZGlzY3Vz c2luZyBpcyB3aGF0IGlzIHRoZSAiY29yZSIgZnVuY3Rpb24gb2YgQ0ROLg0KQXMgeW91IHNheSwg Q0ROIGlzIHVzZWQgdG8gZGVsaXZlciBjb250ZW50LiBUaGF0IGlzIGFic29sdXRlbHkgY29ycmVj dCB0aGF0IHRoZSBkZWxpdmVyeSBjYXBhYmlsaXR5IGlzIHRoZSBjb3JlIHJlcXVpcmVtZW50IGZv ciBDRE4gc3lzdGVtLg0KV2hpbGUgQ0ROIGlzIHVzZWQgdG8gcHJvdmlkZSB0aGUgY29udGVudCBk ZWxpdmVyeSBzZXJ2aWNlLg0KV2hhdCBtZWFucyBzZXJ2aWNlLiBJdCBzaG91bGQgaW5jbHVkZSAi dGltZSIgImxvY2F0aW9uIiBhbmQgIm1lZGlhIHR5cGUiLCBldGMuIFRoZXNlIGZlYXR1cmVzIGFy ZSBhbGwgdGhlIGNvcmUgZmVhdHVyZSBmb3IgYSBzZXJ2aWNlLg0KSWYgd2Ugb25seSBjb25jZXJu ICJkZWxpdmVyaW5nIG9uZSBkYXRhIGJsb2NrIiwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSBp c3N1ZXMgc3VjaCBhcyAibG9nZ2luZyIgImdlb2dyYXBoaWMgY29uc3RyYWludCIgYXJlIHRoZSBj b3JlIG9mIENETi4NCg0KRm9yICJ3aXRob3V0IGV4cGxpY2l0IGtub3dsZWRnZSBvZiB3aGF0IHRo YXQgY29udGVudCBhY3R1YWxseSBpcyAiLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIHdvcmRp bmcgaXMgYWNjdXJhdGUgc2luY2UgZ2VuZXJhbGx5IGEgQ0ROIG1heSBjbGFpbSBpdCBzdXBwb3J0 IGRpZmZlcmVudCBtZWRpYXMuDQpCeSB0aGlzIG9wcG9ydHVuaXR5LCBJIGxpa2UgdG8gc2hhcmUg YSB1c2UgY2FzZTogYSBjYWxsIGZyb20gYSBHU00gcGhvbmUgdG8gYSBQU1ROIHRlbGVwaG9uZSwg dGhlIHZvaWNlIHN0cmVhbSBzaG91bGQgYmUgdHJhbnNmb3JtZWQgZnJvbSBHU00gdm9pY2UgdG8g Ry43MTEuDQpGb3IgdGhlIHVzZXIsIGhlIGRvZXMgbm90IG5lZWQgdG8ga25vdyB3aGF0IHR5cGUg b2YgZGF0YSBoYXMgYmVlbiB0cmFuc2ZlcnJlZCwgYnV0IHRoZSBvcGVyYXRvciBoYXMgZG9uZSBz b21lIHdvcmsgdG8gaW50ZXJjb25uZWN0IHR3byBzeXN0ZW1zLCByaWdodC4NCkkgbGlrZSB0byBr bm93IHdoZXRoZXIgeW91IG1heSBhY2NlcHQgdGhhdCBteSB1c2UgY2FzZSBpcyBzaW1pbGFyIHRv IHRoaXMgY2FzZSBhYm92ZS4NCg0KSSBkb24ndCB0aGluayB5b3VyIHVzZSBjYXNlIGlzIHNpbWls YXIgdG8gdGhlIGFuYWxvZ3kgb2YgbW9iaWxlIG5ldHdvcmtzIGJlaW5nIGludGVyY29ubmVjdGVk IHRvIFBTVE4gbmV0d29ya3MuIEluIHRoZSBjYXNlIG9mIGNvbnRlbnQgZGVsaXZlcnkgdGhlIG5l Z290aWF0aW9uIGlzIGRvbmUgYmV0d2VlbiB0aGUgVXNlci9DbGllbnQgYW5kIHRoZSBDb250ZW50 IFByb3ZpZGVyIGFuZCB0aGUgQ0ROIGlzIGp1c3QgdXNlZCB0byBleGVjdXRlL3BlcmZvcm0gdGhl IGRlbGl2ZXJ5IHRoYXQgaGFzIGJlZW4gbmVnb3RpYXRlZC4gVGhlIENETiBpcyBub3QgaW52b2x2 ZWQgaW4gdGhlIGRlY2lzaW9uIG1ha2luZyBvZiB3aGF0IHJlcHJlc2VudGF0aW9ucyB0aGUgQ29u dGVudCBQcm92aWRlciBkZWNpZGVzIHRvIG9mZmVyIHRvIHRoZSBVc2VyL0NsaWVudCBvciBpbiB3 aGF0IHJlcHJlc2VudGF0aW9ucyB0aGUgVXNlci9DbGllbnQgZGVjaWRlcyB0byByZXF1ZXN0Lg0K DQpBcyBmb3IgeW91IHNhaWQgc2VsZWN0aW5nIG1lZGlhIGJ5IHRoZSAicG9ydGFsIiwgeW91IG1h eSBzZWUgdGhlIHdheSAiIHVDRE4gZGVsaXZlcnMgbXVsdGlwbGUgbWVkaWEgc3RyZWFtcyB0byBk Q0ROIiBpcyBub3QgZ29vZCB0aGFuICJ1Q0ROIGRlbGl2ZXJzIG9uZSBtZWRpYSBzdHJlYW0gdG8g ZENETiBhbmQgZENETiB0YWtlcyBzb21lIGFkYXB0YXRpb24gdG8gc3VwcG9ydCBtdWx0aXBsZSBt ZWRpYSB0eXBlcyIuDQoNCk5vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0IGlzIGFuIG9wdGlt aXNhdGlvbiwgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBhY3R1YWxseSBkZWxpdmVy IHRoZSBjb250ZW50IChhbmQgcmVwb3J0LCBiaWxsLCBldGMuIGZvciB0aGF0IGRlbGl2ZXJ5KS4N Cg0KTXkgcG9zaXRpb24gaXMgdGhhdCB3ZSBzaG91bGQgZm9jdXMgb24gaG93IHRvIGVuYWJsZSB0 aGUgaW50ZXJjb25uZWN0aW9uIG9mIHRoZSBjb3JlIENETiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQg YnkgQ0ROcyB0b2RheSAod2hpY2ggaXMgYWxzbyBteSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgc2Nv cGUgb2YgdGhlIENETkkgd29ya2luZyBncm91cCBhcyBleHByZXNzZWQgaW4gaXRzIGNoYXJ0ZXIp IGJlY2F1c2UgZG9pbmcgc28gaXMgYSBzaWduaWZpY2FudCBwaWVjZSBvZiB3b3JrIGluIGl0c2Vs Zi4gTGV0J3Mgbm90IHN0YXJ0IHRyeWluZyB0byBhZGQgaW4gYWRkaXRpb25hbCBmdW5jdGlvbmFs aXR5IGJleW9uZCB3aGF0IHRoZSBtYWpvcml0eSBvZiBDRE5zIHN1cHBvcnQgdG9kYXkgYXMgdGhh dCB3aWxsIGp1c3QgZGVsYXkgdXMgZ2V0dGluZyB1c2FibGUgc3BlY2lmaWNhdGlvbnMgaW50byB0 aGUgbWFya2V0IGluIGEgdGltZWx5IGZhc2hpb24gSU1PLg0KDQpCZW4NCg0KQSBnb29kIHF1ZXN0 aW9uIGlzICJzZWN1cml0eSIgc2luY2UgSSBoYXZlIGRvbmUgc2l4IHllYXJzIG9uIHRoZSBEUk0N CmFuZCBsaWtlIHRvIHByb21vdGUgdGhlIERSTSBhbGwgYXJvdW5kIHRoZSB3b3JsZDopIElmIHRo ZSBjb250ZW50IGlzIG5lZWRlZCB0byBiZSBwcm90ZWN0ZWQsIGdlbmVyYWxseSB5b3UgbWF5IGtu b3cgYWxsIHRoZSBzeXN0ZW1zIHNob3VsZCBiZSBncmFudGVkIGJ5IHRoZSBjb250ZW50IG93bmVy Lg0KSGVyZSBJIGFsc28gbGlrZSB0byBjbGFyaWZ5IHRoYXQgbm90IG9ubHkgdGhlIG1lZGlhIGl0 c2VsZiBidXQgdGhlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gc2VydmljZSBpdHNlbGYgKHN1Y2gg YXMgdGhlIGdlb2dyYXBoaWMgY29uc3RyYWludCkgc2hvdWxkIGJlIHByb3RlY3RlZCBhbHNvLg0K U28sIHRydXN0IGlzIG5vdCBhIHByb2JsZW0gZm9yIHRoZSBtZWRpYS4NCg0KUGhpbGlwLA0KVGhh bmsgeW91IHRoYXQgeW91IGZlZWwgQ29udGVudCBBZGFwdGlvbiBpcyBhbiBpc3N1ZSBmb3IgIlJl cXVpcmVtZW50cyIgYnV0IEkgZG8gbm90IGtub3cgd2h5IGl0IGlzIG5vdCBmb3IgVXNlIGNhc2Uu DQpJIGxpa2UgdG8gY2xhcmlmeSB0byBVIHRoYXQgaXQgaXMgaW1wb3J0YW50IGZvciB5b3Ugb3Bl cmF0b3Igc2luY2UgaXQgbWF5IHNhdmUgaW52ZXN0bWVudCBpZiB0aGUgc3lzdGVtIG1heSBzdXBw b3J0IGRpZmZlcmVudCBzZXJ2aWNlcy4NCkZvciB1cyB2ZW5kb3IsIHdlIGFyZSBoYXBweSBvcGVy YXRvciBtYXkgaW5zdGFsbCBhIHN5c3RlbSBmb3IgdGhlIG1vYmlsZSBzZXJ2aWNlIGFuZCBhbm90 aGVyIHN5c3RlbSBmb3IgdGhlIEZCQiBzZXJ2aWNlLg0KQnV0IHRoZSByZWFsaXR5IGlzIGFsbCBv cGVyYXRvcnMgYXNrIHVzIHRvIHByb3ZpZGUgYSBzeXN0ZW0gdGhhdCBtYXkgc3VwcG9ydCBkaWZm ZXJlbnQgc2VydmljZSBzeXN0ZW1zLg0KDQpGcmFua2x5LCBCZW4gYW5kIFBoaWxpcCwgSSByZW1l bWJlciBJIGhhdmUgZXhwbGFpbmVkIHNvbWV3aGVyZSB0aGF0IHRvIGltcGxlbWVudCB0aGlzIGlz IHJhdGhlciBzaW1wbGUgLg0KQXQgbGVhc3QgdGhlIFVzZSBjYXNlIGFuZCBSZXF1aXJlbWVudCBh cmUgaW5mb3JtYXRpb25hbCB0byBiZSByZWZlcnJlZCBpbiBmdXR1cmUgd29yay4gU28gSSBkbyBy ZWFsbHkgZmVlbCB5b3UgbWF5IGFjY2VwdCBpdC4NCk9mIGNvdXJzZSBJIGxpa2UgdG8gcmVzcG9u ZCB5b3VyIG1vcmUgY29uY2VybiBhbmQgY29tbWVudHMuDQpUaGFua3MuDQpaaGlwZW5nDQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGhpbGlwLmVhcmRsZXlAYnQuY29t PG1haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20+IFttYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQu Y29tXQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDEwLCAyMDExIDExOjIyIFBNDQpUbzogYmVuQG5p dmVuLWplbmtpbnMuY28udWs8bWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPjsgWmhvdVpo aXBlbmcNCkNjOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0KU3ViamVjdDog UkU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0K DQpCZW4sIFpoaXBlbmcsIGFsbCwNCg0KSSB0aGluayB0aGF0IENvbnRlbnQgQWRhcHRhdGlvbiBp cyBtb3JlIGFuIGlzc3VlIGZvciB0aGUgUmVxdWlyZW1lbnRzIGRvYyB0aGFuIGZvciB0aGUgVXNl IGNhc2VzIGRyYWZ0Lg0KDQpUaGUga2V5IHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ugd2FudCB0aGUg Q0ROSSBpbnRlcmZhY2VzIHRvIGJlIGFibGUgdG8gY29wZSB3aXRoIGEgc2NlbmFyaW8gd2hlcmUg KHNheSkgSEQvU0QgY29udmVyc2lvbiBpcyBkb25lIGluIHRoZSBkQ0ROICYgdG8gc2lnbmFsIGFi b3V0IHRoaXMuDQoNCkkgdGhpbmsgdGhhdCBjb3Bpbmcgd2l0aCB0aGlzIHNjZW5hcmlvIGlzIGEg c2Vjb25kIG9yZGVyIHJlcXVpcmVtZW50LCBpZSB3ZSBzaG91bGQgbm90IHdvcnJ5IGFib3V0IGl0 IGluIHRoZSBpbml0aWFsIHN0YW5kYXJkcy10cmFjayB3b3JrLiBJIGRvbid0IGtub3csIGRpZCB3 ZSBldmVyIGRlY2lkZSB3aGV0aGVyIHRoZSBVc2UgY2FzZXMgZG9jIGlzIHJlc3RyaWN0ZWQgdG8g ImluaXRpYWwiIHNjZW5hcmlvcywgb3Igd2hldGhlciBpdCdzIGFsbC1lbmNvbXBhc3NpbmcsIGll IGNvdmVyaW5nICJmdXR1cmUiIHNjZW5hcmlvcyBhcyB3ZWxsPw0KDQpTY290dCwNClJlYWRpbmcg c29tZSBvZiB5b3VyIGV4YW1wbGVzLCB0aGV5IHNlZW0gdG8gYmUgdmFsaWQgZXZlbiBpZiBjb250 ZW50IGFkYXB0YXRpb24gKEhEL1NEKSBpcyBvdXQgb2Ygc2NvcGUuDQotIGEgZENETiBtaWdodCBm b3Igc29tZSByZWFzb24gYmUgdW53aWxsaW5nIHRvIGRpc3RyaWJ1dGUgSEQ/DQotIGEgQ1NQIG1p Z2h0IHdhbnQgdG8gbWFrZSBzdXJlIHRoZSBkQ0ROIGNhbiB1c2UgSExTIGVuY2Fwc3VsYXRpb24/ DQpCdXQgdGhlc2Ugc29ydHMgb2YgZXhhbXBsZXMgc2VlbSB0byBiZSBzdGF0aWMgcG9saWN5IHRo aW5ncyAodG8gZG8NCndpdGggdGhlIGNhcGFiaWxpdGllcyAmIHByZWZlcmVuY2VzIG9mIHRoZSBD RE5zICYgQ1NQKSwgcmF0aGVyIHRoYW4NCm1ldGFkYXRhIGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRp Y3VsYXIgcGllY2Ugb2YgY29udGVudC4gSW4gdGhlDQpkaXNjdXNzaW9uIHNvIGZhciwgSSB0aGlu ayBuZWdvdGlhdGlvbiBhYm91dCBzdGF0aWMgcG9saWN5IHN0dWZmIGlzDQpyYXRoZXIgb3V0IG9m IHNjb3BlKD8pDQoNCk9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbiBpbnRlcmVzdGluZyBx dWVzdGlvbiBpcyB3aGV0aGVyIHRydXN0IGlzIHRyYW5zaXRpdmUuIERvbid0IHRoaW5rIGl0IG5l ZWQgYmUgLSBqdXN0IGJlY2F1c2UgQ1NQIHRydXN0cyB1Q0ROLCBhbmQgdUNETiB0cnVzdHMgZENE TiBkb2Vzbid0IG1lYW4gdGhhdCB0aGUgQ1NQIGF1dG9tYXRpY2FsbHkgdHJ1c3RzIHRoZSBkQ0RO LiBIb3dldmVyLCBpIHN1c3BlY3QgdGhpcyBjYW4gZ2V0IGFyYml0cmFyaWx5IGNvbXBsZXggLSBz byBvbmUgcG9zc2liaWxpdHkgaXMgdG8gc2F5IHRoYXQgd2Ugd2lsbCBvbmx5IGhhbmRsZSBjYXNl cyB3aGVyZSB0aGUgdHJ1c3QgaXMgdHJhbnNpdGl2ZS4NCg0KQmVzdCB3aXNoZXMNCnBoaWwNCg0K DQpQaGlsaXAgRWFyZGxleQ0KUmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgU3RyYXRlZ3kNCg0KVGhp cyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQg b3IgY29uZmlkZW50aWFsLiBJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9y IGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91J3JlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBub3RlIHRoYXQgZGlzY2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5nIG9yIHVzaW5nIHRo aXMgaW5mb3JtYXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVseSBvbiB0aGUgZW1haWwg YWRkcmVzcyBhYm92ZS4gVGhhbmsgeW91LiBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFu ZCBtYXkgcmVjb3JkIHlvdXIgZW1haWxzLg0KQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxj DQpSZWdpc3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKIFJl Z2lzdGVyZWQgaW4NCkVuZ2xhbmQgbm86IDE4MDAwMDANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogY2RuaS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjZG5pLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCk9mIEJl biBOaXZlbi1KZW5raW5zDQpTZW50OiAxMCBPY3RvYmVyIDIwMTEgMTI6MDQNClRvOiBaaG91Wmhp cGVuZw0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0DQoN CkNvbGxlYWd1ZXMsDQoNCklNTyBTZWN0aW9uIDUuMS4zIHNob3VsZCBiZSByZW1vdmVkIGZyb20g dGhlIFVzZSBDYXNlcyBkcmFmdC4gQ29udGVudCBBZGFwdGF0aW9uIChpLmUuIHRha2luZyBpbiBh IGNvbnRlbnQgaXRlbSBpbiBvbmUgZm9ybWF0IGFuZCB0cmFuc2Zvcm1pbmcgaXQgdG8gYW5vdGhl ciBmb3JtYXQgb3IgcmVwcmVzZW50YXRpb24pIGlzIG5vdCBhICJjb3JlIiBmdW5jdGlvbiBvZiBh IENETiB3aGljaCB0eXBpY2FsbHkgZGVsaXZlcnMgdGhlIGNvbnRlbnQgdGhhdCBpcyByZXF1ZXN0 ZWQgd2l0aG91dCBleHBsaWNpdCBrbm93bGVkZ2Ugb2Ygd2hhdCB0aGF0IGNvbnRlbnQgYWN0dWFs bHkgaXMuDQoNCkxldCdzIG5vdCBmb3JnZXQgdGhhdCBpbiBidWlsZGluZyBhbiBlbmQgdG8gZW5k IGNvbnRlbnQgc2VydmljZSB0aGUgQ0ROIGlzIG9ubHkgb25lIGNvbXBvbmVudCBhbmQgaXMgdGhl IGNvbXBvbmVudCB0YXNrZWQgd2l0aCBleGVjdXRpbmcgdGhlIGRlbGl2ZXJ5IG9mIGEgc3BlY2lm aWMgcmVwcmVzZW50YXRpb24gKHZlcnNpb24vY29weS9mb3JtYXQgZXRjLikgb2YgdGhlIHNlbGVj dGVkIGNvbnRlbnQgbm90IHRoZSBjb21wb25lbnQgdGFza2VkIHdpdGggZGVjaWRpbmcgKG9yIGFw cGx5aW5nIHBvbGljeSkgb24gd2hpY2ggdmVyc2lvbi9jb3B5L3JlcHJlc2VudGF0aW9uIG9mIGNv bnRlbnQgc2hvdWxkIGJlIGRlbGl2ZXJlZC4NCg0KVGhlIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHZl cnNpb24vY29weS9yZXByZXNlbnRhdGlvbiB0byBvZmZlciBhbmQgYWxsb3cgdG8gYmUgZGVsaXZl cmVkIHRvIGEgZ2l2ZW4gZGV2aWNlL3VzZXIgaXMgaW1wbGVtZW50ZWQgb3V0c2lkZSBvZiB0aGUg Q0ROIChlLmcuIGJ5IHRoZSAicG9ydGFsIiB3aGVyZSB0aGUgdXNlciBmaXJzdCBtYWtlcyB0aGVp ciBjb250ZW50IHNlbGVjdGlvbiBwcmlvciB0byB0aGUgQ0ROIGJlY29taW5nIGludm9sdmVkIGlu IHRoZSBkZWxpdmVyeSBvZiB0aGUgc2VsZWN0ZWQgY29udGVudCkuDQoNCkJlbg0KDQpPbiA4IE9j dCAyMDExLCBhdCAwODoyMCwgWmhvdVpoaXBlbmcgd3JvdGU6DQoNCkZvbGxvd2luZyBTY290dCdz IGNvbW1lbnRzIG9uIHNlY3Rpb24gNS4xLjMsIEkgZmVlbCBTY290dCdzIGRlc2NyaXB0aW9uIG9u IHRoZSB1c2UgY2FzZSBvZiBIRCBhbmQgU0QgaXMgbm90IGV4YWN0bHkgY29ycmVjdC4NCklmIG9u ZSBtb3ZpZSBoYXMgdHdvIGZvcm1hdHMgb2YgSEQgYW5kIFNELCB0aGVuIHdlIGhhdmUgdHdvIGNv bnRlbnQgd2l0aCBkaWZmZXJlbnQgaWRlbnRpZmllci4gSW4gRFJNIHNjb3BlLCB0aGUgYmFzaWMg dW5pdCBpcyBhIGNvbnRlbnQgY29weS4NCg0KSGVyZSB0aGUgZmlyc3QgYnVsbGV0ICJhIHN1YnNl dCBvZiBlbmNvZGluZ3MgZGVsaXZlcmFibGUgdG8gc3BlY2lmaWMgZGV2aWNlcywiIGhhcyBsaXN0 ZWQgdGhlIGNhc2Ugb2YgY29udGVudCBhZGFwdGF0aW9uLg0KSW4gbGFzdCBtb250aCwgSSBoYXZl IGNvbnRhY3RlZCB0aGUgQXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50IGFuZCB0YWtlbiBzb21lIGVt YWlsIGV4Y2hhbmdlcyB3aXRoIEdyYW50IGFuZCBQaGlsaXAgKEJUKS4NCkkgaGF2ZSBzaG93biBC VCB3aXRoIHNvbWUgaW5mb3JtYXRpb24gdGhhdCBJIGtub3cgaW4gdGhpcyBjYXNlIGFuZCBhcmVh IHRvIGV4cGxhaW4gdGhlIGNvbnRlbnQgZmxleGliaWxpdHkgaXMgY3VycmVudGx5IGEgYmFzaWMg cmVxdWlyZW1lbnQgZm9yIENETiBzZXJ2aWNlIGFuZCByZWxhdGVkIG5lZ290aWF0aW9uIGlzIG5l ZWRlZCBpbiB0aGUgQ0ROIGludGVyY29ubmVjdGlvbi4NCk1lYW53aGlsZSwgSSBzaG91bGQgYWxz byBpbnZpdGUgeW91IGluIHRoaXMgZ3JvdXAgcmFpc2luZyB5b3VyIGNvbW1lbnRzIG9yIHF1ZXN0 aW9ucyBvbiB0aGlzIGNhc2Ugc2luY2UgSSBob3BlIG15IHVzZSBjYXNlIG1heSBiZSBpbmNvcnBv cmF0ZWQgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0Lg0KDQpJZiB5b3UgaGF2ZSBhbnkgbW9yZSBxdWVz dGlvbiBvciBjb21tZW50cywgcGxzIHNoYXJlIGluIHRoaXMgdGhyZWFkLg0KVGhhbmtzLg0KWmhp cGVuZw0KDQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNjb3R0 IFdhaW5uZXIgW21haWx0bzpzd2Fpbm5lckBjaXNjby5jb21dDQpTZW50OiBGcmlkYXksIFNlcHRl bWJlciAzMCwgMjAxMSA4OjAyIEFNDQpUbzogY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVz ZS1jYXNlcy0wMC50eHQNCg0KU2VjdGlvbiAyLjMgTm9tYWRpYyBVc2Vycw0KVGhpcyBkZXNjcmlw dGlvbiBmYWxscyB1bmRlciB0aGUgY2F0ZWdvcnkgb2YgR2VvZ3JhcGhpYyBFeHRlbnNpb24NCnll dCB0aGUgdGhpcmQgcGFyYWdyYXBoIHN0YXRlcyB0aGUgY2FzZSB3aGVyZSBhIGRpZmZlcmVudCBk ZXZpY2UgaXMNCnVzZWQgaW4gdGhlIHNhbWUgQ0ROIGNvdmVyYWdlIGFyZWEuICBUaGUgaW50ZW50 IG9mIHRoaXMgdXNlIGNhc2UNCm5lZWRzIHRvIGJlIGNsYXJpZmllZC4gIFBlcmhhcHMgdGhlIHVz ZSBjYXNlIGlzIHRyeWluZyB0byBhZGRyZXNzDQp0aGUgc2NlbmFyaW8gd2hlcmUgYSBOb21hZGlj IFVzZXItQSB3aXRoIGFuIGFncmVlbWVudCBhbGxvd2luZw0KYWNjZXNzIHRvIGNvbnRlbnQgZnJv bSBDU1AtQSB2aWEgdUNETiBtb3ZlcyB0byBhIGRDRE4gaW4gYSBkaWZmZXJlbnQNCnJlZ2lvbi4g IFRoZSBkQ0ROIGlzIGFsbG93ZWQgdG8gZGlzdHJpYnV0ZSB0aGUgY29udGVudCBvZiBDU1AtQSB0 bw0KVXNlci1BOyBob3dldmVyLCBub3Qgb3RoZXIgdXNlcnMgaW4gdGhlIHJlZ2lvbiBvZiB0aGUg ZENETiBhcmUNCmFsbG93ZWQgdG8gcmV0cmlldmUgdGhlIGNvbnRlbnQgdW5sZXNzIHRoZXkgdG9v IGhhdmUgc3VjaCBhbiBhZ3JlZW1lbnQuDQoNClNlY3Rpb24gNS4xLjMgQ29udGVudCBFbmNvZGlu ZyBSZXN0cmljdGlvbnMgTmVlZCB0byBjbGFyaWZ5IGlmIHdlJ3JlDQp0YWxraW5nIGFib3V0IHRo ZSByZXN0cmljdGlvbnMgb24gdGhlIGRlbGl2ZXJ5IG9mIHNwZWNpZmljIGNvbnRlbnQNCm9yIHRo ZSByZXN0cmljdGlvbnMgb24gdGhlIGFiaWxpdHkgb2YgYSBDRE4gdG8gZGVsaXZlciBzcGVjaWZp Yw0KY29udGVudC4gIEkgY2VydGFpbmx5IHVuZGVyc3RhbmQgdGhlIGNhc2Ugd2hlcmUgYSBDU1Ag d2lsbCByZXN0cmljdA0KdGhlIGRpc3RyaWJ1dGlvbiBvZiBjb250ZW50IHRvIGEgIm1hbmFnZWQg cGF0aCIgaWYgc3VjaCBjb250ZW50IGlzDQpIRCB3aGlsZSBhbGxvd2luZyB0aGUgY29udGVudCBk aXN0cmlidXRpb24gdmlhIGFuIHVuLW1hbmFnZWQgcGF0aCBpZg0Kc3VjaCBjb250ZW50IGlzIFNE IChzYW1lIGNvdWxkIGFwcGx5IHRvIGVuY3J5cHRpb24gbWV0aG9kcywgZGVsaXZlcnkNCm1ldGhv ZHMsIGV0Yy4pLiAgT24gdGhlIGNvbnRyYXJ5LCB0aGUgZENETiBtYXkgaGF2ZSBpdHMgb3duDQpy ZXN0cmljdGlvbnMgb2YgYmxvY2tpbmcgdGhlIGRpc3RyaWJ1dGlvbiBvZiBIRCBjb250ZW50IHdo aWxlDQphbGxvd2luZyB0aGUgZGlzdHJpYnV0aW9uIG9mIFNEIGNvbnRlbnQuDQoNCm8gZmlyc3Qg YnVsbGV0IG1ha2VzIHNlbnNlIGlmIHRoZSBkQ0ROIGNhbiBwZXJmb3JtIGEgc3Vic2V0IG9mDQpl bmNhcHN1bGF0aW9ucyBmb3IgYSByZWZlcmVuY2Ugc2V0IG9mIG1lZGlhIChlLmcuIEhMUywgSFNT LCBidXQgbm90DQpEQVNIKSBvIHNlY29uZCBidWxsZXQgbWFrZXMgc2Vuc2Ugd2hlcmUgdGhlIGRD RE4gZG9lc24ndCB3YW50IHRvDQpvZmZlciBoaWdoIGJpdC1yYXRlIHZhcmlhbnRzIG9mIHRoZSBt ZWRpYSBvIHRoaXJkIGJ1bGxldCBtYWtlIHNlbnNlDQppZiB0aGUgcG9saWN5IGFkZHJlc3NlcyBR b0UgYnV0IEkgZG9uJ3QgdGhpbmsgc3Vic2NyaWJlcg0KcmlnaHRzL2F1dGhvcml6YXRpb25zIGFw cGx5Lg0KDQpTZWN0aW9uIDEwIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCkFzaWRlIGZyb20g dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIFdJVEhJTiB0aGUgdUNETiBhbmQgZENETiwgSQ0K dGhpbmsgd2UgY2FuIGRlc2NyaWJlIHRoaXMgaW4gZm91ciBjb250ZXh0czoNCg0KYS4gVGhlIHJl bGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBDU1AgYW5kIHRoZSB1Q0ROICh0aGUgcHJpbmNpcGxlIGNv bnRyYWN0DQphcnJhbmdlbWVudCBmb3IgZGlzdHJpYnV0aW9uKQ0KYi4gVGhlIHJlbGF0aW9uc2hp cCBiZXR3ZWVuIHRoZSB1Q0ROIGFuZCBkQ0ROICh0aGUgdHJhbnNpdGl2ZSB0cnVzdA0KcmVsYXRp b25zaGlwIHRoYXQgZXh0ZW5kcyB0aGUgY29udHJhY3QgZGVmaW5lZCBpbiAoYSkgYWJvdmUpIGMu IFRoZQ0KcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIFVzZXIgYW5kIGRDRE4gKHRoZSByZWNvZ25p dGlvbiBvZiByaWdodCB0bw0KZG93bmxvYWQgcHJlZGljYXRlZCBvbiAoYikgYWJvdmUpIGQuIFRo ZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUNClVzZXIgYW5kIENTUCAodGhlIGNvbnRyYWN0IGF1 dGhvcml6aW5nIHRoZSB1c2VyIGFjY2VzcyB0byB0aGUNCmNvbnRlbnQpDQoNClRoZSB1c2VyIGlz IG5vdCBpbnRlcmVzdGVkIGluIHRoZSBhLWIgbm9yIHRoZSBiLWMgcmVsYXRpb25zaGlwLiBUaGUN CnVzZXIgaXMgb25seSBpbnRlcmVzdGVkIGluIHRoZSB0cmFuc3BhcmVuY3kgYW5kIGludGVyb3Bl cmFiaWxpdHkgb2YNCnRoZSBzZWN1cml0eSByZWxhdGlvbnNoaXAgYmV0d2VlbiBkLWIgb3IgZC1j IHRvIHRoZSBwb2ludCB0aGF0IHRoZQ0KYXV0aG9yaXphdGlvbiBncmFudGVkIGluIGQtYSBpcyB2 aWFibGUgd2hlbiB0aGUgZGVsaXZlcnkgaXMNCmluaXRpYXRlZCB2aWEgZWl0aGVyIGQtYiBvciBk LWMuICBBcyBhbiBleGFtcGxlLCB0aGUgdUNETiBtaWdodCB1c2UNClVSTCBhcHBlbmRlZCB0b2tl bnMgZm9yIGF1dGhlbnRpY2F0aW9uIHdoaWxlIGRDRE4gbWlnaHQgdXNlIFVSTA0KYXBwZW5kZWQg aGFzaGVzLiAgVGhlIHVzZXIgZG9lc24ndCB3YW50IHRvIGtub3cgYWJvdXQgdGhlIGRpc3RpbmN0 DQptZXRob2RzLCBidXQgdHJhbnNwYXJlbmN5IGlzIG9ubHkgYWZmb3JkZWQgaWYgdGhlIG1ldGhv ZHMgYXJlDQppbnRlcm9wZXJhYmxlIGNsZWFybHkgZGVmaW5lZCB3aGVuIHRoZSBkZWxlZ2F0aW9u IGZvciBjb250ZW50DQpkZWxpdmVyeSBpcyBleGVjdXRlZC4gIENsZWFybHksIHRoZSBjaG9pY2Ug b2YgYXV0aGVudGljYXRpb24gbWV0aG9kIGlzIGRldGVybWluZWQgYnkgdGhlIHJlc3BlY3RpdmUg Q0ROJ3MuDQoNClNjb3R0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWls aW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0 Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NkbmkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5n IGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0K --Boundary_(ID_hHpHkybtF26E+Cm0tV/cDw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly80NTQvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3Nl LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1i cmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L 5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtc3R5 bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uYXBwbGUt Y29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOy13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTstd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgRnJh bmNvaXMsIGFuZCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFua3MgZm9yIGFsbCB0aGUgZ3JvdXDigJlzIGF0dGVudGlvbiBvbiB0aGlzIHRvcGljLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBhbSBhbHNvIGhhcHB5 IHRoYXQgbXkgcHJvcG9zYWwgaGFzIGdvdHRlbiBzbyBtdWNoIHZhbHVhYmxlIHJlc3BvbnNlL3F1 ZXN0aW9ucy8gY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5UaGF0IHdpbGwgYmUgdmVyeSBoZWxwZnVsIGZvciBhbGwgb2YgdXMgdG8gY2F0Y2ggYSBj b21wbGV0ZSB1bmRlcnN0YW5kaW5nIGFuZCBzb2x1dGlvbiBmb3IgdGhpcyBtYXJrZXQgZGVtYW5k LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hpbGUgSSBmZWVs IHRpbGwgbm93IHRoZSB0b3BpYyBpdHNlbGYgaGFzIG5vdCBiZWVuIGNvbXBsZXRlbHkgYW5hbHl6 ZWQgYW5kIEkgYW0gYnVzeSBkb2luZyB0aGUgd29yay4gSSB3aWxsIGV4cG9zZSBteSBjb250cmli dXRpb24gc29vbiBhZnRlcg0KIEkgY29tcGxldGUgdGhhdCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWVhbndoaWxlIEkgaG9wZSB0aGUgZ3JvdXAgbWF5 IGFsbG93IHNvbWUgbW9yZSB0aW1lIGZvciBwZW9wbGUgdG8gY29uc2lkZXIgaXQuIFBlcmhhcHMg c29tZSBtb3JlIHBlb3BsZSB3aWxsIGVtZXJnZSBpbiB0aGUgZ3JvdXAgbWFpbCBsaXN0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q3VycmVudGx5LCBzb21lIHBl b3BsZSBoYXMgY2xhaW1lZCB0aGVpciBwcmVmZXJlbmNlLiAmbmJzcDtJIGZlZWwgcGVyaGFwcyBu b3QgYSBmZXcgcGVvcGxlIGhhdmUgc3VwcG9ydGVkIHRoaXMgdXNlIGNhc2UodGhlIGF1dGhvcnMg b2YNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPmRyYWZ0LWZtbi1jZG5pLWFkdmFuY2VkLXVzZS1jYXNlcy0wMCwgQWxhbiBmcm9t IEVyaWNzc29uLA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+Q2hpbmFNb2JpbGUsIENoaW5hdGVsZWNvbSwgJm5ic3A7cGVyaGFw cyBhbHNvIEtQTiwgYW5kIG1lKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSBoYXZlIGV4cGxhaW5lZCB0aGF0IGZvciBDRE4tQSBhbmQgQ0ROLUIsIHRoZXkgbWF5IG5lZ290 aWF0ZSB3aGV0aGVyIHRvIHN1cHBvcnQgdGhlIENETkkgYWRhcHRhdGlvbiBzb2x1dGlvbi4gSGVu Y2Ugc3VjaCBvcHRpb25hbCBhcnJhbmdlbWVudA0KIHdpbGwgb25seSBicmluZyBiZW5lZml0IHdo ZW4gYm90aCB1cHN0cmVhbSBhbmQgZG93bnN0cmVhbSBhZ3JlZXMgdGhhdCBhdCB0aGVpciBhcHBy b3ByaWF0ZSBzaXR1YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNv LCBJIHNpbmNlcmVseSBzdWdnZXN0IHR3byBDaGFpcnMgYW5kIHRoZSB3aG9sZSBncm91cCBtYXkg YWxsb3cgc29tZSBtb3JlIGRheXMgZm9yIHRoaXMgdG9waWMuICZuYnNwOyZuYnNwO0kgc3VnZ2Vz dCBhZnRlciB0aGUgVGFpcGVpIG1lZXRpbmcgLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QnkgdGhlbiB3ZSBhbGwgd2lsbCBnZXQgYSBjbGVhcmVyIHVuZGVyc3Rh bmRpbmcgYW5kIGRlY2lzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5aaGlwZW5n DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gRnJhbmNvaXMg TGUgRmF1Y2hldXIgW21haWx0bzpmbGVmYXVjaEBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gRnJpZGF5LCBPY3RvYmVyIDI4LCAyMDExIDk6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFpob3Va aGlwZW5nPGJyPg0KPGI+Q2M6PC9iPiBjZG5pQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBhZ2FpbiBaaGlwZW5nLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGlzIG9uZSBvdGhlciBw b2ludCBJIHNob3VsZCBoYXZlIGJyb3VnaHQgdXAgaW4gbXkgcHJldmlvdXMgbWVzc2FnZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHF1ZXN0aW9uIGlzIG5vdCBzbyBtdWNoIHdoZXRoZXIgdGhl cmUgYXJlIGJlbmVmaXRzIHRvIGFsbG93aW5nIGNvbnRlbnQgYWRhcHRhdGlvbiBmb3Igc29tZSBl bnZpcm9ubWVudHMsIG5vciB3aGV0aGVyIG9uZSBwYXJ0aWN1bGFyIGluZGl2aWR1YWwgY291bGQg Y29uY2VpdmUgYW4gYXBwcm9hY2ggZm9yIGNvbnRlbnQgYWRhcHRhdGlvbiB0aGF0IHN1aXRzIGhp bS4gVGhlDQogcXVlc3Rpb24gaGVyZSBpcyByYXRoZXIgd2hldGhlciBpdCBpcyBqdXN0aWZpZWQg Zm9yIHRoZSBXb3JraW5nIEdyb3VwIHRvIGZvY3VzIGVuZXJneSBvbiB0aGF0IHByb2JsZW0gcmln aHQgbm93IGluIG9yZGVyIHRvIGRldmVsb3AgYSBjb25zZW5zdXMtYmFzZWQgYXBwcm9hY2ggdGhh dCBzdWl0cyB0aGUgY29tbXVuaXR5IGFzIGEgd2hvbGUsIHdoaWxlIHdlIGRvbid0IGV2ZW4gaGF2 ZSB0aGUgYmFzZSBzb2x1dGlvbiBpbiBwbGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdSBoYXZlIG1hZGUgaXQgY2xlYXIgdGhhdCB5b3UgZmVl bCB0aGUgV0cgc2hvdWxkIGluZGVlZCBkZWRpY2F0ZSBlbmVyZ3kgb24gdGhhdCBwcm9ibGVtIHJp Z2h0IGF3YXkgYW5kIGV4cGxhaW5lZCB5b3VyIHJhdGlvbmFsZS4gVGhhbmsgeW91LiBPdGhlcnMg aGF2ZSBhbHNvIGV4cHJlc3NlZCB0aGVpciBvcGluaW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVyczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJhbmNvaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9u IDI4IE9jdCAyMDExLCBhdCAxMToyNSwgWmhvdVpoaXBlbmcgd3JvdGU6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+RGVhciBhbGwsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkluIHRoZXNlIGRheXMgSSBhbSBidXN5IG1ha2luZyBh IHN1bW1hcnkgYW5hbHlzaXMgb24gdGhpcyB0b3BpYy4gQXMgUmljaGFyZOKAmXMgcmVxdWVzdCwg SSBsaWtlIHRvIHNob3cgbXkgaW5mb3JtYXRpb24gYWx0aG91Z2ggcGVyaGFwcyBub3QgY29tcGxl dGUgcmlnaHQgbm93LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDtsaW5lLWhl aWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PjEpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5JDQogaGF2ZSBkb25lIHNvbWUgd29yayB0byBjb2xsZWN0IGRpZmZlcmVudCBjb21w YW554oCZcyByZXF1aXJlbWVudHMgYW5kIG9waW5pb25zIG9uIHRoaXMgZnVuY3Rpb25hbGl0eS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5PbmUsIEkgZmVlbCBt b3N0IG9mIHVzIGhhdmUgYWxyZWFkeSBiZWVuIGF3YXJlIG9mIHRoZSBzZXJ2aWNlIG9mIGNvbnRl bnQgYWRhcHRhdGlvbiwgYW5kIEkgYWxzbyBzZW50IGFuIGVtYWlsIHllc3RlcmRheSB0aGF0IFZv ZGFwaG9uZQ0KIG5vdyBpcyByZXF1aXJpbmcgdGhlIHNvbHV0aW9uIHRvIGVuaGFuY2UgdGhlIHBl cmZvcm1hbmNlIG9mIGl0cyBtb2JpbGUgdmlkZW8gc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TZWNvbmQsIGhlcmUgaXMgYW4gYXJ0aWNsZSBhYm91 dCBDSVNDTyA6IOKAnENpc2NvIHVyZ2VzIG1vYmlsZSBvcGVyYXRvcnMgdG8gYWRkIHZhbHVlIHRv IENETiBzZXJ2aWNlc+KAnTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LnRvdGFsdGVsZS5jb20vdmlldy5hc3B4P0lEPTQ2 ODcwNSI+aHR0cDovL3d3dy50b3RhbHRlbGUuY29tL3ZpZXcuYXNweD9JRD00Njg3MDU8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QmVzaWRlcywgSSBoYXZl IGNoZWNrZWQgbWFueSBDRE4gY29tcGFueeKAmXMgd2Vic2l0ZXMuIE1hbnkgY2xhaW0gdG8gc3Vw cG9ydCB0cmFuc2NvZGluZyB3aGlsZSBzb21lIG1heSBub3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4yKTwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Rm9yDQogdGhlIHdv cmRpbmcg4oCcY29udGVudCBhZGFwdGF0aW9u4oCdLCBpdCBzaG91bGQgYmUgY2xhcmlmaWVkIGhl cmUgdGhhdCBpdCBtYXkgYmUgdHdvIGtpbmRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPk9uZSBpcyBvbmx5IHRoZSB0cmFuc2Zvcm1hdGlvbiBvZiBlbmNhcHN1 bGF0aW9uIGZvcm1hdC4gRm9yIGV4YW1wbGUgdGhlIEguMjY0IHN0cmVhbSBpcyBlbmNhcHN1bGF0 ZWQgaW4gQVBQTEUgYW5kIEFkb2JlIGZvcm1hdA0KIHJlc3BlY3RpdmVseS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIGtub3cgdGhhdCBDb21jYXN0IGhhcyBh IHByb2plY3QgdGhhdCBuZWVkcyB0byBwaWNrIHRoZSBILjI2NCBtZWRpYSBmcm9tIHRoZSBUUyBz dHJlYW0gYW5kIHRoZW4gZW5jYXBzdWxhdGVkIHRoZW0gaW50byBkaWZmZXJlbnQNCiBmb3JtYXRz KEFQUExFLEFkb2Jl4oCmKSB0byBkaWZmZXJlbnQgZGV2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gb3IgdGhpcyBraW5kIG9mIHRyYW5zZm9ybWF0aW9u LCB0aGUgY29tcHV0aW5nIGNvc3QgaXMgdmVyeSB2ZXJ5IGxvdyBhbmQgbWF5IGJlIG5lYXJseSBu ZWdsZWN0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhl IG90aGVyIGlzIHRvIHRyYW5zY29kaW5nLiZuYnNwOyBGb3IgZXhhbXBsZSB0byBzdXBwb3J0IGRp ZmZlcmVudCBiaXRyYXRlcy4mbmJzcDsgU2luY2UgZW5jb2RlciBpcyBhIGhpZ2ggdmFsdWUgZmFj aWxpdHksIHdlIHNob3VsZCBjb21wYXJlDQogdGhlIGNhcGl0YWwgY29zdCBvZiBlbmNvZGVyIGFu ZCB0cmFuc3BvcnQgY29zdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5KdXN0IHRha2UgYSBzaW1wbGUgbW9kZWw6IGNvbnRlbnQgaXMgZGVsaXZlcmVkIGZyb20g Tm9kZSBBIHRvIE5vZGUgQi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbHQ7aW1hZ2UwMDIucG5nJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPlRoZXJlIGFyZSB0d28gc29sdXRpb25zOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O2xpbmUtaGVpZ2h0OjEzLjJwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+MSk8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkENCiBo YXZlIHRoZSB0cmFuc2NvZGVyIGFuZCBkZWxpdmVyIG11bHRpLWZvcm1hdCBjb250ZW50IHRvIEI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDts aW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjIpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5CDQogaGF2ZSB0aGUgdHJhbnNjb2RlcjsgQSBvbmx5IGRlbGl2ZXJzIG9u ZSBmb3JtYXQgY29udGVudCB0byBCIGFuZCBCIHdvdWxkIHRyYW5zY29kZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gcm9tIHdob2xlIHN5c3RlbSBwb2ludCBv ZiB2aWV3LCBlaXRoZXIgQSBvciBCIHdvdWxkIHRyYW5zY29kZSB3aGlsZSB0aGUgYmFuZHdpZHRo IHdvdWxkIGJlIHNhdmVkIGluIHNvbHV0aW9uIEIuIEhlbmNlIHNvbHV0aW9uDQogQiBpcyBiZXR0 ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Tm93IHByb3Zp ZGVkIHRoZSBiYW5kd2lkdGggaXMgcGFpZCBieSBCIGFuZCBCIHNob3VsZCBkZWNpZGUgd2hldGhl ciB0byBpbnN0YWxsIHRyYW5zY29kZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+KFJpY2hhcmQgaGFzIHNhaWQgdG8gc2V0IHRyYW5zY29kZXIgaW4gZWFjaCBl ZGdlIHNlcnZlcik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5J ZiB0aGUgY29zdCBvZiByZW50aW5nIGJhbmR3aWR0aCAoZm9yIGEgZmV3IG1vbnRocykgaXMgbW9y ZSBleHBlbnNpdmUgdGhhbiB0aGUgcHJpY2Ugb2YgdHJhbnNjb2RlciBzdXBwb3J0aW5nIHRoZSBz YW1lIGJhbmR3aWR0aCwNCiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gcHV0IHRoZSB0cmFuc2NvZGVy IGF0IHRoZSByZWNlaXZlciBOb2RlIEIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+SW4gZmFjdCBJIGhhdmUgaW52ZXN0aWdhdGVkIHRoaXMgaXNzdWUgZm9yIG11 Y2ggdGltZS4gV2hpbGUgaW4gZGlmZmVyZW50IGFyZWEgdGhlIHByaWNlIG9mIGJhbmR3aWR0aCBt YXkgYmUgZGlmZmVyZW50LiZuYnNwOyBBbmQgdGhlDQogdHJhbnNwb3J0IGJ1cmRlbiBiZXR3ZWVu IHR3byBkaXN0YW50IHBsYWNlcyBvciBvdmVyIGEgYmFkIG5hdHVyZSBlbnZpcm9ubWVudCB3b3Vs ZCBiZSBtdWNoIGhpZ2hlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5IZXJlIHRoZSBwcmljZSBpbiBVU0EgbWF5IGJlIHJlZmVycmVkIGFzOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vc21h bGxidXNpbmVzcy52ZXJpem9uLmNvbS9wcm9kdWN0cy9pbnRlcm5ldC9oc2kvb3ZlcnZpZXcuYXNw eCNwbGFucyI+aHR0cDovL3NtYWxsYnVzaW5lc3MudmVyaXpvbi5jb20vcHJvZHVjdHMvaW50ZXJu ZXQvaHNpL292ZXJ2aWV3LmFzcHgjcGxhbnM8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkluIFZlcml6b24sIHRoZSBwYWNrYWdlIGZvciAxMC0xNW1icHMg aXMgJDkwIHBlciBtb250aCAoSSBmZWVsIHRoZSBiYW5kd2lkdGggcXVhbGl0eSBmb3IgYnVzaW5l c3Mgd291bGQgYmUgZ3VhcmFudGVlZCkuIEkgcXVlcnkNCiB0aGF0IHRoZSBiYW5kd2lkdGggcHJp Y2UgaW4gQ2hpbmEgbWF5IGJlIDUwJSBoaWdoZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+SSBkbyBub3Qga25vdyBob3cgbXVjaCB0aGUgcHJpY2Ugd2lsbCBi ZSBmb3IgdGhlIGJhbmR3aWR0aCBmcm9tIEFtc3RlcmRhbSB0byBQYXJpcyAoY3Jvc3MgY291bnRy eSBpbiB0aGUgc2FtZSBjb250aW5lbnQpLiZuYnNwOyBCdXQNCiBJIGZlZWwgdGhlIHByaWNlIGZy b20gTmV3WW9yayB0byBQYXJpcyB3b3VsZCBhYnNvbHV0ZWx5IGJlIHZlcnkgaGlnaC4mbmJzcDsg QXMgZm9yIHRoZSBFbmNvZGVyLCBpdCBhbHNvIHZhcmllcy4gUGVyaGFwcyB0aGUgcHJpY2UgaW4g Q2hpbmEgd2lsbCBiZSBoaWdoZXIgdGhhbiBpbiBVU0EuIEFuZCBpbiBmYWN0IHRoZSBwcmljZSBv ZiBiYW5kd2lkdGggYW5kIGVuY29kZXIgZGVwZW5kcyBtb3N0bHkgb24gdGhlIGNvbmNyZXRlIGJ1 c2luZXNzIGl0ZW1zLg0KIEZvciBleGFtcGxlIHRoZSBwcmljZSB0byBIdWF3ZWkgbWF5IGJlIGxv d2VyIHRoYW4gdGhlIHB1YmxpYyBwcmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5CeSBteSBjdXJyZW50IGV2YWx1YXRpb24gaW4gQ2hpbmEgaXQgaXMgYmV0 dGVyIHVzaW5nIHRoZSB0cmFuc2NvZGVyIHRoYW4gcmVudGluZyBtdWx0aXBsZSB0aW1lcyBicm9h ZGJhbmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEz LjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U29tZSBw ZW9wbGUgaGF2ZSB0b2xkIG1lIHRoYXQgZm9yIHRoZSBvcGVyYXRvciBoaW1zZWxmIHByb2JhYmx5 IHRoZSBiYW5kd2lkdGggY29zdCB3b3VsZCBiZSB2ZXJ5IGxvdyBpbiB0aGUgaW50ZXJuYWwgY2Fw aXRhbCBjb3VudGluZy4NCiBCdXQgZm9yIHRoZSBpbmRlcGVuZGVudCBDRE4sIGl0IG1heSBhbm90 aGVyIHRoaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNv LCBteSBzdWdnZXN0aW9uIGlzIHRvIGxldCBkaWZmZXJlbnQgd2F5cyBjby1leGlzdC4gSSBoYXZl IGFubm91bmNlZCB0aGF0IHRvIGxldCB0d28gc2lkZXMgbmVnb3RpYXRlIHdoZXRoZXIgdG8gYXNz aWduIGRDRE4gZm9yDQogdGhlIGNvbnRlbnQgYWRhcHRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5JbiBmYWN0LCBmcm9tIENQIHRvIENETiwmbmJzcDsgdGhlcmUg YXJlIHRoZSByZWFsIGJ1c2luZXNzZXMgdGhhdCBlaXRoZXIgbGV0IENQIHRvIHByb3ZpZGUgbXVs dGktZm9ybWF0IGNvbnRlbnQgb3IgbGV0IHRoZSBDRE4gdG8gcmVjZWl2ZQ0KIG9uZSBmb3JtYXQg YW5kIGNvbXBsZXRlIHRoZSB0cmFuc2Zvcm1hdGlvbiwgZGVwZW5kaW5nIG9uIHRoZSBjb25jcmV0 ZSBidXNpbmVzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5C eSB0aGUgc2FtZSBsb2dpYywgZm9ybSB1Q0ROIHRvIGRDRE4sIGl0IG1heSBiZSBlaXRoZXIgdGhl IHVDRE4gdG8gcHJvdmlkZSBtdWx0aS1mb3JtYXQgY29udGVudCBvciB0aGUgZENETiB0byByZWNl aXZlIG9uZSBmb3JtYXQNCiBjb250ZW50IGFuZCB0aGVuIGNvbXBsZXRlIHRoZSB0cmFuc2Zvcm1h dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMu MnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5DdXJyZW50 bHkgdGhlcmUgaXMgbm90IHRoZSByZWFsIENETi1DRE4gY29ubmVjdGlvbiwgaGVuY2Ugd2UgYXJl IGJhc2luZyBvdXIga25vd2xlZGdlIG9uIHRoZSByZWxhdGVkIHNvbHV0aW9uIHRvIG1ha2Ugb3Vy IHNvbHV0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDtsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjMpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5Bcw0KIGZvciB0aGUgcHJvY2VkdXJlIG9mIGNvbnRlbnQgYWRh cHRhdGlvbiwgSSBqdXN0IGRyYWZ0IGEgZGlhZ3JhbSBhcyBiZWxvdzo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbHQ7aW1hZ2UwMDQucG5nJmd0OzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPllvdSBtYXkgc2VlIHRoZSBzb2x1dGlvbiBp cyByYXRoZXIgY2xlYXIgYW5kIHRoZSBtZXRhZGF0YSBuZWVkZWQgd291bGQgYmUgY2xlYXIgYWxz by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5EZWFyLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJ5IG15IGFuYWx5c2lzIGFib3ZlLCBJ IGtpbmRseSBpbnZpdGUgeW91ciBpZGVhcyB3aGV0aGVyIGl0IG1heSBiZSBhbiBhcHBsaWNhYmxl IGFuZCBzaW1wbGUgcGFydCBpbiB0aGUgQ0ROSSBpdGVtLCBwcm92aWRlZCB0aGF0DQogdGhlIHNv bHV0aW9uIGlzIG9wZW4gdG8gdGhlIHR5cGVzIG9mIGNvbnRlbnQgYWRhcHRhdGlvbiBhbmQgbWF5 IGJlIG9wdGlvbmFsbHkgaW1wbGVtZW50ZWQgaW4gdGhlIHJlYWwgc29sdXRpb25zL2J1c2luZXNz LiBJIGZlZWwgZm9yIHRob3NlIG9wZXJhdG9ycyB0aGF0IG5lZWQgc3VjaCBmdW5jdGlvbmFsaXR5 IGl0IHdvdWxkIGJlIHZlcnkgZ29vZCB3aGlsZSBpdCBkb2VzIG5vdCBpbXBhY3Qgb3RoZXJzIHRo YXQgZG8gbm90IGltcGxlbWVudCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLXdp ZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldvdW5keSwNCiBSaWNoYXJkIFttYWls dG86UmljaGFyZF9Xb3VuZHlAY2FibGUuY29tY2FzdC5jb21dPHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2RheSwgT2N0b2JlciAy NywgMjAxMSA3OjIzIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5aaG91WmhpcGVuZzs8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOidtYXJrQGpldC1zdHJl YW0ubmwiPidtYXJrQGpldC1zdHJlYW0ubmw8L2E+Jzs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOidhbGFuLmthdmFuYWdoQGVy aWNzc29uLmNvbSI+J2FsYW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29tPC9hPic8YnI+DQo8Yj5DYzo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzonY2RuaUBpZXRmLm9yZyI+J2NkbmlAaWV0Zi5vcmc8L2E+JzsgV291bmR5LCBS aWNoYXJkPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5p LXVzZS1jYXNlcy0wMC50eHQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7SW4g eW91ciBjb21wYW554oCZcyB3ZWJzaXRlLCBJIGp1c3QgZmluZCBzb21lIGluZm9ybWF0aW9uPGJy Pg0KPGJyPg0KSSBoYXZlIHRvIHN0ZXAgaW4gYXMgY28tY2hhaXIgaGVyZS48YnI+DQo8YnI+DQpU aGUgZ29hbCBvZiB0aGlzIFdHIGlzIG5vdCB0byBhbGlnbiB2ZW5kb3IgcHJvZHVjdCByb2FkbWFw cywgb3IgdG8gZXF1YWxpemUgYWxsIHZlbmRvciBvZmZlcmluZ3MsIG9yIHRvIHNwZWNpZnkgdGhl IGVudGlyZSBDRE5JIGVjb3N5c3RlbS4gVGhlIGdvYWwgb2YgdGhpcyBXRyBpcyB0byBlbmFibGUg dGhlIGludGVyY29ubmVjdGlvbiBhbmQgaW50ZXJvcGVyYXRpb24gb2YgdHdvIG9yIG1vcmUgQ0RO cywgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlDQogQ0ROSSB3ZyBjaGFydGVyLjxicj4NCjxicj4N Ckl0IGlzIE9LIHRvIGhhdmUgYSBkaXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgY29udGVudCBhZGFw dGF0aW9uIG5lZWRzIHRvIGJlIHBlcmZvcm1lZCBieSB0aGUgZENETiwgc2luY2UgdGhhdCBkZWNp c2lvbiBpbXBhY3RzIHRoZSB1Q0ROLWRDRE4gaW50ZXJmYWNlLiBTbyBsZXQncyBmaW5kIGEgcHJv ZHVjdGl2ZSB3YXkgdG8gZGlzY3VzcyB0aGlzIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCB0byBj bG9zZSB0aGUgZGlzY3Vzc2lvbiBieSBJRVRGIDgyDQogKGlmIG5vdCBzb29uZXIpLjxicj4NCjxi cj4NCkNhbiBzb21lb25lIGRlc2NyaWJlIHJlYWwtbGlmZSBleGFtcGxlcyB3aGVyZSBkb3duc3Ry ZWFtIENETiAob3IgZWRnZSBjYWNoZS1iYXNlZCkgY29udGVudCBhZGFwdGF0aW9uIGlzIG5lZWRl ZCB0b2RheSBpbiBhIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQsIG9yIHNob3J0bHk/IE5vdCBtZXJl bHkgYSBmZWF0dXJlIGluIGEgdmVuZG9yJ3MgcHJvZHVjdCBtYXRlcmlhbHM/PGJyPg0KPGJyPg0K U3BlYWtpbmcgYXMgYW4gaW5kaXZpZHVhbCwgSSBjYW4gZmluZCBhIGxvdCBvZiBleGFtcGxlcyB3 aGVyZSBkb3duc3RyZWFtIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBub3QgbmVlZGVkLCBhbmQgYW55 IGFkYXB0YXRpb24gaXMgcmVhbGx5IHBhcnQgb2YgdGhlIENQIC0gdUNETiBpbnRlcmZhY2UgKHdo aWNoIGlzIG91dCBvZiB0aGUgc2NvcGUgb2Ygb3VyIGNoYXJ0ZXIpLjxicj4NCjxicj4NCi0tIFJp Y2g8YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItd2lkdGg6aW5pdGlhbDtib3JkZXItY29sb3I6 aW5pdGlhbCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjogWmhvdVpoaXBlbmcgW21haWx0bzp6aG91emhpcGVu Z0BodWF3ZWkuY29tXTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQo8Yj5TZW50PC9iPjogVGh1cnNkYXksIE9jdG9iZXIgMjcsIDIwMTEgMDM6NDUg QU08YnI+DQo8Yj5UbzwvYj46IE1hcmsgZGUgSm9uZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcmtA amV0LXN0cmVhbS5ubCI+bWFya0BqZXQtc3RyZWFtLm5sPC9hPiZndDs7IEFsYW4gS2F2YW5hZ2gg Jmx0OzxhIGhyZWY9Im1haWx0bzphbGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbSI+YWxhbi5rYXZh bmFnaEBlcmljc3Nvbi5jb208L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5DYzwvYj46PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5j ZG5pQGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8 L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnI+DQo8Yj5TdWJqZWN0PC9iPjogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNk bmktdXNlLWNhc2VzLTAwLnR4dDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIE1hcmssPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5pY2UgdG8gbWVldCB5b3Ugb24gbGluZS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4geW91ciBjb21wYW554oCZcyB3ZWJz aXRlLCBJIGp1c3QgZmluZCBzb21lIGluZm9ybWF0aW9uIHRoYXQgYWRkcmVzc2VzIOKAnDxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iTkwiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEM1NjVDIj5Wb2RhZm9uZQ0KIHN1 YnNjcmliZXJzIGNvbXBsYWluZWQgYWJvdXQgdmlkZW8gcGVyZm9ybWFuY2Uu4oCdPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNlZTo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFtLm5sL3NlYXJjaC8/c2Vh cmNoPXRyYW5zY29kaW5nIj5odHRwOi8vd3d3LmpldC1zdHJlYW0ubmwvc2VhcmNoLz9zZWFyY2g9 dHJhbnNjb2Rpbmc8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5EZWFyIGFsbCBpbiB0aGlzIGdy b3VwLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiBsYXN0IGZldyBkYXlz LCBleGNlcHQgdGhlIHB1YmxpYyBlbWFpbCBkaXNjdXNzaW9ucyBJIGhhdmUgY29udGFjdGVkIHdp dGggc29tZSBwZW9wbGUgYW5kIGRpc2N1c3NlZCB3aXRoIG15IG93biBjb2xsZWFndWVzIG9mIGFs bCBkZXRhaWxzIG9uDQogdGhpcyBpc3N1ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Rmlyc3QsIGFsdGhvdWdoIHRoZSBtYXJrZXQgcmVxdWlyZW1lbnQgZm9yIGl0IGlzIHZl cnkgaW1wb3J0YW50LCBJIGZlZWwgSeKAmWQgYmV0dGVyIHNob3cgdXAgbW9yZSBpbmZvcm1hdGlv biBvbiB0aGUgcHJvY2VkdXJlIGludm9sdmVkLiBJIGhhdmUgZXhwbGFpbmVkDQogbWFueSB0aW1l cyB0aGF0IHRvIHN1cHBvcnQgY29udGVudCBhZGFwdGF0aW9uIGlzIHJhdGhlciBzaW1wbGUgd2hp bGUgdGhlIHdvcmRpbmcgaXMgbm90IGVub3VnaC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSBhbSBidXN5IG1ha2luZyBzb21lIGNvbnRyaWJ1dGlvbnMgb24gdGhpcyBhbmQg cGxhbiB0byB1cGxvYWQgdG8gRVRTSSBtZWV0aW5nIGFuZCBJRVRGIENETkkuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ5IHRoZXNlIHdvcmsmbmJzcDsgSSBmZWVsIHRoZSBw ZW9wbGUgbWF5IGNhdGNoIGEgd2hvbGUgdmlldyBvbiB0aGlzIGlzc3VlLjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TZWNvbmQsIGZvciB0aGF0IGZ1bmN0aW9uYWxpdHksIGlu IGltcGxlbWVudGF0aW9uLCBpZiBzb21lIGVudGl0eSBkb2VzIG5vdCBjaG9vc2UgdG8gc3VwcG9y dCBpdCwgaXQgbWF5IGJlIG9rLiBTaW5jZSBpdCBtYXkgYmUgbmVnb3RpYXRlZCBiZXR3ZWVuPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPg0KIHR3byBDRE5z Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBkQ0ROIGRvZXMgbm90IHN1 cHBvcnQgdGhhdCwgaXQgbWF5IGJlIHRoZSB1Q0ROIHJlc3BvbnNpYmxlIHRvIGNvbXBsZXRlIHRo ZSB0cmFuc2NvZGluZyBhbmQgZGVsaXZlciB0aGUgY29udGVudCBvZiBtdWx0aXBsZSBmb3JtYXRz IGFuZCByYXRlcw0KIHRvIGRDRE4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoaXJkLCBhbHRob3VnaCBDRE5JIGlzIGEgbmV3IGFyY2hpdGVjdHVyZSwgd2hpbGUgdGhlIGNv bnRlbnQgb3BlcmF0aW5nIGhhcyBiZWVuIGV4aXN0ZWQgZm9yIHllYXJzLiBBcyBJIGtub3cgdGhl IGNvbnRlbnQgZnJvbSBVU0EgdG8gdGhlIGRvd25zdHJlYW0NCiBvcGVyYXRvciBpcyB0cmFuc2Zl cnJlZCBvbiBvbmUgY29weSBhbmQgdGhlIGRvd25zdHJlYW0gb3BlcmF0b3Igd2lsbCBoYW5kbGUg dGhlIHRyYW5zY29kaW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UGVyaGFwcywgdGhlIGNvbnRl bnQgYWRhcHRhdGlvbiBpcyBtb3JlIG9uIHRoZSBtb2JpbGUgb3BlcmF0aW5nLiBCdXQgSSBmZWVs IGN1cnJlbnRseSBtb3N0IG9wZXJhdG9yIHdpbGwgYmUgYSBhbGwgc2VydmljZSBvcGVyYXRvci4g QW5kIGZvciB0aGUNCiBDRE4gcHJvdmlkZXJzLCBpdCBtYXkgYmUgYmV0dGVyIHRvIHN1cHBvcnQg YWxsIGtpbmRzIG9mIHNlcnZpY2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkJlc2lkZXMsIEkgbGlrZSBzYXkgdGhhdCB0aGUgdGVjaG5vbG9neSBvbiB0aGlzIHRvcGljIGhh cyBiZWVuIGZvciBtYW55IHllYXJzIGFuZCBoYXMgYmVlbiByYXRoZXIgbWF0dXJlLCBldmVuIHNv bWUgaXRlbXMgaW4gaWV0ZiBzdWNoIGFzIHJmYzM1MDc8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+DQogaWNhcC4gU28gZnJvbSB0aGUgdGVjaG5pcXVlIHBv aW50IG9mIHZpZXcsIGl0IGlzIGEgbmF0dXJlIGFjdGlvbiB0byBiZSBpbnZvbHZlZCBpbiBDRE4g aW50ZXJjb25uZWN0aW9uLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFu a3MuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlpoaXBlbmc8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItd2lkdGg6aW5pdGlhbDtib3Jk ZXItY29sb3I6aW5pdGlhbCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+TWFyaw0KIGRlIEpvbmcgW21haWx0bzptYXJrQGpldC1zdHJlYW0u bmxdPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5UaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSA0OjIxIEFNPGJyPg0KPGI+VG86PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5BbGFuIEthdmFu YWdoPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5CZW4gTml2ZW4tSmVua2luczsgWmhvdVpoaXBlbmc7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjZG5pQGll dGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0NETmldIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IaSBBbGFuLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFzIEJlbiBzdGF0ZWQgdGhlIG92ZXJhbGwgZGlzY3Vz c2lvbiByaWdodCBub3cgaXMgYWJvdXQgZGVsaXZlcnksIG5vdCBvbiBhZGFwdGF0aW9uLiBJdCBp cyBoYXJkIGVub3VnaCB0byBnZXQgY29uc2Vuc3VzIG9uIHRoZSBkZWxpdmVyeSBhc3BlY3QgYWxy ZWFkeSBub3QgdG8gbWVudGlvbiB5b3VyDQogcmVxdWlyZW1lbnQgZnJvbSBjb250ZW50IGFkYXB0 YXRpb24gYWRkZWQgdG8gdGhhdCwgc28gSSBhZ3JlZSB3aXRoIEJlbiB3ZSBzaG91bGQgc3RpY2sg d2l0aCB0aGUgZGVsaXZlcnkgYXNwZWN0IGZvciB0aGUgZmlyc3Qgc3BlY3MuJm5ic3A7SSBjYW4g aW1hZ2luZSB0aGlzIGNvdWxkIGJlIGEgZGlzY3Vzc2lvbiBsYXRlciBvbiBidXQgcGxlYXNlIGxl dCB1cyBrZWVwIHRoZSBzY29wZSBvZiB0aGlzIGJlIGNsZWFuIGFuZCB0cmFuc3BhcmVudC4gSXQg aXMNCiBvZiBiZW5lZml0IG9mIGV2ZXJ5b25lIHRvIGdldCB0aGUgZmlyc3Qgc3BlY3MgYXMgZmFz dCBhcyBwb3NzaWJsZS4gVGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQsPC9z cGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+S2luZCByZWdhcmRzLDwvc3Bhbj48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8 YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+TWFyayBkZSBKb25nPC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5JbnRlcm5hdGlvbmFsIEJ1c2luZXNz IERldmVsb3Blcjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+SmV0 LVN0cmVhbSBCVjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3Bh biI+RS1tYWlsOjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxhIGhyZWY9Im1haWx0bzpt YXJrQGpldC1zdHJlYW0uY29tIj5tYXJrQGpldC1zdHJlYW0uY29tPC9hPjwvc3Bhbj48YnI+DQo8 c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+T2ZmaWNlOiAmIzQzOzMxICgwKTUwIDUyNjE4 MjA8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPk1vYmlsZTogJiM0 MzszMSAoMCk2IDgxMTA4MjYzPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1z cGFuIj5GYXg6ICYjNDM7MzEgKDApNTAgNTI2NDIxNDwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1z cGFuIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPi0gRXZlbnQ6PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk1lZXQN CiB1cyBhdCBTdHJlYW1pbmcgTWVkaWEgRXVyb3BlLCAxNy0xOCBPY3RvYmVyLCBMb25kb24sIFVL PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0gRXZlbnQ6PC9zcGFuPjwv Yj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7TWVldA0KIHVzIGF0IE9u bGluZSBWaWRlbyBTdHJhdGVnaWVzLCAxOSBPY3RvYmVyLCBMb25kb24sIFVLPC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi0gRXZlbnQ6PC9zcGFuPjwvYj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7TWVldA0KIHVzIGF0IENETiBXb3JsZCBTdW1t aXQsIDI1LTI4IE9jdG9iZXIsIExvbmRvbiwgVUs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxl LXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPk5ld3M6PC9z cGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7UHJlLXJlcXVl c3QNCiB5b3VyIFRlY2hub2xvZ3kgV2hpdGVwYXBlciBub3cgYW5kIGJlIHRoZSBmaXJzdCB0byBo YXZlIGl0LCBjaGVjazwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9 Imh0dHA6Ly93d3cuamV0LXN0cmVhbS5jb20iPnd3dy5qZXQtc3RyZWFtLmNvbTwvYT48L3NwYW4+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tJm5ic3A7PGI+TmV3czombmJzcDs8L2I+Q2hlY2smbmJz cDs8YSBocmVmPSJodHRwOi8vd3d3LmpldC1zdHJlYW0uY29tIj5odHRwOi8vd3d3LmpldC1zdHJl YW0uY29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnRvDQogZG93bmxv YWQgb3VyICdTaXggVHJlbmRzIGluIENETnMnIGJyb2NodXJlPC9zcGFuPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi08L3NwYW4+PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj5CbG9nOjwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFw cGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbS9ibG9nLyI+d3d3 LmpldC1zdHJlYW0uY29tL2Jsb2cvPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFu Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPi08 L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5WaWRlb0V4Y2hhbmdlOjwvc3Bh bj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9z cGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDov L3d3dy52ZG8teC5uZXQiPnd3dy52ZG8teC5uZXQ8L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlN0cmVhbXppbGxh Ojwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0i aHR0cDovL3d3dy5zdHJlYW16aWxsYWNkbi5jb20iPnd3dy5zdHJlYW16aWxsYWNkbi5jb208L2E+ PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBs ZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPkNvcnBvcmF0ZTo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2 LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbSI+d3d3LmpldC1zdHJlYW0u Y29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+T24gMjYsIE9jdCwyMDExLCBhdCA4OjMzIFBNLCBBbGFuIEthdmFuYWdoIHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+QmVuPGJyPg0KPGJyPg0KSW0gYXNzdW1pbmcgdGhlbiBiYXNlZCBvbiB5b3VyIGNvbW1lbnRz IGJlbG93IGFyZSB5b3Ugc3VnZ2VzdGluZyB3ZSBhcmUgZ29pbmcgdG8gaGF2ZSBhIG51bWJlciBv ZiB2ZXJzaW9ucyBvZiB0aGUgQ0ROLUkgTWV0YWRhdGE/PGJyPg0KPGJyPg0KSSBzeW1wYXRoaXNl IHdpdGggd2hhdCB5b3UgYXJlIHBvaW50aW5nIG91dCBiZWxvdyBhbmQgZG8gYWdyZWUgdGhhdCB0 aGVyZSBpcyBzb21lIHdvcmsgdG8gYmUgZG9uZSwgYnV0IEkgc3RpbGwgZmVlbCB0aGF0IGNvbnRl bnQgYWRhcHRhdGlvbiBpcyB0byBtZSBhIGZ1bmRhbWVudGFsIHJlcXVpcmVtZW50IHRvIHdoYXQg Y29sbGVjdGl2ZWx5IHdlIHNob3VsZCBhZGRyZXNzIGluIHRoZSBDRE4tSSBXRy4gSSBkbyBhZ3Jl ZSB3aXRoIHlvdSB0aGF0IGNvbnRlbnQNCiBhZGFwdGF0aW9uIGlzIGFuIG9wdGltaXphdGlvbiBi ZXR3ZWVuIENETidzIGJ1dCBpdCdzIGEgdmVyeSBpbXBvcnRhbnQgb25lIHRoYXQgSSBrbm93IE5l dHdvcmsgU2VydmljZSBQcm92aWRlcnMgcGFydGljdWxhcmx5IHJlcXVpcmUuPGJyPg0KPGJyPg0K QWxhbjxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZyI+Y2RuaS1ib3VuY2VzQGlldGYub3JnPC9hPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bbWFpbHRvOmNkbmkt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlbiBOaXZlbi1KZW5raW5zPGJyPg0KU2Vu dDogT2N0b2Jlci0xMi0xMSAxOjEzIFBNPGJyPg0KVG86IFpob3VaaGlwZW5nPGJyPg0KQ2M6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBb Q0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8YnI+DQo8 YnI+DQpaaGlwZW5nLDxicj4NCjxicj4NCk9uIDEyIE9jdCAyMDExLCBhdCAxMDoyMiwgWmhvdVpo aXBlbmcgd3JvdGU6PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IZWxs byBCZW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhlIFVFIG1heSBzZWxlY3Qg dGhlIGNvbnRlbnQgZm9ybWF0IG9uIHRoZSBDUCB3ZWIuIEFmdGVyIHRoYXQgdGhlIHVzZXIgb25s eSBkZXNpcmVzIHRvIGdldCBoaXMgc2VsZWN0ZWQgY29udGVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CdXQgaG93IHRoZSBjb250ZW50IGlzIHRyYW5z ZmVycmVkIHRvIHRoZSBjbGllbnQgaXMgbm90IHdvcnJpZWQgYnkgdGhlIHVzZXIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhlIENQIG1heSBjcmVhdGUg YSBzcGVjaWFsIGZvcm1hdCBhcyByZXF1aXJlZCBieSB0aGUgdXNlciBhbmQgYXNrIHRoZSBDRE4g dG8gZGVsaXZlciB0byB1c2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPldoaWxlIENQIG1heSBnaXZlIGEgSEQgZm9ybWF0IGNvbnRlbnQgdG8gdUNETiBh bmQgdGhlIGRDRE4gbWF5IHRoZW4gdHJhbnNmb3JtIHRvIHRoZSBmb3JtYXQgYXMgdGhlIHVzZXIg c2VsZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KTG90cyBvZiB0aGluZ3MgbWF5IGJlIHBvc3NpYmxlIHRv IGRvIGFuZCBDRE4gcHJvdmlkZXJzIG9mZmVyIG1hbnkgYWRkaXRpb25hbCBzZXJ2aWNlcyBvbiB0 b3Agb2YgdGhlICZxdW90O2NvcmUmcXVvdDsgc2VydmljZSBvZiBjb250ZW50IGRlbGl2ZXJ5LiBI b3dldmVyLCBvdXIgb2JqZWN0aXZlIChiYXNlZCBvbiBteSBpbnRlcnByZXRhdGlvbiBvZiB0aGUg Q0ROSSBjaGFydGVyKSBpcyB0byBmb2N1cyBvbiB3aGF0IGlzIG5lY2Vzc2FyeSB0byBpbnRlcmNv bm5lY3QNCiBDRE5zIHRvIGRlbGl2ZXIgY29udGVudCBmcm9tIGEgQ1NQIHRvIGFuIEVuZCBVc2Vy IHRoYXQgaXMgdGFyZ2V0ZWQgYW5kIGRlcGxveWFibGUgd2l0aGluIGEgc2hvcnQgdGltZSBmcmFt ZSAoMTgtMjQgbW9udGhzKS48YnI+DQo8YnI+DQpDb250ZW50IHRyYW5zZm9ybWF0aW9uL2FkYXB0 YXRpb24gaXMgbm90IGFuIGVzc2VudGlhbCByZXF1aXJlbWVudCBpbiBvcmRlciB0byBhY2hpZXZl IHRoYXQgYWltICh3ZSBjYW4gZGVsaXZlciBjb250ZW50IGZyb20gQ1NQcyB0byBFbmQgVXNlcnMg dmlhIG11bHRpcGxlIENETnMgd2l0aG91dCBuZWVkaW5nIG9yIHJlcXVpcmluZyBhbnkgQ0ROIHN1 cHBvcnRzIGNvbnRlbnQgYWRhcHRhdGlvbikuPGJyPg0KPGJyPg0KSW4gbXkgb3BpbmlvbiB3ZSBo YXZlIGVub3VnaCB3b3JrIHRvIGRvIGFscmVhZHkgd2l0aG91dCB0cnlpbmcgdG8gZXhwYW5kIHRo ZSBzY29wZSBvZiBvdXIgd29yayB0byBpbmNsdWRlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIHRo YXQgZG8gbm90IGhlbHAgdXMgYWRkcmVzcyBvdXIgY29yZSBvYmplY3RpdmVzIGFzIGxhaWQgb3V0 IGluIHRoZSBDRE5JIGNoYXJ0ZXIuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5JbiB0aGlzIGNhc2UsIGl0IGlzIG5vdGhpbmcgcmVsYXRlZCB0byBob3cgdGhlIHVzZXIg c2VsZWN0IGZvcm1hdHMgb24gQ1Agd2Vic2l0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5TbywgaXQgaXMgdGhlIENQIGFuZCB1c2VyIHRvIGRlY2lkZSB0aGUgY29udGVudCBmb3Jt YXQgbm90IHRoZSBDRE4oeW91ciBhc3NlcnQgaXMgbm90IGNvcnJlY3QgYW5kIHNlZW1zIHlvdSB0 YWtlIHRoYXQgYXNzZXJ0IGFzIHlvdXIgYmFzZSBmb3IgdGhlIGRpc2N1c3Npb24pLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFzIGZvciAmcXVvdDt0aGUgY29y ZSBDRE4gZnVuY3Rpb25hbGl0eSBvZmZlcmVkIGJ5IENETnMgdG9kYXkmcXVvdDssIEkgaGF2ZSBl dmVyIHJhaXNlZCBhbiBlbWFpbCBiZWZvcmUgdGhhdCB5b3VyIGNvbXBhbnkncyB3ZWJwYWdlIGhh cyBjbGFpbWVkIHN1cHBvcnRpbmcgbWVkaWEgdHJhbnNmb3JtYXRpb24gYW5kIG11bHRpLXNjcmVl bg0KIHNlcnZpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+UGVyaGFwcywgSSBsaWtlIGFza2luZyB5b3UgbGlzdCBzb21lIGZlYXR1cmVzIHRoYXQgeW91 IGZlZWwgYXJlIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdGllcyBieSBleGlzdGluZyBtYWluIHN0cmVh bSBDRE5zLiBUaHVzIHdlIG1heSBjb21wYXJlIGFuZCB0YWtlIGRlZXAgbG9vay48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi Pjxicj4NCkkgdGhpbmsgdGhlIGNvcmUgZnVuY3Rpb25hbGl0eSBtYXBzIHByZXR0eSB3ZWxsIHRv IHRoZSBDRE5JIGludGVyZmFjZXMsIG5hbWVseTogUmVxdWVzdCBSb3V0aW5nLCBNZXRhZGF0YSBj b25maWd1cmF0aW9uLCBsb2cgcHJvZHVjdGlvbiBhbmQgY29udHJvbCBwbHVzIGNvbnRlbnQgYWNx dWlzaXRpb24gYW5kIGNvbnRlbnQgZGVsaXZlcnkuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5JIGd1ZXNzIG1hbnkgcGVvcGxlIGhhdmUgdGhlIGV4cGVyaWVuY2Uva25v d2xlZGdlIG9mIGNvbnRlbnQgcmVsYXRlZCBzZXJ2aWNlLiBUaGUgdXNlciBhbmQgQ1Agb25seSBj YXJlIHdoZXRoZXIgdGhlIENETiBwcm92aWRlcnMgbWF5IHNhdGlzZnkgdGhlaXIgcmVxdWlyZW1l bnQgd2hpbGUgbm90IGNhcmUNCiB0aGUgaW50ZXJuYWwgcHJvY2Vzcy4gSnVzdCBhcyBHU00vUFNU TiBpbnRlcmNvbm5lY3Rpb24sIHRoZSB1c2VyIG9ubHkgY2FyZSBzdWNjZXNzZnVsIGludGVyY29u bmVjdGlvbiB3aGlsZSBub3QgY2FyZSBob3cgdGhlIHZvaWNlIGlzIHRyYW5zZm9ybWVkIGluIHBy b2Nlc3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QmVzaWRlcywgSSBsaWtlIHJhaXNl IGEgY2FzZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5H aXZlbiBjdXJyZW50bHkgQkJDIHJlY3J1aXRzIENETiBwcm92aWRlcnMgdGhhdCBtYXkgc3VwcG9y dCAxMCBtZWRpYSBmb3JtYXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPk9uZSBjYW5kaWRhdGUgaXMgeW91ciBjb21wYW55LCBhbm90aGVyIGlzIENETi1Y LiBUaGUgdXNlcnMgYXJlIGxvY2F0ZWQgaW4gRnJhbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNvIGJvdGggeW91ciBjb21wYW55IGFuZCBDRE4tWCBz aG91bGQgY29ubmVjdCBhIEZyYW5jZSBDRE4gcHJvdmlkZXIoQ0ROLVkpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPklmIHlvdXIgY29tcGFueSdzIHNvbHV0 aW9uIGlzIHRvIHNlbmQgMTAgc3RyZWFtcyBvZiBkaWZmZXJlbnQgZm9ybWF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+b2Ygb25lIGNvbnRlbnQgdG8gQ0RO LVk7IFdoaWxlIENETi1YJ3Mgc29sdXRpb24gaXMgdG8gc2VuZCAxIHN0cmVhbSB0byBDRE4tWSB3 aGlsZSBDRE4tWSBtYXkgY29uZHVjdCBzb21lIGFkYXB0YXRpb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Q29tcGFyaW5nIHRoZXNlIHR3byBzb2x1dGlv bnMsIGZvciB5b3VyIGNvbXBhbnkgYW5kIENETi1YLCBhYnNvbHV0ZWx5IHRoZSBjb3N0IG9mIENE Ti1YIGlzIG11Y2ggbG93ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Rm9yIENETi1ZLCBpbiBzb2x1dGlvbi0xLCBpdCBzaG91bGQgcmVjZWl2ZS9mb3J3 YXJkIDEwIHN0cmVhbXMgOyB3aGlsZSBpbiBzb2x1dGlvbi0yLCBpdCBzaG91bGQgb25seSByZWNl aXZlIDEgc3RyZWFtIGJ1dCBuZWVkIHRvIHRha2UgdHJhbnNmb3JtYXRpb24gdG8gb3V0cHV0IDEw IHN0cmVhbXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+V2hp Y2ggc29sdXRpb24gaXMgbW9yZSBjb21wZXRpdGl2ZS4gaXQgaXMgU29sdXRpb24gMSwgcmlnaHQu IFJlbWVtYmVyIHRoZSBwcmljZSBmcm9tIEJCQyBpcyBzYW1lIHRvIGJvdGggeW91ciBjb21wYW55 IGFuZCBDRE4tWCBvciBCQkMgd291bGQgc2VsZWN0IG9uZSBDRE4gcHJvdmlkZXIgd2l0aCB0aGUN CiBsb3dlciBwcmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5JZiBhIENETiBwcm92aWRlciBtYXkgbm90IGdldCB0aGUgY29udHJhY3QgZnJvbSBDUCwg aG93IGl0IG1heSBzYXkgaXQgaXMgbm90IGEgY29yZSBmdW5jdGlvbmFsaXR5LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PGJyPg0KV2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgYSBwb3NzaWJsZSBvcHRpbWl6YXRpb24g dGhhdCBhIHBhcnRpY3VsYXIgQ0ROIG1heSB3aXNoIHRvIGltcGxlbWVudCBub3QgYSBjb3JlIGZ1 bmN0aW9uYWxpdHkgcmVxdWlyZWQgdG8gZW5hYmxlIGNvbnRlbnQgZGVsaXZlcnkgYmV0d2VlbiBp bnRlcmNvbm5lY3RlZCBDRE5zLiBJIGNhbiB0aGluayBvZiBtYW55IG9wdGltaXphdGlvbnMgdGhh dCBhIENETiBjb3VsZCBpbXBsZW1lbnQgdG8gZGlmZmVyZW50aWF0ZQ0KIHRoZWlyIHNlcnZpY2Ug YnV0IHRoZSBpbnRlcm5hbCB3b3JraW5ncyBvZiBhbiBpbmRpdmlkdWFsIENETiBhcmUgb3V0IG9m IHNjb3BlIG9mIG91ciBjaGFydGVyLjxicj4NCjxicj4NClNvIHRvIHJlcGVhdCBteSBwb3NpdGlv biBmb3IgYSBmaW5hbCB0aW1lOiBDb250ZW50IGFkYXB0YXRpb24gaXMgbm90IGEgY29yZSBmdW5j dGlvbiByZXF1aXJlZCB0byBlbmFibGUgY29udGVudCBkZWxpdmVyeSBiZXR3ZWVuIGludGVyY29u bmVjdGVkIENETnMgYW5kIHRoZXJlZm9yZSBnaXZlbiB0aGUgd29ya2xvYWQgd2UgYWxyZWFkeSBo YXZlIHRvIHNwZWNpZnkgc29sdXRpb25zIHRoYXQgZG8gYWRkcmVzcyB0aGUgY29yZSBmdW5jdGlv bmFsaXR5DQogcmVxdWlyZWQgdG8gaW50ZXJjb25uZWN0IENETnMgSSBkbyBub3QgdGhpbmsgd2Ug c2hvdWxkIGJlIHRyeWluZyB0byBhZGQgbW9yZSB3b3JrIGludG8gdGhhdCB3b3JrbG9hZCBhcyBp dCB3aWxsIG9ubHkgZGlzdHJhY3QgdXMgZnJvbSBhY2hpZXZpbmcgb3VyIGdvYWwgb2YgcHJvZHVj aW5nIGRlcGxveWFibGUgc29sdXRpb25zIHdpdGhpbiB0aGUgdGltZWZyYW1lIHdlIGFyZSBiZWlu ZyB0b2xkIGJ5IG9wZXJhdG9ycyB0aGV5IG5lZWRzIHNvbHV0aW9ucw0KIHdpdGhpbi48YnI+DQo8 YnI+DQpCZW48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNvLCBpZiB3 ZSBhbGwgcmVhbGl6ZSB0aGF0IGN1cnJlbnRseSB0aGUgbWVkaWEgdHlwZSBpcyByaWNoLCB0aGUg Q0ROIHByb3ZpZGVycyBzaG91bGQgc3Vydml2ZSBpbiB0aGUgZXhpc3RpbmcgZWNvc3lzdGVtIGFu ZCBzdXBwb3J0IHRoZSBtZWRpYSB0eXBlcyBhcyByZXF1aXJlZCBieSB0aGUgbWFya2V0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJhY2sgdG8gdGhlIGNhc2Ugb2YgR1NNL0cuNzExLCBp dCBqdXN0IHdoZW4gY29uY2VybmluZyB0aGUgaW50ZXJjb25uZWN0aW9uLCB0aGUgdHJhbnNmb3Jt YXRpb24gc2hvdWxkIGF0IG9uY2UgYmUgc29sdmVkLiBPdGhlcndpc2UgdGhlIGludGVyY29ubmVj dGlvbiBtYXkgbm90IGJlIG9wZXJhdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPkJyLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPkZyb206IEJlbiBOaXZlbi1KZW5raW5zIFttYWlsdG86YmVuQG5pdmVuLWplbmtp bnMuY28udWtdPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEyLCAyMDExIDEyOjE5IEFNPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VG86IFpob3VaaGlwZW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Q2M6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwaGlsaXAu ZWFyZGxleUBidC5jb20iPnBoaWxpcC5lYXJkbGV5QGJ0LmNvbTwvYT47PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjZG5pQGll dGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPlN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5aaGlwZW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPk9uIDExIE9jdCAyMDExLCBhdCAwNToxNiwgWmhvdVpoaXBlbmcgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZW4gYW5kIFBoaWxpcCw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPkkgbGlrZSB0byByZXNwb25kIHlvdXIgY29uY2VybiBpbiB0aGlzIG9uZSBlbWFpbDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+QmVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SSBmZWVsIHdoYXQgd2UgYXJlIG5vdyBk aXNjdXNzaW5nIGlzIHdoYXQgaXMgdGhlICZxdW90O2NvcmUmcXVvdDsgZnVuY3Rpb24gb2YgQ0RO LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+QXMgeW91IHNheSwgQ0ROIGlzIHVzZWQgdG8gZGVsaXZlciBjb250ZW50LiBUaGF0 IGlzIGFic29sdXRlbHkgY29ycmVjdCB0aGF0IHRoZSBkZWxpdmVyeSBjYXBhYmlsaXR5IGlzIHRo ZSBjb3JlIHJlcXVpcmVtZW50IGZvciBDRE4gc3lzdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+V2hpbGUgQ0ROIGlzIHVz ZWQgdG8gcHJvdmlkZSB0aGUgY29udGVudCBkZWxpdmVyeSBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+V2hhdCBt ZWFucyBzZXJ2aWNlLiBJdCBzaG91bGQgaW5jbHVkZSAmcXVvdDt0aW1lJnF1b3Q7ICZxdW90O2xv Y2F0aW9uJnF1b3Q7IGFuZCAmcXVvdDttZWRpYSB0eXBlJnF1b3Q7LCBldGMuIFRoZXNlIGZlYXR1 cmVzIGFyZSBhbGwgdGhlIGNvcmUgZmVhdHVyZSBmb3IgYSBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SWYgd2Ug b25seSBjb25jZXJuICZxdW90O2RlbGl2ZXJpbmcgb25lIGRhdGEgYmxvY2smcXVvdDssIEkgYW0g bm90IHN1cmUgd2hldGhlciB0aGUgaXNzdWVzIHN1Y2ggYXMgJnF1b3Q7bG9nZ2luZyZxdW90OyAm cXVvdDtnZW9ncmFwaGljIGNvbnN0cmFpbnQmcXVvdDsgYXJlIHRoZSBjb3JlIG9mIENETi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Rm9yICZxdW90O3dpdGhvdXQgZXhwbGljaXQga25vd2xlZGdlIG9m IHdoYXQgdGhhdCBjb250ZW50IGFjdHVhbGx5IGlzICZxdW90OywgSSBhbSBub3Qgc3VyZSB3aGV0 aGVyIHRoZSB3b3JkaW5nIGlzIGFjY3VyYXRlIHNpbmNlIGdlbmVyYWxseSBhIENETiBtYXkgY2xh aW0gaXQgc3VwcG9ydCBkaWZmZXJlbnQgbWVkaWFzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QnkgdGhpcyBvcHBvcnR1bml0 eSwgSSBsaWtlIHRvIHNoYXJlIGEgdXNlIGNhc2U6IGEgY2FsbCBmcm9tIGEgR1NNIHBob25lIHRv IGEgUFNUTiB0ZWxlcGhvbmUsIHRoZSB2b2ljZSBzdHJlYW0gc2hvdWxkIGJlIHRyYW5zZm9ybWVk IGZyb20gR1NNIHZvaWNlIHRvIEcuNzExLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Rm9yIHRoZSB1c2VyLCBoZSBkb2VzIG5v dCBuZWVkIHRvIGtub3cgd2hhdCB0eXBlIG9mIGRhdGEgaGFzIGJlZW4gdHJhbnNmZXJyZWQsIGJ1 dCB0aGUgb3BlcmF0b3IgaGFzIGRvbmUgc29tZSB3b3JrIHRvIGludGVyY29ubmVjdCB0d28gc3lz dGVtcywgcmlnaHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIGxpa2UgdG8ga25vdyB3aGV0aGVyIHlvdSBtYXkgYWNjZXB0 IHRoYXQgbXkgdXNlIGNhc2UgaXMgc2ltaWxhciB0byB0aGlzIGNhc2UgYWJvdmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SSBkb24n dCB0aGluayB5b3VyIHVzZSBjYXNlIGlzIHNpbWlsYXIgdG8gdGhlIGFuYWxvZ3kgb2YgbW9iaWxl IG5ldHdvcmtzIGJlaW5nIGludGVyY29ubmVjdGVkIHRvIFBTVE4gbmV0d29ya3MuIEluIHRoZSBj YXNlIG9mIGNvbnRlbnQgZGVsaXZlcnkgdGhlIG5lZ290aWF0aW9uIGlzIGRvbmUgYmV0d2Vlbg0K IHRoZSBVc2VyL0NsaWVudCBhbmQgdGhlIENvbnRlbnQgUHJvdmlkZXIgYW5kIHRoZSBDRE4gaXMg anVzdCB1c2VkIHRvIGV4ZWN1dGUvcGVyZm9ybSB0aGUgZGVsaXZlcnkgdGhhdCBoYXMgYmVlbiBu ZWdvdGlhdGVkLiBUaGUgQ0ROIGlzIG5vdCBpbnZvbHZlZCBpbiB0aGUgZGVjaXNpb24gbWFraW5n IG9mIHdoYXQgcmVwcmVzZW50YXRpb25zIHRoZSBDb250ZW50IFByb3ZpZGVyIGRlY2lkZXMgdG8g b2ZmZXIgdG8gdGhlIFVzZXIvQ2xpZW50IG9yIGluDQogd2hhdCByZXByZXNlbnRhdGlvbnMgdGhl IFVzZXIvQ2xpZW50IGRlY2lkZXMgdG8gcmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFzIGZvciB5b3Ugc2FpZCBzZWxlY3RpbmcgbWVkaWEgYnkg dGhlICZxdW90O3BvcnRhbCZxdW90OywgeW91IG1heSBzZWUgdGhlIHdheSAmcXVvdDsgdUNETiBk ZWxpdmVycyBtdWx0aXBsZSBtZWRpYSBzdHJlYW1zIHRvIGRDRE4mcXVvdDsgaXMgbm90IGdvb2Qg dGhhbiAmcXVvdDt1Q0ROIGRlbGl2ZXJzIG9uZSBtZWRpYSBzdHJlYW0gdG8gZENETg0KIGFuZCBk Q0ROIHRha2VzIHNvbWUgYWRhcHRhdGlvbiB0byBzdXBwb3J0IG11bHRpcGxlIG1lZGlhIHR5cGVz JnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPk5vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0IGlzIGFuIG9wdGltaXNhdGlv biwgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBhY3R1YWxseSBkZWxpdmVyIHRoZSBj b250ZW50IChhbmQgcmVwb3J0LCBiaWxsLCBldGMuIGZvciB0aGF0IGRlbGl2ZXJ5KS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5NeSBwb3NpdGlvbiBpcyB0aGF0 IHdlIHNob3VsZCBmb2N1cyBvbiBob3cgdG8gZW5hYmxlIHRoZSBpbnRlcmNvbm5lY3Rpb24gb2Yg dGhlIGNvcmUgQ0ROIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSBDRE5zIHRvZGF5ICh3aGljaCBp cyBhbHNvIG15IGludGVycHJldGF0aW9uIG9mIHRoZSBzY29wZQ0KIG9mIHRoZSBDRE5JIHdvcmtp bmcgZ3JvdXAgYXMgZXhwcmVzc2VkIGluIGl0cyBjaGFydGVyKSBiZWNhdXNlIGRvaW5nIHNvIGlz IGEgc2lnbmlmaWNhbnQgcGllY2Ugb2Ygd29yayBpbiBpdHNlbGYuIExldCdzIG5vdCBzdGFydCB0 cnlpbmcgdG8gYWRkIGluIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBiZXlvbmQgd2hhdCB0aGUg bWFqb3JpdHkgb2YgQ0ROcyBzdXBwb3J0IHRvZGF5IGFzIHRoYXQgd2lsbCBqdXN0IGRlbGF5IHVz IGdldHRpbmcgdXNhYmxlDQogc3BlY2lmaWNhdGlvbnMgaW50byB0aGUgbWFya2V0IGluIGEgdGlt ZWx5IGZhc2hpb24gSU1PLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPkJlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QSBn b29kIHF1ZXN0aW9uIGlzICZxdW90O3NlY3VyaXR5JnF1b3Q7IHNpbmNlIEkgaGF2ZSBkb25lIHNp eCB5ZWFycyBvbiB0aGUgRFJNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5hbmQgbGlrZSB0byBwcm9tb3RlIHRoZSBEUk0gYWxs IGFyb3VuZCB0aGUgd29ybGQ6KSBJZiB0aGUgY29udGVudCBpcyBuZWVkZWQgdG8gYmUgcHJvdGVj dGVkLCBnZW5lcmFsbHkgeW91IG1heSBrbm93IGFsbCB0aGUgc3lzdGVtcyBzaG91bGQgYmUgZ3Jh bnRlZCBieSB0aGUgY29udGVudCBvd25lci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhlcmUgSSBhbHNvIGxpa2UgdG8gY2xh cmlmeSB0aGF0IG5vdCBvbmx5IHRoZSBtZWRpYSBpdHNlbGYgYnV0IHRoZSBpbmZvcm1hdGlvbiBy ZWxhdGVkIHRvIHNlcnZpY2UgaXRzZWxmIChzdWNoIGFzIHRoZSBnZW9ncmFwaGljIGNvbnN0cmFp bnQpIHNob3VsZCBiZSBwcm90ZWN0ZWQgYWxzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNvLCB0cnVzdCBpcyBub3QgYSBw cm9ibGVtIGZvciB0aGUgbWVkaWEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlBoaWxpcCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PlRoYW5rIHlvdSB0aGF0IHlvdSBmZWVsIENvbnRlbnQgQWRhcHRpb24gaXMgYW4gaXNzdWUgZm9y ICZxdW90O1JlcXVpcmVtZW50cyZxdW90OyBidXQgSSBkbyBub3Qga25vdyB3aHkgaXQgaXMgbm90 IGZvciBVc2UgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgbGlrZSB0byBjbGFyaWZ5IHRvIFUgdGhhdCBpdCBpcyBp bXBvcnRhbnQgZm9yIHlvdSBvcGVyYXRvciBzaW5jZSBpdCBtYXkgc2F2ZSBpbnZlc3RtZW50IGlm IHRoZSBzeXN0ZW0gbWF5IHN1cHBvcnQgZGlmZmVyZW50IHNlcnZpY2VzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Rm9yIHVz IHZlbmRvciwgd2UgYXJlIGhhcHB5IG9wZXJhdG9yIG1heSBpbnN0YWxsIGEgc3lzdGVtIGZvciB0 aGUgbW9iaWxlIHNlcnZpY2UgYW5kIGFub3RoZXIgc3lzdGVtIGZvciB0aGUgRkJCIHNlcnZpY2Uu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5CdXQgdGhlIHJlYWxpdHkgaXMgYWxsIG9wZXJhdG9ycyBhc2sgdXMgdG8gcHJvdmlk ZSBhIHN5c3RlbSB0aGF0IG1heSBzdXBwb3J0IGRpZmZlcmVudCBzZXJ2aWNlIHN5c3RlbXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkZyYW5rbHksIEJlbiBhbmQgUGhpbGlwLCBJIHJlbWVtYmVyIEkg aGF2ZSBleHBsYWluZWQgc29tZXdoZXJlIHRoYXQgdG8gaW1wbGVtZW50IHRoaXMgaXMgcmF0aGVy IHNpbXBsZSAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5BdCBsZWFzdCB0aGUgVXNlIGNhc2UgYW5kIFJlcXVpcmVtZW50IGFy ZSBpbmZvcm1hdGlvbmFsIHRvIGJlIHJlZmVycmVkIGluIGZ1dHVyZSB3b3JrLiBTbyBJIGRvIHJl YWxseSBmZWVsIHlvdSBtYXkgYWNjZXB0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+T2YgY291cnNlIEkgbGlrZSB0byBy ZXNwb25kIHlvdXIgbW9yZSBjb25jZXJuIGFuZCBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoYW5rcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gcm9tOjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbGlw LmVhcmRsZXlAYnQuY29tIj5waGlsaXAuZWFyZGxleUBidC5jb208L2E+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlttYWlsdG86cGhpbGlwLmVhcmRsZXlA YnQuY29tXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+U2VudDogTW9uZGF5LCBPY3RvYmVyIDEwLCAyMDExIDExOjIyIFBNPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrIj5iZW5Abml2ZW4tamVua2lu cy5jby51azwvYT47IFpob3VaaGlwZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmci PmNkbmlAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TdWJqZWN0OiBSRTogW0NETmldIEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJl biwgWmhpcGVuZywgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIHRoaW5rIHRoYXQgQ29udGVu dCBBZGFwdGF0aW9uIGlzIG1vcmUgYW4gaXNzdWUgZm9yIHRoZSBSZXF1aXJlbWVudHMgZG9jIHRo YW4gZm9yIHRoZSBVc2UgY2FzZXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBrZXkg cXVlc3Rpb24gaXMgd2hldGhlciB3ZSB3YW50IHRoZSBDRE5JIGludGVyZmFjZXMgdG8gYmUgYWJs ZSB0byBjb3BlIHdpdGggYSBzY2VuYXJpbyB3aGVyZSAoc2F5KSBIRC9TRCBjb252ZXJzaW9uIGlz IGRvbmUgaW4gdGhlIGRDRE4gJmFtcDsgdG8gc2lnbmFsIGFib3V0IHRoaXMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPkkgdGhpbmsgdGhhdCBjb3Bpbmcgd2l0aCB0aGlzIHNjZW5hcmlvIGlzIGEgc2Vj b25kIG9yZGVyIHJlcXVpcmVtZW50LCBpZSB3ZSBzaG91bGQgbm90IHdvcnJ5IGFib3V0IGl0IGlu IHRoZSBpbml0aWFsIHN0YW5kYXJkcy10cmFjayB3b3JrLiBJIGRvbid0IGtub3csIGRpZCB3ZSBl dmVyIGRlY2lkZQ0KIHdoZXRoZXIgdGhlIFVzZSBjYXNlcyBkb2MgaXMgcmVzdHJpY3RlZCB0byAm cXVvdDtpbml0aWFsJnF1b3Q7IHNjZW5hcmlvcywgb3Igd2hldGhlciBpdCdzIGFsbC1lbmNvbXBh c3NpbmcsIGllIGNvdmVyaW5nICZxdW90O2Z1dHVyZSZxdW90OyBzY2VuYXJpb3MgYXMgd2VsbD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+U2NvdHQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5SZWFkaW5nIHNvbWUgb2YgeW91ciBl eGFtcGxlcywgdGhleSBzZWVtIHRvIGJlIHZhbGlkIGV2ZW4gaWYgY29udGVudCBhZGFwdGF0aW9u IChIRC9TRCkgaXMgb3V0IG9mIHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LSBhIGRDRE4gbWlnaHQgZm9yIHNvbWUg cmVhc29uIGJlIHVud2lsbGluZyB0byBkaXN0cmlidXRlIEhEPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LSBhIENTUCBtaWdo dCB3YW50IHRvIG1ha2Ugc3VyZSB0aGUgZENETiBjYW4gdXNlIEhMUyBlbmNhcHN1bGF0aW9uPzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+QnV0IHRoZXNlIHNvcnRzIG9mIGV4YW1wbGVzIHNlZW0gdG8gYmUgc3RhdGljIHBvbGlj eSB0aGluZ3MgKHRvIGRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij53aXRoIHRoZSBjYXBhYmlsaXRpZXMgJmFtcDsgcHJlZmVy ZW5jZXMgb2YgdGhlIENETnMgJmFtcDsgQ1NQKSwgcmF0aGVyIHRoYW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPm1ldGFkYXRh IGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgcGllY2Ugb2YgY29udGVudC4gSW4gdGhlPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5kaXNjdXNzaW9uIHNvIGZhciwgSSB0aGluayBuZWdvdGlhdGlvbiBhYm91dCBzdGF0aWMg cG9saWN5IHN0dWZmIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5yYXRoZXIgb3V0IG9mIHNjb3BlKD8pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPk9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbiBpbnRlcmVzdGluZyBxdWVz dGlvbiBpcyB3aGV0aGVyIHRydXN0IGlzIHRyYW5zaXRpdmUuIERvbid0IHRoaW5rIGl0IG5lZWQg YmUgLSBqdXN0IGJlY2F1c2UgQ1NQIHRydXN0cyB1Q0ROLCBhbmQgdUNETiB0cnVzdHMgZENETiBk b2Vzbid0IG1lYW4NCiB0aGF0IHRoZSBDU1AgYXV0b21hdGljYWxseSB0cnVzdHMgdGhlIGRDRE4u IEhvd2V2ZXIsIGkgc3VzcGVjdCB0aGlzIGNhbiBnZXQgYXJiaXRyYXJpbHkgY29tcGxleCAtIHNv IG9uZSBwb3NzaWJpbGl0eSBpcyB0byBzYXkgdGhhdCB3ZSB3aWxsIG9ubHkgaGFuZGxlIGNhc2Vz IHdoZXJlIHRoZSB0cnVzdCBpcyB0cmFuc2l0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZXN0 IHdpc2hlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+cGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlBo aWxpcCBFYXJkbGV5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5SZXNlYXJjaCBhbmQgVGVjaG5vbG9neSBTdHJhdGVneTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5UaGlzIGVtYWlsIGNvbnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3aGlj aCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIEl0J3MgbWVhbnQgb25seSBmb3Ig dGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB5b3UncmUgbm90IHRo ZSBpbnRlbmRlZCByZWNpcGllbnQsDQogbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcsIGRp c3RyaWJ1dGluZyBvciB1c2luZyB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlv dSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgbGV0IG1lIGtub3cgaW1t ZWRpYXRlbHkgb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4gV2UgbW9uaXRv ciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5b3VyIGVtYWlscy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJy aXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+UmVnaXN0ZXJlZCBvZmZpY2U6IDgx IE5ld2dhdGUgU3RyZWV0IExvbmRvbiBFQzFBIDdBSiBSZWdpc3RlcmVkIGluPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Fbmds YW5kIG5vOiAxODAwMDAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjZG5pLWJvdW5jZXNAaWV0 Zi5vcmciPmNkbmktYm91bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddDQog T24gQmVoYWxmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5PZiBCZW4gTml2ZW4tSmVua2luczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U2VudDogMTAgT2N0 b2JlciAyMDExIDEyOjA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UbzogWmhvdVpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkNjOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlN1YmplY3Q6IFJlOiBbQ0RO aV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Q29sbGVhZ3Vlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SU1PIFNlY3Rpb24g NS4xLjMgc2hvdWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgVXNlIENhc2VzIGRyYWZ0LiBDb250ZW50 IEFkYXB0YXRpb24gKGkuZS4gdGFraW5nIGluIGEgY29udGVudCBpdGVtIGluIG9uZSBmb3JtYXQg YW5kIHRyYW5zZm9ybWluZyBpdCB0byBhbm90aGVyIGZvcm1hdCBvciByZXByZXNlbnRhdGlvbikN CiBpcyBub3QgYSAmcXVvdDtjb3JlJnF1b3Q7IGZ1bmN0aW9uIG9mIGEgQ0ROIHdoaWNoIHR5cGlj YWxseSBkZWxpdmVycyB0aGUgY29udGVudCB0aGF0IGlzIHJlcXVlc3RlZCB3aXRob3V0IGV4cGxp Y2l0IGtub3dsZWRnZSBvZiB3aGF0IHRoYXQgY29udGVudCBhY3R1YWxseSBpcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+TGV0J3Mgbm90IGZvcmdldCB0aGF0IGluIGJ1aWxkaW5nIGFuIGVuZCB0byBl bmQgY29udGVudCBzZXJ2aWNlIHRoZSBDRE4gaXMgb25seSBvbmUgY29tcG9uZW50IGFuZCBpcyB0 aGUgY29tcG9uZW50IHRhc2tlZCB3aXRoIGV4ZWN1dGluZyB0aGUgZGVsaXZlcnkgb2YgYSBzcGVj aWZpYyByZXByZXNlbnRhdGlvbg0KICh2ZXJzaW9uL2NvcHkvZm9ybWF0IGV0Yy4pIG9mIHRoZSBz ZWxlY3RlZCBjb250ZW50IG5vdCB0aGUgY29tcG9uZW50IHRhc2tlZCB3aXRoIGRlY2lkaW5nIChv ciBhcHBseWluZyBwb2xpY3kpIG9uIHdoaWNoIHZlcnNpb24vY29weS9yZXByZXNlbnRhdGlvbiBv ZiBjb250ZW50IHNob3VsZCBiZSBkZWxpdmVyZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBk ZWNpc2lvbiBhcyB0byB3aGljaCB2ZXJzaW9uL2NvcHkvcmVwcmVzZW50YXRpb24gdG8gb2ZmZXIg YW5kIGFsbG93IHRvIGJlIGRlbGl2ZXJlZCB0byBhIGdpdmVuIGRldmljZS91c2VyIGlzIGltcGxl bWVudGVkIG91dHNpZGUgb2YgdGhlIENETiAoZS5nLiBieSB0aGUgJnF1b3Q7cG9ydGFsJnF1b3Q7 IHdoZXJlDQogdGhlIHVzZXIgZmlyc3QgbWFrZXMgdGhlaXIgY29udGVudCBzZWxlY3Rpb24gcHJp b3IgdG8gdGhlIENETiBiZWNvbWluZyBpbnZvbHZlZCBpbiB0aGUgZGVsaXZlcnkgb2YgdGhlIHNl bGVjdGVkIGNvbnRlbnQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZW48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+T24gOCBPY3QgMjAxMSwgYXQgMDg6MjAsIFpob3VaaGlwZW5nIHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPkZvbGxvd2luZyBTY290dCdzIGNvbW1lbnRzIG9uIHNlY3Rpb24gNS4x LjMsIEkgZmVlbCBTY290dCdzIGRlc2NyaXB0aW9uIG9uIHRoZSB1c2UgY2FzZSBvZiBIRCBhbmQg U0QgaXMgbm90IGV4YWN0bHkgY29ycmVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SWYgb25l IG1vdmllIGhhcyB0d28gZm9ybWF0cyBvZiBIRCBhbmQgU0QsIHRoZW4gd2UgaGF2ZSB0d28gY29u dGVudCB3aXRoIGRpZmZlcmVudCBpZGVudGlmaWVyLiBJbiBEUk0gc2NvcGUsIHRoZSBiYXNpYyB1 bml0IGlzIGEgY29udGVudCBjb3B5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+SGVyZSB0aGUgZmlyc3QgYnVsbGV0ICZxdW90O2Egc3Vic2V0 IG9mIGVuY29kaW5ncyBkZWxpdmVyYWJsZSB0byBzcGVjaWZpYyBkZXZpY2VzLCZxdW90OyBoYXMg bGlzdGVkIHRoZSBjYXNlIG9mIGNvbnRlbnQgYWRhcHRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+SW4gbGFzdCBtb250aCwgSSBoYXZlIGNvbnRhY3RlZCB0aGUgQXV0aG9ycyBvZiB0aGlz IGRvY3VtZW50IGFuZCB0YWtlbiBzb21lIGVtYWlsIGV4Y2hhbmdlcyB3aXRoIEdyYW50IGFuZCBQ aGlsaXAgKEJUKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SSBoYXZlIHNob3duIEJUIHdpdGgg c29tZSBpbmZvcm1hdGlvbiB0aGF0IEkga25vdyBpbiB0aGlzIGNhc2UgYW5kIGFyZWEgdG8gZXhw bGFpbiB0aGUgY29udGVudCBmbGV4aWJpbGl0eSBpcyBjdXJyZW50bHkgYSBiYXNpYyByZXF1aXJl bWVudCBmb3IgQ0ROIHNlcnZpY2UgYW5kIHJlbGF0ZWQgbmVnb3RpYXRpb24NCiBpcyBuZWVkZWQg aW4gdGhlIENETiBpbnRlcmNvbm5lY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk1lYW53 aGlsZSwgSSBzaG91bGQgYWxzbyBpbnZpdGUgeW91IGluIHRoaXMgZ3JvdXAgcmFpc2luZyB5b3Vy IGNvbW1lbnRzIG9yIHF1ZXN0aW9ucyBvbiB0aGlzIGNhc2Ugc2luY2UgSSBob3BlIG15IHVzZSBj YXNlIG1heSBiZSBpbmNvcnBvcmF0ZWQgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SWYgeW91IGhhdmUg YW55IG1vcmUgcXVlc3Rpb24gb3IgY29tbWVudHMsIHBscyBzaGFyZSBpbiB0aGlzIHRocmVhZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5a aGlwZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkZyb206IFNjb3R0IFdhaW5u ZXIgW21haWx0bzpzd2Fpbm5lckBjaXNjby5jb21dPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNl bnQ6IEZyaWRheSwgU2VwdGVtYmVyIDMwLCAyMDExIDg6MDIgQU08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5TdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TZWN0aW9uIDIuMyBOb21hZGljIFVzZXJzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPlRoaXMgZGVzY3JpcHRpb24gZmFsbHMgdW5kZXIgdGhlIGNhdGVnb3J5 IG9mIEdlb2dyYXBoaWMgRXh0ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnlldCB0aGUg dGhpcmQgcGFyYWdyYXBoIHN0YXRlcyB0aGUgY2FzZSB3aGVyZSBhIGRpZmZlcmVudCBkZXZpY2Ug aXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+dXNlZCBpbiB0aGUgc2FtZSBDRE4gY292ZXJhZ2Ug YXJlYS4gJm5ic3A7VGhlIGludGVudCBvZiB0aGlzIHVzZSBjYXNlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPm5lZWRzIHRvIGJlIGNsYXJpZmllZC4gJm5ic3A7UGVyaGFwcyB0aGUgdXNlIGNhc2Ug aXMgdHJ5aW5nIHRvIGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+dGhlIHNjZW5hcmlv IHdoZXJlIGEgTm9tYWRpYyBVc2VyLUEgd2l0aCBhbiBhZ3JlZW1lbnQgYWxsb3dpbmc8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+YWNjZXNzIHRvIGNvbnRlbnQgZnJvbSBDU1AtQSB2aWEgdUNETiBt b3ZlcyB0byBhIGRDRE4gaW4gYSBkaWZmZXJlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+cmVn aW9uLiAmbmJzcDtUaGUgZENETiBpcyBhbGxvd2VkIHRvIGRpc3RyaWJ1dGUgdGhlIGNvbnRlbnQg b2YgQ1NQLUEgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VXNlci1BOyBob3dldmVyLCBub3Qg b3RoZXIgdXNlcnMgaW4gdGhlIHJlZ2lvbiBvZiB0aGUgZENETiBhcmU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+YWxsb3dlZCB0byByZXRyaWV2ZSB0aGUgY29udGVudCB1bmxlc3MgdGhleSB0b28g aGF2ZSBzdWNoIGFuIGFncmVlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNlY3Rpb24gNS4xLjMgQ29udGVudCBFbmNvZGluZyBSZXN0 cmljdGlvbnMgTmVlZCB0byBjbGFyaWZ5IGlmIHdlJ3JlPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PnRhbGtpbmcgYWJvdXQgdGhlIHJlc3RyaWN0aW9ucyBvbiB0aGUgZGVsaXZlcnkgb2Ygc3BlY2lm aWMgY29udGVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5vciB0aGUgcmVzdHJpY3Rpb25zIG9u IHRoZSBhYmlsaXR5IG9mIGEgQ0ROIHRvIGRlbGl2ZXIgc3BlY2lmaWM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Y29udGVudC4gJm5ic3A7SSBjZXJ0YWlubHkgdW5kZXJzdGFuZCB0aGUgY2FzZSB3 aGVyZSBhIENTUCB3aWxsIHJlc3RyaWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnRoZSBkaXN0 cmlidXRpb24gb2YgY29udGVudCB0byBhICZxdW90O21hbmFnZWQgcGF0aCZxdW90OyBpZiBzdWNo IGNvbnRlbnQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SEQgd2hpbGUgYWxsb3dpbmcgdGhl IGNvbnRlbnQgZGlzdHJpYnV0aW9uIHZpYSBhbiB1bi1tYW5hZ2VkIHBhdGggaWY8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+c3VjaCBjb250ZW50IGlzIFNEIChzYW1lIGNvdWxkIGFwcGx5IHRvIGVu Y3J5cHRpb24gbWV0aG9kcywgZGVsaXZlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+bWV0aG9k cywgZXRjLikuICZuYnNwO09uIHRoZSBjb250cmFyeSwgdGhlIGRDRE4gbWF5IGhhdmUgaXRzIG93 bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5yZXN0cmljdGlvbnMgb2YgYmxvY2tpbmcgdGhlIGRp c3RyaWJ1dGlvbiBvZiBIRCBjb250ZW50IHdoaWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmFs bG93aW5nIHRoZSBkaXN0cmlidXRpb24gb2YgU0QgY29udGVudC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPm8gZmlyc3QgYnVsbGV0IG1ha2Vz IHNlbnNlIGlmIHRoZSBkQ0ROIGNhbiBwZXJmb3JtIGEgc3Vic2V0IG9mPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPmVuY2Fwc3VsYXRpb25zIGZvciBhIHJlZmVyZW5jZSBzZXQgb2YgbWVkaWEgKGUu Zy4gSExTLCBIU1MsIGJ1dCBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+REFTSCkgbyBzZWNv bmQgYnVsbGV0IG1ha2VzIHNlbnNlIHdoZXJlIHRoZSBkQ0ROIGRvZXNuJ3Qgd2FudCB0bzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5vZmZlciBoaWdoIGJpdC1yYXRlIHZhcmlhbnRzIG9mIHRoZSBt ZWRpYSBvIHRoaXJkIGJ1bGxldCBtYWtlIHNlbnNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmlm IHRoZSBwb2xpY3kgYWRkcmVzc2VzIFFvRSBidXQgSSBkb24ndCB0aGluayBzdWJzY3JpYmVyPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPnJpZ2h0cy9hdXRob3JpemF0aW9ucyBhcHBseS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNlY3Rpb24g MTAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFzaWRlIGZyb20gdGhlIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIFdJVEhJTiB0aGUgdUNETiBhbmQgZENETiwgSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij50aGluayB3ZSBjYW4gZGVzY3JpYmUgdGhpcyBpbiBmb3VyIGNvbnRleHRzOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+YS4gVGhlIHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIHRoZSBDU1AgYW5kIHRoZSB1Q0ROICh0aGUgcHJpbmNpcGxlIGNvbnRy YWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmFycmFuZ2VtZW50IGZvciBkaXN0cmlidXRpb24p PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmIuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUg dUNETiBhbmQgZENETiAodGhlIHRyYW5zaXRpdmUgdHJ1c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+cmVsYXRpb25zaGlwIHRoYXQgZXh0ZW5kcyB0aGUgY29udHJhY3QgZGVmaW5lZCBpbiAoYSkg YWJvdmUpIGMuIFRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5yZWxhdGlvbnNoaXAgYmV0d2Vl biB0aGUgVXNlciBhbmQgZENETiAodGhlIHJlY29nbml0aW9uIG9mIHJpZ2h0IHRvPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPmRvd25sb2FkIHByZWRpY2F0ZWQgb24gKGIpIGFib3ZlKSBkLiBUaGUg cmVsYXRpb25zaGlwIGJldHdlZW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlVzZXIgYW5k IENTUCAodGhlIGNvbnRyYWN0IGF1dGhvcml6aW5nIHRoZSB1c2VyIGFjY2VzcyB0byB0aGU8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Y29udGVudCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSB1c2VyIGlzIG5vdCBpbnRlcmVzdGVkIGlu IHRoZSBhLWIgbm9yIHRoZSBiLWMgcmVsYXRpb25zaGlwLiBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+dXNlciBpcyBvbmx5IGludGVyZXN0ZWQgaW4gdGhlIHRyYW5zcGFyZW5jeSBhbmQgaW50 ZXJvcGVyYWJpbGl0eSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij50aGUgc2VjdXJpdHkgcmVs YXRpb25zaGlwIGJldHdlZW4gZC1iIG9yIGQtYyB0byB0aGUgcG9pbnQgdGhhdCB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+YXV0aG9yaXphdGlvbiBncmFudGVkIGluIGQtYSBpcyB2aWFibGUg d2hlbiB0aGUgZGVsaXZlcnkgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+aW5pdGlhdGVkIHZp YSBlaXRoZXIgZC1iIG9yIGQtYy4gJm5ic3A7QXMgYW4gZXhhbXBsZSwgdGhlIHVDRE4gbWlnaHQg dXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlVSTCBhcHBlbmRlZCB0b2tlbnMgZm9yIGF1dGhl bnRpY2F0aW9uIHdoaWxlIGRDRE4gbWlnaHQgdXNlIFVSTDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5hcHBlbmRlZCBoYXNoZXMuICZuYnNwO1RoZSB1c2VyIGRvZXNuJ3Qgd2FudCB0byBrbm93IGFi b3V0IHRoZSBkaXN0aW5jdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5tZXRob2RzLCBidXQgdHJh bnNwYXJlbmN5IGlzIG9ubHkgYWZmb3JkZWQgaWYgdGhlIG1ldGhvZHMgYXJlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPmludGVyb3BlcmFibGUgY2xlYXJseSBkZWZpbmVkIHdoZW4gdGhlIGRlbGVn YXRpb24gZm9yIGNvbnRlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ZGVsaXZlcnkgaXMgZXhl Y3V0ZWQuICZuYnNwO0NsZWFybHksIHRoZSBjaG9pY2Ugb2YgYXV0aGVudGljYXRpb24gbWV0aG9k IGlzIGRldGVybWluZWQgYnkgdGhlIHJlc3BlY3RpdmUgQ0ROJ3MuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TY290dDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ Q0ROaSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0ibWFpbHRv OkNETmlAaWV0Zi5vcmciPkNETmlAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Q0ROaSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1h aWx0bzpDRE5pQGlldGYub3JnIj5DRE5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNE TmkgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNETmlAaWV0Zi5vcmciPkNETmlA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jZG5pIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk8 L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpDRE5pIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDRE5pQGlldGYub3Jn Ij5DRE5pQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jZG5pPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0ROaSBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q0ROaUBpZXRmLm9yZyI+Q0ROaUBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmki Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaTwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --Boundary_(ID_hHpHkybtF26E+Cm0tV/cDw)-- From zhouzhipeng@huawei.com Mon Oct 31 02:05:32 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B112B21F8CD6 for ; Mon, 31 Oct 2011 02:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.734 X-Spam-Level: X-Spam-Status: No, score=-4.734 tagged_above=-999 required=5 tests=[AWL=-0.536, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhL5uIQ-BN-6 for ; Mon, 31 Oct 2011 02:05:28 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id C889521F8CD4 for ; Mon, 31 Oct 2011 02:05:22 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTX00DSXAKE8O@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 31 Oct 2011 17:05:02 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTX000PLAKEU2@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 31 Oct 2011 17:05:02 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV19854; Mon, 31 Oct 2011 17:04:36 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 31 Oct 2011 17:04:35 +0800 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.117]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 17:04:29 +0800 Date: Mon, 31 Oct 2011 09:04:28 +0000 From: ZhouZhipeng X-Originating-IP: [10.138.73.38] To: Francois Le Faucheur Message-id: <260A32EFD5C9EB47AD504929D005DF6217F6D1F9@SZXEML519-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Zh3zl81PPMd5qfCfpzFruA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65WWIlhggAAKpqA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> <144D124A-E8A2-48DC-A98D-6F33B2EB1B90@cisco.com> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:05:32 -0000 --Boundary_(ID_Zh3zl81PPMd5qfCfpzFruA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 U29ycnksIG5vdCBLUE4uIEl0IGlzIFJheSBmcm9tIFROTy4NClpoaXBlbmcNCg0KDQpGcm9tOiBa aG91WmhpcGVuZw0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDMxLCAyMDExIDQ6NDkgUE0NClRvOiAn RnJhbmNvaXMgTGUgRmF1Y2hldXInDQpDYzogY2RuaUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtD RE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQpEZWFy IEZyYW5jb2lzLCBhbmQgYWxsLA0KVGhhbmtzIGZvciBhbGwgdGhlIGdyb3Vw4oCZcyBhdHRlbnRp b24gb24gdGhpcyB0b3BpYy4NCkkgYW0gYWxzbyBoYXBweSB0aGF0IG15IHByb3Bvc2FsIGhhcyBn b3R0ZW4gc28gbXVjaCB2YWx1YWJsZSByZXNwb25zZS9xdWVzdGlvbnMvIGNvbW1lbnRzLg0KVGhh dCB3aWxsIGJlIHZlcnkgaGVscGZ1bCBmb3IgYWxsIG9mIHVzIHRvIGNhdGNoIGEgY29tcGxldGUg dW5kZXJzdGFuZGluZyBhbmQgc29sdXRpb24gZm9yIHRoaXMgbWFya2V0IGRlbWFuZC4NCldoaWxl IEkgZmVlbCB0aWxsIG5vdyB0aGUgdG9waWMgaXRzZWxmIGhhcyBub3QgYmVlbiBjb21wbGV0ZWx5 IGFuYWx5emVkIGFuZCBJIGFtIGJ1c3kgZG9pbmcgdGhlIHdvcmsuIEkgd2lsbCBleHBvc2UgbXkg Y29udHJpYnV0aW9uIHNvb24gYWZ0ZXIgSSBjb21wbGV0ZSB0aGF0IHdvcmsuDQpNZWFud2hpbGUg SSBob3BlIHRoZSBncm91cCBtYXkgYWxsb3cgc29tZSBtb3JlIHRpbWUgZm9yIHBlb3BsZSB0byBj b25zaWRlciBpdC4gUGVyaGFwcyBzb21lIG1vcmUgcGVvcGxlIHdpbGwgZW1lcmdlIGluIHRoZSBn cm91cCBtYWlsIGxpc3QuDQpDdXJyZW50bHksIHNvbWUgcGVvcGxlIGhhcyBjbGFpbWVkIHRoZWly IHByZWZlcmVuY2UuICBJIGZlZWwgcGVyaGFwcyBub3QgYSBmZXcgcGVvcGxlIGhhdmUgc3VwcG9y dGVkIHRoaXMgdXNlIGNhc2UodGhlIGF1dGhvcnMgb2YgZHJhZnQtZm1uLWNkbmktYWR2YW5jZWQt dXNlLWNhc2VzLTAwLCBBbGFuIGZyb20gRXJpY3Nzb24sIENoaW5hTW9iaWxlLCBDaGluYXRlbGVj b20sICBwZXJoYXBzIGFsc28gS1BOLCBhbmQgbWUpLg0KDQpJIGhhdmUgZXhwbGFpbmVkIHRoYXQg Zm9yIENETi1BIGFuZCBDRE4tQiwgdGhleSBtYXkgbmVnb3RpYXRlIHdoZXRoZXIgdG8gc3VwcG9y dCB0aGUgQ0ROSSBhZGFwdGF0aW9uIHNvbHV0aW9uLiBIZW5jZSBzdWNoIG9wdGlvbmFsIGFycmFu Z2VtZW50IHdpbGwgb25seSBicmluZyBiZW5lZml0IHdoZW4gYm90aCB1cHN0cmVhbSBhbmQgZG93 bnN0cmVhbSBhZ3JlZXMgdGhhdCBhdCB0aGVpciBhcHByb3ByaWF0ZSBzaXR1YXRpb24uDQoNClNv LCBJIHNpbmNlcmVseSBzdWdnZXN0IHR3byBDaGFpcnMgYW5kIHRoZSB3aG9sZSBncm91cCBtYXkg YWxsb3cgc29tZSBtb3JlIGRheXMgZm9yIHRoaXMgdG9waWMuICAgSSBzdWdnZXN0IGFmdGVyIHRo ZSBUYWlwZWkgbWVldGluZyAuDQpCeSB0aGVuIHdlIGFsbCB3aWxsIGdldCBhIGNsZWFyZXIgdW5k ZXJzdGFuZGluZyBhbmQgZGVjaXNpb24uDQoNClRoYW5rcy4NClpoaXBlbmcNCg0KDQoNCkZyb206 IEZyYW5jb2lzIExlIEZhdWNoZXVyIFttYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tXQ0KU2VudDog RnJpZGF5LCBPY3RvYmVyIDI4LCAyMDExIDk6NTAgUE0NClRvOiBaaG91WmhpcGVuZw0KQ2M6IGNk bmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1j ZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KSGkgYWdhaW4gWmhpcGVuZywNCg0KVGhlcmUgaXMgb25l IG90aGVyIHBvaW50IEkgc2hvdWxkIGhhdmUgYnJvdWdodCB1cCBpbiBteSBwcmV2aW91cyBtZXNz YWdlOg0KVGhlIHF1ZXN0aW9uIGlzIG5vdCBzbyBtdWNoIHdoZXRoZXIgdGhlcmUgYXJlIGJlbmVm aXRzIHRvIGFsbG93aW5nIGNvbnRlbnQgYWRhcHRhdGlvbiBmb3Igc29tZSBlbnZpcm9ubWVudHMs IG5vciB3aGV0aGVyIG9uZSBwYXJ0aWN1bGFyIGluZGl2aWR1YWwgY291bGQgY29uY2VpdmUgYW4g YXBwcm9hY2ggZm9yIGNvbnRlbnQgYWRhcHRhdGlvbiB0aGF0IHN1aXRzIGhpbS4gVGhlIHF1ZXN0 aW9uIGhlcmUgaXMgcmF0aGVyIHdoZXRoZXIgaXQgaXMganVzdGlmaWVkIGZvciB0aGUgV29ya2lu ZyBHcm91cCB0byBmb2N1cyBlbmVyZ3kgb24gdGhhdCBwcm9ibGVtIHJpZ2h0IG5vdyBpbiBvcmRl ciB0byBkZXZlbG9wIGEgY29uc2Vuc3VzLWJhc2VkIGFwcHJvYWNoIHRoYXQgc3VpdHMgdGhlIGNv bW11bml0eSBhcyBhIHdob2xlLCB3aGlsZSB3ZSBkb24ndCBldmVuIGhhdmUgdGhlIGJhc2Ugc29s dXRpb24gaW4gcGxhY2UuDQoNCllvdSBoYXZlIG1hZGUgaXQgY2xlYXIgdGhhdCB5b3UgZmVlbCB0 aGUgV0cgc2hvdWxkIGluZGVlZCBkZWRpY2F0ZSBlbmVyZ3kgb24gdGhhdCBwcm9ibGVtIHJpZ2h0 IGF3YXkgYW5kIGV4cGxhaW5lZCB5b3VyIHJhdGlvbmFsZS4gVGhhbmsgeW91LiBPdGhlcnMgaGF2 ZSBhbHNvIGV4cHJlc3NlZCB0aGVpciBvcGluaW9ucy4NCg0KQ2hlZXJzDQoNCkZyYW5jb2lzDQoN Cg0KT24gMjggT2N0IDIwMTEsIGF0IDExOjI1LCBaaG91WmhpcGVuZyB3cm90ZToNCg0KRGVhciBh bGwsDQpJbiB0aGVzZSBkYXlzIEkgYW0gYnVzeSBtYWtpbmcgYSBzdW1tYXJ5IGFuYWx5c2lzIG9u IHRoaXMgdG9waWMuIEFzIFJpY2hhcmTigJlzIHJlcXVlc3QsIEkgbGlrZSB0byBzaG93IG15IGlu Zm9ybWF0aW9uIGFsdGhvdWdoIHBlcmhhcHMgbm90IGNvbXBsZXRlIHJpZ2h0IG5vdy4NCg0KMSkg ICAgIEkgaGF2ZSBkb25lIHNvbWUgd29yayB0byBjb2xsZWN0IGRpZmZlcmVudCBjb21wYW554oCZ cyByZXF1aXJlbWVudHMgYW5kIG9waW5pb25zIG9uIHRoaXMgZnVuY3Rpb25hbGl0eS4NCk9uZSwg SSBmZWVsIG1vc3Qgb2YgdXMgaGF2ZSBhbHJlYWR5IGJlZW4gYXdhcmUgb2YgdGhlIHNlcnZpY2Ug b2YgY29udGVudCBhZGFwdGF0aW9uLCBhbmQgSSBhbHNvIHNlbnQgYW4gZW1haWwgeWVzdGVyZGF5 IHRoYXQgVm9kYXBob25lIG5vdyBpcyByZXF1aXJpbmcgdGhlIHNvbHV0aW9uIHRvIGVuaGFuY2Ug dGhlIHBlcmZvcm1hbmNlIG9mIGl0cyBtb2JpbGUgdmlkZW8gc2VydmljZS4NClNlY29uZCwgaGVy ZSBpcyBhbiBhcnRpY2xlIGFib3V0IENJU0NPIDog4oCcQ2lzY28gdXJnZXMgbW9iaWxlIG9wZXJh dG9ycyB0byBhZGQgdmFsdWUgdG8gQ0ROIHNlcnZpY2Vz4oCdIGh0dHA6Ly93d3cudG90YWx0ZWxl LmNvbS92aWV3LmFzcHg/SUQ9NDY4NzA1DQpCZXNpZGVzLCBJIGhhdmUgY2hlY2tlZCBtYW55IENE TiBjb21wYW554oCZcyB3ZWJzaXRlcy4gTWFueSBjbGFpbSB0byBzdXBwb3J0IHRyYW5zY29kaW5n IHdoaWxlIHNvbWUgbWF5IG5vdC4NCg0KMikgICAgIEZvciB0aGUgd29yZGluZyDigJxjb250ZW50 IGFkYXB0YXRpb27igJ0sIGl0IHNob3VsZCBiZSBjbGFyaWZpZWQgaGVyZSB0aGF0IGl0IG1heSBi ZSB0d28ga2luZHMuDQpPbmUgaXMgb25seSB0aGUgdHJhbnNmb3JtYXRpb24gb2YgZW5jYXBzdWxh dGlvbiBmb3JtYXQuIEZvciBleGFtcGxlIHRoZSBILjI2NCBzdHJlYW0gaXMgZW5jYXBzdWxhdGVk IGluIEFQUExFIGFuZCBBZG9iZSBmb3JtYXQgcmVzcGVjdGl2ZWx5Lg0KSSBrbm93IHRoYXQgQ29t Y2FzdCBoYXMgYSBwcm9qZWN0IHRoYXQgbmVlZHMgdG8gcGljayB0aGUgSC4yNjQgbWVkaWEgZnJv bSB0aGUgVFMgc3RyZWFtIGFuZCB0aGVuIGVuY2Fwc3VsYXRlZCB0aGVtIGludG8gZGlmZmVyZW50 IGZvcm1hdHMoQVBQTEUsQWRvYmXigKYpIHRvIGRpZmZlcmVudCBkZXZpY2VzLg0KRm9yIHRoaXMg a2luZCBvZiB0cmFuc2Zvcm1hdGlvbiwgdGhlIGNvbXB1dGluZyBjb3N0IGlzIHZlcnkgdmVyeSBs b3cgYW5kIG1heSBiZSBuZWFybHkgbmVnbGVjdGVkLg0KVGhlIG90aGVyIGlzIHRvIHRyYW5zY29k aW5nLiAgRm9yIGV4YW1wbGUgdG8gc3VwcG9ydCBkaWZmZXJlbnQgYml0cmF0ZXMuICBTaW5jZSBl bmNvZGVyIGlzIGEgaGlnaCB2YWx1ZSBmYWNpbGl0eSwgd2Ugc2hvdWxkIGNvbXBhcmUgdGhlIGNh cGl0YWwgY29zdCBvZiBlbmNvZGVyIGFuZCB0cmFuc3BvcnQgY29zdC4NCkp1c3QgdGFrZSBhIHNp bXBsZSBtb2RlbDogY29udGVudCBpcyBkZWxpdmVyZWQgZnJvbSBOb2RlIEEgdG8gTm9kZSBCLg0K PGltYWdlMDAyLnBuZz4NClRoZXJlIGFyZSB0d28gc29sdXRpb25zOg0KMSkgICAgIEEgaGF2ZSB0 aGUgdHJhbnNjb2RlciBhbmQgZGVsaXZlciBtdWx0aS1mb3JtYXQgY29udGVudCB0byBCDQoyKSAg ICAgQiBoYXZlIHRoZSB0cmFuc2NvZGVyOyBBIG9ubHkgZGVsaXZlcnMgb25lIGZvcm1hdCBjb250 ZW50IHRvIEIgYW5kIEIgd291bGQgdHJhbnNjb2RlLg0KRnJvbSB3aG9sZSBzeXN0ZW0gcG9pbnQg b2YgdmlldywgZWl0aGVyIEEgb3IgQiB3b3VsZCB0cmFuc2NvZGUgd2hpbGUgdGhlIGJhbmR3aWR0 aCB3b3VsZCBiZSBzYXZlZCBpbiBzb2x1dGlvbiBCLiBIZW5jZSBzb2x1dGlvbiBCIGlzIGJldHRl ci4NCk5vdyBwcm92aWRlZCB0aGUgYmFuZHdpZHRoIGlzIHBhaWQgYnkgQiBhbmQgQiBzaG91bGQg ZGVjaWRlIHdoZXRoZXIgdG8gaW5zdGFsbCB0cmFuc2NvZGVyLg0KKFJpY2hhcmQgaGFzIHNhaWQg dG8gc2V0IHRyYW5zY29kZXIgaW4gZWFjaCBlZGdlIHNlcnZlcikNCklmIHRoZSBjb3N0IG9mIHJl bnRpbmcgYmFuZHdpZHRoIChmb3IgYSBmZXcgbW9udGhzKSBpcyBtb3JlIGV4cGVuc2l2ZSB0aGFu IHRoZSBwcmljZSBvZiB0cmFuc2NvZGVyIHN1cHBvcnRpbmcgdGhlIHNhbWUgYmFuZHdpZHRoLCBp dCB3b3VsZCBiZSBiZXR0ZXIgdG8gcHV0IHRoZSB0cmFuc2NvZGVyIGF0IHRoZSByZWNlaXZlciBO b2RlIEIuDQpJbiBmYWN0IEkgaGF2ZSBpbnZlc3RpZ2F0ZWQgdGhpcyBpc3N1ZSBmb3IgbXVjaCB0 aW1lLiBXaGlsZSBpbiBkaWZmZXJlbnQgYXJlYSB0aGUgcHJpY2Ugb2YgYmFuZHdpZHRoIG1heSBi ZSBkaWZmZXJlbnQuICBBbmQgdGhlIHRyYW5zcG9ydCBidXJkZW4gYmV0d2VlbiB0d28gZGlzdGFu dCBwbGFjZXMgb3Igb3ZlciBhIGJhZCBuYXR1cmUgZW52aXJvbm1lbnQgd291bGQgYmUgbXVjaCBo aWdoZXIuDQpIZXJlIHRoZSBwcmljZSBpbiBVU0EgbWF5IGJlIHJlZmVycmVkIGFzOiBodHRwOi8v c21hbGxidXNpbmVzcy52ZXJpem9uLmNvbS9wcm9kdWN0cy9pbnRlcm5ldC9oc2kvb3ZlcnZpZXcu YXNweCNwbGFucy4NCkluIFZlcml6b24sIHRoZSBwYWNrYWdlIGZvciAxMC0xNW1icHMgaXMgJDkw IHBlciBtb250aCAoSSBmZWVsIHRoZSBiYW5kd2lkdGggcXVhbGl0eSBmb3IgYnVzaW5lc3Mgd291 bGQgYmUgZ3VhcmFudGVlZCkuIEkgcXVlcnkgdGhhdCB0aGUgYmFuZHdpZHRoIHByaWNlIGluIENo aW5hIG1heSBiZSA1MCUgaGlnaGVyLg0KSSBkbyBub3Qga25vdyBob3cgbXVjaCB0aGUgcHJpY2Ug d2lsbCBiZSBmb3IgdGhlIGJhbmR3aWR0aCBmcm9tIEFtc3RlcmRhbSB0byBQYXJpcyAoY3Jvc3Mg Y291bnRyeSBpbiB0aGUgc2FtZSBjb250aW5lbnQpLiAgQnV0IEkgZmVlbCB0aGUgcHJpY2UgZnJv bSBOZXdZb3JrIHRvIFBhcmlzIHdvdWxkIGFic29sdXRlbHkgYmUgdmVyeSBoaWdoLiAgQXMgZm9y IHRoZSBFbmNvZGVyLCBpdCBhbHNvIHZhcmllcy4gUGVyaGFwcyB0aGUgcHJpY2UgaW4gQ2hpbmEg d2lsbCBiZSBoaWdoZXIgdGhhbiBpbiBVU0EuIEFuZCBpbiBmYWN0IHRoZSBwcmljZSBvZiBiYW5k d2lkdGggYW5kIGVuY29kZXIgZGVwZW5kcyBtb3N0bHkgb24gdGhlIGNvbmNyZXRlIGJ1c2luZXNz IGl0ZW1zLiBGb3IgZXhhbXBsZSB0aGUgcHJpY2UgdG8gSHVhd2VpIG1heSBiZSBsb3dlciB0aGFu IHRoZSBwdWJsaWMgcHJpY2UuDQpCeSBteSBjdXJyZW50IGV2YWx1YXRpb24gaW4gQ2hpbmEgaXQg aXMgYmV0dGVyIHVzaW5nIHRoZSB0cmFuc2NvZGVyIHRoYW4gcmVudGluZyBtdWx0aXBsZSB0aW1l cyBicm9hZGJhbmQuDQpTb21lIHBlb3BsZSBoYXZlIHRvbGQgbWUgdGhhdCBmb3IgdGhlIG9wZXJh dG9yIGhpbXNlbGYgcHJvYmFibHkgdGhlIGJhbmR3aWR0aCBjb3N0IHdvdWxkIGJlIHZlcnkgbG93 IGluIHRoZSBpbnRlcm5hbCBjYXBpdGFsIGNvdW50aW5nLiBCdXQgZm9yIHRoZSBpbmRlcGVuZGVu dCBDRE4sIGl0IG1heSBhbm90aGVyIHRoaW5nLg0KU28sIG15IHN1Z2dlc3Rpb24gaXMgdG8gbGV0 IGRpZmZlcmVudCB3YXlzIGNvLWV4aXN0LiBJIGhhdmUgYW5ub3VuY2VkIHRoYXQgdG8gbGV0IHR3 byBzaWRlcyBuZWdvdGlhdGUgd2hldGhlciB0byBhc3NpZ24gZENETiBmb3IgdGhlIGNvbnRlbnQg YWRhcHRhdGlvbi4NCg0KSW4gZmFjdCwgZnJvbSBDUCB0byBDRE4sICB0aGVyZSBhcmUgdGhlIHJl YWwgYnVzaW5lc3NlcyB0aGF0IGVpdGhlciBsZXQgQ1AgdG8gcHJvdmlkZSBtdWx0aS1mb3JtYXQg Y29udGVudCBvciBsZXQgdGhlIENETiB0byByZWNlaXZlIG9uZSBmb3JtYXQgYW5kIGNvbXBsZXRl IHRoZSB0cmFuc2Zvcm1hdGlvbiwgZGVwZW5kaW5nIG9uIHRoZSBjb25jcmV0ZSBidXNpbmVzcy4N CkJ5IHRoZSBzYW1lIGxvZ2ljLCBmb3JtIHVDRE4gdG8gZENETiwgaXQgbWF5IGJlIGVpdGhlciB0 aGUgdUNETiB0byBwcm92aWRlIG11bHRpLWZvcm1hdCBjb250ZW50IG9yIHRoZSBkQ0ROIHRvIHJl Y2VpdmUgb25lIGZvcm1hdCBjb250ZW50IGFuZCB0aGVuIGNvbXBsZXRlIHRoZSB0cmFuc2Zvcm1h dGlvbi4NCkN1cnJlbnRseSB0aGVyZSBpcyBub3QgdGhlIHJlYWwgQ0ROLUNETiBjb25uZWN0aW9u LCBoZW5jZSB3ZSBhcmUgYmFzaW5nIG91ciBrbm93bGVkZ2Ugb24gdGhlIHJlbGF0ZWQgc29sdXRp b24gdG8gbWFrZSBvdXIgc29sdXRpb25zLg0KDQozKSAgICAgQXMgZm9yIHRoZSBwcm9jZWR1cmUg b2YgY29udGVudCBhZGFwdGF0aW9uLCBJIGp1c3QgZHJhZnQgYSBkaWFncmFtIGFzIGJlbG93Og0K PGltYWdlMDA0LnBuZz4NCg0KWW91IG1heSBzZWUgdGhlIHNvbHV0aW9uIGlzIHJhdGhlciBjbGVh ciBhbmQgdGhlIG1ldGFkYXRhIG5lZWRlZCB3b3VsZCBiZSBjbGVhciBhbHNvLg0KDQpEZWFyLA0K QnkgbXkgYW5hbHlzaXMgYWJvdmUsIEkga2luZGx5IGludml0ZSB5b3VyIGlkZWFzIHdoZXRoZXIg aXQgbWF5IGJlIGFuIGFwcGxpY2FibGUgYW5kIHNpbXBsZSBwYXJ0IGluIHRoZSBDRE5JIGl0ZW0s IHByb3ZpZGVkIHRoYXQgdGhlIHNvbHV0aW9uIGlzIG9wZW4gdG8gdGhlIHR5cGVzIG9mIGNvbnRl bnQgYWRhcHRhdGlvbiBhbmQgbWF5IGJlIG9wdGlvbmFsbHkgaW1wbGVtZW50ZWQgaW4gdGhlIHJl YWwgc29sdXRpb25zL2J1c2luZXNzLiBJIGZlZWwgZm9yIHRob3NlIG9wZXJhdG9ycyB0aGF0IG5l ZWQgc3VjaCBmdW5jdGlvbmFsaXR5IGl0IHdvdWxkIGJlIHZlcnkgZ29vZCB3aGlsZSBpdCBkb2Vz IG5vdCBpbXBhY3Qgb3RoZXJzIHRoYXQgZG8gbm90IGltcGxlbWVudCBpdC4NClRoYW5rcy4NClpo aXBlbmcNCg0KDQpGcm9tOiBXb3VuZHksIFJpY2hhcmQgW21haWx0bzpSaWNoYXJkX1dvdW5keUBj YWJsZS5jb21jYXN0LmNvbV0NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDExIDc6MjMg UE0NClRvOiBaaG91WmhpcGVuZzsgJ21hcmtAamV0LXN0cmVhbS5ubDxtYWlsdG86J21hcmtAamV0 LXN0cmVhbS5ubD4nOyAnYWxhbi5rYXZhbmFnaEBlcmljc3Nvbi5jb208bWFpbHRvOidhbGFuLmth dmFuYWdoQGVyaWNzc29uLmNvbT4nDQpDYzogJ2NkbmlAaWV0Zi5vcmc8bWFpbHRvOidjZG5pQGll dGYub3JnPic7IFdvdW5keSwgUmljaGFyZA0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQo+SW4geW91ciBjb21wYW554oCZ cyB3ZWJzaXRlLCBJIGp1c3QgZmluZCBzb21lIGluZm9ybWF0aW9uDQoNCkkgaGF2ZSB0byBzdGVw IGluIGFzIGNvLWNoYWlyIGhlcmUuDQoNClRoZSBnb2FsIG9mIHRoaXMgV0cgaXMgbm90IHRvIGFs aWduIHZlbmRvciBwcm9kdWN0IHJvYWRtYXBzLCBvciB0byBlcXVhbGl6ZSBhbGwgdmVuZG9yIG9m ZmVyaW5ncywgb3IgdG8gc3BlY2lmeSB0aGUgZW50aXJlIENETkkgZWNvc3lzdGVtLiBUaGUgZ29h bCBvZiB0aGlzIFdHIGlzIHRvIGVuYWJsZSB0aGUgaW50ZXJjb25uZWN0aW9uIGFuZCBpbnRlcm9w ZXJhdGlvbiBvZiB0d28gb3IgbW9yZSBDRE5zLCB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgQ0RO SSB3ZyBjaGFydGVyLg0KDQpJdCBpcyBPSyB0byBoYXZlIGEgZGlzY3Vzc2lvbiBhYm91dCB3aGV0 aGVyIGNvbnRlbnQgYWRhcHRhdGlvbiBuZWVkcyB0byBiZSBwZXJmb3JtZWQgYnkgdGhlIGRDRE4s IHNpbmNlIHRoYXQgZGVjaXNpb24gaW1wYWN0cyB0aGUgdUNETi1kQ0ROIGludGVyZmFjZS4gU28g bGV0J3MgZmluZCBhIHByb2R1Y3RpdmUgd2F5IHRvIGRpc2N1c3MgdGhpcyBvbiB0aGUgbWFpbGlu ZyBsaXN0LCBhbmQgdG8gY2xvc2UgdGhlIGRpc2N1c3Npb24gYnkgSUVURiA4MiAoaWYgbm90IHNv b25lcikuDQoNCkNhbiBzb21lb25lIGRlc2NyaWJlIHJlYWwtbGlmZSBleGFtcGxlcyB3aGVyZSBk b3duc3RyZWFtIENETiAob3IgZWRnZSBjYWNoZS1iYXNlZCkgY29udGVudCBhZGFwdGF0aW9uIGlz IG5lZWRlZCB0b2RheSBpbiBhIHByb2R1Y3Rpb24gZW52aXJvbm1lbnQsIG9yIHNob3J0bHk/IE5v dCBtZXJlbHkgYSBmZWF0dXJlIGluIGEgdmVuZG9yJ3MgcHJvZHVjdCBtYXRlcmlhbHM/DQoNClNw ZWFraW5nIGFzIGFuIGluZGl2aWR1YWwsIEkgY2FuIGZpbmQgYSBsb3Qgb2YgZXhhbXBsZXMgd2hl cmUgZG93bnN0cmVhbSBjb250ZW50IGFkYXB0YXRpb24gaXMgbm90IG5lZWRlZCwgYW5kIGFueSBh ZGFwdGF0aW9uIGlzIHJlYWxseSBwYXJ0IG9mIHRoZSBDUCAtIHVDRE4gaW50ZXJmYWNlICh3aGlj aCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIG91ciBjaGFydGVyKS4NCg0KLS0gUmljaA0KDQoNCkZy b206IFpob3VaaGlwZW5nIFttYWlsdG86emhvdXpoaXBlbmdAaHVhd2VpLmNvbV0NClNlbnQ6IFRo dXJzZGF5LCBPY3RvYmVyIDI3LCAyMDExIDAzOjQ1IEFNDQpUbzogTWFyayBkZSBKb25nIDxtYXJr QGpldC1zdHJlYW0ubmw8bWFpbHRvOm1hcmtAamV0LXN0cmVhbS5ubD4+OyBBbGFuIEthdmFuYWdo IDxhbGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbTxtYWlsdG86YWxhbi5rYXZhbmFnaEBlcmljc3Nv bi5jb20+Pg0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+IDxjZG5pQGll dGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KSGVsbG8gTWFyaywNCk5p Y2UgdG8gbWVldCB5b3Ugb24gbGluZS4NCkluIHlvdXIgY29tcGFueeKAmXMgd2Vic2l0ZSwgSSBq dXN0IGZpbmQgc29tZSBpbmZvcm1hdGlvbiB0aGF0IGFkZHJlc3NlcyDigJwgVm9kYWZvbmUgc3Vi c2NyaWJlcnMgY29tcGxhaW5lZCBhYm91dCB2aWRlbyBwZXJmb3JtYW5jZS7igJ0NClNlZToNCmh0 dHA6Ly93d3cuamV0LXN0cmVhbS5ubC9zZWFyY2gvP3NlYXJjaD10cmFuc2NvZGluZw0KDQpEZWFy IGFsbCBpbiB0aGlzIGdyb3VwLA0KSW4gbGFzdCBmZXcgZGF5cywgZXhjZXB0IHRoZSBwdWJsaWMg ZW1haWwgZGlzY3Vzc2lvbnMgSSBoYXZlIGNvbnRhY3RlZCB3aXRoIHNvbWUgcGVvcGxlIGFuZCBk aXNjdXNzZWQgd2l0aCBteSBvd24gY29sbGVhZ3VlcyBvZiBhbGwgZGV0YWlscyBvbiB0aGlzIGlz c3VlLg0KRmlyc3QsIGFsdGhvdWdoIHRoZSBtYXJrZXQgcmVxdWlyZW1lbnQgZm9yIGl0IGlzIHZl cnkgaW1wb3J0YW50LCBJIGZlZWwgSeKAmWQgYmV0dGVyIHNob3cgdXAgbW9yZSBpbmZvcm1hdGlv biBvbiB0aGUgcHJvY2VkdXJlIGludm9sdmVkLiBJIGhhdmUgZXhwbGFpbmVkIG1hbnkgdGltZXMg dGhhdCB0byBzdXBwb3J0IGNvbnRlbnQgYWRhcHRhdGlvbiBpcyByYXRoZXIgc2ltcGxlIHdoaWxl IHRoZSB3b3JkaW5nIGlzIG5vdCBlbm91Z2guDQpJIGFtIGJ1c3kgbWFraW5nIHNvbWUgY29udHJp YnV0aW9ucyBvbiB0aGlzIGFuZCBwbGFuIHRvIHVwbG9hZCB0byBFVFNJIG1lZXRpbmcgYW5kIElF VEYgQ0ROSS4NCkJ5IHRoZXNlIHdvcmsgIEkgZmVlbCB0aGUgcGVvcGxlIG1heSBjYXRjaCBhIHdo b2xlIHZpZXcgb24gdGhpcyBpc3N1ZS4NClNlY29uZCwgZm9yIHRoYXQgZnVuY3Rpb25hbGl0eSwg aW4gaW1wbGVtZW50YXRpb24sIGlmIHNvbWUgZW50aXR5IGRvZXMgbm90IGNob29zZSB0byBzdXBw b3J0IGl0LCBpdCBtYXkgYmUgb2suIFNpbmNlIGl0IG1heSBiZSBuZWdvdGlhdGVkIGJldHdlZW4g IHR3byBDRE5zLg0KSWYgZENETiBkb2VzIG5vdCBzdXBwb3J0IHRoYXQsIGl0IG1heSBiZSB0aGUg dUNETiByZXNwb25zaWJsZSB0byBjb21wbGV0ZSB0aGUgdHJhbnNjb2RpbmcgYW5kIGRlbGl2ZXIg dGhlIGNvbnRlbnQgb2YgbXVsdGlwbGUgZm9ybWF0cyBhbmQgcmF0ZXMgdG8gZENETi4NClRoaXJk LCBhbHRob3VnaCBDRE5JIGlzIGEgbmV3IGFyY2hpdGVjdHVyZSwgd2hpbGUgdGhlIGNvbnRlbnQg b3BlcmF0aW5nIGhhcyBiZWVuIGV4aXN0ZWQgZm9yIHllYXJzLiBBcyBJIGtub3cgdGhlIGNvbnRl bnQgZnJvbSBVU0EgdG8gdGhlIGRvd25zdHJlYW0gb3BlcmF0b3IgaXMgdHJhbnNmZXJyZWQgb24g b25lIGNvcHkgYW5kIHRoZSBkb3duc3RyZWFtIG9wZXJhdG9yIHdpbGwgaGFuZGxlIHRoZSB0cmFu c2NvZGluZy4NCg0KUGVyaGFwcywgdGhlIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBtb3JlIG9uIHRo ZSBtb2JpbGUgb3BlcmF0aW5nLiBCdXQgSSBmZWVsIGN1cnJlbnRseSBtb3N0IG9wZXJhdG9yIHdp bGwgYmUgYSBhbGwgc2VydmljZSBvcGVyYXRvci4gQW5kIGZvciB0aGUgQ0ROIHByb3ZpZGVycywg aXQgbWF5IGJlIGJldHRlciB0byBzdXBwb3J0IGFsbCBraW5kcyBvZiBzZXJ2aWNlLg0KQmVzaWRl cywgSSBsaWtlIHNheSB0aGF0IHRoZSB0ZWNobm9sb2d5IG9uIHRoaXMgdG9waWMgaGFzIGJlZW4g Zm9yIG1hbnkgeWVhcnMgYW5kIGhhcyBiZWVuIHJhdGhlciBtYXR1cmUsIGV2ZW4gc29tZSBpdGVt cyBpbiBpZXRmIHN1Y2ggYXMgcmZjMzUwNyAgaWNhcC4gU28gZnJvbSB0aGUgdGVjaG5pcXVlIHBv aW50IG9mIHZpZXcsIGl0IGlzIGEgbmF0dXJlIGFjdGlvbiB0byBiZSBpbnZvbHZlZCBpbiBDRE4g aW50ZXJjb25uZWN0aW9uLg0KVGhhbmtzLg0KWmhpcGVuZw0KDQoNCg0KDQpGcm9tOiBNYXJrIGRl IEpvbmcgW21haWx0bzptYXJrQGpldC1zdHJlYW0ubmxdDQpTZW50OiBUaHVyc2RheSwgT2N0b2Jl ciAyNywgMjAxMSA0OjIxIEFNDQpUbzogQWxhbiBLYXZhbmFnaA0KQ2M6IEJlbiBOaXZlbi1KZW5r aW5zOyBaaG91WmhpcGVuZzsgY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0w MC50eHQNCg0KSGkgQWxhbiwNCg0KQXMgQmVuIHN0YXRlZCB0aGUgb3ZlcmFsbCBkaXNjdXNzaW9u IHJpZ2h0IG5vdyBpcyBhYm91dCBkZWxpdmVyeSwgbm90IG9uIGFkYXB0YXRpb24uIEl0IGlzIGhh cmQgZW5vdWdoIHRvIGdldCBjb25zZW5zdXMgb24gdGhlIGRlbGl2ZXJ5IGFzcGVjdCBhbHJlYWR5 IG5vdCB0byBtZW50aW9uIHlvdXIgcmVxdWlyZW1lbnQgZnJvbSBjb250ZW50IGFkYXB0YXRpb24g YWRkZWQgdG8gdGhhdCwgc28gSSBhZ3JlZSB3aXRoIEJlbiB3ZSBzaG91bGQgc3RpY2sgd2l0aCB0 aGUgZGVsaXZlcnkgYXNwZWN0IGZvciB0aGUgZmlyc3Qgc3BlY3MuIEkgY2FuIGltYWdpbmUgdGhp cyBjb3VsZCBiZSBhIGRpc2N1c3Npb24gbGF0ZXIgb24gYnV0IHBsZWFzZSBsZXQgdXMga2VlcCB0 aGUgc2NvcGUgb2YgdGhpcyBiZSBjbGVhbiBhbmQgdHJhbnNwYXJlbnQuIEl0IGlzIG9mIGJlbmVm aXQgb2YgZXZlcnlvbmUgdG8gZ2V0IHRoZSBmaXJzdCBzcGVjcyBhcyBmYXN0IGFzIHBvc3NpYmxl LiBUaGFua3MuDQoNCk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQsDQpLaW5kIHJlZ2FyZHMsDQoNCk1h cmsgZGUgSm9uZw0KSW50ZXJuYXRpb25hbCBCdXNpbmVzcyBEZXZlbG9wZXINCkpldC1TdHJlYW0g QlYNCg0KRS1tYWlsOiBtYXJrQGpldC1zdHJlYW0uY29tPG1haWx0bzptYXJrQGpldC1zdHJlYW0u Y29tPg0KT2ZmaWNlOiArMzEgKDApNTAgNTI2MTgyMA0KTW9iaWxlOiArMzEgKDApNiA4MTEwODI2 Mw0KRmF4OiArMzEgKDApNTAgNTI2NDIxNA0KDQotIEV2ZW50OiBNZWV0IHVzIGF0IFN0cmVhbWlu ZyBNZWRpYSBFdXJvcGUsIDE3LTE4IE9jdG9iZXIsIExvbmRvbiwgVUsNCi0gRXZlbnQ6IE1lZXQg dXMgYXQgT25saW5lIFZpZGVvIFN0cmF0ZWdpZXMsIDE5IE9jdG9iZXIsIExvbmRvbiwgVUsNCi0g RXZlbnQ6IE1lZXQgdXMgYXQgQ0ROIFdvcmxkIFN1bW1pdCwgMjUtMjggT2N0b2JlciwgTG9uZG9u LCBVSw0KLSBOZXdzOiBQcmUtcmVxdWVzdCB5b3VyIFRlY2hub2xvZ3kgV2hpdGVwYXBlciBub3cg YW5kIGJlIHRoZSBmaXJzdCB0byBoYXZlIGl0LCBjaGVjayB3d3cuamV0LXN0cmVhbS5jb208aHR0 cDovL3d3dy5qZXQtc3RyZWFtLmNvbT4NCi0gTmV3czogQ2hlY2sgaHR0cDovL3d3dy5qZXQtc3Ry ZWFtLmNvbSB0byBkb3dubG9hZCBvdXIgJ1NpeCBUcmVuZHMgaW4gQ0ROcycgYnJvY2h1cmUNCg0K LSBCbG9nOiB3d3cuamV0LXN0cmVhbS5jb20vYmxvZy88aHR0cDovL3d3dy5qZXQtc3RyZWFtLmNv bS9ibG9nLz4NCi0gVmlkZW9FeGNoYW5nZTogd3d3LnZkby14Lm5ldDxodHRwOi8vd3d3LnZkby14 Lm5ldD4NCi0gU3RyZWFtemlsbGE6IHd3dy5zdHJlYW16aWxsYWNkbi5jb208aHR0cDovL3d3dy5z dHJlYW16aWxsYWNkbi5jb20+DQotIENvcnBvcmF0ZTogd3d3LmpldC1zdHJlYW0uY29tPGh0dHA6 Ly93d3cuamV0LXN0cmVhbS5jb20+DQoNCk9uIDI2LCBPY3QsMjAxMSwgYXQgODozMyBQTSwgQWxh biBLYXZhbmFnaCB3cm90ZToNCg0KQmVuDQoNCkltIGFzc3VtaW5nIHRoZW4gYmFzZWQgb24geW91 ciBjb21tZW50cyBiZWxvdyBhcmUgeW91IHN1Z2dlc3Rpbmcgd2UgYXJlIGdvaW5nIHRvIGhhdmUg YSBudW1iZXIgb2YgdmVyc2lvbnMgb2YgdGhlIENETi1JIE1ldGFkYXRhPw0KDQpJIHN5bXBhdGhp c2Ugd2l0aCB3aGF0IHlvdSBhcmUgcG9pbnRpbmcgb3V0IGJlbG93IGFuZCBkbyBhZ3JlZSB0aGF0 IHRoZXJlIGlzIHNvbWUgd29yayB0byBiZSBkb25lLCBidXQgSSBzdGlsbCBmZWVsIHRoYXQgY29u dGVudCBhZGFwdGF0aW9uIGlzIHRvIG1lIGEgZnVuZGFtZW50YWwgcmVxdWlyZW1lbnQgdG8gd2hh dCBjb2xsZWN0aXZlbHkgd2Ugc2hvdWxkIGFkZHJlc3MgaW4gdGhlIENETi1JIFdHLiBJIGRvIGFn cmVlIHdpdGggeW91IHRoYXQgY29udGVudCBhZGFwdGF0aW9uIGlzIGFuIG9wdGltaXphdGlvbiBi ZXR3ZWVuIENETidzIGJ1dCBpdCdzIGEgdmVyeSBpbXBvcnRhbnQgb25lIHRoYXQgSSBrbm93IE5l dHdvcmsgU2VydmljZSBQcm92aWRlcnMgcGFydGljdWxhcmx5IHJlcXVpcmUuDQoNCkFsYW4NCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNkbmktYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJlbiBOaXZlbi1KZW5raW5zDQpTZW50OiBPY3RvYmVyLTEyLTExIDE6 MTMgUE0NClRvOiBaaG91WmhpcGVuZw0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11 c2UtY2FzZXMtMDAudHh0DQoNClpoaXBlbmcsDQoNCk9uIDEyIE9jdCAyMDExLCBhdCAxMDoyMiwg WmhvdVpoaXBlbmcgd3JvdGU6DQoNCkhlbGxvIEJlbiwNClRoZSBVRSBtYXkgc2VsZWN0IHRoZSBj b250ZW50IGZvcm1hdCBvbiB0aGUgQ1Agd2ViLiBBZnRlciB0aGF0IHRoZSB1c2VyIG9ubHkgZGVz aXJlcyB0byBnZXQgaGlzIHNlbGVjdGVkIGNvbnRlbnQuDQpCdXQgaG93IHRoZSBjb250ZW50IGlz IHRyYW5zZmVycmVkIHRvIHRoZSBjbGllbnQgaXMgbm90IHdvcnJpZWQgYnkgdGhlIHVzZXIuDQpU aGUgQ1AgbWF5IGNyZWF0ZSBhIHNwZWNpYWwgZm9ybWF0IGFzIHJlcXVpcmVkIGJ5IHRoZSB1c2Vy IGFuZCBhc2sgdGhlIENETiB0byBkZWxpdmVyIHRvIHVzZXIuDQpXaGlsZSBDUCBtYXkgZ2l2ZSBh IEhEIGZvcm1hdCBjb250ZW50IHRvIHVDRE4gYW5kIHRoZSBkQ0ROIG1heSB0aGVuIHRyYW5zZm9y bSB0byB0aGUgZm9ybWF0IGFzIHRoZSB1c2VyIHNlbGVjdC4NCg0KTG90cyBvZiB0aGluZ3MgbWF5 IGJlIHBvc3NpYmxlIHRvIGRvIGFuZCBDRE4gcHJvdmlkZXJzIG9mZmVyIG1hbnkgYWRkaXRpb25h bCBzZXJ2aWNlcyBvbiB0b3Agb2YgdGhlICJjb3JlIiBzZXJ2aWNlIG9mIGNvbnRlbnQgZGVsaXZl cnkuIEhvd2V2ZXIsIG91ciBvYmplY3RpdmUgKGJhc2VkIG9uIG15IGludGVycHJldGF0aW9uIG9m IHRoZSBDRE5JIGNoYXJ0ZXIpIGlzIHRvIGZvY3VzIG9uIHdoYXQgaXMgbmVjZXNzYXJ5IHRvIGlu dGVyY29ubmVjdCBDRE5zIHRvIGRlbGl2ZXIgY29udGVudCBmcm9tIGEgQ1NQIHRvIGFuIEVuZCBV c2VyIHRoYXQgaXMgdGFyZ2V0ZWQgYW5kIGRlcGxveWFibGUgd2l0aGluIGEgc2hvcnQgdGltZSBm cmFtZSAoMTgtMjQgbW9udGhzKS4NCg0KQ29udGVudCB0cmFuc2Zvcm1hdGlvbi9hZGFwdGF0aW9u IGlzIG5vdCBhbiBlc3NlbnRpYWwgcmVxdWlyZW1lbnQgaW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGF0 IGFpbSAod2UgY2FuIGRlbGl2ZXIgY29udGVudCBmcm9tIENTUHMgdG8gRW5kIFVzZXJzIHZpYSBt dWx0aXBsZSBDRE5zIHdpdGhvdXQgbmVlZGluZyBvciByZXF1aXJpbmcgYW55IENETiBzdXBwb3J0 cyBjb250ZW50IGFkYXB0YXRpb24pLg0KDQpJbiBteSBvcGluaW9uIHdlIGhhdmUgZW5vdWdoIHdv cmsgdG8gZG8gYWxyZWFkeSB3aXRob3V0IHRyeWluZyB0byBleHBhbmQgdGhlIHNjb3BlIG9mIG91 ciB3b3JrIHRvIGluY2x1ZGUgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgdGhhdCBkbyBub3QgaGVs cCB1cyBhZGRyZXNzIG91ciBjb3JlIG9iamVjdGl2ZXMgYXMgbGFpZCBvdXQgaW4gdGhlIENETkkg Y2hhcnRlci4NCg0KSW4gdGhpcyBjYXNlLCBpdCBpcyBub3RoaW5nIHJlbGF0ZWQgdG8gaG93IHRo ZSB1c2VyIHNlbGVjdCBmb3JtYXRzIG9uIENQIHdlYnNpdGUuDQpTbywgaXQgaXMgdGhlIENQIGFu ZCB1c2VyIHRvIGRlY2lkZSB0aGUgY29udGVudCBmb3JtYXQgbm90IHRoZSBDRE4oeW91ciBhc3Nl cnQgaXMgbm90IGNvcnJlY3QgYW5kIHNlZW1zIHlvdSB0YWtlIHRoYXQgYXNzZXJ0IGFzIHlvdXIg YmFzZSBmb3IgdGhlIGRpc2N1c3Npb24pLg0KDQpBcyBmb3IgInRoZSBjb3JlIENETiBmdW5jdGlv bmFsaXR5IG9mZmVyZWQgYnkgQ0ROcyB0b2RheSIsIEkgaGF2ZSBldmVyIHJhaXNlZCBhbiBlbWFp bCBiZWZvcmUgdGhhdCB5b3VyIGNvbXBhbnkncyB3ZWJwYWdlIGhhcyBjbGFpbWVkIHN1cHBvcnRp bmcgbWVkaWEgdHJhbnNmb3JtYXRpb24gYW5kIG11bHRpLXNjcmVlbiBzZXJ2aWNlLg0KUGVyaGFw cywgSSBsaWtlIGFza2luZyB5b3UgbGlzdCBzb21lIGZlYXR1cmVzIHRoYXQgeW91IGZlZWwgYXJl IHRoZSBjb3JlIGZ1bmN0aW9uYWxpdGllcyBieSBleGlzdGluZyBtYWluIHN0cmVhbSBDRE5zLiBU aHVzIHdlIG1heSBjb21wYXJlIGFuZCB0YWtlIGRlZXAgbG9vay4NCg0KSSB0aGluayB0aGUgY29y ZSBmdW5jdGlvbmFsaXR5IG1hcHMgcHJldHR5IHdlbGwgdG8gdGhlIENETkkgaW50ZXJmYWNlcywg bmFtZWx5OiBSZXF1ZXN0IFJvdXRpbmcsIE1ldGFkYXRhIGNvbmZpZ3VyYXRpb24sIGxvZyBwcm9k dWN0aW9uIGFuZCBjb250cm9sIHBsdXMgY29udGVudCBhY3F1aXNpdGlvbiBhbmQgY29udGVudCBk ZWxpdmVyeS4NCg0KSSBndWVzcyBtYW55IHBlb3BsZSBoYXZlIHRoZSBleHBlcmllbmNlL2tub3ds ZWRnZSBvZiBjb250ZW50IHJlbGF0ZWQgc2VydmljZS4gVGhlIHVzZXIgYW5kIENQIG9ubHkgY2Fy ZSB3aGV0aGVyIHRoZSBDRE4gcHJvdmlkZXJzIG1heSBzYXRpc2Z5IHRoZWlyIHJlcXVpcmVtZW50 IHdoaWxlIG5vdCBjYXJlIHRoZSBpbnRlcm5hbCBwcm9jZXNzLiBKdXN0IGFzIEdTTS9QU1ROIGlu dGVyY29ubmVjdGlvbiwgdGhlIHVzZXIgb25seSBjYXJlIHN1Y2Nlc3NmdWwgaW50ZXJjb25uZWN0 aW9uIHdoaWxlIG5vdCBjYXJlIGhvdyB0aGUgdm9pY2UgaXMgdHJhbnNmb3JtZWQgaW4gcHJvY2Vz cy4NCg0KQmVzaWRlcywgSSBsaWtlIHJhaXNlIGEgY2FzZToNCkdpdmVuIGN1cnJlbnRseSBCQkMg cmVjcnVpdHMgQ0ROIHByb3ZpZGVycyB0aGF0IG1heSBzdXBwb3J0IDEwIG1lZGlhIGZvcm1hdHMu DQpPbmUgY2FuZGlkYXRlIGlzIHlvdXIgY29tcGFueSwgYW5vdGhlciBpcyBDRE4tWC4gVGhlIHVz ZXJzIGFyZSBsb2NhdGVkIGluIEZyYW5jZS4NClNvIGJvdGggeW91ciBjb21wYW55IGFuZCBDRE4t WCBzaG91bGQgY29ubmVjdCBhIEZyYW5jZSBDRE4gcHJvdmlkZXIoQ0ROLVkpLg0KSWYgeW91ciBj b21wYW55J3Mgc29sdXRpb24gaXMgdG8gc2VuZCAxMCBzdHJlYW1zIG9mIGRpZmZlcmVudCBmb3Jt YXQNCm9mIG9uZSBjb250ZW50IHRvIENETi1ZOyBXaGlsZSBDRE4tWCdzIHNvbHV0aW9uIGlzIHRv IHNlbmQgMSBzdHJlYW0gdG8gQ0ROLVkgd2hpbGUgQ0ROLVkgbWF5IGNvbmR1Y3Qgc29tZSBhZGFw dGF0aW9uLg0KQ29tcGFyaW5nIHRoZXNlIHR3byBzb2x1dGlvbnMsIGZvciB5b3VyIGNvbXBhbnkg YW5kIENETi1YLCBhYnNvbHV0ZWx5IHRoZSBjb3N0IG9mIENETi1YIGlzIG11Y2ggbG93ZXIuDQpG b3IgQ0ROLVksIGluIHNvbHV0aW9uLTEsIGl0IHNob3VsZCByZWNlaXZlL2ZvcndhcmQgMTAgc3Ry ZWFtcyA7IHdoaWxlIGluIHNvbHV0aW9uLTIsIGl0IHNob3VsZCBvbmx5IHJlY2VpdmUgMSBzdHJl YW0gYnV0IG5lZWQgdG8gdGFrZSB0cmFuc2Zvcm1hdGlvbiB0byBvdXRwdXQgMTAgc3RyZWFtcy4N Cg0KV2hpY2ggc29sdXRpb24gaXMgbW9yZSBjb21wZXRpdGl2ZS4gaXQgaXMgU29sdXRpb24gMSwg cmlnaHQuIFJlbWVtYmVyIHRoZSBwcmljZSBmcm9tIEJCQyBpcyBzYW1lIHRvIGJvdGggeW91ciBj b21wYW55IGFuZCBDRE4tWCBvciBCQkMgd291bGQgc2VsZWN0IG9uZSBDRE4gcHJvdmlkZXIgd2l0 aCB0aGUgbG93ZXIgcHJpY2UuDQpJZiBhIENETiBwcm92aWRlciBtYXkgbm90IGdldCB0aGUgY29u dHJhY3QgZnJvbSBDUCwgaG93IGl0IG1heSBzYXkgaXQgaXMgbm90IGEgY29yZSBmdW5jdGlvbmFs aXR5Lg0KDQpXaGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyBhIHBvc3NpYmxlIG9wdGltaXphdGlv biB0aGF0IGEgcGFydGljdWxhciBDRE4gbWF5IHdpc2ggdG8gaW1wbGVtZW50IG5vdCBhIGNvcmUg ZnVuY3Rpb25hbGl0eSByZXF1aXJlZCB0byBlbmFibGUgY29udGVudCBkZWxpdmVyeSBiZXR3ZWVu IGludGVyY29ubmVjdGVkIENETnMuIEkgY2FuIHRoaW5rIG9mIG1hbnkgb3B0aW1pemF0aW9ucyB0 aGF0IGEgQ0ROIGNvdWxkIGltcGxlbWVudCB0byBkaWZmZXJlbnRpYXRlIHRoZWlyIHNlcnZpY2Ug YnV0IHRoZSBpbnRlcm5hbCB3b3JraW5ncyBvZiBhbiBpbmRpdmlkdWFsIENETiBhcmUgb3V0IG9m IHNjb3BlIG9mIG91ciBjaGFydGVyLg0KDQpTbyB0byByZXBlYXQgbXkgcG9zaXRpb24gZm9yIGEg ZmluYWwgdGltZTogQ29udGVudCBhZGFwdGF0aW9uIGlzIG5vdCBhIGNvcmUgZnVuY3Rpb24gcmVx dWlyZWQgdG8gZW5hYmxlIGNvbnRlbnQgZGVsaXZlcnkgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBD RE5zIGFuZCB0aGVyZWZvcmUgZ2l2ZW4gdGhlIHdvcmtsb2FkIHdlIGFscmVhZHkgaGF2ZSB0byBz cGVjaWZ5IHNvbHV0aW9ucyB0aGF0IGRvIGFkZHJlc3MgdGhlIGNvcmUgZnVuY3Rpb25hbGl0eSBy ZXF1aXJlZCB0byBpbnRlcmNvbm5lY3QgQ0ROcyBJIGRvIG5vdCB0aGluayB3ZSBzaG91bGQgYmUg dHJ5aW5nIHRvIGFkZCBtb3JlIHdvcmsgaW50byB0aGF0IHdvcmtsb2FkIGFzIGl0IHdpbGwgb25s eSBkaXN0cmFjdCB1cyBmcm9tIGFjaGlldmluZyBvdXIgZ29hbCBvZiBwcm9kdWNpbmcgZGVwbG95 YWJsZSBzb2x1dGlvbnMgd2l0aGluIHRoZSB0aW1lZnJhbWUgd2UgYXJlIGJlaW5nIHRvbGQgYnkg b3BlcmF0b3JzIHRoZXkgbmVlZHMgc29sdXRpb25zIHdpdGhpbi4NCg0KQmVuDQoNClNvLCBpZiB3 ZSBhbGwgcmVhbGl6ZSB0aGF0IGN1cnJlbnRseSB0aGUgbWVkaWEgdHlwZSBpcyByaWNoLCB0aGUg Q0ROIHByb3ZpZGVycyBzaG91bGQgc3Vydml2ZSBpbiB0aGUgZXhpc3RpbmcgZWNvc3lzdGVtIGFu ZCBzdXBwb3J0IHRoZSBtZWRpYSB0eXBlcyBhcyByZXF1aXJlZCBieSB0aGUgbWFya2V0Lg0KDQpC YWNrIHRvIHRoZSBjYXNlIG9mIEdTTS9HLjcxMSwgaXQganVzdCB3aGVuIGNvbmNlcm5pbmcgdGhl IGludGVyY29ubmVjdGlvbiwgdGhlIHRyYW5zZm9ybWF0aW9uIHNob3VsZCBhdCBvbmNlIGJlIHNv bHZlZC4gT3RoZXJ3aXNlIHRoZSBpbnRlcmNvbm5lY3Rpb24gbWF5IG5vdCBiZSBvcGVyYXRlZC4N Cg0KQnIsDQpaaGlwZW5nDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBCZW4gTml2ZW4tSmVua2lucyBbbWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrXQ0KU2Vu dDogV2VkbmVzZGF5LCBPY3RvYmVyIDEyLCAyMDExIDEyOjE5IEFNDQpUbzogWmhvdVpoaXBlbmcN CkNjOiBwaGlsaXAuZWFyZGxleUBidC5jb208bWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbT47 IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NETmld IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0DQoNClpoaXBlbmcs DQoNCk9uIDExIE9jdCAyMDExLCBhdCAwNToxNiwgWmhvdVpoaXBlbmcgd3JvdGU6DQoNCkJlbiBh bmQgUGhpbGlwLA0KSSBsaWtlIHRvIHJlc3BvbmQgeW91ciBjb25jZXJuIGluIHRoaXMgb25lIGVt YWlsOg0KDQpCZW4sDQpJIGZlZWwgd2hhdCB3ZSBhcmUgbm93IGRpc2N1c3NpbmcgaXMgd2hhdCBp cyB0aGUgImNvcmUiIGZ1bmN0aW9uIG9mIENETi4NCkFzIHlvdSBzYXksIENETiBpcyB1c2VkIHRv IGRlbGl2ZXIgY29udGVudC4gVGhhdCBpcyBhYnNvbHV0ZWx5IGNvcnJlY3QgdGhhdCB0aGUgZGVs aXZlcnkgY2FwYWJpbGl0eSBpcyB0aGUgY29yZSByZXF1aXJlbWVudCBmb3IgQ0ROIHN5c3RlbS4N CldoaWxlIENETiBpcyB1c2VkIHRvIHByb3ZpZGUgdGhlIGNvbnRlbnQgZGVsaXZlcnkgc2Vydmlj ZS4NCldoYXQgbWVhbnMgc2VydmljZS4gSXQgc2hvdWxkIGluY2x1ZGUgInRpbWUiICJsb2NhdGlv biIgYW5kICJtZWRpYSB0eXBlIiwgZXRjLiBUaGVzZSBmZWF0dXJlcyBhcmUgYWxsIHRoZSBjb3Jl IGZlYXR1cmUgZm9yIGEgc2VydmljZS4NCklmIHdlIG9ubHkgY29uY2VybiAiZGVsaXZlcmluZyBv bmUgZGF0YSBibG9jayIsIEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgaXNzdWVzIHN1Y2ggYXMg ImxvZ2dpbmciICJnZW9ncmFwaGljIGNvbnN0cmFpbnQiIGFyZSB0aGUgY29yZSBvZiBDRE4uDQoN CkZvciAid2l0aG91dCBleHBsaWNpdCBrbm93bGVkZ2Ugb2Ygd2hhdCB0aGF0IGNvbnRlbnQgYWN0 dWFsbHkgaXMgIiwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSB3b3JkaW5nIGlzIGFjY3VyYXRl IHNpbmNlIGdlbmVyYWxseSBhIENETiBtYXkgY2xhaW0gaXQgc3VwcG9ydCBkaWZmZXJlbnQgbWVk aWFzLg0KQnkgdGhpcyBvcHBvcnR1bml0eSwgSSBsaWtlIHRvIHNoYXJlIGEgdXNlIGNhc2U6IGEg Y2FsbCBmcm9tIGEgR1NNIHBob25lIHRvIGEgUFNUTiB0ZWxlcGhvbmUsIHRoZSB2b2ljZSBzdHJl YW0gc2hvdWxkIGJlIHRyYW5zZm9ybWVkIGZyb20gR1NNIHZvaWNlIHRvIEcuNzExLg0KRm9yIHRo ZSB1c2VyLCBoZSBkb2VzIG5vdCBuZWVkIHRvIGtub3cgd2hhdCB0eXBlIG9mIGRhdGEgaGFzIGJl ZW4gdHJhbnNmZXJyZWQsIGJ1dCB0aGUgb3BlcmF0b3IgaGFzIGRvbmUgc29tZSB3b3JrIHRvIGlu dGVyY29ubmVjdCB0d28gc3lzdGVtcywgcmlnaHQuDQpJIGxpa2UgdG8ga25vdyB3aGV0aGVyIHlv dSBtYXkgYWNjZXB0IHRoYXQgbXkgdXNlIGNhc2UgaXMgc2ltaWxhciB0byB0aGlzIGNhc2UgYWJv dmUuDQoNCkkgZG9uJ3QgdGhpbmsgeW91ciB1c2UgY2FzZSBpcyBzaW1pbGFyIHRvIHRoZSBhbmFs b2d5IG9mIG1vYmlsZSBuZXR3b3JrcyBiZWluZyBpbnRlcmNvbm5lY3RlZCB0byBQU1ROIG5ldHdv cmtzLiBJbiB0aGUgY2FzZSBvZiBjb250ZW50IGRlbGl2ZXJ5IHRoZSBuZWdvdGlhdGlvbiBpcyBk b25lIGJldHdlZW4gdGhlIFVzZXIvQ2xpZW50IGFuZCB0aGUgQ29udGVudCBQcm92aWRlciBhbmQg dGhlIENETiBpcyBqdXN0IHVzZWQgdG8gZXhlY3V0ZS9wZXJmb3JtIHRoZSBkZWxpdmVyeSB0aGF0 IGhhcyBiZWVuIG5lZ290aWF0ZWQuIFRoZSBDRE4gaXMgbm90IGludm9sdmVkIGluIHRoZSBkZWNp c2lvbiBtYWtpbmcgb2Ygd2hhdCByZXByZXNlbnRhdGlvbnMgdGhlIENvbnRlbnQgUHJvdmlkZXIg ZGVjaWRlcyB0byBvZmZlciB0byB0aGUgVXNlci9DbGllbnQgb3IgaW4gd2hhdCByZXByZXNlbnRh dGlvbnMgdGhlIFVzZXIvQ2xpZW50IGRlY2lkZXMgdG8gcmVxdWVzdC4NCg0KQXMgZm9yIHlvdSBz YWlkIHNlbGVjdGluZyBtZWRpYSBieSB0aGUgInBvcnRhbCIsIHlvdSBtYXkgc2VlIHRoZSB3YXkg IiB1Q0ROIGRlbGl2ZXJzIG11bHRpcGxlIG1lZGlhIHN0cmVhbXMgdG8gZENETiIgaXMgbm90IGdv b2QgdGhhbiAidUNETiBkZWxpdmVycyBvbmUgbWVkaWEgc3RyZWFtIHRvIGRDRE4gYW5kIGRDRE4g dGFrZXMgc29tZSBhZGFwdGF0aW9uIHRvIHN1cHBvcnQgbXVsdGlwbGUgbWVkaWEgdHlwZXMiLg0K DQpOb3cgd2hhdCB5b3UncmUgdGFsa2luZyBhYm91dCBpcyBhbiBvcHRpbWlzYXRpb24sIG5vdCBh IGNvcmUgZnVuY3Rpb24gcmVxdWlyZWQgdG8gYWN0dWFsbHkgZGVsaXZlciB0aGUgY29udGVudCAo YW5kIHJlcG9ydCwgYmlsbCwgZXRjLiBmb3IgdGhhdCBkZWxpdmVyeSkuDQoNCk15IHBvc2l0aW9u IGlzIHRoYXQgd2Ugc2hvdWxkIGZvY3VzIG9uIGhvdyB0byBlbmFibGUgdGhlIGludGVyY29ubmVj dGlvbiBvZiB0aGUgY29yZSBDRE4gZnVuY3Rpb25hbGl0eSBvZmZlcmVkIGJ5IENETnMgdG9kYXkg KHdoaWNoIGlzIGFsc28gbXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHNjb3BlIG9mIHRoZSBDRE5J IHdvcmtpbmcgZ3JvdXAgYXMgZXhwcmVzc2VkIGluIGl0cyBjaGFydGVyKSBiZWNhdXNlIGRvaW5n IHNvIGlzIGEgc2lnbmlmaWNhbnQgcGllY2Ugb2Ygd29yayBpbiBpdHNlbGYuIExldCdzIG5vdCBz dGFydCB0cnlpbmcgdG8gYWRkIGluIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBiZXlvbmQgd2hh dCB0aGUgbWFqb3JpdHkgb2YgQ0ROcyBzdXBwb3J0IHRvZGF5IGFzIHRoYXQgd2lsbCBqdXN0IGRl bGF5IHVzIGdldHRpbmcgdXNhYmxlIHNwZWNpZmljYXRpb25zIGludG8gdGhlIG1hcmtldCBpbiBh IHRpbWVseSBmYXNoaW9uIElNTy4NCg0KQmVuDQoNCkEgZ29vZCBxdWVzdGlvbiBpcyAic2VjdXJp dHkiIHNpbmNlIEkgaGF2ZSBkb25lIHNpeCB5ZWFycyBvbiB0aGUgRFJNDQphbmQgbGlrZSB0byBw cm9tb3RlIHRoZSBEUk0gYWxsIGFyb3VuZCB0aGUgd29ybGQ6KSBJZiB0aGUgY29udGVudCBpcyBu ZWVkZWQgdG8gYmUgcHJvdGVjdGVkLCBnZW5lcmFsbHkgeW91IG1heSBrbm93IGFsbCB0aGUgc3lz dGVtcyBzaG91bGQgYmUgZ3JhbnRlZCBieSB0aGUgY29udGVudCBvd25lci4NCkhlcmUgSSBhbHNv IGxpa2UgdG8gY2xhcmlmeSB0aGF0IG5vdCBvbmx5IHRoZSBtZWRpYSBpdHNlbGYgYnV0IHRoZSBp bmZvcm1hdGlvbiByZWxhdGVkIHRvIHNlcnZpY2UgaXRzZWxmIChzdWNoIGFzIHRoZSBnZW9ncmFw aGljIGNvbnN0cmFpbnQpIHNob3VsZCBiZSBwcm90ZWN0ZWQgYWxzby4NClNvLCB0cnVzdCBpcyBu b3QgYSBwcm9ibGVtIGZvciB0aGUgbWVkaWEuDQoNClBoaWxpcCwNClRoYW5rIHlvdSB0aGF0IHlv dSBmZWVsIENvbnRlbnQgQWRhcHRpb24gaXMgYW4gaXNzdWUgZm9yICJSZXF1aXJlbWVudHMiIGJ1 dCBJIGRvIG5vdCBrbm93IHdoeSBpdCBpcyBub3QgZm9yIFVzZSBjYXNlLg0KSSBsaWtlIHRvIGNs YXJpZnkgdG8gVSB0aGF0IGl0IGlzIGltcG9ydGFudCBmb3IgeW91IG9wZXJhdG9yIHNpbmNlIGl0 IG1heSBzYXZlIGludmVzdG1lbnQgaWYgdGhlIHN5c3RlbSBtYXkgc3VwcG9ydCBkaWZmZXJlbnQg c2VydmljZXMuDQpGb3IgdXMgdmVuZG9yLCB3ZSBhcmUgaGFwcHkgb3BlcmF0b3IgbWF5IGluc3Rh bGwgYSBzeXN0ZW0gZm9yIHRoZSBtb2JpbGUgc2VydmljZSBhbmQgYW5vdGhlciBzeXN0ZW0gZm9y IHRoZSBGQkIgc2VydmljZS4NCkJ1dCB0aGUgcmVhbGl0eSBpcyBhbGwgb3BlcmF0b3JzIGFzayB1 cyB0byBwcm92aWRlIGEgc3lzdGVtIHRoYXQgbWF5IHN1cHBvcnQgZGlmZmVyZW50IHNlcnZpY2Ug c3lzdGVtcy4NCg0KRnJhbmtseSwgQmVuIGFuZCBQaGlsaXAsIEkgcmVtZW1iZXIgSSBoYXZlIGV4 cGxhaW5lZCBzb21ld2hlcmUgdGhhdCB0byBpbXBsZW1lbnQgdGhpcyBpcyByYXRoZXIgc2ltcGxl IC4NCkF0IGxlYXN0IHRoZSBVc2UgY2FzZSBhbmQgUmVxdWlyZW1lbnQgYXJlIGluZm9ybWF0aW9u YWwgdG8gYmUgcmVmZXJyZWQgaW4gZnV0dXJlIHdvcmsuIFNvIEkgZG8gcmVhbGx5IGZlZWwgeW91 IG1heSBhY2NlcHQgaXQuDQpPZiBjb3Vyc2UgSSBsaWtlIHRvIHJlc3BvbmQgeW91ciBtb3JlIGNv bmNlcm4gYW5kIGNvbW1lbnRzLg0KVGhhbmtzLg0KWmhpcGVuZw0KDQoNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxtYWlsdG86cGhpbGlw LmVhcmRsZXlAYnQuY29tPiBbbWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbV0NClNlbnQ6IE1v bmRheSwgT2N0b2JlciAxMCwgMjAxMSAxMToyMiBQTQ0KVG86IGJlbkBuaXZlbi1qZW5raW5zLmNv LnVrPG1haWx0bzpiZW5Abml2ZW4tamVua2lucy5jby51az47IFpob3VaaGlwZW5nDQpDYzogY2Ru aUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbQ0ROaV0gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KQmVuLCBaaGlwZW5n LCBhbGwsDQoNCkkgdGhpbmsgdGhhdCBDb250ZW50IEFkYXB0YXRpb24gaXMgbW9yZSBhbiBpc3N1 ZSBmb3IgdGhlIFJlcXVpcmVtZW50cyBkb2MgdGhhbiBmb3IgdGhlIFVzZSBjYXNlcyBkcmFmdC4N Cg0KVGhlIGtleSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHdhbnQgdGhlIENETkkgaW50ZXJmYWNl cyB0byBiZSBhYmxlIHRvIGNvcGUgd2l0aCBhIHNjZW5hcmlvIHdoZXJlIChzYXkpIEhEL1NEIGNv bnZlcnNpb24gaXMgZG9uZSBpbiB0aGUgZENETiAmIHRvIHNpZ25hbCBhYm91dCB0aGlzLg0KDQpJ IHRoaW5rIHRoYXQgY29waW5nIHdpdGggdGhpcyBzY2VuYXJpbyBpcyBhIHNlY29uZCBvcmRlciBy ZXF1aXJlbWVudCwgaWUgd2Ugc2hvdWxkIG5vdCB3b3JyeSBhYm91dCBpdCBpbiB0aGUgaW5pdGlh bCBzdGFuZGFyZHMtdHJhY2sgd29yay4gSSBkb24ndCBrbm93LCBkaWQgd2UgZXZlciBkZWNpZGUg d2hldGhlciB0aGUgVXNlIGNhc2VzIGRvYyBpcyByZXN0cmljdGVkIHRvICJpbml0aWFsIiBzY2Vu YXJpb3MsIG9yIHdoZXRoZXIgaXQncyBhbGwtZW5jb21wYXNzaW5nLCBpZSBjb3ZlcmluZyAiZnV0 dXJlIiBzY2VuYXJpb3MgYXMgd2VsbD8NCg0KU2NvdHQsDQpSZWFkaW5nIHNvbWUgb2YgeW91ciBl eGFtcGxlcywgdGhleSBzZWVtIHRvIGJlIHZhbGlkIGV2ZW4gaWYgY29udGVudCBhZGFwdGF0aW9u IChIRC9TRCkgaXMgb3V0IG9mIHNjb3BlLg0KLSBhIGRDRE4gbWlnaHQgZm9yIHNvbWUgcmVhc29u IGJlIHVud2lsbGluZyB0byBkaXN0cmlidXRlIEhEPw0KLSBhIENTUCBtaWdodCB3YW50IHRvIG1h a2Ugc3VyZSB0aGUgZENETiBjYW4gdXNlIEhMUyBlbmNhcHN1bGF0aW9uPw0KQnV0IHRoZXNlIHNv cnRzIG9mIGV4YW1wbGVzIHNlZW0gdG8gYmUgc3RhdGljIHBvbGljeSB0aGluZ3MgKHRvIGRvDQp3 aXRoIHRoZSBjYXBhYmlsaXRpZXMgJiBwcmVmZXJlbmNlcyBvZiB0aGUgQ0ROcyAmIENTUCksIHJh dGhlciB0aGFuDQptZXRhZGF0YSBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIHBpZWNlIG9m IGNvbnRlbnQuIEluIHRoZQ0KZGlzY3Vzc2lvbiBzbyBmYXIsIEkgdGhpbmsgbmVnb3RpYXRpb24g YWJvdXQgc3RhdGljIHBvbGljeSBzdHVmZiBpcw0KcmF0aGVyIG91dCBvZiBzY29wZSg/KQ0KDQpP biBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24gaXMgd2hl dGhlciB0cnVzdCBpcyB0cmFuc2l0aXZlLiBEb24ndCB0aGluayBpdCBuZWVkIGJlIC0ganVzdCBi ZWNhdXNlIENTUCB0cnVzdHMgdUNETiwgYW5kIHVDRE4gdHJ1c3RzIGRDRE4gZG9lc24ndCBtZWFu IHRoYXQgdGhlIENTUCBhdXRvbWF0aWNhbGx5IHRydXN0cyB0aGUgZENETi4gSG93ZXZlciwgaSBz dXNwZWN0IHRoaXMgY2FuIGdldCBhcmJpdHJhcmlseSBjb21wbGV4IC0gc28gb25lIHBvc3NpYmls aXR5IGlzIHRvIHNheSB0aGF0IHdlIHdpbGwgb25seSBoYW5kbGUgY2FzZXMgd2hlcmUgdGhlIHRy dXN0IGlzIHRyYW5zaXRpdmUuDQoNCkJlc3Qgd2lzaGVzDQpwaGlsDQoNCg0KUGhpbGlwIEVhcmRs ZXkNClJlc2VhcmNoIGFuZCBUZWNobm9sb2d5IFN0cmF0ZWd5DQoNClRoaXMgZW1haWwgY29udGFp bnMgQlQgaW5mb3JtYXRpb24sIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlh bC4gSXQncyBtZWFudCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQg YWJvdmUuIElmIHlvdSdyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90ZSB0aGF0IGRp c2Nsb3NpbmcsIGNvcHlpbmcsIGRpc3RyaWJ1dGluZyBvciB1c2luZyB0aGlzIGluZm9ybWF0aW9u IGlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2UgbGV0IG1lIGtub3cgaW1tZWRpYXRlbHkgb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUu IFRoYW5rIHlvdS4gV2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5 b3VyIGVtYWlscy4NCkJyaXRpc2ggVGVsZWNvbW11bmljYXRpb25zIHBsYw0KUmVnaXN0ZXJlZCBv ZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRvbiBFQzFBIDdBSiBSZWdpc3RlcmVkIGluDQpF bmdsYW5kIG5vOiAxODAwMDAwDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IGNkbmktYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnPiBbbWFp bHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQpPZiBCZW4gTml2ZW4tSmVua2lu cw0KU2VudDogMTAgT2N0b2JlciAyMDExIDEyOjA0DQpUbzogWmhvdVpoaXBlbmcNCkNjOiBjZG5p QGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQpDb2xsZWFndWVzLA0K DQpJTU8gU2VjdGlvbiA1LjEuMyBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBVc2UgQ2FzZXMg ZHJhZnQuIENvbnRlbnQgQWRhcHRhdGlvbiAoaS5lLiB0YWtpbmcgaW4gYSBjb250ZW50IGl0ZW0g aW4gb25lIGZvcm1hdCBhbmQgdHJhbnNmb3JtaW5nIGl0IHRvIGFub3RoZXIgZm9ybWF0IG9yIHJl cHJlc2VudGF0aW9uKSBpcyBub3QgYSAiY29yZSIgZnVuY3Rpb24gb2YgYSBDRE4gd2hpY2ggdHlw aWNhbGx5IGRlbGl2ZXJzIHRoZSBjb250ZW50IHRoYXQgaXMgcmVxdWVzdGVkIHdpdGhvdXQgZXhw bGljaXQga25vd2xlZGdlIG9mIHdoYXQgdGhhdCBjb250ZW50IGFjdHVhbGx5IGlzLg0KDQpMZXQn cyBub3QgZm9yZ2V0IHRoYXQgaW4gYnVpbGRpbmcgYW4gZW5kIHRvIGVuZCBjb250ZW50IHNlcnZp Y2UgdGhlIENETiBpcyBvbmx5IG9uZSBjb21wb25lbnQgYW5kIGlzIHRoZSBjb21wb25lbnQgdGFz a2VkIHdpdGggZXhlY3V0aW5nIHRoZSBkZWxpdmVyeSBvZiBhIHNwZWNpZmljIHJlcHJlc2VudGF0 aW9uICh2ZXJzaW9uL2NvcHkvZm9ybWF0IGV0Yy4pIG9mIHRoZSBzZWxlY3RlZCBjb250ZW50IG5v dCB0aGUgY29tcG9uZW50IHRhc2tlZCB3aXRoIGRlY2lkaW5nIChvciBhcHBseWluZyBwb2xpY3kp IG9uIHdoaWNoIHZlcnNpb24vY29weS9yZXByZXNlbnRhdGlvbiBvZiBjb250ZW50IHNob3VsZCBi ZSBkZWxpdmVyZWQuDQoNClRoZSBkZWNpc2lvbiBhcyB0byB3aGljaCB2ZXJzaW9uL2NvcHkvcmVw cmVzZW50YXRpb24gdG8gb2ZmZXIgYW5kIGFsbG93IHRvIGJlIGRlbGl2ZXJlZCB0byBhIGdpdmVu IGRldmljZS91c2VyIGlzIGltcGxlbWVudGVkIG91dHNpZGUgb2YgdGhlIENETiAoZS5nLiBieSB0 aGUgInBvcnRhbCIgd2hlcmUgdGhlIHVzZXIgZmlyc3QgbWFrZXMgdGhlaXIgY29udGVudCBzZWxl Y3Rpb24gcHJpb3IgdG8gdGhlIENETiBiZWNvbWluZyBpbnZvbHZlZCBpbiB0aGUgZGVsaXZlcnkg b2YgdGhlIHNlbGVjdGVkIGNvbnRlbnQpLg0KDQpCZW4NCg0KT24gOCBPY3QgMjAxMSwgYXQgMDg6 MjAsIFpob3VaaGlwZW5nIHdyb3RlOg0KDQpGb2xsb3dpbmcgU2NvdHQncyBjb21tZW50cyBvbiBz ZWN0aW9uIDUuMS4zLCBJIGZlZWwgU2NvdHQncyBkZXNjcmlwdGlvbiBvbiB0aGUgdXNlIGNhc2Ug b2YgSEQgYW5kIFNEIGlzIG5vdCBleGFjdGx5IGNvcnJlY3QuDQpJZiBvbmUgbW92aWUgaGFzIHR3 byBmb3JtYXRzIG9mIEhEIGFuZCBTRCwgdGhlbiB3ZSBoYXZlIHR3byBjb250ZW50IHdpdGggZGlm ZmVyZW50IGlkZW50aWZpZXIuIEluIERSTSBzY29wZSwgdGhlIGJhc2ljIHVuaXQgaXMgYSBjb250 ZW50IGNvcHkuDQoNCkhlcmUgdGhlIGZpcnN0IGJ1bGxldCAiYSBzdWJzZXQgb2YgZW5jb2Rpbmdz IGRlbGl2ZXJhYmxlIHRvIHNwZWNpZmljIGRldmljZXMsIiBoYXMgbGlzdGVkIHRoZSBjYXNlIG9m IGNvbnRlbnQgYWRhcHRhdGlvbi4NCkluIGxhc3QgbW9udGgsIEkgaGF2ZSBjb250YWN0ZWQgdGhl IEF1dGhvcnMgb2YgdGhpcyBkb2N1bWVudCBhbmQgdGFrZW4gc29tZSBlbWFpbCBleGNoYW5nZXMg d2l0aCBHcmFudCBhbmQgUGhpbGlwIChCVCkuDQpJIGhhdmUgc2hvd24gQlQgd2l0aCBzb21lIGlu Zm9ybWF0aW9uIHRoYXQgSSBrbm93IGluIHRoaXMgY2FzZSBhbmQgYXJlYSB0byBleHBsYWluIHRo ZSBjb250ZW50IGZsZXhpYmlsaXR5IGlzIGN1cnJlbnRseSBhIGJhc2ljIHJlcXVpcmVtZW50IGZv ciBDRE4gc2VydmljZSBhbmQgcmVsYXRlZCBuZWdvdGlhdGlvbiBpcyBuZWVkZWQgaW4gdGhlIENE TiBpbnRlcmNvbm5lY3Rpb24uDQpNZWFud2hpbGUsIEkgc2hvdWxkIGFsc28gaW52aXRlIHlvdSBp biB0aGlzIGdyb3VwIHJhaXNpbmcgeW91ciBjb21tZW50cyBvciBxdWVzdGlvbnMgb24gdGhpcyBj YXNlIHNpbmNlIEkgaG9wZSBteSB1c2UgY2FzZSBtYXkgYmUgaW5jb3Jwb3JhdGVkIGluIHRoZSB1 c2UgY2FzZSBkcmFmdC4NCg0KSWYgeW91IGhhdmUgYW55IG1vcmUgcXVlc3Rpb24gb3IgY29tbWVu dHMsIHBscyBzaGFyZSBpbiB0aGlzIHRocmVhZC4NClRoYW5rcy4NClpoaXBlbmcNCg0KDQoNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTY290dCBXYWlubmVyIFttYWls dG86c3dhaW5uZXJAY2lzY28uY29tXQ0KU2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMTEg ODowMiBBTQ0KVG86IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0 DQoNClNlY3Rpb24gMi4zIE5vbWFkaWMgVXNlcnMNClRoaXMgZGVzY3JpcHRpb24gZmFsbHMgdW5k ZXIgdGhlIGNhdGVnb3J5IG9mIEdlb2dyYXBoaWMgRXh0ZW5zaW9uDQp5ZXQgdGhlIHRoaXJkIHBh cmFncmFwaCBzdGF0ZXMgdGhlIGNhc2Ugd2hlcmUgYSBkaWZmZXJlbnQgZGV2aWNlIGlzDQp1c2Vk IGluIHRoZSBzYW1lIENETiBjb3ZlcmFnZSBhcmVhLiAgVGhlIGludGVudCBvZiB0aGlzIHVzZSBj YXNlDQpuZWVkcyB0byBiZSBjbGFyaWZpZWQuICBQZXJoYXBzIHRoZSB1c2UgY2FzZSBpcyB0cnlp bmcgdG8gYWRkcmVzcw0KdGhlIHNjZW5hcmlvIHdoZXJlIGEgTm9tYWRpYyBVc2VyLUEgd2l0aCBh biBhZ3JlZW1lbnQgYWxsb3dpbmcNCmFjY2VzcyB0byBjb250ZW50IGZyb20gQ1NQLUEgdmlhIHVD RE4gbW92ZXMgdG8gYSBkQ0ROIGluIGEgZGlmZmVyZW50DQpyZWdpb24uICBUaGUgZENETiBpcyBh bGxvd2VkIHRvIGRpc3RyaWJ1dGUgdGhlIGNvbnRlbnQgb2YgQ1NQLUEgdG8NClVzZXItQTsgaG93 ZXZlciwgbm90IG90aGVyIHVzZXJzIGluIHRoZSByZWdpb24gb2YgdGhlIGRDRE4gYXJlDQphbGxv d2VkIHRvIHJldHJpZXZlIHRoZSBjb250ZW50IHVubGVzcyB0aGV5IHRvbyBoYXZlIHN1Y2ggYW4g YWdyZWVtZW50Lg0KDQpTZWN0aW9uIDUuMS4zIENvbnRlbnQgRW5jb2RpbmcgUmVzdHJpY3Rpb25z IE5lZWQgdG8gY2xhcmlmeSBpZiB3ZSdyZQ0KdGFsa2luZyBhYm91dCB0aGUgcmVzdHJpY3Rpb25z IG9uIHRoZSBkZWxpdmVyeSBvZiBzcGVjaWZpYyBjb250ZW50DQpvciB0aGUgcmVzdHJpY3Rpb25z IG9uIHRoZSBhYmlsaXR5IG9mIGEgQ0ROIHRvIGRlbGl2ZXIgc3BlY2lmaWMNCmNvbnRlbnQuICBJ IGNlcnRhaW5seSB1bmRlcnN0YW5kIHRoZSBjYXNlIHdoZXJlIGEgQ1NQIHdpbGwgcmVzdHJpY3QN CnRoZSBkaXN0cmlidXRpb24gb2YgY29udGVudCB0byBhICJtYW5hZ2VkIHBhdGgiIGlmIHN1Y2gg Y29udGVudCBpcw0KSEQgd2hpbGUgYWxsb3dpbmcgdGhlIGNvbnRlbnQgZGlzdHJpYnV0aW9uIHZp YSBhbiB1bi1tYW5hZ2VkIHBhdGggaWYNCnN1Y2ggY29udGVudCBpcyBTRCAoc2FtZSBjb3VsZCBh cHBseSB0byBlbmNyeXB0aW9uIG1ldGhvZHMsIGRlbGl2ZXJ5DQptZXRob2RzLCBldGMuKS4gIE9u IHRoZSBjb250cmFyeSwgdGhlIGRDRE4gbWF5IGhhdmUgaXRzIG93bg0KcmVzdHJpY3Rpb25zIG9m IGJsb2NraW5nIHRoZSBkaXN0cmlidXRpb24gb2YgSEQgY29udGVudCB3aGlsZQ0KYWxsb3dpbmcg dGhlIGRpc3RyaWJ1dGlvbiBvZiBTRCBjb250ZW50Lg0KDQpvIGZpcnN0IGJ1bGxldCBtYWtlcyBz ZW5zZSBpZiB0aGUgZENETiBjYW4gcGVyZm9ybSBhIHN1YnNldCBvZg0KZW5jYXBzdWxhdGlvbnMg Zm9yIGEgcmVmZXJlbmNlIHNldCBvZiBtZWRpYSAoZS5nLiBITFMsIEhTUywgYnV0IG5vdA0KREFT SCkgbyBzZWNvbmQgYnVsbGV0IG1ha2VzIHNlbnNlIHdoZXJlIHRoZSBkQ0ROIGRvZXNuJ3Qgd2Fu dCB0bw0Kb2ZmZXIgaGlnaCBiaXQtcmF0ZSB2YXJpYW50cyBvZiB0aGUgbWVkaWEgbyB0aGlyZCBi dWxsZXQgbWFrZSBzZW5zZQ0KaWYgdGhlIHBvbGljeSBhZGRyZXNzZXMgUW9FIGJ1dCBJIGRvbid0 IHRoaW5rIHN1YnNjcmliZXINCnJpZ2h0cy9hdXRob3JpemF0aW9ucyBhcHBseS4NCg0KU2VjdGlv biAxMCBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQpBc2lkZSBmcm9tIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBXSVRISU4gdGhlIHVDRE4gYW5kIGRDRE4sIEkNCnRoaW5rIHdlIGNhbiBk ZXNjcmliZSB0aGlzIGluIGZvdXIgY29udGV4dHM6DQoNCmEuIFRoZSByZWxhdGlvbnNoaXAgYmV0 d2VlbiB0aGUgQ1NQIGFuZCB0aGUgdUNETiAodGhlIHByaW5jaXBsZSBjb250cmFjdA0KYXJyYW5n ZW1lbnQgZm9yIGRpc3RyaWJ1dGlvbikNCmIuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUg dUNETiBhbmQgZENETiAodGhlIHRyYW5zaXRpdmUgdHJ1c3QNCnJlbGF0aW9uc2hpcCB0aGF0IGV4 dGVuZHMgdGhlIGNvbnRyYWN0IGRlZmluZWQgaW4gKGEpIGFib3ZlKSBjLiBUaGUNCnJlbGF0aW9u c2hpcCBiZXR3ZWVuIHRoZSBVc2VyIGFuZCBkQ0ROICh0aGUgcmVjb2duaXRpb24gb2YgcmlnaHQg dG8NCmRvd25sb2FkIHByZWRpY2F0ZWQgb24gKGIpIGFib3ZlKSBkLiBUaGUgcmVsYXRpb25zaGlw IGJldHdlZW4gdGhlDQpVc2VyIGFuZCBDU1AgKHRoZSBjb250cmFjdCBhdXRob3JpemluZyB0aGUg dXNlciBhY2Nlc3MgdG8gdGhlDQpjb250ZW50KQ0KDQpUaGUgdXNlciBpcyBub3QgaW50ZXJlc3Rl ZCBpbiB0aGUgYS1iIG5vciB0aGUgYi1jIHJlbGF0aW9uc2hpcC4gVGhlDQp1c2VyIGlzIG9ubHkg aW50ZXJlc3RlZCBpbiB0aGUgdHJhbnNwYXJlbmN5IGFuZCBpbnRlcm9wZXJhYmlsaXR5IG9mDQp0 aGUgc2VjdXJpdHkgcmVsYXRpb25zaGlwIGJldHdlZW4gZC1iIG9yIGQtYyB0byB0aGUgcG9pbnQg dGhhdCB0aGUNCmF1dGhvcml6YXRpb24gZ3JhbnRlZCBpbiBkLWEgaXMgdmlhYmxlIHdoZW4gdGhl IGRlbGl2ZXJ5IGlzDQppbml0aWF0ZWQgdmlhIGVpdGhlciBkLWIgb3IgZC1jLiAgQXMgYW4gZXhh bXBsZSwgdGhlIHVDRE4gbWlnaHQgdXNlDQpVUkwgYXBwZW5kZWQgdG9rZW5zIGZvciBhdXRoZW50 aWNhdGlvbiB3aGlsZSBkQ0ROIG1pZ2h0IHVzZSBVUkwNCmFwcGVuZGVkIGhhc2hlcy4gIFRoZSB1 c2VyIGRvZXNuJ3Qgd2FudCB0byBrbm93IGFib3V0IHRoZSBkaXN0aW5jdA0KbWV0aG9kcywgYnV0 IHRyYW5zcGFyZW5jeSBpcyBvbmx5IGFmZm9yZGVkIGlmIHRoZSBtZXRob2RzIGFyZQ0KaW50ZXJv cGVyYWJsZSBjbGVhcmx5IGRlZmluZWQgd2hlbiB0aGUgZGVsZWdhdGlvbiBmb3IgY29udGVudA0K ZGVsaXZlcnkgaXMgZXhlY3V0ZWQuICBDbGVhcmx5LCB0aGUgY2hvaWNlIG9mIGF1dGhlbnRpY2F0 aW9uIG1ldGhvZCBpcyBkZXRlcm1pbmVkIGJ5IHRoZSByZXNwZWN0aXZlIENETidzLg0KDQpTY290 dA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0RO aSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5p QGlldGYub3JnPG1haWx0bzpDRE5pQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jZG5pDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYub3JnPG1haWx0bzpD RE5pQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5p DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBt YWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGll dGYub3JnPG1haWx0bzpDRE5pQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jZG5pDQoNCg== --Boundary_(ID_Zh3zl81PPMd5qfCfpzFruA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly80NTQvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3Nl LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1i cmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L 5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uYXBwbGUtc3R5 bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uYXBwbGUt Y29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg OTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTog c3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3JyeSwgbm90IEtQTi4gSXQg aXMgUmF5IGZyb20gVE5PLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gWmhvdVpoaXBlbmcNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMzEs IDIwMTEgNDo0OSBQTTxicj4NCjxiPlRvOjwvYj4gJ0ZyYW5jb2lzIExlIEZhdWNoZXVyJzxicj4N CjxiPkNjOjwvYj4gY2RuaUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0NETmld IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkRlYXIgRnJhbmNvaXMsIGFuZCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGFua3MgZm9yIGFsbCB0aGUgZ3JvdXDigJlzIGF0dGVudGlvbiBvbiB0 aGlzIHRvcGljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBh bSBhbHNvIGhhcHB5IHRoYXQgbXkgcHJvcG9zYWwgaGFzIGdvdHRlbiBzbyBtdWNoIHZhbHVhYmxl IHJlc3BvbnNlL3F1ZXN0aW9ucy8gY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGF0IHdpbGwgYmUgdmVyeSBoZWxwZnVsIGZvciBhbGwgb2YgdXMg dG8gY2F0Y2ggYSBjb21wbGV0ZSB1bmRlcnN0YW5kaW5nIGFuZCBzb2x1dGlvbiBmb3IgdGhpcyBt YXJrZXQgZGVtYW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ V2hpbGUgSSBmZWVsIHRpbGwgbm93IHRoZSB0b3BpYyBpdHNlbGYgaGFzIG5vdCBiZWVuIGNvbXBs ZXRlbHkgYW5hbHl6ZWQgYW5kIEkgYW0gYnVzeSBkb2luZyB0aGUgd29yay4gSSB3aWxsIGV4cG9z ZSBteSBjb250cmlidXRpb24gc29vbiBhZnRlcg0KIEkgY29tcGxldGUgdGhhdCB3b3JrLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TWVhbndoaWxlIEkgaG9wZSB0 aGUgZ3JvdXAgbWF5IGFsbG93IHNvbWUgbW9yZSB0aW1lIGZvciBwZW9wbGUgdG8gY29uc2lkZXIg aXQuIFBlcmhhcHMgc29tZSBtb3JlIHBlb3BsZSB3aWxsIGVtZXJnZSBpbiB0aGUgZ3JvdXAgbWFp bCBsaXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q3VycmVu dGx5LCBzb21lIHBlb3BsZSBoYXMgY2xhaW1lZCB0aGVpciBwcmVmZXJlbmNlLiAmbmJzcDtJIGZl ZWwgcGVyaGFwcyBub3QgYSBmZXcgcGVvcGxlIGhhdmUgc3VwcG9ydGVkIHRoaXMgdXNlIGNhc2Uo dGhlIGF1dGhvcnMgb2YNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmRyYWZ0LWZtbi1jZG5pLWFkdmFuY2VkLXVzZS1jYXNlcy0w MCwgQWxhbiBmcm9tIEVyaWNzc29uLA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q2hpbmFNb2JpbGUsIENoaW5hdGVsZWNvbSwg Jm5ic3A7cGVyaGFwcyBhbHNvIEtQTiwgYW5kIG1lKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+SSBoYXZlIGV4cGxhaW5lZCB0aGF0IGZvciBDRE4tQSBhbmQgQ0ROLUIsIHRo ZXkgbWF5IG5lZ290aWF0ZSB3aGV0aGVyIHRvIHN1cHBvcnQgdGhlIENETkkgYWRhcHRhdGlvbiBz b2x1dGlvbi4gSGVuY2Ugc3VjaCBvcHRpb25hbCBhcnJhbmdlbWVudA0KIHdpbGwgb25seSBicmlu ZyBiZW5lZml0IHdoZW4gYm90aCB1cHN0cmVhbSBhbmQgZG93bnN0cmVhbSBhZ3JlZXMgdGhhdCBh dCB0aGVpciBhcHByb3ByaWF0ZSBzaXR1YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPlNvLCBJIHNpbmNlcmVseSBzdWdnZXN0IHR3byBDaGFpcnMgYW5kIHRoZSB3aG9s ZSBncm91cCBtYXkgYWxsb3cgc29tZSBtb3JlIGRheXMgZm9yIHRoaXMgdG9waWMuICZuYnNwOyZu YnNwO0kgc3VnZ2VzdCBhZnRlciB0aGUgVGFpcGVpIG1lZXRpbmcgLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QnkgdGhlbiB3ZSBhbGwgd2lsbCBnZXQgYSBjbGVh cmVyIHVuZGVyc3RhbmRpbmcgYW5kIGRlY2lzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5aaGlwZW5nDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gRnJhbmNvaXMgTGUgRmF1Y2hldXIgW21haWx0bzpmbGVmYXVjaEBjaXNjby5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDI4LCAyMDExIDk6NTAgUE08YnI+DQo8Yj5U bzo8L2I+IFpob3VaaGlwZW5nPGJyPg0KPGI+Q2M6PC9iPiBjZG5pQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1j YXNlcy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBhZ2FpbiBa aGlwZW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGlz IG9uZSBvdGhlciBwb2ludCBJIHNob3VsZCBoYXZlIGJyb3VnaHQgdXAgaW4gbXkgcHJldmlvdXMg bWVzc2FnZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHF1ZXN0aW9uIGlzIG5vdCBzbyBtdWNo IHdoZXRoZXIgdGhlcmUgYXJlIGJlbmVmaXRzIHRvIGFsbG93aW5nIGNvbnRlbnQgYWRhcHRhdGlv biBmb3Igc29tZSBlbnZpcm9ubWVudHMsIG5vciB3aGV0aGVyIG9uZSBwYXJ0aWN1bGFyIGluZGl2 aWR1YWwgY291bGQgY29uY2VpdmUgYW4gYXBwcm9hY2ggZm9yIGNvbnRlbnQgYWRhcHRhdGlvbiB0 aGF0IHN1aXRzIGhpbS4gVGhlDQogcXVlc3Rpb24gaGVyZSBpcyByYXRoZXIgd2hldGhlciBpdCBp cyBqdXN0aWZpZWQgZm9yIHRoZSBXb3JraW5nIEdyb3VwIHRvIGZvY3VzIGVuZXJneSBvbiB0aGF0 IHByb2JsZW0gcmlnaHQgbm93IGluIG9yZGVyIHRvIGRldmVsb3AgYSBjb25zZW5zdXMtYmFzZWQg YXBwcm9hY2ggdGhhdCBzdWl0cyB0aGUgY29tbXVuaXR5IGFzIGEgd2hvbGUsIHdoaWxlIHdlIGRv bid0IGV2ZW4gaGF2ZSB0aGUgYmFzZSBzb2x1dGlvbiBpbiBwbGFjZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPllvdSBoYXZlIG1hZGUgaXQgY2xlYXIg dGhhdCB5b3UgZmVlbCB0aGUgV0cgc2hvdWxkIGluZGVlZCBkZWRpY2F0ZSBlbmVyZ3kgb24gdGhh dCBwcm9ibGVtIHJpZ2h0IGF3YXkgYW5kIGV4cGxhaW5lZCB5b3VyIHJhdGlvbmFsZS4gVGhhbmsg eW91LiBPdGhlcnMgaGF2ZSBhbHNvIGV4cHJlc3NlZCB0aGVpciBvcGluaW9ucy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNoZWVyczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJhbmNvaXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPk9uIDI4IE9jdCAyMDExLCBhdCAxMToyNSwgWmhvdVpoaXBlbmcgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5EZWFyIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+SW4gdGhlc2UgZGF5cyBJIGFtIGJ1c3kgbWFraW5nIGEgc3VtbWFyeSBhbmFseXNpcyBvbiB0 aGlzIHRvcGljLiBBcyBSaWNoYXJk4oCZcyByZXF1ZXN0LCBJIGxpa2UgdG8gc2hvdyBteSBpbmZv cm1hdGlvbiBhbHRob3VnaCBwZXJoYXBzIG5vdCBjb21wbGV0ZSByaWdodCBub3cuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O2xpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+MSk8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkNCiBoYXZlIGRvbmUg c29tZSB3b3JrIHRvIGNvbGxlY3QgZGlmZmVyZW50IGNvbXBhbnnigJlzIHJlcXVpcmVtZW50cyBh bmQgb3BpbmlvbnMgb24gdGhpcyBmdW5jdGlvbmFsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPk9uZSwgSSBmZWVsIG1vc3Qgb2YgdXMgaGF2ZSBhbHJlYWR5 IGJlZW4gYXdhcmUgb2YgdGhlIHNlcnZpY2Ugb2YgY29udGVudCBhZGFwdGF0aW9uLCBhbmQgSSBh bHNvIHNlbnQgYW4gZW1haWwgeWVzdGVyZGF5IHRoYXQgVm9kYXBob25lDQogbm93IGlzIHJlcXVp cmluZyB0aGUgc29sdXRpb24gdG8gZW5oYW5jZSB0aGUgcGVyZm9ybWFuY2Ugb2YgaXRzIG1vYmls ZSB2aWRlbyBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPlNlY29uZCwgaGVyZSBpcyBhbiBhcnRpY2xlIGFib3V0IENJU0NPIDog4oCcQ2lzY28gdXJn ZXMgbW9iaWxlIG9wZXJhdG9ycyB0byBhZGQgdmFsdWUgdG8gQ0ROIHNlcnZpY2Vz4oCdPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6 Ly93d3cudG90YWx0ZWxlLmNvbS92aWV3LmFzcHg/SUQ9NDY4NzA1Ij5odHRwOi8vd3d3LnRvdGFs dGVsZS5jb20vdmlldy5hc3B4P0lEPTQ2ODcwNTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZXNpZGVzLCBJIGhhdmUgY2hlY2tlZCBtYW55IENETiBjb21w YW554oCZcyB3ZWJzaXRlcy4gTWFueSBjbGFpbSB0byBzdXBwb3J0IHRyYW5zY29kaW5nIHdoaWxl IHNvbWUgbWF5IG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LTE4LjBwdDtsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPjIpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gb3INCiB0aGUgd29yZGluZyDigJxjb250ZW50IGFkYXB0 YXRpb27igJ0sIGl0IHNob3VsZCBiZSBjbGFyaWZpZWQgaGVyZSB0aGF0IGl0IG1heSBiZSB0d28g a2luZHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEz LjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+T25lIGlz IG9ubHkgdGhlIHRyYW5zZm9ybWF0aW9uIG9mIGVuY2Fwc3VsYXRpb24gZm9ybWF0LiBGb3IgZXhh bXBsZSB0aGUgSC4yNjQgc3RyZWFtIGlzIGVuY2Fwc3VsYXRlZCBpbiBBUFBMRSBhbmQgQWRvYmUg Zm9ybWF0DQogcmVzcGVjdGl2ZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPkkga25vdyB0aGF0IENvbWNhc3QgaGFzIGEgcHJvamVjdCB0aGF0IG5lZWRzIHRv IHBpY2sgdGhlIEguMjY0IG1lZGlhIGZyb20gdGhlIFRTIHN0cmVhbSBhbmQgdGhlbiBlbmNhcHN1 bGF0ZWQgdGhlbSBpbnRvIGRpZmZlcmVudA0KIGZvcm1hdHMoQVBQTEUsQWRvYmXigKYpIHRvIGRp ZmZlcmVudCBkZXZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPkZvciB0aGlzIGtpbmQgb2YgdHJhbnNmb3JtYXRpb24sIHRoZSBjb21wdXRpbmcgY29zdCBp cyB2ZXJ5IHZlcnkgbG93IGFuZCBtYXkgYmUgbmVhcmx5IG5lZ2xlY3RlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGUgb3RoZXIgaXMgdG8gdHJhbnNjb2Rp bmcuJm5ic3A7IEZvciBleGFtcGxlIHRvIHN1cHBvcnQgZGlmZmVyZW50IGJpdHJhdGVzLiZuYnNw OyBTaW5jZSBlbmNvZGVyIGlzIGEgaGlnaCB2YWx1ZSBmYWNpbGl0eSwgd2Ugc2hvdWxkIGNvbXBh cmUNCiB0aGUgY2FwaXRhbCBjb3N0IG9mIGVuY29kZXIgYW5kIHRyYW5zcG9ydCBjb3N0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkp1c3QgdGFrZSBhIHNpbXBs ZSBtb2RlbDogY29udGVudCBpcyBkZWxpdmVyZWQgZnJvbSBOb2RlIEEgdG8gTm9kZSBCLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZsdDtpbWFnZTAwMi5wbmcm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhlcmUgYXJl IHR3byBzb2x1dGlvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt aW5kZW50Oi0xOC4wcHQ7bGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4xKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QQ0KIGhhdmUgdGhlIHRyYW5zY29kZXIgYW5k IGRlbGl2ZXIgbXVsdGktZm9ybWF0IGNvbnRlbnQgdG8gQjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O2xpbmUtaGVpZ2h0OjEzLjJwdCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Mik8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkINCiBoYXZl IHRoZSB0cmFuc2NvZGVyOyBBIG9ubHkgZGVsaXZlcnMgb25lIGZvcm1hdCBjb250ZW50IHRvIEIg YW5kIEIgd291bGQgdHJhbnNjb2RlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPkZyb20gd2hvbGUgc3lzdGVtIHBvaW50IG9mIHZpZXcsIGVpdGhlciBBIG9yIEIg d291bGQgdHJhbnNjb2RlIHdoaWxlIHRoZSBiYW5kd2lkdGggd291bGQgYmUgc2F2ZWQgaW4gc29s dXRpb24gQi4gSGVuY2Ugc29sdXRpb24NCiBCIGlzIGJldHRlci48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Ob3cgcHJvdmlkZWQgdGhlIGJhbmR3aWR0aCBpcyBw YWlkIGJ5IEIgYW5kIEIgc2hvdWxkIGRlY2lkZSB3aGV0aGVyIHRvIGluc3RhbGwgdHJhbnNjb2Rl ci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4oUmljaGFyZCBo YXMgc2FpZCB0byBzZXQgdHJhbnNjb2RlciBpbiBlYWNoIGVkZ2Ugc2VydmVyKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPklmIHRoZSBjb3N0IG9mIHJlbnRpbmcg YmFuZHdpZHRoIChmb3IgYSBmZXcgbW9udGhzKSBpcyBtb3JlIGV4cGVuc2l2ZSB0aGFuIHRoZSBw cmljZSBvZiB0cmFuc2NvZGVyIHN1cHBvcnRpbmcgdGhlIHNhbWUgYmFuZHdpZHRoLA0KIGl0IHdv dWxkIGJlIGJldHRlciB0byBwdXQgdGhlIHRyYW5zY29kZXIgYXQgdGhlIHJlY2VpdmVyIE5vZGUg Qi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0 OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JbiBmYWN0IEkg aGF2ZSBpbnZlc3RpZ2F0ZWQgdGhpcyBpc3N1ZSBmb3IgbXVjaCB0aW1lLiBXaGlsZSBpbiBkaWZm ZXJlbnQgYXJlYSB0aGUgcHJpY2Ugb2YgYmFuZHdpZHRoIG1heSBiZSBkaWZmZXJlbnQuJm5ic3A7 IEFuZCB0aGUNCiB0cmFuc3BvcnQgYnVyZGVuIGJldHdlZW4gdHdvIGRpc3RhbnQgcGxhY2VzIG9y IG92ZXIgYSBiYWQgbmF0dXJlIGVudmlyb25tZW50IHdvdWxkIGJlIG11Y2ggaGlnaGVyLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhlcmUgdGhlIHByaWNlIGlu IFVTQSBtYXkgYmUgcmVmZXJyZWQgYXM6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zbWFsbGJ1c2luZXNzLnZlcml6b24uY29t L3Byb2R1Y3RzL2ludGVybmV0L2hzaS9vdmVydmlldy5hc3B4I3BsYW5zIj5odHRwOi8vc21hbGxi dXNpbmVzcy52ZXJpem9uLmNvbS9wcm9kdWN0cy9pbnRlcm5ldC9oc2kvb3ZlcnZpZXcuYXNweCNw bGFuczwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SW4g VmVyaXpvbiwgdGhlIHBhY2thZ2UgZm9yIDEwLTE1bWJwcyBpcyAkOTAgcGVyIG1vbnRoIChJIGZl ZWwgdGhlIGJhbmR3aWR0aCBxdWFsaXR5IGZvciBidXNpbmVzcyB3b3VsZCBiZSBndWFyYW50ZWVk KS4gSSBxdWVyeQ0KIHRoYXQgdGhlIGJhbmR3aWR0aCBwcmljZSBpbiBDaGluYSBtYXkgYmUgNTAl IGhpZ2hlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIGRv IG5vdCBrbm93IGhvdyBtdWNoIHRoZSBwcmljZSB3aWxsIGJlIGZvciB0aGUgYmFuZHdpZHRoIGZy b20gQW1zdGVyZGFtIHRvIFBhcmlzIChjcm9zcyBjb3VudHJ5IGluIHRoZSBzYW1lIGNvbnRpbmVu dCkuJm5ic3A7IEJ1dA0KIEkgZmVlbCB0aGUgcHJpY2UgZnJvbSBOZXdZb3JrIHRvIFBhcmlzIHdv dWxkIGFic29sdXRlbHkgYmUgdmVyeSBoaWdoLiZuYnNwOyBBcyBmb3IgdGhlIEVuY29kZXIsIGl0 IGFsc28gdmFyaWVzLiBQZXJoYXBzIHRoZSBwcmljZSBpbiBDaGluYSB3aWxsIGJlIGhpZ2hlciB0 aGFuIGluIFVTQS4gQW5kIGluIGZhY3QgdGhlIHByaWNlIG9mIGJhbmR3aWR0aCBhbmQgZW5jb2Rl ciBkZXBlbmRzIG1vc3RseSBvbiB0aGUgY29uY3JldGUgYnVzaW5lc3MgaXRlbXMuDQogRm9yIGV4 YW1wbGUgdGhlIHByaWNlIHRvIEh1YXdlaSBtYXkgYmUgbG93ZXIgdGhhbiB0aGUgcHVibGljIHBy aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4y cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJ5IG15IGN1 cnJlbnQgZXZhbHVhdGlvbiBpbiBDaGluYSBpdCBpcyBiZXR0ZXIgdXNpbmcgdGhlIHRyYW5zY29k ZXIgdGhhbiByZW50aW5nIG11bHRpcGxlIHRpbWVzIGJyb2FkYmFuZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Tb21lIHBlb3BsZSBoYXZlIHRvbGQgbWUgdGhh dCBmb3IgdGhlIG9wZXJhdG9yIGhpbXNlbGYgcHJvYmFibHkgdGhlIGJhbmR3aWR0aCBjb3N0IHdv dWxkIGJlIHZlcnkgbG93IGluIHRoZSBpbnRlcm5hbCBjYXBpdGFsIGNvdW50aW5nLg0KIEJ1dCBm b3IgdGhlIGluZGVwZW5kZW50IENETiwgaXQgbWF5IGFub3RoZXIgdGhpbmcuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U28sIG15IHN1Z2dlc3Rpb24gaXMgdG8g bGV0IGRpZmZlcmVudCB3YXlzIGNvLWV4aXN0LiBJIGhhdmUgYW5ub3VuY2VkIHRoYXQgdG8gbGV0 IHR3byBzaWRlcyBuZWdvdGlhdGUgd2hldGhlciB0byBhc3NpZ24gZENETiBmb3INCiB0aGUgY29u dGVudCBhZGFwdGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPklu IGZhY3QsIGZyb20gQ1AgdG8gQ0ROLCZuYnNwOyB0aGVyZSBhcmUgdGhlIHJlYWwgYnVzaW5lc3Nl cyB0aGF0IGVpdGhlciBsZXQgQ1AgdG8gcHJvdmlkZSBtdWx0aS1mb3JtYXQgY29udGVudCBvciBs ZXQgdGhlIENETiB0byByZWNlaXZlDQogb25lIGZvcm1hdCBhbmQgY29tcGxldGUgdGhlIHRyYW5z Zm9ybWF0aW9uLCBkZXBlbmRpbmcgb24gdGhlIGNvbmNyZXRlIGJ1c2luZXNzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJ5IHRoZSBzYW1lIGxvZ2ljLCBmb3Jt IHVDRE4gdG8gZENETiwgaXQgbWF5IGJlIGVpdGhlciB0aGUgdUNETiB0byBwcm92aWRlIG11bHRp LWZvcm1hdCBjb250ZW50IG9yIHRoZSBkQ0ROIHRvIHJlY2VpdmUgb25lIGZvcm1hdA0KIGNvbnRl bnQgYW5kIHRoZW4gY29tcGxldGUgdGhlIHRyYW5zZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkN1cnJlbnRseSB0aGVyZSBpcyBub3QgdGhlIHJl YWwgQ0ROLUNETiBjb25uZWN0aW9uLCBoZW5jZSB3ZSBhcmUgYmFzaW5nIG91ciBrbm93bGVkZ2Ug b24gdGhlIHJlbGF0ZWQgc29sdXRpb24gdG8gbWFrZSBvdXIgc29sdXRpb25zLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O2xpbmUtaGVpZ2h0OjEzLjJw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Myk8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFz DQogZm9yIHRoZSBwcm9jZWR1cmUgb2YgY29udGVudCBhZGFwdGF0aW9uLCBJIGp1c3QgZHJhZnQg YSBkaWFncmFtIGFzIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZsdDtpbWFnZTAwNC5wbmcmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+WW91IG1heSBzZWUgdGhlIHNvbHV0aW9uIGlzIHJhdGhlciBjbGVhciBhbmQgdGhl IG1ldGFkYXRhIG5lZWRlZCB3b3VsZCBiZSBjbGVhciBhbHNvLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkRlYXIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+QnkgbXkgYW5hbHlzaXMgYWJvdmUsIEkga2luZGx5IGludml0ZSB5b3VyIGlk ZWFzIHdoZXRoZXIgaXQgbWF5IGJlIGFuIGFwcGxpY2FibGUgYW5kIHNpbXBsZSBwYXJ0IGluIHRo ZSBDRE5JIGl0ZW0sIHByb3ZpZGVkIHRoYXQNCiB0aGUgc29sdXRpb24gaXMgb3BlbiB0byB0aGUg dHlwZXMgb2YgY29udGVudCBhZGFwdGF0aW9uIGFuZCBtYXkgYmUgb3B0aW9uYWxseSBpbXBsZW1l bnRlZCBpbiB0aGUgcmVhbCBzb2x1dGlvbnMvYnVzaW5lc3MuIEkgZmVlbCBmb3IgdGhvc2Ugb3Bl cmF0b3JzIHRoYXQgbmVlZCBzdWNoIGZ1bmN0aW9uYWxpdHkgaXQgd291bGQgYmUgdmVyeSBnb29k IHdoaWxlIGl0IGRvZXMgbm90IGltcGFjdCBvdGhlcnMgdGhhdCBkbyBub3QgaW1wbGVtZW50IGl0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoYW5rcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5aaGlwZW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItd2lkdGg6aW5pdGlhbDtib3JkZXItY29s b3I6aW5pdGlhbCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+V291bmR5LA0KIFJpY2hhcmQgW21haWx0bzpSaWNoYXJkX1dvdW5keUBjYWJs ZS5jb21jYXN0LmNvbV08c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDExIDc6MjMgUE08YnI+DQo8 Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Plpob3VaaGlwZW5nOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86J21hcmtAamV0LXN0cmVhbS5ubCI+J21hcmtAamV0LXN0cmVh bS5ubDwvYT4nOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86J2FsYW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29tIj4nYWxhbi5rYXZh bmFnaEBlcmljc3Nvbi5jb208L2E+Jzxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOidjZG5pQGlldGYu b3JnIj4nY2RuaUBpZXRmLm9yZzwvYT4nOyBXb3VuZHksIFJpY2hhcmQ8YnI+DQo8Yj5TdWJqZWN0 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6 IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDtJbiB5b3VyIGNvbXBhbnnigJlzIHdlYnNp dGUsIEkganVzdCBmaW5kIHNvbWUgaW5mb3JtYXRpb248YnI+DQo8YnI+DQpJIGhhdmUgdG8gc3Rl cCBpbiBhcyBjby1jaGFpciBoZXJlLjxicj4NCjxicj4NClRoZSBnb2FsIG9mIHRoaXMgV0cgaXMg bm90IHRvIGFsaWduIHZlbmRvciBwcm9kdWN0IHJvYWRtYXBzLCBvciB0byBlcXVhbGl6ZSBhbGwg dmVuZG9yIG9mZmVyaW5ncywgb3IgdG8gc3BlY2lmeSB0aGUgZW50aXJlIENETkkgZWNvc3lzdGVt LiBUaGUgZ29hbCBvZiB0aGlzIFdHIGlzIHRvIGVuYWJsZSB0aGUgaW50ZXJjb25uZWN0aW9uIGFu ZCBpbnRlcm9wZXJhdGlvbiBvZiB0d28gb3IgbW9yZSBDRE5zLCB3aXRoaW4gdGhlIGJvdW5kcyBv ZiB0aGUNCiBDRE5JIHdnIGNoYXJ0ZXIuPGJyPg0KPGJyPg0KSXQgaXMgT0sgdG8gaGF2ZSBhIGRp c2N1c3Npb24gYWJvdXQgd2hldGhlciBjb250ZW50IGFkYXB0YXRpb24gbmVlZHMgdG8gYmUgcGVy Zm9ybWVkIGJ5IHRoZSBkQ0ROLCBzaW5jZSB0aGF0IGRlY2lzaW9uIGltcGFjdHMgdGhlIHVDRE4t ZENETiBpbnRlcmZhY2UuIFNvIGxldCdzIGZpbmQgYSBwcm9kdWN0aXZlIHdheSB0byBkaXNjdXNz IHRoaXMgb24gdGhlIG1haWxpbmcgbGlzdCwgYW5kIHRvIGNsb3NlIHRoZSBkaXNjdXNzaW9uIGJ5 IElFVEYgODINCiAoaWYgbm90IHNvb25lcikuPGJyPg0KPGJyPg0KQ2FuIHNvbWVvbmUgZGVzY3Jp YmUgcmVhbC1saWZlIGV4YW1wbGVzIHdoZXJlIGRvd25zdHJlYW0gQ0ROIChvciBlZGdlIGNhY2hl LWJhc2VkKSBjb250ZW50IGFkYXB0YXRpb24gaXMgbmVlZGVkIHRvZGF5IGluIGEgcHJvZHVjdGlv biBlbnZpcm9ubWVudCwgb3Igc2hvcnRseT8gTm90IG1lcmVseSBhIGZlYXR1cmUgaW4gYSB2ZW5k b3IncyBwcm9kdWN0IG1hdGVyaWFscz88YnI+DQo8YnI+DQpTcGVha2luZyBhcyBhbiBpbmRpdmlk dWFsLCBJIGNhbiBmaW5kIGEgbG90IG9mIGV4YW1wbGVzIHdoZXJlIGRvd25zdHJlYW0gY29udGVu dCBhZGFwdGF0aW9uIGlzIG5vdCBuZWVkZWQsIGFuZCBhbnkgYWRhcHRhdGlvbiBpcyByZWFsbHkg cGFydCBvZiB0aGUgQ1AgLSB1Q0ROIGludGVyZmFjZSAod2hpY2ggaXMgb3V0IG9mIHRoZSBzY29w ZSBvZiBvdXIgY2hhcnRlcikuPGJyPg0KPGJyPg0KLS0gUmljaDxicj4NCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PGJyPg0KJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt O2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjppbml0aWFsIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb208L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+OiBaaG91WmhpcGVuZyBbbWFpbHRvOnpob3V6aGlwZW5nQGh1YXdlaS5jb21dPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ8L2I+ OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSAwMzo0NSBBTTxicj4NCjxiPlRvPC9iPjogTWFy ayBkZSBKb25nICZsdDs8YSBocmVmPSJtYWlsdG86bWFya0BqZXQtc3RyZWFtLm5sIj5tYXJrQGpl dC1zdHJlYW0ubmw8L2E+Jmd0OzsgQWxhbiBLYXZhbmFnaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFs YW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29tIj5hbGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbTwvYT4m Z3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CjxiPkNjPC9iPjo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8L2E+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDs8YSBocmVmPSJt YWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlN1YmplY3Q8L2I+OiBS ZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SGVsbG8gTWFyayw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+TmljZSB0byBtZWV0IHlvdSBvbiBsaW5lLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5JbiB5b3VyIGNvbXBhbnnigJlzIHdlYnNpdGUsIEkganVzdCBmaW5kIHNvbWUg aW5mb3JtYXRpb24gdGhhdCBhZGRyZXNzZXMg4oCcPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJOTCIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM0QzU2NUMiPlZvZGFmb25lDQogc3Vic2NyaWJlcnMgY29tcGxhaW5lZCBh Ym91dCB2aWRlbyBwZXJmb3JtYW5jZS7igJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+U2VlOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJo dHRwOi8vd3d3LmpldC1zdHJlYW0ubmwvc2VhcmNoLz9zZWFyY2g9dHJhbnNjb2RpbmciPmh0dHA6 Ly93d3cuamV0LXN0cmVhbS5ubC9zZWFyY2gvP3NlYXJjaD10cmFuc2NvZGluZzwvYT48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsIGluIHRoaXMgZ3JvdXAsPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIGxhc3QgZmV3IGRheXMsIGV4Y2VwdCB0aGUgcHVibGljIGVt YWlsIGRpc2N1c3Npb25zIEkgaGF2ZSBjb250YWN0ZWQgd2l0aCBzb21lIHBlb3BsZSBhbmQgZGlz Y3Vzc2VkIHdpdGggbXkgb3duIGNvbGxlYWd1ZXMgb2YgYWxsIGRldGFpbHMgb24NCiB0aGlzIGlz c3VlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5GaXJzdCwgYWx0aG91Z2gg dGhlIG1hcmtldCByZXF1aXJlbWVudCBmb3IgaXQgaXMgdmVyeSBpbXBvcnRhbnQsIEkgZmVlbCBJ 4oCZZCBiZXR0ZXIgc2hvdyB1cCBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBwcm9jZWR1cmUgaW52 b2x2ZWQuIEkgaGF2ZSBleHBsYWluZWQNCiBtYW55IHRpbWVzIHRoYXQgdG8gc3VwcG9ydCBjb250 ZW50IGFkYXB0YXRpb24gaXMgcmF0aGVyIHNpbXBsZSB3aGlsZSB0aGUgd29yZGluZyBpcyBub3Qg ZW5vdWdoLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIGJ1c3kgbWFr aW5nIHNvbWUgY29udHJpYnV0aW9ucyBvbiB0aGlzIGFuZCBwbGFuIHRvIHVwbG9hZCB0byBFVFNJ IG1lZXRpbmcgYW5kIElFVEYgQ0ROSS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+QnkgdGhlc2Ugd29yayZuYnNwOyBJIGZlZWwgdGhlIHBlb3BsZSBtYXkgY2F0Y2ggYSB3aG9s ZSB2aWV3IG9uIHRoaXMgaXNzdWUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlNlY29uZCwgZm9yIHRoYXQgZnVuY3Rpb25hbGl0eSwgaW4gaW1wbGVtZW50YXRpb24sIGlmIHNv bWUgZW50aXR5IGRvZXMgbm90IGNob29zZSB0byBzdXBwb3J0IGl0LCBpdCBtYXkgYmUgb2suIFNp bmNlIGl0IG1heSBiZSBuZWdvdGlhdGVkIGJldHdlZW48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+DQogdHdvIENETnMuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPklmIGRDRE4gZG9lcyBub3Qgc3VwcG9ydCB0aGF0LCBpdCBtYXkgYmUg dGhlIHVDRE4gcmVzcG9uc2libGUgdG8gY29tcGxldGUgdGhlIHRyYW5zY29kaW5nIGFuZCBkZWxp dmVyIHRoZSBjb250ZW50IG9mIG11bHRpcGxlIGZvcm1hdHMgYW5kIHJhdGVzDQogdG8gZENETi48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcmQsIGFsdGhvdWdoIENETkkg aXMgYSBuZXcgYXJjaGl0ZWN0dXJlLCB3aGlsZSB0aGUgY29udGVudCBvcGVyYXRpbmcgaGFzIGJl ZW4gZXhpc3RlZCBmb3IgeWVhcnMuIEFzIEkga25vdyB0aGUgY29udGVudCBmcm9tIFVTQSB0byB0 aGUgZG93bnN0cmVhbQ0KIG9wZXJhdG9yIGlzIHRyYW5zZmVycmVkIG9uIG9uZSBjb3B5IGFuZCB0 aGUgZG93bnN0cmVhbSBvcGVyYXRvciB3aWxsIGhhbmRsZSB0aGUgdHJhbnNjb2RpbmcuPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5QZXJoYXBzLCB0aGUgY29udGVudCBhZGFwdGF0aW9uIGlzIG1vcmUg b24gdGhlIG1vYmlsZSBvcGVyYXRpbmcuIEJ1dCBJIGZlZWwgY3VycmVudGx5IG1vc3Qgb3BlcmF0 b3Igd2lsbCBiZSBhIGFsbCBzZXJ2aWNlIG9wZXJhdG9yLiBBbmQgZm9yIHRoZQ0KIENETiBwcm92 aWRlcnMsIGl0IG1heSBiZSBiZXR0ZXIgdG8gc3VwcG9ydCBhbGwga2luZHMgb2Ygc2VydmljZS48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzaWRlcywgSSBsaWtlIHNheSB0 aGF0IHRoZSB0ZWNobm9sb2d5IG9uIHRoaXMgdG9waWMgaGFzIGJlZW4gZm9yIG1hbnkgeWVhcnMg YW5kIGhhcyBiZWVuIHJhdGhlciBtYXR1cmUsIGV2ZW4gc29tZSBpdGVtcyBpbiBpZXRmIHN1Y2gg YXMgcmZjMzUwNzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj4NCiBpY2FwLiBTbyBmcm9tIHRoZSB0ZWNobmlxdWUgcG9pbnQgb2YgdmlldywgaXQgaXMgYSBu YXR1cmUgYWN0aW9uIHRvIGJlIGludm9sdmVkIGluIENETiBpbnRlcmNvbm5lY3Rpb24uPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcy48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+WmhpcGVuZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtO2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjppbml0aWFsIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NYXJr DQogZGUgSm9uZyBbbWFpbHRvOm1hcmtAamV0LXN0cmVhbS5ubF08c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBPY3RvYmVy IDI3LCAyMDExIDQ6MjEgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkFsYW4gS2F2YW5hZ2g8YnI+DQo8Yj5DYzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkJlbiBOaXZlbi1K ZW5raW5zOyBaaG91WmhpcGVuZzs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVz ZS1jYXNlcy0wMC50eHQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkhpIEFsYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+QXMgQmVuIHN0YXRlZCB0aGUgb3ZlcmFsbCBkaXNjdXNzaW9uIHJpZ2h0IG5vdyBpcyBhYm91 dCBkZWxpdmVyeSwgbm90IG9uIGFkYXB0YXRpb24uIEl0IGlzIGhhcmQgZW5vdWdoIHRvIGdldCBj b25zZW5zdXMgb24gdGhlIGRlbGl2ZXJ5IGFzcGVjdCBhbHJlYWR5IG5vdCB0byBtZW50aW9uIHlv dXINCiByZXF1aXJlbWVudCBmcm9tIGNvbnRlbnQgYWRhcHRhdGlvbiBhZGRlZCB0byB0aGF0LCBz byBJIGFncmVlIHdpdGggQmVuIHdlIHNob3VsZCBzdGljayB3aXRoIHRoZSBkZWxpdmVyeSBhc3Bl Y3QgZm9yIHRoZSBmaXJzdCBzcGVjcy4mbmJzcDtJIGNhbiBpbWFnaW5lIHRoaXMgY291bGQgYmUg YSBkaXNjdXNzaW9uIGxhdGVyIG9uIGJ1dCBwbGVhc2UgbGV0IHVzIGtlZXAgdGhlIHNjb3BlIG9m IHRoaXMgYmUgY2xlYW4gYW5kIHRyYW5zcGFyZW50LiBJdCBpcw0KIG9mIGJlbmVmaXQgb2YgZXZl cnlvbmUgdG8gZ2V0IHRoZSBmaXJzdCBzcGVjcyBhcyBmYXN0IGFzIHBvc3NpYmxlLiBUaGFua3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxl LXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+TWV0IHZyaWVuZGVsaWprZSBncm9ldCw8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5 bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5LaW5kIHJlZ2FyZHMsPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJhcHBs ZS1zdHlsZS1zcGFuIj5NYXJrIGRlIEpvbmc8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxl LXN0eWxlLXNwYW4iPkludGVybmF0aW9uYWwgQnVzaW5lc3MgRGV2ZWxvcGVyPC9zcGFuPjxicj4N CjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5KZXQtU3RyZWFtIEJWPC9zcGFuPjxicj4N Cjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5FLW1haWw6PC9zcGFuPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+PGEgaHJlZj0ibWFpbHRvOm1hcmtAamV0LXN0cmVhbS5jb20iPm1h cmtAamV0LXN0cmVhbS5jb208L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHls ZS1zcGFuIj5PZmZpY2U6ICYjNDM7MzEgKDApNTAgNTI2MTgyMDwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+TW9iaWxlOiAmIzQzOzMxICgwKTYgODExMDgyNjM8L3Nw YW4+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPkZheDogJiM0MzszMSAoMCk1 MCA1MjY0MjE0PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LSBFdmVudDo8L3NwYW4+PC9i Pjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TWVldA0KIHVzIGF0IFN0cmVhbWluZyBNZWRp YSBFdXJvcGUsIDE3LTE4IE9jdG9iZXIsIExvbmRvbiwgVUs8L3NwYW4+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+LSBFdmVudDo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDtNZWV0DQogdXMgYXQgT25saW5lIFZpZGVvIFN0cmF0ZWdpZXMs IDE5IE9jdG9iZXIsIExvbmRvbiwgVUs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxl LXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+LSBFdmVudDo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUt c3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDtNZWV0DQogdXMgYXQgQ0ROIFdvcmxkIFN1bW1pdCwgMjUtMjggT2N0b2JlciwgTG9u ZG9uLCBVSzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tPC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TmV3czo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBj bGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDtQcmUtcmVxdWVzdA0KIHlvdXIgVGVjaG5vbG9neSBX aGl0ZXBhcGVyIG5vdyBhbmQgYmUgdGhlIGZpcnN0IHRvIGhhdmUgaXQsIGNoZWNrPC9zcGFuPjwv c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFt LmNvbSI+d3d3LmpldC1zdHJlYW0uY29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1z cGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pi0mbmJzcDs8Yj5OZXdzOiZuYnNwOzwvYj5DaGVjayZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cu amV0LXN0cmVhbS5jb20iPmh0dHA6Ly93d3cuamV0LXN0cmVhbS5jb208L2E+PC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+dG8NCiBkb3dubG9hZCBvdXIgJ1NpeCBUcmVuZHMgaW4g Q0ROcycgYnJvY2h1cmU8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFw cGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJsb2c6 PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJo dHRwOi8vd3d3LmpldC1zdHJlYW0uY29tL2Jsb2cvIj53d3cuamV0LXN0cmVhbS5jb20vYmxvZy88 L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2 LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlZpZGVvRXhjaGFuZ2U6PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBj bGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LnZkby14Lm5ldCI+d3d3LnZk by14Lm5ldDwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tPC9zcGFuPjwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U3RyZWFtemlsbGE6PC9zcGFuPjwvYj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9iPjwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LnN0cmVhbXppbGxh Y2RuLmNvbSI+d3d3LnN0cmVhbXppbGxhY2RuLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt c3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4tPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q29ycG9yYXRl Ojwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8v d3d3LmpldC1zdHJlYW0uY29tIj53d3cuamV0LXN0cmVhbS5jb208L2E+PC9zcGFuPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5PbiAyNiwgT2N0LDIwMTEs IGF0IDg6MzMgUE0sIEFsYW4gS2F2YW5hZ2ggd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZW48YnI+DQo8YnI+DQpJbSBh c3N1bWluZyB0aGVuIGJhc2VkIG9uIHlvdXIgY29tbWVudHMgYmVsb3cgYXJlIHlvdSBzdWdnZXN0 aW5nIHdlIGFyZSBnb2luZyB0byBoYXZlIGEgbnVtYmVyIG9mIHZlcnNpb25zIG9mIHRoZSBDRE4t SSBNZXRhZGF0YT88YnI+DQo8YnI+DQpJIHN5bXBhdGhpc2Ugd2l0aCB3aGF0IHlvdSBhcmUgcG9p bnRpbmcgb3V0IGJlbG93IGFuZCBkbyBhZ3JlZSB0aGF0IHRoZXJlIGlzIHNvbWUgd29yayB0byBi ZSBkb25lLCBidXQgSSBzdGlsbCBmZWVsIHRoYXQgY29udGVudCBhZGFwdGF0aW9uIGlzIHRvIG1l IGEgZnVuZGFtZW50YWwgcmVxdWlyZW1lbnQgdG8gd2hhdCBjb2xsZWN0aXZlbHkgd2Ugc2hvdWxk IGFkZHJlc3MgaW4gdGhlIENETi1JIFdHLiBJIGRvIGFncmVlIHdpdGggeW91IHRoYXQgY29udGVu dA0KIGFkYXB0YXRpb24gaXMgYW4gb3B0aW1pemF0aW9uIGJldHdlZW4gQ0ROJ3MgYnV0IGl0J3Mg YSB2ZXJ5IGltcG9ydGFudCBvbmUgdGhhdCBJIGtub3cgTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVy cyBwYXJ0aWN1bGFybHkgcmVxdWlyZS48YnI+DQo8YnI+DQpBbGFuPGJyPg0KPGJyPg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYu b3JnIj5jZG5pLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgQmVuIE5pdmVuLUplbmtpbnM8YnI+DQpTZW50OiBPY3RvYmVyLTEyLTExIDE6MTMg UE08YnI+DQpUbzogWmhvdVpoaXBlbmc8YnI+DQpDYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNk bmlAaWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxicj4NCjxicj4NClpoaXBlbmcsPGJyPg0KPGJy Pg0KT24gMTIgT2N0IDIwMTEsIGF0IDEwOjIyLCBaaG91WmhpcGVuZyB3cm90ZTo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhlbGxvIEJlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5UaGUgVUUgbWF5IHNlbGVjdCB0aGUgY29udGVudCBmb3JtYXQgb24gdGhlIENQ IHdlYi4gQWZ0ZXIgdGhhdCB0aGUgdXNlciBvbmx5IGRlc2lyZXMgdG8gZ2V0IGhpcyBzZWxlY3Rl ZCBjb250ZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PkJ1dCBob3cgdGhlIGNvbnRlbnQgaXMgdHJhbnNmZXJyZWQgdG8gdGhlIGNsaWVudCBpcyBub3Qg d29ycmllZCBieSB0aGUgdXNlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5UaGUgQ1AgbWF5IGNyZWF0ZSBhIHNwZWNpYWwgZm9ybWF0IGFzIHJlcXVpcmVk IGJ5IHRoZSB1c2VyIGFuZCBhc2sgdGhlIENETiB0byBkZWxpdmVyIHRvIHVzZXIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+V2hpbGUgQ1AgbWF5IGdpdmUg YSBIRCBmb3JtYXQgY29udGVudCB0byB1Q0ROIGFuZCB0aGUgZENETiBtYXkgdGhlbiB0cmFuc2Zv cm0gdG8gdGhlIGZvcm1hdCBhcyB0aGUgdXNlciBzZWxlY3QuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpMb3Rz IG9mIHRoaW5ncyBtYXkgYmUgcG9zc2libGUgdG8gZG8gYW5kIENETiBwcm92aWRlcnMgb2ZmZXIg bWFueSBhZGRpdGlvbmFsIHNlcnZpY2VzIG9uIHRvcCBvZiB0aGUgJnF1b3Q7Y29yZSZxdW90OyBz ZXJ2aWNlIG9mIGNvbnRlbnQgZGVsaXZlcnkuIEhvd2V2ZXIsIG91ciBvYmplY3RpdmUgKGJhc2Vk IG9uIG15IGludGVycHJldGF0aW9uIG9mIHRoZSBDRE5JIGNoYXJ0ZXIpIGlzIHRvIGZvY3VzIG9u IHdoYXQgaXMgbmVjZXNzYXJ5IHRvIGludGVyY29ubmVjdA0KIENETnMgdG8gZGVsaXZlciBjb250 ZW50IGZyb20gYSBDU1AgdG8gYW4gRW5kIFVzZXIgdGhhdCBpcyB0YXJnZXRlZCBhbmQgZGVwbG95 YWJsZSB3aXRoaW4gYSBzaG9ydCB0aW1lIGZyYW1lICgxOC0yNCBtb250aHMpLjxicj4NCjxicj4N CkNvbnRlbnQgdHJhbnNmb3JtYXRpb24vYWRhcHRhdGlvbiBpcyBub3QgYW4gZXNzZW50aWFsIHJl cXVpcmVtZW50IGluIG9yZGVyIHRvIGFjaGlldmUgdGhhdCBhaW0gKHdlIGNhbiBkZWxpdmVyIGNv bnRlbnQgZnJvbSBDU1BzIHRvIEVuZCBVc2VycyB2aWEgbXVsdGlwbGUgQ0ROcyB3aXRob3V0IG5l ZWRpbmcgb3IgcmVxdWlyaW5nIGFueSBDRE4gc3VwcG9ydHMgY29udGVudCBhZGFwdGF0aW9uKS48 YnI+DQo8YnI+DQpJbiBteSBvcGluaW9uIHdlIGhhdmUgZW5vdWdoIHdvcmsgdG8gZG8gYWxyZWFk eSB3aXRob3V0IHRyeWluZyB0byBleHBhbmQgdGhlIHNjb3BlIG9mIG91ciB3b3JrIHRvIGluY2x1 ZGUgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgdGhhdCBkbyBub3QgaGVscCB1cyBhZGRyZXNzIG91 ciBjb3JlIG9iamVjdGl2ZXMgYXMgbGFpZCBvdXQgaW4gdGhlIENETkkgY2hhcnRlci48YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkluIHRoaXMgY2FzZSwgaXQgaXMgbm90aGluZyBy ZWxhdGVkIHRvIGhvdyB0aGUgdXNlciBzZWxlY3QgZm9ybWF0cyBvbiBDUCB3ZWJzaXRlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNvLCBpdCBpcyB0aGUgQ1AgYW5kIHVzZXIgdG8g ZGVjaWRlIHRoZSBjb250ZW50IGZvcm1hdCBub3QgdGhlIENETih5b3VyIGFzc2VydCBpcyBub3Qg Y29ycmVjdCBhbmQgc2VlbXMgeW91IHRha2UgdGhhdCBhc3NlcnQgYXMgeW91ciBiYXNlIGZvciB0 aGUgZGlzY3Vzc2lvbikuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+QXMgZm9yICZxdW90O3RoZSBjb3JlIENETiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgQ0RO cyB0b2RheSZxdW90OywgSSBoYXZlIGV2ZXIgcmFpc2VkIGFuIGVtYWlsIGJlZm9yZSB0aGF0IHlv dXIgY29tcGFueSdzIHdlYnBhZ2UgaGFzIGNsYWltZWQgc3VwcG9ydGluZyBtZWRpYSB0cmFuc2Zv cm1hdGlvbiBhbmQgbXVsdGktc2NyZWVuDQogc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5QZXJoYXBzLCBJIGxpa2UgYXNraW5nIHlvdSBsaXN0 IHNvbWUgZmVhdHVyZXMgdGhhdCB5b3UgZmVlbCBhcmUgdGhlIGNvcmUgZnVuY3Rpb25hbGl0aWVz IGJ5IGV4aXN0aW5nIG1haW4gc3RyZWFtIENETnMuIFRodXMgd2UgbWF5IGNvbXBhcmUgYW5kIHRh a2UgZGVlcCBsb29rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0KSSB0aGluayB0aGUgY29yZSBmdW5jdGlvbmFs aXR5IG1hcHMgcHJldHR5IHdlbGwgdG8gdGhlIENETkkgaW50ZXJmYWNlcywgbmFtZWx5OiBSZXF1 ZXN0IFJvdXRpbmcsIE1ldGFkYXRhIGNvbmZpZ3VyYXRpb24sIGxvZyBwcm9kdWN0aW9uIGFuZCBj b250cm9sIHBsdXMgY29udGVudCBhY3F1aXNpdGlvbiBhbmQgY29udGVudCBkZWxpdmVyeS48YnI+ DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgZ3Vlc3MgbWFueSBwZW9wbGUgaGF2ZSB0 aGUgZXhwZXJpZW5jZS9rbm93bGVkZ2Ugb2YgY29udGVudCByZWxhdGVkIHNlcnZpY2UuIFRoZSB1 c2VyIGFuZCBDUCBvbmx5IGNhcmUgd2hldGhlciB0aGUgQ0ROIHByb3ZpZGVycyBtYXkgc2F0aXNm eSB0aGVpciByZXF1aXJlbWVudCB3aGlsZSBub3QgY2FyZQ0KIHRoZSBpbnRlcm5hbCBwcm9jZXNz LiBKdXN0IGFzIEdTTS9QU1ROIGludGVyY29ubmVjdGlvbiwgdGhlIHVzZXIgb25seSBjYXJlIHN1 Y2Nlc3NmdWwgaW50ZXJjb25uZWN0aW9uIHdoaWxlIG5vdCBjYXJlIGhvdyB0aGUgdm9pY2UgaXMg dHJhbnNmb3JtZWQgaW4gcHJvY2Vzcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZXNp ZGVzLCBJIGxpa2UgcmFpc2UgYSBjYXNlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPkdpdmVuIGN1cnJlbnRseSBCQkMgcmVjcnVpdHMgQ0ROIHByb3ZpZGVy cyB0aGF0IG1heSBzdXBwb3J0IDEwIG1lZGlhIGZvcm1hdHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+T25lIGNhbmRpZGF0ZSBpcyB5b3VyIGNvbXBhbnks IGFub3RoZXIgaXMgQ0ROLVguIFRoZSB1c2VycyBhcmUgbG9jYXRlZCBpbiBGcmFuY2UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U28gYm90aCB5b3VyIGNv bXBhbnkgYW5kIENETi1YIHNob3VsZCBjb25uZWN0IGEgRnJhbmNlIENETiBwcm92aWRlcihDRE4t WSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SWYgeW91 ciBjb21wYW55J3Mgc29sdXRpb24gaXMgdG8gc2VuZCAxMCBzdHJlYW1zIG9mIGRpZmZlcmVudCBm b3JtYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5vZiBv bmUgY29udGVudCB0byBDRE4tWTsgV2hpbGUgQ0ROLVgncyBzb2x1dGlvbiBpcyB0byBzZW5kIDEg c3RyZWFtIHRvIENETi1ZIHdoaWxlIENETi1ZIG1heSBjb25kdWN0IHNvbWUgYWRhcHRhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Db21wYXJpbmcg dGhlc2UgdHdvIHNvbHV0aW9ucywgZm9yIHlvdXIgY29tcGFueSBhbmQgQ0ROLVgsIGFic29sdXRl bHkgdGhlIGNvc3Qgb2YgQ0ROLVggaXMgbXVjaCBsb3dlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gb3IgQ0ROLVksIGluIHNvbHV0aW9uLTEsIGl0IHNo b3VsZCByZWNlaXZlL2ZvcndhcmQgMTAgc3RyZWFtcyA7IHdoaWxlIGluIHNvbHV0aW9uLTIsIGl0 IHNob3VsZCBvbmx5IHJlY2VpdmUgMSBzdHJlYW0gYnV0IG5lZWQgdG8gdGFrZSB0cmFuc2Zvcm1h dGlvbiB0byBvdXRwdXQgMTAgc3RyZWFtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5XaGljaCBzb2x1dGlvbiBpcyBtb3JlIGNvbXBldGl0aXZlLiBpdCBpcyBT b2x1dGlvbiAxLCByaWdodC4gUmVtZW1iZXIgdGhlIHByaWNlIGZyb20gQkJDIGlzIHNhbWUgdG8g Ym90aCB5b3VyIGNvbXBhbnkgYW5kIENETi1YIG9yIEJCQyB3b3VsZCBzZWxlY3Qgb25lIENETiBw cm92aWRlciB3aXRoIHRoZQ0KIGxvd2VyIHByaWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPklmIGEgQ0ROIHByb3ZpZGVyIG1heSBub3QgZ2V0IHRoZSBj b250cmFjdCBmcm9tIENQLCBob3cgaXQgbWF5IHNheSBpdCBpcyBub3QgYSBjb3JlIGZ1bmN0aW9u YWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpXaGF0IHlvdSBhcmUgZGVzY3JpYmluZyBpcyBhIHBvc3Np YmxlIG9wdGltaXphdGlvbiB0aGF0IGEgcGFydGljdWxhciBDRE4gbWF5IHdpc2ggdG8gaW1wbGVt ZW50IG5vdCBhIGNvcmUgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCB0byBlbmFibGUgY29udGVudCBk ZWxpdmVyeSBiZXR3ZWVuIGludGVyY29ubmVjdGVkIENETnMuIEkgY2FuIHRoaW5rIG9mIG1hbnkg b3B0aW1pemF0aW9ucyB0aGF0IGEgQ0ROIGNvdWxkIGltcGxlbWVudCB0byBkaWZmZXJlbnRpYXRl DQogdGhlaXIgc2VydmljZSBidXQgdGhlIGludGVybmFsIHdvcmtpbmdzIG9mIGFuIGluZGl2aWR1 YWwgQ0ROIGFyZSBvdXQgb2Ygc2NvcGUgb2Ygb3VyIGNoYXJ0ZXIuPGJyPg0KPGJyPg0KU28gdG8g cmVwZWF0IG15IHBvc2l0aW9uIGZvciBhIGZpbmFsIHRpbWU6IENvbnRlbnQgYWRhcHRhdGlvbiBp cyBub3QgYSBjb3JlIGZ1bmN0aW9uIHJlcXVpcmVkIHRvIGVuYWJsZSBjb250ZW50IGRlbGl2ZXJ5 IGJldHdlZW4gaW50ZXJjb25uZWN0ZWQgQ0ROcyBhbmQgdGhlcmVmb3JlIGdpdmVuIHRoZSB3b3Jr bG9hZCB3ZSBhbHJlYWR5IGhhdmUgdG8gc3BlY2lmeSBzb2x1dGlvbnMgdGhhdCBkbyBhZGRyZXNz IHRoZSBjb3JlIGZ1bmN0aW9uYWxpdHkNCiByZXF1aXJlZCB0byBpbnRlcmNvbm5lY3QgQ0ROcyBJ IGRvIG5vdCB0aGluayB3ZSBzaG91bGQgYmUgdHJ5aW5nIHRvIGFkZCBtb3JlIHdvcmsgaW50byB0 aGF0IHdvcmtsb2FkIGFzIGl0IHdpbGwgb25seSBkaXN0cmFjdCB1cyBmcm9tIGFjaGlldmluZyBv dXIgZ29hbCBvZiBwcm9kdWNpbmcgZGVwbG95YWJsZSBzb2x1dGlvbnMgd2l0aGluIHRoZSB0aW1l ZnJhbWUgd2UgYXJlIGJlaW5nIHRvbGQgYnkgb3BlcmF0b3JzIHRoZXkgbmVlZHMgc29sdXRpb25z DQogd2l0aGluLjxicj4NCjxicj4NCkJlbjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+U28sIGlmIHdlIGFsbCByZWFsaXplIHRoYXQgY3VycmVudGx5IHRoZSBtZWRpYSB0eXBlIGlz IHJpY2gsIHRoZSBDRE4gcHJvdmlkZXJzIHNob3VsZCBzdXJ2aXZlIGluIHRoZSBleGlzdGluZyBl Y29zeXN0ZW0gYW5kIHN1cHBvcnQgdGhlIG1lZGlhIHR5cGVzIGFzIHJlcXVpcmVkIGJ5IHRoZSBt YXJrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QmFjayB0byB0aGUgY2FzZSBvZiBH U00vRy43MTEsIGl0IGp1c3Qgd2hlbiBjb25jZXJuaW5nIHRoZSBpbnRlcmNvbm5lY3Rpb24sIHRo ZSB0cmFuc2Zvcm1hdGlvbiBzaG91bGQgYXQgb25jZSBiZSBzb2x2ZWQuIE90aGVyd2lzZSB0aGUg aW50ZXJjb25uZWN0aW9uIG1heSBub3QgYmUgb3BlcmF0ZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+QnIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+RnJvbTogQmVuIE5pdmVuLUplbmtpbnMgW21haWx0bzpiZW5A bml2ZW4tamVua2lucy5jby51a108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIwMTEgMTI6MTkgQU08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UbzogWmhvdVpoaXBl bmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5DYzo8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbSI+cGhpbGlwLmVhcmRsZXlAYnQuY29tPC9hPjs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPlpoaXBlbmcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+T24gMTEgT2N0IDIwMTEsIGF0IDA1OjE2LCBaaG91WmhpcGVuZyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJlbiBh bmQgUGhpbGlwLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+SSBsaWtlIHRvIHJlc3BvbmQgeW91ciBjb25jZXJuIGluIHRoaXMg b25lIGVtYWlsOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIGZlZWwgd2hhdCB3 ZSBhcmUgbm93IGRpc2N1c3NpbmcgaXMgd2hhdCBpcyB0aGUgJnF1b3Q7Y29yZSZxdW90OyBmdW5j dGlvbiBvZiBDRE4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5BcyB5b3Ugc2F5LCBDRE4gaXMgdXNlZCB0byBkZWxpdmVyIGNv bnRlbnQuIFRoYXQgaXMgYWJzb2x1dGVseSBjb3JyZWN0IHRoYXQgdGhlIGRlbGl2ZXJ5IGNhcGFi aWxpdHkgaXMgdGhlIGNvcmUgcmVxdWlyZW1lbnQgZm9yIENETiBzeXN0ZW0uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XaGls ZSBDRE4gaXMgdXNlZCB0byBwcm92aWRlIHRoZSBjb250ZW50IGRlbGl2ZXJ5IHNlcnZpY2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5XaGF0IG1lYW5zIHNlcnZpY2UuIEl0IHNob3VsZCBpbmNsdWRlICZxdW90O3RpbWUmcXVv dDsgJnF1b3Q7bG9jYXRpb24mcXVvdDsgYW5kICZxdW90O21lZGlhIHR5cGUmcXVvdDssIGV0Yy4g VGhlc2UgZmVhdHVyZXMgYXJlIGFsbCB0aGUgY29yZSBmZWF0dXJlIGZvciBhIHNlcnZpY2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5JZiB3ZSBvbmx5IGNvbmNlcm4gJnF1b3Q7ZGVsaXZlcmluZyBvbmUgZGF0YSBibG9jayZx dW90OywgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSBpc3N1ZXMgc3VjaCBhcyAmcXVvdDtsb2dn aW5nJnF1b3Q7ICZxdW90O2dlb2dyYXBoaWMgY29uc3RyYWludCZxdW90OyBhcmUgdGhlIGNvcmUg b2YgQ0ROLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gb3IgJnF1b3Q7d2l0aG91dCBleHBsaWNpdCBr bm93bGVkZ2Ugb2Ygd2hhdCB0aGF0IGNvbnRlbnQgYWN0dWFsbHkgaXMgJnF1b3Q7LCBJIGFtIG5v dCBzdXJlIHdoZXRoZXIgdGhlIHdvcmRpbmcgaXMgYWNjdXJhdGUgc2luY2UgZ2VuZXJhbGx5IGEg Q0ROIG1heSBjbGFpbSBpdCBzdXBwb3J0IGRpZmZlcmVudCBtZWRpYXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CeSB0aGlz IG9wcG9ydHVuaXR5LCBJIGxpa2UgdG8gc2hhcmUgYSB1c2UgY2FzZTogYSBjYWxsIGZyb20gYSBH U00gcGhvbmUgdG8gYSBQU1ROIHRlbGVwaG9uZSwgdGhlIHZvaWNlIHN0cmVhbSBzaG91bGQgYmUg dHJhbnNmb3JtZWQgZnJvbSBHU00gdm9pY2UgdG8gRy43MTEuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gb3IgdGhlIHVzZXIs IGhlIGRvZXMgbm90IG5lZWQgdG8ga25vdyB3aGF0IHR5cGUgb2YgZGF0YSBoYXMgYmVlbiB0cmFu c2ZlcnJlZCwgYnV0IHRoZSBvcGVyYXRvciBoYXMgZG9uZSBzb21lIHdvcmsgdG8gaW50ZXJjb25u ZWN0IHR3byBzeXN0ZW1zLCByaWdodC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgbGlrZSB0byBrbm93IHdoZXRoZXIgeW91 IG1heSBhY2NlcHQgdGhhdCBteSB1c2UgY2FzZSBpcyBzaW1pbGFyIHRvIHRoaXMgY2FzZSBhYm92 ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5JIGRvbid0IHRoaW5rIHlvdXIgdXNlIGNhc2UgaXMgc2ltaWxhciB0byB0aGUgYW5hbG9n eSBvZiBtb2JpbGUgbmV0d29ya3MgYmVpbmcgaW50ZXJjb25uZWN0ZWQgdG8gUFNUTiBuZXR3b3Jr cy4gSW4gdGhlIGNhc2Ugb2YgY29udGVudCBkZWxpdmVyeSB0aGUgbmVnb3RpYXRpb24gaXMgZG9u ZSBiZXR3ZWVuDQogdGhlIFVzZXIvQ2xpZW50IGFuZCB0aGUgQ29udGVudCBQcm92aWRlciBhbmQg dGhlIENETiBpcyBqdXN0IHVzZWQgdG8gZXhlY3V0ZS9wZXJmb3JtIHRoZSBkZWxpdmVyeSB0aGF0 IGhhcyBiZWVuIG5lZ290aWF0ZWQuIFRoZSBDRE4gaXMgbm90IGludm9sdmVkIGluIHRoZSBkZWNp c2lvbiBtYWtpbmcgb2Ygd2hhdCByZXByZXNlbnRhdGlvbnMgdGhlIENvbnRlbnQgUHJvdmlkZXIg ZGVjaWRlcyB0byBvZmZlciB0byB0aGUgVXNlci9DbGllbnQgb3IgaW4NCiB3aGF0IHJlcHJlc2Vu dGF0aW9ucyB0aGUgVXNlci9DbGllbnQgZGVjaWRlcyB0byByZXF1ZXN0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QXMgZm9yIHlvdSBzYWlkIHNlbGVjdGlu ZyBtZWRpYSBieSB0aGUgJnF1b3Q7cG9ydGFsJnF1b3Q7LCB5b3UgbWF5IHNlZSB0aGUgd2F5ICZx dW90OyB1Q0ROIGRlbGl2ZXJzIG11bHRpcGxlIG1lZGlhIHN0cmVhbXMgdG8gZENETiZxdW90OyBp cyBub3QgZ29vZCB0aGFuICZxdW90O3VDRE4gZGVsaXZlcnMgb25lIG1lZGlhIHN0cmVhbSB0byBk Q0RODQogYW5kIGRDRE4gdGFrZXMgc29tZSBhZGFwdGF0aW9uIHRvIHN1cHBvcnQgbXVsdGlwbGUg bWVkaWEgdHlwZXMmcXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Tm93IHdoYXQgeW91J3JlIHRhbGtpbmcgYWJvdXQgaXMgYW4g b3B0aW1pc2F0aW9uLCBub3QgYSBjb3JlIGZ1bmN0aW9uIHJlcXVpcmVkIHRvIGFjdHVhbGx5IGRl bGl2ZXIgdGhlIGNvbnRlbnQgKGFuZCByZXBvcnQsIGJpbGwsIGV0Yy4gZm9yIHRoYXQgZGVsaXZl cnkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk15IHBvc2l0 aW9uIGlzIHRoYXQgd2Ugc2hvdWxkIGZvY3VzIG9uIGhvdyB0byBlbmFibGUgdGhlIGludGVyY29u bmVjdGlvbiBvZiB0aGUgY29yZSBDRE4gZnVuY3Rpb25hbGl0eSBvZmZlcmVkIGJ5IENETnMgdG9k YXkgKHdoaWNoIGlzIGFsc28gbXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlIHNjb3BlDQogb2YgdGhl IENETkkgd29ya2luZyBncm91cCBhcyBleHByZXNzZWQgaW4gaXRzIGNoYXJ0ZXIpIGJlY2F1c2Ug ZG9pbmcgc28gaXMgYSBzaWduaWZpY2FudCBwaWVjZSBvZiB3b3JrIGluIGl0c2VsZi4gTGV0J3Mg bm90IHN0YXJ0IHRyeWluZyB0byBhZGQgaW4gYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGJleW9u ZCB3aGF0IHRoZSBtYWpvcml0eSBvZiBDRE5zIHN1cHBvcnQgdG9kYXkgYXMgdGhhdCB3aWxsIGp1 c3QgZGVsYXkgdXMgZ2V0dGluZyB1c2FibGUNCiBzcGVjaWZpY2F0aW9ucyBpbnRvIHRoZSBtYXJr ZXQgaW4gYSB0aW1lbHkgZmFzaGlvbiBJTU8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+QmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5BIGdvb2QgcXVlc3Rpb24gaXMgJnF1b3Q7c2VjdXJpdHkmcXVvdDsgc2luY2UgSSBo YXZlIGRvbmUgc2l4IHllYXJzIG9uIHRoZSBEUk08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmFuZCBsaWtlIHRvIHByb21vdGUg dGhlIERSTSBhbGwgYXJvdW5kIHRoZSB3b3JsZDopIElmIHRoZSBjb250ZW50IGlzIG5lZWRlZCB0 byBiZSBwcm90ZWN0ZWQsIGdlbmVyYWxseSB5b3UgbWF5IGtub3cgYWxsIHRoZSBzeXN0ZW1zIHNo b3VsZCBiZSBncmFudGVkIGJ5IHRoZSBjb250ZW50IG93bmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SGVyZSBJIGFsc28g bGlrZSB0byBjbGFyaWZ5IHRoYXQgbm90IG9ubHkgdGhlIG1lZGlhIGl0c2VsZiBidXQgdGhlIGlu Zm9ybWF0aW9uIHJlbGF0ZWQgdG8gc2VydmljZSBpdHNlbGYgKHN1Y2ggYXMgdGhlIGdlb2dyYXBo aWMgY29uc3RyYWludCkgc2hvdWxkIGJlIHByb3RlY3RlZCBhbHNvLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U28sIHRydXN0 IGlzIG5vdCBhIHByb2JsZW0gZm9yIHRoZSBtZWRpYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+UGhp bGlwLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+VGhhbmsgeW91IHRoYXQgeW91IGZlZWwgQ29udGVudCBBZGFwdGlvbiBpcyBh biBpc3N1ZSBmb3IgJnF1b3Q7UmVxdWlyZW1lbnRzJnF1b3Q7IGJ1dCBJIGRvIG5vdCBrbm93IHdo eSBpdCBpcyBub3QgZm9yIFVzZSBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SSBsaWtlIHRvIGNsYXJpZnkgdG8gVSB0 aGF0IGl0IGlzIGltcG9ydGFudCBmb3IgeW91IG9wZXJhdG9yIHNpbmNlIGl0IG1heSBzYXZlIGlu dmVzdG1lbnQgaWYgdGhlIHN5c3RlbSBtYXkgc3VwcG9ydCBkaWZmZXJlbnQgc2VydmljZXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5Gb3IgdXMgdmVuZG9yLCB3ZSBhcmUgaGFwcHkgb3BlcmF0b3IgbWF5IGluc3RhbGwgYSBz eXN0ZW0gZm9yIHRoZSBtb2JpbGUgc2VydmljZSBhbmQgYW5vdGhlciBzeXN0ZW0gZm9yIHRoZSBG QkIgc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkJ1dCB0aGUgcmVhbGl0eSBpcyBhbGwgb3BlcmF0b3JzIGFzayB1 cyB0byBwcm92aWRlIGEgc3lzdGVtIHRoYXQgbWF5IHN1cHBvcnQgZGlmZmVyZW50IHNlcnZpY2Ug c3lzdGVtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+RnJhbmtseSwgQmVuIGFuZCBQaGlsaXAsIEkg cmVtZW1iZXIgSSBoYXZlIGV4cGxhaW5lZCBzb21ld2hlcmUgdGhhdCB0byBpbXBsZW1lbnQgdGhp cyBpcyByYXRoZXIgc2ltcGxlIC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkF0IGxlYXN0IHRoZSBVc2UgY2FzZSBhbmQgUmVx dWlyZW1lbnQgYXJlIGluZm9ybWF0aW9uYWwgdG8gYmUgcmVmZXJyZWQgaW4gZnV0dXJlIHdvcmsu IFNvIEkgZG8gcmVhbGx5IGZlZWwgeW91IG1heSBhY2NlcHQgaXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5PZiBjb3Vyc2Ug SSBsaWtlIHRvIHJlc3BvbmQgeW91ciBtb3JlIGNvbmNlcm4gYW5kIGNvbW1lbnRzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkZyb206PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20iPnBoaWxpcC5lYXJkbGV5QGJ0LmNvbTwvYT48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W21haWx0bzpwaGls aXAuZWFyZGxleUBidC5jb21dPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TZW50OiBNb25kYXksIE9jdG9iZXIgMTAsIDIwMTEg MTE6MjIgUE08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86YmVuQG5pdmVuLWplbmtpbnMuY28udWsiPmJlbkBu aXZlbi1qZW5raW5zLmNvLnVrPC9hPjsgWmhvdVpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkNjOjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y2Ru aUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlN1YmplY3Q6IFJFOiBbQ0ROaV0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+QmVuLCBaaGlwZW5nLCBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgdGhpbmsg dGhhdCBDb250ZW50IEFkYXB0YXRpb24gaXMgbW9yZSBhbiBpc3N1ZSBmb3IgdGhlIFJlcXVpcmVt ZW50cyBkb2MgdGhhbiBmb3IgdGhlIFVzZSBjYXNlcyBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+VGhlIGtleSBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIHdhbnQgdGhlIENETkkgaW50ZXJmYWNl cyB0byBiZSBhYmxlIHRvIGNvcGUgd2l0aCBhIHNjZW5hcmlvIHdoZXJlIChzYXkpIEhEL1NEIGNv bnZlcnNpb24gaXMgZG9uZSBpbiB0aGUgZENETiAmYW1wOyB0byBzaWduYWwgYWJvdXQgdGhpcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+SSB0aGluayB0aGF0IGNvcGluZyB3aXRoIHRoaXMgc2NlbmFy aW8gaXMgYSBzZWNvbmQgb3JkZXIgcmVxdWlyZW1lbnQsIGllIHdlIHNob3VsZCBub3Qgd29ycnkg YWJvdXQgaXQgaW4gdGhlIGluaXRpYWwgc3RhbmRhcmRzLXRyYWNrIHdvcmsuIEkgZG9uJ3Qga25v dywgZGlkIHdlIGV2ZXIgZGVjaWRlDQogd2hldGhlciB0aGUgVXNlIGNhc2VzIGRvYyBpcyByZXN0 cmljdGVkIHRvICZxdW90O2luaXRpYWwmcXVvdDsgc2NlbmFyaW9zLCBvciB3aGV0aGVyIGl0J3Mg YWxsLWVuY29tcGFzc2luZywgaWUgY292ZXJpbmcgJnF1b3Q7ZnV0dXJlJnF1b3Q7IHNjZW5hcmlv cyBhcyB3ZWxsPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TY290dCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlJlYWRpbmcgc29t ZSBvZiB5b3VyIGV4YW1wbGVzLCB0aGV5IHNlZW0gdG8gYmUgdmFsaWQgZXZlbiBpZiBjb250ZW50 IGFkYXB0YXRpb24gKEhEL1NEKSBpcyBvdXQgb2Ygc2NvcGUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4tIGEgZENETiBtaWdo dCBmb3Igc29tZSByZWFzb24gYmUgdW53aWxsaW5nIHRvIGRpc3RyaWJ1dGUgSEQ/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4t IGEgQ1NQIG1pZ2h0IHdhbnQgdG8gbWFrZSBzdXJlIHRoZSBkQ0ROIGNhbiB1c2UgSExTIGVuY2Fw c3VsYXRpb24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5CdXQgdGhlc2Ugc29ydHMgb2YgZXhhbXBsZXMgc2VlbSB0byBiZSBz dGF0aWMgcG9saWN5IHRoaW5ncyAodG8gZG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPndpdGggdGhlIGNhcGFiaWxpdGllcyAm YW1wOyBwcmVmZXJlbmNlcyBvZiB0aGUgQ0ROcyAmYW1wOyBDU1ApLCByYXRoZXIgdGhhbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+bWV0YWRhdGEgYXNzb2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBwaWVjZSBvZiBjb250ZW50 LiBJbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPmRpc2N1c3Npb24gc28gZmFyLCBJIHRoaW5rIG5lZ290aWF0aW9uIGFi b3V0IHN0YXRpYyBwb2xpY3kgc3R1ZmYgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnJhdGhlciBvdXQgb2Ygc2NvcGUoPyk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+T24gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIGFuIGludGVy ZXN0aW5nIHF1ZXN0aW9uIGlzIHdoZXRoZXIgdHJ1c3QgaXMgdHJhbnNpdGl2ZS4gRG9uJ3QgdGhp bmsgaXQgbmVlZCBiZSAtIGp1c3QgYmVjYXVzZSBDU1AgdHJ1c3RzIHVDRE4sIGFuZCB1Q0ROIHRy dXN0cyBkQ0ROIGRvZXNuJ3QgbWVhbg0KIHRoYXQgdGhlIENTUCBhdXRvbWF0aWNhbGx5IHRydXN0 cyB0aGUgZENETi4gSG93ZXZlciwgaSBzdXNwZWN0IHRoaXMgY2FuIGdldCBhcmJpdHJhcmlseSBj b21wbGV4IC0gc28gb25lIHBvc3NpYmlsaXR5IGlzIHRvIHNheSB0aGF0IHdlIHdpbGwgb25seSBo YW5kbGUgY2FzZXMgd2hlcmUgdGhlIHRydXN0IGlzIHRyYW5zaXRpdmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPkJlc3Qgd2lzaGVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5waGlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+UGhpbGlwIEVhcmRsZXk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlJlc2VhcmNoIGFuZCBUZWNobm9sb2d5IFN0 cmF0ZWd5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoaXMgZW1haWwgY29udGFpbnMgQlQgaW5mb3Jt YXRpb24sIHdoaWNoIG1heSBiZSBwcml2aWxlZ2VkIG9yIGNvbmZpZGVudGlhbC4gSXQncyBtZWFu dCBvbmx5IGZvciB0aGUgaW5kaXZpZHVhbChzKSBvciBlbnRpdHkgbmFtZWQgYWJvdmUuIElmIHlv dSdyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwNCiBub3RlIHRoYXQgZGlzY2xvc2luZywg Y29weWluZywgZGlzdHJpYnV0aW5nIG9yIHVzaW5nIHRoaXMgaW5mb3JtYXRpb24gaXMgcHJvaGli aXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBsZXQg bWUga25vdyBpbW1lZGlhdGVseSBvbiB0aGUgZW1haWwgYWRkcmVzcyBhYm92ZS4gVGhhbmsgeW91 LiBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVjb3JkIHlvdXIgZW1haWxz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+QnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5SZWdpc3RlcmVk IG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKIFJlZ2lzdGVyZWQgaW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPkVuZ2xhbmQgbm86IDE4MDAwMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+RnJvbTo8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNkbmkt Ym91bmNlc0BpZXRmLm9yZyI+Y2RuaS1ib3VuY2VzQGlldGYub3JnPC9hPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5bbWFpbHRvOmNkbmktYm91bmNlc0Bp ZXRmLm9yZ10NCiBPbiBCZWhhbGY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk9mIEJlbiBOaXZlbi1KZW5raW5zPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5T ZW50OiAxMCBPY3RvYmVyIDIwMTEgMTI6MDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRvOiBaaG91WmhpcGVuZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U3ViamVj dDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4 dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Db2xsZWFndWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5J TU8gU2VjdGlvbiA1LjEuMyBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBVc2UgQ2FzZXMgZHJh ZnQuIENvbnRlbnQgQWRhcHRhdGlvbiAoaS5lLiB0YWtpbmcgaW4gYSBjb250ZW50IGl0ZW0gaW4g b25lIGZvcm1hdCBhbmQgdHJhbnNmb3JtaW5nIGl0IHRvIGFub3RoZXIgZm9ybWF0IG9yIHJlcHJl c2VudGF0aW9uKQ0KIGlzIG5vdCBhICZxdW90O2NvcmUmcXVvdDsgZnVuY3Rpb24gb2YgYSBDRE4g d2hpY2ggdHlwaWNhbGx5IGRlbGl2ZXJzIHRoZSBjb250ZW50IHRoYXQgaXMgcmVxdWVzdGVkIHdp dGhvdXQgZXhwbGljaXQga25vd2xlZGdlIG9mIHdoYXQgdGhhdCBjb250ZW50IGFjdHVhbGx5IGlz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5MZXQncyBub3QgZm9yZ2V0IHRoYXQgaW4gYnVpbGRpbmcg YW4gZW5kIHRvIGVuZCBjb250ZW50IHNlcnZpY2UgdGhlIENETiBpcyBvbmx5IG9uZSBjb21wb25l bnQgYW5kIGlzIHRoZSBjb21wb25lbnQgdGFza2VkIHdpdGggZXhlY3V0aW5nIHRoZSBkZWxpdmVy eSBvZiBhIHNwZWNpZmljIHJlcHJlc2VudGF0aW9uDQogKHZlcnNpb24vY29weS9mb3JtYXQgZXRj Likgb2YgdGhlIHNlbGVjdGVkIGNvbnRlbnQgbm90IHRoZSBjb21wb25lbnQgdGFza2VkIHdpdGgg ZGVjaWRpbmcgKG9yIGFwcGx5aW5nIHBvbGljeSkgb24gd2hpY2ggdmVyc2lvbi9jb3B5L3JlcHJl c2VudGF0aW9uIG9mIGNvbnRlbnQgc2hvdWxkIGJlIGRlbGl2ZXJlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+VGhlIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHZlcnNpb24vY29weS9yZXByZXNlbnRhdGlv biB0byBvZmZlciBhbmQgYWxsb3cgdG8gYmUgZGVsaXZlcmVkIHRvIGEgZ2l2ZW4gZGV2aWNlL3Vz ZXIgaXMgaW1wbGVtZW50ZWQgb3V0c2lkZSBvZiB0aGUgQ0ROIChlLmcuIGJ5IHRoZSAmcXVvdDtw b3J0YWwmcXVvdDsgd2hlcmUNCiB0aGUgdXNlciBmaXJzdCBtYWtlcyB0aGVpciBjb250ZW50IHNl bGVjdGlvbiBwcmlvciB0byB0aGUgQ0ROIGJlY29taW5nIGludm9sdmVkIGluIHRoZSBkZWxpdmVy eSBvZiB0aGUgc2VsZWN0ZWQgY29udGVudCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJlbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5PbiA4IE9jdCAyMDExLCBhdCAwODoyMCwgWmhvdVpoaXBlbmcgd3Jv dGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Rm9sbG93aW5nIFNjb3R0J3MgY29tbWVudHMgb24g c2VjdGlvbiA1LjEuMywgSSBmZWVsIFNjb3R0J3MgZGVzY3JpcHRpb24gb24gdGhlIHVzZSBjYXNl IG9mIEhEIGFuZCBTRCBpcyBub3QgZXhhY3RseSBjb3JyZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5JZiBvbmUgbW92aWUgaGFzIHR3byBmb3JtYXRzIG9mIEhEIGFuZCBTRCwgdGhlbiB3ZSBo YXZlIHR3byBjb250ZW50IHdpdGggZGlmZmVyZW50IGlkZW50aWZpZXIuIEluIERSTSBzY29wZSwg dGhlIGJhc2ljIHVuaXQgaXMgYSBjb250ZW50IGNvcHkuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IZXJlIHRoZSBmaXJzdCBidWxsZXQgJnF1 b3Q7YSBzdWJzZXQgb2YgZW5jb2RpbmdzIGRlbGl2ZXJhYmxlIHRvIHNwZWNpZmljIGRldmljZXMs JnF1b3Q7IGhhcyBsaXN0ZWQgdGhlIGNhc2Ugb2YgY29udGVudCBhZGFwdGF0aW9uLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5JbiBsYXN0IG1vbnRoLCBJIGhhdmUgY29udGFjdGVkIHRoZSBBdXRo b3JzIG9mIHRoaXMgZG9jdW1lbnQgYW5kIHRha2VuIHNvbWUgZW1haWwgZXhjaGFuZ2VzIHdpdGgg R3JhbnQgYW5kIFBoaWxpcCAoQlQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIGhhdmUgc2hv d24gQlQgd2l0aCBzb21lIGluZm9ybWF0aW9uIHRoYXQgSSBrbm93IGluIHRoaXMgY2FzZSBhbmQg YXJlYSB0byBleHBsYWluIHRoZSBjb250ZW50IGZsZXhpYmlsaXR5IGlzIGN1cnJlbnRseSBhIGJh c2ljIHJlcXVpcmVtZW50IGZvciBDRE4gc2VydmljZSBhbmQgcmVsYXRlZCBuZWdvdGlhdGlvbg0K IGlzIG5lZWRlZCBpbiB0aGUgQ0ROIGludGVyY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+TWVhbndoaWxlLCBJIHNob3VsZCBhbHNvIGludml0ZSB5b3UgaW4gdGhpcyBncm91cCBy YWlzaW5nIHlvdXIgY29tbWVudHMgb3IgcXVlc3Rpb25zIG9uIHRoaXMgY2FzZSBzaW5jZSBJIGhv cGUgbXkgdXNlIGNhc2UgbWF5IGJlIGluY29ycG9yYXRlZCBpbiB0aGUgdXNlIGNhc2UgZHJhZnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5J ZiB5b3UgaGF2ZSBhbnkgbW9yZSBxdWVzdGlvbiBvciBjb21tZW50cywgcGxzIHNoYXJlIGluIHRo aXMgdGhyZWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGFua3MuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+RnJvbTog U2NvdHQgV2Fpbm5lciBbbWFpbHRvOnN3YWlubmVyQGNpc2NvLmNvbV08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+U2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMTEgODowMiBBTTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8 L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNlY3Rpb24gMi4zIE5vbWFkaWMgVXNl cnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhpcyBkZXNjcmlwdGlvbiBmYWxscyB1bmRlciB0 aGUgY2F0ZWdvcnkgb2YgR2VvZ3JhcGhpYyBFeHRlbnNpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+eWV0IHRoZSB0aGlyZCBwYXJhZ3JhcGggc3RhdGVzIHRoZSBjYXNlIHdoZXJlIGEgZGlmZmVy ZW50IGRldmljZSBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij51c2VkIGluIHRoZSBzYW1lIENE TiBjb3ZlcmFnZSBhcmVhLiAmbmJzcDtUaGUgaW50ZW50IG9mIHRoaXMgdXNlIGNhc2U8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+bmVlZHMgdG8gYmUgY2xhcmlmaWVkLiAmbmJzcDtQZXJoYXBzIHRo ZSB1c2UgY2FzZSBpcyB0cnlpbmcgdG8gYWRkcmVzczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij50 aGUgc2NlbmFyaW8gd2hlcmUgYSBOb21hZGljIFVzZXItQSB3aXRoIGFuIGFncmVlbWVudCBhbGxv d2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5hY2Nlc3MgdG8gY29udGVudCBmcm9tIENTUC1B IHZpYSB1Q0ROIG1vdmVzIHRvIGEgZENETiBpbiBhIGRpZmZlcmVudDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5yZWdpb24uICZuYnNwO1RoZSBkQ0ROIGlzIGFsbG93ZWQgdG8gZGlzdHJpYnV0ZSB0 aGUgY29udGVudCBvZiBDU1AtQSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Vc2VyLUE7IGhv d2V2ZXIsIG5vdCBvdGhlciB1c2VycyBpbiB0aGUgcmVnaW9uIG9mIHRoZSBkQ0ROIGFyZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5hbGxvd2VkIHRvIHJldHJpZXZlIHRoZSBjb250ZW50IHVubGVz cyB0aGV5IHRvbyBoYXZlIHN1Y2ggYW4gYWdyZWVtZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U2VjdGlvbiA1LjEuMyBDb250ZW50IEVu Y29kaW5nIFJlc3RyaWN0aW9ucyBOZWVkIHRvIGNsYXJpZnkgaWYgd2UncmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+dGFsa2luZyBhYm91dCB0aGUgcmVzdHJpY3Rpb25zIG9uIHRoZSBkZWxpdmVy eSBvZiBzcGVjaWZpYyBjb250ZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPm9yIHRoZSByZXN0 cmljdGlvbnMgb24gdGhlIGFiaWxpdHkgb2YgYSBDRE4gdG8gZGVsaXZlciBzcGVjaWZpYzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5jb250ZW50LiAmbmJzcDtJIGNlcnRhaW5seSB1bmRlcnN0YW5k IHRoZSBjYXNlIHdoZXJlIGEgQ1NQIHdpbGwgcmVzdHJpY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+dGhlIGRpc3RyaWJ1dGlvbiBvZiBjb250ZW50IHRvIGEgJnF1b3Q7bWFuYWdlZCBwYXRoJnF1 b3Q7IGlmIHN1Y2ggY29udGVudCBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IRCB3aGlsZSBh bGxvd2luZyB0aGUgY29udGVudCBkaXN0cmlidXRpb24gdmlhIGFuIHVuLW1hbmFnZWQgcGF0aCBp ZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5zdWNoIGNvbnRlbnQgaXMgU0QgKHNhbWUgY291bGQg YXBwbHkgdG8gZW5jcnlwdGlvbiBtZXRob2RzLCBkZWxpdmVyeTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5tZXRob2RzLCBldGMuKS4gJm5ic3A7T24gdGhlIGNvbnRyYXJ5LCB0aGUgZENETiBtYXkg aGF2ZSBpdHMgb3duPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnJlc3RyaWN0aW9ucyBvZiBibG9j a2luZyB0aGUgZGlzdHJpYnV0aW9uIG9mIEhEIGNvbnRlbnQgd2hpbGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+YWxsb3dpbmcgdGhlIGRpc3RyaWJ1dGlvbiBvZiBTRCBjb250ZW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+byBmaXJzdCBi dWxsZXQgbWFrZXMgc2Vuc2UgaWYgdGhlIGRDRE4gY2FuIHBlcmZvcm0gYSBzdWJzZXQgb2Y8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+ZW5jYXBzdWxhdGlvbnMgZm9yIGEgcmVmZXJlbmNlIHNldCBv ZiBtZWRpYSAoZS5nLiBITFMsIEhTUywgYnV0IG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5E QVNIKSBvIHNlY29uZCBidWxsZXQgbWFrZXMgc2Vuc2Ugd2hlcmUgdGhlIGRDRE4gZG9lc24ndCB3 YW50IHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPm9mZmVyIGhpZ2ggYml0LXJhdGUgdmFyaWFu dHMgb2YgdGhlIG1lZGlhIG8gdGhpcmQgYnVsbGV0IG1ha2Ugc2Vuc2U8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+aWYgdGhlIHBvbGljeSBhZGRyZXNzZXMgUW9FIGJ1dCBJIGRvbid0IHRoaW5rIHN1 YnNjcmliZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+cmlnaHRzL2F1dGhvcml6YXRpb25zIGFw cGx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+U2VjdGlvbiAxMCBTZWN1cml0eSBDb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QXNpZGUgZnJvbSB0aGUgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgV0lUSElOIHRoZSB1Q0ROIGFuZCBkQ0ROLCBJPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPnRoaW5rIHdlIGNhbiBkZXNjcmliZSB0aGlzIGluIGZvdXIgY29udGV4dHM6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5h LiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIENTUCBhbmQgdGhlIHVDRE4gKHRoZSBwcmlu Y2lwbGUgY29udHJhY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+YXJyYW5nZW1lbnQgZm9yIGRp c3RyaWJ1dGlvbik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Yi4gVGhlIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIHRoZSB1Q0ROIGFuZCBkQ0ROICh0aGUgdHJhbnNpdGl2ZSB0cnVzdDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5yZWxhdGlvbnNoaXAgdGhhdCBleHRlbmRzIHRoZSBjb250cmFjdCBkZWZp bmVkIGluIChhKSBhYm92ZSkgYy4gVGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnJlbGF0aW9u c2hpcCBiZXR3ZWVuIHRoZSBVc2VyIGFuZCBkQ0ROICh0aGUgcmVjb2duaXRpb24gb2YgcmlnaHQg dG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ZG93bmxvYWQgcHJlZGljYXRlZCBvbiAoYikgYWJv dmUpIGQuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+VXNlciBhbmQgQ1NQICh0aGUgY29udHJhY3QgYXV0aG9yaXppbmcgdGhlIHVzZXIgYWNjZXNz IHRvIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5jb250ZW50KTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhlIHVzZXIgaXMgbm90IGlu dGVyZXN0ZWQgaW4gdGhlIGEtYiBub3IgdGhlIGItYyByZWxhdGlvbnNoaXAuIFRoZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij51c2VyIGlzIG9ubHkgaW50ZXJlc3RlZCBpbiB0aGUgdHJhbnNwYXJl bmN5IGFuZCBpbnRlcm9wZXJhYmlsaXR5IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnRoZSBz ZWN1cml0eSByZWxhdGlvbnNoaXAgYmV0d2VlbiBkLWIgb3IgZC1jIHRvIHRoZSBwb2ludCB0aGF0 IHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5hdXRob3JpemF0aW9uIGdyYW50ZWQgaW4gZC1h IGlzIHZpYWJsZSB3aGVuIHRoZSBkZWxpdmVyeSBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5p bml0aWF0ZWQgdmlhIGVpdGhlciBkLWIgb3IgZC1jLiAmbmJzcDtBcyBhbiBleGFtcGxlLCB0aGUg dUNETiBtaWdodCB1c2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VVJMIGFwcGVuZGVkIHRva2Vu cyBmb3IgYXV0aGVudGljYXRpb24gd2hpbGUgZENETiBtaWdodCB1c2UgVVJMPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPmFwcGVuZGVkIGhhc2hlcy4gJm5ic3A7VGhlIHVzZXIgZG9lc24ndCB3YW50 IHRvIGtub3cgYWJvdXQgdGhlIGRpc3RpbmN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPm1ldGhv ZHMsIGJ1dCB0cmFuc3BhcmVuY3kgaXMgb25seSBhZmZvcmRlZCBpZiB0aGUgbWV0aG9kcyBhcmU8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+aW50ZXJvcGVyYWJsZSBjbGVhcmx5IGRlZmluZWQgd2hl biB0aGUgZGVsZWdhdGlvbiBmb3IgY29udGVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5kZWxp dmVyeSBpcyBleGVjdXRlZC4gJm5ic3A7Q2xlYXJseSwgdGhlIGNob2ljZSBvZiBhdXRoZW50aWNh dGlvbiBtZXRob2QgaXMgZGV0ZXJtaW5lZCBieSB0aGUgcmVzcGVjdGl2ZSBDRE4ncy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNjb3R0PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5DRE5pIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YSBo cmVmPSJtYWlsdG86Q0ROaUBpZXRmLm9yZyI+Q0ROaUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jZG5pIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5DRE5pIG1haWxpbmcgbGlzdDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PGEgaHJlZj0ibWFpbHRvOkNETmlAaWV0Zi5vcmciPkNETmlAaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KQ0ROaSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q0ROaUBpZXRm Lm9yZyI+Q0ROaUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2RuaTwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCkNETmkgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNE TmlAaWV0Zi5vcmciPkNETmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Nkbmk8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDRE5p IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDRE5pQGlldGYub3JnIj5DRE5pQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pPC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --Boundary_(ID_Zh3zl81PPMd5qfCfpzFruA)-- From ray.vanbrandenburg@tno.nl Mon Oct 31 02:23:23 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9102A21F8D55 for ; Mon, 31 Oct 2011 02:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oOBXe1BunzH for ; Mon, 31 Oct 2011 02:23:23 -0700 (PDT) Received: from mailouta.tno.nl (mailouta.tno.nl [134.221.1.16]) by ietfa.amsl.com (Postfix) with ESMTP id 683C221F8D53 for ; Mon, 31 Oct 2011 02:23:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.69,429,1315173600"; d="scan'208,217";a="59641477" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1a.tno.nl with ESMTP; 31 Oct 2011 10:23:18 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.246]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.01.0323.003; Mon, 31 Oct 2011 10:23:18 +0100 From: "Brandenburg, R. (Ray) van" To: ZhouZhipeng , Francois Le Faucheur Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AQHMf6O2VExcRrnYVk25qolmOBlG5JWWIlhggAAKpqCAAC/foA== Date: Mon, 31 Oct 2011 09:23:17 +0000 Message-ID: References: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> <144D124A-E8A2-48DC-A98D-6F33B2EB1B90@cisco.com> <260A32EFD5C9EB47AD504929D005DF6217F6D1F9@SZXEML519-MBX.china.huawei.com> In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6217F6D1F9@SZXEML519-MBX.china.huawei.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581558B761EXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:23:23 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581558B761EXCMBX03tsntnon_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWmhpcGVuZywNCg0KVG8gYmUgY2xlYXIgaGVyZSwgSSBoYXZlIG5vdCBnaXZlbiBteSBzdXBw b3J0IHRvIHRoZSBDb250ZW50IEFkYXB0YXRpb24gdXNlIGNhc2UgKG5vciBoYXZlIEkgdm9pY2Vk IG15IG9wcG9zaXRpb24gYWdhaW5zdCBpdCkuDQoNClRoZSBjb252ZXJzYXRpb24gSSBoYWQgd2l0 aCBCZW4gaGFkIHRvIGRvIHdpdGggdGhlIGNvbmNlcHQgb2YgR3JvdXBlZCBGaWxlIERlbGVnYXRp b24gYW5kIGhvdyBkaWZmZXJlbnQgcXVhbGl0eSBsZXZlbHMsIGVuY29kZWQgYnkgdGhlIENvbnRl bnQgUHJvdmlkZXIsIGFyZSBoYW5kbGVkIGluIGEgQ0ROIGludGVyY29ubmVjdGlvbiBzY2VuYXJp by4NCg0KUmF5DQoNCkZyb206IGNkbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFpob3VaaGlwZW5nDQpTZW50OiBtYWFuZGFnIDMx IG9rdG9iZXIgMjAxMSAxMDowNA0KVG86IEZyYW5jb2lzIExlIEZhdWNoZXVyDQpDYzogY2RuaUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmkt dXNlLWNhc2VzLTAwLnR4dA0KDQpTb3JyeSwgbm90IEtQTi4gSXQgaXMgUmF5IGZyb20gVE5PLg0K WmhpcGVuZw0KDQoNCkZyb206IFpob3VaaGlwZW5nDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMzEs IDIwMTEgNDo0OSBQTQ0KVG86ICdGcmFuY29pcyBMZSBGYXVjaGV1cicNCkNjOiBjZG5pQGlldGYu b3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtDRE5pXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQpEZWFyIEZyYW5jb2lzLCBhbmQg YWxsLA0KVGhhbmtzIGZvciBhbGwgdGhlIGdyb3Vw4oCZcyBhdHRlbnRpb24gb24gdGhpcyB0b3Bp Yy4NCkkgYW0gYWxzbyBoYXBweSB0aGF0IG15IHByb3Bvc2FsIGhhcyBnb3R0ZW4gc28gbXVjaCB2 YWx1YWJsZSByZXNwb25zZS9xdWVzdGlvbnMvIGNvbW1lbnRzLg0KVGhhdCB3aWxsIGJlIHZlcnkg aGVscGZ1bCBmb3IgYWxsIG9mIHVzIHRvIGNhdGNoIGEgY29tcGxldGUgdW5kZXJzdGFuZGluZyBh bmQgc29sdXRpb24gZm9yIHRoaXMgbWFya2V0IGRlbWFuZC4NCldoaWxlIEkgZmVlbCB0aWxsIG5v dyB0aGUgdG9waWMgaXRzZWxmIGhhcyBub3QgYmVlbiBjb21wbGV0ZWx5IGFuYWx5emVkIGFuZCBJ IGFtIGJ1c3kgZG9pbmcgdGhlIHdvcmsuIEkgd2lsbCBleHBvc2UgbXkgY29udHJpYnV0aW9uIHNv b24gYWZ0ZXIgSSBjb21wbGV0ZSB0aGF0IHdvcmsuDQpNZWFud2hpbGUgSSBob3BlIHRoZSBncm91 cCBtYXkgYWxsb3cgc29tZSBtb3JlIHRpbWUgZm9yIHBlb3BsZSB0byBjb25zaWRlciBpdC4gUGVy aGFwcyBzb21lIG1vcmUgcGVvcGxlIHdpbGwgZW1lcmdlIGluIHRoZSBncm91cCBtYWlsIGxpc3Qu DQpDdXJyZW50bHksIHNvbWUgcGVvcGxlIGhhcyBjbGFpbWVkIHRoZWlyIHByZWZlcmVuY2UuICBJ IGZlZWwgcGVyaGFwcyBub3QgYSBmZXcgcGVvcGxlIGhhdmUgc3VwcG9ydGVkIHRoaXMgdXNlIGNh c2UodGhlIGF1dGhvcnMgb2YgZHJhZnQtZm1uLWNkbmktYWR2YW5jZWQtdXNlLWNhc2VzLTAwLCBB bGFuIGZyb20gRXJpY3Nzb24sIENoaW5hTW9iaWxlLCBDaGluYXRlbGVjb20sICBwZXJoYXBzIGFs c28gS1BOLCBhbmQgbWUpLg0KDQpJIGhhdmUgZXhwbGFpbmVkIHRoYXQgZm9yIENETi1BIGFuZCBD RE4tQiwgdGhleSBtYXkgbmVnb3RpYXRlIHdoZXRoZXIgdG8gc3VwcG9ydCB0aGUgQ0ROSSBhZGFw dGF0aW9uIHNvbHV0aW9uLiBIZW5jZSBzdWNoIG9wdGlvbmFsIGFycmFuZ2VtZW50IHdpbGwgb25s eSBicmluZyBiZW5lZml0IHdoZW4gYm90aCB1cHN0cmVhbSBhbmQgZG93bnN0cmVhbSBhZ3JlZXMg dGhhdCBhdCB0aGVpciBhcHByb3ByaWF0ZSBzaXR1YXRpb24uDQoNClNvLCBJIHNpbmNlcmVseSBz dWdnZXN0IHR3byBDaGFpcnMgYW5kIHRoZSB3aG9sZSBncm91cCBtYXkgYWxsb3cgc29tZSBtb3Jl IGRheXMgZm9yIHRoaXMgdG9waWMuICAgSSBzdWdnZXN0IGFmdGVyIHRoZSBUYWlwZWkgbWVldGlu ZyAuDQpCeSB0aGVuIHdlIGFsbCB3aWxsIGdldCBhIGNsZWFyZXIgdW5kZXJzdGFuZGluZyBhbmQg ZGVjaXNpb24uDQoNClRoYW5rcy4NClpoaXBlbmcNCg0KDQoNCkZyb206IEZyYW5jb2lzIExlIEZh dWNoZXVyIFttYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tXTxtYWlsdG86W21haWx0bzpmbGVmYXVj aEBjaXNjby5jb21dPg0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDI4LCAyMDExIDk6NTAgUE0NClRv OiBaaG91WmhpcGVuZw0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMt MDAudHh0DQoNCkhpIGFnYWluIFpoaXBlbmcsDQoNClRoZXJlIGlzIG9uZSBvdGhlciBwb2ludCBJ IHNob3VsZCBoYXZlIGJyb3VnaHQgdXAgaW4gbXkgcHJldmlvdXMgbWVzc2FnZToNClRoZSBxdWVz dGlvbiBpcyBub3Qgc28gbXVjaCB3aGV0aGVyIHRoZXJlIGFyZSBiZW5lZml0cyB0byBhbGxvd2lu ZyBjb250ZW50IGFkYXB0YXRpb24gZm9yIHNvbWUgZW52aXJvbm1lbnRzLCBub3Igd2hldGhlciBv bmUgcGFydGljdWxhciBpbmRpdmlkdWFsIGNvdWxkIGNvbmNlaXZlIGFuIGFwcHJvYWNoIGZvciBj b250ZW50IGFkYXB0YXRpb24gdGhhdCBzdWl0cyBoaW0uIFRoZSBxdWVzdGlvbiBoZXJlIGlzIHJh dGhlciB3aGV0aGVyIGl0IGlzIGp1c3RpZmllZCBmb3IgdGhlIFdvcmtpbmcgR3JvdXAgdG8gZm9j dXMgZW5lcmd5IG9uIHRoYXQgcHJvYmxlbSByaWdodCBub3cgaW4gb3JkZXIgdG8gZGV2ZWxvcCBh IGNvbnNlbnN1cy1iYXNlZCBhcHByb2FjaCB0aGF0IHN1aXRzIHRoZSBjb21tdW5pdHkgYXMgYSB3 aG9sZSwgd2hpbGUgd2UgZG9uJ3QgZXZlbiBoYXZlIHRoZSBiYXNlIHNvbHV0aW9uIGluIHBsYWNl Lg0KDQpZb3UgaGF2ZSBtYWRlIGl0IGNsZWFyIHRoYXQgeW91IGZlZWwgdGhlIFdHIHNob3VsZCBp bmRlZWQgZGVkaWNhdGUgZW5lcmd5IG9uIHRoYXQgcHJvYmxlbSByaWdodCBhd2F5IGFuZCBleHBs YWluZWQgeW91ciByYXRpb25hbGUuIFRoYW5rIHlvdS4gT3RoZXJzIGhhdmUgYWxzbyBleHByZXNz ZWQgdGhlaXIgb3BpbmlvbnMuDQoNCkNoZWVycw0KDQpGcmFuY29pcw0KDQoNCk9uIDI4IE9jdCAy MDExLCBhdCAxMToyNSwgWmhvdVpoaXBlbmcgd3JvdGU6DQoNCkRlYXIgYWxsLA0KSW4gdGhlc2Ug ZGF5cyBJIGFtIGJ1c3kgbWFraW5nIGEgc3VtbWFyeSBhbmFseXNpcyBvbiB0aGlzIHRvcGljLiBB cyBSaWNoYXJk4oCZcyByZXF1ZXN0LCBJIGxpa2UgdG8gc2hvdyBteSBpbmZvcm1hdGlvbiBhbHRo b3VnaCBwZXJoYXBzIG5vdCBjb21wbGV0ZSByaWdodCBub3cuDQoNCjEpICAgICBJIGhhdmUgZG9u ZSBzb21lIHdvcmsgdG8gY29sbGVjdCBkaWZmZXJlbnQgY29tcGFueeKAmXMgcmVxdWlyZW1lbnRz IGFuZCBvcGluaW9ucyBvbiB0aGlzIGZ1bmN0aW9uYWxpdHkuDQpPbmUsIEkgZmVlbCBtb3N0IG9m IHVzIGhhdmUgYWxyZWFkeSBiZWVuIGF3YXJlIG9mIHRoZSBzZXJ2aWNlIG9mIGNvbnRlbnQgYWRh cHRhdGlvbiwgYW5kIEkgYWxzbyBzZW50IGFuIGVtYWlsIHllc3RlcmRheSB0aGF0IFZvZGFwaG9u ZSBub3cgaXMgcmVxdWlyaW5nIHRoZSBzb2x1dGlvbiB0byBlbmhhbmNlIHRoZSBwZXJmb3JtYW5j ZSBvZiBpdHMgbW9iaWxlIHZpZGVvIHNlcnZpY2UuDQpTZWNvbmQsIGhlcmUgaXMgYW4gYXJ0aWNs ZSBhYm91dCBDSVNDTyA6IOKAnENpc2NvIHVyZ2VzIG1vYmlsZSBvcGVyYXRvcnMgdG8gYWRkIHZh bHVlIHRvIENETiBzZXJ2aWNlc+KAnSBodHRwOi8vd3d3LnRvdGFsdGVsZS5jb20vdmlldy5hc3B4 P0lEPTQ2ODcwNQ0KQmVzaWRlcywgSSBoYXZlIGNoZWNrZWQgbWFueSBDRE4gY29tcGFueeKAmXMg d2Vic2l0ZXMuIE1hbnkgY2xhaW0gdG8gc3VwcG9ydCB0cmFuc2NvZGluZyB3aGlsZSBzb21lIG1h eSBub3QuDQoNCjIpICAgICBGb3IgdGhlIHdvcmRpbmcg4oCcY29udGVudCBhZGFwdGF0aW9u4oCd LCBpdCBzaG91bGQgYmUgY2xhcmlmaWVkIGhlcmUgdGhhdCBpdCBtYXkgYmUgdHdvIGtpbmRzLg0K T25lIGlzIG9ubHkgdGhlIHRyYW5zZm9ybWF0aW9uIG9mIGVuY2Fwc3VsYXRpb24gZm9ybWF0LiBG b3IgZXhhbXBsZSB0aGUgSC4yNjQgc3RyZWFtIGlzIGVuY2Fwc3VsYXRlZCBpbiBBUFBMRSBhbmQg QWRvYmUgZm9ybWF0IHJlc3BlY3RpdmVseS4NCkkga25vdyB0aGF0IENvbWNhc3QgaGFzIGEgcHJv amVjdCB0aGF0IG5lZWRzIHRvIHBpY2sgdGhlIEguMjY0IG1lZGlhIGZyb20gdGhlIFRTIHN0cmVh bSBhbmQgdGhlbiBlbmNhcHN1bGF0ZWQgdGhlbSBpbnRvIGRpZmZlcmVudCBmb3JtYXRzKEFQUExF LEFkb2Jl4oCmKSB0byBkaWZmZXJlbnQgZGV2aWNlcy4NCkZvciB0aGlzIGtpbmQgb2YgdHJhbnNm b3JtYXRpb24sIHRoZSBjb21wdXRpbmcgY29zdCBpcyB2ZXJ5IHZlcnkgbG93IGFuZCBtYXkgYmUg bmVhcmx5IG5lZ2xlY3RlZC4NClRoZSBvdGhlciBpcyB0byB0cmFuc2NvZGluZy4gIEZvciBleGFt cGxlIHRvIHN1cHBvcnQgZGlmZmVyZW50IGJpdHJhdGVzLiAgU2luY2UgZW5jb2RlciBpcyBhIGhp Z2ggdmFsdWUgZmFjaWxpdHksIHdlIHNob3VsZCBjb21wYXJlIHRoZSBjYXBpdGFsIGNvc3Qgb2Yg ZW5jb2RlciBhbmQgdHJhbnNwb3J0IGNvc3QuDQpKdXN0IHRha2UgYSBzaW1wbGUgbW9kZWw6IGNv bnRlbnQgaXMgZGVsaXZlcmVkIGZyb20gTm9kZSBBIHRvIE5vZGUgQi4NCjxpbWFnZTAwMi5wbmc+ DQpUaGVyZSBhcmUgdHdvIHNvbHV0aW9uczoNCjEpICAgICBBIGhhdmUgdGhlIHRyYW5zY29kZXIg YW5kIGRlbGl2ZXIgbXVsdGktZm9ybWF0IGNvbnRlbnQgdG8gQg0KMikgICAgIEIgaGF2ZSB0aGUg dHJhbnNjb2RlcjsgQSBvbmx5IGRlbGl2ZXJzIG9uZSBmb3JtYXQgY29udGVudCB0byBCIGFuZCBC IHdvdWxkIHRyYW5zY29kZS4NCkZyb20gd2hvbGUgc3lzdGVtIHBvaW50IG9mIHZpZXcsIGVpdGhl ciBBIG9yIEIgd291bGQgdHJhbnNjb2RlIHdoaWxlIHRoZSBiYW5kd2lkdGggd291bGQgYmUgc2F2 ZWQgaW4gc29sdXRpb24gQi4gSGVuY2Ugc29sdXRpb24gQiBpcyBiZXR0ZXIuDQpOb3cgcHJvdmlk ZWQgdGhlIGJhbmR3aWR0aCBpcyBwYWlkIGJ5IEIgYW5kIEIgc2hvdWxkIGRlY2lkZSB3aGV0aGVy IHRvIGluc3RhbGwgdHJhbnNjb2Rlci4NCihSaWNoYXJkIGhhcyBzYWlkIHRvIHNldCB0cmFuc2Nv ZGVyIGluIGVhY2ggZWRnZSBzZXJ2ZXIpDQpJZiB0aGUgY29zdCBvZiByZW50aW5nIGJhbmR3aWR0 aCAoZm9yIGEgZmV3IG1vbnRocykgaXMgbW9yZSBleHBlbnNpdmUgdGhhbiB0aGUgcHJpY2Ugb2Yg dHJhbnNjb2RlciBzdXBwb3J0aW5nIHRoZSBzYW1lIGJhbmR3aWR0aCwgaXQgd291bGQgYmUgYmV0 dGVyIHRvIHB1dCB0aGUgdHJhbnNjb2RlciBhdCB0aGUgcmVjZWl2ZXIgTm9kZSBCLg0KSW4gZmFj dCBJIGhhdmUgaW52ZXN0aWdhdGVkIHRoaXMgaXNzdWUgZm9yIG11Y2ggdGltZS4gV2hpbGUgaW4g ZGlmZmVyZW50IGFyZWEgdGhlIHByaWNlIG9mIGJhbmR3aWR0aCBtYXkgYmUgZGlmZmVyZW50LiAg QW5kIHRoZSB0cmFuc3BvcnQgYnVyZGVuIGJldHdlZW4gdHdvIGRpc3RhbnQgcGxhY2VzIG9yIG92 ZXIgYSBiYWQgbmF0dXJlIGVudmlyb25tZW50IHdvdWxkIGJlIG11Y2ggaGlnaGVyLg0KSGVyZSB0 aGUgcHJpY2UgaW4gVVNBIG1heSBiZSByZWZlcnJlZCBhczogaHR0cDovL3NtYWxsYnVzaW5lc3Mu dmVyaXpvbi5jb20vcHJvZHVjdHMvaW50ZXJuZXQvaHNpL292ZXJ2aWV3LmFzcHgjcGxhbnMuDQpJ biBWZXJpem9uLCB0aGUgcGFja2FnZSBmb3IgMTAtMTVtYnBzIGlzICQ5MCBwZXIgbW9udGggKEkg ZmVlbCB0aGUgYmFuZHdpZHRoIHF1YWxpdHkgZm9yIGJ1c2luZXNzIHdvdWxkIGJlIGd1YXJhbnRl ZWQpLiBJIHF1ZXJ5IHRoYXQgdGhlIGJhbmR3aWR0aCBwcmljZSBpbiBDaGluYSBtYXkgYmUgNTAl IGhpZ2hlci4NCkkgZG8gbm90IGtub3cgaG93IG11Y2ggdGhlIHByaWNlIHdpbGwgYmUgZm9yIHRo ZSBiYW5kd2lkdGggZnJvbSBBbXN0ZXJkYW0gdG8gUGFyaXMgKGNyb3NzIGNvdW50cnkgaW4gdGhl IHNhbWUgY29udGluZW50KS4gIEJ1dCBJIGZlZWwgdGhlIHByaWNlIGZyb20gTmV3WW9yayB0byBQ YXJpcyB3b3VsZCBhYnNvbHV0ZWx5IGJlIHZlcnkgaGlnaC4gIEFzIGZvciB0aGUgRW5jb2Rlciwg aXQgYWxzbyB2YXJpZXMuIFBlcmhhcHMgdGhlIHByaWNlIGluIENoaW5hIHdpbGwgYmUgaGlnaGVy IHRoYW4gaW4gVVNBLiBBbmQgaW4gZmFjdCB0aGUgcHJpY2Ugb2YgYmFuZHdpZHRoIGFuZCBlbmNv ZGVyIGRlcGVuZHMgbW9zdGx5IG9uIHRoZSBjb25jcmV0ZSBidXNpbmVzcyBpdGVtcy4gRm9yIGV4 YW1wbGUgdGhlIHByaWNlIHRvIEh1YXdlaSBtYXkgYmUgbG93ZXIgdGhhbiB0aGUgcHVibGljIHBy aWNlLg0KQnkgbXkgY3VycmVudCBldmFsdWF0aW9uIGluIENoaW5hIGl0IGlzIGJldHRlciB1c2lu ZyB0aGUgdHJhbnNjb2RlciB0aGFuIHJlbnRpbmcgbXVsdGlwbGUgdGltZXMgYnJvYWRiYW5kLg0K U29tZSBwZW9wbGUgaGF2ZSB0b2xkIG1lIHRoYXQgZm9yIHRoZSBvcGVyYXRvciBoaW1zZWxmIHBy b2JhYmx5IHRoZSBiYW5kd2lkdGggY29zdCB3b3VsZCBiZSB2ZXJ5IGxvdyBpbiB0aGUgaW50ZXJu YWwgY2FwaXRhbCBjb3VudGluZy4gQnV0IGZvciB0aGUgaW5kZXBlbmRlbnQgQ0ROLCBpdCBtYXkg YW5vdGhlciB0aGluZy4NClNvLCBteSBzdWdnZXN0aW9uIGlzIHRvIGxldCBkaWZmZXJlbnQgd2F5 cyBjby1leGlzdC4gSSBoYXZlIGFubm91bmNlZCB0aGF0IHRvIGxldCB0d28gc2lkZXMgbmVnb3Rp YXRlIHdoZXRoZXIgdG8gYXNzaWduIGRDRE4gZm9yIHRoZSBjb250ZW50IGFkYXB0YXRpb24uDQoN CkluIGZhY3QsIGZyb20gQ1AgdG8gQ0ROLCAgdGhlcmUgYXJlIHRoZSByZWFsIGJ1c2luZXNzZXMg dGhhdCBlaXRoZXIgbGV0IENQIHRvIHByb3ZpZGUgbXVsdGktZm9ybWF0IGNvbnRlbnQgb3IgbGV0 IHRoZSBDRE4gdG8gcmVjZWl2ZSBvbmUgZm9ybWF0IGFuZCBjb21wbGV0ZSB0aGUgdHJhbnNmb3Jt YXRpb24sIGRlcGVuZGluZyBvbiB0aGUgY29uY3JldGUgYnVzaW5lc3MuDQpCeSB0aGUgc2FtZSBs b2dpYywgZm9ybSB1Q0ROIHRvIGRDRE4sIGl0IG1heSBiZSBlaXRoZXIgdGhlIHVDRE4gdG8gcHJv dmlkZSBtdWx0aS1mb3JtYXQgY29udGVudCBvciB0aGUgZENETiB0byByZWNlaXZlIG9uZSBmb3Jt YXQgY29udGVudCBhbmQgdGhlbiBjb21wbGV0ZSB0aGUgdHJhbnNmb3JtYXRpb24uDQpDdXJyZW50 bHkgdGhlcmUgaXMgbm90IHRoZSByZWFsIENETi1DRE4gY29ubmVjdGlvbiwgaGVuY2Ugd2UgYXJl IGJhc2luZyBvdXIga25vd2xlZGdlIG9uIHRoZSByZWxhdGVkIHNvbHV0aW9uIHRvIG1ha2Ugb3Vy IHNvbHV0aW9ucy4NCg0KMykgICAgIEFzIGZvciB0aGUgcHJvY2VkdXJlIG9mIGNvbnRlbnQgYWRh cHRhdGlvbiwgSSBqdXN0IGRyYWZ0IGEgZGlhZ3JhbSBhcyBiZWxvdzoNCjxpbWFnZTAwNC5wbmc+ DQoNCllvdSBtYXkgc2VlIHRoZSBzb2x1dGlvbiBpcyByYXRoZXIgY2xlYXIgYW5kIHRoZSBtZXRh ZGF0YSBuZWVkZWQgd291bGQgYmUgY2xlYXIgYWxzby4NCg0KRGVhciwNCkJ5IG15IGFuYWx5c2lz IGFib3ZlLCBJIGtpbmRseSBpbnZpdGUgeW91ciBpZGVhcyB3aGV0aGVyIGl0IG1heSBiZSBhbiBh cHBsaWNhYmxlIGFuZCBzaW1wbGUgcGFydCBpbiB0aGUgQ0ROSSBpdGVtLCBwcm92aWRlZCB0aGF0 IHRoZSBzb2x1dGlvbiBpcyBvcGVuIHRvIHRoZSB0eXBlcyBvZiBjb250ZW50IGFkYXB0YXRpb24g YW5kIG1heSBiZSBvcHRpb25hbGx5IGltcGxlbWVudGVkIGluIHRoZSByZWFsIHNvbHV0aW9ucy9i dXNpbmVzcy4gSSBmZWVsIGZvciB0aG9zZSBvcGVyYXRvcnMgdGhhdCBuZWVkIHN1Y2ggZnVuY3Rp b25hbGl0eSBpdCB3b3VsZCBiZSB2ZXJ5IGdvb2Qgd2hpbGUgaXQgZG9lcyBub3QgaW1wYWN0IG90 aGVycyB0aGF0IGRvIG5vdCBpbXBsZW1lbnQgaXQuDQpUaGFua3MuDQpaaGlwZW5nDQoNCg0KRnJv bTogV291bmR5LCBSaWNoYXJkIFttYWlsdG86UmljaGFyZF9Xb3VuZHlAY2FibGUuY29tY2FzdC5j b21dPG1haWx0bzpbbWFpbHRvOlJpY2hhcmRfV291bmR5QGNhYmxlLmNvbWNhc3QuY29tXT4NClNl bnQ6IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDExIDc6MjMgUE0NClRvOiBaaG91WmhpcGVuZzsg J21hcmtAamV0LXN0cmVhbS5ubDxtYWlsdG86J21hcmtAamV0LXN0cmVhbS5ubD4nOyAnYWxhbi5r YXZhbmFnaEBlcmljc3Nvbi5jb208bWFpbHRvOidhbGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbT4n DQpDYzogJ2NkbmlAaWV0Zi5vcmc8bWFpbHRvOidjZG5pQGlldGYub3JnPic7IFdvdW5keSwgUmlj aGFyZA0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNl LWNhc2VzLTAwLnR4dA0KDQo+SW4geW91ciBjb21wYW554oCZcyB3ZWJzaXRlLCBJIGp1c3QgZmlu ZCBzb21lIGluZm9ybWF0aW9uDQoNCkkgaGF2ZSB0byBzdGVwIGluIGFzIGNvLWNoYWlyIGhlcmUu DQoNClRoZSBnb2FsIG9mIHRoaXMgV0cgaXMgbm90IHRvIGFsaWduIHZlbmRvciBwcm9kdWN0IHJv YWRtYXBzLCBvciB0byBlcXVhbGl6ZSBhbGwgdmVuZG9yIG9mZmVyaW5ncywgb3IgdG8gc3BlY2lm eSB0aGUgZW50aXJlIENETkkgZWNvc3lzdGVtLiBUaGUgZ29hbCBvZiB0aGlzIFdHIGlzIHRvIGVu YWJsZSB0aGUgaW50ZXJjb25uZWN0aW9uIGFuZCBpbnRlcm9wZXJhdGlvbiBvZiB0d28gb3IgbW9y ZSBDRE5zLCB3aXRoaW4gdGhlIGJvdW5kcyBvZiB0aGUgQ0ROSSB3ZyBjaGFydGVyLg0KDQpJdCBp cyBPSyB0byBoYXZlIGEgZGlzY3Vzc2lvbiBhYm91dCB3aGV0aGVyIGNvbnRlbnQgYWRhcHRhdGlv biBuZWVkcyB0byBiZSBwZXJmb3JtZWQgYnkgdGhlIGRDRE4sIHNpbmNlIHRoYXQgZGVjaXNpb24g aW1wYWN0cyB0aGUgdUNETi1kQ0ROIGludGVyZmFjZS4gU28gbGV0J3MgZmluZCBhIHByb2R1Y3Rp dmUgd2F5IHRvIGRpc2N1c3MgdGhpcyBvbiB0aGUgbWFpbGluZyBsaXN0LCBhbmQgdG8gY2xvc2Ug dGhlIGRpc2N1c3Npb24gYnkgSUVURiA4MiAoaWYgbm90IHNvb25lcikuDQoNCkNhbiBzb21lb25l IGRlc2NyaWJlIHJlYWwtbGlmZSBleGFtcGxlcyB3aGVyZSBkb3duc3RyZWFtIENETiAob3IgZWRn ZSBjYWNoZS1iYXNlZCkgY29udGVudCBhZGFwdGF0aW9uIGlzIG5lZWRlZCB0b2RheSBpbiBhIHBy b2R1Y3Rpb24gZW52aXJvbm1lbnQsIG9yIHNob3J0bHk/IE5vdCBtZXJlbHkgYSBmZWF0dXJlIGlu IGEgdmVuZG9yJ3MgcHJvZHVjdCBtYXRlcmlhbHM/DQoNClNwZWFraW5nIGFzIGFuIGluZGl2aWR1 YWwsIEkgY2FuIGZpbmQgYSBsb3Qgb2YgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBjb250ZW50 IGFkYXB0YXRpb24gaXMgbm90IG5lZWRlZCwgYW5kIGFueSBhZGFwdGF0aW9uIGlzIHJlYWxseSBw YXJ0IG9mIHRoZSBDUCAtIHVDRE4gaW50ZXJmYWNlICh3aGljaCBpcyBvdXQgb2YgdGhlIHNjb3Bl IG9mIG91ciBjaGFydGVyKS4NCg0KLS0gUmljaA0KDQoNCkZyb206IFpob3VaaGlwZW5nIFttYWls dG86emhvdXpoaXBlbmdAaHVhd2VpLmNvbV08bWFpbHRvOlttYWlsdG86emhvdXpoaXBlbmdAaHVh d2VpLmNvbV0+DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSAwMzo0NSBBTQ0KVG86 IE1hcmsgZGUgSm9uZyA8bWFya0BqZXQtc3RyZWFtLm5sPG1haWx0bzptYXJrQGpldC1zdHJlYW0u bmw+PjsgQWxhbiBLYXZhbmFnaCA8YWxhbi5rYXZhbmFnaEBlcmljc3Nvbi5jb208bWFpbHRvOmFs YW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29tPj4NCkNjOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5p QGlldGYub3JnPiA8Y2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0 DQoNCkhlbGxvIE1hcmssDQpOaWNlIHRvIG1lZXQgeW91IG9uIGxpbmUuDQpJbiB5b3VyIGNvbXBh bnnigJlzIHdlYnNpdGUsIEkganVzdCBmaW5kIHNvbWUgaW5mb3JtYXRpb24gdGhhdCBhZGRyZXNz ZXMg4oCcIFZvZGFmb25lIHN1YnNjcmliZXJzIGNvbXBsYWluZWQgYWJvdXQgdmlkZW8gcGVyZm9y bWFuY2Uu4oCdDQpTZWU6DQpodHRwOi8vd3d3LmpldC1zdHJlYW0ubmwvc2VhcmNoLz9zZWFyY2g9 dHJhbnNjb2RpbmcNCg0KRGVhciBhbGwgaW4gdGhpcyBncm91cCwNCkluIGxhc3QgZmV3IGRheXMs IGV4Y2VwdCB0aGUgcHVibGljIGVtYWlsIGRpc2N1c3Npb25zIEkgaGF2ZSBjb250YWN0ZWQgd2l0 aCBzb21lIHBlb3BsZSBhbmQgZGlzY3Vzc2VkIHdpdGggbXkgb3duIGNvbGxlYWd1ZXMgb2YgYWxs IGRldGFpbHMgb24gdGhpcyBpc3N1ZS4NCkZpcnN0LCBhbHRob3VnaCB0aGUgbWFya2V0IHJlcXVp cmVtZW50IGZvciBpdCBpcyB2ZXJ5IGltcG9ydGFudCwgSSBmZWVsIEnigJlkIGJldHRlciBzaG93 IHVwIG1vcmUgaW5mb3JtYXRpb24gb24gdGhlIHByb2NlZHVyZSBpbnZvbHZlZC4gSSBoYXZlIGV4 cGxhaW5lZCBtYW55IHRpbWVzIHRoYXQgdG8gc3VwcG9ydCBjb250ZW50IGFkYXB0YXRpb24gaXMg cmF0aGVyIHNpbXBsZSB3aGlsZSB0aGUgd29yZGluZyBpcyBub3QgZW5vdWdoLg0KSSBhbSBidXN5 IG1ha2luZyBzb21lIGNvbnRyaWJ1dGlvbnMgb24gdGhpcyBhbmQgcGxhbiB0byB1cGxvYWQgdG8g RVRTSSBtZWV0aW5nIGFuZCBJRVRGIENETkkuDQpCeSB0aGVzZSB3b3JrICBJIGZlZWwgdGhlIHBl b3BsZSBtYXkgY2F0Y2ggYSB3aG9sZSB2aWV3IG9uIHRoaXMgaXNzdWUuDQpTZWNvbmQsIGZvciB0 aGF0IGZ1bmN0aW9uYWxpdHksIGluIGltcGxlbWVudGF0aW9uLCBpZiBzb21lIGVudGl0eSBkb2Vz IG5vdCBjaG9vc2UgdG8gc3VwcG9ydCBpdCwgaXQgbWF5IGJlIG9rLiBTaW5jZSBpdCBtYXkgYmUg bmVnb3RpYXRlZCBiZXR3ZWVuICB0d28gQ0ROcy4NCklmIGRDRE4gZG9lcyBub3Qgc3VwcG9ydCB0 aGF0LCBpdCBtYXkgYmUgdGhlIHVDRE4gcmVzcG9uc2libGUgdG8gY29tcGxldGUgdGhlIHRyYW5z Y29kaW5nIGFuZCBkZWxpdmVyIHRoZSBjb250ZW50IG9mIG11bHRpcGxlIGZvcm1hdHMgYW5kIHJh dGVzIHRvIGRDRE4uDQpUaGlyZCwgYWx0aG91Z2ggQ0ROSSBpcyBhIG5ldyBhcmNoaXRlY3R1cmUs IHdoaWxlIHRoZSBjb250ZW50IG9wZXJhdGluZyBoYXMgYmVlbiBleGlzdGVkIGZvciB5ZWFycy4g QXMgSSBrbm93IHRoZSBjb250ZW50IGZyb20gVVNBIHRvIHRoZSBkb3duc3RyZWFtIG9wZXJhdG9y IGlzIHRyYW5zZmVycmVkIG9uIG9uZSBjb3B5IGFuZCB0aGUgZG93bnN0cmVhbSBvcGVyYXRvciB3 aWxsIGhhbmRsZSB0aGUgdHJhbnNjb2RpbmcuDQoNClBlcmhhcHMsIHRoZSBjb250ZW50IGFkYXB0 YXRpb24gaXMgbW9yZSBvbiB0aGUgbW9iaWxlIG9wZXJhdGluZy4gQnV0IEkgZmVlbCBjdXJyZW50 bHkgbW9zdCBvcGVyYXRvciB3aWxsIGJlIGEgYWxsIHNlcnZpY2Ugb3BlcmF0b3IuIEFuZCBmb3Ig dGhlIENETiBwcm92aWRlcnMsIGl0IG1heSBiZSBiZXR0ZXIgdG8gc3VwcG9ydCBhbGwga2luZHMg b2Ygc2VydmljZS4NCkJlc2lkZXMsIEkgbGlrZSBzYXkgdGhhdCB0aGUgdGVjaG5vbG9neSBvbiB0 aGlzIHRvcGljIGhhcyBiZWVuIGZvciBtYW55IHllYXJzIGFuZCBoYXMgYmVlbiByYXRoZXIgbWF0 dXJlLCBldmVuIHNvbWUgaXRlbXMgaW4gaWV0ZiBzdWNoIGFzIHJmYzM1MDcgIGljYXAuIFNvIGZy b20gdGhlIHRlY2huaXF1ZSBwb2ludCBvZiB2aWV3LCBpdCBpcyBhIG5hdHVyZSBhY3Rpb24gdG8g YmUgaW52b2x2ZWQgaW4gQ0ROIGludGVyY29ubmVjdGlvbi4NClRoYW5rcy4NClpoaXBlbmcNCg0K DQoNCg0KRnJvbTogTWFyayBkZSBKb25nIFttYWlsdG86bWFya0BqZXQtc3RyZWFtLm5sXTxtYWls dG86W21haWx0bzptYXJrQGpldC1zdHJlYW0ubmxdPg0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIg MjcsIDIwMTEgNDoyMSBBTQ0KVG86IEFsYW4gS2F2YW5hZ2gNCkNjOiBCZW4gTml2ZW4tSmVua2lu czsgWmhvdVpoaXBlbmc7IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAu dHh0DQoNCkhpIEFsYW4sDQoNCkFzIEJlbiBzdGF0ZWQgdGhlIG92ZXJhbGwgZGlzY3Vzc2lvbiBy aWdodCBub3cgaXMgYWJvdXQgZGVsaXZlcnksIG5vdCBvbiBhZGFwdGF0aW9uLiBJdCBpcyBoYXJk IGVub3VnaCB0byBnZXQgY29uc2Vuc3VzIG9uIHRoZSBkZWxpdmVyeSBhc3BlY3QgYWxyZWFkeSBu b3QgdG8gbWVudGlvbiB5b3VyIHJlcXVpcmVtZW50IGZyb20gY29udGVudCBhZGFwdGF0aW9uIGFk ZGVkIHRvIHRoYXQsIHNvIEkgYWdyZWUgd2l0aCBCZW4gd2Ugc2hvdWxkIHN0aWNrIHdpdGggdGhl IGRlbGl2ZXJ5IGFzcGVjdCBmb3IgdGhlIGZpcnN0IHNwZWNzLiBJIGNhbiBpbWFnaW5lIHRoaXMg Y291bGQgYmUgYSBkaXNjdXNzaW9uIGxhdGVyIG9uIGJ1dCBwbGVhc2UgbGV0IHVzIGtlZXAgdGhl IHNjb3BlIG9mIHRoaXMgYmUgY2xlYW4gYW5kIHRyYW5zcGFyZW50LiBJdCBpcyBvZiBiZW5lZml0 IG9mIGV2ZXJ5b25lIHRvIGdldCB0aGUgZmlyc3Qgc3BlY3MgYXMgZmFzdCBhcyBwb3NzaWJsZS4g VGhhbmtzLg0KDQpNZXQgdnJpZW5kZWxpamtlIGdyb2V0LA0KS2luZCByZWdhcmRzLA0KDQpNYXJr IGRlIEpvbmcNCkludGVybmF0aW9uYWwgQnVzaW5lc3MgRGV2ZWxvcGVyDQpKZXQtU3RyZWFtIEJW DQoNCkUtbWFpbDogbWFya0BqZXQtc3RyZWFtLmNvbTxtYWlsdG86bWFya0BqZXQtc3RyZWFtLmNv bT4NCk9mZmljZTogKzMxICgwKTUwIDUyNjE4MjANCk1vYmlsZTogKzMxICgwKTYgODExMDgyNjMN CkZheDogKzMxICgwKTUwIDUyNjQyMTQNCg0KLSBFdmVudDogTWVldCB1cyBhdCBTdHJlYW1pbmcg TWVkaWEgRXVyb3BlLCAxNy0xOCBPY3RvYmVyLCBMb25kb24sIFVLDQotIEV2ZW50OiBNZWV0IHVz IGF0IE9ubGluZSBWaWRlbyBTdHJhdGVnaWVzLCAxOSBPY3RvYmVyLCBMb25kb24sIFVLDQotIEV2 ZW50OiBNZWV0IHVzIGF0IENETiBXb3JsZCBTdW1taXQsIDI1LTI4IE9jdG9iZXIsIExvbmRvbiwg VUsNCi0gTmV3czogUHJlLXJlcXVlc3QgeW91ciBUZWNobm9sb2d5IFdoaXRlcGFwZXIgbm93IGFu ZCBiZSB0aGUgZmlyc3QgdG8gaGF2ZSBpdCwgY2hlY2sgd3d3LmpldC1zdHJlYW0uY29tPGh0dHA6 Ly93d3cuamV0LXN0cmVhbS5jb20+DQotIE5ld3M6IENoZWNrIGh0dHA6Ly93d3cuamV0LXN0cmVh bS5jb20gdG8gZG93bmxvYWQgb3VyICdTaXggVHJlbmRzIGluIENETnMnIGJyb2NodXJlDQoNCi0g QmxvZzogd3d3LmpldC1zdHJlYW0uY29tL2Jsb2cvPGh0dHA6Ly93d3cuamV0LXN0cmVhbS5jb20v YmxvZy8+DQotIFZpZGVvRXhjaGFuZ2U6IHd3dy52ZG8teC5uZXQ8aHR0cDovL3d3dy52ZG8teC5u ZXQ+DQotIFN0cmVhbXppbGxhOiB3d3cuc3RyZWFtemlsbGFjZG4uY29tPGh0dHA6Ly93d3cuc3Ry ZWFtemlsbGFjZG4uY29tPg0KLSBDb3Jwb3JhdGU6IHd3dy5qZXQtc3RyZWFtLmNvbTxodHRwOi8v d3d3LmpldC1zdHJlYW0uY29tPg0KDQpPbiAyNiwgT2N0LDIwMTEsIGF0IDg6MzMgUE0sIEFsYW4g S2F2YW5hZ2ggd3JvdGU6DQoNCkJlbg0KDQpJbSBhc3N1bWluZyB0aGVuIGJhc2VkIG9uIHlvdXIg Y29tbWVudHMgYmVsb3cgYXJlIHlvdSBzdWdnZXN0aW5nIHdlIGFyZSBnb2luZyB0byBoYXZlIGEg bnVtYmVyIG9mIHZlcnNpb25zIG9mIHRoZSBDRE4tSSBNZXRhZGF0YT8NCg0KSSBzeW1wYXRoaXNl IHdpdGggd2hhdCB5b3UgYXJlIHBvaW50aW5nIG91dCBiZWxvdyBhbmQgZG8gYWdyZWUgdGhhdCB0 aGVyZSBpcyBzb21lIHdvcmsgdG8gYmUgZG9uZSwgYnV0IEkgc3RpbGwgZmVlbCB0aGF0IGNvbnRl bnQgYWRhcHRhdGlvbiBpcyB0byBtZSBhIGZ1bmRhbWVudGFsIHJlcXVpcmVtZW50IHRvIHdoYXQg Y29sbGVjdGl2ZWx5IHdlIHNob3VsZCBhZGRyZXNzIGluIHRoZSBDRE4tSSBXRy4gSSBkbyBhZ3Jl ZSB3aXRoIHlvdSB0aGF0IGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBhbiBvcHRpbWl6YXRpb24gYmV0 d2VlbiBDRE4ncyBidXQgaXQncyBhIHZlcnkgaW1wb3J0YW50IG9uZSB0aGF0IEkga25vdyBOZXR3 b3JrIFNlcnZpY2UgUHJvdmlkZXJzIHBhcnRpY3VsYXJseSByZXF1aXJlLg0KDQpBbGFuDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmdd PG1haWx0bzpbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10+IE9uIEJlaGFsZiBPZiBCZW4g Tml2ZW4tSmVua2lucw0KU2VudDogT2N0b2Jlci0xMi0xMSAxOjEzIFBNDQpUbzogWmhvdVpoaXBl bmcNCkNjOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQpa aGlwZW5nLA0KDQpPbiAxMiBPY3QgMjAxMSwgYXQgMTA6MjIsIFpob3VaaGlwZW5nIHdyb3RlOg0K SGVsbG8gQmVuLA0KVGhlIFVFIG1heSBzZWxlY3QgdGhlIGNvbnRlbnQgZm9ybWF0IG9uIHRoZSBD UCB3ZWIuIEFmdGVyIHRoYXQgdGhlIHVzZXIgb25seSBkZXNpcmVzIHRvIGdldCBoaXMgc2VsZWN0 ZWQgY29udGVudC4NCkJ1dCBob3cgdGhlIGNvbnRlbnQgaXMgdHJhbnNmZXJyZWQgdG8gdGhlIGNs aWVudCBpcyBub3Qgd29ycmllZCBieSB0aGUgdXNlci4NClRoZSBDUCBtYXkgY3JlYXRlIGEgc3Bl Y2lhbCBmb3JtYXQgYXMgcmVxdWlyZWQgYnkgdGhlIHVzZXIgYW5kIGFzayB0aGUgQ0ROIHRvIGRl bGl2ZXIgdG8gdXNlci4NCldoaWxlIENQIG1heSBnaXZlIGEgSEQgZm9ybWF0IGNvbnRlbnQgdG8g dUNETiBhbmQgdGhlIGRDRE4gbWF5IHRoZW4gdHJhbnNmb3JtIHRvIHRoZSBmb3JtYXQgYXMgdGhl IHVzZXIgc2VsZWN0Lg0KDQpMb3RzIG9mIHRoaW5ncyBtYXkgYmUgcG9zc2libGUgdG8gZG8gYW5k IENETiBwcm92aWRlcnMgb2ZmZXIgbWFueSBhZGRpdGlvbmFsIHNlcnZpY2VzIG9uIHRvcCBvZiB0 aGUgImNvcmUiIHNlcnZpY2Ugb2YgY29udGVudCBkZWxpdmVyeS4gSG93ZXZlciwgb3VyIG9iamVj dGl2ZSAoYmFzZWQgb24gbXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlIENETkkgY2hhcnRlcikgaXMg dG8gZm9jdXMgb24gd2hhdCBpcyBuZWNlc3NhcnkgdG8gaW50ZXJjb25uZWN0IENETnMgdG8gZGVs aXZlciBjb250ZW50IGZyb20gYSBDU1AgdG8gYW4gRW5kIFVzZXIgdGhhdCBpcyB0YXJnZXRlZCBh bmQgZGVwbG95YWJsZSB3aXRoaW4gYSBzaG9ydCB0aW1lIGZyYW1lICgxOC0yNCBtb250aHMpLg0K DQpDb250ZW50IHRyYW5zZm9ybWF0aW9uL2FkYXB0YXRpb24gaXMgbm90IGFuIGVzc2VudGlhbCBy ZXF1aXJlbWVudCBpbiBvcmRlciB0byBhY2hpZXZlIHRoYXQgYWltICh3ZSBjYW4gZGVsaXZlciBj b250ZW50IGZyb20gQ1NQcyB0byBFbmQgVXNlcnMgdmlhIG11bHRpcGxlIENETnMgd2l0aG91dCBu ZWVkaW5nIG9yIHJlcXVpcmluZyBhbnkgQ0ROIHN1cHBvcnRzIGNvbnRlbnQgYWRhcHRhdGlvbiku DQoNCkluIG15IG9waW5pb24gd2UgaGF2ZSBlbm91Z2ggd29yayB0byBkbyBhbHJlYWR5IHdpdGhv dXQgdHJ5aW5nIHRvIGV4cGFuZCB0aGUgc2NvcGUgb2Ygb3VyIHdvcmsgdG8gaW5jbHVkZSBhZGRp dGlvbmFsIHJlcXVpcmVtZW50cyB0aGF0IGRvIG5vdCBoZWxwIHVzIGFkZHJlc3Mgb3VyIGNvcmUg b2JqZWN0aXZlcyBhcyBsYWlkIG91dCBpbiB0aGUgQ0ROSSBjaGFydGVyLg0KSW4gdGhpcyBjYXNl LCBpdCBpcyBub3RoaW5nIHJlbGF0ZWQgdG8gaG93IHRoZSB1c2VyIHNlbGVjdCBmb3JtYXRzIG9u IENQIHdlYnNpdGUuDQpTbywgaXQgaXMgdGhlIENQIGFuZCB1c2VyIHRvIGRlY2lkZSB0aGUgY29u dGVudCBmb3JtYXQgbm90IHRoZSBDRE4oeW91ciBhc3NlcnQgaXMgbm90IGNvcnJlY3QgYW5kIHNl ZW1zIHlvdSB0YWtlIHRoYXQgYXNzZXJ0IGFzIHlvdXIgYmFzZSBmb3IgdGhlIGRpc2N1c3Npb24p Lg0KDQpBcyBmb3IgInRoZSBjb3JlIENETiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgQ0ROcyB0 b2RheSIsIEkgaGF2ZSBldmVyIHJhaXNlZCBhbiBlbWFpbCBiZWZvcmUgdGhhdCB5b3VyIGNvbXBh bnkncyB3ZWJwYWdlIGhhcyBjbGFpbWVkIHN1cHBvcnRpbmcgbWVkaWEgdHJhbnNmb3JtYXRpb24g YW5kIG11bHRpLXNjcmVlbiBzZXJ2aWNlLg0KUGVyaGFwcywgSSBsaWtlIGFza2luZyB5b3UgbGlz dCBzb21lIGZlYXR1cmVzIHRoYXQgeW91IGZlZWwgYXJlIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdGll cyBieSBleGlzdGluZyBtYWluIHN0cmVhbSBDRE5zLiBUaHVzIHdlIG1heSBjb21wYXJlIGFuZCB0 YWtlIGRlZXAgbG9vay4NCg0KSSB0aGluayB0aGUgY29yZSBmdW5jdGlvbmFsaXR5IG1hcHMgcHJl dHR5IHdlbGwgdG8gdGhlIENETkkgaW50ZXJmYWNlcywgbmFtZWx5OiBSZXF1ZXN0IFJvdXRpbmcs IE1ldGFkYXRhIGNvbmZpZ3VyYXRpb24sIGxvZyBwcm9kdWN0aW9uIGFuZCBjb250cm9sIHBsdXMg Y29udGVudCBhY3F1aXNpdGlvbiBhbmQgY29udGVudCBkZWxpdmVyeS4NCkkgZ3Vlc3MgbWFueSBw ZW9wbGUgaGF2ZSB0aGUgZXhwZXJpZW5jZS9rbm93bGVkZ2Ugb2YgY29udGVudCByZWxhdGVkIHNl cnZpY2UuIFRoZSB1c2VyIGFuZCBDUCBvbmx5IGNhcmUgd2hldGhlciB0aGUgQ0ROIHByb3ZpZGVy cyBtYXkgc2F0aXNmeSB0aGVpciByZXF1aXJlbWVudCB3aGlsZSBub3QgY2FyZSB0aGUgaW50ZXJu YWwgcHJvY2Vzcy4gSnVzdCBhcyBHU00vUFNUTiBpbnRlcmNvbm5lY3Rpb24sIHRoZSB1c2VyIG9u bHkgY2FyZSBzdWNjZXNzZnVsIGludGVyY29ubmVjdGlvbiB3aGlsZSBub3QgY2FyZSBob3cgdGhl IHZvaWNlIGlzIHRyYW5zZm9ybWVkIGluIHByb2Nlc3MuDQoNCkJlc2lkZXMsIEkgbGlrZSByYWlz ZSBhIGNhc2U6DQpHaXZlbiBjdXJyZW50bHkgQkJDIHJlY3J1aXRzIENETiBwcm92aWRlcnMgdGhh dCBtYXkgc3VwcG9ydCAxMCBtZWRpYSBmb3JtYXRzLg0KT25lIGNhbmRpZGF0ZSBpcyB5b3VyIGNv bXBhbnksIGFub3RoZXIgaXMgQ0ROLVguIFRoZSB1c2VycyBhcmUgbG9jYXRlZCBpbiBGcmFuY2Uu DQpTbyBib3RoIHlvdXIgY29tcGFueSBhbmQgQ0ROLVggc2hvdWxkIGNvbm5lY3QgYSBGcmFuY2Ug Q0ROIHByb3ZpZGVyKENETi1ZKS4NCklmIHlvdXIgY29tcGFueSdzIHNvbHV0aW9uIGlzIHRvIHNl bmQgMTAgc3RyZWFtcyBvZiBkaWZmZXJlbnQgZm9ybWF0DQpvZiBvbmUgY29udGVudCB0byBDRE4t WTsgV2hpbGUgQ0ROLVgncyBzb2x1dGlvbiBpcyB0byBzZW5kIDEgc3RyZWFtIHRvIENETi1ZIHdo aWxlIENETi1ZIG1heSBjb25kdWN0IHNvbWUgYWRhcHRhdGlvbi4NCkNvbXBhcmluZyB0aGVzZSB0 d28gc29sdXRpb25zLCBmb3IgeW91ciBjb21wYW55IGFuZCBDRE4tWCwgYWJzb2x1dGVseSB0aGUg Y29zdCBvZiBDRE4tWCBpcyBtdWNoIGxvd2VyLg0KRm9yIENETi1ZLCBpbiBzb2x1dGlvbi0xLCBp dCBzaG91bGQgcmVjZWl2ZS9mb3J3YXJkIDEwIHN0cmVhbXMgOyB3aGlsZSBpbiBzb2x1dGlvbi0y LCBpdCBzaG91bGQgb25seSByZWNlaXZlIDEgc3RyZWFtIGJ1dCBuZWVkIHRvIHRha2UgdHJhbnNm b3JtYXRpb24gdG8gb3V0cHV0IDEwIHN0cmVhbXMuDQoNCldoaWNoIHNvbHV0aW9uIGlzIG1vcmUg Y29tcGV0aXRpdmUuIGl0IGlzIFNvbHV0aW9uIDEsIHJpZ2h0LiBSZW1lbWJlciB0aGUgcHJpY2Ug ZnJvbSBCQkMgaXMgc2FtZSB0byBib3RoIHlvdXIgY29tcGFueSBhbmQgQ0ROLVggb3IgQkJDIHdv dWxkIHNlbGVjdCBvbmUgQ0ROIHByb3ZpZGVyIHdpdGggdGhlIGxvd2VyIHByaWNlLg0KSWYgYSBD RE4gcHJvdmlkZXIgbWF5IG5vdCBnZXQgdGhlIGNvbnRyYWN0IGZyb20gQ1AsIGhvdyBpdCBtYXkg c2F5IGl0IGlzIG5vdCBhIGNvcmUgZnVuY3Rpb25hbGl0eS4NCg0KV2hhdCB5b3UgYXJlIGRlc2Ny aWJpbmcgaXMgYSBwb3NzaWJsZSBvcHRpbWl6YXRpb24gdGhhdCBhIHBhcnRpY3VsYXIgQ0ROIG1h eSB3aXNoIHRvIGltcGxlbWVudCBub3QgYSBjb3JlIGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgdG8g ZW5hYmxlIGNvbnRlbnQgZGVsaXZlcnkgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5zLiBJIGNh biB0aGluayBvZiBtYW55IG9wdGltaXphdGlvbnMgdGhhdCBhIENETiBjb3VsZCBpbXBsZW1lbnQg dG8gZGlmZmVyZW50aWF0ZSB0aGVpciBzZXJ2aWNlIGJ1dCB0aGUgaW50ZXJuYWwgd29ya2luZ3Mg b2YgYW4gaW5kaXZpZHVhbCBDRE4gYXJlIG91dCBvZiBzY29wZSBvZiBvdXIgY2hhcnRlci4NCg0K U28gdG8gcmVwZWF0IG15IHBvc2l0aW9uIGZvciBhIGZpbmFsIHRpbWU6IENvbnRlbnQgYWRhcHRh dGlvbiBpcyBub3QgYSBjb3JlIGZ1bmN0aW9uIHJlcXVpcmVkIHRvIGVuYWJsZSBjb250ZW50IGRl bGl2ZXJ5IGJldHdlZW4gaW50ZXJjb25uZWN0ZWQgQ0ROcyBhbmQgdGhlcmVmb3JlIGdpdmVuIHRo ZSB3b3JrbG9hZCB3ZSBhbHJlYWR5IGhhdmUgdG8gc3BlY2lmeSBzb2x1dGlvbnMgdGhhdCBkbyBh ZGRyZXNzIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgdG8gaW50ZXJjb25uZWN0IENE TnMgSSBkbyBub3QgdGhpbmsgd2Ugc2hvdWxkIGJlIHRyeWluZyB0byBhZGQgbW9yZSB3b3JrIGlu dG8gdGhhdCB3b3JrbG9hZCBhcyBpdCB3aWxsIG9ubHkgZGlzdHJhY3QgdXMgZnJvbSBhY2hpZXZp bmcgb3VyIGdvYWwgb2YgcHJvZHVjaW5nIGRlcGxveWFibGUgc29sdXRpb25zIHdpdGhpbiB0aGUg dGltZWZyYW1lIHdlIGFyZSBiZWluZyB0b2xkIGJ5IG9wZXJhdG9ycyB0aGV5IG5lZWRzIHNvbHV0 aW9ucyB3aXRoaW4uDQoNCkJlbg0KU28sIGlmIHdlIGFsbCByZWFsaXplIHRoYXQgY3VycmVudGx5 IHRoZSBtZWRpYSB0eXBlIGlzIHJpY2gsIHRoZSBDRE4gcHJvdmlkZXJzIHNob3VsZCBzdXJ2aXZl IGluIHRoZSBleGlzdGluZyBlY29zeXN0ZW0gYW5kIHN1cHBvcnQgdGhlIG1lZGlhIHR5cGVzIGFz IHJlcXVpcmVkIGJ5IHRoZSBtYXJrZXQuDQoNCkJhY2sgdG8gdGhlIGNhc2Ugb2YgR1NNL0cuNzEx LCBpdCBqdXN0IHdoZW4gY29uY2VybmluZyB0aGUgaW50ZXJjb25uZWN0aW9uLCB0aGUgdHJhbnNm b3JtYXRpb24gc2hvdWxkIGF0IG9uY2UgYmUgc29sdmVkLiBPdGhlcndpc2UgdGhlIGludGVyY29u bmVjdGlvbiBtYXkgbm90IGJlIG9wZXJhdGVkLg0KDQpCciwNClpoaXBlbmcNCg0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJlbiBOaXZlbi1KZW5raW5zIFttYWlsdG86 YmVuQG5pdmVuLWplbmtpbnMuY28udWtdPG1haWx0bzpbbWFpbHRvOmJlbkBuaXZlbi1qZW5raW5z LmNvLnVrXT4NClNlbnQ6IFdlZG5lc2RheSwgT2N0b2JlciAxMiwgMjAxMSAxMjoxOSBBTQ0KVG86 IFpob3VaaGlwZW5nDQpDYzogcGhpbGlwLmVhcmRsZXlAYnQuY29tPG1haWx0bzpwaGlsaXAuZWFy ZGxleUBidC5jb20+OyBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4 dA0KDQpaaGlwZW5nLA0KDQpPbiAxMSBPY3QgMjAxMSwgYXQgMDU6MTYsIFpob3VaaGlwZW5nIHdy b3RlOg0KDQpCZW4gYW5kIFBoaWxpcCwNCkkgbGlrZSB0byByZXNwb25kIHlvdXIgY29uY2VybiBp biB0aGlzIG9uZSBlbWFpbDoNCg0KQmVuLA0KSSBmZWVsIHdoYXQgd2UgYXJlIG5vdyBkaXNjdXNz aW5nIGlzIHdoYXQgaXMgdGhlICJjb3JlIiBmdW5jdGlvbiBvZiBDRE4uDQpBcyB5b3Ugc2F5LCBD RE4gaXMgdXNlZCB0byBkZWxpdmVyIGNvbnRlbnQuIFRoYXQgaXMgYWJzb2x1dGVseSBjb3JyZWN0 IHRoYXQgdGhlIGRlbGl2ZXJ5IGNhcGFiaWxpdHkgaXMgdGhlIGNvcmUgcmVxdWlyZW1lbnQgZm9y IENETiBzeXN0ZW0uDQpXaGlsZSBDRE4gaXMgdXNlZCB0byBwcm92aWRlIHRoZSBjb250ZW50IGRl bGl2ZXJ5IHNlcnZpY2UuDQpXaGF0IG1lYW5zIHNlcnZpY2UuIEl0IHNob3VsZCBpbmNsdWRlICJ0 aW1lIiAibG9jYXRpb24iIGFuZCAibWVkaWEgdHlwZSIsIGV0Yy4gVGhlc2UgZmVhdHVyZXMgYXJl IGFsbCB0aGUgY29yZSBmZWF0dXJlIGZvciBhIHNlcnZpY2UuDQpJZiB3ZSBvbmx5IGNvbmNlcm4g ImRlbGl2ZXJpbmcgb25lIGRhdGEgYmxvY2siLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIGlz c3VlcyBzdWNoIGFzICJsb2dnaW5nIiAiZ2VvZ3JhcGhpYyBjb25zdHJhaW50IiBhcmUgdGhlIGNv cmUgb2YgQ0ROLg0KDQpGb3IgIndpdGhvdXQgZXhwbGljaXQga25vd2xlZGdlIG9mIHdoYXQgdGhh dCBjb250ZW50IGFjdHVhbGx5IGlzICIsIEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgd29yZGlu ZyBpcyBhY2N1cmF0ZSBzaW5jZSBnZW5lcmFsbHkgYSBDRE4gbWF5IGNsYWltIGl0IHN1cHBvcnQg ZGlmZmVyZW50IG1lZGlhcy4NCkJ5IHRoaXMgb3Bwb3J0dW5pdHksIEkgbGlrZSB0byBzaGFyZSBh IHVzZSBjYXNlOiBhIGNhbGwgZnJvbSBhIEdTTSBwaG9uZSB0byBhIFBTVE4gdGVsZXBob25lLCB0 aGUgdm9pY2Ugc3RyZWFtIHNob3VsZCBiZSB0cmFuc2Zvcm1lZCBmcm9tIEdTTSB2b2ljZSB0byBH LjcxMS4NCkZvciB0aGUgdXNlciwgaGUgZG9lcyBub3QgbmVlZCB0byBrbm93IHdoYXQgdHlwZSBv ZiBkYXRhIGhhcyBiZWVuIHRyYW5zZmVycmVkLCBidXQgdGhlIG9wZXJhdG9yIGhhcyBkb25lIHNv bWUgd29yayB0byBpbnRlcmNvbm5lY3QgdHdvIHN5c3RlbXMsIHJpZ2h0Lg0KSSBsaWtlIHRvIGtu b3cgd2hldGhlciB5b3UgbWF5IGFjY2VwdCB0aGF0IG15IHVzZSBjYXNlIGlzIHNpbWlsYXIgdG8g dGhpcyBjYXNlIGFib3ZlLg0KDQpJIGRvbid0IHRoaW5rIHlvdXIgdXNlIGNhc2UgaXMgc2ltaWxh ciB0byB0aGUgYW5hbG9neSBvZiBtb2JpbGUgbmV0d29ya3MgYmVpbmcgaW50ZXJjb25uZWN0ZWQg dG8gUFNUTiBuZXR3b3Jrcy4gSW4gdGhlIGNhc2Ugb2YgY29udGVudCBkZWxpdmVyeSB0aGUgbmVn b3RpYXRpb24gaXMgZG9uZSBiZXR3ZWVuIHRoZSBVc2VyL0NsaWVudCBhbmQgdGhlIENvbnRlbnQg UHJvdmlkZXIgYW5kIHRoZSBDRE4gaXMganVzdCB1c2VkIHRvIGV4ZWN1dGUvcGVyZm9ybSB0aGUg ZGVsaXZlcnkgdGhhdCBoYXMgYmVlbiBuZWdvdGlhdGVkLiBUaGUgQ0ROIGlzIG5vdCBpbnZvbHZl ZCBpbiB0aGUgZGVjaXNpb24gbWFraW5nIG9mIHdoYXQgcmVwcmVzZW50YXRpb25zIHRoZSBDb250 ZW50IFByb3ZpZGVyIGRlY2lkZXMgdG8gb2ZmZXIgdG8gdGhlIFVzZXIvQ2xpZW50IG9yIGluIHdo YXQgcmVwcmVzZW50YXRpb25zIHRoZSBVc2VyL0NsaWVudCBkZWNpZGVzIHRvIHJlcXVlc3QuDQoN CkFzIGZvciB5b3Ugc2FpZCBzZWxlY3RpbmcgbWVkaWEgYnkgdGhlICJwb3J0YWwiLCB5b3UgbWF5 IHNlZSB0aGUgd2F5ICIgdUNETiBkZWxpdmVycyBtdWx0aXBsZSBtZWRpYSBzdHJlYW1zIHRvIGRD RE4iIGlzIG5vdCBnb29kIHRoYW4gInVDRE4gZGVsaXZlcnMgb25lIG1lZGlhIHN0cmVhbSB0byBk Q0ROIGFuZCBkQ0ROIHRha2VzIHNvbWUgYWRhcHRhdGlvbiB0byBzdXBwb3J0IG11bHRpcGxlIG1l ZGlhIHR5cGVzIi4NCg0KTm93IHdoYXQgeW91J3JlIHRhbGtpbmcgYWJvdXQgaXMgYW4gb3B0aW1p c2F0aW9uLCBub3QgYSBjb3JlIGZ1bmN0aW9uIHJlcXVpcmVkIHRvIGFjdHVhbGx5IGRlbGl2ZXIg dGhlIGNvbnRlbnQgKGFuZCByZXBvcnQsIGJpbGwsIGV0Yy4gZm9yIHRoYXQgZGVsaXZlcnkpLg0K DQpNeSBwb3NpdGlvbiBpcyB0aGF0IHdlIHNob3VsZCBmb2N1cyBvbiBob3cgdG8gZW5hYmxlIHRo ZSBpbnRlcmNvbm5lY3Rpb24gb2YgdGhlIGNvcmUgQ0ROIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBi eSBDRE5zIHRvZGF5ICh3aGljaCBpcyBhbHNvIG15IGludGVycHJldGF0aW9uIG9mIHRoZSBzY29w ZSBvZiB0aGUgQ0ROSSB3b3JraW5nIGdyb3VwIGFzIGV4cHJlc3NlZCBpbiBpdHMgY2hhcnRlcikg YmVjYXVzZSBkb2luZyBzbyBpcyBhIHNpZ25pZmljYW50IHBpZWNlIG9mIHdvcmsgaW4gaXRzZWxm LiBMZXQncyBub3Qgc3RhcnQgdHJ5aW5nIHRvIGFkZCBpbiBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxp dHkgYmV5b25kIHdoYXQgdGhlIG1ham9yaXR5IG9mIENETnMgc3VwcG9ydCB0b2RheSBhcyB0aGF0 IHdpbGwganVzdCBkZWxheSB1cyBnZXR0aW5nIHVzYWJsZSBzcGVjaWZpY2F0aW9ucyBpbnRvIHRo ZSBtYXJrZXQgaW4gYSB0aW1lbHkgZmFzaGlvbiBJTU8uDQoNCkJlbg0KDQpBIGdvb2QgcXVlc3Rp b24gaXMgInNlY3VyaXR5IiBzaW5jZSBJIGhhdmUgZG9uZSBzaXggeWVhcnMgb24gdGhlIERSTQ0K YW5kIGxpa2UgdG8gcHJvbW90ZSB0aGUgRFJNIGFsbCBhcm91bmQgdGhlIHdvcmxkOikgSWYgdGhl IGNvbnRlbnQgaXMgbmVlZGVkIHRvIGJlIHByb3RlY3RlZCwgZ2VuZXJhbGx5IHlvdSBtYXkga25v dyBhbGwgdGhlIHN5c3RlbXMgc2hvdWxkIGJlIGdyYW50ZWQgYnkgdGhlIGNvbnRlbnQgb3duZXIu DQpIZXJlIEkgYWxzbyBsaWtlIHRvIGNsYXJpZnkgdGhhdCBub3Qgb25seSB0aGUgbWVkaWEgaXRz ZWxmIGJ1dCB0aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBzZXJ2aWNlIGl0c2VsZiAoc3VjaCBh cyB0aGUgZ2VvZ3JhcGhpYyBjb25zdHJhaW50KSBzaG91bGQgYmUgcHJvdGVjdGVkIGFsc28uDQpT bywgdHJ1c3QgaXMgbm90IGEgcHJvYmxlbSBmb3IgdGhlIG1lZGlhLg0KDQpQaGlsaXAsDQpUaGFu ayB5b3UgdGhhdCB5b3UgZmVlbCBDb250ZW50IEFkYXB0aW9uIGlzIGFuIGlzc3VlIGZvciAiUmVx dWlyZW1lbnRzIiBidXQgSSBkbyBub3Qga25vdyB3aHkgaXQgaXMgbm90IGZvciBVc2UgY2FzZS4N CkkgbGlrZSB0byBjbGFyaWZ5IHRvIFUgdGhhdCBpdCBpcyBpbXBvcnRhbnQgZm9yIHlvdSBvcGVy YXRvciBzaW5jZSBpdCBtYXkgc2F2ZSBpbnZlc3RtZW50IGlmIHRoZSBzeXN0ZW0gbWF5IHN1cHBv cnQgZGlmZmVyZW50IHNlcnZpY2VzLg0KRm9yIHVzIHZlbmRvciwgd2UgYXJlIGhhcHB5IG9wZXJh dG9yIG1heSBpbnN0YWxsIGEgc3lzdGVtIGZvciB0aGUgbW9iaWxlIHNlcnZpY2UgYW5kIGFub3Ro ZXIgc3lzdGVtIGZvciB0aGUgRkJCIHNlcnZpY2UuDQpCdXQgdGhlIHJlYWxpdHkgaXMgYWxsIG9w ZXJhdG9ycyBhc2sgdXMgdG8gcHJvdmlkZSBhIHN5c3RlbSB0aGF0IG1heSBzdXBwb3J0IGRpZmZl cmVudCBzZXJ2aWNlIHN5c3RlbXMuDQoNCkZyYW5rbHksIEJlbiBhbmQgUGhpbGlwLCBJIHJlbWVt YmVyIEkgaGF2ZSBleHBsYWluZWQgc29tZXdoZXJlIHRoYXQgdG8gaW1wbGVtZW50IHRoaXMgaXMg cmF0aGVyIHNpbXBsZSAuDQpBdCBsZWFzdCB0aGUgVXNlIGNhc2UgYW5kIFJlcXVpcmVtZW50IGFy ZSBpbmZvcm1hdGlvbmFsIHRvIGJlIHJlZmVycmVkIGluIGZ1dHVyZSB3b3JrLiBTbyBJIGRvIHJl YWxseSBmZWVsIHlvdSBtYXkgYWNjZXB0IGl0Lg0KT2YgY291cnNlIEkgbGlrZSB0byByZXNwb25k IHlvdXIgbW9yZSBjb25jZXJuIGFuZCBjb21tZW50cy4NClRoYW5rcy4NClpoaXBlbmcNCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBwaGlsaXAuZWFyZGxleUBidC5jb208 bWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbT4gW21haWx0bzpwaGlsaXAuZWFyZGxleUBidC5j b21dPG1haWx0bzpbbWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbV0+DQpTZW50OiBNb25kYXks IE9jdG9iZXIgMTAsIDIwMTEgMTE6MjIgUE0NClRvOiBiZW5Abml2ZW4tamVua2lucy5jby51azxt YWlsdG86YmVuQG5pdmVuLWplbmtpbnMuY28udWs+OyBaaG91WmhpcGVuZw0KQ2M6IGNkbmlAaWV0 Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW0NETmldIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0DQoNCkJlbiwgWmhpcGVuZywgYWxs LA0KDQpJIHRoaW5rIHRoYXQgQ29udGVudCBBZGFwdGF0aW9uIGlzIG1vcmUgYW4gaXNzdWUgZm9y IHRoZSBSZXF1aXJlbWVudHMgZG9jIHRoYW4gZm9yIHRoZSBVc2UgY2FzZXMgZHJhZnQuDQoNClRo ZSBrZXkgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSB3YW50IHRoZSBDRE5JIGludGVyZmFjZXMgdG8g YmUgYWJsZSB0byBjb3BlIHdpdGggYSBzY2VuYXJpbyB3aGVyZSAoc2F5KSBIRC9TRCBjb252ZXJz aW9uIGlzIGRvbmUgaW4gdGhlIGRDRE4gJiB0byBzaWduYWwgYWJvdXQgdGhpcy4NCg0KSSB0aGlu ayB0aGF0IGNvcGluZyB3aXRoIHRoaXMgc2NlbmFyaW8gaXMgYSBzZWNvbmQgb3JkZXIgcmVxdWly ZW1lbnQsIGllIHdlIHNob3VsZCBub3Qgd29ycnkgYWJvdXQgaXQgaW4gdGhlIGluaXRpYWwgc3Rh bmRhcmRzLXRyYWNrIHdvcmsuIEkgZG9uJ3Qga25vdywgZGlkIHdlIGV2ZXIgZGVjaWRlIHdoZXRo ZXIgdGhlIFVzZSBjYXNlcyBkb2MgaXMgcmVzdHJpY3RlZCB0byAiaW5pdGlhbCIgc2NlbmFyaW9z LCBvciB3aGV0aGVyIGl0J3MgYWxsLWVuY29tcGFzc2luZywgaWUgY292ZXJpbmcgImZ1dHVyZSIg c2NlbmFyaW9zIGFzIHdlbGw/DQoNClNjb3R0LA0KUmVhZGluZyBzb21lIG9mIHlvdXIgZXhhbXBs ZXMsIHRoZXkgc2VlbSB0byBiZSB2YWxpZCBldmVuIGlmIGNvbnRlbnQgYWRhcHRhdGlvbiAoSEQv U0QpIGlzIG91dCBvZiBzY29wZS4NCi0gYSBkQ0ROIG1pZ2h0IGZvciBzb21lIHJlYXNvbiBiZSB1 bndpbGxpbmcgdG8gZGlzdHJpYnV0ZSBIRD8NCi0gYSBDU1AgbWlnaHQgd2FudCB0byBtYWtlIHN1 cmUgdGhlIGRDRE4gY2FuIHVzZSBITFMgZW5jYXBzdWxhdGlvbj8NCkJ1dCB0aGVzZSBzb3J0cyBv ZiBleGFtcGxlcyBzZWVtIHRvIGJlIHN0YXRpYyBwb2xpY3kgdGhpbmdzICh0byBkbw0Kd2l0aCB0 aGUgY2FwYWJpbGl0aWVzICYgcHJlZmVyZW5jZXMgb2YgdGhlIENETnMgJiBDU1ApLCByYXRoZXIg dGhhbg0KbWV0YWRhdGEgYXNzb2NpYXRlZCB3aXRoIGEgcGFydGljdWxhciBwaWVjZSBvZiBjb250 ZW50LiBJbiB0aGUNCmRpc2N1c3Npb24gc28gZmFyLCBJIHRoaW5rIG5lZ290aWF0aW9uIGFib3V0 IHN0YXRpYyBwb2xpY3kgc3R1ZmYgaXMNCnJhdGhlciBvdXQgb2Ygc2NvcGUoPykNCg0KT24gc2Vj dXJpdHkgY29uc2lkZXJhdGlvbnMsIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uIGlzIHdoZXRoZXIg dHJ1c3QgaXMgdHJhbnNpdGl2ZS4gRG9uJ3QgdGhpbmsgaXQgbmVlZCBiZSAtIGp1c3QgYmVjYXVz ZSBDU1AgdHJ1c3RzIHVDRE4sIGFuZCB1Q0ROIHRydXN0cyBkQ0ROIGRvZXNuJ3QgbWVhbiB0aGF0 IHRoZSBDU1AgYXV0b21hdGljYWxseSB0cnVzdHMgdGhlIGRDRE4uIEhvd2V2ZXIsIGkgc3VzcGVj dCB0aGlzIGNhbiBnZXQgYXJiaXRyYXJpbHkgY29tcGxleCAtIHNvIG9uZSBwb3NzaWJpbGl0eSBp cyB0byBzYXkgdGhhdCB3ZSB3aWxsIG9ubHkgaGFuZGxlIGNhc2VzIHdoZXJlIHRoZSB0cnVzdCBp cyB0cmFuc2l0aXZlLg0KDQpCZXN0IHdpc2hlcw0KcGhpbA0KDQoNClBoaWxpcCBFYXJkbGV5DQpS ZXNlYXJjaCBhbmQgVGVjaG5vbG9neSBTdHJhdGVneQ0KDQpUaGlzIGVtYWlsIGNvbnRhaW5zIEJU IGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIEl0 J3MgbWVhbnQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkIGFib3Zl LiBJZiB5b3UncmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNjbG9z aW5nLCBjb3B5aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcgdGhpcyBpbmZvcm1hdGlvbiBpcyBw cm9oaWJpdGVkLiBJZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IGxldCBtZSBrbm93IGltbWVkaWF0ZWx5IG9uIHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFu ayB5b3UuIFdlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3RlbSwgYW5kIG1heSByZWNvcmQgeW91ciBl bWFpbHMuDQpCcml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGMNClJlZ2lzdGVyZWQgb2ZmaWNl OiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUogUmVnaXN0ZXJlZCBpbg0KRW5nbGFu ZCBubzogMTgwMDAwMA0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjZG5p LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpj ZG5pLWJvdW5jZXNAaWV0Zi5vcmddPG1haWx0bzpbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9y Z10+IE9uIEJlaGFsZg0KT2YgQmVuIE5pdmVuLUplbmtpbnMNClNlbnQ6IDEwIE9jdG9iZXIgMjAx MSAxMjowNA0KVG86IFpob3VaaGlwZW5nDQpDYzogY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5p LXVzZS1jYXNlcy0wMC50eHQNCg0KQ29sbGVhZ3VlcywNCg0KSU1PIFNlY3Rpb24gNS4xLjMgc2hv dWxkIGJlIHJlbW92ZWQgZnJvbSB0aGUgVXNlIENhc2VzIGRyYWZ0LiBDb250ZW50IEFkYXB0YXRp b24gKGkuZS4gdGFraW5nIGluIGEgY29udGVudCBpdGVtIGluIG9uZSBmb3JtYXQgYW5kIHRyYW5z Zm9ybWluZyBpdCB0byBhbm90aGVyIGZvcm1hdCBvciByZXByZXNlbnRhdGlvbikgaXMgbm90IGEg ImNvcmUiIGZ1bmN0aW9uIG9mIGEgQ0ROIHdoaWNoIHR5cGljYWxseSBkZWxpdmVycyB0aGUgY29u dGVudCB0aGF0IGlzIHJlcXVlc3RlZCB3aXRob3V0IGV4cGxpY2l0IGtub3dsZWRnZSBvZiB3aGF0 IHRoYXQgY29udGVudCBhY3R1YWxseSBpcy4NCg0KTGV0J3Mgbm90IGZvcmdldCB0aGF0IGluIGJ1 aWxkaW5nIGFuIGVuZCB0byBlbmQgY29udGVudCBzZXJ2aWNlIHRoZSBDRE4gaXMgb25seSBvbmUg Y29tcG9uZW50IGFuZCBpcyB0aGUgY29tcG9uZW50IHRhc2tlZCB3aXRoIGV4ZWN1dGluZyB0aGUg ZGVsaXZlcnkgb2YgYSBzcGVjaWZpYyByZXByZXNlbnRhdGlvbiAodmVyc2lvbi9jb3B5L2Zvcm1h dCBldGMuKSBvZiB0aGUgc2VsZWN0ZWQgY29udGVudCBub3QgdGhlIGNvbXBvbmVudCB0YXNrZWQg d2l0aCBkZWNpZGluZyAob3IgYXBwbHlpbmcgcG9saWN5KSBvbiB3aGljaCB2ZXJzaW9uL2NvcHkv cmVwcmVzZW50YXRpb24gb2YgY29udGVudCBzaG91bGQgYmUgZGVsaXZlcmVkLg0KDQpUaGUgZGVj aXNpb24gYXMgdG8gd2hpY2ggdmVyc2lvbi9jb3B5L3JlcHJlc2VudGF0aW9uIHRvIG9mZmVyIGFu ZCBhbGxvdyB0byBiZSBkZWxpdmVyZWQgdG8gYSBnaXZlbiBkZXZpY2UvdXNlciBpcyBpbXBsZW1l bnRlZCBvdXRzaWRlIG9mIHRoZSBDRE4gKGUuZy4gYnkgdGhlICJwb3J0YWwiIHdoZXJlIHRoZSB1 c2VyIGZpcnN0IG1ha2VzIHRoZWlyIGNvbnRlbnQgc2VsZWN0aW9uIHByaW9yIHRvIHRoZSBDRE4g YmVjb21pbmcgaW52b2x2ZWQgaW4gdGhlIGRlbGl2ZXJ5IG9mIHRoZSBzZWxlY3RlZCBjb250ZW50 KS4NCg0KQmVuDQoNCk9uIDggT2N0IDIwMTEsIGF0IDA4OjIwLCBaaG91WmhpcGVuZyB3cm90ZToN Cg0KRm9sbG93aW5nIFNjb3R0J3MgY29tbWVudHMgb24gc2VjdGlvbiA1LjEuMywgSSBmZWVsIFNj b3R0J3MgZGVzY3JpcHRpb24gb24gdGhlIHVzZSBjYXNlIG9mIEhEIGFuZCBTRCBpcyBub3QgZXhh Y3RseSBjb3JyZWN0Lg0KSWYgb25lIG1vdmllIGhhcyB0d28gZm9ybWF0cyBvZiBIRCBhbmQgU0Qs IHRoZW4gd2UgaGF2ZSB0d28gY29udGVudCB3aXRoIGRpZmZlcmVudCBpZGVudGlmaWVyLiBJbiBE Uk0gc2NvcGUsIHRoZSBiYXNpYyB1bml0IGlzIGEgY29udGVudCBjb3B5Lg0KDQpIZXJlIHRoZSBm aXJzdCBidWxsZXQgImEgc3Vic2V0IG9mIGVuY29kaW5ncyBkZWxpdmVyYWJsZSB0byBzcGVjaWZp YyBkZXZpY2VzLCIgaGFzIGxpc3RlZCB0aGUgY2FzZSBvZiBjb250ZW50IGFkYXB0YXRpb24uDQpJ biBsYXN0IG1vbnRoLCBJIGhhdmUgY29udGFjdGVkIHRoZSBBdXRob3JzIG9mIHRoaXMgZG9jdW1l bnQgYW5kIHRha2VuIHNvbWUgZW1haWwgZXhjaGFuZ2VzIHdpdGggR3JhbnQgYW5kIFBoaWxpcCAo QlQpLg0KSSBoYXZlIHNob3duIEJUIHdpdGggc29tZSBpbmZvcm1hdGlvbiB0aGF0IEkga25vdyBp biB0aGlzIGNhc2UgYW5kIGFyZWEgdG8gZXhwbGFpbiB0aGUgY29udGVudCBmbGV4aWJpbGl0eSBp cyBjdXJyZW50bHkgYSBiYXNpYyByZXF1aXJlbWVudCBmb3IgQ0ROIHNlcnZpY2UgYW5kIHJlbGF0 ZWQgbmVnb3RpYXRpb24gaXMgbmVlZGVkIGluIHRoZSBDRE4gaW50ZXJjb25uZWN0aW9uLg0KTWVh bndoaWxlLCBJIHNob3VsZCBhbHNvIGludml0ZSB5b3UgaW4gdGhpcyBncm91cCByYWlzaW5nIHlv dXIgY29tbWVudHMgb3IgcXVlc3Rpb25zIG9uIHRoaXMgY2FzZSBzaW5jZSBJIGhvcGUgbXkgdXNl IGNhc2UgbWF5IGJlIGluY29ycG9yYXRlZCBpbiB0aGUgdXNlIGNhc2UgZHJhZnQuDQoNCklmIHlv dSBoYXZlIGFueSBtb3JlIHF1ZXN0aW9uIG9yIGNvbW1lbnRzLCBwbHMgc2hhcmUgaW4gdGhpcyB0 aHJlYWQuDQpUaGFua3MuDQpaaGlwZW5nDQoNCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogU2NvdHQgV2Fpbm5lciBbbWFpbHRvOnN3YWlubmVyQGNpc2NvLmNvbV08 bWFpbHRvOlttYWlsdG86c3dhaW5uZXJAY2lzY28uY29tXT4NClNlbnQ6IEZyaWRheSwgU2VwdGVt YmVyIDMwLCAyMDExIDg6MDIgQU0NClRvOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNl LWNhc2VzLTAwLnR4dA0KDQpTZWN0aW9uIDIuMyBOb21hZGljIFVzZXJzDQpUaGlzIGRlc2NyaXB0 aW9uIGZhbGxzIHVuZGVyIHRoZSBjYXRlZ29yeSBvZiBHZW9ncmFwaGljIEV4dGVuc2lvbg0KeWV0 IHRoZSB0aGlyZCBwYXJhZ3JhcGggc3RhdGVzIHRoZSBjYXNlIHdoZXJlIGEgZGlmZmVyZW50IGRl dmljZSBpcw0KdXNlZCBpbiB0aGUgc2FtZSBDRE4gY292ZXJhZ2UgYXJlYS4gIFRoZSBpbnRlbnQg b2YgdGhpcyB1c2UgY2FzZQ0KbmVlZHMgdG8gYmUgY2xhcmlmaWVkLiAgUGVyaGFwcyB0aGUgdXNl IGNhc2UgaXMgdHJ5aW5nIHRvIGFkZHJlc3MNCnRoZSBzY2VuYXJpbyB3aGVyZSBhIE5vbWFkaWMg VXNlci1BIHdpdGggYW4gYWdyZWVtZW50IGFsbG93aW5nDQphY2Nlc3MgdG8gY29udGVudCBmcm9t IENTUC1BIHZpYSB1Q0ROIG1vdmVzIHRvIGEgZENETiBpbiBhIGRpZmZlcmVudA0KcmVnaW9uLiAg VGhlIGRDRE4gaXMgYWxsb3dlZCB0byBkaXN0cmlidXRlIHRoZSBjb250ZW50IG9mIENTUC1BIHRv DQpVc2VyLUE7IGhvd2V2ZXIsIG5vdCBvdGhlciB1c2VycyBpbiB0aGUgcmVnaW9uIG9mIHRoZSBk Q0ROIGFyZQ0KYWxsb3dlZCB0byByZXRyaWV2ZSB0aGUgY29udGVudCB1bmxlc3MgdGhleSB0b28g aGF2ZSBzdWNoIGFuIGFncmVlbWVudC4NCg0KU2VjdGlvbiA1LjEuMyBDb250ZW50IEVuY29kaW5n IFJlc3RyaWN0aW9ucyBOZWVkIHRvIGNsYXJpZnkgaWYgd2UncmUNCnRhbGtpbmcgYWJvdXQgdGhl IHJlc3RyaWN0aW9ucyBvbiB0aGUgZGVsaXZlcnkgb2Ygc3BlY2lmaWMgY29udGVudA0Kb3IgdGhl IHJlc3RyaWN0aW9ucyBvbiB0aGUgYWJpbGl0eSBvZiBhIENETiB0byBkZWxpdmVyIHNwZWNpZmlj DQpjb250ZW50LiAgSSBjZXJ0YWlubHkgdW5kZXJzdGFuZCB0aGUgY2FzZSB3aGVyZSBhIENTUCB3 aWxsIHJlc3RyaWN0DQp0aGUgZGlzdHJpYnV0aW9uIG9mIGNvbnRlbnQgdG8gYSAibWFuYWdlZCBw YXRoIiBpZiBzdWNoIGNvbnRlbnQgaXMNCkhEIHdoaWxlIGFsbG93aW5nIHRoZSBjb250ZW50IGRp c3RyaWJ1dGlvbiB2aWEgYW4gdW4tbWFuYWdlZCBwYXRoIGlmDQpzdWNoIGNvbnRlbnQgaXMgU0Qg KHNhbWUgY291bGQgYXBwbHkgdG8gZW5jcnlwdGlvbiBtZXRob2RzLCBkZWxpdmVyeQ0KbWV0aG9k cywgZXRjLikuICBPbiB0aGUgY29udHJhcnksIHRoZSBkQ0ROIG1heSBoYXZlIGl0cyBvd24NCnJl c3RyaWN0aW9ucyBvZiBibG9ja2luZyB0aGUgZGlzdHJpYnV0aW9uIG9mIEhEIGNvbnRlbnQgd2hp bGUNCmFsbG93aW5nIHRoZSBkaXN0cmlidXRpb24gb2YgU0QgY29udGVudC4NCg0KbyBmaXJzdCBi dWxsZXQgbWFrZXMgc2Vuc2UgaWYgdGhlIGRDRE4gY2FuIHBlcmZvcm0gYSBzdWJzZXQgb2YNCmVu Y2Fwc3VsYXRpb25zIGZvciBhIHJlZmVyZW5jZSBzZXQgb2YgbWVkaWEgKGUuZy4gSExTLCBIU1Ms IGJ1dCBub3QNCkRBU0gpIG8gc2Vjb25kIGJ1bGxldCBtYWtlcyBzZW5zZSB3aGVyZSB0aGUgZENE TiBkb2Vzbid0IHdhbnQgdG8NCm9mZmVyIGhpZ2ggYml0LXJhdGUgdmFyaWFudHMgb2YgdGhlIG1l ZGlhIG8gdGhpcmQgYnVsbGV0IG1ha2Ugc2Vuc2UNCmlmIHRoZSBwb2xpY3kgYWRkcmVzc2VzIFFv RSBidXQgSSBkb24ndCB0aGluayBzdWJzY3JpYmVyDQpyaWdodHMvYXV0aG9yaXphdGlvbnMgYXBw bHkuDQoNClNlY3Rpb24gMTAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KQXNpZGUgZnJvbSB0 aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgV0lUSElOIHRoZSB1Q0ROIGFuZCBkQ0ROLCBJDQp0 aGluayB3ZSBjYW4gZGVzY3JpYmUgdGhpcyBpbiBmb3VyIGNvbnRleHRzOg0KDQphLiBUaGUgcmVs YXRpb25zaGlwIGJldHdlZW4gdGhlIENTUCBhbmQgdGhlIHVDRE4gKHRoZSBwcmluY2lwbGUgY29u dHJhY3QNCmFycmFuZ2VtZW50IGZvciBkaXN0cmlidXRpb24pDQpiLiBUaGUgcmVsYXRpb25zaGlw IGJldHdlZW4gdGhlIHVDRE4gYW5kIGRDRE4gKHRoZSB0cmFuc2l0aXZlIHRydXN0DQpyZWxhdGlv bnNoaXAgdGhhdCBleHRlbmRzIHRoZSBjb250cmFjdCBkZWZpbmVkIGluIChhKSBhYm92ZSkgYy4g VGhlDQpyZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgVXNlciBhbmQgZENETiAodGhlIHJlY29nbml0 aW9uIG9mIHJpZ2h0IHRvDQpkb3dubG9hZCBwcmVkaWNhdGVkIG9uIChiKSBhYm92ZSkgZC4gVGhl IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZQ0KVXNlciBhbmQgQ1NQICh0aGUgY29udHJhY3QgYXV0 aG9yaXppbmcgdGhlIHVzZXIgYWNjZXNzIHRvIHRoZQ0KY29udGVudCkNCg0KVGhlIHVzZXIgaXMg bm90IGludGVyZXN0ZWQgaW4gdGhlIGEtYiBub3IgdGhlIGItYyByZWxhdGlvbnNoaXAuIFRoZQ0K dXNlciBpcyBvbmx5IGludGVyZXN0ZWQgaW4gdGhlIHRyYW5zcGFyZW5jeSBhbmQgaW50ZXJvcGVy YWJpbGl0eSBvZg0KdGhlIHNlY3VyaXR5IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGQtYiBvciBkLWMg dG8gdGhlIHBvaW50IHRoYXQgdGhlDQphdXRob3JpemF0aW9uIGdyYW50ZWQgaW4gZC1hIGlzIHZp YWJsZSB3aGVuIHRoZSBkZWxpdmVyeSBpcw0KaW5pdGlhdGVkIHZpYSBlaXRoZXIgZC1iIG9yIGQt Yy4gIEFzIGFuIGV4YW1wbGUsIHRoZSB1Q0ROIG1pZ2h0IHVzZQ0KVVJMIGFwcGVuZGVkIHRva2Vu cyBmb3IgYXV0aGVudGljYXRpb24gd2hpbGUgZENETiBtaWdodCB1c2UgVVJMDQphcHBlbmRlZCBo YXNoZXMuICBUaGUgdXNlciBkb2Vzbid0IHdhbnQgdG8ga25vdyBhYm91dCB0aGUgZGlzdGluY3QN Cm1ldGhvZHMsIGJ1dCB0cmFuc3BhcmVuY3kgaXMgb25seSBhZmZvcmRlZCBpZiB0aGUgbWV0aG9k cyBhcmUNCmludGVyb3BlcmFibGUgY2xlYXJseSBkZWZpbmVkIHdoZW4gdGhlIGRlbGVnYXRpb24g Zm9yIGNvbnRlbnQNCmRlbGl2ZXJ5IGlzIGV4ZWN1dGVkLiAgQ2xlYXJseSwgdGhlIGNob2ljZSBv ZiBhdXRoZW50aWNhdGlvbiBtZXRob2QgaXMgZGV0ZXJtaW5lZCBieSB0aGUgcmVzcGVjdGl2ZSBD RE4ncy4NCg0KU2NvdHQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYub3JnPG1haWx0bzpDRE5pQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDRE5pIG1haWxp bmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRm Lm9yZzxtYWlsdG86Q0ROaUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2RuaQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYub3JnPG1haWx0bzpDRE5pQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDRE5pIG1haWxpbmcg bGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGNvbnRl bnRzIGFyZSBzdWJqZWN0IHRvIHRoZSBESVNDTEFJTUVSIGF0IGh0dHA6Ly93d3cudG5vLm5sL2Vt YWlsZGlzY2xhaW1lcgo= --_000_FCC100FC8D6B034CB88CD8173B2DA1581558B761EXCMBX03tsntnon_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly80NTQvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3Nl LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1 bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAx IDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxl LXN0eWxlLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5h bWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iTkwiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBaaGlwZW5nLA0K PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gYmUgY2xlYXIgaGVyZSwgSSBoYXZlIG5vdCBnaXZl biBteSBzdXBwb3J0IHRvIHRoZSBDb250ZW50IEFkYXB0YXRpb24gdXNlIGNhc2UgKG5vciBoYXZl IEkgdm9pY2VkIG15IG9wcG9zaXRpb24gYWdhaW5zdCBpdCkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoZSBjb252ZXJzYXRpb24gSSBoYWQgd2l0aCBCZW4gaGFkIHRvIGRv IHdpdGggdGhlIGNvbmNlcHQgb2YgR3JvdXBlZCBGaWxlIERlbGVnYXRpb24gYW5kIGhvdyBkaWZm ZXJlbnQgcXVhbGl0eSBsZXZlbHMsIGVuY29kZWQgYnkgdGhlIENvbnRlbnQNCiBQcm92aWRlciwg YXJlIGhhbmRsZWQgaW4gYSBDRE4gaW50ZXJjb25uZWN0aW9uIHNjZW5hcmlvLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmF5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gY2RuaS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5aaG91Wmhp cGVuZzxicj4NCjxiPlNlbnQ6PC9iPiBtYWFuZGFnIDMxIG9rdG9iZXIgMjAxMSAxMDowNDxicj4N CjxiPlRvOjwvYj4gRnJhbmNvaXMgTGUgRmF1Y2hldXI8YnI+DQo8Yj5DYzo8L2I+IGNkbmlAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+U29ycnksIG5vdCBLUE4u IEl0IGlzIFJheSBmcm9tIFROTy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+IFpob3VaaGlwZW5nDQo8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDMxLCAyMDExIDQ6NDkgUE08YnI+DQo8Yj5Ubzo8L2I+ICdG cmFuY29pcyBMZSBGYXVjaGV1cic8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjZG5p QGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0NE TmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+RGVhciBGcmFuY29pcywgYW5kIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoYW5rcyBm b3IgYWxsIHRoZSBncm91cOKAmXMgYXR0ZW50aW9uIG9uIHRoaXMgdG9waWMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5JIGFtIGFsc28gaGFwcHkgdGhhdCBteSBwcm9wb3NhbCBoYXMgZ290dGVuIHNvIG11Y2ggdmFs dWFibGUgcmVzcG9uc2UvcXVlc3Rpb25zLyBjb21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoYXQgd2ls bCBiZSB2ZXJ5IGhlbHBmdWwgZm9yIGFsbCBvZiB1cyB0byBjYXRjaCBhIGNvbXBsZXRlIHVuZGVy c3RhbmRpbmcgYW5kIHNvbHV0aW9uIGZvciB0aGlzIG1hcmtldCBkZW1hbmQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5XaGlsZSBJIGZlZWwgdGlsbCBub3cgdGhlIHRvcGljIGl0c2VsZiBoYXMgbm90IGJlZW4gY29t cGxldGVseSBhbmFseXplZCBhbmQgSSBhbSBidXN5IGRvaW5nIHRoZSB3b3JrLiBJIHdpbGwgZXhw b3NlDQogbXkgY29udHJpYnV0aW9uIHNvb24gYWZ0ZXIgSSBjb21wbGV0ZSB0aGF0IHdvcmsuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5NZWFud2hpbGUgSSBob3BlIHRoZSBncm91cCBtYXkgYWxsb3cgc29tZSBtb3Jl IHRpbWUgZm9yIHBlb3BsZSB0byBjb25zaWRlciBpdC4gUGVyaGFwcyBzb21lIG1vcmUgcGVvcGxl IHdpbGwgZW1lcmdlDQogaW4gdGhlIGdyb3VwIG1haWwgbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkN1cnJl bnRseSwgc29tZSBwZW9wbGUgaGFzIGNsYWltZWQgdGhlaXIgcHJlZmVyZW5jZS4gJm5ic3A7SSBm ZWVsIHBlcmhhcHMgbm90IGEgZmV3IHBlb3BsZSBoYXZlIHN1cHBvcnRlZCB0aGlzIHVzZSBjYXNl KHRoZQ0KIGF1dGhvcnMgb2YgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ZHJhZnQt Zm1uLWNkbmktYWR2YW5jZWQtdXNlLWNhc2VzLTAwLCBBbGFuIGZyb20gRXJpY3Nzb24sDQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5DaGluYU1vYmlsZSwgQ2hpbmF0ZWxlY29tLCAm bmJzcDtwZXJoYXBzIGFsc28gS1BOLCBhbmQgbWUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5JIGhhdmUgZXhwbGFpbmVkIHRoYXQgZm9yIENETi1BIGFuZCBDRE4tQiwgdGhleSBt YXkgbmVnb3RpYXRlIHdoZXRoZXIgdG8gc3VwcG9ydCB0aGUgQ0ROSSBhZGFwdGF0aW9uIHNvbHV0 aW9uLiBIZW5jZQ0KIHN1Y2ggb3B0aW9uYWwgYXJyYW5nZW1lbnQgd2lsbCBvbmx5IGJyaW5nIGJl bmVmaXQgd2hlbiBib3RoIHVwc3RyZWFtIGFuZCBkb3duc3RyZWFtIGFncmVlcyB0aGF0IGF0IHRo ZWlyIGFwcHJvcHJpYXRlIHNpdHVhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+U28sIEkgc2luY2VyZWx5IHN1Z2dlc3QgdHdvIENoYWlycyBhbmQgdGhlIHdob2xlIGdyb3Vw IG1heSBhbGxvdyBzb21lIG1vcmUgZGF5cyBmb3IgdGhpcyB0b3BpYy4gJm5ic3A7Jm5ic3A7SSBz dWdnZXN0IGFmdGVyIHRoZQ0KIFRhaXBlaSBtZWV0aW5nIC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJ5IHRoZW4g d2UgYWxsIHdpbGwgZ2V0IGEgY2xlYXJlciB1bmRlcnN0YW5kaW5nIGFuZCBkZWNpc2lvbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhhbmtzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+WmhpcGVu Zw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+IEZyYW5jb2lzDQogTGUgRmF1Y2hldXIgPGEgaHJlZj0ibWFpbHRvOlttYWls dG86ZmxlZmF1Y2hAY2lzY28uY29tXSI+W21haWx0bzpmbGVmYXVjaEBjaXNjby5jb21dPC9hPg0K PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAyOCwgMjAxMSA5OjUwIFBNPGJyPg0K PGI+VG86PC9iPiBaaG91WmhpcGVuZzxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmNk bmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb Q0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SGkgYWdhaW4gWmhpcGVu Zyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ VGhlcmUgaXMgb25lIG90aGVyIHBvaW50IEkgc2hvdWxkIGhhdmUgYnJvdWdodCB1cCBpbiBteSBw cmV2aW91cyBtZXNzYWdlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPlRoZSBxdWVzdGlvbiBpcyBub3Qgc28gbXVjaCB3aGV0aGVyIHRoZXJl IGFyZSBiZW5lZml0cyB0byBhbGxvd2luZyBjb250ZW50IGFkYXB0YXRpb24gZm9yIHNvbWUgZW52 aXJvbm1lbnRzLCBub3Igd2hldGhlciBvbmUgcGFydGljdWxhciBpbmRpdmlkdWFsIGNvdWxkIGNv bmNlaXZlIGFuIGFwcHJvYWNoIGZvciBjb250ZW50DQogYWRhcHRhdGlvbiB0aGF0IHN1aXRzIGhp bS4gVGhlIHF1ZXN0aW9uIGhlcmUgaXMgcmF0aGVyIHdoZXRoZXIgaXQgaXMganVzdGlmaWVkIGZv ciB0aGUgV29ya2luZyBHcm91cCB0byBmb2N1cyBlbmVyZ3kgb24gdGhhdCBwcm9ibGVtIHJpZ2h0 IG5vdyBpbiBvcmRlciB0byBkZXZlbG9wIGEgY29uc2Vuc3VzLWJhc2VkIGFwcHJvYWNoIHRoYXQg c3VpdHMgdGhlIGNvbW11bml0eSBhcyBhIHdob2xlLCB3aGlsZSB3ZSBkb24ndCBldmVuIGhhdmUg dGhlDQogYmFzZSBzb2x1dGlvbiBpbiBwbGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Zb3UgaGF2ZSBtYWRlIGl0IGNsZWFy IHRoYXQgeW91IGZlZWwgdGhlIFdHIHNob3VsZCBpbmRlZWQgZGVkaWNhdGUgZW5lcmd5IG9uIHRo YXQgcHJvYmxlbSByaWdodCBhd2F5IGFuZCBleHBsYWluZWQgeW91ciByYXRpb25hbGUuIFRoYW5r IHlvdS4gT3RoZXJzIGhhdmUgYWxzbyBleHByZXNzZWQgdGhlaXIgb3BpbmlvbnMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Q2hl ZXJzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+RnJhbmNvaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk9uIDI4IE9jdCAyMDExLCBhdCAxMToyNSwgWmhv dVpoaXBlbmcgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkRlYXIgYWxsLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JbiB0 aGVzZSBkYXlzIEkgYW0gYnVzeSBtYWtpbmcgYSBzdW1tYXJ5IGFuYWx5c2lzIG9uIHRoaXMgdG9w aWMuIEFzIFJpY2hhcmTigJlzIHJlcXVlc3QsIEkgbGlrZSB0byBzaG93IG15IGluZm9ybWF0aW9u IGFsdGhvdWdoIHBlcmhhcHMgbm90IGNvbXBsZXRlDQogcmlnaHQgbm93LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDtsaW5lLWhl aWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjEpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JDQogaGF2ZSBkb25lIHNvbWUgd29yayB0 byBjb2xsZWN0IGRpZmZlcmVudCBjb21wYW554oCZcyByZXF1aXJlbWVudHMgYW5kIG9waW5pb25z IG9uIHRoaXMgZnVuY3Rpb25hbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5PbmUsIEkgZmVlbCBtb3N0IG9m IHVzIGhhdmUgYWxyZWFkeSBiZWVuIGF3YXJlIG9mIHRoZSBzZXJ2aWNlIG9mIGNvbnRlbnQgYWRh cHRhdGlvbiwgYW5kIEkgYWxzbyBzZW50DQogYW4gZW1haWwgeWVzdGVyZGF5IHRoYXQgVm9kYXBo b25lIG5vdyBpcyByZXF1aXJpbmcgdGhlIHNvbHV0aW9uIHRvIGVuaGFuY2UgdGhlIHBlcmZvcm1h bmNlIG9mIGl0cyBtb2JpbGUgdmlkZW8gc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5TZWNvbmQsIGhl cmUgaXMgYW4gYXJ0aWNsZSBhYm91dCBDSVNDTyA6IOKAnENpc2NvIHVyZ2VzIG1vYmlsZSBvcGVy YXRvcnMgdG8gYWRkIHZhbHVlIHRvIENETiBzZXJ2aWNlc+KAnTxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwOi8vd3d3LnRvdGFsdGVs ZS5jb20vdmlldy5hc3B4P0lEPTQ2ODcwNSI+aHR0cDovL3d3dy50b3RhbHRlbGUuY29tL3ZpZXcu YXNweD9JRD00Njg3MDU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QmVzaWRlcywgSSBoYXZlIGNoZWNrZWQg bWFueSBDRE4gY29tcGFueeKAmXMgd2Vic2l0ZXMuIE1hbnkgY2xhaW0gdG8gc3VwcG9ydCB0cmFu c2NvZGluZyB3aGlsZSBzb21lIG1heQ0KIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDtsaW5lLWhl aWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjIpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gb3INCiB0aGUgd29yZGluZyDigJxjb250 ZW50IGFkYXB0YXRpb27igJ0sIGl0IHNob3VsZCBiZSBjbGFyaWZpZWQgaGVyZSB0aGF0IGl0IG1h eSBiZSB0d28ga2luZHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+T25lIGlzIG9ubHkgdGhlIHRyYW5zZm9ybWF0 aW9uIG9mIGVuY2Fwc3VsYXRpb24gZm9ybWF0LiBGb3IgZXhhbXBsZSB0aGUgSC4yNjQgc3RyZWFt IGlzIGVuY2Fwc3VsYXRlZA0KIGluIEFQUExFIGFuZCBBZG9iZSBmb3JtYXQgcmVzcGVjdGl2ZWx5 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPkkga25vdyB0aGF0IENvbWNhc3QgaGFzIGEgcHJvamVjdCB0aGF0IG5l ZWRzIHRvIHBpY2sgdGhlIEguMjY0IG1lZGlhIGZyb20gdGhlIFRTIHN0cmVhbSBhbmQgdGhlbiBl bmNhcHN1bGF0ZWQNCiB0aGVtIGludG8gZGlmZmVyZW50IGZvcm1hdHMoQVBQTEUsQWRvYmXigKYp IHRvIGRpZmZlcmVudCBkZXZpY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZvciB0aGlzIGtpbmQgb2YgdHJh bnNmb3JtYXRpb24sIHRoZSBjb21wdXRpbmcgY29zdCBpcyB2ZXJ5IHZlcnkgbG93IGFuZCBtYXkg YmUgbmVhcmx5IG5lZ2xlY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGUgb3RoZXIgaXMgdG8gdHJhbnNj b2RpbmcuJm5ic3A7IEZvciBleGFtcGxlIHRvIHN1cHBvcnQgZGlmZmVyZW50IGJpdHJhdGVzLiZu YnNwOyBTaW5jZSBlbmNvZGVyIGlzIGEgaGlnaCB2YWx1ZQ0KIGZhY2lsaXR5LCB3ZSBzaG91bGQg Y29tcGFyZSB0aGUgY2FwaXRhbCBjb3N0IG9mIGVuY29kZXIgYW5kIHRyYW5zcG9ydCBjb3N0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTgu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPkp1c3QgdGFrZSBhIHNpbXBsZSBtb2RlbDogY29udGVudCBpcyBkZWxpdmVy ZWQgZnJvbSBOb2RlIEEgdG8gTm9kZSBCLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZsdDtpbWFnZTAwMi5wbmcm Z3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+VGhlcmUgYXJlIHR3byBzb2x1dGlvbnM6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bGluZS1oZWlnaHQ6MTMu MnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4xKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QQ0KIGhhdmUgdGhlIHRyYW5zY29kZXIgYW5kIGRlbGl2 ZXIgbXVsdGktZm9ybWF0IGNvbnRlbnQgdG8gQjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O2xpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Mik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPkINCiBoYXZlIHRoZSB0cmFuc2NvZGVyOyBBIG9ubHkgZGVsaXZlcnMgb25lIGZv cm1hdCBjb250ZW50IHRvIEIgYW5kIEIgd291bGQgdHJhbnNjb2RlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZy b20gd2hvbGUgc3lzdGVtIHBvaW50IG9mIHZpZXcsIGVpdGhlciBBIG9yIEIgd291bGQgdHJhbnNj b2RlIHdoaWxlIHRoZSBiYW5kd2lkdGggd291bGQgYmUgc2F2ZWQgaW4NCiBzb2x1dGlvbiBCLiBI ZW5jZSBzb2x1dGlvbiBCIGlzIGJldHRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Ob3cgcHJvdmlkZWQgdGhl IGJhbmR3aWR0aCBpcyBwYWlkIGJ5IEIgYW5kIEIgc2hvdWxkIGRlY2lkZSB3aGV0aGVyIHRvIGlu c3RhbGwgdHJhbnNjb2Rlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4oUmljaGFyZCBoYXMgc2FpZCB0byBzZXQg dHJhbnNjb2RlciBpbiBlYWNoIGVkZ2Ugc2VydmVyKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPklmIHRoZSBjb3N0 IG9mIHJlbnRpbmcgYmFuZHdpZHRoIChmb3IgYSBmZXcgbW9udGhzKSBpcyBtb3JlIGV4cGVuc2l2 ZSB0aGFuIHRoZSBwcmljZSBvZiB0cmFuc2NvZGVyIHN1cHBvcnRpbmcNCiB0aGUgc2FtZSBiYW5k d2lkdGgsIGl0IHdvdWxkIGJlIGJldHRlciB0byBwdXQgdGhlIHRyYW5zY29kZXIgYXQgdGhlIHJl Y2VpdmVyIE5vZGUgQi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JbiBmYWN0IEkgaGF2ZSBpbnZlc3RpZ2F0ZWQg dGhpcyBpc3N1ZSBmb3IgbXVjaCB0aW1lLiBXaGlsZSBpbiBkaWZmZXJlbnQgYXJlYSB0aGUgcHJp Y2Ugb2YgYmFuZHdpZHRoDQogbWF5IGJlIGRpZmZlcmVudC4mbmJzcDsgQW5kIHRoZSB0cmFuc3Bv cnQgYnVyZGVuIGJldHdlZW4gdHdvIGRpc3RhbnQgcGxhY2VzIG9yIG92ZXIgYSBiYWQgbmF0dXJl IGVudmlyb25tZW50IHdvdWxkIGJlIG11Y2ggaGlnaGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhlcmUgdGhl IHByaWNlIGluIFVTQSBtYXkgYmUgcmVmZXJyZWQgYXM6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHA6Ly9zbWFsbGJ1c2luZXNzLnZl cml6b24uY29tL3Byb2R1Y3RzL2ludGVybmV0L2hzaS9vdmVydmlldy5hc3B4I3BsYW5zIj5odHRw Oi8vc21hbGxidXNpbmVzcy52ZXJpem9uLmNvbS9wcm9kdWN0cy9pbnRlcm5ldC9oc2kvb3ZlcnZp ZXcuYXNweCNwbGFuczwvYT4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SW4gVmVyaXpvbiwgdGhlIHBhY2thZ2Ug Zm9yIDEwLTE1bWJwcyBpcyAkOTAgcGVyIG1vbnRoIChJIGZlZWwgdGhlIGJhbmR3aWR0aCBxdWFs aXR5IGZvciBidXNpbmVzcyB3b3VsZA0KIGJlIGd1YXJhbnRlZWQpLiBJIHF1ZXJ5IHRoYXQgdGhl IGJhbmR3aWR0aCBwcmljZSBpbiBDaGluYSBtYXkgYmUgNTAlIGhpZ2hlci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5JIGRvIG5vdCBrbm93IGhvdyBtdWNoIHRoZSBwcmljZSB3aWxsIGJlIGZvciB0aGUgYmFuZHdp ZHRoIGZyb20gQW1zdGVyZGFtIHRvIFBhcmlzIChjcm9zcyBjb3VudHJ5IGluDQogdGhlIHNhbWUg Y29udGluZW50KS4mbmJzcDsgQnV0IEkgZmVlbCB0aGUgcHJpY2UgZnJvbSBOZXdZb3JrIHRvIFBh cmlzIHdvdWxkIGFic29sdXRlbHkgYmUgdmVyeSBoaWdoLiZuYnNwOyBBcyBmb3IgdGhlIEVuY29k ZXIsIGl0IGFsc28gdmFyaWVzLiBQZXJoYXBzIHRoZSBwcmljZSBpbiBDaGluYSB3aWxsIGJlIGhp Z2hlciB0aGFuIGluIFVTQS4gQW5kIGluIGZhY3QgdGhlIHByaWNlIG9mIGJhbmR3aWR0aCBhbmQg ZW5jb2RlciBkZXBlbmRzIG1vc3RseSBvbiB0aGUNCiBjb25jcmV0ZSBidXNpbmVzcyBpdGVtcy4g Rm9yIGV4YW1wbGUgdGhlIHByaWNlIHRvIEh1YXdlaSBtYXkgYmUgbG93ZXIgdGhhbiB0aGUgcHVi bGljIHByaWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJ5IG15IGN1cnJlbnQgZXZhbHVhdGlvbiBpbiBDaGlu YSBpdCBpcyBiZXR0ZXIgdXNpbmcgdGhlIHRyYW5zY29kZXIgdGhhbiByZW50aW5nIG11bHRpcGxl IHRpbWVzIGJyb2FkYmFuZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Tb21lIHBlb3BsZSBoYXZlIHRvbGQgbWUg dGhhdCBmb3IgdGhlIG9wZXJhdG9yIGhpbXNlbGYgcHJvYmFibHkgdGhlIGJhbmR3aWR0aCBjb3N0 IHdvdWxkIGJlIHZlcnkgbG93DQogaW4gdGhlIGludGVybmFsIGNhcGl0YWwgY291bnRpbmcuIEJ1 dCBmb3IgdGhlIGluZGVwZW5kZW50IENETiwgaXQgbWF5IGFub3RoZXIgdGhpbmcuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+U28sIG15IHN1Z2dlc3Rpb24gaXMgdG8gbGV0IGRpZmZlcmVudCB3YXlzIGNvLWV4aXN0 LiBJIGhhdmUgYW5ub3VuY2VkIHRoYXQgdG8gbGV0IHR3byBzaWRlcyBuZWdvdGlhdGUNCiB3aGV0 aGVyIHRvIGFzc2lnbiBkQ0ROIGZvciB0aGUgY29udGVudCBhZGFwdGF0aW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdo dDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkluIGZhY3QsIGZyb20gQ1AgdG8gQ0ROLCZuYnNwOyB0 aGVyZSBhcmUgdGhlIHJlYWwgYnVzaW5lc3NlcyB0aGF0IGVpdGhlciBsZXQgQ1AgdG8gcHJvdmlk ZSBtdWx0aS1mb3JtYXQgY29udGVudA0KIG9yIGxldCB0aGUgQ0ROIHRvIHJlY2VpdmUgb25lIGZv cm1hdCBhbmQgY29tcGxldGUgdGhlIHRyYW5zZm9ybWF0aW9uLCBkZXBlbmRpbmcgb24gdGhlIGNv bmNyZXRlIGJ1c2luZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5l LWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJ5IHRoZSBzYW1lIGxvZ2ljLCBmb3JtIHVD RE4gdG8gZENETiwgaXQgbWF5IGJlIGVpdGhlciB0aGUgdUNETiB0byBwcm92aWRlIG11bHRpLWZv cm1hdCBjb250ZW50IG9yIHRoZQ0KIGRDRE4gdG8gcmVjZWl2ZSBvbmUgZm9ybWF0IGNvbnRlbnQg YW5kIHRoZW4gY29tcGxldGUgdGhlIHRyYW5zZm9ybWF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkN1cnJl bnRseSB0aGVyZSBpcyBub3QgdGhlIHJlYWwgQ0ROLUNETiBjb25uZWN0aW9uLCBoZW5jZSB3ZSBh cmUgYmFzaW5nIG91ciBrbm93bGVkZ2Ugb24gdGhlIHJlbGF0ZWQNCiBzb2x1dGlvbiB0byBtYWtl IG91ciBzb2x1dGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bGluZS1oZWlnaHQ6MTMuMnB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4zKTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+QXMNCiBmb3IgdGhlIHByb2NlZHVyZSBvZiBjb250ZW50IGFkYXB0 YXRpb24sIEkganVzdCBkcmFmdCBhIGRpYWdyYW0gYXMgYmVsb3c6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jmx0 O2ltYWdlMDA0LnBuZyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Zb3Ug bWF5IHNlZSB0aGUgc29sdXRpb24gaXMgcmF0aGVyIGNsZWFyIGFuZCB0aGUgbWV0YWRhdGEgbmVl ZGVkIHdvdWxkIGJlIGNsZWFyIGFsc28uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+RGVhciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5CeSBteSBhbmFseXNpcyBhYm92ZSwgSSBraW5kbHkgaW52 aXRlIHlvdXIgaWRlYXMgd2hldGhlciBpdCBtYXkgYmUgYW4gYXBwbGljYWJsZSBhbmQgc2ltcGxl IHBhcnQgaW4NCiB0aGUgQ0ROSSBpdGVtLCBwcm92aWRlZCB0aGF0IHRoZSBzb2x1dGlvbiBpcyBv cGVuIHRvIHRoZSB0eXBlcyBvZiBjb250ZW50IGFkYXB0YXRpb24gYW5kIG1heSBiZSBvcHRpb25h bGx5IGltcGxlbWVudGVkIGluIHRoZSByZWFsIHNvbHV0aW9ucy9idXNpbmVzcy4gSSBmZWVsIGZv ciB0aG9zZSBvcGVyYXRvcnMgdGhhdCBuZWVkIHN1Y2ggZnVuY3Rpb25hbGl0eSBpdCB3b3VsZCBi ZSB2ZXJ5IGdvb2Qgd2hpbGUgaXQgZG9lcyBub3QgaW1wYWN0IG90aGVycw0KIHRoYXQgZG8gbm90 IGltcGxlbWVudCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+WmhpcGVu ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVy LWNvbG9yOmluaXRpYWwiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPldvdW5keSwNCiBSaWNoYXJk IDxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOlJpY2hhcmRfV291bmR5QGNhYmxlLmNvbWNhc3QuY29t XSI+W21haWx0bzpSaWNoYXJkX1dvdW5keUBjYWJsZS5jb21jYXN0LmNvbV08L2E+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9i PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5UaHVyc2Rh eSwgT2N0b2JlciAyNywgMjAxMSA3OjIzIFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5aaG91WmhpcGVuZzs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOidt YXJrQGpldC1zdHJlYW0ubmwiPidtYXJrQGpldC1zdHJlYW0ubmw8L2E+Jzs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOidhbGFu LmthdmFuYWdoQGVyaWNzc29uLmNvbSI+J2FsYW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29tPC9hPic8 YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzonY2RuaUBpZXRmLm9yZyI+J2NkbmlAaWV0Zi5vcmc8L2E+ JzsgV291bmR5LCBSaWNoYXJkPGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mZ3Q7SW4geW91ciBjb21wYW554oCZcyB3ZWJz aXRlLCBJIGp1c3QgZmluZCBzb21lIGluZm9ybWF0aW9uPGJyPg0KPGJyPg0KSSBoYXZlIHRvIHN0 ZXAgaW4gYXMgY28tY2hhaXIgaGVyZS48YnI+DQo8YnI+DQpUaGUgZ29hbCBvZiB0aGlzIFdHIGlz IG5vdCB0byBhbGlnbiB2ZW5kb3IgcHJvZHVjdCByb2FkbWFwcywgb3IgdG8gZXF1YWxpemUgYWxs IHZlbmRvciBvZmZlcmluZ3MsIG9yIHRvIHNwZWNpZnkgdGhlIGVudGlyZSBDRE5JIGVjb3N5c3Rl bS4gVGhlIGdvYWwgb2YgdGhpcyBXRyBpcyB0byBlbmFibGUgdGhlIGludGVyY29ubmVjdGlvbiBh bmQgaW50ZXJvcGVyYXRpb24gb2YgdHdvIG9yIG1vcmUgQ0ROcywgd2l0aGluIHRoZSBib3VuZHMg b2YgdGhlDQogQ0ROSSB3ZyBjaGFydGVyLjxicj4NCjxicj4NCkl0IGlzIE9LIHRvIGhhdmUgYSBk aXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgY29udGVudCBhZGFwdGF0aW9uIG5lZWRzIHRvIGJlIHBl cmZvcm1lZCBieSB0aGUgZENETiwgc2luY2UgdGhhdCBkZWNpc2lvbiBpbXBhY3RzIHRoZSB1Q0RO LWRDRE4gaW50ZXJmYWNlLiBTbyBsZXQncyBmaW5kIGEgcHJvZHVjdGl2ZSB3YXkgdG8gZGlzY3Vz cyB0aGlzIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCB0byBjbG9zZSB0aGUgZGlzY3Vzc2lvbiBi eSBJRVRGIDgyDQogKGlmIG5vdCBzb29uZXIpLjxicj4NCjxicj4NCkNhbiBzb21lb25lIGRlc2Ny aWJlIHJlYWwtbGlmZSBleGFtcGxlcyB3aGVyZSBkb3duc3RyZWFtIENETiAob3IgZWRnZSBjYWNo ZS1iYXNlZCkgY29udGVudCBhZGFwdGF0aW9uIGlzIG5lZWRlZCB0b2RheSBpbiBhIHByb2R1Y3Rp b24gZW52aXJvbm1lbnQsIG9yIHNob3J0bHk/IE5vdCBtZXJlbHkgYSBmZWF0dXJlIGluIGEgdmVu ZG9yJ3MgcHJvZHVjdCBtYXRlcmlhbHM/PGJyPg0KPGJyPg0KU3BlYWtpbmcgYXMgYW4gaW5kaXZp ZHVhbCwgSSBjYW4gZmluZCBhIGxvdCBvZiBleGFtcGxlcyB3aGVyZSBkb3duc3RyZWFtIGNvbnRl bnQgYWRhcHRhdGlvbiBpcyBub3QgbmVlZGVkLCBhbmQgYW55IGFkYXB0YXRpb24gaXMgcmVhbGx5 IHBhcnQgb2YgdGhlIENQIC0gdUNETiBpbnRlcmZhY2UgKHdoaWNoIGlzIG91dCBvZiB0aGUgc2Nv cGUgb2Ygb3VyIGNoYXJ0ZXIpLjxicj4NCjxicj4NCi0tIFJpY2g8YnI+DQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KJm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtO2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjppbml0aWFsIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb208L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+OiBaaG91WmhpcGVuZw0KPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86emhvdXpoaXBlbmdA aHVhd2VpLmNvbV0iPlttYWlsdG86emhvdXpoaXBlbmdAaHVhd2VpLmNvbV08L2E+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ8L2I+ OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSAwMzo0NSBBTTxicj4NCjxiPlRvPC9iPjogTWFy ayBkZSBKb25nICZsdDs8YSBocmVmPSJtYWlsdG86bWFya0BqZXQtc3RyZWFtLm5sIj5tYXJrQGpl dC1zdHJlYW0ubmw8L2E+Jmd0OzsgQWxhbiBLYXZhbmFnaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFs YW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29tIj5hbGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbTwvYT4m Z3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CjxiPkNjPC9iPjo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8L2E+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPiZsdDs8YSBocmVmPSJt YWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT4mZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlN1YmplY3Q8L2I+OiBS ZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5IZWxsbyBNYXJr LDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5OaWNlIHRvIG1lZXQgeW91IG9uIGxp bmUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkluIHlvdXIgY29tcGFueeKAmXMg d2Vic2l0ZSwgSSBqdXN0IGZpbmQgc29tZSBpbmZvcm1hdGlvbiB0aGF0IGFkZHJlc3NlcyDigJw8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNEM1NjVDO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5Wb2RhZm9uZQ0KIHN1YnNjcmliZXJzIGNvbXBsYWluZWQgYWJvdXQgdmlkZW8gcGVy Zm9ybWFuY2Uu4oCdPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlNlZTo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFt Lm5sL3NlYXJjaC8/c2VhcmNoPXRyYW5zY29kaW5nIj5odHRwOi8vd3d3LmpldC1zdHJlYW0ubmwv c2VhcmNoLz9zZWFyY2g9dHJhbnNjb2Rpbmc8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5EZWFyIGFsbCBp biB0aGlzIGdyb3VwLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JbiBsYXN0IGZl dyBkYXlzLCBleGNlcHQgdGhlIHB1YmxpYyBlbWFpbCBkaXNjdXNzaW9ucyBJIGhhdmUgY29udGFj dGVkIHdpdGggc29tZSBwZW9wbGUgYW5kIGRpc2N1c3NlZCB3aXRoIG15IG93biBjb2xsZWFndWVz DQogb2YgYWxsIGRldGFpbHMgb24gdGhpcyBpc3N1ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Rmlyc3QsIGFsdGhvdWdoIHRoZSBtYXJrZXQgcmVxdWlyZW1lbnQgZm9yIGl0IGlz IHZlcnkgaW1wb3J0YW50LCBJIGZlZWwgSeKAmWQgYmV0dGVyIHNob3cgdXAgbW9yZSBpbmZvcm1h dGlvbiBvbiB0aGUgcHJvY2VkdXJlDQogaW52b2x2ZWQuIEkgaGF2ZSBleHBsYWluZWQgbWFueSB0 aW1lcyB0aGF0IHRvIHN1cHBvcnQgY29udGVudCBhZGFwdGF0aW9uIGlzIHJhdGhlciBzaW1wbGUg d2hpbGUgdGhlIHdvcmRpbmcgaXMgbm90IGVub3VnaC48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+SSBhbSBidXN5IG1ha2luZyBzb21lIGNvbnRyaWJ1dGlvbnMgb24gdGhpcyBhbmQg cGxhbiB0byB1cGxvYWQgdG8gRVRTSSBtZWV0aW5nIGFuZCBJRVRGIENETkkuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJ5IHRoZXNlIHdvcmsmbmJzcDsgSSBmZWVsIHRoZSBwZW9w bGUgbWF5IGNhdGNoIGEgd2hvbGUgdmlldyBvbiB0aGlzIGlzc3VlLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5TZWNvbmQsIGZvciB0aGF0IGZ1bmN0aW9uYWxpdHksIGluIGltcGxl bWVudGF0aW9uLCBpZiBzb21lIGVudGl0eSBkb2VzIG5vdCBjaG9vc2UgdG8gc3VwcG9ydCBpdCwg aXQgbWF5IGJlIG9rLiBTaW5jZQ0KIGl0IG1heSBiZSBuZWdvdGlhdGVkIGJldHdlZW48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+IHR3byBDRE5zLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JZiBkQ0ROIGRvZXMgbm90IHN1cHBvcnQgdGhh dCwgaXQgbWF5IGJlIHRoZSB1Q0ROIHJlc3BvbnNpYmxlIHRvIGNvbXBsZXRlIHRoZSB0cmFuc2Nv ZGluZyBhbmQgZGVsaXZlciB0aGUgY29udGVudCBvZg0KIG11bHRpcGxlIGZvcm1hdHMgYW5kIHJh dGVzIHRvIGRDRE4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoaXJkLCBhbHRo b3VnaCBDRE5JIGlzIGEgbmV3IGFyY2hpdGVjdHVyZSwgd2hpbGUgdGhlIGNvbnRlbnQgb3BlcmF0 aW5nIGhhcyBiZWVuIGV4aXN0ZWQgZm9yIHllYXJzLiBBcyBJIGtub3cgdGhlIGNvbnRlbnQNCiBm cm9tIFVTQSB0byB0aGUgZG93bnN0cmVhbSBvcGVyYXRvciBpcyB0cmFuc2ZlcnJlZCBvbiBvbmUg Y29weSBhbmQgdGhlIGRvd25zdHJlYW0gb3BlcmF0b3Igd2lsbCBoYW5kbGUgdGhlIHRyYW5zY29k aW5nLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+UGVyaGFwcywgdGhlIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBt b3JlIG9uIHRoZSBtb2JpbGUgb3BlcmF0aW5nLiBCdXQgSSBmZWVsIGN1cnJlbnRseSBtb3N0IG9w ZXJhdG9yIHdpbGwgYmUgYSBhbGwgc2VydmljZQ0KIG9wZXJhdG9yLiBBbmQgZm9yIHRoZSBDRE4g cHJvdmlkZXJzLCBpdCBtYXkgYmUgYmV0dGVyIHRvIHN1cHBvcnQgYWxsIGtpbmRzIG9mIHNlcnZp Y2UuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJlc2lkZXMsIEkgbGlrZSBzYXkg dGhhdCB0aGUgdGVjaG5vbG9neSBvbiB0aGlzIHRvcGljIGhhcyBiZWVuIGZvciBtYW55IHllYXJz IGFuZCBoYXMgYmVlbiByYXRoZXIgbWF0dXJlLCBldmVuIHNvbWUNCiBpdGVtcyBpbiBpZXRmIHN1 Y2ggYXMgcmZjMzUwNzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj4gaWNhcC4gU28gZnJvbSB0aGUgdGVjaG5pcXVlIHBvaW50IG9mIHZpZXcsIGl0IGlzIGEg bmF0dXJlIGFjdGlvbiB0byBiZSBpbnZvbHZlZCBpbiBDRE4gaW50ZXJjb25uZWN0aW9uLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFua3MuPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPlpoaXBlbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbTtib3JkZXItd2lkdGg6aW5pdGlhbDtib3JkZXItY29sb3I6aW5p dGlhbCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4m bmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+TWFyaw0KIGRlIEpvbmcgPGEgaHJlZj0ibWFp bHRvOlttYWlsdG86bWFya0BqZXQtc3RyZWFtLm5sXSI+W21haWx0bzptYXJrQGpldC1zdHJlYW0u bmxdPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+VGh1cnNkYXksIE9jdG9iZXIgMjcsIDIwMTEgNDoyMSBBTTxicj4NCjxiPlRvOjwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QWxhbiBL YXZhbmFnaDxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+QmVuIE5pdmVuLUplbmtpbnM7IFpob3VaaGlwZW5nOzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y2Ru aUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtDRE5pXSBJLUQg QWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+SGkgQWxhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5BcyBCZW4g c3RhdGVkIHRoZSBvdmVyYWxsIGRpc2N1c3Npb24gcmlnaHQgbm93IGlzIGFib3V0IGRlbGl2ZXJ5 LCBub3Qgb24gYWRhcHRhdGlvbi4gSXQgaXMgaGFyZCBlbm91Z2ggdG8gZ2V0IGNvbnNlbnN1cyBv biB0aGUgZGVsaXZlcnkgYXNwZWN0IGFscmVhZHkNCiBub3QgdG8gbWVudGlvbiB5b3VyIHJlcXVp cmVtZW50IGZyb20gY29udGVudCBhZGFwdGF0aW9uIGFkZGVkIHRvIHRoYXQsIHNvIEkgYWdyZWUg d2l0aCBCZW4gd2Ugc2hvdWxkIHN0aWNrIHdpdGggdGhlIGRlbGl2ZXJ5IGFzcGVjdCBmb3IgdGhl IGZpcnN0IHNwZWNzLiZuYnNwO0kgY2FuIGltYWdpbmUgdGhpcyBjb3VsZCBiZSBhIGRpc2N1c3Np b24gbGF0ZXIgb24gYnV0IHBsZWFzZSBsZXQgdXMga2VlcCB0aGUgc2NvcGUgb2YgdGhpcyBiZSBj bGVhbiBhbmQNCiB0cmFuc3BhcmVudC4gSXQgaXMgb2YgYmVuZWZpdCBvZiBldmVyeW9uZSB0byBn ZXQgdGhlIGZpcnN0IHNwZWNzIGFzIGZhc3QgYXMgcG9zc2libGUuIFRoYW5rcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5NZXQg dnJpZW5kZWxpamtlIGdyb2V0LDwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNs YXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPktpbmQgcmVnYXJk cyw8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KPGJyPg0KPHNwYW4g Y2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPk1hcmsgZGUgSm9uZzwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+SW50ZXJuYXRpb25hbCBCdXNpbmVzcyBEZXZlbG9wZXI8 L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPkpldC1TdHJlYW0gQlY8 L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPkUtbWFpbDo8 L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48YSBocmVmPSJtYWlsdG86bWFya0BqZXQtc3Ry ZWFtLmNvbSI+bWFya0BqZXQtc3RyZWFtLmNvbTwvYT48L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9 ImFwcGxlLXN0eWxlLXNwYW4iPk9mZmljZTogJiM0MzszMSAoMCk1MCA1MjYxODIwPC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5Nb2JpbGU6ICYjNDM7MzEgKDApNiA4 MTEwODI2Mzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+RmF4OiAm IzQzOzMxICgwKTUwIDUyNjQyMTQ8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tIEV2ZW50Ojwvc3Bh bj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5 bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5NZWV0DQogdXMgYXQgU3RyZWFtaW5nIE1l ZGlhIEV1cm9wZSwgMTctMTggT2N0b2JlciwgTG9uZG9uLCBVSzwvc3Bhbj48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4tIEV2ZW50Ojwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwO01lZXQNCiB1cyBh dCBPbmxpbmUgVmlkZW8gU3RyYXRlZ2llcywgMTkgT2N0b2JlciwgTG9uZG9uLCBVSzwvc3Bhbj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3Bh biI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tIEV2ZW50Ojwvc3Bhbj48L2I+PC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNw O01lZXQNCiB1cyBhdCBDRE4gV29ybGQgU3VtbWl0LCAyNS0yOCBPY3RvYmVyLCBMb25kb24sIFVL PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1z dHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi08L3NwYW4+PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5OZXdzOjwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1z dHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwO1ByZS1yZXF1ZXN0DQogeW91 ciBUZWNobm9sb2d5IFdoaXRlcGFwZXIgbm93IGFuZCBiZSB0aGUgZmlyc3QgdG8gaGF2ZSBpdCwg Y2hlY2s8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBw bGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YSBocmVmPSJodHRwOi8vd3d3 LmpldC1zdHJlYW0uY29tIj53d3cuamV0LXN0cmVhbS5jb208L2E+PC9zcGFuPjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+LSZuYnNwOzxiPk5ld3M6Jm5ic3A7PC9iPkNoZWNrJm5ic3A7PGEgaHJlZj0iaHR0 cDovL3d3dy5qZXQtc3RyZWFtLmNvbSI+aHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbTwvYT48L3Nw YW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUt c3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj50bw0KIGRvd25sb2FkIG91ciAnU2l4IFRyZW5k cyBpbiBDRE5zJyBicm9jaHVyZTwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj4tPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QmxvZzo8L3Nw YW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxhIGhyZWY9Imh0dHA6Ly93 d3cuamV0LXN0cmVhbS5jb20vYmxvZy8iPnd3dy5qZXQtc3RyZWFtLmNvbS9ibG9nLzwvYT48L3Nw YW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+VmlkZW9FeGNoYW5nZTo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48L2I+ PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPjxhIGhyZWY9Imh0dHA6Ly93d3cudmRvLXgubmV0Ij53d3cudmRvLXgubmV0PC9hPjwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi08L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5TdHJlYW16aWxsYTo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48L2I+PC9z cGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PjxhIGhyZWY9Imh0dHA6Ly93d3cuc3RyZWFtemlsbGFjZG4uY29tIj53d3cuc3RyZWFtemlsbGFj ZG4uY29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBs ZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi08L3NwYW4+PC9zcGFuPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5Db3Jwb3JhdGU6PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPjxhIGhyZWY9Imh0dHA6Ly93d3cuamV0LXN0cmVhbS5jb20iPnd3dy5qZXQtc3RyZWFt LmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk9uIDI2LCBPY3QsMjAxMSwgYXQgODozMyBQ TSwgQWxhbiBLYXZhbmFnaCB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJlbjxicj4NCjxicj4NCkltIGFzc3VtaW5nIHRoZW4g YmFzZWQgb24geW91ciBjb21tZW50cyBiZWxvdyBhcmUgeW91IHN1Z2dlc3Rpbmcgd2UgYXJlIGdv aW5nIHRvIGhhdmUgYSBudW1iZXIgb2YgdmVyc2lvbnMgb2YgdGhlIENETi1JIE1ldGFkYXRhPzxi cj4NCjxicj4NCkkgc3ltcGF0aGlzZSB3aXRoIHdoYXQgeW91IGFyZSBwb2ludGluZyBvdXQgYmVs b3cgYW5kIGRvIGFncmVlIHRoYXQgdGhlcmUgaXMgc29tZSB3b3JrIHRvIGJlIGRvbmUsIGJ1dCBJ IHN0aWxsIGZlZWwgdGhhdCBjb250ZW50IGFkYXB0YXRpb24gaXMgdG8gbWUgYSBmdW5kYW1lbnRh bCByZXF1aXJlbWVudCB0byB3aGF0IGNvbGxlY3RpdmVseSB3ZSBzaG91bGQgYWRkcmVzcyBpbiB0 aGUgQ0ROLUkgV0cuIEkgZG8gYWdyZWUgd2l0aCB5b3UgdGhhdCBjb250ZW50DQogYWRhcHRhdGlv biBpcyBhbiBvcHRpbWl6YXRpb24gYmV0d2VlbiBDRE4ncyBidXQgaXQncyBhIHZlcnkgaW1wb3J0 YW50IG9uZSB0aGF0IEkga25vdyBOZXR3b3JrIFNlcnZpY2UgUHJvdmlkZXJzIHBhcnRpY3VsYXJs eSByZXF1aXJlLjxicj4NCjxicj4NCkFsYW48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLTxicj4NCkZyb206PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmciPmNkbmktYm91 bmNlc0BpZXRmLm9yZzwvYT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOlttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSI+ W21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddPC9hPiBPbiBCZWhhbGYgT2YgQmVuDQogTml2 ZW4tSmVua2luczxicj4NClNlbnQ6IE9jdG9iZXItMTItMTEgMToxMyBQTTxicj4NClRvOiBaaG91 WmhpcGVuZzxicj4NCkNjOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48 YnI+DQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2Ut Y2FzZXMtMDAudHh0PGJyPg0KPGJyPg0KWmhpcGVuZyw8YnI+DQo8YnI+DQpPbiAxMiBPY3QgMjAx MSwgYXQgMTA6MjIsIFpob3VaaGlwZW5nIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SGVsbG8gQmVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZSBVRSBtYXkgc2VsZWN0IHRo ZSBjb250ZW50IGZvcm1hdCBvbiB0aGUgQ1Agd2ViLiBBZnRlciB0aGF0IHRoZSB1c2VyIG9ubHkg ZGVzaXJlcyB0byBnZXQgaGlzIHNlbGVjdGVkIGNvbnRlbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QnV0 IGhvdyB0aGUgY29udGVudCBpcyB0cmFuc2ZlcnJlZCB0byB0aGUgY2xpZW50IGlzIG5vdCB3b3Jy aWVkIGJ5IHRoZSB1c2VyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZSBDUCBtYXkgY3JlYXRlIGEgc3Bl Y2lhbCBmb3JtYXQgYXMgcmVxdWlyZWQgYnkgdGhlIHVzZXIgYW5kIGFzayB0aGUgQ0ROIHRvIGRl bGl2ZXIgdG8gdXNlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5XaGlsZSBDUCBtYXkgZ2l2ZSBhIEhEIGZv cm1hdCBjb250ZW50IHRvIHVDRE4gYW5kIHRoZSBkQ0ROIG1heSB0aGVuIHRyYW5zZm9ybSB0byB0 aGUgZm9ybWF0IGFzIHRoZSB1c2VyIHNlbGVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxicj4NCkxvdHMgb2YgdGhpbmdzIG1heSBiZSBwb3NzaWJsZSB0byBkbyBhbmQg Q0ROIHByb3ZpZGVycyBvZmZlciBtYW55IGFkZGl0aW9uYWwgc2VydmljZXMgb24gdG9wIG9mIHRo ZSAmcXVvdDtjb3JlJnF1b3Q7IHNlcnZpY2Ugb2YgY29udGVudCBkZWxpdmVyeS4gSG93ZXZlciwg b3VyIG9iamVjdGl2ZSAoYmFzZWQgb24gbXkgaW50ZXJwcmV0YXRpb24gb2YgdGhlIENETkkgY2hh cnRlcikgaXMgdG8gZm9jdXMgb24gd2hhdCBpcyBuZWNlc3NhcnkgdG8gaW50ZXJjb25uZWN0DQog Q0ROcyB0byBkZWxpdmVyIGNvbnRlbnQgZnJvbSBhIENTUCB0byBhbiBFbmQgVXNlciB0aGF0IGlz IHRhcmdldGVkIGFuZCBkZXBsb3lhYmxlIHdpdGhpbiBhIHNob3J0IHRpbWUgZnJhbWUgKDE4LTI0 IG1vbnRocykuPGJyPg0KPGJyPg0KQ29udGVudCB0cmFuc2Zvcm1hdGlvbi9hZGFwdGF0aW9uIGlz IG5vdCBhbiBlc3NlbnRpYWwgcmVxdWlyZW1lbnQgaW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGF0IGFp bSAod2UgY2FuIGRlbGl2ZXIgY29udGVudCBmcm9tIENTUHMgdG8gRW5kIFVzZXJzIHZpYSBtdWx0 aXBsZSBDRE5zIHdpdGhvdXQgbmVlZGluZyBvciByZXF1aXJpbmcgYW55IENETiBzdXBwb3J0cyBj b250ZW50IGFkYXB0YXRpb24pLjxicj4NCjxicj4NCkluIG15IG9waW5pb24gd2UgaGF2ZSBlbm91 Z2ggd29yayB0byBkbyBhbHJlYWR5IHdpdGhvdXQgdHJ5aW5nIHRvIGV4cGFuZCB0aGUgc2NvcGUg b2Ygb3VyIHdvcmsgdG8gaW5jbHVkZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB0aGF0IGRvIG5v dCBoZWxwIHVzIGFkZHJlc3Mgb3VyIGNvcmUgb2JqZWN0aXZlcyBhcyBsYWlkIG91dCBpbiB0aGUg Q0ROSSBjaGFydGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+SW4gdGhpcyBjYXNlLCBpdCBpcyBub3RoaW5nIHJlbGF0ZWQgdG8gaG93IHRoZSB1c2Vy IHNlbGVjdCBmb3JtYXRzIG9uIENQIHdlYnNpdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+U28sIGl0IGlzIHRoZSBDUCBhbmQgdXNl ciB0byBkZWNpZGUgdGhlIGNvbnRlbnQgZm9ybWF0IG5vdCB0aGUgQ0ROKHlvdXIgYXNzZXJ0IGlz IG5vdCBjb3JyZWN0IGFuZCBzZWVtcyB5b3UgdGFrZSB0aGF0IGFzc2VydCBhcyB5b3VyIGJhc2Ug Zm9yIHRoZQ0KIGRpc2N1c3Npb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPkFzIGZvciAmcXVvdDt0aGUgY29yZSBDRE4gZnVuY3Rpb25hbGl0eSBvZmZlcmVkIGJ5 IENETnMgdG9kYXkmcXVvdDssIEkgaGF2ZSBldmVyIHJhaXNlZCBhbiBlbWFpbCBiZWZvcmUgdGhh dCB5b3VyIGNvbXBhbnkncyB3ZWJwYWdlIGhhcyBjbGFpbWVkIHN1cHBvcnRpbmcNCiBtZWRpYSB0 cmFuc2Zvcm1hdGlvbiBhbmQgbXVsdGktc2NyZWVuIHNlcnZpY2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ UGVyaGFwcywgSSBsaWtlIGFza2luZyB5b3UgbGlzdCBzb21lIGZlYXR1cmVzIHRoYXQgeW91IGZl ZWwgYXJlIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdGllcyBieSBleGlzdGluZyBtYWluIHN0cmVhbSBD RE5zLiBUaHVzIHdlIG1heSBjb21wYXJlIGFuZCB0YWtlDQogZGVlcCBsb29rLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KSSB0aGluayB0aGUgY29yZSBmdW5jdGlv bmFsaXR5IG1hcHMgcHJldHR5IHdlbGwgdG8gdGhlIENETkkgaW50ZXJmYWNlcywgbmFtZWx5OiBS ZXF1ZXN0IFJvdXRpbmcsIE1ldGFkYXRhIGNvbmZpZ3VyYXRpb24sIGxvZyBwcm9kdWN0aW9uIGFu ZCBjb250cm9sIHBsdXMgY29udGVudCBhY3F1aXNpdGlvbiBhbmQgY29udGVudCBkZWxpdmVyeS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkgZ3Vlc3Mg bWFueSBwZW9wbGUgaGF2ZSB0aGUgZXhwZXJpZW5jZS9rbm93bGVkZ2Ugb2YgY29udGVudCByZWxh dGVkIHNlcnZpY2UuIFRoZSB1c2VyIGFuZCBDUCBvbmx5IGNhcmUgd2hldGhlciB0aGUgQ0ROIHBy b3ZpZGVycyBtYXkgc2F0aXNmeSB0aGVpcg0KIHJlcXVpcmVtZW50IHdoaWxlIG5vdCBjYXJlIHRo ZSBpbnRlcm5hbCBwcm9jZXNzLiBKdXN0IGFzIEdTTS9QU1ROIGludGVyY29ubmVjdGlvbiwgdGhl IHVzZXIgb25seSBjYXJlIHN1Y2Nlc3NmdWwgaW50ZXJjb25uZWN0aW9uIHdoaWxlIG5vdCBjYXJl IGhvdyB0aGUgdm9pY2UgaXMgdHJhbnNmb3JtZWQgaW4gcHJvY2Vzcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5CZXNpZGVzLCBJIGxpa2UgcmFpc2UgYSBjYXNlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PkdpdmVuIGN1cnJlbnRseSBCQkMgcmVjcnVpdHMgQ0ROIHByb3ZpZGVycyB0aGF0IG1heSBzdXBw b3J0IDEwIG1lZGlhIGZvcm1hdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+T25lIGNhbmRpZGF0ZSBpcyB5 b3VyIGNvbXBhbnksIGFub3RoZXIgaXMgQ0ROLVguIFRoZSB1c2VycyBhcmUgbG9jYXRlZCBpbiBG cmFuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+U28gYm90aCB5b3VyIGNvbXBhbnkgYW5kIENETi1YIHNo b3VsZCBjb25uZWN0IGEgRnJhbmNlIENETiBwcm92aWRlcihDRE4tWSkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+SWYgeW91ciBjb21wYW55J3Mgc29sdXRpb24gaXMgdG8gc2VuZCAxMCBzdHJlYW1zIG9mIGRp ZmZlcmVudCBmb3JtYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5vZiBvbmUgY29udGVudCB0byBDRE4tWTsg V2hpbGUgQ0ROLVgncyBzb2x1dGlvbiBpcyB0byBzZW5kIDEgc3RyZWFtIHRvIENETi1ZIHdoaWxl IENETi1ZIG1heSBjb25kdWN0IHNvbWUgYWRhcHRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Db21w YXJpbmcgdGhlc2UgdHdvIHNvbHV0aW9ucywgZm9yIHlvdXIgY29tcGFueSBhbmQgQ0ROLVgsIGFi c29sdXRlbHkgdGhlIGNvc3Qgb2YgQ0ROLVggaXMgbXVjaCBsb3dlci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5Gb3IgQ0ROLVksIGluIHNvbHV0aW9uLTEsIGl0IHNob3VsZCByZWNlaXZlL2ZvcndhcmQgMTAg c3RyZWFtcyA7IHdoaWxlIGluIHNvbHV0aW9uLTIsIGl0IHNob3VsZCBvbmx5IHJlY2VpdmUgMSBz dHJlYW0gYnV0IG5lZWQgdG8gdGFrZSB0cmFuc2Zvcm1hdGlvbg0KIHRvIG91dHB1dCAxMCBzdHJl YW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPldoaWNoIHNvbHV0 aW9uIGlzIG1vcmUgY29tcGV0aXRpdmUuIGl0IGlzIFNvbHV0aW9uIDEsIHJpZ2h0LiBSZW1lbWJl ciB0aGUgcHJpY2UgZnJvbSBCQkMgaXMgc2FtZSB0byBib3RoIHlvdXIgY29tcGFueSBhbmQgQ0RO LVggb3IgQkJDIHdvdWxkIHNlbGVjdA0KIG9uZSBDRE4gcHJvdmlkZXIgd2l0aCB0aGUgbG93ZXIg cHJpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWYgYSBDRE4gcHJvdmlkZXIgbWF5IG5vdCBnZXQgdGhl IGNvbnRyYWN0IGZyb20gQ1AsIGhvdyBpdCBtYXkgc2F5IGl0IGlzIG5vdCBhIGNvcmUgZnVuY3Rp b25hbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxicj4NCldoYXQg eW91IGFyZSBkZXNjcmliaW5nIGlzIGEgcG9zc2libGUgb3B0aW1pemF0aW9uIHRoYXQgYSBwYXJ0 aWN1bGFyIENETiBtYXkgd2lzaCB0byBpbXBsZW1lbnQgbm90IGEgY29yZSBmdW5jdGlvbmFsaXR5 IHJlcXVpcmVkIHRvIGVuYWJsZSBjb250ZW50IGRlbGl2ZXJ5IGJldHdlZW4gaW50ZXJjb25uZWN0 ZWQgQ0ROcy4gSSBjYW4gdGhpbmsgb2YgbWFueSBvcHRpbWl6YXRpb25zIHRoYXQgYSBDRE4gY291 bGQgaW1wbGVtZW50IHRvIGRpZmZlcmVudGlhdGUNCiB0aGVpciBzZXJ2aWNlIGJ1dCB0aGUgaW50 ZXJuYWwgd29ya2luZ3Mgb2YgYW4gaW5kaXZpZHVhbCBDRE4gYXJlIG91dCBvZiBzY29wZSBvZiBv dXIgY2hhcnRlci48YnI+DQo8YnI+DQpTbyB0byByZXBlYXQgbXkgcG9zaXRpb24gZm9yIGEgZmlu YWwgdGltZTogQ29udGVudCBhZGFwdGF0aW9uIGlzIG5vdCBhIGNvcmUgZnVuY3Rpb24gcmVxdWly ZWQgdG8gZW5hYmxlIGNvbnRlbnQgZGVsaXZlcnkgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5z IGFuZCB0aGVyZWZvcmUgZ2l2ZW4gdGhlIHdvcmtsb2FkIHdlIGFscmVhZHkgaGF2ZSB0byBzcGVj aWZ5IHNvbHV0aW9ucyB0aGF0IGRvIGFkZHJlc3MgdGhlIGNvcmUgZnVuY3Rpb25hbGl0eQ0KIHJl cXVpcmVkIHRvIGludGVyY29ubmVjdCBDRE5zIEkgZG8gbm90IHRoaW5rIHdlIHNob3VsZCBiZSB0 cnlpbmcgdG8gYWRkIG1vcmUgd29yayBpbnRvIHRoYXQgd29ya2xvYWQgYXMgaXQgd2lsbCBvbmx5 IGRpc3RyYWN0IHVzIGZyb20gYWNoaWV2aW5nIG91ciBnb2FsIG9mIHByb2R1Y2luZyBkZXBsb3lh YmxlIHNvbHV0aW9ucyB3aXRoaW4gdGhlIHRpbWVmcmFtZSB3ZSBhcmUgYmVpbmcgdG9sZCBieSBv cGVyYXRvcnMgdGhleSBuZWVkcyBzb2x1dGlvbnMNCiB3aXRoaW4uPGJyPg0KPGJyPg0KQmVuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5TbywgaWYgd2Ug YWxsIHJlYWxpemUgdGhhdCBjdXJyZW50bHkgdGhlIG1lZGlhIHR5cGUgaXMgcmljaCwgdGhlIENE TiBwcm92aWRlcnMgc2hvdWxkIHN1cnZpdmUgaW4gdGhlIGV4aXN0aW5nIGVjb3N5c3RlbSBhbmQg c3VwcG9ydCB0aGUgbWVkaWEgdHlwZXMNCiBhcyByZXF1aXJlZCBieSB0aGUgbWFya2V0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkJhY2sgdG8gdGhlIGNhc2Ugb2YgR1NNL0cuNzExLCBpdCBq dXN0IHdoZW4gY29uY2VybmluZyB0aGUgaW50ZXJjb25uZWN0aW9uLCB0aGUgdHJhbnNmb3JtYXRp b24gc2hvdWxkIGF0IG9uY2UgYmUgc29sdmVkLiBPdGhlcndpc2UgdGhlIGludGVyY29ubmVjdGlv bg0KIG1heSBub3QgYmUgb3BlcmF0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+QnIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTogQmVuIE5pdmVuLUplbmtpbnMNCjxhIGhyZWY9 Im1haWx0bzpbbWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrXSI+W21haWx0bzpiZW5Abml2 ZW4tamVua2lucy5jby51a108L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+U2VudDogV2VkbmVzZGF5LCBP Y3RvYmVyIDEyLCAyMDExIDEyOjE5IEFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VG86IFpob3VaaGlwZW5n PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20iPnBoaWxp cC5lYXJkbGV5QGJ0LmNvbTwvYT47PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5aaGlwZW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPk9uIDExIE9jdCAyMDExLCBhdCAwNToxNiwgWmhvdVpoaXBlbmcgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5CZW4gYW5kIFBoaWxpcCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkgbGlrZSB0byByZXNwb25kIHlvdXIgY29u Y2VybiBpbiB0aGlzIG9uZSBlbWFpbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QmVuLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SSBmZWVsIHdoYXQgd2UgYXJlIG5vdyBkaXNjdXNzaW5n IGlzIHdoYXQgaXMgdGhlICZxdW90O2NvcmUmcXVvdDsgZnVuY3Rpb24gb2YgQ0ROLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QXMgeW91IHNheSwgQ0ROIGlzIHVzZWQgdG8gZGVs aXZlciBjb250ZW50LiBUaGF0IGlzIGFic29sdXRlbHkgY29ycmVjdCB0aGF0IHRoZSBkZWxpdmVy eSBjYXBhYmlsaXR5IGlzIHRoZSBjb3JlIHJlcXVpcmVtZW50IGZvciBDRE4gc3lzdGVtLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+V2hpbGUgQ0ROIGlzIHVzZWQgdG8gcHJvdmlk ZSB0aGUgY29udGVudCBkZWxpdmVyeSBzZXJ2aWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+V2hhdCBtZWFucyBzZXJ2aWNlLiBJdCBzaG91bGQgaW5jbHVkZSAmcXVvdDt0aW1l JnF1b3Q7ICZxdW90O2xvY2F0aW9uJnF1b3Q7IGFuZCAmcXVvdDttZWRpYSB0eXBlJnF1b3Q7LCBl dGMuIFRoZXNlIGZlYXR1cmVzIGFyZSBhbGwgdGhlIGNvcmUgZmVhdHVyZSBmb3IgYSBzZXJ2aWNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWYgd2Ugb25seSBjb25jZXJuICZx dW90O2RlbGl2ZXJpbmcgb25lIGRhdGEgYmxvY2smcXVvdDssIEkgYW0gbm90IHN1cmUgd2hldGhl ciB0aGUgaXNzdWVzIHN1Y2ggYXMgJnF1b3Q7bG9nZ2luZyZxdW90OyAmcXVvdDtnZW9ncmFwaGlj IGNvbnN0cmFpbnQmcXVvdDsgYXJlIHRoZSBjb3JlIG9mIENETi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ Rm9yICZxdW90O3dpdGhvdXQgZXhwbGljaXQga25vd2xlZGdlIG9mIHdoYXQgdGhhdCBjb250ZW50 IGFjdHVhbGx5IGlzICZxdW90OywgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSB3b3JkaW5nIGlz IGFjY3VyYXRlIHNpbmNlIGdlbmVyYWxseSBhIENETiBtYXkgY2xhaW0NCiBpdCBzdXBwb3J0IGRp ZmZlcmVudCBtZWRpYXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5CeSB0aGlz IG9wcG9ydHVuaXR5LCBJIGxpa2UgdG8gc2hhcmUgYSB1c2UgY2FzZTogYSBjYWxsIGZyb20gYSBH U00gcGhvbmUgdG8gYSBQU1ROIHRlbGVwaG9uZSwgdGhlIHZvaWNlIHN0cmVhbSBzaG91bGQgYmUg dHJhbnNmb3JtZWQgZnJvbSBHU00gdm9pY2UNCiB0byBHLjcxMS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPkZvciB0aGUgdXNlciwgaGUgZG9lcyBub3QgbmVlZCB0byBrbm93IHdo YXQgdHlwZSBvZiBkYXRhIGhhcyBiZWVuIHRyYW5zZmVycmVkLCBidXQgdGhlIG9wZXJhdG9yIGhh cyBkb25lIHNvbWUgd29yayB0byBpbnRlcmNvbm5lY3QgdHdvIHN5c3RlbXMsDQogcmlnaHQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JIGxpa2UgdG8ga25vdyB3aGV0aGVyIHlv dSBtYXkgYWNjZXB0IHRoYXQgbXkgdXNlIGNhc2UgaXMgc2ltaWxhciB0byB0aGlzIGNhc2UgYWJv dmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+SSBkb24ndCB0aGluayB5b3VyIHVzZSBjYXNlIGlzIHNpbWlsYXIgdG8gdGhlIGFuYWxvZ3kg b2YgbW9iaWxlIG5ldHdvcmtzIGJlaW5nIGludGVyY29ubmVjdGVkIHRvIFBTVE4gbmV0d29ya3Mu IEluIHRoZSBjYXNlIG9mIGNvbnRlbnQgZGVsaXZlcnkNCiB0aGUgbmVnb3RpYXRpb24gaXMgZG9u ZSBiZXR3ZWVuIHRoZSBVc2VyL0NsaWVudCBhbmQgdGhlIENvbnRlbnQgUHJvdmlkZXIgYW5kIHRo ZSBDRE4gaXMganVzdCB1c2VkIHRvIGV4ZWN1dGUvcGVyZm9ybSB0aGUgZGVsaXZlcnkgdGhhdCBo YXMgYmVlbiBuZWdvdGlhdGVkLiBUaGUgQ0ROIGlzIG5vdCBpbnZvbHZlZCBpbiB0aGUgZGVjaXNp b24gbWFraW5nIG9mIHdoYXQgcmVwcmVzZW50YXRpb25zIHRoZSBDb250ZW50IFByb3ZpZGVyIGRl Y2lkZXMNCiB0byBvZmZlciB0byB0aGUgVXNlci9DbGllbnQgb3IgaW4gd2hhdCByZXByZXNlbnRh dGlvbnMgdGhlIFVzZXIvQ2xpZW50IGRlY2lkZXMgdG8gcmVxdWVzdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkFzIGZvciB5b3Ugc2FpZCBzZWxlY3RpbmcgbWVk aWEgYnkgdGhlICZxdW90O3BvcnRhbCZxdW90OywgeW91IG1heSBzZWUgdGhlIHdheSAmcXVvdDsg dUNETiBkZWxpdmVycyBtdWx0aXBsZSBtZWRpYSBzdHJlYW1zIHRvIGRDRE4mcXVvdDsgaXMgbm90 IGdvb2QgdGhhbiAmcXVvdDt1Q0ROIGRlbGl2ZXJzDQogb25lIG1lZGlhIHN0cmVhbSB0byBkQ0RO IGFuZCBkQ0ROIHRha2VzIHNvbWUgYWRhcHRhdGlvbiB0byBzdXBwb3J0IG11bHRpcGxlIG1lZGlh IHR5cGVzJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPk5vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0IGlzIGFuIG9wdGltaXNh dGlvbiwgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBhY3R1YWxseSBkZWxpdmVyIHRo ZSBjb250ZW50IChhbmQgcmVwb3J0LCBiaWxsLCBldGMuIGZvciB0aGF0DQogZGVsaXZlcnkpLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk15IHBvc2l0aW9uIGlzIHRo YXQgd2Ugc2hvdWxkIGZvY3VzIG9uIGhvdyB0byBlbmFibGUgdGhlIGludGVyY29ubmVjdGlvbiBv ZiB0aGUgY29yZSBDRE4gZnVuY3Rpb25hbGl0eSBvZmZlcmVkIGJ5IENETnMgdG9kYXkgKHdoaWNo IGlzIGFsc28gbXkgaW50ZXJwcmV0YXRpb24NCiBvZiB0aGUgc2NvcGUgb2YgdGhlIENETkkgd29y a2luZyBncm91cCBhcyBleHByZXNzZWQgaW4gaXRzIGNoYXJ0ZXIpIGJlY2F1c2UgZG9pbmcgc28g aXMgYSBzaWduaWZpY2FudCBwaWVjZSBvZiB3b3JrIGluIGl0c2VsZi4gTGV0J3Mgbm90IHN0YXJ0 IHRyeWluZyB0byBhZGQgaW4gYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGJleW9uZCB3aGF0IHRo ZSBtYWpvcml0eSBvZiBDRE5zIHN1cHBvcnQgdG9kYXkgYXMgdGhhdCB3aWxsIGp1c3QgZGVsYXkN CiB1cyBnZXR0aW5nIHVzYWJsZSBzcGVjaWZpY2F0aW9ucyBpbnRvIHRoZSBtYXJrZXQgaW4gYSB0 aW1lbHkgZmFzaGlvbiBJTU8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+QmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5BIGdvb2Qg cXVlc3Rpb24gaXMgJnF1b3Q7c2VjdXJpdHkmcXVvdDsgc2luY2UgSSBoYXZlIGRvbmUgc2l4IHll YXJzIG9uIHRoZSBEUk08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmFuZCBsaWtl IHRvIHByb21vdGUgdGhlIERSTSBhbGwgYXJvdW5kIHRoZSB3b3JsZDopIElmIHRoZSBjb250ZW50 IGlzIG5lZWRlZCB0byBiZSBwcm90ZWN0ZWQsIGdlbmVyYWxseSB5b3UgbWF5IGtub3cgYWxsIHRo ZSBzeXN0ZW1zIHNob3VsZCBiZSBncmFudGVkDQogYnkgdGhlIGNvbnRlbnQgb3duZXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5IZXJlIEkgYWxzbyBsaWtlIHRvIGNsYXJpZnkg dGhhdCBub3Qgb25seSB0aGUgbWVkaWEgaXRzZWxmIGJ1dCB0aGUgaW5mb3JtYXRpb24gcmVsYXRl ZCB0byBzZXJ2aWNlIGl0c2VsZiAoc3VjaCBhcyB0aGUgZ2VvZ3JhcGhpYyBjb25zdHJhaW50KSBz aG91bGQNCiBiZSBwcm90ZWN0ZWQgYWxzby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPlNvLCB0cnVzdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgbWVkaWEuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPlBoaWxpcCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoYW5rIHlv dSB0aGF0IHlvdSBmZWVsIENvbnRlbnQgQWRhcHRpb24gaXMgYW4gaXNzdWUgZm9yICZxdW90O1Jl cXVpcmVtZW50cyZxdW90OyBidXQgSSBkbyBub3Qga25vdyB3aHkgaXQgaXMgbm90IGZvciBVc2Ug Y2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkgbGlrZSB0byBjbGFyaWZ5 IHRvIFUgdGhhdCBpdCBpcyBpbXBvcnRhbnQgZm9yIHlvdSBvcGVyYXRvciBzaW5jZSBpdCBtYXkg c2F2ZSBpbnZlc3RtZW50IGlmIHRoZSBzeXN0ZW0gbWF5IHN1cHBvcnQgZGlmZmVyZW50IHNlcnZp Y2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Rm9yIHVzIHZlbmRvciwgd2Ug YXJlIGhhcHB5IG9wZXJhdG9yIG1heSBpbnN0YWxsIGEgc3lzdGVtIGZvciB0aGUgbW9iaWxlIHNl cnZpY2UgYW5kIGFub3RoZXIgc3lzdGVtIGZvciB0aGUgRkJCIHNlcnZpY2UuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5CdXQgdGhlIHJlYWxpdHkgaXMgYWxsIG9wZXJhdG9ycyBh c2sgdXMgdG8gcHJvdmlkZSBhIHN5c3RlbSB0aGF0IG1heSBzdXBwb3J0IGRpZmZlcmVudCBzZXJ2 aWNlIHN5c3RlbXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyYW5rbHksIEJlbiBhbmQgUGhpbGlwLCBJ IHJlbWVtYmVyIEkgaGF2ZSBleHBsYWluZWQgc29tZXdoZXJlIHRoYXQgdG8gaW1wbGVtZW50IHRo aXMgaXMgcmF0aGVyIHNpbXBsZSAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5B dCBsZWFzdCB0aGUgVXNlIGNhc2UgYW5kIFJlcXVpcmVtZW50IGFyZSBpbmZvcm1hdGlvbmFsIHRv IGJlIHJlZmVycmVkIGluIGZ1dHVyZSB3b3JrLiBTbyBJIGRvIHJlYWxseSBmZWVsIHlvdSBtYXkg YWNjZXB0IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+T2YgY291cnNlIEkg bGlrZSB0byByZXNwb25kIHlvdXIgbW9yZSBjb25jZXJuIGFuZCBjb21tZW50cy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tIj5waGlsaXAuZWFyZGxl eUBidC5jb208L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbV0iPlttYWls dG86cGhpbGlwLmVhcmRsZXlAYnQuY29tXTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPlNlbnQ6IE1vbmRheSwgT2N0b2JlciAxMCwgMjAxMSAxMToyMiBQTTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpiZW5Abml2ZW4tamVua2lucy5jby51 ayI+YmVuQG5pdmVuLWplbmtpbnMuY28udWs8L2E+OyBaaG91WmhpcGVuZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+U3ViamVjdDogUkU6IFtD RE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5CZW4sIFpoaXBlbmcsIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SSB0aGluayB0 aGF0IENvbnRlbnQgQWRhcHRhdGlvbiBpcyBtb3JlIGFuIGlzc3VlIGZvciB0aGUgUmVxdWlyZW1l bnRzIGRvYyB0aGFuIGZvciB0aGUgVXNlIGNhc2VzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5U aGUga2V5IHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ugd2FudCB0aGUgQ0ROSSBpbnRlcmZhY2VzIHRv IGJlIGFibGUgdG8gY29wZSB3aXRoIGEgc2NlbmFyaW8gd2hlcmUgKHNheSkgSEQvU0QgY29udmVy c2lvbiBpcyBkb25lIGluIHRoZSBkQ0ROICZhbXA7IHRvDQogc2lnbmFsIGFib3V0IHRoaXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPkkgdGhpbmsgdGhhdCBjb3Bpbmcgd2l0aCB0aGlzIHNjZW5hcmlvIGlz IGEgc2Vjb25kIG9yZGVyIHJlcXVpcmVtZW50LCBpZSB3ZSBzaG91bGQgbm90IHdvcnJ5IGFib3V0 IGl0IGluIHRoZSBpbml0aWFsIHN0YW5kYXJkcy10cmFjayB3b3JrLiBJIGRvbid0DQoga25vdywg ZGlkIHdlIGV2ZXIgZGVjaWRlIHdoZXRoZXIgdGhlIFVzZSBjYXNlcyBkb2MgaXMgcmVzdHJpY3Rl ZCB0byAmcXVvdDtpbml0aWFsJnF1b3Q7IHNjZW5hcmlvcywgb3Igd2hldGhlciBpdCdzIGFsbC1l bmNvbXBhc3NpbmcsIGllIGNvdmVyaW5nICZxdW90O2Z1dHVyZSZxdW90OyBzY2VuYXJpb3MgYXMg d2VsbD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+U2NvdHQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5SZWFkaW5nIHNvbWUgb2YgeW91ciBleGFtcGxlcywgdGhleSBzZWVtIHRvIGJlIHZh bGlkIGV2ZW4gaWYgY29udGVudCBhZGFwdGF0aW9uIChIRC9TRCkgaXMgb3V0IG9mIHNjb3BlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+LSBhIGRDRE4gbWlnaHQgZm9yIHNvbWUg cmVhc29uIGJlIHVud2lsbGluZyB0byBkaXN0cmlidXRlIEhEPzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+LSBhIENTUCBtaWdodCB3YW50IHRvIG1ha2Ugc3VyZSB0aGUgZENETiBj YW4gdXNlIEhMUyBlbmNhcHN1bGF0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+QnV0IHRoZXNlIHNvcnRzIG9mIGV4YW1wbGVzIHNlZW0gdG8gYmUgc3RhdGljIHBvbGljeSB0 aGluZ3MgKHRvIGRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj53aXRoIHRoZSBj YXBhYmlsaXRpZXMgJmFtcDsgcHJlZmVyZW5jZXMgb2YgdGhlIENETnMgJmFtcDsgQ1NQKSwgcmF0 aGVyIHRoYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPm1ldGFkYXRhIGFzc29j aWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgcGllY2Ugb2YgY29udGVudC4gSW4gdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5kaXNjdXNzaW9uIHNvIGZhciwgSSB0aGluayBuZWdv dGlhdGlvbiBhYm91dCBzdGF0aWMgcG9saWN5IHN0dWZmIGlzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5yYXRoZXIgb3V0IG9mIHNjb3BlKD8pPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk9u IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiBpcyB3aGV0 aGVyIHRydXN0IGlzIHRyYW5zaXRpdmUuIERvbid0IHRoaW5rIGl0IG5lZWQgYmUgLSBqdXN0IGJl Y2F1c2UgQ1NQIHRydXN0cyB1Q0ROLCBhbmQgdUNETg0KIHRydXN0cyBkQ0ROIGRvZXNuJ3QgbWVh biB0aGF0IHRoZSBDU1AgYXV0b21hdGljYWxseSB0cnVzdHMgdGhlIGRDRE4uIEhvd2V2ZXIsIGkg c3VzcGVjdCB0aGlzIGNhbiBnZXQgYXJiaXRyYXJpbHkgY29tcGxleCAtIHNvIG9uZSBwb3NzaWJp bGl0eSBpcyB0byBzYXkgdGhhdCB3ZSB3aWxsIG9ubHkgaGFuZGxlIGNhc2VzIHdoZXJlIHRoZSB0 cnVzdCBpcyB0cmFuc2l0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5CZXN0IHdpc2hlczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+cGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlBoaWxpcCBFYXJkbGV5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5SZXNlYXJjaCBhbmQgVGVjaG5vbG9neSBTdHJhdGVn eTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5UaGlzIGVtYWlsIGNvbnRhaW5zIEJUIGluZm9ybWF0aW9uLCB3 aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwuIEl0J3MgbWVhbnQgb25seSBm b3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkIGFib3ZlLiBJZiB5b3UncmUNCiBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgbm90ZSB0aGF0IGRpc2Nsb3NpbmcsIGNvcHlpbmcs IGRpc3RyaWJ1dGluZyBvciB1c2luZyB0aGlzIGluZm9ybWF0aW9uIGlzIHByb2hpYml0ZWQuIElm IHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2UgbGV0IG1lIGtub3cg aW1tZWRpYXRlbHkgb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUuIFRoYW5rIHlvdS4gV2UgbW9u aXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQNCiBtYXkgcmVjb3JkIHlvdXIgZW1haWxzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMg cGxjPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5SZWdpc3RlcmVkIG9mZmljZTog ODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKIFJlZ2lzdGVyZWQgaW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkVuZ2xhbmQgbm86IDE4MDAwMDA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZyI+Y2RuaS1ib3VuY2VzQGlldGYub3JnPC9hPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJt YWlsdG86W21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIj5bbWFpbHRvOmNkbmktYm91bmNl c0BpZXRmLm9yZ108L2E+DQogT24gQmVoYWxmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5PZiBCZW4gTml2ZW4tSmVua2luczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+U2VudDogMTAgT2N0b2JlciAyMDExIDEyOjA0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5UbzogWmhvdVpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PkNjOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBo cmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Q29sbGVhZ3Vl cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+SU1PIFNlY3Rpb24gNS4xLjMgc2hvdWxkIGJlIHJlbW92ZWQg ZnJvbSB0aGUgVXNlIENhc2VzIGRyYWZ0LiBDb250ZW50IEFkYXB0YXRpb24gKGkuZS4gdGFraW5n IGluIGEgY29udGVudCBpdGVtIGluIG9uZSBmb3JtYXQgYW5kIHRyYW5zZm9ybWluZyBpdA0KIHRv IGFub3RoZXIgZm9ybWF0IG9yIHJlcHJlc2VudGF0aW9uKSBpcyBub3QgYSAmcXVvdDtjb3JlJnF1 b3Q7IGZ1bmN0aW9uIG9mIGEgQ0ROIHdoaWNoIHR5cGljYWxseSBkZWxpdmVycyB0aGUgY29udGVu dCB0aGF0IGlzIHJlcXVlc3RlZCB3aXRob3V0IGV4cGxpY2l0IGtub3dsZWRnZSBvZiB3aGF0IHRo YXQgY29udGVudCBhY3R1YWxseSBpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+TGV0J3Mgbm90IGZvcmdl dCB0aGF0IGluIGJ1aWxkaW5nIGFuIGVuZCB0byBlbmQgY29udGVudCBzZXJ2aWNlIHRoZSBDRE4g aXMgb25seSBvbmUgY29tcG9uZW50IGFuZCBpcyB0aGUgY29tcG9uZW50IHRhc2tlZCB3aXRoIGV4 ZWN1dGluZyB0aGUgZGVsaXZlcnkNCiBvZiBhIHNwZWNpZmljIHJlcHJlc2VudGF0aW9uICh2ZXJz aW9uL2NvcHkvZm9ybWF0IGV0Yy4pIG9mIHRoZSBzZWxlY3RlZCBjb250ZW50IG5vdCB0aGUgY29t cG9uZW50IHRhc2tlZCB3aXRoIGRlY2lkaW5nIChvciBhcHBseWluZyBwb2xpY3kpIG9uIHdoaWNo IHZlcnNpb24vY29weS9yZXByZXNlbnRhdGlvbiBvZiBjb250ZW50IHNob3VsZCBiZSBkZWxpdmVy ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZSBkZWNpc2lvbiBhcyB0byB3aGljaCB2ZXJzaW9uL2Nv cHkvcmVwcmVzZW50YXRpb24gdG8gb2ZmZXIgYW5kIGFsbG93IHRvIGJlIGRlbGl2ZXJlZCB0byBh IGdpdmVuIGRldmljZS91c2VyIGlzIGltcGxlbWVudGVkIG91dHNpZGUgb2YgdGhlIENETg0KIChl LmcuIGJ5IHRoZSAmcXVvdDtwb3J0YWwmcXVvdDsgd2hlcmUgdGhlIHVzZXIgZmlyc3QgbWFrZXMg dGhlaXIgY29udGVudCBzZWxlY3Rpb24gcHJpb3IgdG8gdGhlIENETiBiZWNvbWluZyBpbnZvbHZl ZCBpbiB0aGUgZGVsaXZlcnkgb2YgdGhlIHNlbGVjdGVkIGNvbnRlbnQpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5CZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+T24gOCBPY3QgMjAxMSwgYXQgMDg6MjAsIFpob3Va aGlwZW5nIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZvbGxvd2luZyBTY290dCdzIGNvbW1l bnRzIG9uIHNlY3Rpb24gNS4xLjMsIEkgZmVlbCBTY290dCdzIGRlc2NyaXB0aW9uIG9uIHRoZSB1 c2UgY2FzZSBvZiBIRCBhbmQgU0QgaXMgbm90IGV4YWN0bHkgY29ycmVjdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWYgb25lIG1vdmllIGhhcyB0 d28gZm9ybWF0cyBvZiBIRCBhbmQgU0QsIHRoZW4gd2UgaGF2ZSB0d28gY29udGVudCB3aXRoIGRp ZmZlcmVudCBpZGVudGlmaWVyLiBJbiBEUk0gc2NvcGUsIHRoZSBiYXNpYyB1bml0IGlzIGEgY29u dGVudCBjb3B5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+SGVyZSB0aGUgZmlyc3QgYnVsbGV0ICZxdW90O2Egc3Vic2V0IG9mIGVuY29kaW5ncyBk ZWxpdmVyYWJsZSB0byBzcGVjaWZpYyBkZXZpY2VzLCZxdW90OyBoYXMgbGlzdGVkIHRoZSBjYXNl IG9mIGNvbnRlbnQgYWRhcHRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+SW4gbGFzdCBtb250aCwgSSBoYXZlIGNvbnRhY3RlZCB0aGUgQXV0 aG9ycyBvZiB0aGlzIGRvY3VtZW50IGFuZCB0YWtlbiBzb21lIGVtYWlsIGV4Y2hhbmdlcyB3aXRo IEdyYW50IGFuZCBQaGlsaXAgKEJUKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+SSBoYXZlIHNob3duIEJUIHdpdGggc29tZSBpbmZvcm1hdGlvbiB0 aGF0IEkga25vdyBpbiB0aGlzIGNhc2UgYW5kIGFyZWEgdG8gZXhwbGFpbiB0aGUgY29udGVudCBm bGV4aWJpbGl0eSBpcyBjdXJyZW50bHkgYSBiYXNpYyByZXF1aXJlbWVudCBmb3INCiBDRE4gc2Vy dmljZSBhbmQgcmVsYXRlZCBuZWdvdGlhdGlvbiBpcyBuZWVkZWQgaW4gdGhlIENETiBpbnRlcmNv bm5lY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPk1lYW53aGlsZSwgSSBzaG91bGQgYWxzbyBpbnZpdGUgeW91IGluIHRoaXMgZ3JvdXAgcmFp c2luZyB5b3VyIGNvbW1lbnRzIG9yIHF1ZXN0aW9ucyBvbiB0aGlzIGNhc2Ugc2luY2UgSSBob3Bl IG15IHVzZSBjYXNlIG1heSBiZSBpbmNvcnBvcmF0ZWQgaW4NCiB0aGUgdXNlIGNhc2UgZHJhZnQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JZiB5 b3UgaGF2ZSBhbnkgbW9yZSBxdWVzdGlvbiBvciBjb21tZW50cywgcGxzIHNoYXJlIGluIHRoaXMg dGhyZWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RnJvbTogU2NvdHQgV2Fpbm5lcg0KPGEg aHJlZj0ibWFpbHRvOlttYWlsdG86c3dhaW5uZXJAY2lzY28uY29tXSI+W21haWx0bzpzd2Fpbm5l ckBjaXNjby5jb21dPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5TZW50OiBGcmlkYXksIFNlcHRlbWJlciAzMCwgMjAxMSA4OjAyIEFNPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRvOjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+U3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+U2VjdGlvbiAyLjMgTm9tYWRpYyBVc2Vyczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGlzIGRl c2NyaXB0aW9uIGZhbGxzIHVuZGVyIHRoZSBjYXRlZ29yeSBvZiBHZW9ncmFwaGljIEV4dGVuc2lv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj55ZXQg dGhlIHRoaXJkIHBhcmFncmFwaCBzdGF0ZXMgdGhlIGNhc2Ugd2hlcmUgYSBkaWZmZXJlbnQgZGV2 aWNlIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PnVzZWQgaW4gdGhlIHNhbWUgQ0ROIGNvdmVyYWdlIGFyZWEuICZuYnNwO1RoZSBpbnRlbnQgb2Yg dGhpcyB1c2UgY2FzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5uZWVkcyB0byBiZSBjbGFyaWZpZWQuICZuYnNwO1BlcmhhcHMgdGhlIHVzZSBjYXNl IGlzIHRyeWluZyB0byBhZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPnRoZSBzY2VuYXJpbyB3aGVyZSBhIE5vbWFkaWMgVXNlci1BIHdpdGgg YW4gYWdyZWVtZW50IGFsbG93aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPmFjY2VzcyB0byBjb250ZW50IGZyb20gQ1NQLUEgdmlhIHVDRE4gbW92 ZXMgdG8gYSBkQ0ROIGluIGEgZGlmZmVyZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPnJlZ2lvbi4gJm5ic3A7VGhlIGRDRE4gaXMgYWxsb3dlZCB0 byBkaXN0cmlidXRlIHRoZSBjb250ZW50IG9mIENTUC1BIHRvPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlVzZXItQTsgaG93ZXZlciwgbm90IG90aGVy IHVzZXJzIGluIHRoZSByZWdpb24gb2YgdGhlIGRDRE4gYXJlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmFsbG93ZWQgdG8gcmV0cmlldmUgdGhlIGNv bnRlbnQgdW5sZXNzIHRoZXkgdG9vIGhhdmUgc3VjaCBhbiBhZ3JlZW1lbnQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5TZWN0aW9uIDUuMS4zIENv bnRlbnQgRW5jb2RpbmcgUmVzdHJpY3Rpb25zIE5lZWQgdG8gY2xhcmlmeSBpZiB3ZSdyZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj50YWxraW5nIGFi b3V0IHRoZSByZXN0cmljdGlvbnMgb24gdGhlIGRlbGl2ZXJ5IG9mIHNwZWNpZmljIGNvbnRlbnQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+b3IgdGhl IHJlc3RyaWN0aW9ucyBvbiB0aGUgYWJpbGl0eSBvZiBhIENETiB0byBkZWxpdmVyIHNwZWNpZmlj PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmNvbnRl bnQuICZuYnNwO0kgY2VydGFpbmx5IHVuZGVyc3RhbmQgdGhlIGNhc2Ugd2hlcmUgYSBDU1Agd2ls bCByZXN0cmljdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj50aGUgZGlzdHJpYnV0aW9uIG9mIGNvbnRlbnQgdG8gYSAmcXVvdDttYW5hZ2VkIHBhdGgm cXVvdDsgaWYgc3VjaCBjb250ZW50IGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPkhEIHdoaWxlIGFsbG93aW5nIHRoZSBjb250ZW50IGRpc3RyaWJ1 dGlvbiB2aWEgYW4gdW4tbWFuYWdlZCBwYXRoIGlmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPnN1Y2ggY29udGVudCBpcyBTRCAoc2FtZSBjb3VsZCBh cHBseSB0byBlbmNyeXB0aW9uIG1ldGhvZHMsIGRlbGl2ZXJ5PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPm1ldGhvZHMsIGV0Yy4pLiAmbmJzcDtPbiB0 aGUgY29udHJhcnksIHRoZSBkQ0ROIG1heSBoYXZlIGl0cyBvd248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+cmVzdHJpY3Rpb25zIG9mIGJsb2NraW5n IHRoZSBkaXN0cmlidXRpb24gb2YgSEQgY29udGVudCB3aGlsZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5hbGxvd2luZyB0aGUgZGlzdHJpYnV0aW9u IG9mIFNEIGNvbnRlbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5vIGZpcnN0IGJ1bGxldCBtYWtlcyBzZW5zZSBpZiB0aGUgZENETiBjYW4gcGVy Zm9ybSBhIHN1YnNldCBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5lbmNhcHN1bGF0aW9ucyBmb3IgYSByZWZlcmVuY2Ugc2V0IG9mIG1lZGlhIChl LmcuIEhMUywgSFNTLCBidXQgbm90PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPkRBU0gpIG8gc2Vjb25kIGJ1bGxldCBtYWtlcyBzZW5zZSB3aGVyZSB0 aGUgZENETiBkb2Vzbid0IHdhbnQgdG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+b2ZmZXIgaGlnaCBiaXQtcmF0ZSB2YXJpYW50cyBvZiB0aGUgbWVk aWEgbyB0aGlyZCBidWxsZXQgbWFrZSBzZW5zZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj5pZiB0aGUgcG9saWN5IGFkZHJlc3NlcyBRb0UgYnV0IEkg ZG9uJ3QgdGhpbmsgc3Vic2NyaWJlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5yaWdodHMvYXV0aG9yaXphdGlvbnMgYXBwbHkuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5TZWN0aW9uIDEwIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5Bc2lkZSBmcm9tIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBXSVRI SU4gdGhlIHVDRE4gYW5kIGRDRE4sIEk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+dGhpbmsgd2UgY2FuIGRlc2NyaWJlIHRoaXMgaW4gZm91ciBjb250 ZXh0czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PmEuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgQ1NQIGFuZCB0aGUgdUNETiAodGhlIHBy aW5jaXBsZSBjb250cmFjdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj5hcnJhbmdlbWVudCBmb3IgZGlzdHJpYnV0aW9uKTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5iLiBUaGUgcmVsYXRpb25zaGlwIGJl dHdlZW4gdGhlIHVDRE4gYW5kIGRDRE4gKHRoZSB0cmFuc2l0aXZlIHRydXN0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPnJlbGF0aW9uc2hpcCB0aGF0 IGV4dGVuZHMgdGhlIGNvbnRyYWN0IGRlZmluZWQgaW4gKGEpIGFib3ZlKSBjLiBUaGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+cmVsYXRpb25zaGlw IGJldHdlZW4gdGhlIFVzZXIgYW5kIGRDRE4gKHRoZSByZWNvZ25pdGlvbiBvZiByaWdodCB0bzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5kb3dubG9h ZCBwcmVkaWNhdGVkIG9uIChiKSBhYm92ZSkgZC4gVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRo ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5Vc2Vy IGFuZCBDU1AgKHRoZSBjb250cmFjdCBhdXRob3JpemluZyB0aGUgdXNlciBhY2Nlc3MgdG8gdGhl PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmNvbnRl bnQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5U aGUgdXNlciBpcyBub3QgaW50ZXJlc3RlZCBpbiB0aGUgYS1iIG5vciB0aGUgYi1jIHJlbGF0aW9u c2hpcC4gVGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPnVzZXIgaXMgb25seSBpbnRlcmVzdGVkIGluIHRoZSB0cmFuc3BhcmVuY3kgYW5kIGludGVy b3BlcmFiaWxpdHkgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+dGhlIHNlY3VyaXR5IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIGQtYiBvciBkLWMgdG8g dGhlIHBvaW50IHRoYXQgdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPmF1dGhvcml6YXRpb24gZ3JhbnRlZCBpbiBkLWEgaXMgdmlhYmxlIHdoZW4g dGhlIGRlbGl2ZXJ5IGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPmluaXRpYXRlZCB2aWEgZWl0aGVyIGQtYiBvciBkLWMuICZuYnNwO0FzIGFuIGV4 YW1wbGUsIHRoZSB1Q0ROIG1pZ2h0IHVzZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5VUkwgYXBwZW5kZWQgdG9rZW5zIGZvciBhdXRoZW50aWNhdGlv biB3aGlsZSBkQ0ROIG1pZ2h0IHVzZSBVUkw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+YXBwZW5kZWQgaGFzaGVzLiAmbmJzcDtUaGUgdXNlciBkb2Vz bid0IHdhbnQgdG8ga25vdyBhYm91dCB0aGUgZGlzdGluY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+bWV0aG9kcywgYnV0IHRyYW5zcGFyZW5jeSBp cyBvbmx5IGFmZm9yZGVkIGlmIHRoZSBtZXRob2RzIGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5pbnRlcm9wZXJhYmxlIGNsZWFybHkgZGVmaW5l ZCB3aGVuIHRoZSBkZWxlZ2F0aW9uIGZvciBjb250ZW50PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmRlbGl2ZXJ5IGlzIGV4ZWN1dGVkLiAmbmJzcDtD bGVhcmx5LCB0aGUgY2hvaWNlIG9mIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBpcyBkZXRlcm1pbmVk IGJ5IHRoZSByZXNwZWN0aXZlIENETidzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+U2NvdHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 WkgtQ04iPkNETmkgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjxhIGhyZWY9Im1haWx0bzpDRE5pQGlldGYub3JnIj5DRE5pQGll dGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmki Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaTwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkNETmkgbWFp bGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48YSBocmVmPSJtYWls dG86Q0ROaUBpZXRmLm9yZyI+Q0ROaUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pPC9hPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Ozttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpDRE5pIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpDRE5pQGlldGYub3JnIj5DRE5pQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jZG5pPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0ROaSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86Q0ROaUBpZXRmLm9yZyI+Q0ROaUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkNETmkgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNETmlAaWV0Zi5vcmci PkNETmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9jZG5pIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Nkbmk8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 Zm9udCBmYWNlPSJtb25vc3BhY2UiPlRoaXMgZS1tYWlsIGFuZCBpdHMgY29udGVudHMgYXJlIHN1 YmplY3QgdG8gdGhlIERJU0NMQUlNRVIgYXQgaHR0cDovL3d3dy50bm8ubmwvZW1haWxkaXNjbGFp bWVyPC9mb250PjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FCC100FC8D6B034CB88CD8173B2DA1581558B761EXCMBX03tsntnon_-- From zhouzhipeng@huawei.com Mon Oct 31 02:36:02 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7CE21F8CF2 for ; Mon, 31 Oct 2011 02:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.698 X-Spam-Level: X-Spam-Status: No, score=-4.698 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2t6Ofe8OmVm for ; Mon, 31 Oct 2011 02:35:57 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id E4B2221F8CFD for ; Mon, 31 Oct 2011 02:35:53 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTX00DEGBYR3P@szxga03-in.huawei.com> for cdni@ietf.org; Mon, 31 Oct 2011 17:35:16 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LTX00HW9BXOFQ@szxga03-in.huawei.com> for cdni@ietf.org; Mon, 31 Oct 2011 17:35:15 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEQ36603; Mon, 31 Oct 2011 17:35:14 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 31 Oct 2011 17:35:12 +0800 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.117]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Mon, 31 Oct 2011 17:35:00 +0800 Date: Mon, 31 Oct 2011 09:35:00 +0000 From: ZhouZhipeng In-reply-to: X-Originating-IP: [10.138.73.38] To: "Brandenburg, R. (Ray) van" , Francois Le Faucheur Message-id: <260A32EFD5C9EB47AD504929D005DF6217F6D282@SZXEML519-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_H8itvd7FyeFtDJBc48s76g)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-index: AQHMf6O20p1toKNg4Uy+T11t9RIj65WWIlhggAAKpqD//6sQgIAAhzPg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> <144D124A-E8A2-48DC-A98D-6F33B2EB1B90@cisco.com> <260A32EFD5C9EB47AD504929D005DF6217F6D1F9@SZXEML519-MBX.china.huawei.com> Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 09:36:02 -0000 --Boundary_(ID_H8itvd7FyeFtDJBc48s76g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 VGhhbmtzIFJheS4gd2VsY29tZSB5b3VyIG1vcmUgYXR0ZW50aW9uIG9uIGl0Lg0KWmhpcGVuZw0K DQoNCkZyb206IEJyYW5kZW5idXJnLCBSLiAoUmF5KSB2YW4gW21haWx0bzpyYXkudmFuYnJhbmRl bmJ1cmdAdG5vLm5sXQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDMxLCAyMDExIDU6MjMgUE0NClRv OiBaaG91WmhpcGVuZzsgRnJhbmNvaXMgTGUgRmF1Y2hldXINCkNjOiBjZG5pQGlldGYub3JnDQpT dWJqZWN0OiBSRTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMt MDAudHh0DQoNCkhpIFpoaXBlbmcsDQoNClRvIGJlIGNsZWFyIGhlcmUsIEkgaGF2ZSBub3QgZ2l2 ZW4gbXkgc3VwcG9ydCB0byB0aGUgQ29udGVudCBBZGFwdGF0aW9uIHVzZSBjYXNlIChub3IgaGF2 ZSBJIHZvaWNlZCBteSBvcHBvc2l0aW9uIGFnYWluc3QgaXQpLg0KDQpUaGUgY29udmVyc2F0aW9u IEkgaGFkIHdpdGggQmVuIGhhZCB0byBkbyB3aXRoIHRoZSBjb25jZXB0IG9mIEdyb3VwZWQgRmls ZSBEZWxlZ2F0aW9uIGFuZCBob3cgZGlmZmVyZW50IHF1YWxpdHkgbGV2ZWxzLCBlbmNvZGVkIGJ5 IHRoZSBDb250ZW50IFByb3ZpZGVyLCBhcmUgaGFuZGxlZCBpbiBhIENETiBpbnRlcmNvbm5lY3Rp b24gc2NlbmFyaW8uDQoNClJheQ0KDQpGcm9tOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBaaG91WmhpcGVuZw0KU2VudDog bWFhbmRhZyAzMSBva3RvYmVyIDIwMTEgMTA6MDQNClRvOiBGcmFuY29pcyBMZSBGYXVjaGV1cg0K Q2M6IGNkbmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KU29ycnksIG5vdCBLUE4uIEl0IGlzIFJheSBm cm9tIFROTy4NClpoaXBlbmcNCg0KDQpGcm9tOiBaaG91WmhpcGVuZw0KU2VudDogTW9uZGF5LCBP Y3RvYmVyIDMxLCAyMDExIDQ6NDkgUE0NClRvOiAnRnJhbmNvaXMgTGUgRmF1Y2hldXInDQpDYzog Y2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbQ0ROaV0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KRGVhciBGcmFu Y29pcywgYW5kIGFsbCwNClRoYW5rcyBmb3IgYWxsIHRoZSBncm91cOKAmXMgYXR0ZW50aW9uIG9u IHRoaXMgdG9waWMuDQpJIGFtIGFsc28gaGFwcHkgdGhhdCBteSBwcm9wb3NhbCBoYXMgZ290dGVu IHNvIG11Y2ggdmFsdWFibGUgcmVzcG9uc2UvcXVlc3Rpb25zLyBjb21tZW50cy4NClRoYXQgd2ls bCBiZSB2ZXJ5IGhlbHBmdWwgZm9yIGFsbCBvZiB1cyB0byBjYXRjaCBhIGNvbXBsZXRlIHVuZGVy c3RhbmRpbmcgYW5kIHNvbHV0aW9uIGZvciB0aGlzIG1hcmtldCBkZW1hbmQuDQpXaGlsZSBJIGZl ZWwgdGlsbCBub3cgdGhlIHRvcGljIGl0c2VsZiBoYXMgbm90IGJlZW4gY29tcGxldGVseSBhbmFs eXplZCBhbmQgSSBhbSBidXN5IGRvaW5nIHRoZSB3b3JrLiBJIHdpbGwgZXhwb3NlIG15IGNvbnRy aWJ1dGlvbiBzb29uIGFmdGVyIEkgY29tcGxldGUgdGhhdCB3b3JrLg0KTWVhbndoaWxlIEkgaG9w ZSB0aGUgZ3JvdXAgbWF5IGFsbG93IHNvbWUgbW9yZSB0aW1lIGZvciBwZW9wbGUgdG8gY29uc2lk ZXIgaXQuIFBlcmhhcHMgc29tZSBtb3JlIHBlb3BsZSB3aWxsIGVtZXJnZSBpbiB0aGUgZ3JvdXAg bWFpbCBsaXN0Lg0KQ3VycmVudGx5LCBzb21lIHBlb3BsZSBoYXMgY2xhaW1lZCB0aGVpciBwcmVm ZXJlbmNlLiAgSSBmZWVsIHBlcmhhcHMgbm90IGEgZmV3IHBlb3BsZSBoYXZlIHN1cHBvcnRlZCB0 aGlzIHVzZSBjYXNlKHRoZSBhdXRob3JzIG9mIGRyYWZ0LWZtbi1jZG5pLWFkdmFuY2VkLXVzZS1j YXNlcy0wMCwgQWxhbiBmcm9tIEVyaWNzc29uLCBDaGluYU1vYmlsZSwgQ2hpbmF0ZWxlY29tLCAg cGVyaGFwcyBhbHNvIEtQTiwgYW5kIG1lKS4NCg0KSSBoYXZlIGV4cGxhaW5lZCB0aGF0IGZvciBD RE4tQSBhbmQgQ0ROLUIsIHRoZXkgbWF5IG5lZ290aWF0ZSB3aGV0aGVyIHRvIHN1cHBvcnQgdGhl IENETkkgYWRhcHRhdGlvbiBzb2x1dGlvbi4gSGVuY2Ugc3VjaCBvcHRpb25hbCBhcnJhbmdlbWVu dCB3aWxsIG9ubHkgYnJpbmcgYmVuZWZpdCB3aGVuIGJvdGggdXBzdHJlYW0gYW5kIGRvd25zdHJl YW0gYWdyZWVzIHRoYXQgYXQgdGhlaXIgYXBwcm9wcmlhdGUgc2l0dWF0aW9uLg0KDQpTbywgSSBz aW5jZXJlbHkgc3VnZ2VzdCB0d28gQ2hhaXJzIGFuZCB0aGUgd2hvbGUgZ3JvdXAgbWF5IGFsbG93 IHNvbWUgbW9yZSBkYXlzIGZvciB0aGlzIHRvcGljLiAgIEkgc3VnZ2VzdCBhZnRlciB0aGUgVGFp cGVpIG1lZXRpbmcgLg0KQnkgdGhlbiB3ZSBhbGwgd2lsbCBnZXQgYSBjbGVhcmVyIHVuZGVyc3Rh bmRpbmcgYW5kIGRlY2lzaW9uLg0KDQpUaGFua3MuDQpaaGlwZW5nDQoNCg0KDQpGcm9tOiBGcmFu Y29pcyBMZSBGYXVjaGV1ciBbbWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbV08bWFpbHRvOlttYWls dG86ZmxlZmF1Y2hAY2lzY28uY29tXT4NClNlbnQ6IEZyaWRheSwgT2N0b2JlciAyOCwgMjAxMSA5 OjUwIFBNDQpUbzogWmhvdVpoaXBlbmcNCkNjOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmkt dXNlLWNhc2VzLTAwLnR4dA0KDQpIaSBhZ2FpbiBaaGlwZW5nLA0KDQpUaGVyZSBpcyBvbmUgb3Ro ZXIgcG9pbnQgSSBzaG91bGQgaGF2ZSBicm91Z2h0IHVwIGluIG15IHByZXZpb3VzIG1lc3NhZ2U6 DQpUaGUgcXVlc3Rpb24gaXMgbm90IHNvIG11Y2ggd2hldGhlciB0aGVyZSBhcmUgYmVuZWZpdHMg dG8gYWxsb3dpbmcgY29udGVudCBhZGFwdGF0aW9uIGZvciBzb21lIGVudmlyb25tZW50cywgbm9y IHdoZXRoZXIgb25lIHBhcnRpY3VsYXIgaW5kaXZpZHVhbCBjb3VsZCBjb25jZWl2ZSBhbiBhcHBy b2FjaCBmb3IgY29udGVudCBhZGFwdGF0aW9uIHRoYXQgc3VpdHMgaGltLiBUaGUgcXVlc3Rpb24g aGVyZSBpcyByYXRoZXIgd2hldGhlciBpdCBpcyBqdXN0aWZpZWQgZm9yIHRoZSBXb3JraW5nIEdy b3VwIHRvIGZvY3VzIGVuZXJneSBvbiB0aGF0IHByb2JsZW0gcmlnaHQgbm93IGluIG9yZGVyIHRv IGRldmVsb3AgYSBjb25zZW5zdXMtYmFzZWQgYXBwcm9hY2ggdGhhdCBzdWl0cyB0aGUgY29tbXVu aXR5IGFzIGEgd2hvbGUsIHdoaWxlIHdlIGRvbid0IGV2ZW4gaGF2ZSB0aGUgYmFzZSBzb2x1dGlv biBpbiBwbGFjZS4NCg0KWW91IGhhdmUgbWFkZSBpdCBjbGVhciB0aGF0IHlvdSBmZWVsIHRoZSBX RyBzaG91bGQgaW5kZWVkIGRlZGljYXRlIGVuZXJneSBvbiB0aGF0IHByb2JsZW0gcmlnaHQgYXdh eSBhbmQgZXhwbGFpbmVkIHlvdXIgcmF0aW9uYWxlLiBUaGFuayB5b3UuIE90aGVycyBoYXZlIGFs c28gZXhwcmVzc2VkIHRoZWlyIG9waW5pb25zLg0KDQpDaGVlcnMNCg0KRnJhbmNvaXMNCg0KDQpP biAyOCBPY3QgMjAxMSwgYXQgMTE6MjUsIFpob3VaaGlwZW5nIHdyb3RlOg0KDQpEZWFyIGFsbCwN CkluIHRoZXNlIGRheXMgSSBhbSBidXN5IG1ha2luZyBhIHN1bW1hcnkgYW5hbHlzaXMgb24gdGhp cyB0b3BpYy4gQXMgUmljaGFyZOKAmXMgcmVxdWVzdCwgSSBsaWtlIHRvIHNob3cgbXkgaW5mb3Jt YXRpb24gYWx0aG91Z2ggcGVyaGFwcyBub3QgY29tcGxldGUgcmlnaHQgbm93Lg0KDQoxKSAgICAg SSBoYXZlIGRvbmUgc29tZSB3b3JrIHRvIGNvbGxlY3QgZGlmZmVyZW50IGNvbXBhbnnigJlzIHJl cXVpcmVtZW50cyBhbmQgb3BpbmlvbnMgb24gdGhpcyBmdW5jdGlvbmFsaXR5Lg0KT25lLCBJIGZl ZWwgbW9zdCBvZiB1cyBoYXZlIGFscmVhZHkgYmVlbiBhd2FyZSBvZiB0aGUgc2VydmljZSBvZiBj b250ZW50IGFkYXB0YXRpb24sIGFuZCBJIGFsc28gc2VudCBhbiBlbWFpbCB5ZXN0ZXJkYXkgdGhh dCBWb2RhcGhvbmUgbm93IGlzIHJlcXVpcmluZyB0aGUgc29sdXRpb24gdG8gZW5oYW5jZSB0aGUg cGVyZm9ybWFuY2Ugb2YgaXRzIG1vYmlsZSB2aWRlbyBzZXJ2aWNlLg0KU2Vjb25kLCBoZXJlIGlz IGFuIGFydGljbGUgYWJvdXQgQ0lTQ08gOiDigJxDaXNjbyB1cmdlcyBtb2JpbGUgb3BlcmF0b3Jz IHRvIGFkZCB2YWx1ZSB0byBDRE4gc2VydmljZXPigJ0gaHR0cDovL3d3dy50b3RhbHRlbGUuY29t L3ZpZXcuYXNweD9JRD00Njg3MDUNCkJlc2lkZXMsIEkgaGF2ZSBjaGVja2VkIG1hbnkgQ0ROIGNv bXBhbnnigJlzIHdlYnNpdGVzLiBNYW55IGNsYWltIHRvIHN1cHBvcnQgdHJhbnNjb2Rpbmcgd2hp bGUgc29tZSBtYXkgbm90Lg0KDQoyKSAgICAgRm9yIHRoZSB3b3JkaW5nIOKAnGNvbnRlbnQgYWRh cHRhdGlvbuKAnSwgaXQgc2hvdWxkIGJlIGNsYXJpZmllZCBoZXJlIHRoYXQgaXQgbWF5IGJlIHR3 byBraW5kcy4NCk9uZSBpcyBvbmx5IHRoZSB0cmFuc2Zvcm1hdGlvbiBvZiBlbmNhcHN1bGF0aW9u IGZvcm1hdC4gRm9yIGV4YW1wbGUgdGhlIEguMjY0IHN0cmVhbSBpcyBlbmNhcHN1bGF0ZWQgaW4g QVBQTEUgYW5kIEFkb2JlIGZvcm1hdCByZXNwZWN0aXZlbHkuDQpJIGtub3cgdGhhdCBDb21jYXN0 IGhhcyBhIHByb2plY3QgdGhhdCBuZWVkcyB0byBwaWNrIHRoZSBILjI2NCBtZWRpYSBmcm9tIHRo ZSBUUyBzdHJlYW0gYW5kIHRoZW4gZW5jYXBzdWxhdGVkIHRoZW0gaW50byBkaWZmZXJlbnQgZm9y bWF0cyhBUFBMRSxBZG9iZeKApikgdG8gZGlmZmVyZW50IGRldmljZXMuDQpGb3IgdGhpcyBraW5k IG9mIHRyYW5zZm9ybWF0aW9uLCB0aGUgY29tcHV0aW5nIGNvc3QgaXMgdmVyeSB2ZXJ5IGxvdyBh bmQgbWF5IGJlIG5lYXJseSBuZWdsZWN0ZWQuDQpUaGUgb3RoZXIgaXMgdG8gdHJhbnNjb2Rpbmcu ICBGb3IgZXhhbXBsZSB0byBzdXBwb3J0IGRpZmZlcmVudCBiaXRyYXRlcy4gIFNpbmNlIGVuY29k ZXIgaXMgYSBoaWdoIHZhbHVlIGZhY2lsaXR5LCB3ZSBzaG91bGQgY29tcGFyZSB0aGUgY2FwaXRh bCBjb3N0IG9mIGVuY29kZXIgYW5kIHRyYW5zcG9ydCBjb3N0Lg0KSnVzdCB0YWtlIGEgc2ltcGxl IG1vZGVsOiBjb250ZW50IGlzIGRlbGl2ZXJlZCBmcm9tIE5vZGUgQSB0byBOb2RlIEIuDQo8aW1h Z2UwMDIucG5nPg0KVGhlcmUgYXJlIHR3byBzb2x1dGlvbnM6DQoxKSAgICAgQSBoYXZlIHRoZSB0 cmFuc2NvZGVyIGFuZCBkZWxpdmVyIG11bHRpLWZvcm1hdCBjb250ZW50IHRvIEINCjIpICAgICBC IGhhdmUgdGhlIHRyYW5zY29kZXI7IEEgb25seSBkZWxpdmVycyBvbmUgZm9ybWF0IGNvbnRlbnQg dG8gQiBhbmQgQiB3b3VsZCB0cmFuc2NvZGUuDQpGcm9tIHdob2xlIHN5c3RlbSBwb2ludCBvZiB2 aWV3LCBlaXRoZXIgQSBvciBCIHdvdWxkIHRyYW5zY29kZSB3aGlsZSB0aGUgYmFuZHdpZHRoIHdv dWxkIGJlIHNhdmVkIGluIHNvbHV0aW9uIEIuIEhlbmNlIHNvbHV0aW9uIEIgaXMgYmV0dGVyLg0K Tm93IHByb3ZpZGVkIHRoZSBiYW5kd2lkdGggaXMgcGFpZCBieSBCIGFuZCBCIHNob3VsZCBkZWNp ZGUgd2hldGhlciB0byBpbnN0YWxsIHRyYW5zY29kZXIuDQooUmljaGFyZCBoYXMgc2FpZCB0byBz ZXQgdHJhbnNjb2RlciBpbiBlYWNoIGVkZ2Ugc2VydmVyKQ0KSWYgdGhlIGNvc3Qgb2YgcmVudGlu ZyBiYW5kd2lkdGggKGZvciBhIGZldyBtb250aHMpIGlzIG1vcmUgZXhwZW5zaXZlIHRoYW4gdGhl IHByaWNlIG9mIHRyYW5zY29kZXIgc3VwcG9ydGluZyB0aGUgc2FtZSBiYW5kd2lkdGgsIGl0IHdv dWxkIGJlIGJldHRlciB0byBwdXQgdGhlIHRyYW5zY29kZXIgYXQgdGhlIHJlY2VpdmVyIE5vZGUg Qi4NCkluIGZhY3QgSSBoYXZlIGludmVzdGlnYXRlZCB0aGlzIGlzc3VlIGZvciBtdWNoIHRpbWUu IFdoaWxlIGluIGRpZmZlcmVudCBhcmVhIHRoZSBwcmljZSBvZiBiYW5kd2lkdGggbWF5IGJlIGRp ZmZlcmVudC4gIEFuZCB0aGUgdHJhbnNwb3J0IGJ1cmRlbiBiZXR3ZWVuIHR3byBkaXN0YW50IHBs YWNlcyBvciBvdmVyIGEgYmFkIG5hdHVyZSBlbnZpcm9ubWVudCB3b3VsZCBiZSBtdWNoIGhpZ2hl ci4NCkhlcmUgdGhlIHByaWNlIGluIFVTQSBtYXkgYmUgcmVmZXJyZWQgYXM6IGh0dHA6Ly9zbWFs bGJ1c2luZXNzLnZlcml6b24uY29tL3Byb2R1Y3RzL2ludGVybmV0L2hzaS9vdmVydmlldy5hc3B4 I3BsYW5zLg0KSW4gVmVyaXpvbiwgdGhlIHBhY2thZ2UgZm9yIDEwLTE1bWJwcyBpcyAkOTAgcGVy IG1vbnRoIChJIGZlZWwgdGhlIGJhbmR3aWR0aCBxdWFsaXR5IGZvciBidXNpbmVzcyB3b3VsZCBi ZSBndWFyYW50ZWVkKS4gSSBxdWVyeSB0aGF0IHRoZSBiYW5kd2lkdGggcHJpY2UgaW4gQ2hpbmEg bWF5IGJlIDUwJSBoaWdoZXIuDQpJIGRvIG5vdCBrbm93IGhvdyBtdWNoIHRoZSBwcmljZSB3aWxs IGJlIGZvciB0aGUgYmFuZHdpZHRoIGZyb20gQW1zdGVyZGFtIHRvIFBhcmlzIChjcm9zcyBjb3Vu dHJ5IGluIHRoZSBzYW1lIGNvbnRpbmVudCkuICBCdXQgSSBmZWVsIHRoZSBwcmljZSBmcm9tIE5l d1lvcmsgdG8gUGFyaXMgd291bGQgYWJzb2x1dGVseSBiZSB2ZXJ5IGhpZ2guICBBcyBmb3IgdGhl IEVuY29kZXIsIGl0IGFsc28gdmFyaWVzLiBQZXJoYXBzIHRoZSBwcmljZSBpbiBDaGluYSB3aWxs IGJlIGhpZ2hlciB0aGFuIGluIFVTQS4gQW5kIGluIGZhY3QgdGhlIHByaWNlIG9mIGJhbmR3aWR0 aCBhbmQgZW5jb2RlciBkZXBlbmRzIG1vc3RseSBvbiB0aGUgY29uY3JldGUgYnVzaW5lc3MgaXRl bXMuIEZvciBleGFtcGxlIHRoZSBwcmljZSB0byBIdWF3ZWkgbWF5IGJlIGxvd2VyIHRoYW4gdGhl IHB1YmxpYyBwcmljZS4NCkJ5IG15IGN1cnJlbnQgZXZhbHVhdGlvbiBpbiBDaGluYSBpdCBpcyBi ZXR0ZXIgdXNpbmcgdGhlIHRyYW5zY29kZXIgdGhhbiByZW50aW5nIG11bHRpcGxlIHRpbWVzIGJy b2FkYmFuZC4NClNvbWUgcGVvcGxlIGhhdmUgdG9sZCBtZSB0aGF0IGZvciB0aGUgb3BlcmF0b3Ig aGltc2VsZiBwcm9iYWJseSB0aGUgYmFuZHdpZHRoIGNvc3Qgd291bGQgYmUgdmVyeSBsb3cgaW4g dGhlIGludGVybmFsIGNhcGl0YWwgY291bnRpbmcuIEJ1dCBmb3IgdGhlIGluZGVwZW5kZW50IENE TiwgaXQgbWF5IGFub3RoZXIgdGhpbmcuDQpTbywgbXkgc3VnZ2VzdGlvbiBpcyB0byBsZXQgZGlm ZmVyZW50IHdheXMgY28tZXhpc3QuIEkgaGF2ZSBhbm5vdW5jZWQgdGhhdCB0byBsZXQgdHdvIHNp ZGVzIG5lZ290aWF0ZSB3aGV0aGVyIHRvIGFzc2lnbiBkQ0ROIGZvciB0aGUgY29udGVudCBhZGFw dGF0aW9uLg0KDQpJbiBmYWN0LCBmcm9tIENQIHRvIENETiwgIHRoZXJlIGFyZSB0aGUgcmVhbCBi dXNpbmVzc2VzIHRoYXQgZWl0aGVyIGxldCBDUCB0byBwcm92aWRlIG11bHRpLWZvcm1hdCBjb250 ZW50IG9yIGxldCB0aGUgQ0ROIHRvIHJlY2VpdmUgb25lIGZvcm1hdCBhbmQgY29tcGxldGUgdGhl IHRyYW5zZm9ybWF0aW9uLCBkZXBlbmRpbmcgb24gdGhlIGNvbmNyZXRlIGJ1c2luZXNzLg0KQnkg dGhlIHNhbWUgbG9naWMsIGZvcm0gdUNETiB0byBkQ0ROLCBpdCBtYXkgYmUgZWl0aGVyIHRoZSB1 Q0ROIHRvIHByb3ZpZGUgbXVsdGktZm9ybWF0IGNvbnRlbnQgb3IgdGhlIGRDRE4gdG8gcmVjZWl2 ZSBvbmUgZm9ybWF0IGNvbnRlbnQgYW5kIHRoZW4gY29tcGxldGUgdGhlIHRyYW5zZm9ybWF0aW9u Lg0KQ3VycmVudGx5IHRoZXJlIGlzIG5vdCB0aGUgcmVhbCBDRE4tQ0ROIGNvbm5lY3Rpb24sIGhl bmNlIHdlIGFyZSBiYXNpbmcgb3VyIGtub3dsZWRnZSBvbiB0aGUgcmVsYXRlZCBzb2x1dGlvbiB0 byBtYWtlIG91ciBzb2x1dGlvbnMuDQoNCjMpICAgICBBcyBmb3IgdGhlIHByb2NlZHVyZSBvZiBj b250ZW50IGFkYXB0YXRpb24sIEkganVzdCBkcmFmdCBhIGRpYWdyYW0gYXMgYmVsb3c6DQo8aW1h Z2UwMDQucG5nPg0KDQpZb3UgbWF5IHNlZSB0aGUgc29sdXRpb24gaXMgcmF0aGVyIGNsZWFyIGFu ZCB0aGUgbWV0YWRhdGEgbmVlZGVkIHdvdWxkIGJlIGNsZWFyIGFsc28uDQoNCkRlYXIsDQpCeSBt eSBhbmFseXNpcyBhYm92ZSwgSSBraW5kbHkgaW52aXRlIHlvdXIgaWRlYXMgd2hldGhlciBpdCBt YXkgYmUgYW4gYXBwbGljYWJsZSBhbmQgc2ltcGxlIHBhcnQgaW4gdGhlIENETkkgaXRlbSwgcHJv dmlkZWQgdGhhdCB0aGUgc29sdXRpb24gaXMgb3BlbiB0byB0aGUgdHlwZXMgb2YgY29udGVudCBh ZGFwdGF0aW9uIGFuZCBtYXkgYmUgb3B0aW9uYWxseSBpbXBsZW1lbnRlZCBpbiB0aGUgcmVhbCBz b2x1dGlvbnMvYnVzaW5lc3MuIEkgZmVlbCBmb3IgdGhvc2Ugb3BlcmF0b3JzIHRoYXQgbmVlZCBz dWNoIGZ1bmN0aW9uYWxpdHkgaXQgd291bGQgYmUgdmVyeSBnb29kIHdoaWxlIGl0IGRvZXMgbm90 IGltcGFjdCBvdGhlcnMgdGhhdCBkbyBub3QgaW1wbGVtZW50IGl0Lg0KVGhhbmtzLg0KWmhpcGVu Zw0KDQoNCkZyb206IFdvdW5keSwgUmljaGFyZCBbbWFpbHRvOlJpY2hhcmRfV291bmR5QGNhYmxl LmNvbWNhc3QuY29tXTxtYWlsdG86W21haWx0bzpSaWNoYXJkX1dvdW5keUBjYWJsZS5jb21jYXN0 LmNvbV0+DQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSA3OjIzIFBNDQpUbzogWmhv dVpoaXBlbmc7ICdtYXJrQGpldC1zdHJlYW0ubmw8bWFpbHRvOidtYXJrQGpldC1zdHJlYW0ubmw+ JzsgJ2FsYW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29tPG1haWx0bzonYWxhbi5rYXZhbmFnaEBlcmlj c3Nvbi5jb20+Jw0KQ2M6ICdjZG5pQGlldGYub3JnPG1haWx0bzonY2RuaUBpZXRmLm9yZz4nOyBX b3VuZHksIFJpY2hhcmQNClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KPkluIHlvdXIgY29tcGFueeKAmXMgd2Vic2l0ZSwg SSBqdXN0IGZpbmQgc29tZSBpbmZvcm1hdGlvbg0KDQpJIGhhdmUgdG8gc3RlcCBpbiBhcyBjby1j aGFpciBoZXJlLg0KDQpUaGUgZ29hbCBvZiB0aGlzIFdHIGlzIG5vdCB0byBhbGlnbiB2ZW5kb3Ig cHJvZHVjdCByb2FkbWFwcywgb3IgdG8gZXF1YWxpemUgYWxsIHZlbmRvciBvZmZlcmluZ3MsIG9y IHRvIHNwZWNpZnkgdGhlIGVudGlyZSBDRE5JIGVjb3N5c3RlbS4gVGhlIGdvYWwgb2YgdGhpcyBX RyBpcyB0byBlbmFibGUgdGhlIGludGVyY29ubmVjdGlvbiBhbmQgaW50ZXJvcGVyYXRpb24gb2Yg dHdvIG9yIG1vcmUgQ0ROcywgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIENETkkgd2cgY2hhcnRl ci4NCg0KSXQgaXMgT0sgdG8gaGF2ZSBhIGRpc2N1c3Npb24gYWJvdXQgd2hldGhlciBjb250ZW50 IGFkYXB0YXRpb24gbmVlZHMgdG8gYmUgcGVyZm9ybWVkIGJ5IHRoZSBkQ0ROLCBzaW5jZSB0aGF0 IGRlY2lzaW9uIGltcGFjdHMgdGhlIHVDRE4tZENETiBpbnRlcmZhY2UuIFNvIGxldCdzIGZpbmQg YSBwcm9kdWN0aXZlIHdheSB0byBkaXNjdXNzIHRoaXMgb24gdGhlIG1haWxpbmcgbGlzdCwgYW5k IHRvIGNsb3NlIHRoZSBkaXNjdXNzaW9uIGJ5IElFVEYgODIgKGlmIG5vdCBzb29uZXIpLg0KDQpD YW4gc29tZW9uZSBkZXNjcmliZSByZWFsLWxpZmUgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBD RE4gKG9yIGVkZ2UgY2FjaGUtYmFzZWQpIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBuZWVkZWQgdG9k YXkgaW4gYSBwcm9kdWN0aW9uIGVudmlyb25tZW50LCBvciBzaG9ydGx5PyBOb3QgbWVyZWx5IGEg ZmVhdHVyZSBpbiBhIHZlbmRvcidzIHByb2R1Y3QgbWF0ZXJpYWxzPw0KDQpTcGVha2luZyBhcyBh biBpbmRpdmlkdWFsLCBJIGNhbiBmaW5kIGEgbG90IG9mIGV4YW1wbGVzIHdoZXJlIGRvd25zdHJl YW0gY29udGVudCBhZGFwdGF0aW9uIGlzIG5vdCBuZWVkZWQsIGFuZCBhbnkgYWRhcHRhdGlvbiBp cyByZWFsbHkgcGFydCBvZiB0aGUgQ1AgLSB1Q0ROIGludGVyZmFjZSAod2hpY2ggaXMgb3V0IG9m IHRoZSBzY29wZSBvZiBvdXIgY2hhcnRlcikuDQoNCi0tIFJpY2gNCg0KDQpGcm9tOiBaaG91Wmhp cGVuZyBbbWFpbHRvOnpob3V6aGlwZW5nQGh1YXdlaS5jb21dPG1haWx0bzpbbWFpbHRvOnpob3V6 aGlwZW5nQGh1YXdlaS5jb21dPg0KU2VudDogVGh1cnNkYXksIE9jdG9iZXIgMjcsIDIwMTEgMDM6 NDUgQU0NClRvOiBNYXJrIGRlIEpvbmcgPG1hcmtAamV0LXN0cmVhbS5ubDxtYWlsdG86bWFya0Bq ZXQtc3RyZWFtLm5sPj47IEFsYW4gS2F2YW5hZ2ggPGFsYW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29t PG1haWx0bzphbGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbT4+DQpDYzogY2RuaUBpZXRmLm9yZzxt YWlsdG86Y2RuaUBpZXRmLm9yZz4gPGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+ Pg0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNh c2VzLTAwLnR4dA0KDQpIZWxsbyBNYXJrLA0KTmljZSB0byBtZWV0IHlvdSBvbiBsaW5lLg0KSW4g eW91ciBjb21wYW554oCZcyB3ZWJzaXRlLCBJIGp1c3QgZmluZCBzb21lIGluZm9ybWF0aW9uIHRo YXQgYWRkcmVzc2VzIOKAnCBWb2RhZm9uZSBzdWJzY3JpYmVycyBjb21wbGFpbmVkIGFib3V0IHZp ZGVvIHBlcmZvcm1hbmNlLuKAnQ0KU2VlOg0KaHR0cDovL3d3dy5qZXQtc3RyZWFtLm5sL3NlYXJj aC8/c2VhcmNoPXRyYW5zY29kaW5nDQoNCkRlYXIgYWxsIGluIHRoaXMgZ3JvdXAsDQpJbiBsYXN0 IGZldyBkYXlzLCBleGNlcHQgdGhlIHB1YmxpYyBlbWFpbCBkaXNjdXNzaW9ucyBJIGhhdmUgY29u dGFjdGVkIHdpdGggc29tZSBwZW9wbGUgYW5kIGRpc2N1c3NlZCB3aXRoIG15IG93biBjb2xsZWFn dWVzIG9mIGFsbCBkZXRhaWxzIG9uIHRoaXMgaXNzdWUuDQpGaXJzdCwgYWx0aG91Z2ggdGhlIG1h cmtldCByZXF1aXJlbWVudCBmb3IgaXQgaXMgdmVyeSBpbXBvcnRhbnQsIEkgZmVlbCBJ4oCZZCBi ZXR0ZXIgc2hvdyB1cCBtb3JlIGluZm9ybWF0aW9uIG9uIHRoZSBwcm9jZWR1cmUgaW52b2x2ZWQu IEkgaGF2ZSBleHBsYWluZWQgbWFueSB0aW1lcyB0aGF0IHRvIHN1cHBvcnQgY29udGVudCBhZGFw dGF0aW9uIGlzIHJhdGhlciBzaW1wbGUgd2hpbGUgdGhlIHdvcmRpbmcgaXMgbm90IGVub3VnaC4N CkkgYW0gYnVzeSBtYWtpbmcgc29tZSBjb250cmlidXRpb25zIG9uIHRoaXMgYW5kIHBsYW4gdG8g dXBsb2FkIHRvIEVUU0kgbWVldGluZyBhbmQgSUVURiBDRE5JLg0KQnkgdGhlc2Ugd29yayAgSSBm ZWVsIHRoZSBwZW9wbGUgbWF5IGNhdGNoIGEgd2hvbGUgdmlldyBvbiB0aGlzIGlzc3VlLg0KU2Vj b25kLCBmb3IgdGhhdCBmdW5jdGlvbmFsaXR5LCBpbiBpbXBsZW1lbnRhdGlvbiwgaWYgc29tZSBl bnRpdHkgZG9lcyBub3QgY2hvb3NlIHRvIHN1cHBvcnQgaXQsIGl0IG1heSBiZSBvay4gU2luY2Ug aXQgbWF5IGJlIG5lZ290aWF0ZWQgYmV0d2VlbiAgdHdvIENETnMuDQpJZiBkQ0ROIGRvZXMgbm90 IHN1cHBvcnQgdGhhdCwgaXQgbWF5IGJlIHRoZSB1Q0ROIHJlc3BvbnNpYmxlIHRvIGNvbXBsZXRl IHRoZSB0cmFuc2NvZGluZyBhbmQgZGVsaXZlciB0aGUgY29udGVudCBvZiBtdWx0aXBsZSBmb3Jt YXRzIGFuZCByYXRlcyB0byBkQ0ROLg0KVGhpcmQsIGFsdGhvdWdoIENETkkgaXMgYSBuZXcgYXJj aGl0ZWN0dXJlLCB3aGlsZSB0aGUgY29udGVudCBvcGVyYXRpbmcgaGFzIGJlZW4gZXhpc3RlZCBm b3IgeWVhcnMuIEFzIEkga25vdyB0aGUgY29udGVudCBmcm9tIFVTQSB0byB0aGUgZG93bnN0cmVh bSBvcGVyYXRvciBpcyB0cmFuc2ZlcnJlZCBvbiBvbmUgY29weSBhbmQgdGhlIGRvd25zdHJlYW0g b3BlcmF0b3Igd2lsbCBoYW5kbGUgdGhlIHRyYW5zY29kaW5nLg0KDQpQZXJoYXBzLCB0aGUgY29u dGVudCBhZGFwdGF0aW9uIGlzIG1vcmUgb24gdGhlIG1vYmlsZSBvcGVyYXRpbmcuIEJ1dCBJIGZl ZWwgY3VycmVudGx5IG1vc3Qgb3BlcmF0b3Igd2lsbCBiZSBhIGFsbCBzZXJ2aWNlIG9wZXJhdG9y LiBBbmQgZm9yIHRoZSBDRE4gcHJvdmlkZXJzLCBpdCBtYXkgYmUgYmV0dGVyIHRvIHN1cHBvcnQg YWxsIGtpbmRzIG9mIHNlcnZpY2UuDQpCZXNpZGVzLCBJIGxpa2Ugc2F5IHRoYXQgdGhlIHRlY2hu b2xvZ3kgb24gdGhpcyB0b3BpYyBoYXMgYmVlbiBmb3IgbWFueSB5ZWFycyBhbmQgaGFzIGJlZW4g cmF0aGVyIG1hdHVyZSwgZXZlbiBzb21lIGl0ZW1zIGluIGlldGYgc3VjaCBhcyByZmMzNTA3ICBp Y2FwLiBTbyBmcm9tIHRoZSB0ZWNobmlxdWUgcG9pbnQgb2YgdmlldywgaXQgaXMgYSBuYXR1cmUg YWN0aW9uIHRvIGJlIGludm9sdmVkIGluIENETiBpbnRlcmNvbm5lY3Rpb24uDQpUaGFua3MuDQpa aGlwZW5nDQoNCg0KDQoNCkZyb206IE1hcmsgZGUgSm9uZyBbbWFpbHRvOm1hcmtAamV0LXN0cmVh bS5ubF08bWFpbHRvOlttYWlsdG86bWFya0BqZXQtc3RyZWFtLm5sXT4NClNlbnQ6IFRodXJzZGF5 LCBPY3RvYmVyIDI3LCAyMDExIDQ6MjEgQU0NClRvOiBBbGFuIEthdmFuYWdoDQpDYzogQmVuIE5p dmVuLUplbmtpbnM7IFpob3VaaGlwZW5nOyBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNl LWNhc2VzLTAwLnR4dA0KDQpIaSBBbGFuLA0KDQpBcyBCZW4gc3RhdGVkIHRoZSBvdmVyYWxsIGRp c2N1c3Npb24gcmlnaHQgbm93IGlzIGFib3V0IGRlbGl2ZXJ5LCBub3Qgb24gYWRhcHRhdGlvbi4g SXQgaXMgaGFyZCBlbm91Z2ggdG8gZ2V0IGNvbnNlbnN1cyBvbiB0aGUgZGVsaXZlcnkgYXNwZWN0 IGFscmVhZHkgbm90IHRvIG1lbnRpb24geW91ciByZXF1aXJlbWVudCBmcm9tIGNvbnRlbnQgYWRh cHRhdGlvbiBhZGRlZCB0byB0aGF0LCBzbyBJIGFncmVlIHdpdGggQmVuIHdlIHNob3VsZCBzdGlj ayB3aXRoIHRoZSBkZWxpdmVyeSBhc3BlY3QgZm9yIHRoZSBmaXJzdCBzcGVjcy4gSSBjYW4gaW1h Z2luZSB0aGlzIGNvdWxkIGJlIGEgZGlzY3Vzc2lvbiBsYXRlciBvbiBidXQgcGxlYXNlIGxldCB1 cyBrZWVwIHRoZSBzY29wZSBvZiB0aGlzIGJlIGNsZWFuIGFuZCB0cmFuc3BhcmVudC4gSXQgaXMg b2YgYmVuZWZpdCBvZiBldmVyeW9uZSB0byBnZXQgdGhlIGZpcnN0IHNwZWNzIGFzIGZhc3QgYXMg cG9zc2libGUuIFRoYW5rcy4NCg0KTWV0IHZyaWVuZGVsaWprZSBncm9ldCwNCktpbmQgcmVnYXJk cywNCg0KTWFyayBkZSBKb25nDQpJbnRlcm5hdGlvbmFsIEJ1c2luZXNzIERldmVsb3Blcg0KSmV0 LVN0cmVhbSBCVg0KDQpFLW1haWw6IG1hcmtAamV0LXN0cmVhbS5jb208bWFpbHRvOm1hcmtAamV0 LXN0cmVhbS5jb20+DQpPZmZpY2U6ICszMSAoMCk1MCA1MjYxODIwDQpNb2JpbGU6ICszMSAoMCk2 IDgxMTA4MjYzDQpGYXg6ICszMSAoMCk1MCA1MjY0MjE0DQoNCi0gRXZlbnQ6IE1lZXQgdXMgYXQg U3RyZWFtaW5nIE1lZGlhIEV1cm9wZSwgMTctMTggT2N0b2JlciwgTG9uZG9uLCBVSw0KLSBFdmVu dDogTWVldCB1cyBhdCBPbmxpbmUgVmlkZW8gU3RyYXRlZ2llcywgMTkgT2N0b2JlciwgTG9uZG9u LCBVSw0KLSBFdmVudDogTWVldCB1cyBhdCBDRE4gV29ybGQgU3VtbWl0LCAyNS0yOCBPY3RvYmVy LCBMb25kb24sIFVLDQotIE5ld3M6IFByZS1yZXF1ZXN0IHlvdXIgVGVjaG5vbG9neSBXaGl0ZXBh cGVyIG5vdyBhbmQgYmUgdGhlIGZpcnN0IHRvIGhhdmUgaXQsIGNoZWNrIHd3dy5qZXQtc3RyZWFt LmNvbTxodHRwOi8vd3d3LmpldC1zdHJlYW0uY29tPg0KLSBOZXdzOiBDaGVjayBodHRwOi8vd3d3 LmpldC1zdHJlYW0uY29tIHRvIGRvd25sb2FkIG91ciAnU2l4IFRyZW5kcyBpbiBDRE5zJyBicm9j aHVyZQ0KDQotIEJsb2c6IHd3dy5qZXQtc3RyZWFtLmNvbS9ibG9nLzxodHRwOi8vd3d3LmpldC1z dHJlYW0uY29tL2Jsb2cvPg0KLSBWaWRlb0V4Y2hhbmdlOiB3d3cudmRvLXgubmV0PGh0dHA6Ly93 d3cudmRvLXgubmV0Pg0KLSBTdHJlYW16aWxsYTogd3d3LnN0cmVhbXppbGxhY2RuLmNvbTxodHRw Oi8vd3d3LnN0cmVhbXppbGxhY2RuLmNvbT4NCi0gQ29ycG9yYXRlOiB3d3cuamV0LXN0cmVhbS5j b208aHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbT4NCg0KT24gMjYsIE9jdCwyMDExLCBhdCA4OjMz IFBNLCBBbGFuIEthdmFuYWdoIHdyb3RlOg0KDQpCZW4NCg0KSW0gYXNzdW1pbmcgdGhlbiBiYXNl ZCBvbiB5b3VyIGNvbW1lbnRzIGJlbG93IGFyZSB5b3Ugc3VnZ2VzdGluZyB3ZSBhcmUgZ29pbmcg dG8gaGF2ZSBhIG51bWJlciBvZiB2ZXJzaW9ucyBvZiB0aGUgQ0ROLUkgTWV0YWRhdGE/DQoNCkkg c3ltcGF0aGlzZSB3aXRoIHdoYXQgeW91IGFyZSBwb2ludGluZyBvdXQgYmVsb3cgYW5kIGRvIGFn cmVlIHRoYXQgdGhlcmUgaXMgc29tZSB3b3JrIHRvIGJlIGRvbmUsIGJ1dCBJIHN0aWxsIGZlZWwg dGhhdCBjb250ZW50IGFkYXB0YXRpb24gaXMgdG8gbWUgYSBmdW5kYW1lbnRhbCByZXF1aXJlbWVu dCB0byB3aGF0IGNvbGxlY3RpdmVseSB3ZSBzaG91bGQgYWRkcmVzcyBpbiB0aGUgQ0ROLUkgV0cu IEkgZG8gYWdyZWUgd2l0aCB5b3UgdGhhdCBjb250ZW50IGFkYXB0YXRpb24gaXMgYW4gb3B0aW1p emF0aW9uIGJldHdlZW4gQ0ROJ3MgYnV0IGl0J3MgYSB2ZXJ5IGltcG9ydGFudCBvbmUgdGhhdCBJ IGtub3cgTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVycyBwYXJ0aWN1bGFybHkgcmVxdWlyZS4NCg0K QWxhbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2RuaS1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86Y2RuaS1ib3VuY2Vz QGlldGYub3JnXTxtYWlsdG86W21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhh bGYgT2YgQmVuIE5pdmVuLUplbmtpbnMNClNlbnQ6IE9jdG9iZXItMTItMTEgMToxMyBQTQ0KVG86 IFpob3VaaGlwZW5nDQpDYzogY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0w MC50eHQNCg0KWmhpcGVuZywNCg0KT24gMTIgT2N0IDIwMTEsIGF0IDEwOjIyLCBaaG91WmhpcGVu ZyB3cm90ZToNCkhlbGxvIEJlbiwNClRoZSBVRSBtYXkgc2VsZWN0IHRoZSBjb250ZW50IGZvcm1h dCBvbiB0aGUgQ1Agd2ViLiBBZnRlciB0aGF0IHRoZSB1c2VyIG9ubHkgZGVzaXJlcyB0byBnZXQg aGlzIHNlbGVjdGVkIGNvbnRlbnQuDQpCdXQgaG93IHRoZSBjb250ZW50IGlzIHRyYW5zZmVycmVk IHRvIHRoZSBjbGllbnQgaXMgbm90IHdvcnJpZWQgYnkgdGhlIHVzZXIuDQpUaGUgQ1AgbWF5IGNy ZWF0ZSBhIHNwZWNpYWwgZm9ybWF0IGFzIHJlcXVpcmVkIGJ5IHRoZSB1c2VyIGFuZCBhc2sgdGhl IENETiB0byBkZWxpdmVyIHRvIHVzZXIuDQpXaGlsZSBDUCBtYXkgZ2l2ZSBhIEhEIGZvcm1hdCBj b250ZW50IHRvIHVDRE4gYW5kIHRoZSBkQ0ROIG1heSB0aGVuIHRyYW5zZm9ybSB0byB0aGUgZm9y bWF0IGFzIHRoZSB1c2VyIHNlbGVjdC4NCg0KTG90cyBvZiB0aGluZ3MgbWF5IGJlIHBvc3NpYmxl IHRvIGRvIGFuZCBDRE4gcHJvdmlkZXJzIG9mZmVyIG1hbnkgYWRkaXRpb25hbCBzZXJ2aWNlcyBv biB0b3Agb2YgdGhlICJjb3JlIiBzZXJ2aWNlIG9mIGNvbnRlbnQgZGVsaXZlcnkuIEhvd2V2ZXIs IG91ciBvYmplY3RpdmUgKGJhc2VkIG9uIG15IGludGVycHJldGF0aW9uIG9mIHRoZSBDRE5JIGNo YXJ0ZXIpIGlzIHRvIGZvY3VzIG9uIHdoYXQgaXMgbmVjZXNzYXJ5IHRvIGludGVyY29ubmVjdCBD RE5zIHRvIGRlbGl2ZXIgY29udGVudCBmcm9tIGEgQ1NQIHRvIGFuIEVuZCBVc2VyIHRoYXQgaXMg dGFyZ2V0ZWQgYW5kIGRlcGxveWFibGUgd2l0aGluIGEgc2hvcnQgdGltZSBmcmFtZSAoMTgtMjQg bW9udGhzKS4NCg0KQ29udGVudCB0cmFuc2Zvcm1hdGlvbi9hZGFwdGF0aW9uIGlzIG5vdCBhbiBl c3NlbnRpYWwgcmVxdWlyZW1lbnQgaW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGF0IGFpbSAod2UgY2Fu IGRlbGl2ZXIgY29udGVudCBmcm9tIENTUHMgdG8gRW5kIFVzZXJzIHZpYSBtdWx0aXBsZSBDRE5z IHdpdGhvdXQgbmVlZGluZyBvciByZXF1aXJpbmcgYW55IENETiBzdXBwb3J0cyBjb250ZW50IGFk YXB0YXRpb24pLg0KDQpJbiBteSBvcGluaW9uIHdlIGhhdmUgZW5vdWdoIHdvcmsgdG8gZG8gYWxy ZWFkeSB3aXRob3V0IHRyeWluZyB0byBleHBhbmQgdGhlIHNjb3BlIG9mIG91ciB3b3JrIHRvIGlu Y2x1ZGUgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgdGhhdCBkbyBub3QgaGVscCB1cyBhZGRyZXNz IG91ciBjb3JlIG9iamVjdGl2ZXMgYXMgbGFpZCBvdXQgaW4gdGhlIENETkkgY2hhcnRlci4NCklu IHRoaXMgY2FzZSwgaXQgaXMgbm90aGluZyByZWxhdGVkIHRvIGhvdyB0aGUgdXNlciBzZWxlY3Qg Zm9ybWF0cyBvbiBDUCB3ZWJzaXRlLg0KU28sIGl0IGlzIHRoZSBDUCBhbmQgdXNlciB0byBkZWNp ZGUgdGhlIGNvbnRlbnQgZm9ybWF0IG5vdCB0aGUgQ0ROKHlvdXIgYXNzZXJ0IGlzIG5vdCBjb3Jy ZWN0IGFuZCBzZWVtcyB5b3UgdGFrZSB0aGF0IGFzc2VydCBhcyB5b3VyIGJhc2UgZm9yIHRoZSBk aXNjdXNzaW9uKS4NCg0KQXMgZm9yICJ0aGUgY29yZSBDRE4gZnVuY3Rpb25hbGl0eSBvZmZlcmVk IGJ5IENETnMgdG9kYXkiLCBJIGhhdmUgZXZlciByYWlzZWQgYW4gZW1haWwgYmVmb3JlIHRoYXQg eW91ciBjb21wYW55J3Mgd2VicGFnZSBoYXMgY2xhaW1lZCBzdXBwb3J0aW5nIG1lZGlhIHRyYW5z Zm9ybWF0aW9uIGFuZCBtdWx0aS1zY3JlZW4gc2VydmljZS4NClBlcmhhcHMsIEkgbGlrZSBhc2tp bmcgeW91IGxpc3Qgc29tZSBmZWF0dXJlcyB0aGF0IHlvdSBmZWVsIGFyZSB0aGUgY29yZSBmdW5j dGlvbmFsaXRpZXMgYnkgZXhpc3RpbmcgbWFpbiBzdHJlYW0gQ0ROcy4gVGh1cyB3ZSBtYXkgY29t cGFyZSBhbmQgdGFrZSBkZWVwIGxvb2suDQoNCkkgdGhpbmsgdGhlIGNvcmUgZnVuY3Rpb25hbGl0 eSBtYXBzIHByZXR0eSB3ZWxsIHRvIHRoZSBDRE5JIGludGVyZmFjZXMsIG5hbWVseTogUmVxdWVz dCBSb3V0aW5nLCBNZXRhZGF0YSBjb25maWd1cmF0aW9uLCBsb2cgcHJvZHVjdGlvbiBhbmQgY29u dHJvbCBwbHVzIGNvbnRlbnQgYWNxdWlzaXRpb24gYW5kIGNvbnRlbnQgZGVsaXZlcnkuDQpJIGd1 ZXNzIG1hbnkgcGVvcGxlIGhhdmUgdGhlIGV4cGVyaWVuY2Uva25vd2xlZGdlIG9mIGNvbnRlbnQg cmVsYXRlZCBzZXJ2aWNlLiBUaGUgdXNlciBhbmQgQ1Agb25seSBjYXJlIHdoZXRoZXIgdGhlIENE TiBwcm92aWRlcnMgbWF5IHNhdGlzZnkgdGhlaXIgcmVxdWlyZW1lbnQgd2hpbGUgbm90IGNhcmUg dGhlIGludGVybmFsIHByb2Nlc3MuIEp1c3QgYXMgR1NNL1BTVE4gaW50ZXJjb25uZWN0aW9uLCB0 aGUgdXNlciBvbmx5IGNhcmUgc3VjY2Vzc2Z1bCBpbnRlcmNvbm5lY3Rpb24gd2hpbGUgbm90IGNh cmUgaG93IHRoZSB2b2ljZSBpcyB0cmFuc2Zvcm1lZCBpbiBwcm9jZXNzLg0KDQpCZXNpZGVzLCBJ IGxpa2UgcmFpc2UgYSBjYXNlOg0KR2l2ZW4gY3VycmVudGx5IEJCQyByZWNydWl0cyBDRE4gcHJv dmlkZXJzIHRoYXQgbWF5IHN1cHBvcnQgMTAgbWVkaWEgZm9ybWF0cy4NCk9uZSBjYW5kaWRhdGUg aXMgeW91ciBjb21wYW55LCBhbm90aGVyIGlzIENETi1YLiBUaGUgdXNlcnMgYXJlIGxvY2F0ZWQg aW4gRnJhbmNlLg0KU28gYm90aCB5b3VyIGNvbXBhbnkgYW5kIENETi1YIHNob3VsZCBjb25uZWN0 IGEgRnJhbmNlIENETiBwcm92aWRlcihDRE4tWSkuDQpJZiB5b3VyIGNvbXBhbnkncyBzb2x1dGlv biBpcyB0byBzZW5kIDEwIHN0cmVhbXMgb2YgZGlmZmVyZW50IGZvcm1hdA0Kb2Ygb25lIGNvbnRl bnQgdG8gQ0ROLVk7IFdoaWxlIENETi1YJ3Mgc29sdXRpb24gaXMgdG8gc2VuZCAxIHN0cmVhbSB0 byBDRE4tWSB3aGlsZSBDRE4tWSBtYXkgY29uZHVjdCBzb21lIGFkYXB0YXRpb24uDQpDb21wYXJp bmcgdGhlc2UgdHdvIHNvbHV0aW9ucywgZm9yIHlvdXIgY29tcGFueSBhbmQgQ0ROLVgsIGFic29s dXRlbHkgdGhlIGNvc3Qgb2YgQ0ROLVggaXMgbXVjaCBsb3dlci4NCkZvciBDRE4tWSwgaW4gc29s dXRpb24tMSwgaXQgc2hvdWxkIHJlY2VpdmUvZm9yd2FyZCAxMCBzdHJlYW1zIDsgd2hpbGUgaW4g c29sdXRpb24tMiwgaXQgc2hvdWxkIG9ubHkgcmVjZWl2ZSAxIHN0cmVhbSBidXQgbmVlZCB0byB0 YWtlIHRyYW5zZm9ybWF0aW9uIHRvIG91dHB1dCAxMCBzdHJlYW1zLg0KDQpXaGljaCBzb2x1dGlv biBpcyBtb3JlIGNvbXBldGl0aXZlLiBpdCBpcyBTb2x1dGlvbiAxLCByaWdodC4gUmVtZW1iZXIg dGhlIHByaWNlIGZyb20gQkJDIGlzIHNhbWUgdG8gYm90aCB5b3VyIGNvbXBhbnkgYW5kIENETi1Y IG9yIEJCQyB3b3VsZCBzZWxlY3Qgb25lIENETiBwcm92aWRlciB3aXRoIHRoZSBsb3dlciBwcmlj ZS4NCklmIGEgQ0ROIHByb3ZpZGVyIG1heSBub3QgZ2V0IHRoZSBjb250cmFjdCBmcm9tIENQLCBo b3cgaXQgbWF5IHNheSBpdCBpcyBub3QgYSBjb3JlIGZ1bmN0aW9uYWxpdHkuDQoNCldoYXQgeW91 IGFyZSBkZXNjcmliaW5nIGlzIGEgcG9zc2libGUgb3B0aW1pemF0aW9uIHRoYXQgYSBwYXJ0aWN1 bGFyIENETiBtYXkgd2lzaCB0byBpbXBsZW1lbnQgbm90IGEgY29yZSBmdW5jdGlvbmFsaXR5IHJl cXVpcmVkIHRvIGVuYWJsZSBjb250ZW50IGRlbGl2ZXJ5IGJldHdlZW4gaW50ZXJjb25uZWN0ZWQg Q0ROcy4gSSBjYW4gdGhpbmsgb2YgbWFueSBvcHRpbWl6YXRpb25zIHRoYXQgYSBDRE4gY291bGQg aW1wbGVtZW50IHRvIGRpZmZlcmVudGlhdGUgdGhlaXIgc2VydmljZSBidXQgdGhlIGludGVybmFs IHdvcmtpbmdzIG9mIGFuIGluZGl2aWR1YWwgQ0ROIGFyZSBvdXQgb2Ygc2NvcGUgb2Ygb3VyIGNo YXJ0ZXIuDQoNClNvIHRvIHJlcGVhdCBteSBwb3NpdGlvbiBmb3IgYSBmaW5hbCB0aW1lOiBDb250 ZW50IGFkYXB0YXRpb24gaXMgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBlbmFibGUg Y29udGVudCBkZWxpdmVyeSBiZXR3ZWVuIGludGVyY29ubmVjdGVkIENETnMgYW5kIHRoZXJlZm9y ZSBnaXZlbiB0aGUgd29ya2xvYWQgd2UgYWxyZWFkeSBoYXZlIHRvIHNwZWNpZnkgc29sdXRpb25z IHRoYXQgZG8gYWRkcmVzcyB0aGUgY29yZSBmdW5jdGlvbmFsaXR5IHJlcXVpcmVkIHRvIGludGVy Y29ubmVjdCBDRE5zIEkgZG8gbm90IHRoaW5rIHdlIHNob3VsZCBiZSB0cnlpbmcgdG8gYWRkIG1v cmUgd29yayBpbnRvIHRoYXQgd29ya2xvYWQgYXMgaXQgd2lsbCBvbmx5IGRpc3RyYWN0IHVzIGZy b20gYWNoaWV2aW5nIG91ciBnb2FsIG9mIHByb2R1Y2luZyBkZXBsb3lhYmxlIHNvbHV0aW9ucyB3 aXRoaW4gdGhlIHRpbWVmcmFtZSB3ZSBhcmUgYmVpbmcgdG9sZCBieSBvcGVyYXRvcnMgdGhleSBu ZWVkcyBzb2x1dGlvbnMgd2l0aGluLg0KDQpCZW4NClNvLCBpZiB3ZSBhbGwgcmVhbGl6ZSB0aGF0 IGN1cnJlbnRseSB0aGUgbWVkaWEgdHlwZSBpcyByaWNoLCB0aGUgQ0ROIHByb3ZpZGVycyBzaG91 bGQgc3Vydml2ZSBpbiB0aGUgZXhpc3RpbmcgZWNvc3lzdGVtIGFuZCBzdXBwb3J0IHRoZSBtZWRp YSB0eXBlcyBhcyByZXF1aXJlZCBieSB0aGUgbWFya2V0Lg0KDQpCYWNrIHRvIHRoZSBjYXNlIG9m IEdTTS9HLjcxMSwgaXQganVzdCB3aGVuIGNvbmNlcm5pbmcgdGhlIGludGVyY29ubmVjdGlvbiwg dGhlIHRyYW5zZm9ybWF0aW9uIHNob3VsZCBhdCBvbmNlIGJlIHNvbHZlZC4gT3RoZXJ3aXNlIHRo ZSBpbnRlcmNvbm5lY3Rpb24gbWF5IG5vdCBiZSBvcGVyYXRlZC4NCg0KQnIsDQpaaGlwZW5nDQoN Cg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCZW4gTml2ZW4tSmVua2lu cyBbbWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrXTxtYWlsdG86W21haWx0bzpiZW5Abml2 ZW4tamVua2lucy5jby51a10+DQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIwMTEgMTI6 MTkgQU0NClRvOiBaaG91WmhpcGVuZw0KQ2M6IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxtYWlsdG86 cGhpbGlwLmVhcmRsZXlAYnQuY29tPjsgY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1j YXNlcy0wMC50eHQNCg0KWmhpcGVuZywNCg0KT24gMTEgT2N0IDIwMTEsIGF0IDA1OjE2LCBaaG91 WmhpcGVuZyB3cm90ZToNCg0KQmVuIGFuZCBQaGlsaXAsDQpJIGxpa2UgdG8gcmVzcG9uZCB5b3Vy IGNvbmNlcm4gaW4gdGhpcyBvbmUgZW1haWw6DQoNCkJlbiwNCkkgZmVlbCB3aGF0IHdlIGFyZSBu b3cgZGlzY3Vzc2luZyBpcyB3aGF0IGlzIHRoZSAiY29yZSIgZnVuY3Rpb24gb2YgQ0ROLg0KQXMg eW91IHNheSwgQ0ROIGlzIHVzZWQgdG8gZGVsaXZlciBjb250ZW50LiBUaGF0IGlzIGFic29sdXRl bHkgY29ycmVjdCB0aGF0IHRoZSBkZWxpdmVyeSBjYXBhYmlsaXR5IGlzIHRoZSBjb3JlIHJlcXVp cmVtZW50IGZvciBDRE4gc3lzdGVtLg0KV2hpbGUgQ0ROIGlzIHVzZWQgdG8gcHJvdmlkZSB0aGUg Y29udGVudCBkZWxpdmVyeSBzZXJ2aWNlLg0KV2hhdCBtZWFucyBzZXJ2aWNlLiBJdCBzaG91bGQg aW5jbHVkZSAidGltZSIgImxvY2F0aW9uIiBhbmQgIm1lZGlhIHR5cGUiLCBldGMuIFRoZXNlIGZl YXR1cmVzIGFyZSBhbGwgdGhlIGNvcmUgZmVhdHVyZSBmb3IgYSBzZXJ2aWNlLg0KSWYgd2Ugb25s eSBjb25jZXJuICJkZWxpdmVyaW5nIG9uZSBkYXRhIGJsb2NrIiwgSSBhbSBub3Qgc3VyZSB3aGV0 aGVyIHRoZSBpc3N1ZXMgc3VjaCBhcyAibG9nZ2luZyIgImdlb2dyYXBoaWMgY29uc3RyYWludCIg YXJlIHRoZSBjb3JlIG9mIENETi4NCg0KRm9yICJ3aXRob3V0IGV4cGxpY2l0IGtub3dsZWRnZSBv ZiB3aGF0IHRoYXQgY29udGVudCBhY3R1YWxseSBpcyAiLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIg dGhlIHdvcmRpbmcgaXMgYWNjdXJhdGUgc2luY2UgZ2VuZXJhbGx5IGEgQ0ROIG1heSBjbGFpbSBp dCBzdXBwb3J0IGRpZmZlcmVudCBtZWRpYXMuDQpCeSB0aGlzIG9wcG9ydHVuaXR5LCBJIGxpa2Ug dG8gc2hhcmUgYSB1c2UgY2FzZTogYSBjYWxsIGZyb20gYSBHU00gcGhvbmUgdG8gYSBQU1ROIHRl bGVwaG9uZSwgdGhlIHZvaWNlIHN0cmVhbSBzaG91bGQgYmUgdHJhbnNmb3JtZWQgZnJvbSBHU00g dm9pY2UgdG8gRy43MTEuDQpGb3IgdGhlIHVzZXIsIGhlIGRvZXMgbm90IG5lZWQgdG8ga25vdyB3 aGF0IHR5cGUgb2YgZGF0YSBoYXMgYmVlbiB0cmFuc2ZlcnJlZCwgYnV0IHRoZSBvcGVyYXRvciBo YXMgZG9uZSBzb21lIHdvcmsgdG8gaW50ZXJjb25uZWN0IHR3byBzeXN0ZW1zLCByaWdodC4NCkkg bGlrZSB0byBrbm93IHdoZXRoZXIgeW91IG1heSBhY2NlcHQgdGhhdCBteSB1c2UgY2FzZSBpcyBz aW1pbGFyIHRvIHRoaXMgY2FzZSBhYm92ZS4NCg0KSSBkb24ndCB0aGluayB5b3VyIHVzZSBjYXNl IGlzIHNpbWlsYXIgdG8gdGhlIGFuYWxvZ3kgb2YgbW9iaWxlIG5ldHdvcmtzIGJlaW5nIGludGVy Y29ubmVjdGVkIHRvIFBTVE4gbmV0d29ya3MuIEluIHRoZSBjYXNlIG9mIGNvbnRlbnQgZGVsaXZl cnkgdGhlIG5lZ290aWF0aW9uIGlzIGRvbmUgYmV0d2VlbiB0aGUgVXNlci9DbGllbnQgYW5kIHRo ZSBDb250ZW50IFByb3ZpZGVyIGFuZCB0aGUgQ0ROIGlzIGp1c3QgdXNlZCB0byBleGVjdXRlL3Bl cmZvcm0gdGhlIGRlbGl2ZXJ5IHRoYXQgaGFzIGJlZW4gbmVnb3RpYXRlZC4gVGhlIENETiBpcyBu b3QgaW52b2x2ZWQgaW4gdGhlIGRlY2lzaW9uIG1ha2luZyBvZiB3aGF0IHJlcHJlc2VudGF0aW9u cyB0aGUgQ29udGVudCBQcm92aWRlciBkZWNpZGVzIHRvIG9mZmVyIHRvIHRoZSBVc2VyL0NsaWVu dCBvciBpbiB3aGF0IHJlcHJlc2VudGF0aW9ucyB0aGUgVXNlci9DbGllbnQgZGVjaWRlcyB0byBy ZXF1ZXN0Lg0KDQpBcyBmb3IgeW91IHNhaWQgc2VsZWN0aW5nIG1lZGlhIGJ5IHRoZSAicG9ydGFs IiwgeW91IG1heSBzZWUgdGhlIHdheSAiIHVDRE4gZGVsaXZlcnMgbXVsdGlwbGUgbWVkaWEgc3Ry ZWFtcyB0byBkQ0ROIiBpcyBub3QgZ29vZCB0aGFuICJ1Q0ROIGRlbGl2ZXJzIG9uZSBtZWRpYSBz dHJlYW0gdG8gZENETiBhbmQgZENETiB0YWtlcyBzb21lIGFkYXB0YXRpb24gdG8gc3VwcG9ydCBt dWx0aXBsZSBtZWRpYSB0eXBlcyIuDQoNCk5vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0IGlz IGFuIG9wdGltaXNhdGlvbiwgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBhY3R1YWxs eSBkZWxpdmVyIHRoZSBjb250ZW50IChhbmQgcmVwb3J0LCBiaWxsLCBldGMuIGZvciB0aGF0IGRl bGl2ZXJ5KS4NCg0KTXkgcG9zaXRpb24gaXMgdGhhdCB3ZSBzaG91bGQgZm9jdXMgb24gaG93IHRv IGVuYWJsZSB0aGUgaW50ZXJjb25uZWN0aW9uIG9mIHRoZSBjb3JlIENETiBmdW5jdGlvbmFsaXR5 IG9mZmVyZWQgYnkgQ0ROcyB0b2RheSAod2hpY2ggaXMgYWxzbyBteSBpbnRlcnByZXRhdGlvbiBv ZiB0aGUgc2NvcGUgb2YgdGhlIENETkkgd29ya2luZyBncm91cCBhcyBleHByZXNzZWQgaW4gaXRz IGNoYXJ0ZXIpIGJlY2F1c2UgZG9pbmcgc28gaXMgYSBzaWduaWZpY2FudCBwaWVjZSBvZiB3b3Jr IGluIGl0c2VsZi4gTGV0J3Mgbm90IHN0YXJ0IHRyeWluZyB0byBhZGQgaW4gYWRkaXRpb25hbCBm dW5jdGlvbmFsaXR5IGJleW9uZCB3aGF0IHRoZSBtYWpvcml0eSBvZiBDRE5zIHN1cHBvcnQgdG9k YXkgYXMgdGhhdCB3aWxsIGp1c3QgZGVsYXkgdXMgZ2V0dGluZyB1c2FibGUgc3BlY2lmaWNhdGlv bnMgaW50byB0aGUgbWFya2V0IGluIGEgdGltZWx5IGZhc2hpb24gSU1PLg0KDQpCZW4NCg0KQSBn b29kIHF1ZXN0aW9uIGlzICJzZWN1cml0eSIgc2luY2UgSSBoYXZlIGRvbmUgc2l4IHllYXJzIG9u IHRoZSBEUk0NCmFuZCBsaWtlIHRvIHByb21vdGUgdGhlIERSTSBhbGwgYXJvdW5kIHRoZSB3b3Js ZDopIElmIHRoZSBjb250ZW50IGlzIG5lZWRlZCB0byBiZSBwcm90ZWN0ZWQsIGdlbmVyYWxseSB5 b3UgbWF5IGtub3cgYWxsIHRoZSBzeXN0ZW1zIHNob3VsZCBiZSBncmFudGVkIGJ5IHRoZSBjb250 ZW50IG93bmVyLg0KSGVyZSBJIGFsc28gbGlrZSB0byBjbGFyaWZ5IHRoYXQgbm90IG9ubHkgdGhl IG1lZGlhIGl0c2VsZiBidXQgdGhlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gc2VydmljZSBpdHNl bGYgKHN1Y2ggYXMgdGhlIGdlb2dyYXBoaWMgY29uc3RyYWludCkgc2hvdWxkIGJlIHByb3RlY3Rl ZCBhbHNvLg0KU28sIHRydXN0IGlzIG5vdCBhIHByb2JsZW0gZm9yIHRoZSBtZWRpYS4NCg0KUGhp bGlwLA0KVGhhbmsgeW91IHRoYXQgeW91IGZlZWwgQ29udGVudCBBZGFwdGlvbiBpcyBhbiBpc3N1 ZSBmb3IgIlJlcXVpcmVtZW50cyIgYnV0IEkgZG8gbm90IGtub3cgd2h5IGl0IGlzIG5vdCBmb3Ig VXNlIGNhc2UuDQpJIGxpa2UgdG8gY2xhcmlmeSB0byBVIHRoYXQgaXQgaXMgaW1wb3J0YW50IGZv ciB5b3Ugb3BlcmF0b3Igc2luY2UgaXQgbWF5IHNhdmUgaW52ZXN0bWVudCBpZiB0aGUgc3lzdGVt IG1heSBzdXBwb3J0IGRpZmZlcmVudCBzZXJ2aWNlcy4NCkZvciB1cyB2ZW5kb3IsIHdlIGFyZSBo YXBweSBvcGVyYXRvciBtYXkgaW5zdGFsbCBhIHN5c3RlbSBmb3IgdGhlIG1vYmlsZSBzZXJ2aWNl IGFuZCBhbm90aGVyIHN5c3RlbSBmb3IgdGhlIEZCQiBzZXJ2aWNlLg0KQnV0IHRoZSByZWFsaXR5 IGlzIGFsbCBvcGVyYXRvcnMgYXNrIHVzIHRvIHByb3ZpZGUgYSBzeXN0ZW0gdGhhdCBtYXkgc3Vw cG9ydCBkaWZmZXJlbnQgc2VydmljZSBzeXN0ZW1zLg0KDQpGcmFua2x5LCBCZW4gYW5kIFBoaWxp cCwgSSByZW1lbWJlciBJIGhhdmUgZXhwbGFpbmVkIHNvbWV3aGVyZSB0aGF0IHRvIGltcGxlbWVu dCB0aGlzIGlzIHJhdGhlciBzaW1wbGUgLg0KQXQgbGVhc3QgdGhlIFVzZSBjYXNlIGFuZCBSZXF1 aXJlbWVudCBhcmUgaW5mb3JtYXRpb25hbCB0byBiZSByZWZlcnJlZCBpbiBmdXR1cmUgd29yay4g U28gSSBkbyByZWFsbHkgZmVlbCB5b3UgbWF5IGFjY2VwdCBpdC4NCk9mIGNvdXJzZSBJIGxpa2Ug dG8gcmVzcG9uZCB5b3VyIG1vcmUgY29uY2VybiBhbmQgY29tbWVudHMuDQpUaGFua3MuDQpaaGlw ZW5nDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGhpbGlwLmVhcmRs ZXlAYnQuY29tPG1haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20+IFttYWlsdG86cGhpbGlwLmVh cmRsZXlAYnQuY29tXTxtYWlsdG86W21haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb21dPg0KU2Vu dDogTW9uZGF5LCBPY3RvYmVyIDEwLCAyMDExIDExOjIyIFBNDQpUbzogYmVuQG5pdmVuLWplbmtp bnMuY28udWs8bWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPjsgWmhvdVpoaXBlbmcNCkNj OiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtDRE5p XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQpCZW4sIFpo aXBlbmcsIGFsbCwNCg0KSSB0aGluayB0aGF0IENvbnRlbnQgQWRhcHRhdGlvbiBpcyBtb3JlIGFu IGlzc3VlIGZvciB0aGUgUmVxdWlyZW1lbnRzIGRvYyB0aGFuIGZvciB0aGUgVXNlIGNhc2VzIGRy YWZ0Lg0KDQpUaGUga2V5IHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ugd2FudCB0aGUgQ0ROSSBpbnRl cmZhY2VzIHRvIGJlIGFibGUgdG8gY29wZSB3aXRoIGEgc2NlbmFyaW8gd2hlcmUgKHNheSkgSEQv U0QgY29udmVyc2lvbiBpcyBkb25lIGluIHRoZSBkQ0ROICYgdG8gc2lnbmFsIGFib3V0IHRoaXMu DQoNCkkgdGhpbmsgdGhhdCBjb3Bpbmcgd2l0aCB0aGlzIHNjZW5hcmlvIGlzIGEgc2Vjb25kIG9y ZGVyIHJlcXVpcmVtZW50LCBpZSB3ZSBzaG91bGQgbm90IHdvcnJ5IGFib3V0IGl0IGluIHRoZSBp bml0aWFsIHN0YW5kYXJkcy10cmFjayB3b3JrLiBJIGRvbid0IGtub3csIGRpZCB3ZSBldmVyIGRl Y2lkZSB3aGV0aGVyIHRoZSBVc2UgY2FzZXMgZG9jIGlzIHJlc3RyaWN0ZWQgdG8gImluaXRpYWwi IHNjZW5hcmlvcywgb3Igd2hldGhlciBpdCdzIGFsbC1lbmNvbXBhc3NpbmcsIGllIGNvdmVyaW5n ICJmdXR1cmUiIHNjZW5hcmlvcyBhcyB3ZWxsPw0KDQpTY290dCwNClJlYWRpbmcgc29tZSBvZiB5 b3VyIGV4YW1wbGVzLCB0aGV5IHNlZW0gdG8gYmUgdmFsaWQgZXZlbiBpZiBjb250ZW50IGFkYXB0 YXRpb24gKEhEL1NEKSBpcyBvdXQgb2Ygc2NvcGUuDQotIGEgZENETiBtaWdodCBmb3Igc29tZSBy ZWFzb24gYmUgdW53aWxsaW5nIHRvIGRpc3RyaWJ1dGUgSEQ/DQotIGEgQ1NQIG1pZ2h0IHdhbnQg dG8gbWFrZSBzdXJlIHRoZSBkQ0ROIGNhbiB1c2UgSExTIGVuY2Fwc3VsYXRpb24/DQpCdXQgdGhl c2Ugc29ydHMgb2YgZXhhbXBsZXMgc2VlbSB0byBiZSBzdGF0aWMgcG9saWN5IHRoaW5ncyAodG8g ZG8NCndpdGggdGhlIGNhcGFiaWxpdGllcyAmIHByZWZlcmVuY2VzIG9mIHRoZSBDRE5zICYgQ1NQ KSwgcmF0aGVyIHRoYW4NCm1ldGFkYXRhIGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIgcGll Y2Ugb2YgY29udGVudC4gSW4gdGhlDQpkaXNjdXNzaW9uIHNvIGZhciwgSSB0aGluayBuZWdvdGlh dGlvbiBhYm91dCBzdGF0aWMgcG9saWN5IHN0dWZmIGlzDQpyYXRoZXIgb3V0IG9mIHNjb3BlKD8p DQoNCk9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiBp cyB3aGV0aGVyIHRydXN0IGlzIHRyYW5zaXRpdmUuIERvbid0IHRoaW5rIGl0IG5lZWQgYmUgLSBq dXN0IGJlY2F1c2UgQ1NQIHRydXN0cyB1Q0ROLCBhbmQgdUNETiB0cnVzdHMgZENETiBkb2Vzbid0 IG1lYW4gdGhhdCB0aGUgQ1NQIGF1dG9tYXRpY2FsbHkgdHJ1c3RzIHRoZSBkQ0ROLiBIb3dldmVy LCBpIHN1c3BlY3QgdGhpcyBjYW4gZ2V0IGFyYml0cmFyaWx5IGNvbXBsZXggLSBzbyBvbmUgcG9z c2liaWxpdHkgaXMgdG8gc2F5IHRoYXQgd2Ugd2lsbCBvbmx5IGhhbmRsZSBjYXNlcyB3aGVyZSB0 aGUgdHJ1c3QgaXMgdHJhbnNpdGl2ZS4NCg0KQmVzdCB3aXNoZXMNCnBoaWwNCg0KDQpQaGlsaXAg RWFyZGxleQ0KUmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgU3RyYXRlZ3kNCg0KVGhpcyBlbWFpbCBj b250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlk ZW50aWFsLiBJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBu YW1lZCBhYm92ZS4gSWYgeW91J3JlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3RlIHRo YXQgZGlzY2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5nIG9yIHVzaW5nIHRoaXMgaW5mb3Jt YXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IsIHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVseSBvbiB0aGUgZW1haWwgYWRkcmVzcyBh Ym92ZS4gVGhhbmsgeW91LiBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkgcmVj b3JkIHlvdXIgZW1haWxzLg0KQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQpSZWdpc3Rl cmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKIFJlZ2lzdGVyZWQg aW4NCkVuZ2xhbmQgbm86IDE4MDAwMDANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogY2RuaS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmc+ IFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0bzpjZG5pLWJvdW5j ZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYNCk9mIEJlbiBOaXZlbi1KZW5raW5zDQpTZW50OiAxMCBP Y3RvYmVyIDIwMTEgMTI6MDQNClRvOiBaaG91WmhpcGVuZw0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFp bHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0 LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0DQoNCkNvbGxlYWd1ZXMsDQoNCklNTyBTZWN0aW9u IDUuMS4zIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIFVzZSBDYXNlcyBkcmFmdC4gQ29udGVu dCBBZGFwdGF0aW9uIChpLmUuIHRha2luZyBpbiBhIGNvbnRlbnQgaXRlbSBpbiBvbmUgZm9ybWF0 IGFuZCB0cmFuc2Zvcm1pbmcgaXQgdG8gYW5vdGhlciBmb3JtYXQgb3IgcmVwcmVzZW50YXRpb24p IGlzIG5vdCBhICJjb3JlIiBmdW5jdGlvbiBvZiBhIENETiB3aGljaCB0eXBpY2FsbHkgZGVsaXZl cnMgdGhlIGNvbnRlbnQgdGhhdCBpcyByZXF1ZXN0ZWQgd2l0aG91dCBleHBsaWNpdCBrbm93bGVk Z2Ugb2Ygd2hhdCB0aGF0IGNvbnRlbnQgYWN0dWFsbHkgaXMuDQoNCkxldCdzIG5vdCBmb3JnZXQg dGhhdCBpbiBidWlsZGluZyBhbiBlbmQgdG8gZW5kIGNvbnRlbnQgc2VydmljZSB0aGUgQ0ROIGlz IG9ubHkgb25lIGNvbXBvbmVudCBhbmQgaXMgdGhlIGNvbXBvbmVudCB0YXNrZWQgd2l0aCBleGVj dXRpbmcgdGhlIGRlbGl2ZXJ5IG9mIGEgc3BlY2lmaWMgcmVwcmVzZW50YXRpb24gKHZlcnNpb24v Y29weS9mb3JtYXQgZXRjLikgb2YgdGhlIHNlbGVjdGVkIGNvbnRlbnQgbm90IHRoZSBjb21wb25l bnQgdGFza2VkIHdpdGggZGVjaWRpbmcgKG9yIGFwcGx5aW5nIHBvbGljeSkgb24gd2hpY2ggdmVy c2lvbi9jb3B5L3JlcHJlc2VudGF0aW9uIG9mIGNvbnRlbnQgc2hvdWxkIGJlIGRlbGl2ZXJlZC4N Cg0KVGhlIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHZlcnNpb24vY29weS9yZXByZXNlbnRhdGlvbiB0 byBvZmZlciBhbmQgYWxsb3cgdG8gYmUgZGVsaXZlcmVkIHRvIGEgZ2l2ZW4gZGV2aWNlL3VzZXIg aXMgaW1wbGVtZW50ZWQgb3V0c2lkZSBvZiB0aGUgQ0ROIChlLmcuIGJ5IHRoZSAicG9ydGFsIiB3 aGVyZSB0aGUgdXNlciBmaXJzdCBtYWtlcyB0aGVpciBjb250ZW50IHNlbGVjdGlvbiBwcmlvciB0 byB0aGUgQ0ROIGJlY29taW5nIGludm9sdmVkIGluIHRoZSBkZWxpdmVyeSBvZiB0aGUgc2VsZWN0 ZWQgY29udGVudCkuDQoNCkJlbg0KDQpPbiA4IE9jdCAyMDExLCBhdCAwODoyMCwgWmhvdVpoaXBl bmcgd3JvdGU6DQoNCkZvbGxvd2luZyBTY290dCdzIGNvbW1lbnRzIG9uIHNlY3Rpb24gNS4xLjMs IEkgZmVlbCBTY290dCdzIGRlc2NyaXB0aW9uIG9uIHRoZSB1c2UgY2FzZSBvZiBIRCBhbmQgU0Qg aXMgbm90IGV4YWN0bHkgY29ycmVjdC4NCklmIG9uZSBtb3ZpZSBoYXMgdHdvIGZvcm1hdHMgb2Yg SEQgYW5kIFNELCB0aGVuIHdlIGhhdmUgdHdvIGNvbnRlbnQgd2l0aCBkaWZmZXJlbnQgaWRlbnRp Zmllci4gSW4gRFJNIHNjb3BlLCB0aGUgYmFzaWMgdW5pdCBpcyBhIGNvbnRlbnQgY29weS4NCg0K SGVyZSB0aGUgZmlyc3QgYnVsbGV0ICJhIHN1YnNldCBvZiBlbmNvZGluZ3MgZGVsaXZlcmFibGUg dG8gc3BlY2lmaWMgZGV2aWNlcywiIGhhcyBsaXN0ZWQgdGhlIGNhc2Ugb2YgY29udGVudCBhZGFw dGF0aW9uLg0KSW4gbGFzdCBtb250aCwgSSBoYXZlIGNvbnRhY3RlZCB0aGUgQXV0aG9ycyBvZiB0 aGlzIGRvY3VtZW50IGFuZCB0YWtlbiBzb21lIGVtYWlsIGV4Y2hhbmdlcyB3aXRoIEdyYW50IGFu ZCBQaGlsaXAgKEJUKS4NCkkgaGF2ZSBzaG93biBCVCB3aXRoIHNvbWUgaW5mb3JtYXRpb24gdGhh dCBJIGtub3cgaW4gdGhpcyBjYXNlIGFuZCBhcmVhIHRvIGV4cGxhaW4gdGhlIGNvbnRlbnQgZmxl eGliaWxpdHkgaXMgY3VycmVudGx5IGEgYmFzaWMgcmVxdWlyZW1lbnQgZm9yIENETiBzZXJ2aWNl IGFuZCByZWxhdGVkIG5lZ290aWF0aW9uIGlzIG5lZWRlZCBpbiB0aGUgQ0ROIGludGVyY29ubmVj dGlvbi4NCk1lYW53aGlsZSwgSSBzaG91bGQgYWxzbyBpbnZpdGUgeW91IGluIHRoaXMgZ3JvdXAg cmFpc2luZyB5b3VyIGNvbW1lbnRzIG9yIHF1ZXN0aW9ucyBvbiB0aGlzIGNhc2Ugc2luY2UgSSBo b3BlIG15IHVzZSBjYXNlIG1heSBiZSBpbmNvcnBvcmF0ZWQgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0 Lg0KDQpJZiB5b3UgaGF2ZSBhbnkgbW9yZSBxdWVzdGlvbiBvciBjb21tZW50cywgcGxzIHNoYXJl IGluIHRoaXMgdGhyZWFkLg0KVGhhbmtzLg0KWmhpcGVuZw0KDQoNCg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNjb3R0IFdhaW5uZXIgW21haWx0bzpzd2Fpbm5lckBj aXNjby5jb21dPG1haWx0bzpbbWFpbHRvOnN3YWlubmVyQGNpc2NvLmNvbV0+DQpTZW50OiBGcmlk YXksIFNlcHRlbWJlciAzMCwgMjAxMSA4OjAyIEFNDQpUbzogY2RuaUBpZXRmLm9yZzxtYWlsdG86 Y2RuaUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KU2VjdGlvbiAyLjMgTm9tYWRpYyBVc2Vycw0KVGhp cyBkZXNjcmlwdGlvbiBmYWxscyB1bmRlciB0aGUgY2F0ZWdvcnkgb2YgR2VvZ3JhcGhpYyBFeHRl bnNpb24NCnlldCB0aGUgdGhpcmQgcGFyYWdyYXBoIHN0YXRlcyB0aGUgY2FzZSB3aGVyZSBhIGRp ZmZlcmVudCBkZXZpY2UgaXMNCnVzZWQgaW4gdGhlIHNhbWUgQ0ROIGNvdmVyYWdlIGFyZWEuICBU aGUgaW50ZW50IG9mIHRoaXMgdXNlIGNhc2UNCm5lZWRzIHRvIGJlIGNsYXJpZmllZC4gIFBlcmhh cHMgdGhlIHVzZSBjYXNlIGlzIHRyeWluZyB0byBhZGRyZXNzDQp0aGUgc2NlbmFyaW8gd2hlcmUg YSBOb21hZGljIFVzZXItQSB3aXRoIGFuIGFncmVlbWVudCBhbGxvd2luZw0KYWNjZXNzIHRvIGNv bnRlbnQgZnJvbSBDU1AtQSB2aWEgdUNETiBtb3ZlcyB0byBhIGRDRE4gaW4gYSBkaWZmZXJlbnQN CnJlZ2lvbi4gIFRoZSBkQ0ROIGlzIGFsbG93ZWQgdG8gZGlzdHJpYnV0ZSB0aGUgY29udGVudCBv ZiBDU1AtQSB0bw0KVXNlci1BOyBob3dldmVyLCBub3Qgb3RoZXIgdXNlcnMgaW4gdGhlIHJlZ2lv biBvZiB0aGUgZENETiBhcmUNCmFsbG93ZWQgdG8gcmV0cmlldmUgdGhlIGNvbnRlbnQgdW5sZXNz IHRoZXkgdG9vIGhhdmUgc3VjaCBhbiBhZ3JlZW1lbnQuDQoNClNlY3Rpb24gNS4xLjMgQ29udGVu dCBFbmNvZGluZyBSZXN0cmljdGlvbnMgTmVlZCB0byBjbGFyaWZ5IGlmIHdlJ3JlDQp0YWxraW5n IGFib3V0IHRoZSByZXN0cmljdGlvbnMgb24gdGhlIGRlbGl2ZXJ5IG9mIHNwZWNpZmljIGNvbnRl bnQNCm9yIHRoZSByZXN0cmljdGlvbnMgb24gdGhlIGFiaWxpdHkgb2YgYSBDRE4gdG8gZGVsaXZl ciBzcGVjaWZpYw0KY29udGVudC4gIEkgY2VydGFpbmx5IHVuZGVyc3RhbmQgdGhlIGNhc2Ugd2hl cmUgYSBDU1Agd2lsbCByZXN0cmljdA0KdGhlIGRpc3RyaWJ1dGlvbiBvZiBjb250ZW50IHRvIGEg Im1hbmFnZWQgcGF0aCIgaWYgc3VjaCBjb250ZW50IGlzDQpIRCB3aGlsZSBhbGxvd2luZyB0aGUg Y29udGVudCBkaXN0cmlidXRpb24gdmlhIGFuIHVuLW1hbmFnZWQgcGF0aCBpZg0Kc3VjaCBjb250 ZW50IGlzIFNEIChzYW1lIGNvdWxkIGFwcGx5IHRvIGVuY3J5cHRpb24gbWV0aG9kcywgZGVsaXZl cnkNCm1ldGhvZHMsIGV0Yy4pLiAgT24gdGhlIGNvbnRyYXJ5LCB0aGUgZENETiBtYXkgaGF2ZSBp dHMgb3duDQpyZXN0cmljdGlvbnMgb2YgYmxvY2tpbmcgdGhlIGRpc3RyaWJ1dGlvbiBvZiBIRCBj b250ZW50IHdoaWxlDQphbGxvd2luZyB0aGUgZGlzdHJpYnV0aW9uIG9mIFNEIGNvbnRlbnQuDQoN Cm8gZmlyc3QgYnVsbGV0IG1ha2VzIHNlbnNlIGlmIHRoZSBkQ0ROIGNhbiBwZXJmb3JtIGEgc3Vi c2V0IG9mDQplbmNhcHN1bGF0aW9ucyBmb3IgYSByZWZlcmVuY2Ugc2V0IG9mIG1lZGlhIChlLmcu IEhMUywgSFNTLCBidXQgbm90DQpEQVNIKSBvIHNlY29uZCBidWxsZXQgbWFrZXMgc2Vuc2Ugd2hl cmUgdGhlIGRDRE4gZG9lc24ndCB3YW50IHRvDQpvZmZlciBoaWdoIGJpdC1yYXRlIHZhcmlhbnRz IG9mIHRoZSBtZWRpYSBvIHRoaXJkIGJ1bGxldCBtYWtlIHNlbnNlDQppZiB0aGUgcG9saWN5IGFk ZHJlc3NlcyBRb0UgYnV0IEkgZG9uJ3QgdGhpbmsgc3Vic2NyaWJlcg0KcmlnaHRzL2F1dGhvcml6 YXRpb25zIGFwcGx5Lg0KDQpTZWN0aW9uIDEwIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCkFz aWRlIGZyb20gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIFdJVEhJTiB0aGUgdUNETiBhbmQg ZENETiwgSQ0KdGhpbmsgd2UgY2FuIGRlc2NyaWJlIHRoaXMgaW4gZm91ciBjb250ZXh0czoNCg0K YS4gVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBDU1AgYW5kIHRoZSB1Q0ROICh0aGUgcHJp bmNpcGxlIGNvbnRyYWN0DQphcnJhbmdlbWVudCBmb3IgZGlzdHJpYnV0aW9uKQ0KYi4gVGhlIHJl bGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSB1Q0ROIGFuZCBkQ0ROICh0aGUgdHJhbnNpdGl2ZSB0cnVz dA0KcmVsYXRpb25zaGlwIHRoYXQgZXh0ZW5kcyB0aGUgY29udHJhY3QgZGVmaW5lZCBpbiAoYSkg YWJvdmUpIGMuIFRoZQ0KcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIFVzZXIgYW5kIGRDRE4gKHRo ZSByZWNvZ25pdGlvbiBvZiByaWdodCB0bw0KZG93bmxvYWQgcHJlZGljYXRlZCBvbiAoYikgYWJv dmUpIGQuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUNClVzZXIgYW5kIENTUCAodGhlIGNv bnRyYWN0IGF1dGhvcml6aW5nIHRoZSB1c2VyIGFjY2VzcyB0byB0aGUNCmNvbnRlbnQpDQoNClRo ZSB1c2VyIGlzIG5vdCBpbnRlcmVzdGVkIGluIHRoZSBhLWIgbm9yIHRoZSBiLWMgcmVsYXRpb25z aGlwLiBUaGUNCnVzZXIgaXMgb25seSBpbnRlcmVzdGVkIGluIHRoZSB0cmFuc3BhcmVuY3kgYW5k IGludGVyb3BlcmFiaWxpdHkgb2YNCnRoZSBzZWN1cml0eSByZWxhdGlvbnNoaXAgYmV0d2VlbiBk LWIgb3IgZC1jIHRvIHRoZSBwb2ludCB0aGF0IHRoZQ0KYXV0aG9yaXphdGlvbiBncmFudGVkIGlu IGQtYSBpcyB2aWFibGUgd2hlbiB0aGUgZGVsaXZlcnkgaXMNCmluaXRpYXRlZCB2aWEgZWl0aGVy IGQtYiBvciBkLWMuICBBcyBhbiBleGFtcGxlLCB0aGUgdUNETiBtaWdodCB1c2UNClVSTCBhcHBl bmRlZCB0b2tlbnMgZm9yIGF1dGhlbnRpY2F0aW9uIHdoaWxlIGRDRE4gbWlnaHQgdXNlIFVSTA0K YXBwZW5kZWQgaGFzaGVzLiAgVGhlIHVzZXIgZG9lc24ndCB3YW50IHRvIGtub3cgYWJvdXQgdGhl IGRpc3RpbmN0DQptZXRob2RzLCBidXQgdHJhbnNwYXJlbmN5IGlzIG9ubHkgYWZmb3JkZWQgaWYg dGhlIG1ldGhvZHMgYXJlDQppbnRlcm9wZXJhYmxlIGNsZWFybHkgZGVmaW5lZCB3aGVuIHRoZSBk ZWxlZ2F0aW9uIGZvciBjb250ZW50DQpkZWxpdmVyeSBpcyBleGVjdXRlZC4gIENsZWFybHksIHRo ZSBjaG9pY2Ugb2YgYXV0aGVudGljYXRpb24gbWV0aG9kIGlzIGRldGVybWluZWQgYnkgdGhlIHJl c3BlY3RpdmUgQ0ROJ3MuDQoNClNjb3R0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWls dG86Q0ROaUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2RuaQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Q0ROaSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5nIGxpc3QN CkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86 Q0ROaUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2Ru aQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0RO aSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KVGhpcyBlLW1haWwgYW5k IGl0cyBjb250ZW50cyBhcmUgc3ViamVjdCB0byB0aGUgRElTQ0xBSU1FUiBhdCBodHRwOi8vd3d3 LnRuby5ubC9lbWFpbGRpc2NsYWltZXINCg== --Boundary_(ID_H8itvd7FyeFtDJBc48s76g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly80NTQvIj48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQg MiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3Nl LTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1i cmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMg NSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5v c2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L 5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQs IHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwg bGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkNoYXINCgl7bXNvLXN0eWxlLW5hbWU6IuaJueaz qOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpzcGFuLmFwcGxlLXN0 eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLmFwcGxl LWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KcC5CYWxsb29uVGV4dCwgbGkuQmFsbG9vblRleHQs IGRpdi5CYWxsb29uVGV4dA0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IjsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUyNg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4w cHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo YW5rcyBSYXkuIHdlbGNvbWUgeW91ciBtb3JlIGF0dGVudGlvbiBvbiBpdC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQnJhbmRlbmJ1cmcsIFIuIChSYXkp IHZhbiBbbWFpbHRvOnJheS52YW5icmFuZGVuYnVyZ0B0bm8ubmxdDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBPY3RvYmVyIDMxLCAyMDExIDU6MjMgUE08YnI+DQo8Yj5Ubzo8L2I+IFpob3Va aGlwZW5nOyBGcmFuY29pcyBMZSBGYXVjaGV1cjxicj4NCjxiPkNjOjwvYj4gY2RuaUBpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Y2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJOTCIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFpoaXBlbmcsDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJOTCIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VG8gYmUgY2xlYXIgaGVyZSwgSSBoYXZlIG5vdCBnaXZl biBteSBzdXBwb3J0IHRvIHRoZSBDb250ZW50IEFkYXB0YXRpb24gdXNlIGNhc2UgKG5vciBoYXZl IEkgdm9pY2VkIG15IG9wcG9zaXRpb24gYWdhaW5zdCBpdCkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoZSBjb252ZXJzYXRpb24gSSBoYWQgd2l0aCBCZW4gaGFkIHRvIGRv IHdpdGggdGhlIGNvbmNlcHQgb2YgR3JvdXBlZCBGaWxlIERlbGVnYXRpb24gYW5kIGhvdyBkaWZm ZXJlbnQgcXVhbGl0eSBsZXZlbHMsIGVuY29kZWQgYnkgdGhlIENvbnRlbnQNCiBQcm92aWRlciwg YXJlIGhhbmRsZWQgaW4gYSBDRE4gaW50ZXJjb25uZWN0aW9uIHNjZW5hcmlvLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmF5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gY2RuaS1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5aaG91Wmhp cGVuZzxicj4NCjxiPlNlbnQ6PC9iPiBtYWFuZGFnIDMxIG9rdG9iZXIgMjAxMSAxMDowNDxicj4N CjxiPlRvOjwvYj4gRnJhbmNvaXMgTGUgRmF1Y2hldXI8YnI+DQo8Yj5DYzo8L2I+IGNkbmlAaWV0 Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJOTCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Tb3JyeSwgbm90IEtQTi4gSXQg aXMgUmF5IGZyb20gVE5PLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4gWmhvdVpoaXBlbmcNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMzEs IDIwMTEgNDo0OSBQTTxicj4NCjxiPlRvOjwvYj4gJ0ZyYW5jb2lzIExlIEZhdWNoZXVyJzxicj4N CjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciBGcmFuY29pcywgYW5k IGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyBm b3IgYWxsIHRoZSBncm91cOKAmXMgYXR0ZW50aW9uIG9uIHRoaXMgdG9waWMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFtIGFsc28gaGFwcHkgdGhhdCBteSBw cm9wb3NhbCBoYXMgZ290dGVuIHNvIG11Y2ggdmFsdWFibGUgcmVzcG9uc2UvcXVlc3Rpb25zLyBj b21tZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYXQg d2lsbCBiZSB2ZXJ5IGhlbHBmdWwgZm9yIGFsbCBvZiB1cyB0byBjYXRjaCBhIGNvbXBsZXRlIHVu ZGVyc3RhbmRpbmcgYW5kIHNvbHV0aW9uIGZvciB0aGlzIG1hcmtldCBkZW1hbmQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGlsZSBJIGZlZWwgdGlsbCBub3cg dGhlIHRvcGljIGl0c2VsZiBoYXMgbm90IGJlZW4gY29tcGxldGVseSBhbmFseXplZCBhbmQgSSBh bSBidXN5IGRvaW5nIHRoZSB3b3JrLiBJIHdpbGwgZXhwb3NlIG15IGNvbnRyaWJ1dGlvbiBzb29u IGFmdGVyDQogSSBjb21wbGV0ZSB0aGF0IHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5NZWFud2hpbGUgSSBob3BlIHRoZSBncm91cCBtYXkgYWxsb3cgc29t ZSBtb3JlIHRpbWUgZm9yIHBlb3BsZSB0byBjb25zaWRlciBpdC4gUGVyaGFwcyBzb21lIG1vcmUg cGVvcGxlIHdpbGwgZW1lcmdlIGluIHRoZSBncm91cCBtYWlsIGxpc3QuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5DdXJyZW50bHksIHNvbWUgcGVvcGxlIGhhcyBj bGFpbWVkIHRoZWlyIHByZWZlcmVuY2UuICZuYnNwO0kgZmVlbCBwZXJoYXBzIG5vdCBhIGZldyBw ZW9wbGUgaGF2ZSBzdXBwb3J0ZWQgdGhpcyB1c2UgY2FzZSh0aGUgYXV0aG9ycyBvZg0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ ZHJhZnQtZm1uLWNkbmktYWR2YW5jZWQtdXNlLWNhc2VzLTAwLCBBbGFuIGZyb20gRXJpY3Nzb24s DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5DaGluYU1vYmlsZSwgQ2hpbmF0ZWxlY29tLCAmbmJzcDtwZXJoYXBzIGFsc28gS1BO LCBhbmQgbWUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGhhdmUgZXhw bGFpbmVkIHRoYXQgZm9yIENETi1BIGFuZCBDRE4tQiwgdGhleSBtYXkgbmVnb3RpYXRlIHdoZXRo ZXIgdG8gc3VwcG9ydCB0aGUgQ0ROSSBhZGFwdGF0aW9uIHNvbHV0aW9uLiBIZW5jZSBzdWNoIG9w dGlvbmFsIGFycmFuZ2VtZW50DQogd2lsbCBvbmx5IGJyaW5nIGJlbmVmaXQgd2hlbiBib3RoIHVw c3RyZWFtIGFuZCBkb3duc3RyZWFtIGFncmVlcyB0aGF0IGF0IHRoZWlyIGFwcHJvcHJpYXRlIHNp dHVhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28sIEkgc2luY2Vy ZWx5IHN1Z2dlc3QgdHdvIENoYWlycyBhbmQgdGhlIHdob2xlIGdyb3VwIG1heSBhbGxvdyBzb21l IG1vcmUgZGF5cyBmb3IgdGhpcyB0b3BpYy4gJm5ic3A7Jm5ic3A7SSBzdWdnZXN0IGFmdGVyIHRo ZSBUYWlwZWkgbWVldGluZyAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5CeSB0aGVuIHdlIGFsbCB3aWxsIGdldCBhIGNsZWFyZXIgdW5kZXJzdGFuZGluZyBhbmQg ZGVjaXNpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlpoaXBlbmcNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBGcmFuY29pcyBMZSBGYXVjaGV1 cg0KPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tXSI+W21haWx0bzpm bGVmYXVjaEBjaXNjby5jb21dPC9hPiA8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBPY3RvYmVy IDI4LCAyMDExIDk6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFpob3VaaGlwZW5nPGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmkt dXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhpIGFn YWluIFpoaXBlbmcsPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhl cmUgaXMgb25lIG90aGVyIHBvaW50IEkgc2hvdWxkIGhhdmUgYnJvdWdodCB1cCBpbiBteSBwcmV2 aW91cyBtZXNzYWdlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgcXVlc3Rpb24gaXMgbm90IHNv IG11Y2ggd2hldGhlciB0aGVyZSBhcmUgYmVuZWZpdHMgdG8gYWxsb3dpbmcgY29udGVudCBhZGFw dGF0aW9uIGZvciBzb21lIGVudmlyb25tZW50cywgbm9yIHdoZXRoZXIgb25lIHBhcnRpY3VsYXIg aW5kaXZpZHVhbCBjb3VsZCBjb25jZWl2ZSBhbiBhcHByb2FjaCBmb3IgY29udGVudCBhZGFwdGF0 aW9uIHRoYXQgc3VpdHMgaGltLiBUaGUNCiBxdWVzdGlvbiBoZXJlIGlzIHJhdGhlciB3aGV0aGVy IGl0IGlzIGp1c3RpZmllZCBmb3IgdGhlIFdvcmtpbmcgR3JvdXAgdG8gZm9jdXMgZW5lcmd5IG9u IHRoYXQgcHJvYmxlbSByaWdodCBub3cgaW4gb3JkZXIgdG8gZGV2ZWxvcCBhIGNvbnNlbnN1cy1i YXNlZCBhcHByb2FjaCB0aGF0IHN1aXRzIHRoZSBjb21tdW5pdHkgYXMgYSB3aG9sZSwgd2hpbGUg d2UgZG9uJ3QgZXZlbiBoYXZlIHRoZSBiYXNlIHNvbHV0aW9uIGluIHBsYWNlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WW91IGhhdmUgbWFkZSBpdCBj bGVhciB0aGF0IHlvdSBmZWVsIHRoZSBXRyBzaG91bGQgaW5kZWVkIGRlZGljYXRlIGVuZXJneSBv biB0aGF0IHByb2JsZW0gcmlnaHQgYXdheSBhbmQgZXhwbGFpbmVkIHlvdXIgcmF0aW9uYWxlLiBU aGFuayB5b3UuIE90aGVycyBoYXZlIGFsc28gZXhwcmVzc2VkIHRoZWlyIG9waW5pb25zLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hlZXJzPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5GcmFuY29pczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+T24gMjggT2N0IDIwMTEsIGF0IDExOjI1LCBaaG91WmhpcGVuZyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5JbiB0aGVzZSBkYXlzIEkgYW0gYnVzeSBtYWtpbmcgYSBzdW1tYXJ5IGFuYWx5c2lz IG9uIHRoaXMgdG9waWMuIEFzIFJpY2hhcmTigJlzIHJlcXVlc3QsIEkgbGlrZSB0byBzaG93IG15 IGluZm9ybWF0aW9uIGFsdGhvdWdoIHBlcmhhcHMgbm90IGNvbXBsZXRlIHJpZ2h0IG5vdy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bGluZS1oZWlnaHQ6MTMuMnB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4xKTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SQ0KIGhhdmUg ZG9uZSBzb21lIHdvcmsgdG8gY29sbGVjdCBkaWZmZXJlbnQgY29tcGFueeKAmXMgcmVxdWlyZW1l bnRzIGFuZCBvcGluaW9ucyBvbiB0aGlzIGZ1bmN0aW9uYWxpdHkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+T25lLCBJIGZlZWwgbW9zdCBvZiB1cyBoYXZlIGFs cmVhZHkgYmVlbiBhd2FyZSBvZiB0aGUgc2VydmljZSBvZiBjb250ZW50IGFkYXB0YXRpb24sIGFu ZCBJIGFsc28gc2VudCBhbiBlbWFpbCB5ZXN0ZXJkYXkgdGhhdCBWb2RhcGhvbmUNCiBub3cgaXMg cmVxdWlyaW5nIHRoZSBzb2x1dGlvbiB0byBlbmhhbmNlIHRoZSBwZXJmb3JtYW5jZSBvZiBpdHMg bW9iaWxlIHZpZGVvIHNlcnZpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+U2Vjb25kLCBoZXJlIGlzIGFuIGFydGljbGUgYWJvdXQgQ0lTQ08gOiDigJxDaXNj byB1cmdlcyBtb2JpbGUgb3BlcmF0b3JzIHRvIGFkZCB2YWx1ZSB0byBDRE4gc2VydmljZXPigJ08 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i aHR0cDovL3d3dy50b3RhbHRlbGUuY29tL3ZpZXcuYXNweD9JRD00Njg3MDUiPmh0dHA6Ly93d3cu dG90YWx0ZWxlLmNvbS92aWV3LmFzcHg/SUQ9NDY4NzA1PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJlc2lkZXMsIEkgaGF2ZSBjaGVja2VkIG1hbnkgQ0RO IGNvbXBhbnnigJlzIHdlYnNpdGVzLiBNYW55IGNsYWltIHRvIHN1cHBvcnQgdHJhbnNjb2Rpbmcg d2hpbGUgc29tZSBtYXkgbm90LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotMTguMHB0O2xpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Mik8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkZvcg0KIHRoZSB3b3JkaW5nIOKAnGNvbnRlbnQg YWRhcHRhdGlvbuKAnSwgaXQgc2hvdWxkIGJlIGNsYXJpZmllZCBoZXJlIHRoYXQgaXQgbWF5IGJl IHR3byBraW5kcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5P bmUgaXMgb25seSB0aGUgdHJhbnNmb3JtYXRpb24gb2YgZW5jYXBzdWxhdGlvbiBmb3JtYXQuIEZv ciBleGFtcGxlIHRoZSBILjI2NCBzdHJlYW0gaXMgZW5jYXBzdWxhdGVkIGluIEFQUExFIGFuZCBB ZG9iZSBmb3JtYXQNCiByZXNwZWN0aXZlbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+SSBrbm93IHRoYXQgQ29tY2FzdCBoYXMgYSBwcm9qZWN0IHRoYXQgbmVl ZHMgdG8gcGljayB0aGUgSC4yNjQgbWVkaWEgZnJvbSB0aGUgVFMgc3RyZWFtIGFuZCB0aGVuIGVu Y2Fwc3VsYXRlZCB0aGVtIGludG8gZGlmZmVyZW50DQogZm9ybWF0cyhBUFBMRSxBZG9iZeKApikg dG8gZGlmZmVyZW50IGRldmljZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Rm9yIHRoaXMga2luZCBvZiB0cmFuc2Zvcm1hdGlvbiwgdGhlIGNvbXB1dGluZyBj b3N0IGlzIHZlcnkgdmVyeSBsb3cgYW5kIG1heSBiZSBuZWFybHkgbmVnbGVjdGVkLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRoZSBvdGhlciBpcyB0byB0cmFu c2NvZGluZy4mbmJzcDsgRm9yIGV4YW1wbGUgdG8gc3VwcG9ydCBkaWZmZXJlbnQgYml0cmF0ZXMu Jm5ic3A7IFNpbmNlIGVuY29kZXIgaXMgYSBoaWdoIHZhbHVlIGZhY2lsaXR5LCB3ZSBzaG91bGQg Y29tcGFyZQ0KIHRoZSBjYXBpdGFsIGNvc3Qgb2YgZW5jb2RlciBhbmQgdHJhbnNwb3J0IGNvc3Qu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDox OC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SnVzdCB0YWtlIGEg c2ltcGxlIG1vZGVsOiBjb250ZW50IGlzIGRlbGl2ZXJlZCBmcm9tIE5vZGUgQSB0byBOb2RlIEIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDox OC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jmx0O2ltYWdlMDAy LnBuZyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6 MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGVy ZSBhcmUgdHdvIHNvbHV0aW9uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LTE4LjBwdDtsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjEpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BDQogaGF2ZSB0aGUgdHJhbnNjb2Rl ciBhbmQgZGVsaXZlciBtdWx0aS1mb3JtYXQgY29udGVudCB0byBCPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bGluZS1oZWlnaHQ6MTMuMnB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4yKTwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Qg0K IGhhdmUgdGhlIHRyYW5zY29kZXI7IEEgb25seSBkZWxpdmVycyBvbmUgZm9ybWF0IGNvbnRlbnQg dG8gQiBhbmQgQiB3b3VsZCB0cmFuc2NvZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+RnJvbSB3aG9sZSBzeXN0ZW0gcG9pbnQgb2YgdmlldywgZWl0aGVyIEEg b3IgQiB3b3VsZCB0cmFuc2NvZGUgd2hpbGUgdGhlIGJhbmR3aWR0aCB3b3VsZCBiZSBzYXZlZCBp biBzb2x1dGlvbiBCLiBIZW5jZSBzb2x1dGlvbg0KIEIgaXMgYmV0dGVyLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk5vdyBwcm92aWRlZCB0aGUgYmFuZHdpZHRo IGlzIHBhaWQgYnkgQiBhbmQgQiBzaG91bGQgZGVjaWRlIHdoZXRoZXIgdG8gaW5zdGFsbCB0cmFu c2NvZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox My4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPihSaWNo YXJkIGhhcyBzYWlkIHRvIHNldCB0cmFuc2NvZGVyIGluIGVhY2ggZWRnZSBzZXJ2ZXIpPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SWYgdGhlIGNvc3Qgb2YgcmVu dGluZyBiYW5kd2lkdGggKGZvciBhIGZldyBtb250aHMpIGlzIG1vcmUgZXhwZW5zaXZlIHRoYW4g dGhlIHByaWNlIG9mIHRyYW5zY29kZXIgc3VwcG9ydGluZyB0aGUgc2FtZSBiYW5kd2lkdGgsDQog aXQgd291bGQgYmUgYmV0dGVyIHRvIHB1dCB0aGUgdHJhbnNjb2RlciBhdCB0aGUgcmVjZWl2ZXIg Tm9kZSBCLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox My4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkluIGZh Y3QgSSBoYXZlIGludmVzdGlnYXRlZCB0aGlzIGlzc3VlIGZvciBtdWNoIHRpbWUuIFdoaWxlIGlu IGRpZmZlcmVudCBhcmVhIHRoZSBwcmljZSBvZiBiYW5kd2lkdGggbWF5IGJlIGRpZmZlcmVudC4m bmJzcDsgQW5kIHRoZQ0KIHRyYW5zcG9ydCBidXJkZW4gYmV0d2VlbiB0d28gZGlzdGFudCBwbGFj ZXMgb3Igb3ZlciBhIGJhZCBuYXR1cmUgZW52aXJvbm1lbnQgd291bGQgYmUgbXVjaCBoaWdoZXIu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDox OC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SGVyZSB0aGUgcHJp Y2UgaW4gVVNBIG1heSBiZSByZWZlcnJlZCBhczo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cDovL3NtYWxsYnVzaW5lc3MudmVyaXpv bi5jb20vcHJvZHVjdHMvaW50ZXJuZXQvaHNpL292ZXJ2aWV3LmFzcHgjcGxhbnMiPmh0dHA6Ly9z bWFsbGJ1c2luZXNzLnZlcml6b24uY29tL3Byb2R1Y3RzL2ludGVybmV0L2hzaS9vdmVydmlldy5h c3B4I3BsYW5zPC9hPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5JbiBWZXJpem9uLCB0aGUgcGFja2FnZSBmb3IgMTAtMTVtYnBzIGlzICQ5MCBwZXIgbW9udGgg KEkgZmVlbCB0aGUgYmFuZHdpZHRoIHF1YWxpdHkgZm9yIGJ1c2luZXNzIHdvdWxkIGJlIGd1YXJh bnRlZWQpLiBJIHF1ZXJ5DQogdGhhdCB0aGUgYmFuZHdpZHRoIHByaWNlIGluIENoaW5hIG1heSBi ZSA1MCUgaGlnaGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhl aWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PkkgZG8gbm90IGtub3cgaG93IG11Y2ggdGhlIHByaWNlIHdpbGwgYmUgZm9yIHRoZSBiYW5kd2lk dGggZnJvbSBBbXN0ZXJkYW0gdG8gUGFyaXMgKGNyb3NzIGNvdW50cnkgaW4gdGhlIHNhbWUgY29u dGluZW50KS4mbmJzcDsgQnV0DQogSSBmZWVsIHRoZSBwcmljZSBmcm9tIE5ld1lvcmsgdG8gUGFy aXMgd291bGQgYWJzb2x1dGVseSBiZSB2ZXJ5IGhpZ2guJm5ic3A7IEFzIGZvciB0aGUgRW5jb2Rl ciwgaXQgYWxzbyB2YXJpZXMuIFBlcmhhcHMgdGhlIHByaWNlIGluIENoaW5hIHdpbGwgYmUgaGln aGVyIHRoYW4gaW4gVVNBLiBBbmQgaW4gZmFjdCB0aGUgcHJpY2Ugb2YgYmFuZHdpZHRoIGFuZCBl bmNvZGVyIGRlcGVuZHMgbW9zdGx5IG9uIHRoZSBjb25jcmV0ZSBidXNpbmVzcyBpdGVtcy4NCiBG b3IgZXhhbXBsZSB0aGUgcHJpY2UgdG8gSHVhd2VpIG1heSBiZSBsb3dlciB0aGFuIHRoZSBwdWJs aWMgcHJpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0 OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Qnkg bXkgY3VycmVudCBldmFsdWF0aW9uIGluIENoaW5hIGl0IGlzIGJldHRlciB1c2luZyB0aGUgdHJh bnNjb2RlciB0aGFuIHJlbnRpbmcgbXVsdGlwbGUgdGltZXMgYnJvYWRiYW5kLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNvbWUgcGVvcGxlIGhhdmUgdG9sZCBt ZSB0aGF0IGZvciB0aGUgb3BlcmF0b3IgaGltc2VsZiBwcm9iYWJseSB0aGUgYmFuZHdpZHRoIGNv c3Qgd291bGQgYmUgdmVyeSBsb3cgaW4gdGhlIGludGVybmFsIGNhcGl0YWwgY291bnRpbmcuDQog QnV0IGZvciB0aGUgaW5kZXBlbmRlbnQgQ0ROLCBpdCBtYXkgYW5vdGhlciB0aGluZy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TbywgbXkgc3VnZ2VzdGlvbiBp cyB0byBsZXQgZGlmZmVyZW50IHdheXMgY28tZXhpc3QuIEkgaGF2ZSBhbm5vdW5jZWQgdGhhdCB0 byBsZXQgdHdvIHNpZGVzIG5lZ290aWF0ZSB3aGV0aGVyIHRvIGFzc2lnbiBkQ0ROIGZvcg0KIHRo ZSBjb250ZW50IGFkYXB0YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUt aGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+SW4gZmFjdCwgZnJvbSBDUCB0byBDRE4sJm5ic3A7IHRoZXJlIGFyZSB0aGUgcmVhbCBidXNp bmVzc2VzIHRoYXQgZWl0aGVyIGxldCBDUCB0byBwcm92aWRlIG11bHRpLWZvcm1hdCBjb250ZW50 IG9yIGxldCB0aGUgQ0ROIHRvIHJlY2VpdmUNCiBvbmUgZm9ybWF0IGFuZCBjb21wbGV0ZSB0aGUg dHJhbnNmb3JtYXRpb24sIGRlcGVuZGluZyBvbiB0aGUgY29uY3JldGUgYnVzaW5lc3MuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QnkgdGhlIHNhbWUgbG9naWMs IGZvcm0gdUNETiB0byBkQ0ROLCBpdCBtYXkgYmUgZWl0aGVyIHRoZSB1Q0ROIHRvIHByb3ZpZGUg bXVsdGktZm9ybWF0IGNvbnRlbnQgb3IgdGhlIGRDRE4gdG8gcmVjZWl2ZSBvbmUgZm9ybWF0DQog Y29udGVudCBhbmQgdGhlbiBjb21wbGV0ZSB0aGUgdHJhbnNmb3JtYXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Q3VycmVudGx5IHRoZXJlIGlzIG5vdCB0 aGUgcmVhbCBDRE4tQ0ROIGNvbm5lY3Rpb24sIGhlbmNlIHdlIGFyZSBiYXNpbmcgb3VyIGtub3ds ZWRnZSBvbiB0aGUgcmVsYXRlZCBzb2x1dGlvbiB0byBtYWtlIG91ciBzb2x1dGlvbnMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bGluZS1oZWlnaHQ6 MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4zKTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+QXMNCiBmb3IgdGhlIHByb2NlZHVyZSBvZiBjb250ZW50IGFkYXB0YXRpb24sIEkganVzdCBk cmFmdCBhIGRpYWdyYW0gYXMgYmVsb3c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jmx0O2ltYWdlMDA0LnBuZyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5Zb3UgbWF5IHNlZSB0aGUgc29sdXRpb24gaXMgcmF0aGVyIGNsZWFyIGFu ZCB0aGUgbWV0YWRhdGEgbmVlZGVkIHdvdWxkIGJlIGNsZWFyIGFsc28uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+RGVhciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5CeSBteSBhbmFseXNpcyBhYm92ZSwgSSBraW5kbHkgaW52aXRlIHlv dXIgaWRlYXMgd2hldGhlciBpdCBtYXkgYmUgYW4gYXBwbGljYWJsZSBhbmQgc2ltcGxlIHBhcnQg aW4gdGhlIENETkkgaXRlbSwgcHJvdmlkZWQgdGhhdA0KIHRoZSBzb2x1dGlvbiBpcyBvcGVuIHRv IHRoZSB0eXBlcyBvZiBjb250ZW50IGFkYXB0YXRpb24gYW5kIG1heSBiZSBvcHRpb25hbGx5IGlt cGxlbWVudGVkIGluIHRoZSByZWFsIHNvbHV0aW9ucy9idXNpbmVzcy4gSSBmZWVsIGZvciB0aG9z ZSBvcGVyYXRvcnMgdGhhdCBuZWVkIHN1Y2ggZnVuY3Rpb25hbGl0eSBpdCB3b3VsZCBiZSB2ZXJ5 IGdvb2Qgd2hpbGUgaXQgZG9lcyBub3QgaW1wYWN0IG90aGVycyB0aGF0IGRvIG5vdCBpbXBsZW1l bnQgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4t bGVmdDoxOC4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEz LjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhhbmtz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTguMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4ycHQi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlpoaXBlbmc8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtO2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRl ci1jb2xvcjppbml0aWFsIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Xb3VuZHksDQogUmljaGFyZCA8YSBocmVmPSJtYWlsdG86W21haWx0 bzpSaWNoYXJkX1dvdW5keUBjYWJsZS5jb21jYXN0LmNvbV0iPlttYWlsdG86UmljaGFyZF9Xb3Vu ZHlAY2FibGUuY29tY2FzdC5jb21dPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+VGh1cnNkYXksIE9jdG9iZXIgMjcsIDIwMTEgNzoy MyBQTTxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+WmhvdVpoaXBlbmc7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzonbWFya0BqZXQtc3RyZWFtLm5sIj4nbWFy a0BqZXQtc3RyZWFtLm5sPC9hPic7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzonYWxhbi5rYXZhbmFnaEBlcmljc3Nvbi5jb20i PidhbGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbTwvYT4nPGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 J2NkbmlAaWV0Zi5vcmciPidjZG5pQGlldGYub3JnPC9hPic7IFdvdW5keSwgUmljaGFyZDxicj4N CjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5SZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMt MDAudHh0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0O0luIHlvdXIgY29tcGFu eeKAmXMgd2Vic2l0ZSwgSSBqdXN0IGZpbmQgc29tZSBpbmZvcm1hdGlvbjxicj4NCjxicj4NCkkg aGF2ZSB0byBzdGVwIGluIGFzIGNvLWNoYWlyIGhlcmUuPGJyPg0KPGJyPg0KVGhlIGdvYWwgb2Yg dGhpcyBXRyBpcyBub3QgdG8gYWxpZ24gdmVuZG9yIHByb2R1Y3Qgcm9hZG1hcHMsIG9yIHRvIGVx dWFsaXplIGFsbCB2ZW5kb3Igb2ZmZXJpbmdzLCBvciB0byBzcGVjaWZ5IHRoZSBlbnRpcmUgQ0RO SSBlY29zeXN0ZW0uIFRoZSBnb2FsIG9mIHRoaXMgV0cgaXMgdG8gZW5hYmxlIHRoZSBpbnRlcmNv bm5lY3Rpb24gYW5kIGludGVyb3BlcmF0aW9uIG9mIHR3byBvciBtb3JlIENETnMsIHdpdGhpbiB0 aGUgYm91bmRzIG9mIHRoZQ0KIENETkkgd2cgY2hhcnRlci48YnI+DQo8YnI+DQpJdCBpcyBPSyB0 byBoYXZlIGEgZGlzY3Vzc2lvbiBhYm91dCB3aGV0aGVyIGNvbnRlbnQgYWRhcHRhdGlvbiBuZWVk cyB0byBiZSBwZXJmb3JtZWQgYnkgdGhlIGRDRE4sIHNpbmNlIHRoYXQgZGVjaXNpb24gaW1wYWN0 cyB0aGUgdUNETi1kQ0ROIGludGVyZmFjZS4gU28gbGV0J3MgZmluZCBhIHByb2R1Y3RpdmUgd2F5 IHRvIGRpc2N1c3MgdGhpcyBvbiB0aGUgbWFpbGluZyBsaXN0LCBhbmQgdG8gY2xvc2UgdGhlIGRp c2N1c3Npb24gYnkgSUVURiA4Mg0KIChpZiBub3Qgc29vbmVyKS48YnI+DQo8YnI+DQpDYW4gc29t ZW9uZSBkZXNjcmliZSByZWFsLWxpZmUgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBDRE4gKG9y IGVkZ2UgY2FjaGUtYmFzZWQpIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBuZWVkZWQgdG9kYXkgaW4g YSBwcm9kdWN0aW9uIGVudmlyb25tZW50LCBvciBzaG9ydGx5PyBOb3QgbWVyZWx5IGEgZmVhdHVy ZSBpbiBhIHZlbmRvcidzIHByb2R1Y3QgbWF0ZXJpYWxzPzxicj4NCjxicj4NClNwZWFraW5nIGFz IGFuIGluZGl2aWR1YWwsIEkgY2FuIGZpbmQgYSBsb3Qgb2YgZXhhbXBsZXMgd2hlcmUgZG93bnN0 cmVhbSBjb250ZW50IGFkYXB0YXRpb24gaXMgbm90IG5lZWRlZCwgYW5kIGFueSBhZGFwdGF0aW9u IGlzIHJlYWxseSBwYXJ0IG9mIHRoZSBDUCAtIHVDRE4gaW50ZXJmYWNlICh3aGljaCBpcyBvdXQg b2YgdGhlIHNjb3BlIG9mIG91ciBjaGFydGVyKS48YnI+DQo8YnI+DQotLSBSaWNoPGJyPg0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQombmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY207Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRpYWwiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij46IFpob3VaaGlwZW5nDQo8YSBocmVmPSJtYWlsdG86W21haWx0bzp6aG91 emhpcGVuZ0BodWF3ZWkuY29tXSI+W21haWx0bzp6aG91emhpcGVuZ0BodWF3ZWkuY29tXTwvYT48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+ U2VudDwvYj46IFRodXJzZGF5LCBPY3RvYmVyIDI3LCAyMDExIDAzOjQ1IEFNPGJyPg0KPGI+VG88 L2I+OiBNYXJrIGRlIEpvbmcgJmx0OzxhIGhyZWY9Im1haWx0bzptYXJrQGpldC1zdHJlYW0ubmwi Pm1hcmtAamV0LXN0cmVhbS5ubDwvYT4mZ3Q7OyBBbGFuIEthdmFuYWdoICZsdDs8YSBocmVmPSJt YWlsdG86YWxhbi5rYXZhbmFnaEBlcmljc3Nvbi5jb20iPmFsYW4ua2F2YW5hZ2hAZXJpY3Nzb24u Y29tPC9hPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGJyPg0KPGI+Q2M8L2I+OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwv YT48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Jmx0Ozxh IGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPiZndDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U3ViamVj dDwvYj46IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0w MC50eHQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJy Pg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IZWxsbyBNYXJrLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5OaWNlIHRvIG1lZXQgeW91IG9uIGxpbmUuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHlvdXIgY29tcGFueeKAmXMgd2Vic2l0ZSwgSSBqdXN0IGZp bmQgc29tZSBpbmZvcm1hdGlvbiB0aGF0IGFkZHJlc3NlcyDigJw8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9Ik5MIiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzRDNTY1QyI+Vm9kYWZvbmUNCiBzdWJzY3JpYmVycyBjb21w bGFpbmVkIGFib3V0IHZpZGVvIHBlcmZvcm1hbmNlLuKAnTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5TZWU6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxh IGhyZWY9Imh0dHA6Ly93d3cuamV0LXN0cmVhbS5ubC9zZWFyY2gvP3NlYXJjaD10cmFuc2NvZGlu ZyI+aHR0cDovL3d3dy5qZXQtc3RyZWFtLm5sL3NlYXJjaC8/c2VhcmNoPXRyYW5zY29kaW5nPC9h Pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciBhbGwgaW4gdGhpcyBncm91cCw8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4gbGFzdCBmZXcgZGF5cywgZXhjZXB0IHRoZSBw dWJsaWMgZW1haWwgZGlzY3Vzc2lvbnMgSSBoYXZlIGNvbnRhY3RlZCB3aXRoIHNvbWUgcGVvcGxl IGFuZCBkaXNjdXNzZWQgd2l0aCBteSBvd24gY29sbGVhZ3VlcyBvZiBhbGwgZGV0YWlscyBvbg0K IHRoaXMgaXNzdWUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkZpcnN0LCBh bHRob3VnaCB0aGUgbWFya2V0IHJlcXVpcmVtZW50IGZvciBpdCBpcyB2ZXJ5IGltcG9ydGFudCwg SSBmZWVsIEnigJlkIGJldHRlciBzaG93IHVwIG1vcmUgaW5mb3JtYXRpb24gb24gdGhlIHByb2Nl ZHVyZSBpbnZvbHZlZC4gSSBoYXZlIGV4cGxhaW5lZA0KIG1hbnkgdGltZXMgdGhhdCB0byBzdXBw b3J0IGNvbnRlbnQgYWRhcHRhdGlvbiBpcyByYXRoZXIgc2ltcGxlIHdoaWxlIHRoZSB3b3JkaW5n IGlzIG5vdCBlbm91Z2guPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0g YnVzeSBtYWtpbmcgc29tZSBjb250cmlidXRpb25zIG9uIHRoaXMgYW5kIHBsYW4gdG8gdXBsb2Fk IHRvIEVUU0kgbWVldGluZyBhbmQgSUVURiBDRE5JLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5CeSB0aGVzZSB3b3JrJm5ic3A7IEkgZmVlbCB0aGUgcGVvcGxlIG1heSBjYXRj aCBhIHdob2xlIHZpZXcgb24gdGhpcyBpc3N1ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+U2Vjb25kLCBmb3IgdGhhdCBmdW5jdGlvbmFsaXR5LCBpbiBpbXBsZW1lbnRhdGlv biwgaWYgc29tZSBlbnRpdHkgZG9lcyBub3QgY2hvb3NlIHRvIHN1cHBvcnQgaXQsIGl0IG1heSBi ZSBvay4gU2luY2UgaXQgbWF5IGJlIG5lZ290aWF0ZWQgYmV0d2VlbjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4NCiB0d28gQ0ROcy48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgZENETiBkb2VzIG5vdCBzdXBwb3J0IHRoYXQsIGl0 IG1heSBiZSB0aGUgdUNETiByZXNwb25zaWJsZSB0byBjb21wbGV0ZSB0aGUgdHJhbnNjb2Rpbmcg YW5kIGRlbGl2ZXIgdGhlIGNvbnRlbnQgb2YgbXVsdGlwbGUgZm9ybWF0cyBhbmQgcmF0ZXMNCiB0 byBkQ0ROLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlyZCwgYWx0aG91 Z2ggQ0ROSSBpcyBhIG5ldyBhcmNoaXRlY3R1cmUsIHdoaWxlIHRoZSBjb250ZW50IG9wZXJhdGlu ZyBoYXMgYmVlbiBleGlzdGVkIGZvciB5ZWFycy4gQXMgSSBrbm93IHRoZSBjb250ZW50IGZyb20g VVNBIHRvIHRoZSBkb3duc3RyZWFtDQogb3BlcmF0b3IgaXMgdHJhbnNmZXJyZWQgb24gb25lIGNv cHkgYW5kIHRoZSBkb3duc3RyZWFtIG9wZXJhdG9yIHdpbGwgaGFuZGxlIHRoZSB0cmFuc2NvZGlu Zy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlBlcmhhcHMsIHRoZSBjb250ZW50IGFkYXB0YXRpb24g aXMgbW9yZSBvbiB0aGUgbW9iaWxlIG9wZXJhdGluZy4gQnV0IEkgZmVlbCBjdXJyZW50bHkgbW9z dCBvcGVyYXRvciB3aWxsIGJlIGEgYWxsIHNlcnZpY2Ugb3BlcmF0b3IuIEFuZCBmb3IgdGhlDQog Q0ROIHByb3ZpZGVycywgaXQgbWF5IGJlIGJldHRlciB0byBzdXBwb3J0IGFsbCBraW5kcyBvZiBz ZXJ2aWNlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXNpZGVzLCBJIGxp a2Ugc2F5IHRoYXQgdGhlIHRlY2hub2xvZ3kgb24gdGhpcyB0b3BpYyBoYXMgYmVlbiBmb3IgbWFu eSB5ZWFycyBhbmQgaGFzIGJlZW4gcmF0aGVyIG1hdHVyZSwgZXZlbiBzb21lIGl0ZW1zIGluIGll dGYgc3VjaCBhcyByZmMzNTA3PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPg0KIGljYXAuIFNvIGZyb20gdGhlIHRlY2huaXF1ZSBwb2ludCBvZiB2aWV3LCBp dCBpcyBhIG5hdHVyZSBhY3Rpb24gdG8gYmUgaW52b2x2ZWQgaW4gQ0ROIGludGVyY29ubmVjdGlv bi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5aaGlwZW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY207Ym9yZGVyLXdpZHRoOmluaXRpYWw7Ym9yZGVyLWNvbG9yOmluaXRp YWwiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPk1hcmsNCiBkZSBKb25nIDxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOm1hcmtAamV0LXN0cmVh bS5ubF0iPlttYWlsdG86bWFya0BqZXQtc3RyZWFtLm5sXTwvYT48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBPY3RvYmVy IDI3LCAyMDExIDQ6MjEgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkFsYW4gS2F2YW5hZ2g8YnI+DQo8Yj5DYzo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkJlbiBOaXZlbi1K ZW5raW5zOyBaaG91WmhpcGVuZzs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVz ZS1jYXNlcy0wMC50eHQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkhpIEFsYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+QXMgQmVuIHN0YXRlZCB0aGUgb3ZlcmFsbCBkaXNjdXNzaW9uIHJpZ2h0IG5vdyBpcyBhYm91 dCBkZWxpdmVyeSwgbm90IG9uIGFkYXB0YXRpb24uIEl0IGlzIGhhcmQgZW5vdWdoIHRvIGdldCBj b25zZW5zdXMgb24gdGhlIGRlbGl2ZXJ5IGFzcGVjdCBhbHJlYWR5IG5vdCB0byBtZW50aW9uIHlv dXINCiByZXF1aXJlbWVudCBmcm9tIGNvbnRlbnQgYWRhcHRhdGlvbiBhZGRlZCB0byB0aGF0LCBz byBJIGFncmVlIHdpdGggQmVuIHdlIHNob3VsZCBzdGljayB3aXRoIHRoZSBkZWxpdmVyeSBhc3Bl Y3QgZm9yIHRoZSBmaXJzdCBzcGVjcy4mbmJzcDtJIGNhbiBpbWFnaW5lIHRoaXMgY291bGQgYmUg YSBkaXNjdXNzaW9uIGxhdGVyIG9uIGJ1dCBwbGVhc2UgbGV0IHVzIGtlZXAgdGhlIHNjb3BlIG9m IHRoaXMgYmUgY2xlYW4gYW5kIHRyYW5zcGFyZW50LiBJdCBpcw0KIG9mIGJlbmVmaXQgb2YgZXZl cnlvbmUgdG8gZ2V0IHRoZSBmaXJzdCBzcGVjcyBhcyBmYXN0IGFzIHBvc3NpYmxlLiBUaGFua3Mu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxl LXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+TWV0IHZyaWVuZGVsaWprZSBncm9ldCw8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5 bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj5LaW5kIHJlZ2FyZHMsPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJhcHBs ZS1zdHlsZS1zcGFuIj5NYXJrIGRlIEpvbmc8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxl LXN0eWxlLXNwYW4iPkludGVybmF0aW9uYWwgQnVzaW5lc3MgRGV2ZWxvcGVyPC9zcGFuPjxicj4N CjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5KZXQtU3RyZWFtIEJWPC9zcGFuPjxicj4N Cjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5FLW1haWw6PC9zcGFuPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+PGEgaHJlZj0ibWFpbHRvOm1hcmtAamV0LXN0cmVhbS5jb20iPm1h cmtAamV0LXN0cmVhbS5jb208L2E+PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHls ZS1zcGFuIj5PZmZpY2U6ICYjNDM7MzEgKDApNTAgNTI2MTgyMDwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+TW9iaWxlOiAmIzQzOzMxICgwKTYgODExMDgyNjM8L3Nw YW4+PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPkZheDogJiM0MzszMSAoMCk1 MCA1MjY0MjE0PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LSBFdmVudDo8L3NwYW4+PC9i Pjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TWVldA0KIHVzIGF0IFN0cmVhbWluZyBNZWRp YSBFdXJvcGUsIDE3LTE4IE9jdG9iZXIsIExvbmRvbiwgVUs8L3NwYW4+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9 ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+LSBFdmVudDo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj4mbmJzcDtNZWV0DQogdXMgYXQgT25saW5lIFZpZGVvIFN0cmF0ZWdpZXMs IDE5IE9jdG9iZXIsIExvbmRvbiwgVUs8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxl LXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+LSBFdmVudDo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUt c3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDtNZWV0DQogdXMgYXQgQ0ROIFdvcmxkIFN1bW1pdCwgMjUtMjggT2N0b2JlciwgTG9u ZG9uLCBVSzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tPC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TmV3czo8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBj bGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDtQcmUtcmVxdWVzdA0KIHlvdXIgVGVjaG5vbG9neSBX aGl0ZXBhcGVyIG5vdyBhbmQgYmUgdGhlIGZpcnN0IHRvIGhhdmUgaXQsIGNoZWNrPC9zcGFuPjwv c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFt LmNvbSI+d3d3LmpldC1zdHJlYW0uY29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1z cGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si Pi0mbmJzcDs8Yj5OZXdzOiZuYnNwOzwvYj5DaGVjayZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cu amV0LXN0cmVhbS5jb20iPmh0dHA6Ly93d3cuamV0LXN0cmVhbS5jb208L2E+PC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+dG8NCiBkb3dubG9hZCBvdXIgJ1NpeCBUcmVuZHMgaW4g Q0ROcycgYnJvY2h1cmU8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFw cGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJsb2c6 PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJo dHRwOi8vd3d3LmpldC1zdHJlYW0uY29tL2Jsb2cvIj53d3cuamV0LXN0cmVhbS5jb20vYmxvZy88 L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1zdHlsZS1zcGFuIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2 LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPlZpZGVvRXhjaGFuZ2U6PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9iPjwvc3Bhbj48c3BhbiBj bGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LnZkby14Lm5ldCI+d3d3LnZk by14Lm5ldDwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4tPC9zcGFuPjwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g Y2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U3RyZWFtemlsbGE6PC9zcGFuPjwvYj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9iPjwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LnN0cmVhbXppbGxh Y2RuLmNvbSI+d3d3LnN0cmVhbXppbGxhY2RuLmNvbTwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt c3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OmJsYWNrIj4tPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Q29ycG9yYXRl Ojwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8v d3d3LmpldC1zdHJlYW0uY29tIj53d3cuamV0LXN0cmVhbS5jb208L2E+PC9zcGFuPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5PbiAyNiwgT2N0LDIwMTEs IGF0IDg6MzMgUE0sIEFsYW4gS2F2YW5hZ2ggd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CZW48YnI+DQo8YnI+DQpJbSBh c3N1bWluZyB0aGVuIGJhc2VkIG9uIHlvdXIgY29tbWVudHMgYmVsb3cgYXJlIHlvdSBzdWdnZXN0 aW5nIHdlIGFyZSBnb2luZyB0byBoYXZlIGEgbnVtYmVyIG9mIHZlcnNpb25zIG9mIHRoZSBDRE4t SSBNZXRhZGF0YT88YnI+DQo8YnI+DQpJIHN5bXBhdGhpc2Ugd2l0aCB3aGF0IHlvdSBhcmUgcG9p bnRpbmcgb3V0IGJlbG93IGFuZCBkbyBhZ3JlZSB0aGF0IHRoZXJlIGlzIHNvbWUgd29yayB0byBi ZSBkb25lLCBidXQgSSBzdGlsbCBmZWVsIHRoYXQgY29udGVudCBhZGFwdGF0aW9uIGlzIHRvIG1l IGEgZnVuZGFtZW50YWwgcmVxdWlyZW1lbnQgdG8gd2hhdCBjb2xsZWN0aXZlbHkgd2Ugc2hvdWxk IGFkZHJlc3MgaW4gdGhlIENETi1JIFdHLiBJIGRvIGFncmVlIHdpdGggeW91IHRoYXQgY29udGVu dA0KIGFkYXB0YXRpb24gaXMgYW4gb3B0aW1pemF0aW9uIGJldHdlZW4gQ0ROJ3MgYnV0IGl0J3Mg YSB2ZXJ5IGltcG9ydGFudCBvbmUgdGhhdCBJIGtub3cgTmV0d29yayBTZXJ2aWNlIFByb3ZpZGVy cyBwYXJ0aWN1bGFybHkgcmVxdWlyZS48YnI+DQo8YnI+DQpBbGFuPGJyPg0KPGJyPg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYu b3JnIj5jZG5pLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFpbHRvOmNkbmktYm91bmNl c0BpZXRmLm9yZ10iPlttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXTwvYT4gT24gQmVoYWxm IE9mIEJlbg0KIE5pdmVuLUplbmtpbnM8YnI+DQpTZW50OiBPY3RvYmVyLTEyLTExIDE6MTMgUE08 YnI+DQpUbzogWmhvdVpoaXBlbmc8YnI+DQpDYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlA aWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxicj4NCjxicj4NClpoaXBlbmcsPGJyPg0KPGJyPg0K T24gMTIgT2N0IDIwMTEsIGF0IDEwOjIyLCBaaG91WmhpcGVuZyB3cm90ZTo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPkhlbGxvIEJlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGUg VUUgbWF5IHNlbGVjdCB0aGUgY29udGVudCBmb3JtYXQgb24gdGhlIENQIHdlYi4gQWZ0ZXIgdGhh dCB0aGUgdXNlciBvbmx5IGRlc2lyZXMgdG8gZ2V0IGhpcyBzZWxlY3RlZCBjb250ZW50LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJ1dCBob3cgdGhlIGNv bnRlbnQgaXMgdHJhbnNmZXJyZWQgdG8gdGhlIGNsaWVudCBpcyBub3Qgd29ycmllZCBieSB0aGUg dXNlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGUg Q1AgbWF5IGNyZWF0ZSBhIHNwZWNpYWwgZm9ybWF0IGFzIHJlcXVpcmVkIGJ5IHRoZSB1c2VyIGFu ZCBhc2sgdGhlIENETiB0byBkZWxpdmVyIHRvIHVzZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+V2hpbGUgQ1AgbWF5IGdpdmUgYSBIRCBmb3JtYXQgY29u dGVudCB0byB1Q0ROIGFuZCB0aGUgZENETiBtYXkgdGhlbiB0cmFuc2Zvcm0gdG8gdGhlIGZvcm1h dCBhcyB0aGUgdXNlciBzZWxlY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpMb3RzIG9mIHRoaW5ncyBtYXkg YmUgcG9zc2libGUgdG8gZG8gYW5kIENETiBwcm92aWRlcnMgb2ZmZXIgbWFueSBhZGRpdGlvbmFs IHNlcnZpY2VzIG9uIHRvcCBvZiB0aGUgJnF1b3Q7Y29yZSZxdW90OyBzZXJ2aWNlIG9mIGNvbnRl bnQgZGVsaXZlcnkuIEhvd2V2ZXIsIG91ciBvYmplY3RpdmUgKGJhc2VkIG9uIG15IGludGVycHJl dGF0aW9uIG9mIHRoZSBDRE5JIGNoYXJ0ZXIpIGlzIHRvIGZvY3VzIG9uIHdoYXQgaXMgbmVjZXNz YXJ5IHRvIGludGVyY29ubmVjdA0KIENETnMgdG8gZGVsaXZlciBjb250ZW50IGZyb20gYSBDU1Ag dG8gYW4gRW5kIFVzZXIgdGhhdCBpcyB0YXJnZXRlZCBhbmQgZGVwbG95YWJsZSB3aXRoaW4gYSBz aG9ydCB0aW1lIGZyYW1lICgxOC0yNCBtb250aHMpLjxicj4NCjxicj4NCkNvbnRlbnQgdHJhbnNm b3JtYXRpb24vYWRhcHRhdGlvbiBpcyBub3QgYW4gZXNzZW50aWFsIHJlcXVpcmVtZW50IGluIG9y ZGVyIHRvIGFjaGlldmUgdGhhdCBhaW0gKHdlIGNhbiBkZWxpdmVyIGNvbnRlbnQgZnJvbSBDU1Bz IHRvIEVuZCBVc2VycyB2aWEgbXVsdGlwbGUgQ0ROcyB3aXRob3V0IG5lZWRpbmcgb3IgcmVxdWly aW5nIGFueSBDRE4gc3VwcG9ydHMgY29udGVudCBhZGFwdGF0aW9uKS48YnI+DQo8YnI+DQpJbiBt eSBvcGluaW9uIHdlIGhhdmUgZW5vdWdoIHdvcmsgdG8gZG8gYWxyZWFkeSB3aXRob3V0IHRyeWlu ZyB0byBleHBhbmQgdGhlIHNjb3BlIG9mIG91ciB3b3JrIHRvIGluY2x1ZGUgYWRkaXRpb25hbCBy ZXF1aXJlbWVudHMgdGhhdCBkbyBub3QgaGVscCB1cyBhZGRyZXNzIG91ciBjb3JlIG9iamVjdGl2 ZXMgYXMgbGFpZCBvdXQgaW4gdGhlIENETkkgY2hhcnRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PkluIHRoaXMgY2FzZSwgaXQgaXMgbm90aGluZyByZWxhdGVkIHRvIGhvdyB0aGUgdXNlciBzZWxl Y3QgZm9ybWF0cyBvbiBDUCB3ZWJzaXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PlNvLCBpdCBpcyB0aGUgQ1AgYW5kIHVzZXIgdG8gZGVjaWRlIHRoZSBjb250ZW50IGZvcm1hdCBu b3QgdGhlIENETih5b3VyIGFzc2VydCBpcyBub3QgY29ycmVjdCBhbmQgc2VlbXMgeW91IHRha2Ug dGhhdCBhc3NlcnQgYXMgeW91ciBiYXNlIGZvciB0aGUgZGlzY3Vzc2lvbikuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QXMgZm9yICZxdW90O3RoZSBjb3JlIENE TiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgQ0ROcyB0b2RheSZxdW90OywgSSBoYXZlIGV2ZXIg cmFpc2VkIGFuIGVtYWlsIGJlZm9yZSB0aGF0IHlvdXIgY29tcGFueSdzIHdlYnBhZ2UgaGFzIGNs YWltZWQgc3VwcG9ydGluZyBtZWRpYSB0cmFuc2Zvcm1hdGlvbiBhbmQgbXVsdGktc2NyZWVuDQog c2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Q ZXJoYXBzLCBJIGxpa2UgYXNraW5nIHlvdSBsaXN0IHNvbWUgZmVhdHVyZXMgdGhhdCB5b3UgZmVl bCBhcmUgdGhlIGNvcmUgZnVuY3Rpb25hbGl0aWVzIGJ5IGV4aXN0aW5nIG1haW4gc3RyZWFtIENE TnMuIFRodXMgd2UgbWF5IGNvbXBhcmUgYW5kIHRha2UgZGVlcCBsb29rLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJy Pg0KSSB0aGluayB0aGUgY29yZSBmdW5jdGlvbmFsaXR5IG1hcHMgcHJldHR5IHdlbGwgdG8gdGhl IENETkkgaW50ZXJmYWNlcywgbmFtZWx5OiBSZXF1ZXN0IFJvdXRpbmcsIE1ldGFkYXRhIGNvbmZp Z3VyYXRpb24sIGxvZyBwcm9kdWN0aW9uIGFuZCBjb250cm9sIHBsdXMgY29udGVudCBhY3F1aXNp dGlvbiBhbmQgY29udGVudCBkZWxpdmVyeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgZ3Vlc3Mg bWFueSBwZW9wbGUgaGF2ZSB0aGUgZXhwZXJpZW5jZS9rbm93bGVkZ2Ugb2YgY29udGVudCByZWxh dGVkIHNlcnZpY2UuIFRoZSB1c2VyIGFuZCBDUCBvbmx5IGNhcmUgd2hldGhlciB0aGUgQ0ROIHBy b3ZpZGVycyBtYXkgc2F0aXNmeSB0aGVpciByZXF1aXJlbWVudCB3aGlsZSBub3QgY2FyZQ0KIHRo ZSBpbnRlcm5hbCBwcm9jZXNzLiBKdXN0IGFzIEdTTS9QU1ROIGludGVyY29ubmVjdGlvbiwgdGhl IHVzZXIgb25seSBjYXJlIHN1Y2Nlc3NmdWwgaW50ZXJjb25uZWN0aW9uIHdoaWxlIG5vdCBjYXJl IGhvdyB0aGUgdm9pY2UgaXMgdHJhbnNmb3JtZWQgaW4gcHJvY2Vzcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5CZXNpZGVzLCBJIGxpa2UgcmFpc2UgYSBjYXNlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkdpdmVuIGN1cnJlbnRseSBCQkMgcmVj cnVpdHMgQ0ROIHByb3ZpZGVycyB0aGF0IG1heSBzdXBwb3J0IDEwIG1lZGlhIGZvcm1hdHMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+T25lIGNhbmRpZGF0 ZSBpcyB5b3VyIGNvbXBhbnksIGFub3RoZXIgaXMgQ0ROLVguIFRoZSB1c2VycyBhcmUgbG9jYXRl ZCBpbiBGcmFuY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+U28gYm90aCB5b3VyIGNvbXBhbnkgYW5kIENETi1YIHNob3VsZCBjb25uZWN0IGEgRnJhbmNl IENETiBwcm92aWRlcihDRE4tWSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+SWYgeW91ciBjb21wYW55J3Mgc29sdXRpb24gaXMgdG8gc2VuZCAxMCBzdHJl YW1zIG9mIGRpZmZlcmVudCBmb3JtYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5vZiBvbmUgY29udGVudCB0byBDRE4tWTsgV2hpbGUgQ0ROLVgncyBzb2x1 dGlvbiBpcyB0byBzZW5kIDEgc3RyZWFtIHRvIENETi1ZIHdoaWxlIENETi1ZIG1heSBjb25kdWN0 IHNvbWUgYWRhcHRhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5Db21wYXJpbmcgdGhlc2UgdHdvIHNvbHV0aW9ucywgZm9yIHlvdXIgY29tcGFueSBh bmQgQ0ROLVgsIGFic29sdXRlbHkgdGhlIGNvc3Qgb2YgQ0ROLVggaXMgbXVjaCBsb3dlci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gb3IgQ0ROLVksIGlu IHNvbHV0aW9uLTEsIGl0IHNob3VsZCByZWNlaXZlL2ZvcndhcmQgMTAgc3RyZWFtcyA7IHdoaWxl IGluIHNvbHV0aW9uLTIsIGl0IHNob3VsZCBvbmx5IHJlY2VpdmUgMSBzdHJlYW0gYnV0IG5lZWQg dG8gdGFrZSB0cmFuc2Zvcm1hdGlvbiB0byBvdXRwdXQgMTAgc3RyZWFtcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5XaGljaCBzb2x1dGlvbiBpcyBtb3JlIGNv bXBldGl0aXZlLiBpdCBpcyBTb2x1dGlvbiAxLCByaWdodC4gUmVtZW1iZXIgdGhlIHByaWNlIGZy b20gQkJDIGlzIHNhbWUgdG8gYm90aCB5b3VyIGNvbXBhbnkgYW5kIENETi1YIG9yIEJCQyB3b3Vs ZCBzZWxlY3Qgb25lIENETiBwcm92aWRlciB3aXRoIHRoZQ0KIGxvd2VyIHByaWNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPklmIGEgQ0ROIHByb3ZpZGVy IG1heSBub3QgZ2V0IHRoZSBjb250cmFjdCBmcm9tIENQLCBob3cgaXQgbWF5IHNheSBpdCBpcyBu b3QgYSBjb3JlIGZ1bmN0aW9uYWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YnI+DQpXaGF0IHlvdSBhcmUgZGVz Y3JpYmluZyBpcyBhIHBvc3NpYmxlIG9wdGltaXphdGlvbiB0aGF0IGEgcGFydGljdWxhciBDRE4g bWF5IHdpc2ggdG8gaW1wbGVtZW50IG5vdCBhIGNvcmUgZnVuY3Rpb25hbGl0eSByZXF1aXJlZCB0 byBlbmFibGUgY29udGVudCBkZWxpdmVyeSBiZXR3ZWVuIGludGVyY29ubmVjdGVkIENETnMuIEkg Y2FuIHRoaW5rIG9mIG1hbnkgb3B0aW1pemF0aW9ucyB0aGF0IGEgQ0ROIGNvdWxkIGltcGxlbWVu dCB0byBkaWZmZXJlbnRpYXRlDQogdGhlaXIgc2VydmljZSBidXQgdGhlIGludGVybmFsIHdvcmtp bmdzIG9mIGFuIGluZGl2aWR1YWwgQ0ROIGFyZSBvdXQgb2Ygc2NvcGUgb2Ygb3VyIGNoYXJ0ZXIu PGJyPg0KPGJyPg0KU28gdG8gcmVwZWF0IG15IHBvc2l0aW9uIGZvciBhIGZpbmFsIHRpbWU6IENv bnRlbnQgYWRhcHRhdGlvbiBpcyBub3QgYSBjb3JlIGZ1bmN0aW9uIHJlcXVpcmVkIHRvIGVuYWJs ZSBjb250ZW50IGRlbGl2ZXJ5IGJldHdlZW4gaW50ZXJjb25uZWN0ZWQgQ0ROcyBhbmQgdGhlcmVm b3JlIGdpdmVuIHRoZSB3b3JrbG9hZCB3ZSBhbHJlYWR5IGhhdmUgdG8gc3BlY2lmeSBzb2x1dGlv bnMgdGhhdCBkbyBhZGRyZXNzIHRoZSBjb3JlIGZ1bmN0aW9uYWxpdHkNCiByZXF1aXJlZCB0byBp bnRlcmNvbm5lY3QgQ0ROcyBJIGRvIG5vdCB0aGluayB3ZSBzaG91bGQgYmUgdHJ5aW5nIHRvIGFk ZCBtb3JlIHdvcmsgaW50byB0aGF0IHdvcmtsb2FkIGFzIGl0IHdpbGwgb25seSBkaXN0cmFjdCB1 cyBmcm9tIGFjaGlldmluZyBvdXIgZ29hbCBvZiBwcm9kdWNpbmcgZGVwbG95YWJsZSBzb2x1dGlv bnMgd2l0aGluIHRoZSB0aW1lZnJhbWUgd2UgYXJlIGJlaW5nIHRvbGQgYnkgb3BlcmF0b3JzIHRo ZXkgbmVlZHMgc29sdXRpb25zDQogd2l0aGluLjxicj4NCjxicj4NCkJlbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+U28sIGlmIHdlIGFsbCByZWFsaXplIHRoYXQgY3VycmVudGx5IHRoZSBtZWRpYSB0 eXBlIGlzIHJpY2gsIHRoZSBDRE4gcHJvdmlkZXJzIHNob3VsZCBzdXJ2aXZlIGluIHRoZSBleGlz dGluZyBlY29zeXN0ZW0gYW5kIHN1cHBvcnQgdGhlIG1lZGlhIHR5cGVzIGFzIHJlcXVpcmVkIGJ5 IHRoZSBtYXJrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QmFjayB0byB0aGUgY2Fz ZSBvZiBHU00vRy43MTEsIGl0IGp1c3Qgd2hlbiBjb25jZXJuaW5nIHRoZSBpbnRlcmNvbm5lY3Rp b24sIHRoZSB0cmFuc2Zvcm1hdGlvbiBzaG91bGQgYXQgb25jZSBiZSBzb2x2ZWQuIE90aGVyd2lz ZSB0aGUgaW50ZXJjb25uZWN0aW9uIG1heSBub3QgYmUgb3BlcmF0ZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QnIsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+RnJvbTogQmVuIE5pdmVuLUplbmtpbnMNCjxhIGhy ZWY9Im1haWx0bzpbbWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrXSI+W21haWx0bzpiZW5A bml2ZW4tamVua2lucy5jby51a108L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+U2VudDogV2VkbmVzZGF5LCBPY3RvYmVyIDEyLCAyMDExIDEyOjE5IEFN PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VG86IFpob3Va aGlwZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Q2M6 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpwaGlsaXAuZWFyZGxleUBidC5jb20iPnBoaWxpcC5lYXJkbGV5QGJ0LmNvbTwvYT47 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5aaGlwZW5nLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPk9uIDExIE9jdCAyMDExLCBhdCAwNToxNiwgWmhvdVpoaXBl bmcgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5C ZW4gYW5kIFBoaWxpcCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgbGlrZSB0byByZXNwb25kIHlvdXIgY29uY2VybiBpbiB0 aGlzIG9uZSBlbWFpbDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+QmVuLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SSBmZWVsIHdo YXQgd2UgYXJlIG5vdyBkaXNjdXNzaW5nIGlzIHdoYXQgaXMgdGhlICZxdW90O2NvcmUmcXVvdDsg ZnVuY3Rpb24gb2YgQ0ROLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+QXMgeW91IHNheSwgQ0ROIGlzIHVzZWQgdG8gZGVsaXZl ciBjb250ZW50LiBUaGF0IGlzIGFic29sdXRlbHkgY29ycmVjdCB0aGF0IHRoZSBkZWxpdmVyeSBj YXBhYmlsaXR5IGlzIHRoZSBjb3JlIHJlcXVpcmVtZW50IGZvciBDRE4gc3lzdGVtLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ V2hpbGUgQ0ROIGlzIHVzZWQgdG8gcHJvdmlkZSB0aGUgY29udGVudCBkZWxpdmVyeSBzZXJ2aWNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+V2hhdCBtZWFucyBzZXJ2aWNlLiBJdCBzaG91bGQgaW5jbHVkZSAmcXVvdDt0aW1l JnF1b3Q7ICZxdW90O2xvY2F0aW9uJnF1b3Q7IGFuZCAmcXVvdDttZWRpYSB0eXBlJnF1b3Q7LCBl dGMuIFRoZXNlIGZlYXR1cmVzIGFyZSBhbGwgdGhlIGNvcmUgZmVhdHVyZSBmb3IgYSBzZXJ2aWNl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+SWYgd2Ugb25seSBjb25jZXJuICZxdW90O2RlbGl2ZXJpbmcgb25lIGRhdGEgYmxv Y2smcXVvdDssIEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgaXNzdWVzIHN1Y2ggYXMgJnF1b3Q7 bG9nZ2luZyZxdW90OyAmcXVvdDtnZW9ncmFwaGljIGNvbnN0cmFpbnQmcXVvdDsgYXJlIHRoZSBj b3JlIG9mIENETi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Rm9yICZxdW90O3dpdGhvdXQgZXhwbGlj aXQga25vd2xlZGdlIG9mIHdoYXQgdGhhdCBjb250ZW50IGFjdHVhbGx5IGlzICZxdW90OywgSSBh bSBub3Qgc3VyZSB3aGV0aGVyIHRoZSB3b3JkaW5nIGlzIGFjY3VyYXRlIHNpbmNlIGdlbmVyYWxs eSBhIENETiBtYXkgY2xhaW0gaXQgc3VwcG9ydCBkaWZmZXJlbnQgbWVkaWFzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Qnkg dGhpcyBvcHBvcnR1bml0eSwgSSBsaWtlIHRvIHNoYXJlIGEgdXNlIGNhc2U6IGEgY2FsbCBmcm9t IGEgR1NNIHBob25lIHRvIGEgUFNUTiB0ZWxlcGhvbmUsIHRoZSB2b2ljZSBzdHJlYW0gc2hvdWxk IGJlIHRyYW5zZm9ybWVkIGZyb20gR1NNIHZvaWNlIHRvIEcuNzExLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Rm9yIHRoZSB1 c2VyLCBoZSBkb2VzIG5vdCBuZWVkIHRvIGtub3cgd2hhdCB0eXBlIG9mIGRhdGEgaGFzIGJlZW4g dHJhbnNmZXJyZWQsIGJ1dCB0aGUgb3BlcmF0b3IgaGFzIGRvbmUgc29tZSB3b3JrIHRvIGludGVy Y29ubmVjdCB0d28gc3lzdGVtcywgcmlnaHQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIGxpa2UgdG8ga25vdyB3aGV0aGVy IHlvdSBtYXkgYWNjZXB0IHRoYXQgbXkgdXNlIGNhc2UgaXMgc2ltaWxhciB0byB0aGlzIGNhc2Ug YWJvdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+SSBkb24ndCB0aGluayB5b3VyIHVzZSBjYXNlIGlzIHNpbWlsYXIgdG8gdGhlIGFu YWxvZ3kgb2YgbW9iaWxlIG5ldHdvcmtzIGJlaW5nIGludGVyY29ubmVjdGVkIHRvIFBTVE4gbmV0 d29ya3MuIEluIHRoZSBjYXNlIG9mIGNvbnRlbnQgZGVsaXZlcnkgdGhlIG5lZ290aWF0aW9uIGlz IGRvbmUgYmV0d2Vlbg0KIHRoZSBVc2VyL0NsaWVudCBhbmQgdGhlIENvbnRlbnQgUHJvdmlkZXIg YW5kIHRoZSBDRE4gaXMganVzdCB1c2VkIHRvIGV4ZWN1dGUvcGVyZm9ybSB0aGUgZGVsaXZlcnkg dGhhdCBoYXMgYmVlbiBuZWdvdGlhdGVkLiBUaGUgQ0ROIGlzIG5vdCBpbnZvbHZlZCBpbiB0aGUg ZGVjaXNpb24gbWFraW5nIG9mIHdoYXQgcmVwcmVzZW50YXRpb25zIHRoZSBDb250ZW50IFByb3Zp ZGVyIGRlY2lkZXMgdG8gb2ZmZXIgdG8gdGhlIFVzZXIvQ2xpZW50IG9yIGluDQogd2hhdCByZXBy ZXNlbnRhdGlvbnMgdGhlIFVzZXIvQ2xpZW50IGRlY2lkZXMgdG8gcmVxdWVzdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkFzIGZvciB5b3Ugc2FpZCBzZWxl Y3RpbmcgbWVkaWEgYnkgdGhlICZxdW90O3BvcnRhbCZxdW90OywgeW91IG1heSBzZWUgdGhlIHdh eSAmcXVvdDsgdUNETiBkZWxpdmVycyBtdWx0aXBsZSBtZWRpYSBzdHJlYW1zIHRvIGRDRE4mcXVv dDsgaXMgbm90IGdvb2QgdGhhbiAmcXVvdDt1Q0ROIGRlbGl2ZXJzIG9uZSBtZWRpYSBzdHJlYW0g dG8gZENETg0KIGFuZCBkQ0ROIHRha2VzIHNvbWUgYWRhcHRhdGlvbiB0byBzdXBwb3J0IG11bHRp cGxlIG1lZGlhIHR5cGVzJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPk5vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0IGlz IGFuIG9wdGltaXNhdGlvbiwgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBhY3R1YWxs eSBkZWxpdmVyIHRoZSBjb250ZW50IChhbmQgcmVwb3J0LCBiaWxsLCBldGMuIGZvciB0aGF0IGRl bGl2ZXJ5KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5NeSBw b3NpdGlvbiBpcyB0aGF0IHdlIHNob3VsZCBmb2N1cyBvbiBob3cgdG8gZW5hYmxlIHRoZSBpbnRl cmNvbm5lY3Rpb24gb2YgdGhlIGNvcmUgQ0ROIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSBDRE5z IHRvZGF5ICh3aGljaCBpcyBhbHNvIG15IGludGVycHJldGF0aW9uIG9mIHRoZSBzY29wZQ0KIG9m IHRoZSBDRE5JIHdvcmtpbmcgZ3JvdXAgYXMgZXhwcmVzc2VkIGluIGl0cyBjaGFydGVyKSBiZWNh dXNlIGRvaW5nIHNvIGlzIGEgc2lnbmlmaWNhbnQgcGllY2Ugb2Ygd29yayBpbiBpdHNlbGYuIExl dCdzIG5vdCBzdGFydCB0cnlpbmcgdG8gYWRkIGluIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eSBi ZXlvbmQgd2hhdCB0aGUgbWFqb3JpdHkgb2YgQ0ROcyBzdXBwb3J0IHRvZGF5IGFzIHRoYXQgd2ls bCBqdXN0IGRlbGF5IHVzIGdldHRpbmcgdXNhYmxlDQogc3BlY2lmaWNhdGlvbnMgaW50byB0aGUg bWFya2V0IGluIGEgdGltZWx5IGZhc2hpb24gSU1PLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkJlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+QSBnb29kIHF1ZXN0aW9uIGlzICZxdW90O3NlY3VyaXR5JnF1b3Q7IHNpbmNl IEkgaGF2ZSBkb25lIHNpeCB5ZWFycyBvbiB0aGUgRFJNPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5hbmQgbGlrZSB0byBwcm9t b3RlIHRoZSBEUk0gYWxsIGFyb3VuZCB0aGUgd29ybGQ6KSBJZiB0aGUgY29udGVudCBpcyBuZWVk ZWQgdG8gYmUgcHJvdGVjdGVkLCBnZW5lcmFsbHkgeW91IG1heSBrbm93IGFsbCB0aGUgc3lzdGVt cyBzaG91bGQgYmUgZ3JhbnRlZCBieSB0aGUgY29udGVudCBvd25lci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhlcmUgSSBh bHNvIGxpa2UgdG8gY2xhcmlmeSB0aGF0IG5vdCBvbmx5IHRoZSBtZWRpYSBpdHNlbGYgYnV0IHRo ZSBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHNlcnZpY2UgaXRzZWxmIChzdWNoIGFzIHRoZSBnZW9n cmFwaGljIGNvbnN0cmFpbnQpIHNob3VsZCBiZSBwcm90ZWN0ZWQgYWxzby48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNvLCB0 cnVzdCBpcyBub3QgYSBwcm9ibGVtIGZvciB0aGUgbWVkaWEuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PlBoaWxpcCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPlRoYW5rIHlvdSB0aGF0IHlvdSBmZWVsIENvbnRlbnQgQWRhcHRpb24g aXMgYW4gaXNzdWUgZm9yICZxdW90O1JlcXVpcmVtZW50cyZxdW90OyBidXQgSSBkbyBub3Qga25v dyB3aHkgaXQgaXMgbm90IGZvciBVc2UgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkkgbGlrZSB0byBjbGFyaWZ5IHRv IFUgdGhhdCBpdCBpcyBpbXBvcnRhbnQgZm9yIHlvdSBvcGVyYXRvciBzaW5jZSBpdCBtYXkgc2F2 ZSBpbnZlc3RtZW50IGlmIHRoZSBzeXN0ZW0gbWF5IHN1cHBvcnQgZGlmZmVyZW50IHNlcnZpY2Vz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Rm9yIHVzIHZlbmRvciwgd2UgYXJlIGhhcHB5IG9wZXJhdG9yIG1heSBpbnN0YWxs IGEgc3lzdGVtIGZvciB0aGUgbW9iaWxlIHNlcnZpY2UgYW5kIGFub3RoZXIgc3lzdGVtIGZvciB0 aGUgRkJCIHNlcnZpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5CdXQgdGhlIHJlYWxpdHkgaXMgYWxsIG9wZXJhdG9ycyBh c2sgdXMgdG8gcHJvdmlkZSBhIHN5c3RlbSB0aGF0IG1heSBzdXBwb3J0IGRpZmZlcmVudCBzZXJ2 aWNlIHN5c3RlbXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkZyYW5rbHksIEJlbiBhbmQgUGhpbGlw LCBJIHJlbWVtYmVyIEkgaGF2ZSBleHBsYWluZWQgc29tZXdoZXJlIHRoYXQgdG8gaW1wbGVtZW50 IHRoaXMgaXMgcmF0aGVyIHNpbXBsZSAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5BdCBsZWFzdCB0aGUgVXNlIGNhc2UgYW5k IFJlcXVpcmVtZW50IGFyZSBpbmZvcm1hdGlvbmFsIHRvIGJlIHJlZmVycmVkIGluIGZ1dHVyZSB3 b3JrLiBTbyBJIGRvIHJlYWxseSBmZWVsIHlvdSBtYXkgYWNjZXB0IGl0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+T2YgY291 cnNlIEkgbGlrZSB0byByZXNwb25kIHlvdXIgbW9yZSBjb25jZXJuIGFuZCBjb21tZW50cy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gcm9t OjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVm PSJtYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tIj5waGlsaXAuZWFyZGxleUBidC5jb208L2E+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpbbWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbV0iPlttYWlsdG86cGhpbGlwLmVh cmRsZXlAYnQuY29tXTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNlbnQ6IE1vbmRheSwgT2N0b2JlciAxMCwgMjAxMSAx MToyMiBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpiZW5Abml2ZW4tamVua2lucy5jby51ayI+YmVuQG5p dmVuLWplbmtpbnMuY28udWs8L2E+OyBaaG91WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Q2M6PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpjZG5p QGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U3ViamVjdDogUkU6IFtDRE5pXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5CZW4sIFpoaXBlbmcsIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+SSB0aGluayB0 aGF0IENvbnRlbnQgQWRhcHRhdGlvbiBpcyBtb3JlIGFuIGlzc3VlIGZvciB0aGUgUmVxdWlyZW1l bnRzIGRvYyB0aGFuIGZvciB0aGUgVXNlIGNhc2VzIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5UaGUga2V5IHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ugd2FudCB0aGUgQ0ROSSBpbnRlcmZhY2Vz IHRvIGJlIGFibGUgdG8gY29wZSB3aXRoIGEgc2NlbmFyaW8gd2hlcmUgKHNheSkgSEQvU0QgY29u dmVyc2lvbiBpcyBkb25lIGluIHRoZSBkQ0ROICZhbXA7IHRvIHNpZ25hbCBhYm91dCB0aGlzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIHRoaW5rIHRoYXQgY29waW5nIHdpdGggdGhpcyBzY2VuYXJp byBpcyBhIHNlY29uZCBvcmRlciByZXF1aXJlbWVudCwgaWUgd2Ugc2hvdWxkIG5vdCB3b3JyeSBh Ym91dCBpdCBpbiB0aGUgaW5pdGlhbCBzdGFuZGFyZHMtdHJhY2sgd29yay4gSSBkb24ndCBrbm93 LCBkaWQgd2UgZXZlciBkZWNpZGUNCiB3aGV0aGVyIHRoZSBVc2UgY2FzZXMgZG9jIGlzIHJlc3Ry aWN0ZWQgdG8gJnF1b3Q7aW5pdGlhbCZxdW90OyBzY2VuYXJpb3MsIG9yIHdoZXRoZXIgaXQncyBh bGwtZW5jb21wYXNzaW5nLCBpZSBjb3ZlcmluZyAmcXVvdDtmdXR1cmUmcXVvdDsgc2NlbmFyaW9z IGFzIHdlbGw/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlNjb3R0LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+UmVhZGluZyBzb21l IG9mIHlvdXIgZXhhbXBsZXMsIHRoZXkgc2VlbSB0byBiZSB2YWxpZCBldmVuIGlmIGNvbnRlbnQg YWRhcHRhdGlvbiAoSEQvU0QpIGlzIG91dCBvZiBzY29wZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi0gYSBkQ0ROIG1pZ2h0 IGZvciBzb21lIHJlYXNvbiBiZSB1bndpbGxpbmcgdG8gZGlzdHJpYnV0ZSBIRD88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPi0g YSBDU1AgbWlnaHQgd2FudCB0byBtYWtlIHN1cmUgdGhlIGRDRE4gY2FuIHVzZSBITFMgZW5jYXBz dWxhdGlvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPkJ1dCB0aGVzZSBzb3J0cyBvZiBleGFtcGxlcyBzZWVtIHRvIGJlIHN0 YXRpYyBwb2xpY3kgdGhpbmdzICh0byBkbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+d2l0aCB0aGUgY2FwYWJpbGl0aWVzICZh bXA7IHByZWZlcmVuY2VzIG9mIHRoZSBDRE5zICZhbXA7IENTUCksIHJhdGhlciB0aGFuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5tZXRhZGF0YSBhc3NvY2lhdGVkIHdpdGggYSBwYXJ0aWN1bGFyIHBpZWNlIG9mIGNvbnRlbnQu IEluIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+ZGlzY3Vzc2lvbiBzbyBmYXIsIEkgdGhpbmsgbmVnb3RpYXRpb24gYWJv dXQgc3RhdGljIHBvbGljeSBzdHVmZiBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+cmF0aGVyIG91dCBvZiBzY29wZSg/KTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5PbiBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgYW4gaW50ZXJl c3RpbmcgcXVlc3Rpb24gaXMgd2hldGhlciB0cnVzdCBpcyB0cmFuc2l0aXZlLiBEb24ndCB0aGlu ayBpdCBuZWVkIGJlIC0ganVzdCBiZWNhdXNlIENTUCB0cnVzdHMgdUNETiwgYW5kIHVDRE4gdHJ1 c3RzIGRDRE4gZG9lc24ndCBtZWFuDQogdGhhdCB0aGUgQ1NQIGF1dG9tYXRpY2FsbHkgdHJ1c3Rz IHRoZSBkQ0ROLiBIb3dldmVyLCBpIHN1c3BlY3QgdGhpcyBjYW4gZ2V0IGFyYml0cmFyaWx5IGNv bXBsZXggLSBzbyBvbmUgcG9zc2liaWxpdHkgaXMgdG8gc2F5IHRoYXQgd2Ugd2lsbCBvbmx5IGhh bmRsZSBjYXNlcyB3aGVyZSB0aGUgdHJ1c3QgaXMgdHJhbnNpdGl2ZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+QmVzdCB3aXNoZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnBoaWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5QaGlsaXAgRWFyZGxleTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+UmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgU3Ry YXRlZ3k8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+VGhpcyBlbWFpbCBjb250YWlucyBCVCBpbmZvcm1h dGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29uZmlkZW50aWFsLiBJdCdzIG1lYW50 IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgeW91 J3JlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LA0KIG5vdGUgdGhhdCBkaXNjbG9zaW5nLCBj b3B5aW5nLCBkaXN0cmlidXRpbmcgb3IgdXNpbmcgdGhpcyBpbmZvcm1hdGlvbiBpcyBwcm9oaWJp dGVkLiBJZiB5b3UndmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIGxldCBt ZSBrbm93IGltbWVkaWF0ZWx5IG9uIHRoZSBlbWFpbCBhZGRyZXNzIGFib3ZlLiBUaGFuayB5b3Uu IFdlIG1vbml0b3Igb3VyIGVtYWlsIHN5c3RlbSwgYW5kIG1heSByZWNvcmQgeW91ciBlbWFpbHMu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5Ccml0aXNoIFRlbGVjb21tdW5pY2F0aW9ucyBwbGM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlJlZ2lzdGVyZWQg b2ZmaWNlOiA4MSBOZXdnYXRlIFN0cmVldCBMb25kb24gRUMxQSA3QUogUmVnaXN0ZXJlZCBpbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZx dW90OyI+RW5nbGFuZCBubzogMTgwMDAwMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Gcm9tOjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86Y2RuaS1i b3VuY2VzQGlldGYub3JnIj5jZG5pLWJvdW5jZXNAaWV0Zi5vcmc8L2E+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpbbWFpbHRv OmNkbmktYm91bmNlc0BpZXRmLm9yZ10iPlttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXTwv YT4NCiBPbiBCZWhhbGY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDssJnF1b3Q7c2VyaWYmcXVvdDsiPk9mIEJlbiBOaXZlbi1KZW5raW5zPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TZW50OiAx MCBPY3RvYmVyIDIwMTEgMTI6MDQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlRvOiBaaG91WmhpcGVuZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Q2M6PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U3ViamVjdDogUmU6 IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5Db2xsZWFndWVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JTU8gU2Vj dGlvbiA1LjEuMyBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBVc2UgQ2FzZXMgZHJhZnQuIENv bnRlbnQgQWRhcHRhdGlvbiAoaS5lLiB0YWtpbmcgaW4gYSBjb250ZW50IGl0ZW0gaW4gb25lIGZv cm1hdCBhbmQgdHJhbnNmb3JtaW5nIGl0IHRvIGFub3RoZXIgZm9ybWF0IG9yIHJlcHJlc2VudGF0 aW9uKQ0KIGlzIG5vdCBhICZxdW90O2NvcmUmcXVvdDsgZnVuY3Rpb24gb2YgYSBDRE4gd2hpY2gg dHlwaWNhbGx5IGRlbGl2ZXJzIHRoZSBjb250ZW50IHRoYXQgaXMgcmVxdWVzdGVkIHdpdGhvdXQg ZXhwbGljaXQga25vd2xlZGdlIG9mIHdoYXQgdGhhdCBjb250ZW50IGFjdHVhbGx5IGlzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZx dW90O3NlcmlmJnF1b3Q7Ij5MZXQncyBub3QgZm9yZ2V0IHRoYXQgaW4gYnVpbGRpbmcgYW4gZW5k IHRvIGVuZCBjb250ZW50IHNlcnZpY2UgdGhlIENETiBpcyBvbmx5IG9uZSBjb21wb25lbnQgYW5k IGlzIHRoZSBjb21wb25lbnQgdGFza2VkIHdpdGggZXhlY3V0aW5nIHRoZSBkZWxpdmVyeSBvZiBh IHNwZWNpZmljIHJlcHJlc2VudGF0aW9uDQogKHZlcnNpb24vY29weS9mb3JtYXQgZXRjLikgb2Yg dGhlIHNlbGVjdGVkIGNvbnRlbnQgbm90IHRoZSBjb21wb25lbnQgdGFza2VkIHdpdGggZGVjaWRp bmcgKG9yIGFwcGx5aW5nIHBvbGljeSkgb24gd2hpY2ggdmVyc2lvbi9jb3B5L3JlcHJlc2VudGF0 aW9uIG9mIGNvbnRlbnQgc2hvdWxkIGJlIGRlbGl2ZXJlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ VGhlIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHZlcnNpb24vY29weS9yZXByZXNlbnRhdGlvbiB0byBv ZmZlciBhbmQgYWxsb3cgdG8gYmUgZGVsaXZlcmVkIHRvIGEgZ2l2ZW4gZGV2aWNlL3VzZXIgaXMg aW1wbGVtZW50ZWQgb3V0c2lkZSBvZiB0aGUgQ0ROIChlLmcuIGJ5IHRoZSAmcXVvdDtwb3J0YWwm cXVvdDsgd2hlcmUNCiB0aGUgdXNlciBmaXJzdCBtYWtlcyB0aGVpciBjb250ZW50IHNlbGVjdGlv biBwcmlvciB0byB0aGUgQ0ROIGJlY29taW5nIGludm9sdmVkIGluIHRoZSBkZWxpdmVyeSBvZiB0 aGUgc2VsZWN0ZWQgY29udGVudCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkJlbjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5PbiA4IE9jdCAyMDExLCBhdCAwODoyMCwgWmhvdVpoaXBlbmcgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+Rm9sbG93aW5nIFNjb3R0J3MgY29tbWVudHMgb24gc2VjdGlv biA1LjEuMywgSSBmZWVsIFNjb3R0J3MgZGVzY3JpcHRpb24gb24gdGhlIHVzZSBjYXNlIG9mIEhE IGFuZCBTRCBpcyBub3QgZXhhY3RseSBjb3JyZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5J ZiBvbmUgbW92aWUgaGFzIHR3byBmb3JtYXRzIG9mIEhEIGFuZCBTRCwgdGhlbiB3ZSBoYXZlIHR3 byBjb250ZW50IHdpdGggZGlmZmVyZW50IGlkZW50aWZpZXIuIEluIERSTSBzY29wZSwgdGhlIGJh c2ljIHVuaXQgaXMgYSBjb250ZW50IGNvcHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5IZXJlIHRoZSBmaXJzdCBidWxsZXQgJnF1b3Q7YSBz dWJzZXQgb2YgZW5jb2RpbmdzIGRlbGl2ZXJhYmxlIHRvIHNwZWNpZmljIGRldmljZXMsJnF1b3Q7 IGhhcyBsaXN0ZWQgdGhlIGNhc2Ugb2YgY29udGVudCBhZGFwdGF0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5JbiBsYXN0IG1vbnRoLCBJIGhhdmUgY29udGFjdGVkIHRoZSBBdXRob3JzIG9m IHRoaXMgZG9jdW1lbnQgYW5kIHRha2VuIHNvbWUgZW1haWwgZXhjaGFuZ2VzIHdpdGggR3JhbnQg YW5kIFBoaWxpcCAoQlQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIGhhdmUgc2hvd24gQlQg d2l0aCBzb21lIGluZm9ybWF0aW9uIHRoYXQgSSBrbm93IGluIHRoaXMgY2FzZSBhbmQgYXJlYSB0 byBleHBsYWluIHRoZSBjb250ZW50IGZsZXhpYmlsaXR5IGlzIGN1cnJlbnRseSBhIGJhc2ljIHJl cXVpcmVtZW50IGZvciBDRE4gc2VydmljZSBhbmQgcmVsYXRlZCBuZWdvdGlhdGlvbg0KIGlzIG5l ZWRlZCBpbiB0aGUgQ0ROIGludGVyY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ TWVhbndoaWxlLCBJIHNob3VsZCBhbHNvIGludml0ZSB5b3UgaW4gdGhpcyBncm91cCByYWlzaW5n IHlvdXIgY29tbWVudHMgb3IgcXVlc3Rpb25zIG9uIHRoaXMgY2FzZSBzaW5jZSBJIGhvcGUgbXkg dXNlIGNhc2UgbWF5IGJlIGluY29ycG9yYXRlZCBpbiB0aGUgdXNlIGNhc2UgZHJhZnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JZiB5b3Ug aGF2ZSBhbnkgbW9yZSBxdWVzdGlvbiBvciBjb21tZW50cywgcGxzIHNoYXJlIGluIHRoaXMgdGhy ZWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2Vy aWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+LS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+RnJvbTogU2NvdHQg V2Fpbm5lcg0KPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86c3dhaW5uZXJAY2lzY28uY29tXSI+W21h aWx0bzpzd2Fpbm5lckBjaXNjby5jb21dPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TZW50 OiBGcmlkYXksIFNlcHRlbWJlciAzMCwgMjAxMSA4OjAyIEFNPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPlRvOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVv dDtzZXJpZiZxdW90OyI+U3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm LWNkbmktdXNlLWNhc2VzLTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+U2VjdGlvbiAyLjMgTm9tYWRpYyBVc2VyczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5UaGlzIGRlc2NyaXB0aW9uIGZhbGxzIHVuZGVyIHRoZSBjYXRlZ29yeSBv ZiBHZW9ncmFwaGljIEV4dGVuc2lvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij55ZXQgdGhlIHRo aXJkIHBhcmFncmFwaCBzdGF0ZXMgdGhlIGNhc2Ugd2hlcmUgYSBkaWZmZXJlbnQgZGV2aWNlIGlz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnVzZWQgaW4gdGhlIHNhbWUgQ0ROIGNvdmVyYWdlIGFy ZWEuICZuYnNwO1RoZSBpbnRlbnQgb2YgdGhpcyB1c2UgY2FzZTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij5uZWVkcyB0byBiZSBjbGFyaWZpZWQuICZuYnNwO1BlcmhhcHMgdGhlIHVzZSBjYXNlIGlz IHRyeWluZyB0byBhZGRyZXNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnRoZSBzY2VuYXJpbyB3 aGVyZSBhIE5vbWFkaWMgVXNlci1BIHdpdGggYW4gYWdyZWVtZW50IGFsbG93aW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPmFjY2VzcyB0byBjb250ZW50IGZyb20gQ1NQLUEgdmlhIHVDRE4gbW92 ZXMgdG8gYSBkQ0ROIGluIGEgZGlmZmVyZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPnJlZ2lv bi4gJm5ic3A7VGhlIGRDRE4gaXMgYWxsb3dlZCB0byBkaXN0cmlidXRlIHRoZSBjb250ZW50IG9m IENTUC1BIHRvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPlVzZXItQTsgaG93ZXZlciwgbm90IG90 aGVyIHVzZXJzIGluIHRoZSByZWdpb24gb2YgdGhlIGRDRE4gYXJlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPmFsbG93ZWQgdG8gcmV0cmlldmUgdGhlIGNvbnRlbnQgdW5sZXNzIHRoZXkgdG9vIGhh dmUgc3VjaCBhbiBhZ3JlZW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5TZWN0aW9uIDUuMS4zIENvbnRlbnQgRW5jb2RpbmcgUmVzdHJp Y3Rpb25zIE5lZWQgdG8gY2xhcmlmeSBpZiB3ZSdyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij50 YWxraW5nIGFib3V0IHRoZSByZXN0cmljdGlvbnMgb24gdGhlIGRlbGl2ZXJ5IG9mIHNwZWNpZmlj IGNvbnRlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+b3IgdGhlIHJlc3RyaWN0aW9ucyBvbiB0 aGUgYWJpbGl0eSBvZiBhIENETiB0byBkZWxpdmVyIHNwZWNpZmljPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPmNvbnRlbnQuICZuYnNwO0kgY2VydGFpbmx5IHVuZGVyc3RhbmQgdGhlIGNhc2Ugd2hl cmUgYSBDU1Agd2lsbCByZXN0cmljdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij50aGUgZGlzdHJp YnV0aW9uIG9mIGNvbnRlbnQgdG8gYSAmcXVvdDttYW5hZ2VkIHBhdGgmcXVvdDsgaWYgc3VjaCBj b250ZW50IGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkhEIHdoaWxlIGFsbG93aW5nIHRoZSBj b250ZW50IGRpc3RyaWJ1dGlvbiB2aWEgYW4gdW4tbWFuYWdlZCBwYXRoIGlmPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7 c2VyaWYmcXVvdDsiPnN1Y2ggY29udGVudCBpcyBTRCAoc2FtZSBjb3VsZCBhcHBseSB0byBlbmNy eXB0aW9uIG1ldGhvZHMsIGRlbGl2ZXJ5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPm1ldGhvZHMs IGV0Yy4pLiAmbmJzcDtPbiB0aGUgY29udHJhcnksIHRoZSBkQ0ROIG1heSBoYXZlIGl0cyBvd248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OywmcXVvdDtzZXJpZiZxdW90OyI+cmVzdHJpY3Rpb25zIG9mIGJsb2NraW5nIHRoZSBkaXN0 cmlidXRpb24gb2YgSEQgY29udGVudCB3aGlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5hbGxv d2luZyB0aGUgZGlzdHJpYnV0aW9uIG9mIFNEIGNvbnRlbnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5vIGZpcnN0IGJ1bGxldCBtYWtlcyBz ZW5zZSBpZiB0aGUgZENETiBjYW4gcGVyZm9ybSBhIHN1YnNldCBvZjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nlcmlm JnF1b3Q7Ij5lbmNhcHN1bGF0aW9ucyBmb3IgYSByZWZlcmVuY2Ugc2V0IG9mIG1lZGlhIChlLmcu IEhMUywgSFNTLCBidXQgbm90PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkRBU0gpIG8gc2Vjb25k IGJ1bGxldCBtYWtlcyBzZW5zZSB3aGVyZSB0aGUgZENETiBkb2Vzbid0IHdhbnQgdG88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oywm cXVvdDtzZXJpZiZxdW90OyI+b2ZmZXIgaGlnaCBiaXQtcmF0ZSB2YXJpYW50cyBvZiB0aGUgbWVk aWEgbyB0aGlyZCBidWxsZXQgbWFrZSBzZW5zZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5pZiB0 aGUgcG9saWN5IGFkZHJlc3NlcyBRb0UgYnV0IEkgZG9uJ3QgdGhpbmsgc3Vic2NyaWJlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LCZxdW90O3NlcmlmJnF1b3Q7Ij5yaWdodHMvYXV0aG9yaXphdGlvbnMgYXBwbHkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5TZWN0aW9uIDEw IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Bc2lkZSBmcm9tIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBXSVRISU4gdGhlIHVDRE4gYW5kIGRDRE4sIEk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ dGhpbmsgd2UgY2FuIGRlc2NyaWJlIHRoaXMgaW4gZm91ciBjb250ZXh0czo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmEuIFRoZSByZWxhdGlv bnNoaXAgYmV0d2VlbiB0aGUgQ1NQIGFuZCB0aGUgdUNETiAodGhlIHByaW5jaXBsZSBjb250cmFj dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5hcnJhbmdlbWVudCBmb3IgZGlzdHJpYnV0aW9uKTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5iLiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHVD RE4gYW5kIGRDRE4gKHRoZSB0cmFuc2l0aXZlIHRydXN0PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsi PnJlbGF0aW9uc2hpcCB0aGF0IGV4dGVuZHMgdGhlIGNvbnRyYWN0IGRlZmluZWQgaW4gKGEpIGFi b3ZlKSBjLiBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+cmVsYXRpb25zaGlwIGJldHdlZW4g dGhlIFVzZXIgYW5kIGRDRE4gKHRoZSByZWNvZ25pdGlvbiBvZiByaWdodCB0bzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90 O3NlcmlmJnF1b3Q7Ij5kb3dubG9hZCBwcmVkaWNhdGVkIG9uIChiKSBhYm92ZSkgZC4gVGhlIHJl bGF0aW9uc2hpcCBiZXR3ZWVuIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5Vc2VyIGFuZCBD U1AgKHRoZSBjb250cmFjdCBhdXRob3JpemluZyB0aGUgdXNlciBhY2Nlc3MgdG8gdGhlPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPmNvbnRlbnQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5UaGUgdXNlciBpcyBub3QgaW50ZXJlc3RlZCBpbiB0 aGUgYS1iIG5vciB0aGUgYi1jIHJlbGF0aW9uc2hpcC4gVGhlPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVv dDsiPnVzZXIgaXMgb25seSBpbnRlcmVzdGVkIGluIHRoZSB0cmFuc3BhcmVuY3kgYW5kIGludGVy b3BlcmFiaWxpdHkgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+dGhlIHNlY3VyaXR5IHJlbGF0 aW9uc2hpcCBiZXR3ZWVuIGQtYiBvciBkLWMgdG8gdGhlIHBvaW50IHRoYXQgdGhlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1 b3Q7c2VyaWYmcXVvdDsiPmF1dGhvcml6YXRpb24gZ3JhbnRlZCBpbiBkLWEgaXMgdmlhYmxlIHdo ZW4gdGhlIGRlbGl2ZXJ5IGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmluaXRpYXRlZCB2aWEg ZWl0aGVyIGQtYiBvciBkLWMuICZuYnNwO0FzIGFuIGV4YW1wbGUsIHRoZSB1Q0ROIG1pZ2h0IHVz ZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5VUkwgYXBwZW5kZWQgdG9rZW5zIGZvciBhdXRoZW50 aWNhdGlvbiB3aGlsZSBkQ0ROIG1pZ2h0IHVzZSBVUkw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+ YXBwZW5kZWQgaGFzaGVzLiAmbmJzcDtUaGUgdXNlciBkb2Vzbid0IHdhbnQgdG8ga25vdyBhYm91 dCB0aGUgZGlzdGluY3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+bWV0aG9kcywgYnV0IHRyYW5z cGFyZW5jeSBpcyBvbmx5IGFmZm9yZGVkIGlmIHRoZSBtZXRob2RzIGFyZTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3Nl cmlmJnF1b3Q7Ij5pbnRlcm9wZXJhYmxlIGNsZWFybHkgZGVmaW5lZCB3aGVuIHRoZSBkZWxlZ2F0 aW9uIGZvciBjb250ZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPmRlbGl2ZXJ5IGlzIGV4ZWN1 dGVkLiAmbmJzcDtDbGVhcmx5LCB0aGUgY2hvaWNlIG9mIGF1dGhlbnRpY2F0aW9uIG1ldGhvZCBp cyBkZXRlcm1pbmVkIGJ5IHRoZSByZXNwZWN0aXZlIENETidzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+U2NvdHQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPkNE TmkgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxhIGhyZWY9Im1haWx0bzpD RE5pQGlldGYub3JnIj5DRE5pQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaTwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkNETmkgbWFpbGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij48YSBocmVmPSJtYWls dG86Q0ROaUBpZXRmLm9yZyI+Q0ROaUBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jZG5pPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90OyI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpDRE5p IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDRE5pQGlldGYub3JnIj5DRE5pQGll dGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pPC9h Pjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KQ0ROaSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q0ROaUBpZXRmLm9yZyI+ Q0ROaUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NkbmkiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2RuaTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNETmkgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNETmlAaWV0Zi5vcmciPkNETmlAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nkbmk8L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9Ik5MIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPlRoaXMgZS1tYWlsIGFuZCBpdHMgY29udGVudHMgYXJlIHN1YmplY3Qg dG8gdGhlIERJU0NMQUlNRVIgYXQgaHR0cDovL3d3dy50bm8ubmwvZW1haWxkaXNjbGFpbWVyPC9z cGFuPjxzcGFuIGxhbmc9Ik5MIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --Boundary_(ID_H8itvd7FyeFtDJBc48s76g)-- From emile.stephan@orange.com Mon Oct 31 03:32:56 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D268D21F8D6A for ; Mon, 31 Oct 2011 03:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.039 X-Spam-Level: X-Spam-Status: No, score=-2.039 tagged_above=-999 required=5 tests=[AWL=-1.211, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hA57TbOwH9Gq for ; Mon, 31 Oct 2011 03:32:55 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 94F5921F8CE8 for ; Mon, 31 Oct 2011 03:32:54 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 5BE65958001; Mon, 31 Oct 2011 11:42:53 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 4C7EC858001; Mon, 31 Oct 2011 11:42:53 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 11:32:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CC97B8.71F88E3F" Date: Mon, 31 Oct 2011 11:32:51 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201FE4E4C@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136D12B4@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Preparing draft-ietf-cdni-problem-statement for WGLast Call Thread-Index: AQHMlVPXUQFpXawaFU6bJJUZa6nEgpWR9/iggARM7lA= References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> <1CA25301D2219F40B3AA37201F0EACD1136D12B4@PACDCEXMB05.cable.comcast.com> From: To: , , X-OriginalArrivalTime: 31 Oct 2011 10:32:53.0771 (UTC) FILETIME=[72809DB0:01CC97B8] Cc: cdni@ietf.org Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WGLast Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 10:32:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC97B8.71F88E3F Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CC97B8.71F88E3F" ------_=_NextPart_002_01CC97B8.71F88E3F Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KIA0KDQpGb3IgQ0RNSSBJIHVzZSB0aGUgcmVmIGh0dHA6Ly9zbmlhLm9yZy9zaXRlcy9k ZWZhdWx0L2ZpbGVzL0NETUlfU05JQV9BcmNoaXRlY3R1cmVfdjEuMC5wZGYgKGV2ZW4gaWYgdGhl IGxpbmsgaXMgYnJva2VuIGluIGh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1zdGVwaGFu LWNkbmktdXNlY2FzZXMtbWV0YWRhdGEtMDAudHh0ICkNCg0KIA0KDQpSZWdhcmRzDQoNCkVtaWxl DQoNCiANCg0KRGUgOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjZG5pLWJvdW5jZXNA aWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgV291bmR5LCBSaWNoYXJkDQpFbnZvecOpIDogdmVuZHJl ZGkgMjggb2N0b2JyZSAyMDExIDE4OjUwDQrDgCA6IEZyYW5jb2lzIExlIEZhdWNoZXVyOyBCZW4g Tml2ZW4tSmVua2lucw0KQ2MgOiBjZG5pQGlldGYub3JnDQpPYmpldCA6IFJlOiBbQ0ROaV0gUHJl cGFyaW5nIGRyYWZ0LWlldGYtY2RuaS1wcm9ibGVtLXN0YXRlbWVudCBmb3IgV0dMYXN0IENhbGwN Cg0KIA0KDQo+ICAgbyAgQ2FibGVMYWJzLCBTTklBIGFuZCBJVFUgaGF2ZSBkZWZpbmVkIChvciBh cmUgd29ya2luZyBvbikgZGVmaW5pdGlvbnMgZm9yIGNvbnRlbnQgcmVsYXRlZCBtZXRhZGF0YSBk ZWZpbml0aW9ucyBhbmQgc3BlY2lmaWNhdGlvbiBmb3IgaXRzIGRpc3RyaWJ1dGlvbi4NCg0KIA0K DQpBcmUgd2UgcmVmZXJyaW5nIHRvIHRoZXNlIENhYmxlTGFicyBzcGVjaWZpY2F0aW9ucz8NCg0K IA0KDQpodHRwOi8vd3d3LmNhYmxlbGFicy5jb20vc3BlY2lmaWNhdGlvbnMvTUQtU1AtQ09OVEVO VHYzLjAtSTAxLTEwMDgxMi5wZGYNCg0KaHR0cDovL3d3dy5jYWJsZWxhYnMuY29tL3Byb2plY3Rz L21ldGFkYXRhL3NwZWNpZmljYXRpb25zL3NwZWNpZmljYXRpb25zMzAuaHRtbA0KDQogDQoNCkRv IHdlIGhhdmUgcmVmZXJlbmNlcyBmb3IgdGhlIFNOSUEgYW5kIElUVSBzcGVjcyBhcyB3ZWxsPw0K DQogDQoNCi0tIFJpY2gNCg0KIA0KDQpGcm9tOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBGcmFuY29pcyBMZSBGYXVjaGV1 cg0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDI4LCAyMDExIDU6MjggQU0NClRvOiBCZW4gTml2ZW4t SmVua2lucw0KQ2M6IGNkbmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQ0ROaV0gUHJlcGFyaW5n IGRyYWZ0LWlldGYtY2RuaS1wcm9ibGVtLXN0YXRlbWVudCBmb3IgV0cgTGFzdCBDYWxsDQoNCiAN Cg0KSEkgQmVuLA0KDQogDQoNCkNvbW1lbnRzIGJlbG93Og0KDQogDQoNCk9uIDE3IE9jdCAyMDEx LCBhdCAxMzowNywgQmVuIE5pdmVuLUplbmtpbnMgd3JvdGU6DQoNCg0KDQoNCg0KDQpDb2xsZWFn dWVzLA0KDQpBdCB0aGUgbGFzdCBJRVRGIEkgc2FpZCBJIHdvdWxkIHRyeSB0byBwcmVwYXJlIGEg dmVyc2lvbiBvZiB0aGUgQ0ROSSBwcm9ibGVtIFN0YXRlbWVudCAoZHJhZnQtaWV0Zi1jZG5pLXBy b2JsZW0tc3RhdGVtZW50KSB0aGF0IGlzIHJlYWR5IGZvciBXRyBMYXN0IENhbGwgYmVmb3JlIElF VEY4MiBpbiBUYWlwZWkuDQoNCkFzIHBhcnQgb2YgdGhhdCBJIGhhdmUgcmV2aWV3ZWQgdGhlIGNv bXBsZXRlIGRyYWZ0IGFuZCBtYWRlIHNvbWUgbWlub3IgZWRpdG9yaWFsIGNsZWFuLXVwcyB0byBt eSB3b3JraW5nIGNvcHkuIEhvd2V2ZXIsIHRoZXJlIHdlcmUgYSBudW1iZXIgb2Ygb3RoZXIgYXJl YXMgd2hlcmUgSSB0aGluayBjaGFuZ2VzIG5lZWQgdG8gYmUgbWFkZSB0byB0aGUgZG9jdW1lbnQg dGhhdCBJIHRoaW5rIHdhcnJhbnQgd2lkZXIgV0cgcmV2aWV3L2NvbnNlbnN1cyBhbmQgSSBoYXZl IGxpc3RlZCB0aGVtIGJlbG93IGFsb25nIHdpdGggdGhlIGNoYW5nZXMgSSBhbSBwcm9wb3Npbmcu DQoNCkNvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSB5b3VyIGZlZWRiYWNrIG9uIHRoZSBhcmVhcy9w cm9wb3NlZCB0ZXh0IEkgaGF2ZSBoaWdobGlnaHRlZCBiZWxvdyBhcyB3ZWxsIGFzIGFueSBvdGhl ciBhcmVhcyBvZiB0aGUgZG9jdW1lbnQgdGhhdCB5b3UgdGhpbmsgcmVxdWlyZSBhZGRpdGlvbmFs IHdvcmsvY2xlYW51cCBiZWZvcmUgeW91IGNvbnNpZGVyIHRoZSBkb2N1bWVudCBpcyByZWFkeSBm b3IgYSBXRyBMYXN0IENhbGwuDQoNCjEpIFNlY3Rpb24gMjogVXBkYXRlIHRoZSBsYXN0IHBhcmFn cmFwaCB0byByZWZlcmVuY2UgdGhlIFdHIGRyYWZ0IGZvciBDRE5JIHVzZSBjYXNlcyBhbmQgcmVt b3ZlIHJlZmVyZW5jZSB0byBkcmFmdC13YXRzb24tY2RuaS11c2UtY2FzZXMsIGkuZS4NCg0KT0xE Og0KICBVc2UgY2FzZXMgZm9yIENETiBJbnRlcmNvbm5lY3Rpb24gYXJlIGZ1cnRoZXIgZGlzY3Vz c2VkIGluDQogIFtJLUQuYmVydHJhbmQtY2RuaS11c2UtY2FzZXNdICh3aGljaCBjb250YWlucyBh IG1lcmdlZCBzZXQgb2YgdXNlDQogIGNhc2VzIHByZXZpb3VzbHkgcHJlc2VudGVkIGluIFtJLUQu d2F0c29uLWNkbmktdXNlLWNhc2VzXSBhbmQNCiAgW0ktRC5iZXJ0cmFuZC1jZG5pLXVzZS1jYXNl cy0wMF0pLg0KTkVXOg0KICBVc2UgY2FzZXMgZm9yIENETiBJbnRlcmNvbm5lY3Rpb24gYXJlIGZ1 cnRoZXIgZGlzY3Vzc2VkIGluDQogIFtJLUQuaWV0Zi1jZG5pLXVzZS1jYXNlc10uDQoNCiANCg0K QWdyZWVkLg0KDQoNCg0KDQoNCg0KDQoNCjIpIFNlY3Rpb24gNCBjb250YWlucyBhbiBpbnRyb2R1 Y3Rpb24gYW5kIDIgc3ViLXNlY3Rpb25zICg0LjEgJiA0LjIpIHRoYXQgYXJlIGVhY2gganVzdCBh IGNvdXBsZSBvZiBzZW50ZW5jZXMsIHNvIEkgcHJvcG9zZSBtZXJnaW5nIHRoZW0gaW50byBhIHNp bmdsZSBzZWN0aW9uIGFuZCBjaGFuZ2luZyB0aGUgZmlyc3QgdHdvIHNlbnRlbmNlcyBvZiBzZWN0 aW9uIDQgYXBwcm9wcmlhdGVseSwgaS5lLg0KDQpPTEQ6DQogIFRoaXMgc2VjdGlvbiBleHBhbmRz IG9uIGhvdyBDRE5JIGludGVyZmFjZXMgY2FuIHJldXNlIGFuZCBsZXZlcmFnZQ0KICBleGlzdGlu ZyBwcm90b2NvbHMuICBGaXJzdCB0aGUgInJldXNlIGluc3RlYWQgb2YgcmVpbnZlbnQiIGRlc2ln bg0KICBwcmluY2lwbGUgaXMgcmVzdGF0ZWQsIHRoZW4gZWFjaCBpbmV0cmZhY2UgaXMgZGlzY3Vz c2VkIGluZGl2aWR1YWxseQ0KICB3aXRoIGV4YW1wbGUgY2FuZGlkYXRlIHByb3RvY29scyB0aGF0 IGNhbiBiZSBjb25zaWRlcmVkIGZvciByZXVzZSBvcg0KICBsZXZlcmFnZS4gDQpORVc6DQogIFRo aXMgc2VjdGlvbiBleHBhbmRzIG9uIGhvdyBDRE5JIGludGVyZmFjZXMgY2FuIHJldXNlIGFuZCBs ZXZlcmFnZQ0KICBleGlzdGluZyBwcm90b2NvbHMgYmVmb3JlIGRlc2NyaWJpbmcgZWFjaCBDRE5J IGludGVyZmFjZSBpbmRpdmlkdWFsbHkNCiAgYW5kIGhpZ2hsaWdodGluZyBleGFtcGxlIGNhbmRp ZGF0ZSBwcm90b2NvbHMgdGhhdCBjb3VsZCBjb25zaWRlcmVkIGZvcg0KICByZXVzZSBvciBsZXZl cmFnaW5nIHRvIGltcGxlbWVudCB0aGUgQ0ROSSBpbnRlcmZhY2VzLiAgDQoNCiANCg0KRmluZSBi eSBtZS4NCg0KDQoNCg0KDQoNCg0KDQozKSBTZWN0aW9uIDUgaXMgY3VycmVudGx5IHRpdGxlICJH YXAgQW5hbHlzaXMgb2YgcmVsZXZhbnQgU3RhbmRhcmRpc2F0aW9uIGFuZCBSZXNlYXJjaCBBY3Rp dml0aWVzIiBidXQgZm9sbG93aW5nIHRoZSBhZ3JlZW1lbnQgYXQgdGhlIGxhc3QgSUVURiB0byBt b3ZlIHRoZSBnZW5lcmljIGRlc2NyaXB0aW9ucyBvZiBvdGhlciBhY3Rpdml0aWVzIGludG8gYW4g YXBwZW5kaXggU2VjdGlvbiA1IG5vIGxvbmdlciByZWZlcmVuY2VzIGFueSByZXNlYXJjaCBhY3Rp dml0aWVzIHNvIEkgcHJvcG9zZSBjaGFuZ2luZyB0aGUgdGl0bGUgdG8iIEdhcCBBbmFseXNpcyBv ZiByZWxldmFudCBTdGFuZGFyZGlzYXRpb24gYWN0aXZpdGllcyIuDQoNCiANCg0KQWdyZWVkLg0K DQoNCg0KDQoNCg0KDQo0KSBBZnRlciB0aGUgZ2VuZXJhbCBpbnRyb2R1Y3Rpb24gaW4gU2VjdGlv biA1IHRoZXJlIGFyZSBvbmx5IHNlY3Rpb25zIHRoYXQgb3V0bGluZSBvdGhlciByZXNlYXJjaCBh Y3Rpdml0aWVzDQoNCiANCg0KSSB0aGluayB5b3UgbWVhbiAic3RhbmRhcmRpemF0aW9uIGFjdGl2 aXRpZXMiDQoNCg0KDQoNCg0KDQpmb3IgQ29udGVudCBBY3F1aXNpdGlvbiAoc2VjdGlvbiA1LjEp IGFuZCBDRE5JIE1ldGFkYXRhIChTZWN0aW9uIDUuMikgYnV0IHRoZXJlIGFyZSBub3Qgc2VjdGlv bnMgZm9yIHRoZSBvdGhlciBDRE5JIGludGVyZmFjZXMgKENvbnRyb2wsIExvZ2dpbmcsIFJlcXVl c3QgUm91dGluZykuDQoNClRoZSByZWFzb24gZm9yIHRoZSBsYWNrIG9mIHRleHQgaXMgSU1PIGJl Y2F1c2UgdGhlcmUgaXMgbm8gY3VycmVudCBvciBwYXN0IHN0YW5kYXJkaXNhdGlvbiBhY3Rpdml0 eSBhZGRyZXNzaW5nIHRob3NlIGFyZWFzIGJ1dCB0aGUgZG9jdW1lbnQgY3VycmVudGx5IGRvZXMg bm90IG1lbnRpb24gdGhhdCBhbmQgdGhlcmVmb3JlIGdpdmVzIHRoZSBpbXByZXNzaW9uIG9mIGJl aW5nIGluY29tcGxldGUuDQoNCkkgdGhlcmVmb3JlIHByb3Bvc2UgbWFraW5nIHRoZSBmb2xsb3dp bmcgY2hhbmdlIHRvIHRoZSBsYXN0IHNlbnRlbmNlIGluIFNlY3Rpb24gNToNCg0KT0xEOg0KICBU aGUgZm9sbG93aW5nIHNlY3Rpb25zIHdpbGwgc3VtbWFyaXplIHRoZSBleGlzdGluZyB3b3JrIG9m IHRoZQ0KICBzdGFuZGFyZCBib2RpZXMgYWJvdmUgYWdhaW5zdCB0aGUgQ0ROSSBwcm9ibGVtIHNw YWNlLg0KTkVXOg0KICBUaGUgZm9sbG93aW5nIHNlY3Rpb25zIHdpbGwgc3VtbWFyaXplIHRoZSBl eGlzdGluZyB3b3JrIG9mIHRoZQ0KICBzdGFuZGFyZCBib2RpZXMgYWJvdmUgYWdhaW5zdCB0aGUg Q0ROSSBwcm9ibGVtIHNwYWNlLiBTZWN0aW9uIDUuMQ0KICBzdW1tYXJpc2VzIGV4aXN0aW5nIGlu dGVyZmFjZXMgdGhhdCBjb3VsZCBiZSBsZXZlcmFnZWQgZm9yIGNvbnRlbnQNCiAgYWNxdWlzaXRp b24gYmV0d2VlbiBDRE5zIGFuZCBTZWN0aW9uIDUuMiBzdW1tYXJpc2VzIGV4aXN0aW5nIG1ldGFk YXRhIA0KICBzcGVjaWZpY2F0aW9ucyB0aGF0IG1heSBiZSBhcHBsaWNhYmxlIHRvIENETkkuIFRv IGRhdGUgdGhlcmUgaXMgbm8NCiAgZXhpc3Rpbmcgc3RhbmRhcmRpc2F0aW9uIGFjdGl2aXRpZXMg aW4gdGhlIGFyZWFzIG9mIHRoZSByZW1haW5pbmcNCiAgQ0ROSSBpbnRlcmZhY2VzIChDRE5JIFJl cXVlc3QgUm91dGluZywgQ0ROSSBDb250cm9sIGFuZCBDRE5JIExvZ2dpbmcpLg0KDQogDQoNCkZp bmUuDQoNCiANCg0KSnVzdCBhIGNvdXBsZSBlZGl0b3JpYWwgc3VnZ2VzdGlvbnM6DQoNCiANCg0K cy9vZiB0aGUgc3RhbmRhcmQgYm9kaWVzIGFib3ZlL29mIHRoZSBzdGFuZGFyZCBib2RpZXMgbGlz dGVkIGVhcmxpZXIvDQoNCiANCg0Kcy90aGVyZSBpcyBubyBleGlzdGluZyBzdGFuZGFyZGlzYXRp b24gYWN0aXZpdGllcy93ZSBhcmUgbm90IGF3YXJlIG9mIGFueSBzdGFuZGFyZGlzYXRpb24gYWN0 aXZpdGllcy8NCg0KIA0KDQoNCg0KDQoNCg0KDQo1KSBJIGFsc28gcHJvcG9zZSB1c2luZyB0aGUg Zm9sbG93aW5nIHRleHQgZm9yIHRoZSB0aGlyZCBidWxsZXQgaW4gU2VjdGlvbiA1IHVubGVzcyBz b21lb25lIGNhbiBzdWdnZXN0IG1vcmUgYXBwcm9wcmlhdGUgdGV4dCB0byBzdW1tYXJpc2UgaW4g YSBzZW50ZW5jZSBvciB0d28gYW55IENETiBtZXRhZGF0YSByZWxhdGVkIHdvcmsgaW4gb3RoZXIg c3RhbmRhcmRzIGJvZGllcy4NCg0KT0xEOg0KICBvICA8VE9ETzogQWRkIGEgc2VudGVuY2Ugb24g SVRVPg0KTkVXOg0KICBvICBDYWJsZUxhYnMsIFNOSUEgYW5kIElUVSBoYXZlIGRlZmluZWQgKG9y IGFyZSB3b3JraW5nIG9uKQ0KICAgICBkZWZpbml0aW9ucyBmb3IgY29udGVudCByZWxhdGVkIG1l dGFkYXRhIGRlZmluaXRpb25zIGFuZCBzcGVjaWZpY2F0aW9uDQogICAgIGZvciBpdHMgZGlzdHJp YnV0aW9uLiBIb3dldmVyLCB0aGV5IGRvIG5vdCBpbmNsdWRlIG1ldGFkYXRhIHNwZWNpZmljDQog ICAgIHRvIHRoZSBkaXN0cmlidXRpb24gb2YgY29udGVudCB3aXRoaW4gYSBDRE4gb3IgYmV0d2Vl biBpbnRlcmNvbm5lY3RlZA0KICAgICBDRE5zLg0KDQogDQoNClRoYXQgd29ya3MgZm9yIG1lLiBJ dCB3b3VsZCBiZSBnb29kIHRvIGdldCB0aGF0IHZhbGlkYXRlZCBieSBzb21lb25lIGF3YXJlIG9m IHRoZSB3b3JrIG9mIHRoZXNlIGJvZGllcy4NCg0KIA0KDQoNCg0KDQoNCg0KDQo2KSBTZWN0aW9u IDEwLjEgbGlzdHMgYSBudW1iZXIgb2YgIm5vcm1hdGl2ZSByZWZlcmVuY2VzIiwgaWYgd2UgYWRv cHQgdGhlIHByb3Bvc2VkIGNoYW5nZXMgYWJvdmUgaXQgd2lsbCBlbmQgdXAgY29udGFpbmluZyAi bm9ybWF0aXZlIiByZWZlcmVuY2VzIHRvOg0KICAtIGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMN CiAgLSBkcmFmdC1iZXJ0cmFuZC1jZG5pLWV4cGVyaWVtZW50cw0KICAtIGRyYWZ0LWplbmtpbnMt Y2RuaS1uYW1lcw0KICAtIFJGQzIxMTkNCg0KQWZ0ZXIgcmVhZGluZyB0aHJvdWdoIHRoZSB0ZXh0 IG9mIHRoZSBQcm9ibGVtIFN0YXRlbWVudCBhZ2FpbiwgSSBhbSBub3QgY29udmluY2VkIHRoYXQg dGhlIFByb2JsZW0gU3RhdGVtZW50IHJlZmVyZW5jZXMgYW55IG9mIHRob3NlIGRvY3VtZW50cyBu b3JtYXRpdmVseSBhcyB0aGUgMyBDRE5JIHJlbGF0ZWQgZHJhZnRzIGFyZSByZWZlcmVuY2VkIGlu IGEgY29udGV4dCB3aGVyZSB0aGV5IGFyZSBmb3IgZnVydGhlciBpbmZvcm1hdGlvbiBhbmQgdGhl IFByb2JsZW0gU3RhdGVtZW50IGRvZXMgbm90IG1ha2UgdXNlIG9mIGFueSBvZiB0aGUgY2FwaXRh bGlzZWQgdGVybXMgZGVmaW5lZCBpbiBSRkMyMTE5Lg0KDQpUaGVyZWZvcmUsIHVubGVzcyBhbnlv bmUgb2JqZWN0cyBJIHdpbGwgbW92ZSB0aGUgcmVmZXJlbmNlcyBmb3IgdGhlIHRocmVlIENETkkg cmVsYXRlZCBkcmFmdHMgdG8gdGhlICJJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzIiBzZWN0aW9uIGFu ZCByZW1vdmUgdGhlIHJlZmVyZW5jZSBmb3IgUkZDMjExOS4NCg0KIA0KDQpJIGFncmVlIHdlIGRv bid0IHdhbnQgbm9ybWF0aXZlIHJlZiB0byB0aGUgb3RoZXIgY2RuaSBkcmFmdHMgYXMgdGhlIHBy b2JsZW0gc3RhdGVtZW50IGlzIHNldHRpbmcgdGhlIHN0YWdlIGZvciB0aGUgb3RoZXIgZG9jdW1l bnRzLg0KDQogDQoNClRoYW5rcw0KDQogDQoNCkZyYW5jb2lzDQoNCg0KDQoNCg0KDQoNCg0KVGhh bmtzDQpCZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KIA0KDQogDQoNCgkNCg0KIA0KDQoNCkZyYW5jb2lz IExlIEZhdWNoZXVyDQpEaXN0aW5ndWlzaGVkIEVuZ2luZWVyDQpDb3Jwb3JhdGUgRGV2ZWxvcG1l bnQNCmZsZWZhdWNoQGNpc2NvLmNvbSA8bWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbT4gDQpQaG9u ZTogKzMzIDQ5IDcyMyAyNjE5DQpNb2JpbGU6ICszMyA2IDE5IDk4IDUwIDkwDQoNCg0KDQoNCkNp c2NvIFN5c3RlbXMgRnJhbmNlDQpHcmVlbnNpZGUNCjQwMCBBdmUgZGUgUm91bWFuaWxsZQ0KMDY0 MTAgU29waGlhIEFudGlwb2xpcw0KRnJhbmNlDQpDaXNjby5jb20gPGh0dHA6Ly93d3cuY2lzY28u Y29tPiANCg0KIA0KDQoNCiANCg0KCQ0KIFRoaW5rIGJlZm9yZSB5b3UgcHJpbnQuDQoNCg0KVGhp cyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByaXZpbGVnZWQgbWF0ZXJpYWwg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LiBBbnkgcmV2aWV3LCB1 c2UsIGRpc3RyaWJ1dGlvbiBvciBkaXNjbG9zdXJlIGJ5IG90aGVycyBpcyBzdHJpY3RseSBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IChvciBhdXRob3Jp emVkIHRvIHJlY2VpdmUgZm9yIHRoZSByZWNpcGllbnQpLCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZWxldGUgYWxsIGNvcGllcyBvZiB0aGlzIG1lc3NhZ2Uu DQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9uc2FiaWl0w6kgbGlt aXTDqWUsIFJ1ZSBDYW1pbGxlIERlc21vdWxpbnMg4oCTIEltbSBBdGxhbnRpcyBaYWMgRm9ydW0g U2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzIE1vdWxpbmVhdXgsIEF1IGNhcGl0YWwgZGUgOTEu NDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJlLCBEaXJlY3RldXIgZGUgbGEgcHVibGlj YXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUuDQoNCkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5m b3JtYXRpb24gZ28gdG86DQpodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVz aW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwNCg0KIA0KDQo= ------_=_NextPart_002_01CC97B8.71F88E3F Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PCEtLVtpZiAhbXNvXT48c3R5 bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJs KCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNo YXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxz dHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAg MyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9z ZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFo b21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGltZXM7DQoJcGFub3NlLTE6MiAyIDYgMyA1IDQgNSAy IDMgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJp ZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBj bTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFu O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBw dCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1GUiBsaW5rPWJsdWUgdmxpbms9cHVycGxlIHN0 eWxlPSd3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24x PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Gb3IgQ0RNSSBJIHVzZSB0 aGUgcmVmIDxhIGhyZWY9Imh0dHA6Ly9zbmlhLm9yZy9zaXRlcy9kZWZhdWx0L2ZpbGVzL0NETUlf U05JQV9BcmNoaXRlY3R1cmVfdjEuMC5wZGYiPmh0dHA6Ly9zbmlhLm9yZy9zaXRlcy9kZWZhdWx0 L2ZpbGVzL0NETUlfU05JQV9BcmNoaXRlY3R1cmVfdjEuMC5wZGY8L2E+IChldmVuIGlmIHRoZSBs aW5rIGlzIGJyb2tlbiBpbiA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt c3RlcGhhbi1jZG5pLXVzZWNhc2VzLW1ldGFkYXRhLTAwLnR4dCI+aHR0cDovL3Rvb2xzLmlldGYu b3JnL2lkL2RyYWZ0LXN0ZXBoYW4tY2RuaS11c2VjYXNlcy1tZXRhZGF0YS0wMC50eHQ8L2E+ICk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SZWdhcmRzPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+RW1pbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48 cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5EZSZuYnNwOzo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ IGNkbmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZ10gPGI+ RGUgbGEgcGFydCBkZTwvYj4gV291bmR5LCBSaWNoYXJkPGJyPjxiPkVudm95w6kmbmJzcDs6PC9i PiB2ZW5kcmVkaSAyOCBvY3RvYnJlIDIwMTEgMTg6NTA8YnI+PGI+w4AmbmJzcDs6PC9iPiBGcmFu Y29pcyBMZSBGYXVjaGV1cjsgQmVuIE5pdmVuLUplbmtpbnM8YnI+PGI+Q2MmbmJzcDs6PC9iPiBj ZG5pQGlldGYub3JnPGJyPjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IFtDRE5pXSBQcmVwYXJpbmcg ZHJhZnQtaWV0Zi1jZG5pLXByb2JsZW0tc3RhdGVtZW50IGZvciBXR0xhc3QgQ2FsbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4mZ3Q7PC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+ICZuYnNwOyZuYnNwO28gJm5ic3A7Q2Fi bGVMYWJzLCBTTklBIGFuZCBJVFUgaGF2ZSBkZWZpbmVkIChvciBhcmUgd29ya2luZyBvbikgZGVm aW5pdGlvbnMgZm9yIGNvbnRlbnQgcmVsYXRlZCBtZXRhZGF0YSBkZWZpbml0aW9ucyBhbmQgc3Bl Y2lmaWNhdGlvbiBmb3IgaXRzIGRpc3RyaWJ1dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5BcmUgd2UgcmVmZXJyaW5n IHRvIHRoZXNlIENhYmxlTGFicyBzcGVjaWZpY2F0aW9ucz88L3NwYW4+PHNwYW4gbGFuZz1FTi1V Uz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8vd3d3LmNhYmxlbGFicy5jb20vc3BlY2lmaWNhdGlv bnMvTUQtU1AtQ09OVEVOVHYzLjAtSTAxLTEwMDgxMi5wZGYiPmh0dHA6Ly93d3cuY2FibGVsYWJz LmNvbS9zcGVjaWZpY2F0aW9ucy9NRC1TUC1DT05URU5UdjMuMC1JMDEtMTAwODEyLnBkZjwvYT48 L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48YSBocmVmPSJodHRwOi8v d3d3LmNhYmxlbGFicy5jb20vcHJvamVjdHMvbWV0YWRhdGEvc3BlY2lmaWNhdGlvbnMvc3BlY2lm aWNhdGlvbnMzMC5odG1sIj5odHRwOi8vd3d3LmNhYmxlbGFicy5jb20vcHJvamVjdHMvbWV0YWRh dGEvc3BlY2lmaWNhdGlvbnMvc3BlY2lmaWNhdGlvbnMzMC5odG1sPC9hPjwvc3Bhbj48c3BhbiBs YW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVT PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V UyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkRvIHdlIGhhdmUgcmVmZXJlbmNlcyBmb3IgdGhlIFNOSUEgYW5k IElUVSBzcGVjcyBhcyB3ZWxsPzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0tIFJp Y2g8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+RnJhbmNvaXMg TGUgRmF1Y2hldXI8YnI+PGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAyOCwgMjAxMSA1OjI4 IEFNPGJyPjxiPlRvOjwvYj4gQmVuIE5pdmVuLUplbmtpbnM8YnI+PGI+Q2M6PC9iPiBjZG5pQGll dGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW0NETmldIFByZXBhcmluZyBkcmFmdC1pZXRm LWNkbmktcHJvYmxlbS1zdGF0ZW1lbnQgZm9yIFdHIExhc3QgQ2FsbDwvc3Bhbj48c3BhbiBsYW5n PUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+SEkgQmVuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PkNvbW1lbnRzIGJlbG93OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+T24gMTcgT2N0IDIw MTEsIGF0IDEzOjA3LCBCZW4gTml2ZW4tSmVua2lucyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PGJyPjxicj48YnI+ PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVM+Q29sbGVhZ3Vlcyw8YnI+PGJyPkF0IHRoZSBsYXN0IElFVEYgSSBzYWlkIEkgd291bGQg dHJ5IHRvIHByZXBhcmUgYSB2ZXJzaW9uIG9mIHRoZSBDRE5JIHByb2JsZW0gU3RhdGVtZW50IChk cmFmdC1pZXRmLWNkbmktcHJvYmxlbS1zdGF0ZW1lbnQpIHRoYXQgaXMgcmVhZHkgZm9yIFdHIExh c3QgQ2FsbCBiZWZvcmUgSUVURjgyIGluIFRhaXBlaS48YnI+PGJyPkFzIHBhcnQgb2YgdGhhdCBJ IGhhdmUgcmV2aWV3ZWQgdGhlIGNvbXBsZXRlIGRyYWZ0IGFuZCBtYWRlIHNvbWUgbWlub3IgZWRp dG9yaWFsIGNsZWFuLXVwcyB0byBteSB3b3JraW5nIGNvcHkuIEhvd2V2ZXIsIHRoZXJlIHdlcmUg YSBudW1iZXIgb2Ygb3RoZXIgYXJlYXMgd2hlcmUgSSB0aGluayBjaGFuZ2VzIG5lZWQgdG8gYmUg bWFkZSB0byB0aGUgZG9jdW1lbnQgdGhhdCBJIHRoaW5rIHdhcnJhbnQgd2lkZXIgV0cgcmV2aWV3 L2NvbnNlbnN1cyBhbmQgSSBoYXZlIGxpc3RlZCB0aGVtIGJlbG93IGFsb25nIHdpdGggdGhlIGNo YW5nZXMgSSBhbSBwcm9wb3NpbmcuPGJyPjxicj5Db3VsZCB5b3UgcGxlYXNlIHByb3ZpZGUgeW91 ciBmZWVkYmFjayBvbiB0aGUgYXJlYXMvcHJvcG9zZWQgdGV4dCBJIGhhdmUgaGlnaGxpZ2h0ZWQg YmVsb3cgYXMgd2VsbCBhcyBhbnkgb3RoZXIgYXJlYXMgb2YgdGhlIGRvY3VtZW50IHRoYXQgeW91 IHRoaW5rIHJlcXVpcmUgYWRkaXRpb25hbCB3b3JrL2NsZWFudXAgYmVmb3JlIHlvdSBjb25zaWRl ciB0aGUgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIGEgV0cgTGFzdCBDYWxsLjxicj48YnI+MSkgU2Vj dGlvbiAyOiBVcGRhdGUgdGhlIGxhc3QgcGFyYWdyYXBoIHRvIHJlZmVyZW5jZSB0aGUgV0cgZHJh ZnQgZm9yIENETkkgdXNlIGNhc2VzIGFuZCByZW1vdmUgcmVmZXJlbmNlIHRvIGRyYWZ0LXdhdHNv bi1jZG5pLXVzZS1jYXNlcywgaS5lLjxicj48YnI+T0xEOjxicj4mbmJzcDsmbmJzcDtVc2UgY2Fz ZXMgZm9yIENETiBJbnRlcmNvbm5lY3Rpb24gYXJlIGZ1cnRoZXIgZGlzY3Vzc2VkIGluPGJyPiZu YnNwOyZuYnNwO1tJLUQuYmVydHJhbmQtY2RuaS11c2UtY2FzZXNdICh3aGljaCBjb250YWlucyBh IG1lcmdlZCBzZXQgb2YgdXNlPGJyPiZuYnNwOyZuYnNwO2Nhc2VzIHByZXZpb3VzbHkgcHJlc2Vu dGVkIGluIFtJLUQud2F0c29uLWNkbmktdXNlLWNhc2VzXSBhbmQ8YnI+Jm5ic3A7Jm5ic3A7W0kt RC5iZXJ0cmFuZC1jZG5pLXVzZS1jYXNlcy0wMF0pLjxicj5ORVc6PGJyPiZuYnNwOyZuYnNwO1Vz ZSBjYXNlcyBmb3IgQ0ROIEludGVyY29ubmVjdGlvbiBhcmUgZnVydGhlciBkaXNjdXNzZWQgaW48 YnI+Jm5ic3A7Jm5ic3A7W0ktRC5pZXRmLWNkbmktdXNlLWNhc2VzXS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUz5BZ3JlZWQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxicj48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxicj48YnI+Mikg U2VjdGlvbiA0IGNvbnRhaW5zIGFuIGludHJvZHVjdGlvbiBhbmQgMiBzdWItc2VjdGlvbnMgKDQu MSAmYW1wOyA0LjIpIHRoYXQgYXJlIGVhY2gganVzdCBhIGNvdXBsZSBvZiBzZW50ZW5jZXMsIHNv IEkgcHJvcG9zZSBtZXJnaW5nIHRoZW0gaW50byBhIHNpbmdsZSBzZWN0aW9uIGFuZCBjaGFuZ2lu ZyB0aGUgZmlyc3QgdHdvIHNlbnRlbmNlcyBvZiBzZWN0aW9uIDQgYXBwcm9wcmlhdGVseSwgaS5l Ljxicj48YnI+T0xEOjxicj4mbmJzcDsmbmJzcDtUaGlzIHNlY3Rpb24gZXhwYW5kcyBvbiBob3cg Q0ROSSBpbnRlcmZhY2VzIGNhbiByZXVzZSBhbmQgbGV2ZXJhZ2U8YnI+Jm5ic3A7Jm5ic3A7ZXhp c3RpbmcgcHJvdG9jb2xzLiAmbmJzcDtGaXJzdCB0aGUgJnF1b3Q7cmV1c2UgaW5zdGVhZCBvZiBy ZWludmVudCZxdW90OyBkZXNpZ248YnI+Jm5ic3A7Jm5ic3A7cHJpbmNpcGxlIGlzIHJlc3RhdGVk LCB0aGVuIGVhY2ggaW5ldHJmYWNlIGlzIGRpc2N1c3NlZCBpbmRpdmlkdWFsbHk8YnI+Jm5ic3A7 Jm5ic3A7d2l0aCBleGFtcGxlIGNhbmRpZGF0ZSBwcm90b2NvbHMgdGhhdCBjYW4gYmUgY29uc2lk ZXJlZCBmb3IgcmV1c2Ugb3I8YnI+Jm5ic3A7Jm5ic3A7bGV2ZXJhZ2UuIDxicj5ORVc6PGJyPiZu YnNwOyZuYnNwO1RoaXMgc2VjdGlvbiBleHBhbmRzIG9uIGhvdyBDRE5JIGludGVyZmFjZXMgY2Fu IHJldXNlIGFuZCBsZXZlcmFnZTxicj4mbmJzcDsmbmJzcDtleGlzdGluZyBwcm90b2NvbHMgYmVm b3JlIGRlc2NyaWJpbmcgZWFjaCBDRE5JIGludGVyZmFjZSBpbmRpdmlkdWFsbHk8YnI+Jm5ic3A7 Jm5ic3A7YW5kIGhpZ2hsaWdodGluZyBleGFtcGxlIGNhbmRpZGF0ZSBwcm90b2NvbHMgdGhhdCBj b3VsZCBjb25zaWRlcmVkIGZvcjxicj4mbmJzcDsmbmJzcDtyZXVzZSBvciBsZXZlcmFnaW5nIHRv IGltcGxlbWVudCB0aGUgQ0ROSSBpbnRlcmZhY2VzLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUz5GaW5lIGJ5IG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48YnI+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48YnI+PGJyPjMp IFNlY3Rpb24gNSBpcyBjdXJyZW50bHkgdGl0bGUgJnF1b3Q7R2FwIEFuYWx5c2lzIG9mIHJlbGV2 YW50IFN0YW5kYXJkaXNhdGlvbiBhbmQgUmVzZWFyY2ggQWN0aXZpdGllcyZxdW90OyBidXQgZm9s bG93aW5nIHRoZSBhZ3JlZW1lbnQgYXQgdGhlIGxhc3QgSUVURiB0byBtb3ZlIHRoZSBnZW5lcmlj IGRlc2NyaXB0aW9ucyBvZiBvdGhlciBhY3Rpdml0aWVzIGludG8gYW4gYXBwZW5kaXggU2VjdGlv biA1IG5vIGxvbmdlciByZWZlcmVuY2VzIGFueSByZXNlYXJjaCBhY3Rpdml0aWVzIHNvIEkgcHJv cG9zZSBjaGFuZ2luZyB0aGUgdGl0bGUgdG8mcXVvdDsgR2FwIEFuYWx5c2lzIG9mIHJlbGV2YW50 IFN0YW5kYXJkaXNhdGlvbiBhY3Rpdml0aWVzJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTPkFncmVlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVM+PGJyPjxicj48YnI+PG86cD48L286cD48L3NwYW4+PC9wPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PGJyPjQpIEFmdGVyIHRoZSBn ZW5lcmFsIGludHJvZHVjdGlvbiBpbiBTZWN0aW9uIDUgdGhlcmUgYXJlIG9ubHkgc2VjdGlvbnMg dGhhdCBvdXRsaW5lIG90aGVyIHJlc2VhcmNoIGFjdGl2aXRpZXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUz5JIHRoaW5rIHlvdSBtZWFuICZxdW90O3N0YW5kYXJkaXphdGlvbiBhY3Rpdml0 aWVzJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTPjxicj48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPmZvciBDb250ZW50IEFjcXVpc2l0aW9u IChzZWN0aW9uIDUuMSkgYW5kIENETkkgTWV0YWRhdGEgKFNlY3Rpb24gNS4yKSBidXQgdGhlcmUg YXJlIG5vdCBzZWN0aW9ucyBmb3IgdGhlIG90aGVyIENETkkgaW50ZXJmYWNlcyAoQ29udHJvbCwg TG9nZ2luZywgUmVxdWVzdCBSb3V0aW5nKS48YnI+PGJyPlRoZSByZWFzb24gZm9yIHRoZSBsYWNr IG9mIHRleHQgaXMgSU1PIGJlY2F1c2UgdGhlcmUgaXMgbm8gY3VycmVudCBvciBwYXN0IHN0YW5k YXJkaXNhdGlvbiBhY3Rpdml0eSBhZGRyZXNzaW5nIHRob3NlIGFyZWFzIGJ1dCB0aGUgZG9jdW1l bnQgY3VycmVudGx5IGRvZXMgbm90IG1lbnRpb24gdGhhdCBhbmQgdGhlcmVmb3JlIGdpdmVzIHRo ZSBpbXByZXNzaW9uIG9mIGJlaW5nIGluY29tcGxldGUuPGJyPjxicj5JIHRoZXJlZm9yZSBwcm9w b3NlIG1ha2luZyB0aGUgZm9sbG93aW5nIGNoYW5nZSB0byB0aGUgbGFzdCBzZW50ZW5jZSBpbiBT ZWN0aW9uIDU6PGJyPjxicj5PTEQ6PGJyPiZuYnNwOyZuYnNwO1RoZSBmb2xsb3dpbmcgc2VjdGlv bnMgd2lsbCBzdW1tYXJpemUgdGhlIGV4aXN0aW5nIHdvcmsgb2YgdGhlPGJyPiZuYnNwOyZuYnNw O3N0YW5kYXJkIGJvZGllcyBhYm92ZSBhZ2FpbnN0IHRoZSBDRE5JIHByb2JsZW0gc3BhY2UuPGJy Pk5FVzo8YnI+Jm5ic3A7Jm5ic3A7VGhlIGZvbGxvd2luZyBzZWN0aW9ucyB3aWxsIHN1bW1hcml6 ZSB0aGUgZXhpc3Rpbmcgd29yayBvZiB0aGU8YnI+Jm5ic3A7Jm5ic3A7c3RhbmRhcmQgYm9kaWVz IGFib3ZlIGFnYWluc3QgdGhlIENETkkgcHJvYmxlbSBzcGFjZS4gU2VjdGlvbiA1LjE8YnI+Jm5i c3A7Jm5ic3A7c3VtbWFyaXNlcyBleGlzdGluZyBpbnRlcmZhY2VzIHRoYXQgY291bGQgYmUgbGV2 ZXJhZ2VkIGZvciBjb250ZW50PGJyPiZuYnNwOyZuYnNwO2FjcXVpc2l0aW9uIGJldHdlZW4gQ0RO cyBhbmQgU2VjdGlvbiA1LjIgc3VtbWFyaXNlcyBleGlzdGluZyBtZXRhZGF0YSA8YnI+Jm5ic3A7 Jm5ic3A7c3BlY2lmaWNhdGlvbnMgdGhhdCBtYXkgYmUgYXBwbGljYWJsZSB0byBDRE5JLiBUbyBk YXRlIHRoZXJlIGlzIG5vPGJyPiZuYnNwOyZuYnNwO2V4aXN0aW5nIHN0YW5kYXJkaXNhdGlvbiBh Y3Rpdml0aWVzIGluIHRoZSBhcmVhcyBvZiB0aGUgcmVtYWluaW5nPGJyPiZuYnNwOyZuYnNwO0NE TkkgaW50ZXJmYWNlcyAoQ0ROSSBSZXF1ZXN0IFJvdXRpbmcsIENETkkgQ29udHJvbCBhbmQgQ0RO SSBMb2dnaW5nKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5GaW5lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTPkp1c3QgYSBjb3VwbGUgZWRpdG9yaWFsIHN1Z2dlc3Rpb25zOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPnMvb2YgdGhlJm5ic3A7c3RhbmRhcmQgYm9kaWVz IGFib3ZlL29mIHRoZSZuYnNwO3N0YW5kYXJkIGJvZGllcyBsaXN0ZWQgZWFybGllci88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5zL3RoZXJlIGlzIG5vJm5ic3A7ZXhpc3Rpbmcgc3RhbmRh cmRpc2F0aW9uIGFjdGl2aXRpZXMvd2UgYXJlIG5vdCBhd2FyZSBvZiBhbnkmbmJzcDtzdGFuZGFy ZGlzYXRpb24gYWN0aXZpdGllcy88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PGJyPjxicj48YnI+ PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVM+PGJyPjUpIEkgYWxzbyBwcm9wb3NlIHVzaW5nIHRoZSBmb2xsb3dpbmcgdGV4dCBmb3Ig dGhlIHRoaXJkIGJ1bGxldCBpbiBTZWN0aW9uIDUgdW5sZXNzIHNvbWVvbmUgY2FuIHN1Z2dlc3Qg bW9yZSBhcHByb3ByaWF0ZSB0ZXh0IHRvIHN1bW1hcmlzZSBpbiBhIHNlbnRlbmNlIG9yIHR3byBh bnkgQ0ROIG1ldGFkYXRhIHJlbGF0ZWQgd29yayBpbiBvdGhlciBzdGFuZGFyZHMgYm9kaWVzLjxi cj48YnI+T0xEOjxicj4mbmJzcDsmbmJzcDtvICZuYnNwOyZsdDtUT0RPOiBBZGQgYSBzZW50ZW5j ZSBvbiBJVFUmZ3Q7PGJyPk5FVzo8YnI+Jm5ic3A7Jm5ic3A7byAmbmJzcDtDYWJsZUxhYnMsIFNO SUEgYW5kIElUVSBoYXZlIGRlZmluZWQgKG9yIGFyZSB3b3JraW5nIG9uKTxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDtkZWZpbml0aW9ucyBmb3IgY29udGVudCByZWxhdGVkIG1ldGFk YXRhIGRlZmluaXRpb25zIGFuZCBzcGVjaWZpY2F0aW9uPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO2ZvciBpdHMgZGlzdHJpYnV0aW9uLiBIb3dldmVyLCB0aGV5IGRvIG5vdCBpbmNs dWRlIG1ldGFkYXRhIHNwZWNpZmljPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Rv IHRoZSBkaXN0cmlidXRpb24gb2YgY29udGVudCB3aXRoaW4gYSBDRE4gb3IgYmV0d2VlbiBpbnRl cmNvbm5lY3RlZDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDRE5zLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTPlRoYXQgd29ya3MgZm9yIG1lLiBJdCB3b3VsZCBiZSBnb29k IHRvIGdldCB0aGF0IHZhbGlkYXRlZCBieSBzb21lb25lIGF3YXJlIG9mIHRoZSB3b3JrIG9mIHRo ZXNlIGJvZGllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PGJyPjxicj48YnI+PG86cD48L286 cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PGJy PjYpIFNlY3Rpb24gMTAuMSBsaXN0cyBhIG51bWJlciBvZiAmcXVvdDtub3JtYXRpdmUgcmVmZXJl bmNlcyZxdW90OywgaWYgd2UgYWRvcHQgdGhlIHByb3Bvc2VkIGNoYW5nZXMgYWJvdmUgaXQgd2ls bCBlbmQgdXAgY29udGFpbmluZyAmcXVvdDtub3JtYXRpdmUmcXVvdDsgcmVmZXJlbmNlcyB0bzo8 YnI+Jm5ic3A7Jm5ic3A7LSBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzPGJyPiZuYnNwOyZuYnNw Oy0gZHJhZnQtYmVydHJhbmQtY2RuaS1leHBlcmllbWVudHM8YnI+Jm5ic3A7Jm5ic3A7LSBkcmFm dC1qZW5raW5zLWNkbmktbmFtZXM8YnI+Jm5ic3A7Jm5ic3A7LSBSRkMyMTE5PGJyPjxicj5BZnRl ciByZWFkaW5nIHRocm91Z2ggdGhlIHRleHQgb2YgdGhlIFByb2JsZW0gU3RhdGVtZW50IGFnYWlu LCBJIGFtIG5vdCBjb252aW5jZWQgdGhhdCB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQgcmVmZXJlbmNl cyBhbnkgb2YgdGhvc2UgZG9jdW1lbnRzIG5vcm1hdGl2ZWx5IGFzIHRoZSAzIENETkkgcmVsYXRl ZCBkcmFmdHMgYXJlIHJlZmVyZW5jZWQgaW4gYSBjb250ZXh0IHdoZXJlIHRoZXkgYXJlIGZvciBm dXJ0aGVyIGluZm9ybWF0aW9uIGFuZCB0aGUgUHJvYmxlbSBTdGF0ZW1lbnQgZG9lcyBub3QgbWFr ZSB1c2Ugb2YgYW55IG9mIHRoZSBjYXBpdGFsaXNlZCB0ZXJtcyBkZWZpbmVkIGluIFJGQzIxMTku PGJyPjxicj5UaGVyZWZvcmUsIHVubGVzcyBhbnlvbmUgb2JqZWN0cyBJIHdpbGwgbW92ZSB0aGUg cmVmZXJlbmNlcyBmb3IgdGhlIHRocmVlIENETkkgcmVsYXRlZCBkcmFmdHMgdG8gdGhlICZxdW90 O0luZm9ybWF0aXZlIFJlZmVyZW5jZXMmcXVvdDsgc2VjdGlvbiBhbmQgcmVtb3ZlIHRoZSByZWZl cmVuY2UgZm9yIFJGQzIxMTkuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+SSBhZ3JlZSB3 ZSBkb24ndCB3YW50IG5vcm1hdGl2ZSByZWYgdG8gdGhlIG90aGVyIGNkbmkgZHJhZnRzIGFzIHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBpcyBzZXR0aW5nIHRoZSBzdGFnZSBmb3IgdGhlIG90aGVyIGRv Y3VtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5UaGFua3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUz5GcmFuY29pczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48YnI+PGJyPjxicj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48YnI+PGJy PlRoYW5rczxicj5CZW48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPkNETmkgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpDRE5p QGlldGYub3JnIj5DRE5pQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2RuaTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w PjxkaXY+PGRpdj48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHNwYWNp bmc9MCBjZWxscGFkZGluZz0wIHdpZHRoPTU0MyBzdHlsZT0nd2lkdGg6NDA3LjI1cHQnPjx0cj48 dGQgc3R5bGU9J3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48aW1nIGJvcmRlcj0wIHdpZHRoPTE1NCBoZWlnaHQ9MTAwIGlk PWE4MDk5YTJlLTI4NjQtNGY1Ni04NTY5LWUzMWQyZTNmODJjOCBzcmM9ImNpZDppbWFnZTAwMS5q cGdAMDFDQzk3QzAuQUJEMjY4NzAiPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48dGFibGUgY2xhc3M9 TXNvTm9ybWFsVGFibGUgYm9yZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wIHdpZHRo PTU0MyBzdHlsZT0nd2lkdGg6NDA3LjI1cHQ7YmFja2dyb3VuZC1hdHRhY2htZW50OmluaXRpYWw7 LXdlYmtpdC1iYWNrZ3JvdW5kLWNsaXA6IGluaXRpYWw7LXdlYmtpdC1iYWNrZ3JvdW5kLW9yaWdp bjogaW5pdGlhbDtiYWNrZ3JvdW5kLWNvbG9yOmluaXRpYWw7YmFja2dyb3VuZC1wb3NpdGlvbi14 OjUwJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCUnPjx0cj48dGQgc3R5bGU9J3BhZGRpbmc6MGNt IDBjbSAwY20gMGNtJz48L3RkPjwvdHI+PC90YWJsZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g Y2xhc3M9YXBwbGUtc3R5bGUtc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtmb250 LWZhbWlseToiVGltZXMiLCJzZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PG86cD48L286cD48L3A+PHRhYmxlIGNsYXNzPU1zb05vcm1hbFRhYmxlIGJvcmRlcj0wIGNlbGxz cGFjaW5nPTAgY2VsbHBhZGRpbmc9MCB3aWR0aD01NDMgc3R5bGU9J3dpZHRoOjQwNy4yNXB0O2Jh Y2tncm91bmQtYXR0YWNobWVudDppbml0aWFsOy13ZWJraXQtYmFja2dyb3VuZC1jbGlwOiBpbml0 aWFsOy13ZWJraXQtYmFja2dyb3VuZC1vcmlnaW46IGluaXRpYWw7YmFja2dyb3VuZC1jb2xvcjpp bml0aWFsO2JhY2tncm91bmQtcG9zaXRpb24teDo1MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAl Jz48dHI+PHRkIG5vd3JhcCB2YWxpZ249dG9wIHN0eWxlPSdwYWRkaW5nOjBjbSAwY20gMTEuMjVw dCAxOC4wcHQnPjxwIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PGI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjoj NjY2NjY2Jz48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPkZyYW5jb2lzIExlIEZhdWNoZXVyPC9zcGFuPjwvc3Ryb25nPjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNl cmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPkRpc3Rpbmd1aXNoZWQgRW5naW5lZXI8L3NwYW4+PC9zdHJv bmc+PGJyPjxzdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiJz5Db3Jwb3JhdGUgRGV2ZWxvcG1lbnQ8L3NwYW4+PC9zdHJvbmc+PGJyPjxhIGhyZWY9Im1h aWx0bzpmbGVmYXVjaEBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSdjb2xvcjojNjY2NjY2Jz5mbGVm YXVjaEBjaXNjby5jb208L3NwYW4+PC9hPjxicj5QaG9uZTombmJzcDs8c3Ryb25nPjxzcGFuIHN0 eWxlPSdmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+KzMzIDQ5IDcyMyAyNjE5PC9z cGFuPjwvc3Ryb25nPjxicj5Nb2JpbGU6Jm5ic3A7PHN0cm9uZz48c3BhbiBzdHlsZT0nZm9udC1m YW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPiszMyA2IDE5IDk4IDUwIDkwPC9zcGFuPjwvc3Ry b25nPjxicj48YnI+PGJyPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L3RkPjx0ZCBub3dyYXAgdmFs aWduPXRvcCBzdHlsZT0ncGFkZGluZzowY20gMGNtIDcuNXB0IDE1LjBwdCc+PHAgc3R5bGU9J21h cmdpbi1ib3R0b206MTIuMHB0Jz48c3Ryb25nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6IzY2NjY2Nic+Q2lzY28gU3lz dGVtcyBGcmFuY2U8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTo4LjVwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIjtjb2xvcjojNjY2NjY2Jz48YnI+R3JlZW5z aWRlPGJyPjQwMCBBdmUgZGUgUm91bWFuaWxsZTxicj4wNjQxMCBTb3BoaWEgQW50aXBvbGlzPGJy PkZyYW5jZTxicj48YSBocmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9J2Nv bG9yOiM2NjY2NjYnPkNpc2NvLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwv dGQ+PHRkIHdpZHRoPTIwMCBzdHlsZT0nd2lkdGg6MTUwLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvdGQ+PC90cj48 L3RhYmxlPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEzLjVwdDtm b250LWZhbWlseToiSGVsdmV0aWNhIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjxicj48aW1n IGJvcmRlcj0wIHdpZHRoPTE4IGhlaWdodD0xOSBpZD0iX3gwMDM2X2RmMmIwZWEtZmUxNy00Mjkz LThlZDgtMTdiOWY3MTNjMzRlIiBzcmM9ImNpZDppbWFnZTAwMi5naWZAMDFDQzk3QzAuQUJEMjY4 NzAiPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48dGFibGUgY2xhc3M9TXNvTm9ybWFsVGFibGUgYm9y ZGVyPTAgY2VsbHNwYWNpbmc9MCBjZWxscGFkZGluZz0wIHdpZHRoPTQwMCBzdHlsZT0nd2lkdGg6 MzAwLjBwdCc+PHRyPjx0ZCBzdHlsZT0ncGFkZGluZzowY20gMGNtIDBjbSAwY20nPjwvdGQ+PC90 cj48dHI+PHRkIHN0eWxlPSdwYWRkaW5nOjBjbSAxOC4wcHQgMGNtIDE4LjBwdCc+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6IkFyaWFs Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzAwOTkwMCc+Jm5ic3A7VGhpbmsgYmVmb3JlIHlvdSBwcmlu dC48L3NwYW4+PG86cD48L286cD48L3A+PC90ZD48L3RyPjx0cj48dGQgc3R5bGU9J3BhZGRpbmc6 NS4yNXB0IDE4LjBwdCA0LjVwdCAxOC4wcHQnPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFy Z2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1p bHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7Y29sb3I6Izk5OTk5OSc+PGJyPlRoaXMgZW1haWwgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcml2aWxlZ2VkIG1hdGVyaWFsIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudC4gQW55IHJldmlldywgdXNlLCBkaXN0cmli dXRpb24gb3IgZGlzY2xvc3VyZSBieSBvdGhlcnMgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCAob3IgYXV0aG9yaXplZCB0byByZWNl aXZlIGZvciB0aGUgcmVjaXBpZW50KSwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBs eSBlbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLjxicj48YnI+Q2lz Y28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBsaW1pdMOpZSwg UnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1bSBTZWluZSBJ bG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5MS40NzAg4oKs LCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJsaWNhdGlvbjog SmVhbi1MdWMgTWljaGVsIEdpdm9uZS48YnI+PGJyPkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3Jt YXRpb24gZ28gdG86PGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9k b2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbCI+aHR0cDovL3d3dy5jaXNjby5jb20v d2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2FsL2NyaS9pbmRleC5odG1sPC9hPjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD48L3RkPjwvdHI+PC90YWJsZT48L3RkPjwvdHI+PC90YWJsZT48L2Rpdj48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= ------_=_NextPart_002_01CC97B8.71F88E3F-- ------_=_NextPart_001_01CC97B8.71F88E3F Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEAYABgAAD/4QBmRXhpZgAASUkqAAgAAAAEABoBBQABAAAAPgAAABsBBQAB AAAARgAAACgBAwABAAAAAgAAADEBAgAQAAAATgAAAAAAAABgAAAAAQAAAGAAAAABAAAAUGFpbnQu TkVUIHYzLjM1AP/bAEMAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/bAEMBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAf/AABEIAGQAmgMBIgACEQEDEQH/xAAf AAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgv/xAC1EAACAQMDAgQDBQUEBAAAAX0BAgMABBEF EiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1Njc4OTpDREVGR0hJ SlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4eLj5OXm5+jp6vHy8/T19vf4+fr/xAAfAQADAQEBAQEBAQEB AAAAAAAAAQIDBAUGBwgJCgv/xAC1EQACAQIEBAMEBwUEBAABAncAAQIDEQQFITEGEkFRB2FxEyIy gQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYnKCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNk ZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfI ycrS09TV1tfY2dri4+Tl5ufo6ery8/T19vf4+fr/2gAMAwEAAhEDEQA/AP7+KKKKACiiigAoor49 /wCCgOv634Y/Yu/aP1vw7qt9omsWnwy1mO01TTLmSzv7Rb57bT7prW6hZJraWSzuriETwuk0QkLx SJIFdenBYaWNxmEwcZqEsXiaGGjOSbjCVerCkptKzai53aTu0rI4syxscty7H5jOEqsMBgsVjZUo tRlUjhaFSvKEZNNRlNU3FNppN3asfX6SRyqWjdJFDyRlkZXUSQyNFKhKkgPFKjxyL95JEZGAZSA+ v54/+Df/AFzWLvwf+0zoF1qd7caJpHiL4YappelzXEkllYajrun+OoNZvLSBmKQT6nFomkJevGAZ xp9rvyYwa/ocr0eIcneQ5xjcpeIWKeElRSrqm6PtI1sPRxEW6bnU5Go1lGS9pJXi2m00ePwfxFHi zhzLOII4R4FZhDEN4R1liHRlhsZiMHNKsqVH2kZTw8pxl7KD5ZJOKaYUUUV4p9KFFFFABTGliR44 mkjWSXf5UbOqvL5Y3P5aEhn2KQz7QdoOTgU+v5DP+CqnjnxjYf8ABS23uLHxNrdlP4BX4NL4MmtN RureTwz52l6Hr8zaM0UimwebWNRvL+Z7fY0087tIX4A+k4X4elxNmFbARxUcG6OBr4z2sqLrKXsZ 0qcafIqlK3POtG8+Z8sVJqMnaL+M454whwVlGHzWeAnmKxGaYTLVQhiFhnH6zCvVlWdR0a1/Z08P Plp8i55yjFzhG8l/XnRRRXzZ9mFFFFABRRRQAUUUUAFVry4FnZ3V2UMgtbae4KA7S4gieUoGIIUs FwDg4znB6V/OT+zV+3z+0t4+/wCCpWtfB3xR43Oo/CXXviR8ZvANv4AOmaTDpOg6L4F0zxvd+Frn SLmCwj1GLV7Sfwxp/wDaWozXUsmsx3GoJeL+9tGsf6LNa/5A2rf9gy//APSWWvczrIcXkGJweGxs 6FSeMwWGx8HQlOUY0sRKpD2c3KEGqkJ0pqXKnFq0oyd9Pl+GOLMv4twWY43LaWKo08uzTGZTUWLh ThOdfCQo1HVpqnVqp0alOvTlDncZp80ZwVk3+C3/AASz/wCCiX7Rf7U/7RvxG+HPxg1Pw7rHha68 A698QPDVppnhzStDm8GXOkeJvC2lQ6Fpl5pltb3WraLNY+IrgTP4km1fWPtNpaTR6skf2mC4/SP/ AIKPf8mNftL/APZNr7/04adX8+H/AAQo/wCTyPFn/ZAfGv8A6m3w1r+g/wD4KPf8mNftL/8AZNr7 /wBOGnV9nxPgMFl3H+VYfAYWjhKH1jI5+xw9ONKmpvE04ykoRSipSUU5NK8pXlK8m2/zbgTNcyzn wmz7GZrjsTmGL+q8T03icXVlWrOnHB1Zxg6k25OMHOShFtqEbQgowjGK/Kf/AIN9/wDkDftVf9hP 4Nf+kvxOr9Sf+Cjn7QHj39mf9lDx18UPhjNYWfje31Pwr4f0TVNSsLbVLfR5PEOvWdhd6ommXsct jfXdtYtciyhvoZ7JbuSGe6truGF7Wb8tv+Dff/kDftVf9hP4Nf8ApL8Tq+2P+Cz/APyYj42/7Hf4 b/8AqT21PiChRxPiksPiKcK1CtmmR06tKpFSp1KcsHl6lCcXpKEldSi01JNppptE8JYvE4HwJljM HWqYbFYbIuJquHxFKThVo1YZjm7hVpTVpQqQlaUJxalCSUotNJnd/wDBLX9pj4n/ALVH7Mk3j34v Xum6t4z8PfEbxH4FuNd07SrLRTrtlpWjeGNbtNS1DTdLhtdJttR/4qOWymGlWNhZSRWcEq2kczzM /wCj1fi//wAEKP8AkzfxZ/2X7xr/AOoT8Nau/wDBZD9qn4zfs2/DT4R6b8GPFM3gjVviN4p8SR63 4m0+1sbjWodK8KadpNxHpenTaha3kVimo3mtwz3l5bRR3+zTo7WG5jtrq8in8PM8ieYcbY7I8shh 8Kq2Y4inh4NOlhqEKdKVedo04ycYQhCbjCELbQikrW+oyTipZR4Y5VxTndTGY94fJ8JWxdSLVfG4 qpVrQwtNudapBVKs6lSmp1KtRN+9UnKTu3+ydfhd/wAFbP28f2g/2VPiB8HfBfwR1zRfDFtrvhy/ 8Z+Jb+/8NaL4jutcFvrjaXa6BKmvWl9BYaT5VlcSXc2lx2WsTNdgW+qWggXf+gv/AAT3+Mvjj9oD 9jz4L/Fn4kXtvqfjfxJp3iyy1/VLazttPTVLjwn4/wDFfg231OWzsooLK3vNRsfD1reX6Wdvb2hv p7hra2t4GjhT8Lf+C+v/ACXb4G/9kl1L/wBTHVK6+C8nof66f2TmmHw2Mjg55nh69GpCNfDTr4SF ak5KNSPLUjGpBypuUFqoyspJW4PEriLErw0fEGRYzG5dLMKWR4zC4ijUlhcbTw2YVsLXjBzozcqV SVGooVVTqNWc6fPKDd/6avht4nuvG3w78A+M722gs73xd4L8LeJ7u0tTIbW1utf0Ox1W4trYzM8p gglu3ihMrvIY1UuzNkn+RX/gq9/yko8Tf90V/wDUS8K1/WJ8Av8AkhPwV/7JL8OP/UO0av5O/wDg q9/yko8Tf90V/wDUS8K16XhpGMOKc0hFWjDKsxjFLZRjjcGkvkkkeJ41znV4DyKpUk5TqZ9ks5yd rynPLswlKTtZXbbeisf2PV/Pl4W/4KQftF6z/wAFR7z9na61Dw6vwUj+MPi34Ox+DI/DulLcJb+H 31nSbXxSPExtT4kOuTajpkWpXFu+pvohgllsItLjPl3af0G1/Hr8P/8AlNbf/wDZ43xL/wDUl8V1 5fA+X4LHUuKJYzC0MS8NkGKq4d1qcansKqjNqrS5k/Z1YuK5asbThryyV3f3PFDN8zyvE8Cwy7HY nBRxvFuBoYxYarKksVh+empYevyte1w81OXtKM+alU054S5Y2/sKoor+bT/gmD+37+0z+0L+2N4g 8G/FDxz/AMJD4G8b+FvGfiK38JzaTpVtp3hG80aSzvdGj8LS2VnbX1jb2Vm0ulS29xd3cWoW8zXm ord6skWoR/O5ZkOMzXAZzmGHqUIUckw9LE4mNWU41KkavtnGNFRpzUpKGHqyfPKCuoxveV19jnvF mXZBmvDeUYyliqmJ4nxtbBYGdCFOVKjUovDRlPEynVhKMHUxeHgvZxqStKcmkoa/0l0UUV4h9QFF FFAH46/Bj/glXP8ACj9unV/2sZfivb6v4VXxd8R/HPhzwXH4fmttdTV/iLZ6/ZSaXrGqtfSWL6do aeKdSkgvbOAXOpSWOn+daWST3Sp+wlxBHdW89tKCYriGWCQKdrGOZGjcBhyCVY4PY81NRXp5nm+Y ZxVw9fMK/t6uGwtHB0ZKFOny0KDnKnG1KME5c1ScpTac5OWrskl4mR8O5Rw5h8Xhcnwv1WhjcdiM yxMHWrVufF4mNOFWadapUlCLhSpwjTg4wjGC5Yptt/kN+wN/wS6uP2L/AI1ePfivqPxVt/HVtqvh XV/Avg7SbPw/LpNxb6Fq3iHRtak1XxHcTXtxE2sRweHdOs0s9Njax33V/ObhgltGv1D/AMFHQT+w 3+0vgE/8W1vzxzwL/TyT9AASfQDNfbFYviTw5oPjDQNa8K+KdI0/X/DfiLTL3Rdd0TVbaK903VdK 1G3ktb6wvrWZWintrm3lkiljdSCrHGDgjqq5/jcbnWDzrNKjxdfDYjBVJuMKVJzpYOpCcacY04wg nJQfvcuspNs4KHCeWZXw1mPDWRUY4DC43CZnRpqdSviFTr5jRq05VZzrVKlWUYynH3VPSEFGNrH8 9P8Awb7g/wBjftUnBwdU+DYB7Ei0+J2Rn1GRn0yPWv2E/bU/ZpP7Wv7PPjH4KweJl8IanrVzoWsa Jr01i2pWNrq/h3VrbVbWHUrKOa3nl0+/WCWxuJLaZbizFyt9FFdm2+xXPe/Av9m74I/s0+H9W8Mf BD4f6Z4C0fXdVbWtZis73WdWvNT1ExmKOW91fxFqer6vcQ2sRaKwspL82OnRSSx2FtbJNKr+3115 9xD9f4oxHEOWqrhn9YweIwnt40nVpzweHw9KE6kFKrSbc6HO4c1SFnytyVzg4U4Q/srgbCcH53LD 46P1PMMJmH1WdeNCtTzHF4zEVIUaso0K6UaeK9mqnJSnzR54qLtb4p/YI/ZJuP2MfgQfhPqHjCDx vrOp+M9d8ca3rFlpsmlaZFqGs2Oi6Smn6ZbT3FzdNaWun6BYlrm6dZri8lupRDbwmKFOA/4KLfsK XP7cPgXwHo2ieObPwJ4q+HfiHU9V0q91bS7nVtF1LTtfs7Sy1nTryKyura6s7gNp+m3tjfxJeKrW k9jJaBb/AO22X6K0V50M9zOnnDz6GItmbr1MQ8R7KlZ1KsZQqfuuT2XJKnOVNwUElF2VnZnsVeFs jrcOLhSpg3LI1hKWDWE9vXUlRoThVpf7Qqnt/aQq04VVUdRyc43k2m0/nT9kv4Awfsu/s8fDX4Ew +IX8Vt4E0/WVvPED2Q05dT1TxJ4n1vxdrEtvY+fdNa2Meq6/eW+nwyXM8y2MNv58rzeYx+Lf+Cin /BNrU/23fFnwy8ZeHvidp/gHUvBmkX/hbWbXWdAutbs7/Q73UhqsF9prWV/Yyw6pYTy3sb2dzutd Riubci801rJ/tv6u0UYTPc0wOazzrDYnkzKrVxNapXdKjNTqYvneIlKlODpfvHUm7KCUW04KNlYz DhbI8zyClwzjMG6mS0KGCw1HCxr4inKnRy/2SwkY4inVjiL0lRpx5nVcpxTVRy5pX5rwX4ZtfBXg 7wn4Nsbie7svCXhrQvDNpdXIQXNza6DpdrpVvcXAiCxieaK0SSURqqCRmCALgV/IP/wVfVh/wUn8 SkggMPgsykggMv8AwinhdcqT1G5WXI43KR1Br+x2vnH4jfsi/s3fFv4m+F/jH8RvhL4c8VfEjwct gmheJL+XVomVNKunvNLXVtKstStdD8SDTbmR5bD/AISTTNW+xnatt5aIir6/CHEVDh7NsTmOMo18 THEYDFYZxoez9p7atUo1ozl7SUI8jnR5ZtO8VPmjGbjyP57xD4OxXF/D+CyfLcRhcFPCZtgMapYr 23svq+FpYjDzpxdKnVm6ip4jmppxUZypqE6lNS9pH6Or8edB/wCCVsmift93f7X4+K1vN4Rm+IGv /FWLwMPD86eIR4r8QJfTz6TJrJv3046FBrOpXOpJepZi9eyjh0Y2SSM2sL+w1FeHl2b5hlSxscDX 9iswwlTBYpezp1PaYer8cV7SEuSVrpVIcs4pu0lc+ozjh7KM+lls81wv1mWUZhRzPAP2tal7HGUH enN+yqQ9rC9nKlV56U3GPNB2QV+Nv7Ev/BKS4/ZG/aN1/wCNFx8WbTxb4etdE8SaB4H8O2nh2403 VEtPEVxCq3HiW/udRu7fzdL0yD7KsOnRyjUbyf7c9xYRW32K7/ZKings3zDLsLmODwlf2WHzWjCh joezpz9tTpupypSnCUqbSq1Y81NxfLUkr3s0s04dyjOcdk2ZZjhfb4zIMTUxeV1fbVqaw9er7Fzk 4UqkIVU5YehNRqxnFTpRaVnJSKKKK8w9sKKKKACuS8eeO/CHww8G+I/iB4916w8MeDvCWl3Gs+IN d1J2S10+wtgNzlY0knubiaRo7aysbSGe+1C9mt7Gxt7i8uIIJOtr8G/+C9PxE1zQvgl8Gvhvp1xc W2kfELx7rmteIfIMiR31v4C0rT207TLx1+R7V9S8UQaqttJkSXmj2dyoLWYK+bnGYf2XlmMx/Iqj w9LmhBtqMqk5xpUlJrXldScea2vLezTPtvDjhB8ecccOcJfWJYWnnGOdPE4mCjKrRwWFw9bHY6dF TTg66weFr+wU04e25OdON0/BvjR/wXr8VL4g1Cw/Z9+DnhdfDdpPJBp/iP4sz61qOpazEkmFvn8M eFdY8Px6LHMgJitH8SapOFKSzSwuXtU+3v8Agmv/AMFIfiD+2p4y8d+BvH3w88G+Fbzwb4QtvFMe teELzW0tr9p9Zs9JaxfR9audVltwBdG4FwusTH5BEYOTIPnv/gj1+xN8BfFH7P8AH8f/AIneAPCX xQ8Y+NfE3iPTtEg8baNpnijRPCWgeF9U/seOGw8PatHf6VHr19q+nXupT61dWX9pw2T6dbaa1lbm 7m1P9qfBfwF+Cvw38U6l41+Hfwq8BeAvE+s6Qug6xq3gvwvpPhaXVtLS7gvkttSg0O1sbO/eO5to Hjurq3lvI1jWFJ1hzGfmciocTYuWCzbGZtTeFxKVeeAjSik8PUhJ0knGmowk7wmkm5ctuao5XR+2 +KuaeCHD1Hibw94a8P8AGRz/ACWcsrw/F1XHVp1IZxgsTRjjp1IVsZKriKN6eKw05TjGj7Xmlh8H Gj7OS/PH/gqN+3j8Xv2JP+FGf8Kq8OfDfxB/ws3/AIWb/b3/AAsHSPE+q/ZP+EM/4V9/Zf8AZH/C OeMPCf2f7R/wleo/b/tn2/zfJsvs/wBl8uf7T9afsMfHnxf+03+yz8Lvjf4803w3pHizxt/wm39q 6f4Rs9UsPD1v/wAI38RfF3hGx/s+01nWNf1KLzdN0Cznu/tOrXfmX0tzLD5Fu8VtD+Of/BwV/wA2 kf8Ade//AHi9fpB/wSO/5R6/s+/91X/9Xd8Sq3wWPxlTjPN8vniKksHQy+lVo4dtezp1HTyxucVa 9261V7/bkeZxNwnw5hPo0eHvF2GyjCUeJc04wxuAzDOIRmsZi8HTxfHEIYerJzcHTjDLcDFJQTth qeujv8yftzf8Fg9O/Zy+JesfBn4OeA9I+IfjPwlPFaeNfEvifUb228J6Jq7RLNceG9P07SGg1HWt SsUlij1W7OqaZa6ZfCbTlhv7mG5Nr5N+xJ/wWB+Nn7Qv7Qfw8+CXxI+GHwttrT4galqmnx+IfBA8 W6DcaN/Z/h7VtcWZ9O17xD4vj1PzW0v7MY1u9O2ifzQ7GLy5Pze/bs+Evxi/ZC/bi8T/AByvvCUG u+GvEPxp1L4zfDjxJ4l0eXxD4C8Sy6t4jl8ZHwvrJJgie70W7uptG1TRZrmx1QWtpHqOnyi0uLDU n/Y39jj/AIK9fCn9pLxp4P8Ahb8X/AMHww+KWs38em+Ddat54tf8C634iu2SCz0vTr28gh1rwjrW sO6Wel2d2mpWN7cItmfEKX13YWFx4eFzfMMRn1ahmGdyymdHMI06GWzwSdDE4dVUlR+sNxUJVqaU YVKim5uanSlrGK/VM78O+D8m8JsszbhLwvw/iHQzPhGrjM140w3E1WnmuSZvUwDlLMFlFOlWqYmj l2LlKriMFg5YeOFWFnhsdRvGtWl+zep6np2i6bqGsavfWml6TpNjd6nqmp6hcRWlhp2nWEEl1e31 7dzvHBa2lpbRS3FzcTOkUMMbySOqKSP56/2if+C7WnaB4m1Lw3+zX8MtK8ZaTpdzNar8RPiJd6tZ 6VrkkTGNp9E8H6S+l6sulMymS0v9V16wvruJlMuiWBAMn2N/wWZ+I2veAP2JtfsNBuZ7J/iT478J /DnVrq2kaKZdB1CDWvEmq2wdeRBqlv4W/si9jyFnsdQurd8pMyn84P8Agi/+xj8FvjN4b+Ivx1+L /hPQviPL4a8ZL4A8JeD/ABTZ22r+GNOuLXQdK17Wde1bw9dtNYa7PeQ+INPsNLh1mxuNOsvseo3E UFzfPDPpvsZ5mWa184wvD+T1qeEq1KDxGJxc4qThC05ckOaM+VKELtxhzznOEVKEVNv858K+CeAM r8Oc88XfEjLsXxBgMFmscmyXh7C1qlKGIxN8NTeIxDpV8N7SVTEYl04wr144bD4fDYmvOhi6tXDU 4fVX/BPX/gqr8Wf2svjjY/Bj4j/Db4d6Mb/wx4j19fEvgmXxLpohk0G3iuBbNo2u6v4l85LoS7DI NWiaEruCy52j9jPix8VfAvwR+Hnin4p/ErXIfD3gvwfpx1HWdTljlnkCvNFaWdlZWkCvcX2panf3 Frp2m2Nujz3l9dW9vGu6QEc/4d/Z2+Avg7xdpvj3wb8G/hp4O8ZaRYX2l2PiTwh4L0Dwvqsem6lC ILywnutBsdPa9s5YxhLa9+0QwNmS3SKRi5/DL/gvp8S/EVnYfAD4R2N7c2nhnW28Y+OvEVpFKyQa xqWjPoujeGluURl8yPSI9Q1+ZYpVeN59QgmAEtrGw662JzHh7IMZicwxUczxdCf7iq4OCl7aVKjQ hUSUW1TqylOfvOUoJpTu0l83l+S8H+MXi1w5knB2Q1uCMgzShH+1sCsQsTOl/ZtLH5hmmIwVSc60 I1MXgaFLD4VOlGlSxTU54aVOM5VPN/ip/wAF7/iVca5eRfBL4KeBdI8NwzvHp998UrnxB4k1vUbd XXy7u70zwnrvhSx0eaaMNu0+HVtbS3dlxqVwEO/6I/ZS/wCC3nhv4leNNG+H/wC0V4E0j4ZTeIr6 10vSPiH4W1O+uvB1vqd7MYLW38TaTrBn1Lw9p0szQQf29HrGr2dtLN52qQaXpsNxqMPrP/BMj9gn 9nXRv2Zvh58VvHPw48FfFT4hfFrw9D4t1LWPHfh/R/GFjoOl6pJO2keHvDela3b6jpej/Y9LaNNY vre2XWNQ1G41CC9vP7PistNsfzZ/4LNfse/CP9n/AMSfDD4pfB7QNM8DaZ8T5/E2jeJvA2iRx2Ph 201vw7DpF5Z654b0eNhBpFvqNnqc1pqumaZDa6NZz2Gn3FpaQ3GpXjS/N1qvF+X5fS4grZlRxFJq hXr5fKnBRjh68oKEbRpRin+8gpqk4zhdtVJ8rv8AtmXZf9HXi/i/G+EGW8E5nlOPp1M0yrK+LqWM xLxFbNspo4ieKq3q42tVlB/U8TPDSx9KvhsS4KE8Jhva01H+r6ivhL/gmd8S/EXxZ/Yg+A/izxZe 3OpeIYND13wlf6leStcXWoQ+BfF3iDwdpN5dXMjNNd3k+iaJpr311cE3FzfG5mmeV3M0n3bX6Ng8 THGYTC4uCcYYrD0cRCMvijGtTjUUX5pSs/NH8Y8RZLiOHM/zzh7FVIVcTkWb5lk+Iq001Tq1stxl bB1KtNO7VOpOi5wTd+WSvqFFFFdB44UUUUAFfmP/AMFWP2TvEf7Uv7OSf8K+sH1X4mfCnXH8b+Ft FhGbvxNpj2E9h4p8LWALBTqV/Yta6rpUQV5r/VNCstIh2NqRkT9OKwPEviG08M6VPql2rSCPCQwI QJJ5nOEjTPc9Seygk8AkceYYShj8FicHib+wr0nCo07Sjs4zi3dKUJqM43TXNFXTWj+j4R4hzXhT ibJeIsk5XmmU4+lisLTqRc6Vd606uFrRjKEnQxVCdXDV1GcJ+xqz5KkJWmv43f2LP+Ckfxf/AGEr XxP8LdX+H8PjzwPJr97qN74B8TajqXgzxL4R8VgW9hq66bq0ulaxJpCXQskj1jQtS8O3ipqMC3dt /Z91JqY1H93f2BP+ClGu/twfFbx74Qk+E2k/DLw54O8BW3iWFU8W3njLW77VJ9fsNKKy6mdC8LWM Onrb3Mri2TRZLkzCNjfbFaOTpfjP8FfhF+0d4iOvfEL4B/D3xZraLFGusf2BqEHiue0tlMVtb6p4 k8O6hpOtanbWyMyW9teXMlpbhsQwocGvb/2UfgR8I/gzc+JF+H/wY8HfDTVb2xtLW81bRdH1KDXN T02OfzRY3+ra7f6rqtxaLcrHcfZxdpbtPGkskTyxxunx+TZdnmAxeGwsc4hXyfD1JctGVDlrVKXL Jxp80qM5U4qUk1BYlwSVkkrJf0Z4mcZ+FfFuQZ3ns/DrE5V4j5thcM62Z0c19tl2Fxbr4WNfFujS zHD0MVVqUY1KbxE8kWInKfPUqOd6j/I//g4K/wCbSP8Auvf/ALxev0g/4JHf8o9f2ff+6r/+ru+J Ve6/tG+FvA3ivUPC0Pj34QfB/wCKtpptnqkuiH4o/DzRfHU+g3F/PZpq40Z9aWZNMi1OOw0j7ctp FE92+n2xuZJhb2yw+zfCrRPDHhv4c+GtI8FeEPC3gPw/a2NzLY+FPBeg6d4a8L6TdXt9d3+qf2Vo Wkw21hYRX2sXN9qU6Qxh5ru8uLi4kmuZpp5PWwmVSpcT5lm/t4ShicHDDqhySU4OMMBHnc37jT+r N2Wvvx7M+Az/AI+oY/wL4K8O1lleliMk4jxWbzzZ4mjPDYiFavxTWVCGGivb06kVnkIuU24t4ao1 pOB+QXxM/wCCzf7OWheLfir8Hfix8BfH+vQeDPGnjTwHqFpaW3gXxl4a8SyeEfEOo6JDdXdh4l1T QEhtNSn01Lt7aay1BrASBVN88IaT8L/Bfh6D9rD9u7RG/Zm+FEnw28MeJvif4Z8TaL4M0qSOWw+H fhTQb3RJvEXie/ntYo7DRtMtWs73xJcWNkhstMub+Hw3oKXrjS4Lr+j7x7+xJ8FfiV4q13xd4q/Z b+HGq6/q2ralqes6vp+m+J/DTaxqd/dPcahqt7B4e8XaPBd3uo3LSXlzdzQyXFxczT3MkjzTzSSf Qn7PHhj4S/BNp/B3gn4NeCvha2qXIivr7whoq6fd6hcBsxQ69eXj3ut34iOBbyXuq3UcAISGGGPF eHismzbN8Xh45vj8J9SoYn2tKVHCOnipxUvdo+1dGmoKUW4tqpKClabhUlGNv1LIfErw+8O+H83x Hh7wpxA+J80yP+z8dRzDiGGK4fw9epSp+2zBYCOZYqeJlTrwVSmpYSliXS58LTxGGpV63NN+3z+z ZeftV/sw+PvhZoRtk8aL/Z/izwDJeSxW9q3i/wAM3BvLKwnuZiIbSPXrB9S8ONezOkNiNY+2TN5U Dg/ywfso/tkfHv8A4JwfETx14P1bwDNeadqd3b23xB+EfjpdT8M39rrWlxTJp2saVe/ZrifQtV8i 4Ecl6dM1TTtb0d4A9rceVpOoWX9q+r6raaLp9zqV6xW3tYy77Rl3P8KIO7ueAK+Avjn4M+Fv7R1z awfEj4F+APHqabG1to9/4i0a8uvFdjZtL50tvZeJNFvtJ1zT7O4lAmmsLK+jtmkG6UTMAw9PiHJp 4nF4bNMvxrwOa4eHs6cuRzp1aacrKaUZ8rXtJxbcKkakZezlBpJr4jwf8S8NkvD2d8CcYcLw4r4B zjFfXcVh1iI4bGYDGOOH554SVSrRjWjOWFwtaFOnicDWwmJp/W6OLhOcoVPm39jP/grFrf7Yf7Q/ h/4PWvwR0r4a6HdeF/Fev6rqlx48u/G+q3E2h2cc9nb6eY/Cng6zsInllH2lrm21N5I1KxeQzB16 L/gsL+yH4k/aL+Cnh/4i/DrTbzXPiJ8D59b1OPw1pts11qPinwV4hTTB4nsdMtYVNxe61o8uj6br mmWcW+W6s7fW7GytrrU76xgf2r9nT9nv4PfBjx5Y6n8NfgB8P/h/rd5Bc6dP4nt9I8RXniG2026A a9trDWPEuu6veWSXYjSOdLaaJZoVMMgaLKV+gGtazY6Dp8+p6hIUt4FyQgDSyufuxRISN8j4wq5A 7kgAkdOFwGKzDJcXgc9xccXUxE5qdelBUo0opUp0eSKpUI81GpBVf4ajKWkuZN38TOuL8i4R8TeH +KvCnh+vw/gcooYV4fKcfi6uPq4+rUnjaGZQxVWWPzOsqWZYPFSwUksZOpSp+/RdOUYOP8g37GP/ AAVu+J/7J3w7g+EfiT4eaf8AGHwLoU92/hC3vPFV34N8SeF4r65nvLzR01v+wfFVtf6Gl9PNdWNh caLFd6fJcXNvFqLWH2OzsvF/2g/2jP2hP+Cnnx38B+HdM8HRi7SSfw58Mvhl4Va9v7DQIdXuLafX Nb1fVrpFae4mjs7S68TeJrq30vS7HSNHtpXtNPtLGV3/AKNPi38Af2bvjh4lvPEnib9l/wCG2ta7 eXD3V9rg03VdK8Q6xOd6/btd1DwVqHhq51S6kjYCR9Tm1CQbY1NxIIISvo/wQ8P/AAu/Z9eTTfh3 8Dfh78PLW/EVrrV94S0F9O8S31okokjTVNc1Ge/1vWYrZ8ywWup6jLHG+5ojEzFj8x/YGb16VHK8 bnyqZNSnBRhToTVadOlKLp025Uk0kkuRTxFanRai4wkoRR+6f8Rd8Osqx2P474b8J6mE8S8ww+Jq VMRi81w08tw+NxtKUMTiqapY+dN1KrnUeJq4TKMtxeYRqVqdXE0Xiasz6E/Zj+B+mfs3fAT4Y/BL Sr0anD4C8OrY32qLF5Eeq6/qd9ea94n1WCDAa3ttS8Sarqt9bW8heWC3uIoppZpUeV/d6r2l1BfW 0F3bOJILiJJYnHdHAIz6EZwQeQQQelWK/SaNKnQo0qNGKjSo04UqUVqo06cVCEU+yikl5I/ijMsf jM0zHH5nmNWWIzDMcbisfjq80lOtjMXXqYjFVZqKSUqlepOckkknJpJLQKKKK0OIKKKKACvLfibY y39vpcQBMKzTyOv8PmBEWMkdztaTHpz68epVn6jYRX8HlSDlWDocZ2sARnHcEEg+xz2qKkOeEo97 fg0/xsdWDxH1XE0q/wDz7k35q8XG681e5yfw+0mz07RFaKFBczTym5kKgvuRsRrnkhRHtYDgZZiB zk93tUEsFAYjBOBkj0J64rm7TTLqxLfZZDGHxuUBWRsdCUYFc9ecA4PWta1S7WR2uZS6lMKuFVQd wJOFAGcdzzjjpSprlhGPK1ZW0tb1363u9N76DxU/bVqtd1VN1JOVm25atWjta0bpLW1lsrWPMfif pf8AaE2jvt3eXFer0zjL2xrtfBkH2XwzpVuRjyo51x6f6XcEfoavatpo1BoCRnyhIOf9sp/8TV6w tvstnFb9PLDj/vqR29/71TGnatOpb4o2v6KHl5dzWri/aZdh8Jf+DVlO19rurrbz5/8Ah9TiPEXi y+t55bLSYV3xEpLdSqXAfAysUZwMochmcMCchV4DHh9H8Hapq+txaxqCuq/akuri5mURvKYyMLEh AJztCghdiqMAkgKfVH0TbeNdRqpfzjOpYAjeW3nIPX5iensQRWzEb3egkESxj72xGBx+LsB+A/Lq JdJzmpVG2oyvGKS5Vqrf8HyT13N6ePWFoOnhIU4TqUuWrWbvVd0nJeeuqV+VNfDozjviNay3mhxQ Jko95F5qjugV2XPsHVfxNZ/w30SysbO8uDDGb17gIzsql0hCKUC55VWYvnGMle+K9EvbSO9t3gkG VYAjjOGBBVh7gj8Rkd6w7bSLiykL2sjRsRglcbWH+0jAq3qNynB6U3T/AHyqW5tLenTTTz7rdmVP F/8ACfPBc/s71HNvZSu4u0mt07Wfay3V0dKUQsGKKWX7rFQWH0JGR+Bryz4mWc1+mmQDcYFM8jKM 7WkGwDcOh2jBHHGT616HAl8JlaeUtGAcqFRQSeATtAPv6UupafFqEIRx80bbkb0OMEe4I7eoB6ir qR9pTlG1ua29tbNPz3tbUwwlb6piqNa6lyNu8bvl5ouN9baq938+pzngbR7DTNEtmt4YxcThnuZs AyNJuIKluoCfdC5AAHTNcz8SdCsrwafcpDGt4XlSRkUBpIgqkGTHXaxIDEZOcZOOO3tNNu7IMLaQ xq3JTCsmfUKwKgnuQATgZNRT6NNeSiS6dpGOAWbnao7Ko4A5JwABk+9RKHNSVPk2UV0srW1Xn8ur vszppYqVPHvG+3u3Kc73blJTTXI+nKrrS70irJNe7X8CwS23hy0gl3fu5LhU3ZyIxM4QDPYAYHtX YVBbQR20McEY2pGoUD6D9T6nueanrWK5Yxj/ACxS+5WOCvV9tWq1bW9pUlO3bmbf66hRRRVGQUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAf/2Q== ------_=_NextPart_001_01CC97B8.71F88E3F Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 ------_=_NextPart_001_01CC97B8.71F88E3F-- From ben@niven-jenkins.co.uk Mon Oct 31 04:46:07 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DB721F8BFB for ; Mon, 31 Oct 2011 04:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.159 X-Spam-Level: X-Spam-Status: No, score=-103.159 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pfl7Xz7INHJj for ; Mon, 31 Oct 2011 04:46:06 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8C621F8BB9 for ; Mon, 31 Oct 2011 04:46:06 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-125-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RKqJZ-0001sn-6v; Mon, 31 Oct 2011 11:46:05 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <12F21DF9-18CA-4916-8681-8919A4735C89@cisco.com> Date: Mon, 31 Oct 2011 11:45:56 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> <2A0AF3CA-36D1-4F0E-8D09-3E29EFBC72A6@niven-jenkins.co.uk> <12F21DF9-18CA-4916-8681-8919A4735C89@cisco.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] =?utf-8?b?562U5aSNOiAgUHJlcGFyaW5nIGRyYWZ0LWlldGYtY2RuaS1w?= =?utf-8?q?roblem-statement_for_WG_Last_Call?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 11:46:07 -0000 Francois, On 28 Oct 2011, at 00:52, Francois Le Faucheur wrote: > On 27 Oct 2011, at 12:59, Ben Niven-Jenkins wrote: >> OLD: >> This creates a requirement for interconnecting standalone >> CDNs so that their collective CDN footprint can be leveraged for the >> end-to-end delivery of content from Content Service Providers (CSPs) >> to End Users. However, no standards or open specifications = currently >> exist to facilitate such CDN interconnection. >> NEW: >> This creates a requirement for interconnecting standalone >> CDNs so that their collective CDN footprint can be leveraged for the >> end-to-end delivery of content from Content Service Providers (CSPs) >> to End Users. However, no standards or open specifications = currently >> exist to facilitate such CDN interconnection. For example, a CSP = could >=20 > The "for example" does not flow very well (it suggests this is an = example of why no standards exist - aka the previous sentence). > So I'd suggest: > s/For example/As an example of scenario involving interconnection of = CDNs/ I've just rearranged the ordering slightly so the "however, no = standards..." comes after the example. The paragraph nows reads: This creates a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. For example, a CSP could contract with an "authoritative" CDN for the delivery of content and that authoritative CDN could contract with one or more downstream CDN(s) to distribute and deliver some or all of the content on behalf of the authoritative CDN. The formation and details of any business relationships between a CSP and a CDN and between one CDN and another CDN are out of scope of this document. However, no standards or open specifications currently exist to facilitate such CDN interconnection. If you still prefer s/For example/As an example/ I can pick that up in = the next revision? >> contract with an "authoritative" CDN for the delivery content >=20 > s/delivery content/delivery of content/ Done. >> and that CDN >=20 > The same CDN is referred in the same sentence as "that CDN" and the = "authoritative CDN". Might be better to always refer to it the same way: > s/that CDN/that authoritative CDN/ Done. >=20 >=20 > Francois >=20 >> could contract with one or more downstream CDN(s) to distribute and >> deliver some or all of the content on behalf of the authoritative = CDN. >> The formation and details of any business relationships between a = CSP and=20 >> a CDN and between one CDN and another CDN are out of scope of this=20= >> document. >>=20 >> Ben >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > >=20 > Francois Le Faucheur > Distinguished Engineer > Corporate Development > flefauch@cisco.com > Phone: +33 49 723 2619 > Mobile: +33 6 19 98 50 90 >=20 >=20 >=20 > Cisco Systems France > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com >=20 >=20 >=20 >=20 > > Think before you print. >=20 > This email may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. >=20 > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 From ben@niven-jenkins.co.uk Mon Oct 31 05:08:57 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4F321F8DF0 for ; Mon, 31 Oct 2011 05:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.384 X-Spam-Level: X-Spam-Status: No, score=-103.384 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCQBJ-PlVmY0 for ; Mon, 31 Oct 2011 05:08:56 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 34F5921F8DF6 for ; Mon, 31 Oct 2011 05:08:56 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-125-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RKqfe-0000EP-1e; Mon, 31 Oct 2011 12:08:54 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <58F25507-696C-4B8F-9DA6-9B7315CE32AC@cisco.com> Date: Mon, 31 Oct 2011 12:08:53 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1B23FC2D-45E0-4FDC-BD2A-B8FF1AD1075E@niven-jenkins.co.uk> References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> <58F25507-696C-4B8F-9DA6-9B7315CE32AC@cisco.com> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:08:57 -0000 On 28 Oct 2011, at 02:02, Francois Le Faucheur wrote: > Ben and all, >=20 > (As an individual) >=20 > A few additional comments on problem-statement: >=20 > 1) Appendix "A.2. Prioritizing the CDNI Work" > I would propose that we remove that appendix altogether because: Done. > * the terms introduced there of "Base/Operationalized/Enhanced = CDNI" do not correspond to anything really meaningful anymore for the WG = now that it has been establish (ie there is "in scope" and "out of = scope") > * the requirements document is defining a specific notion of = priority with High/Medium/Low priority. >=20 > 2) In last paragraph of section 1 (just before section 1.1), the = references to the Appendices are incorrect (ie "Appendix A.2" shows up 3 = times). I've reworded the last paragraph so it doesn't refer to the appendices = (as they're supposed to be removed by the RFC Editor prior to = publication anyway) and so it summarises the content of the sections in = the main document body. The paragraph now reads: The goal of this document is to outline the problem area of CDN interconnection (CDNI) for the IETF. Section 2 discusses the use cases for CDN interconnection. Section 3 presents the CDNI model and problem area being considered by the IETF. Section 4 describes each CDNI interface individually and highlights example candidate protocols that could considered for reuse or leveraging to implement the CDNI interfaces. Section 5 provides a gap analysis against the work of other standards organizations. Section 6 describes the relationships between the CDNI problem space and other relevant IETF Working Groups. >=20 > 3) section 3: > OLD: > The CDNI model and problem area proposed for IETF work > NEW: > The CDNI model and problem area defined for the IETF work Done. > 4) section 3: > OLD: > The CDNI model and problem area proposed > for IETF work is illustrated in Figure 1. The candidate problem = area > (and respectively the non-goals) for IETF work on CDN = Interconnection > are discussed in Section 3.1 (and respectively Appendix A.1 ). > NEW: > This section discusses the problem area for IETF work on CDN = Interconnection. The CDNI model and problem area defined for IETF work = is illustrated in Figure 1.=20 Done.=20 > 5) section 3.1: > I would propose to remove this sentence : > " > [I-D.jenkins-cdni-names] presents one > view on how CDN data types/objects could be classified such that = the > problem space of their naming and referencing is not as large as it > might at first appear because there is significant commonality > between the different data types/objects required for CDNI. > " Done. > I feel that the referenced document has served its purpose in = providing some thoughts on metadata but its detailed content has = received little review/comments and is being revisited as part of the = work on the metadata interface. >=20 >=20 > 6) section 4.3, 4.4 and 4.5 (multiple occurrences) > OLD: > a CDNI WG > NEW: > the CDNI WG Done throughout the document. > 7) section 4.3. > As discussed in 3.1, the Request Routing interface is likely to cover = two capabilities: > * allow the upstream CDN to query the downstream CDN at request- > routing time before redirecting the request to the downstream > CDN > * allow the downstream CDN to provide to the upstream CDN (static > or dynamic) information (e.g. resources, footprint, load) to > facilitate selection of the downstream CDN by the upstream = CDN > request routing system when processing subsequent content > requests from User Agents. > However, section 4.3 only currently discusses candidate protocols for = the first capability. So I would propose we add something along the = lines of: > "As discussed in section 3.1, the CDNI Request Routing interface is = also expected to enable a downstream CDN to provide to the upstream CDN = (static or dynamic) information (e.g. resources, footprint, load) to = facilitate selection of the downstream CDN by the upstream CDN request = routing system when processing subsequent content requests from User = Agents. It is expected that such functionality of the CDNI request = Routing could be specified by the CDNI WG with significant leveraging of = existing IETF protocols supporting the dynamic distribution of = reachability information (such as BGP) or supporting queries by = application element for topological information (such as ALTO). Done but I tweaked the wording slightly, the final words I went with = are: Additionally, as discussed in Section 3, the CDNI Request Routing interface is also expected to enable a downstream CDN to provide to the upstream CDN (static or dynamic) information (e.g. resources, footprint, load) to facilitate selection of the downstream CDN by the upstream CDN request routing system when processing subsequent content requests from User Agents. It is expected that such functionality of the CDNI request Routing could be specified by the CDNI WG with significant leveraging of existing IETF protocols supporting the dynamic distribution of reachability information (for example by leveraging existing routing protocols) or supporting application level queries for topological information (for example by leveraging ALTO). Ben From ben@niven-jenkins.co.uk Mon Oct 31 05:12:17 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09BCF21F8DA6 for ; Mon, 31 Oct 2011 05:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.395 X-Spam-Level: X-Spam-Status: No, score=-103.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tq4XjA4VHYiV for ; Mon, 31 Oct 2011 05:12:16 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4840721F8CBE for ; Mon, 31 Oct 2011 05:12:16 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-125-devlan.cachelogic.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RKqit-00066t-0Q; Mon, 31 Oct 2011 12:12:15 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 31 Oct 2011 12:12:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <398A7DF6-951B-49A0-9A01-B729EAAE697D@niven-jenkins.co.uk> References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> To: Francois Le Faucheur X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 12:12:17 -0000 Francois, On 28 Oct 2011, at 10:27, Francois Le Faucheur wrote: > On 17 Oct 2011, at 13:07, Ben Niven-Jenkins wrote: >> I therefore propose making the following change to the last sentence = in Section 5: >>=20 >> OLD: >> The following sections will summarize the existing work of the >> standard bodies above against the CDNI problem space. >> NEW: >> The following sections will summarize the existing work of the >> standard bodies above against the CDNI problem space. Section 5.1 >> summarises existing interfaces that could be leveraged for content >> acquisition between CDNs and Section 5.2 summarises existing = metadata=20 >> specifications that may be applicable to CDNI. To date there is no >> existing standardisation activities in the areas of the remaining >> CDNI interfaces (CDNI Request Routing, CDNI Control and CDNI = Logging). >=20 > Fine. >=20 > Just a couple editorial suggestions: >=20 > s/of the standard bodies above/of the standard bodies listed earlier/ Done. > s/there is no existing standardisation activities/we are not aware of = any standardisation activities/ Done. >> 5) I also propose using the following text for the third bullet in = Section 5 unless someone can suggest more appropriate text to summarise = in a sentence or two any CDN metadata related work in other standards = bodies. >>=20 >> OLD: >> o >> NEW: >> o CableLabs, SNIA and ITU have defined (or are working on) >> definitions for content related metadata definitions and = specification >> for its distribution. However, they do not include metadata = specific >> to the distribution of content within a CDN or between = interconnected >> CDNs. >=20 > That works for me. It would be good to get that validated by someone = aware of the work of these bodies. Sure, if someone can volunteer to do that or can suggest someone who may = be able to to that validation I'm happy to adjust the text according to = any suggestions they make. Ben From ben@niven-jenkins.co.uk Mon Oct 31 06:05:03 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637CC21F84A1 for ; Mon, 31 Oct 2011 06:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.405 X-Spam-Level: X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtMKg6RyBtrw for ; Mon, 31 Oct 2011 06:05:02 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF9D21F849D for ; Mon, 31 Oct 2011 06:05:02 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-125-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RKrXu-00084w-0e; Mon, 31 Oct 2011 13:04:58 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136D12B4@PACDCEXMB05.cable.comcast.com> Date: Mon, 31 Oct 2011 13:04:54 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> <1CA25301D2219F40B3AA37201F0EACD1136D12B4@PACDCEXMB05.cable.comcast.com> To: "Woundy, Richard" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 13:05:03 -0000 On 28 Oct 2011, at 17:49, Woundy, Richard wrote: > > o CableLabs, SNIA and ITU have defined (or are working on) = definitions for content related metadata definitions and specification = for its distribution. > =20 > Are we referring to these CableLabs specifications? > =20 > = http://www.cablelabs.com/specifications/MD-SP-CONTENTv3.0-I01-100812.pdf > = http://www.cablelabs.com/projects/metadata/specifications/specifications30= .html I believe so, the reference we have currently have for CableLabs is this = URI http://www.cablelabs.com/projects/metadata/primer/ which provides some background and has a link to the actual CableLabs = metadata specifications. > Do we have references for the SNIA and ITU specs as well? The current reference we have for SNIA is this URI: http://www.snia.org/tech_activities/standards/curr_standards/cdmi which has links to the CDMI v1.0 and CDMI v1.0.1 specifications. I'm not sure what the right ITU reference is for metadata but if someone = can suggest one I will include it. Ben > =20 > -- Rich > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Francois Le Faucheur > Sent: Friday, October 28, 2011 5:28 AM > To: Ben Niven-Jenkins > Cc: cdni@ietf.org > Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG = Last Call > =20 > HI Ben, > =20 > Comments below: > =20 > On 17 Oct 2011, at 13:07, Ben Niven-Jenkins wrote: >=20 >=20 > Colleagues, >=20 > At the last IETF I said I would try to prepare a version of the CDNI = problem Statement (draft-ietf-cdni-problem-statement) that is ready for = WG Last Call before IETF82 in Taipei. >=20 > As part of that I have reviewed the complete draft and made some minor = editorial clean-ups to my working copy. However, there were a number of = other areas where I think changes need to be made to the document that I = think warrant wider WG review/consensus and I have listed them below = along with the changes I am proposing. >=20 > Could you please provide your feedback on the areas/proposed text I = have highlighted below as well as any other areas of the document that = you think require additional work/cleanup before you consider the = document is ready for a WG Last Call. >=20 > 1) Section 2: Update the last paragraph to reference the WG draft for = CDNI use cases and remove reference to draft-watson-cdni-use-cases, i.e. >=20 > OLD: > Use cases for CDN Interconnection are further discussed in > [I-D.bertrand-cdni-use-cases] (which contains a merged set of use > cases previously presented in [I-D.watson-cdni-use-cases] and > [I-D.bertrand-cdni-use-cases-00]). > NEW: > Use cases for CDN Interconnection are further discussed in > [I-D.ietf-cdni-use-cases]. > =20 > Agreed. >=20 >=20 >=20 >=20 > 2) Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) = that are each just a couple of sentences, so I propose merging them into = a single section and changing the first two sentences of section 4 = appropriately, i.e. >=20 > OLD: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols. First the "reuse instead of reinvent" design > principle is restated, then each inetrface is discussed individually > with example candidate protocols that can be considered for reuse or > leverage.=20 > NEW: > This section expands on how CDNI interfaces can reuse and leverage > existing protocols before describing each CDNI interface = individually > and highlighting example candidate protocols that could considered = for > reuse or leveraging to implement the CDNI interfaces. =20 > =20 > Fine by me. >=20 >=20 >=20 >=20 > 3) Section 5 is currently title "Gap Analysis of relevant = Standardisation and Research Activities" but following the agreement at = the last IETF to move the generic descriptions of other activities into = an appendix Section 5 no longer references any research activities so I = propose changing the title to" Gap Analysis of relevant Standardisation = activities". > =20 > Agreed. >=20 >=20 >=20 > 4) After the general introduction in Section 5 there are only sections = that outline other research activities > =20 > I think you mean "standardization activities" >=20 >=20 > for Content Acquisition (section 5.1) and CDNI Metadata (Section 5.2) = but there are not sections for the other CDNI interfaces (Control, = Logging, Request Routing). >=20 > The reason for the lack of text is IMO because there is no current or = past standardisation activity addressing those areas but the document = currently does not mention that and therefore gives the impression of = being incomplete. >=20 > I therefore propose making the following change to the last sentence = in Section 5: >=20 > OLD: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. > NEW: > The following sections will summarize the existing work of the > standard bodies above against the CDNI problem space. Section 5.1 > summarises existing interfaces that could be leveraged for content > acquisition between CDNs and Section 5.2 summarises existing = metadata=20 > specifications that may be applicable to CDNI. To date there is no > existing standardisation activities in the areas of the remaining > CDNI interfaces (CDNI Request Routing, CDNI Control and CDNI = Logging). > =20 > Fine. > =20 > Just a couple editorial suggestions: > =20 > s/of the standard bodies above/of the standard bodies listed earlier/ > =20 > s/there is no existing standardisation activities/we are not aware of = any standardisation activities/ > =20 >=20 >=20 >=20 > 5) I also propose using the following text for the third bullet in = Section 5 unless someone can suggest more appropriate text to summarise = in a sentence or two any CDN metadata related work in other standards = bodies. >=20 > OLD: > o > NEW: > o CableLabs, SNIA and ITU have defined (or are working on) > definitions for content related metadata definitions and = specification > for its distribution. However, they do not include metadata = specific > to the distribution of content within a CDN or between = interconnected > CDNs. > =20 > That works for me. It would be good to get that validated by someone = aware of the work of these bodies. > =20 >=20 >=20 >=20 > 6) Section 10.1 lists a number of "normative references", if we adopt = the proposed changes above it will end up containing "normative" = references to: > - draft-ietf-cdni-use-cases > - draft-bertrand-cdni-experiements > - draft-jenkins-cdni-names > - RFC2119 >=20 > After reading through the text of the Problem Statement again, I am = not convinced that the Problem Statement references any of those = documents normatively as the 3 CDNI related drafts are referenced in a = context where they are for further information and the Problem Statement = does not make use of any of the capitalised terms defined in RFC2119. >=20 > Therefore, unless anyone objects I will move the references for the = three CDNI related drafts to the "Informative References" section and = remove the reference for RFC2119. > =20 > I agree we don't want normative ref to the other cdni drafts as the = problem statement is setting the stage for the other documents. > =20 > Thanks > =20 > Francois >=20 >=20 >=20 >=20 > Thanks > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > =20 > >=20 > Francois Le Faucheur > Distinguished Engineer > Corporate Development > flefauch@cisco.com > Phone: +33 49 723 2619 > Mobile: +33 6 19 98 50 90 >=20 >=20 > Cisco Systems France > Greenside > 400 Ave de Roumanille > 06410 Sophia Antipolis > France > Cisco.com >=20 > =20 >=20 > > Think before you print. >=20 > This email may contain confidential and privileged material for the = sole use of the intended recipient. Any review, use, distribution or = disclosure by others is strictly prohibited. If you are not the intended = recipient (or authorized to receive for the recipient), please contact = the sender by reply email and delete all copies of this message. >=20 > Cisco Systems France, Soci=E9t=E9 =E0 responsabiit=E9 limit=E9e, Rue = Camille Desmoulins =96 Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy = les Moulineaux, Au capital de 91.470 =80, 349 166 561 RCS Nanterre, = Directeur de la publication: Jean-Luc Michel Givone. >=20 > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 > =20 From internet-drafts@ietf.org Mon Oct 31 07:20:16 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9A421F8CA7; Mon, 31 Oct 2011 07:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQgIkK6E3+lB; Mon, 31 Oct 2011 07:20:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A891621F854D; Mon, 31 Oct 2011 07:20:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031142015.8805.5308.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 07:20:15 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-problem-statement-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:20:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnec= tion Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Prob= lem Statement Author(s) : Ben Niven-Jenkins Francois Le Faucheur Nabil Bitar Filename : draft-ietf-cdni-problem-statement-01.txt Pages : 35 Date : 2011-10-31 Content Delivery Networks (CDNs) provide numerous benefits: reduced delivery cost for cacheable content, improved quality of experience for End Users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network. This creates a requirement for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The goal of this document is to outline the problem area of CDN interconnection (CDNI) for the IETF. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-01.txt From ben@niven-jenkins.co.uk Mon Oct 31 07:24:33 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58F421F8BE7; Mon, 31 Oct 2011 07:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.423 X-Spam-Level: X-Spam-Status: No, score=-103.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3io3VzYzYTsK; Mon, 31 Oct 2011 07:24:33 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id E357121F8C00; Mon, 31 Oct 2011 07:24:32 -0700 (PDT) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp-125-devlan.cachelogic.com) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RKsmu-0007gH-1s; Mon, 31 Oct 2011 14:24:32 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <20111031142015.8805.5308.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 14:24:31 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20111031142015.8805.5308.idtracker@ietfa.amsl.com> To: internet-drafts@ietf.org X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org, i-d-announce@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-problem-statement-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 14:24:33 -0000 Colleagues, This version incorporates the proposals/comments made to the mailing = list as well as a few other editorial changes/fixes. You can see a diff against the previous version here: = http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-problem-statement-01.= txt Ben On 31 Oct 2011, at 14:20, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Content Delivery Networks = Interconnection Working Group of the IETF. >=20 > Title : Content Distribution Network Interconnection = (CDNI) Problem Statement > Author(s) : Ben Niven-Jenkins > Francois Le Faucheur > Nabil Bitar > Filename : draft-ietf-cdni-problem-statement-01.txt > Pages : 35 > Date : 2011-10-31 >=20 > Content Delivery Networks (CDNs) provide numerous benefits: reduced > delivery cost for cacheable content, improved quality of experience > for End Users and increased robustness of delivery. For these > reasons they are frequently used for large-scale content delivery. > As a result, existing CDN providers are scaling up their > infrastructure and many Network Service Providers (NSPs) are > deploying their own CDNs. It is generally desirable that a given > content item can be delivered to an End User regardless of that End > User's location or attachment network. This creates a = requirement > for interconnecting standalone CDNs so they can interoperate as an > open content delivery infrastructure for the end-to-end delivery of > content from Content Service Providers (CSPs) to End Users. = However, > no standards or open specifications currently exist to facilitate > such CDN interconnection. >=20 > The goal of this document is to outline the problem area of CDN > interconnection (CDNI) for the IETF. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-01.t= xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-problem-statement-01.tx= t > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From alan.kavanagh@ericsson.com Mon Oct 31 09:03:57 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B799111E80E6 for ; Mon, 31 Oct 2011 09:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.458 X-Spam-Level: X-Spam-Status: No, score=-5.458 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arnPpd7jbAJn for ; Mon, 31 Oct 2011 09:03:54 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id D315711E80EB for ; Mon, 31 Oct 2011 09:03:53 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p9VG3Fwe031335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 31 Oct 2011 11:03:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 31 Oct 2011 12:03:14 -0400 From: Alan Kavanagh To: "zahariad@synelixis.com" , "'Kent Leung (kleung)'" , "'Mark de Jong'" Date: Mon, 31 Oct 2011 12:03:13 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyUIr+HmTxXW9tSQVutk3w35YQ82wC0/Z7gADvMhzA= Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D517108F46BC@EUSAACMS0701.eamcs.ericsson.se> References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com><4E8506FC.1020701@cisco.com><260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com><853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk><9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net><260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com><1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk><260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com><166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk><1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> <2979E38DD6FC6544B789C8DAD7BAFC521024D515@xmb-sjc-235.amer.cisco.com> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34@EUSAACMS0701.eamcs.ericsson.se> <00bf01cc96f7$11feedf0$35fcc9d0$@com> In-Reply-To: <00bf01cc96f7$11feedf0$35fcc9d0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1B6D0317D3AD964FBF3956DEFA3524D517108F46BCEUSAACMS0701e_" MIME-Version: 1.0 Cc: "cdni@ietf.org" , 'ZhouZhipeng' Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:03:57 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D517108F46BCEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Theodore I do tend to agree with your point, though i would like one Use Case docume= nt as the baseline for which the Framework adn Metadata etc use to be built= around. I do see the merit in taking on work that should be fullfilled wit= hin a given time limit and im all for that as long as we ensure all use cas= es are captured and not ignored. Im not too picky on where it should be don= e (current use case or another doc). Alan ________________________________ From: Theodore Zahariadis [mailto:zahariad@synelixis.com] Sent: October-30-11 7:29 AM To: Alan Kavanagh; 'Kent Leung (kleung)'; 'Mark de Jong' Cc: cdni@ietf.org; 'ZhouZhipeng' Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Dear all, I think that a good approach would be to proceed in cdni-use cases to ensur= e realistic/short-term use cases and then proceed to the advanced use cases= that the Future Media Networks (FMN) cluster of projects have submitted un= der the cdni-advanced-use-cases ID. Best Regards, Theodore From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: Thursday, October 27, 2011 12:04 AM To: Kent Leung (kleung); Mark de Jong Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt So are we defining a limited set of use cases or should we ensure that use = cases at the very least ensure that the realistic use cases both deployed t= oday and ones planed are captured in the use cases document? Alan ________________________________ From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: October-26-11 5:02 PM To: Mark de Jong; Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I also agree with Ben that content adaptation is an optimization that is ou= t of scope. We have enough to do in the WG already. Kent From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Mar= k de Jong Sent: Wednesday, October 26, 2011 1:21 PM To: Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Alan, As Ben stated the overall discussion right now is about delivery, not on ad= aptation. It is hard enough to get consensus on the delivery aspect already= not to mention your requirement from content adaptation added to that, so = I agree with Ben we should stick with the delivery aspect for the first spe= cs. I can imagine this could be a discussion later on but please let us kee= p the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to have= it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs= ' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: Ben Im assuming then based on your comments below are you suggesting we are goi= ng to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that there i= s some work to be done, but I still feel that content adaptation is to me a= fundamental requirement to what collectively we should address in the CDN-= I WG. I do agree with you that content adaptation is an optimization betwee= n CDN's but it's a very important one that I know Network Service Providers= particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: Hello Ben, The UE may select the content format on the CP web. After that the user onl= y desires to get his selected content. But how the content is transferred to the client is not worried by the user= . The CP may create a special format as required by the user and ask the CDN = to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transfo= rm to the format as the user select. Lots of things may be possible to do and CDN providers offer many additiona= l services on top of the "core" service of content delivery. However, our o= bjective (based on my interpretation of the CDNI charter) is to focus on wh= at is necessary to interconnect CDNs to deliver content from a CSP to an En= d User that is targeted and deployable within a short time frame (18-24 mon= ths). Content transformation/adaptation is not an essential requirement in order = to achieve that aim (we can deliver content from CSPs to End Users via mult= iple CDNs without needing or requiring any CDN supports content adaptation)= . In my opinion we have enough work to do already without trying to expand th= e scope of our work to include additional requirements that do not help us = address our core objectives as laid out in the CDNI charter. In this case, it is nothing related to how the user select formats on CP we= bsite. So, it is the CP and user to decide the content format not the CDN(your ass= ert is not correct and seems you take that assert as your base for the disc= ussion). As for "the core CDN functionality offered by CDNs today", I have ever rais= ed an email before that your company's webpage has claimed supporting media= transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core fu= nctionalities by existing main stream CDNs. Thus we may compare and take de= ep look. I think the core functionality maps pretty well to the CDNI interfaces, nam= ely: Request Routing, Metadata configuration, log production and control pl= us content acquisition and content delivery. I guess many people have the experience/knowledge of content related servic= e. The user and CP only care whether the CDN providers may satisfy their re= quirement while not care the internal process. Just as GSM/PSTN interconnec= tion, the user only care successful interconnection while not care how the = voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media format= s. One candidate is your company, another is CDN-X. The users are located in F= rance. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-= Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the c= ost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in s= olution-2, it should only receive 1 stream but need to take transformation = to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the p= rice from BBC is same to both your company and CDN-X or BBC would select on= e CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is no= t a core functionality. What you are describing is a possible optimization that a particular CDN ma= y wish to implement not a core functionality required to enable content del= ivery between interconnected CDNs. I can think of many optimizations that a= CDN could implement to differentiate their service but the internal workin= gs of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core= function required to enable content delivery between interconnected CDNs a= nd therefore given the workload we already have to specify solutions that d= o address the core functionality required to interconnect CDNs I do not thi= nk we should be trying to add more work into that workload as it will only = distract us from achieving our goal of producing deployable solutions withi= n the timeframe we are being told by operators they needs solutions within. Ben So, if we all realize that currently the media type is rich, the CDN provid= ers should survive in the existing ecosystem and support the media types as= required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection,= the transformation should at once be solved. Otherwise the interconnection= may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: Ben and Philip, I like to respond your concern in this one email: Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct that= the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media type", e= tc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether the i= ssues such as "logging" "geographic constraint" are the core of CDN. For "without explicit knowledge of what that content actually is ", I am no= t sure whether the wording is accurate since generally a CDN may claim it s= upport different medias. By this opportunity, I like to share a use case: a call from a GSM phone to= a PSTN telephone, the voice stream should be transformed from GSM voice to= G.711. For the user, he does not need to know what type of data has been transferr= ed, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to this c= ase above. I don't think your use case is similar to the analogy of mobile networks be= ing interconnected to PSTN networks. In the case of content delivery the ne= gotiation is done between the User/Client and the Content Provider and the = CDN is just used to execute/perform the delivery that has been negotiated. = The CDN is not involved in the decision making of what representations the = Content Provider decides to offer to the User/Client or in what representat= ions the User/Client decides to request. As for you said selecting media by the "portal", you may see the way " uCDN= delivers multiple media streams to dCDN" is not good than "uCDN delivers o= ne media stream to dCDN and dCDN takes some adaptation to support multiple = media types". Now what you're talking about is an optimisation, not a core function requi= red to actually deliver the content (and report, bill, etc. for that delive= ry). My position is that we should focus on how to enable the interconnection of= the core CDN functionality offered by CDNs today (which is also my interpr= etation of the scope of the CDNI working group as expressed in its charter)= because doing so is a significant piece of work in itself. Let's not start= trying to add in additional functionality beyond what the majority of CDNs= support today as that will just delay us getting usable specifications int= o the market in a timely fashion IMO. Ben A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) If the content is needed= to be protected, generally you may know all the systems should be granted = by the content owner. Here I also like to clarify that not only the media itself but the informat= ion related to service itself (such as the geographic constraint) should be= protected also. So, trust is not a problem for the media. Philip, Thank you that you feel Content Adaption is an issue for "Requirements" but= I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it may s= ave investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile se= rvice and another system for the FBB service. But the reality is all operators ask us to provide a system that may suppor= t different service systems. Frankly, Ben and Philip, I remember I have explained somewhere that to impl= ement this is rather simple . At least the Use case and Requirement are informational to be referred in f= uture work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng -----Original Message----- From: philip.eardley@bt.com [mailto:philip.ea= rdley@bt.com] Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ben, Zhipeng, all, I think that Content Adaptation is more an issue for the Requirements doc t= han for the Use cases draft. The key question is whether we want the CDNI interfaces to be able to cope = with a scenario where (say) HD/SD conversion is done in the dCDN & to signa= l about this. I think that coping with this scenario is a second order requirement, ie we= should not worry about it in the initial standards-track work. I don't kno= w, did we ever decide whether the Use cases doc is restricted to "initial" = scenarios, or whether it's all-encompassing, ie covering "future" scenarios= as well? Scott, Reading some of your examples, they seem to be valid even if content adapta= tion (HD/SD) is out of scope. - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) On security considerations, an interesting question is whether trust is tra= nsitive. Don't think it need be - just because CSP trusts uCDN, and uCDN tr= usts dCDN doesn't mean that the CSP automatically trusts the dCDN. However,= i suspect this can get arbitrarily complex - so one possibility is to say = that we will only handle cases where the trust is transitive. Best wishes phil Philip Eardley Research and Technology Strategy This email contains BT information, which may be privileged or confidential= . It's meant only for the individual(s) or entity named above. If you're no= t the intended recipient, note that disclosing, copying, distributing or us= ing this information is prohibited. If you've received this email in error,= please let me know immediately on the email address above. Thank you. We m= onitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adapt= ation (i.e. taking in a content item in one format and transforming it to a= nother format or representation) is not a "core" function of a CDN which ty= pically delivers the content that is requested without explicit knowledge o= f what that content actually is. Let's not forget that in building an end to end content service the CDN is = only one component and is the component tasked with executing the delivery = of a specific representation (version/copy/format etc.) of the selected con= tent not the component tasked with deciding (or applying policy) on which v= ersion/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to = be delivered to a given device/user is implemented outside of the CDN (e.g.= by the "portal" where the user first makes their content selection prior t= o the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: Following Scott's comments on section 5.1.3, I feel Scott's description on = the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with di= fferent identifier. In DRM scope, the basic unit is a content copy. Here the first bullet "a subset of encodings deliverable to specific device= s," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken some= email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area to = explain the content flexibility is currently a basic requirement for CDN se= rvice and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments or = questions on this case since I hope my use case may be incorporated in the = use case draft. If you have any more question or comments, pls share in this thread. Thanks. Zhipeng -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. Section 10 Security Considerations Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is dete= rmined by the respective CDN's. Scott _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_1B6D0317D3AD964FBF3956DEFA3524D517108F46BCEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Theodore
 
I do tend to agree with your point, though i would= like one=20 Use Case document as the baseline for which the Framework adn Metadata etc = use=20 to be built around. I do see the merit in taking on work that should be=20 fullfilled within a given time limit and im all for that as long as we ensu= re=20 all use cases are captured and not ignored. Im not too picky on where it sh= ould=20 be done (current use case or another doc).
 
Alan

From: Theodore Zahariadis=20 [mailto:zahariad@synelixis.com]
Sent: October-30-11 7:29=20 AM
To: Alan Kavanagh; 'Kent Leung (kleung)'; 'Mark de=20 Jong'
Cc: cdni@ietf.org; 'ZhouZhipeng'
Subject: RE: [CD= Ni]=20 I-D Action: draft-ietf-cdni-use-cases-00.txt

Dear=20 all,

 

I=20 think that a good approach would be to proceed in cdni-use cases to ensure= =20 realistic/short-term use cases and then proceed to the advanced use cases t= hat=20 the Future Media Networks (FMN) cluster of projects have submitted under th= e=20 cdni-advanced-use-cases ID.

 

Best=20 Regards,

Theodore

 

 

From:<= /B> Alan Kavanag= h=20 [mailto:alan.kavanagh@ericsson.com]
Sent: Thursday, October 27, = 2011=20 12:04 AM
To: Kent Leung (kleung); Mark de Jong
Cc:=20 cdni@ietf.org; ZhouZhipeng
Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

 

S= o are=20 we defining a limited set of use cases or should we ensure that use cases a= t the=20 very least ensure that the realistic use cases both deployed today and ones= =20 planed are captured in the use cases document?

 

A= lan

 

From:<= /B>= Kent=20 Leung (kleung) [mailto:kleung@cisco.com]
Sent: October-26-11 5:0= 2=20 PM
To: Mark de Jong; Alan Kavanagh
Cc: cdni@ietf.org;=20 ZhouZhipeng
Subject: RE: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

I=20 also agree with Ben that content adaptation is an optimization that is out = of=20 scope.  We have enough to do in the WG already.

 

Kent

 

From:<= /B>= =20 cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ma= rk de=20 Jong
Sent: Wednesday, October 26, 2011 1:21 PM
To: Alan= =20 Kavanagh
Cc: cdni@ietf.org; ZhouZhipeng
Subject: Re: [C= DNi]=20 I-D Action: draft-ietf-cdni-use-cases-00.txt

 

Hi Alan,

 

As Ben stated the overall discussio= n right=20 now is about delivery, not on adaptation. It is hard enough to get consensu= s on=20 the delivery aspect already not to mention your requirement from content=20 adaptation added to that, so I agree with Ben we should stick with the deli= very=20 aspect for the first specs. I can imagine this could be a discussion l= ater=20 on but please let us keep the scope of this be clean and transparent. It is= of=20 benefit of everyone to get the first specs as fast as possible.=20 Thanks.

 

 

 

On 26, Oct,2011, at 8:33 PM, Alan K= avanagh=20 wrote:

 

Ben
Im=20 assuming then based on your comments below are you suggesting we are going = to=20 have a number of versions of the CDN-I Metadata?

I sympathise with w= hat=20 you are pointing out below and do agree that there is some work to be done,= but=20 I still feel that content adaptation is to me a fundamental requirement to = what=20 collectively we should address in the CDN-I WG. I do agree with you that co= ntent=20 adaptation is an optimization between CDN's but it's a very important one t= hat I=20 know Network Service Providers particularly=20 require.

Alan

-----Original Message-----
From: cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent:=20 October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D = Action:=20 draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On 12 Oct 2011, at= =20 10:22, ZhouZhipeng wrote:

Hello Ben,

The UE may select the content for= mat on=20 the CP web. After that the user only desires to get his selected=20 content.

But how the content is transferre= d to the=20 client is not worried by the user.

The CP may create a special forma= t as=20 required by the user and ask the CDN to deliver to=20 user.

While CP may give a HD format con= tent to=20 uCDN and the dCDN may then transform to the format as the user=20 select.


L= ots of=20 things may be possible to do and CDN providers offer many additional servic= es on=20 top of the "core" service of content delivery. However, our objective (base= d on=20 my interpretation of the CDNI charter) is to focus on what is necessary to= =20 interconnect CDNs to deliver content from a CSP to an End User that is targ= eted=20 and deployable within a short time frame (18-24 months).

Content=20 transformation/adaptation is not an essential requirement in order to achie= ve=20 that aim (we can deliver content from CSPs to End Users via multiple CDNs=20 without needing or requiring any CDN supports content adaptation).

I= n my=20 opinion we have enough work to do already without trying to expand the scop= e of=20 our work to include additional requirements that do not help us address our= core=20 objectives as laid out in the CDNI charter.

In this case, it is nothing related= to how=20 the user select formats on CP website.

So, it is the CP and user to deci= de the=20 content format not the CDN(your assert is not correct and seems you take = that=20 assert as your base for the discussion).

 

As for "the core CDN functionalit= y offered=20 by CDNs today", I have ever raised an email before that your company's we= bpage=20 has claimed supporting media transformation and multi-screen=20 service.

Perhaps, I like asking you list s= ome=20 features that you feel are the core functionalities by existing main stre= am=20 CDNs. Thus we may compare and take deep look.


I= think the=20 core functionality maps pretty well to the CDNI interfaces, namely: Request= =20 Routing, Metadata configuration, log production and control plus content=20 acquisition and content delivery.

I guess many people have the=20 experience/knowledge of content related service. The user and CP only care= =20 whether the CDN providers may satisfy their requirement while not care the= =20 internal process. Just as GSM/PSTN interconnection, the user only care=20 successful interconnection while not care how the voice is transformed in=20 process.

 

Besides, I like raise a=20 case:

Given currently BBC recruits CDN = providers=20 that may support 10 media formats.

One candidate is your company, an= other is=20 CDN-X. The users are located in France.

So both your company and CDN-X sh= ould=20 connect a France CDN provider(CDN-Y).

If your company's solution is to = send 10=20 streams of different format

of one content to CDN-Y; While CD= N-X's=20 solution is to send 1 stream to CDN-Y while CDN-Y may conduct some=20 adaptation.

Comparing these two solutions, fo= r your=20 company and CDN-X, absolutely the cost of CDN-X is much=20 lower.

For CDN-Y, in solution-1, it shou= ld=20 receive/forward 10 streams ; while in solution-2, it should only receive = 1=20 stream but need to take transformation to output 10=20 streams.

 

Which solution is more competitiv= e. it is=20 Solution 1, right. Remember the price from BBC is same to both your compa= ny=20 and CDN-X or BBC would select one CDN provider with the lower=20 price.

If a CDN provider may not get the= contract=20 from CP, how it may say it is not a core=20 functionality.


W= hat you are=20 describing is a possible optimization that a particular CDN may wish to=20 implement not a core functionality required to enable content delivery betw= een=20 interconnected CDNs. I can think of many optimizations that a CDN could=20 implement to differentiate their service but the internal workings of an=20 individual CDN are out of scope of our charter.

So to repeat my posi= tion=20 for a final time: Content adaptation is not a core function required to ena= ble=20 content delivery between interconnected CDNs and therefore given the worklo= ad we=20 already have to specify solutions that do address the core functionality=20 required to interconnect CDNs I do not think we should be trying to add mor= e=20 work into that workload as it will only distract us from achieving our goal= of=20 producing deployable solutions within the timeframe we are being told by=20 operators they needs solutions within.

Ben

=

So, if we all realize that currentl= y the=20 media type is rich, the CDN providers should survive in the existing ecosys= tem=20 and support the media types as required by the market.

 

Back to the case of GSM/G.711, it= just=20 when concerning the interconnection, the transformation should at once be= =20 solved. Otherwise the interconnection may not be=20 operated.

 

Br,

Zhipeng

 

 

 

 

-----Original=20 Message-----

From: Ben Niven-Jenkins=20 [mailto:ben@niven-jenkins.co.uk]

Sent: Wednesday, October 12, 2011= 12:19=20 AM

To:=20 ZhouZhipeng

Cc: philip.eardley@bt.com; cdni@ietf.org

Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt

 

Zhipeng,

 

On 11 Oct 2011, at 05:16, ZhouZhi= peng=20 wrote:

 

Ben and=20 Philip,

I like to respond your concern = in this=20 one email:

 

Ben,

I feel what we are now discussi= ng is=20 what is the "core" function of=20 CDN.

As you say, CDN is used to deli= ver=20 content. That is absolutely correct that the delivery capability is the= core=20 requirement for CDN system.

While CDN is used to provide th= e content=20 delivery service.

What means service. It should i= nclude=20 "time" "location" and "media type", etc. These features are all the cor= e=20 feature for a service.

If we only concern "delivering = one data=20 block", I am not sure whether the issues such as "logging" "geographic= =20 constraint" are the core of CDN.

 

For "without explicit knowledge= of what=20 that content actually is ", I am not sure whether the wording is accura= te=20 since generally a CDN may claim it support different=20 medias.

By this opportunity, I like to = share a=20 use case: a call from a GSM phone to a PSTN telephone, the voice stream= =20 should be transformed from GSM voice to=20 G.711.

For the user, he does not need = to know=20 what type of data has been transferred, but the operator has done some = work=20 to interconnect two systems,=20 right.

I like to know whether you may = accept=20 that my use case is similar to this case=20 above.

 

I don't think your use case is si= milar to=20 the analogy of mobile networks being interconnected to PSTN networks. In = the=20 case of content delivery the negotiation is done between the User/Client = and=20 the Content Provider and the CDN is just used to execute/perform the deli= very=20 that has been negotiated. The CDN is not involved in the decision making = of=20 what representations the Content Provider decides to offer to the User/Cl= ient=20 or in what representations the User/Client decides to=20 request.

 

As for you said selecting media= by the=20 "portal", you may see the way " uCDN delivers multiple media streams to= =20 dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN= =20 takes some adaptation to support multiple media=20 types".

 

Now what you're talking about is = an=20 optimisation, not a core function required to actually deliver the conten= t=20 (and report, bill, etc. for that delivery).

 

My position is that we should foc= us on how=20 to enable the interconnection of the core CDN functionality offered by CD= Ns=20 today (which is also my interpretation of the scope of the CDNI working g= roup=20 as expressed in its charter) because doing so is a significant piece of w= ork=20 in itself. Let's not start trying to add in additional functionality beyo= nd=20 what the majority of CDNs support today as that will just delay us gettin= g=20 usable specifications into the market in a timely fashion=20 IMO.

 

Ben

 

A good question is "security" s= ince I=20 have done six years on the DRM

and like to promote the DRM all= around=20 the world:) If the content is needed to be protected, generally you may= know=20 all the systems should be granted by the content=20 owner.

Here I also like to clarify tha= t not=20 only the media itself but the information related to service itself (su= ch as=20 the geographic constraint) should be protected=20 also.

So, trust is not a problem for = the=20 media.

 

Philip,

Thank you that you feel Content= Adaption=20 is an issue for "Requirements" but I do not know why it is not for Use= =20 case.

I like to clarify to U that it = is=20 important for you operator since it may save investment if the system m= ay=20 support different services.

For us vendor, we are happy ope= rator may=20 install a system for the mobile service and another system for the FBB= =20 service.

But the reality is all operator= s ask us=20 to provide a system that may support different service=20 systems.

 

Frankly, Ben and Philip, I reme= mber I=20 have explained somewhere that to implement this is rather simple=20 .

At least the Use case and Requi= rement=20 are informational to be referred in future work. So I do really feel yo= u may=20 accept it.

Of course I like to respond you= r more=20 concern and comments.

Thanks.

Zhipeng

 

 

 

-----Original=20 Message-----

From: philip.eardley@bt.com=20 [mailto:philip.eardley@bt.com]

Sent: Monday, October 10, 2011 = 11:22=20 PM

To: ben@niven-jenkins.co.uk;=20 ZhouZhipeng

Cc: cdni@ietf.org

Subject: RE: [CDNi] I-D Action:= =20 draft-ietf-cdni-use-cases-00.txt

 

Ben, Zhipeng,=20 all,

 

I think that Content Adaptation= is more=20 an issue for the Requirements doc than for the Use cases=20 draft.

 

The key question is whether we = want the=20 CDNI interfaces to be able to cope with a scenario where (say) HD/SD=20 conversion is done in the dCDN & to signal about=20 this.

 

I think that coping with this s= cenario=20 is a second order requirement, ie we should not worry about it in the=20 initial standards-track work. I don't know, did we ever decide whether = the=20 Use cases doc is restricted to "initial" scenarios, or whether it's=20 all-encompassing, ie covering "future" scenarios as=20 well?

 

Scott,

Reading some of your examples, = they seem=20 to be valid even if content adaptation (HD/SD) is out of=20 scope.

- a dCDN might for some reason = be=20 unwilling to distribute HD?

- a CSP might want to make sure= the dCDN=20 can use HLS encapsulation?

But these sorts of examples see= m to be=20 static policy things (to do

with the capabilities & pre= ferences=20 of the CDNs & CSP), rather=20 than

metadata associated with a part= icular=20 piece of content. In the

discussion so far, I think nego= tiation=20 about static policy stuff is

rather out of=20 scope(?)

 

On security considerations, an= =20 interesting question is whether trust is transitive. Don't think it nee= d be=20 - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that = the=20 CSP automatically trusts the dCDN. However, i suspect this can get=20 arbitrarily complex - so one possibility is to say that we will only ha= ndle=20 cases where the trust is=20 transitive.

 

Best=20 wishes

phil

 

 

Philip=20 Eardley

Research and Technology=20 Strategy

 

This email contains BT informat= ion,=20 which may be privileged or confidential. It's meant only for the=20 individual(s) or entity named above. If you're not the intended recipie= nt,=20 note that disclosing, copying, distributing or using this information i= s=20 prohibited. If you've received this email in error, please let me know= =20 immediately on the email address above. Thank you. We monitor our email= =20 system, and may record your=20 emails.

British Telecommunications=20 plc

Registered office: 81 Newgate S= treet=20 London EC1A 7AJ Registered in

England no:=20 1800000

 

 

-----Original=20 Message-----

From: cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On=20 Behalf

Of Ben=20 Niven-Jenkins

Sent: 10 October 2011=20 12:04

To:=20 ZhouZhipeng

Cc: cdni@ietf.org

Subject: Re: [CDNi] I-D Action:= =20 draft-ietf-cdni-use-cases-00.txt

 

Colleagues,

 

IMO Section 5.1.3 should be rem= oved from=20 the Use Cases draft. Content Adaptation (i.e. taking in a content item = in=20 one format and transforming it to another format or representation) is = not a=20 "core" function of a CDN which typically delivers the content that is=20 requested without explicit knowledge of what that content actually=20 is.

 

Let's not forget that in buildi= ng an end=20 to end content service the CDN is only one component and is the compone= nt=20 tasked with executing the delivery of a specific representation=20 (version/copy/format etc.) of the selected content not the component ta= sked=20 with deciding (or applying policy) on which version/copy/representation= of=20 content should be delivered.

 

The decision as to which=20 version/copy/representation to offer and allow to be delivered to a giv= en=20 device/user is implemented outside of the CDN (e.g. by the "portal" whe= re=20 the user first makes their content selection prior to the CDN becoming= =20 involved in the delivery of the selected=20 content).

 

Ben

 

On 8 Oct 2011, at 08:20, ZhouZh= ipeng=20 wrote:

 

Following Scott's comments on= section=20 5.1.3, I feel Scott's description on the use case of HD and SD is not= =20 exactly correct.

If one movie has two formats = of HD and=20 SD, then we have two content with different identifier. In DRM scope,= the=20 basic unit is a content=20 copy.

 

Here the first bullet "a subs= et of=20 encodings deliverable to specific devices," has listed the case of co= ntent=20 adaptation.

In last month, I have contact= ed the=20 Authors of this document and taken some email exchanges with Grant an= d=20 Philip (BT).

I have shown BT with some inf= ormation=20 that I know in this case and area to explain the content flexibility = is=20 currently a basic requirement for CDN service and related negotiation= is=20 needed in the CDN=20 interconnection.

Meanwhile, I should also invi= te you in=20 this group raising your comments or questions on this case since I ho= pe my=20 use case may be incorporated in the use case=20 draft.

 

If you have any more question= or=20 comments, pls share in this=20 thread.

Thanks.

Zhipeng

 

 

 

 

 

 

-----Original=20 Message-----

From: Scott Wainner=20 [mailto:swainner@cisco.com]

Sent: Friday, September 30, 2= 011 8:02=20 AM

To: cdni@ietf.org

=

Subject: Re: [CDNi] I-D Actio= n:=20 draft-ietf-cdni-use-cases-00.txt

 

Section 2.3 Nomadic=20 Users

This description falls under = the=20 category of Geographic=20 Extension

yet the third paragraph state= s the=20 case where a different device=20 is

used in the same CDN coverage= area.=20  The intent of this use=20 case

needs to be clarified.  = Perhaps=20 the use case is trying to=20 address

the scenario where a Nomadic = User-A=20 with an agreement=20 allowing

access to content from CSP-A = via uCDN=20 moves to a dCDN in a=20 different

region.  The dCDN is all= owed to=20 distribute the content of CSP-A=20 to

User-A; however, not other us= ers in=20 the region of the dCDN=20 are

allowed to retrieve the conte= nt unless=20 they too have such an=20 agreement.

 

Section 5.1.3 Content Encodin= g=20 Restrictions Need to clarify if=20 we're

talking about the restriction= s on the=20 delivery of specific=20 content

or the restrictions on the ab= ility of=20 a CDN to deliver=20 specific

content.  I certainly un= derstand=20 the case where a CSP will=20 restrict

the distribution of content t= o a=20 "managed path" if such content=20 is

HD while allowing the content= =20 distribution via an un-managed path=20 if

such content is SD (same coul= d apply=20 to encryption methods,=20 delivery

methods, etc.).  On the = contrary,=20 the dCDN may have its=20 own

restrictions of blocking the= =20 distribution of HD content=20 while

allowing the distribution of = SD=20 content.

 

o first bullet makes sense if= the dCDN=20 can perform a subset=20 of

encapsulations for a referenc= e set of=20 media (e.g. HLS, HSS, but=20 not

DASH) o second bullet makes s= ense=20 where the dCDN doesn't want=20 to

offer high bit-rate variants = of the=20 media o third bullet make=20 sense

if the policy addresses QoE b= ut I=20 don't think=20 subscriber

rights/authorizations=20 apply.

 

Section 10 Security=20 Considerations

 

Aside from the security consi= derations=20 WITHIN the uCDN and dCDN,=20 I

think we can describe this in= four=20 contexts:

 

a. The relationship between t= he CSP=20 and the uCDN (the principle=20 contract

arrangement for=20 distribution)

b. The relationship between t= he uCDN=20 and dCDN (the transitive=20 trust

relationship that extends the= contract=20 defined in (a) above) c.=20 The

relationship between the User= and dCDN=20 (the recognition of right=20 to

download predicated on (b) ab= ove) d.=20 The relationship between=20 the

User and CSP (the contract au= thorizing=20 the user access to=20 the

content)

 

The user is not interested in= the a-b=20 nor the b-c relationship.=20 The

user is only interested in th= e=20 transparency and interoperability=20 of

the security relationship bet= ween d-b=20 or d-c to the point that=20 the

authorization granted in d-a = is viable=20 when the delivery=20 is

initiated via either d-b or d= -c.=20  As an example, the uCDN might=20 use

URL appended tokens for authe= ntication=20 while dCDN might use=20 URL

appended hashes.  The us= er=20 doesn't want to know about the=20 distinct

methods, but transparency is = only=20 afforded if the methods=20 are

interoperable clearly defined= when the=20 delegation for=20 content

delivery is executed.  C= learly,=20 the choice of authentication method is determined by the respective=20 CDN's.

 

Scott

 

_______________________________________________

CDNi mailing=20 list

CDNi@ietf.org

=

https://www.ietf.= org/mailman/listinfo/cdni

 

_______________________________________________=

CDNi mailing=20 list

CDNi@ietf.org

https://www.ietf.or= g/mailman/listinfo/cdni

 


_______________________________________________
CDNi ma= iling=20 list
CDNi@ietf.org
https://www.ietf.org/ma= ilman/listinfo/cdni
_______________________________________________<= BR>CDNi=20 mailing list
CDNi@ietf.org
https://www.ietf.org/mai= lman/listinfo/cdni

 

--_000_1B6D0317D3AD964FBF3956DEFA3524D517108F46BCEUSAACMS0701e_-- From zahariad@synelixis.com Mon Oct 31 09:39:55 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3587711E80E6 for ; Mon, 31 Oct 2011 09:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.372 X-Spam-Level: ** X-Spam-Status: No, score=2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RDNS_NONE=0.1, SARE_FWDLOOK=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLpgcIYZpjay for ; Mon, 31 Oct 2011 09:39:42 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 68BD211E80DC for ; Mon, 31 Oct 2011 09:39:42 -0700 (PDT) Received: (qmail 17284 invoked by uid 0); 31 Oct 2011 16:39:42 -0000 Received: from unknown (HELO box521.bluehost.com) (74.220.219.121) by oproxy9.bluehost.com with SMTP; 31 Oct 2011 16:38:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=synelixis.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Reply-To; bh=nLfCJTzRen/b63Q0QW+y6A9dcHa5nAKpsEjViMmJRiY=; b=lhV+LBu42I3gYkOwDmTJLBjmEwRAl12ElPLk24nlZNHfXzBDxiWRdmfo8JJI81hjuxkWRgTG30DJW9wXjGd63UA3HOkg0+ubS31CjcpI32kfY0DDkXWMrLfbgjyqQDn2; Received: from [195.130.64.9] (helo=acer) by box521.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RKusq-0003gj-5N; Mon, 31 Oct 2011 10:38:50 -0600 From: "Theodore Zahariadis" To: "'Alan Kavanagh'" , "'Kent Leung \(kleung\)'" , "'Mark de Jong'" References: <20110922193639.11562.32240.idtracker@ietfa.amsl.com><4E8506FC.1020701@cisco.com><260A32EFD5C9EB47AD504929D005DF6245A694@SZXEML519-MBS.china.huawei.com><853F186F-7A10-4EEA-8460-606F20218F33@niven-jenkins.co.uk><9510D26531EF184D9017DF24659BB87F330C58F86A@EMV65-UKRD.domain1.systemhost.net><260A32EFD5C9EB47AD504929D005DF6245AA42@SZXEML519-MBS.china.huawei.com><1E5D2F7D-D855-4082-97EA-E609F089D4D3@niven-jenkins.co.uk><260A32EFD5C9EB47AD504929D005DF6245AD64@SZXEML519-MBS.china.huawei.com><166602C2-3084-4EED-A6DA-E772C4A72136@niven-jenkins.co.uk><1B6D0317D3AD964FBF3956DEFA3524D5170F26BB1D@EUSAACMS0701.eamcs.ericsson.se> <2979E38DD6FC6544B789C8DAD7BAFC521024D515@xmb-sjc-235.amer.cisco.com> <1B6D0317D3AD964FBF3956DEFA3524D5170F26BC34@EUSAACMS0701.eamcs.ericsson.se> <00bf01cc96f7$11feedf0$35fcc9d0$@com> <1B6D0317D3AD964FBF3956DEFA3524D517108F46BC@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D517108F46BC@EUSAACMS0701.eamcs.ericsson.se> Date: Mon, 31 Oct 2011 18:38:40 +0200 Organization: Synelixis Solutions Ltd Message-ID: <005301cc97eb$90e09d90$b2a1d8b0$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01CC97FC.54696D90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyUIr+HmTxXW9tSQVutk3w35YQ82wC0/Z7gADvMhzAAAEdkAA== Content-Language: el X-Identified-User: {712:box521.bluehost.com:synelixi:synelixis.com} {sentby:smtp auth 195.130.64.9 authed with zahariad@synelixis.com} Cc: cdni@ietf.org, yannick.lelouedec@orange.com, 'ZhouZhipeng' Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: zahariad@synelixis.com List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 16:39:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0054_01CC97FC.54696D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Alan, I also fully agree with your point. As the timeframe is rather short I think that both the Framework and the Metadata should be built around one document. However, the draft we have sent is the result of many discussions, PhC and research done by a large number of companies and participants from 6 project. So, I believe it is worth a discussion. Unfortunately, I'll not be able to participate at this IETF meeting, but our colleague Emile Stephan (Orange) will and he may present the draft. Of course there are two options: a) To try to merge the two documents towards a joined WG working document, which could be also the base for the Framework and the Metadata specification or b) Keep the one that you are already working on and just extend/update this one as forward looking one. In either case, I will be very happy to help and contribute. Best Regards, Theodore From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: Monday, October 31, 2011 6:03 PM To: zahariad@synelixis.com; 'Kent Leung (kleung)'; 'Mark de Jong' Cc: cdni@ietf.org; 'ZhouZhipeng' Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Theodore I do tend to agree with your point, though i would like one Use Case document as the baseline for which the Framework adn Metadata etc use to be built around. I do see the merit in taking on work that should be fullfilled within a given time limit and im all for that as long as we ensure all use cases are captured and not ignored. Im not too picky on where it should be done (current use case or another doc). Alan _____ From: Theodore Zahariadis [mailto:zahariad@synelixis.com] Sent: October-30-11 7:29 AM To: Alan Kavanagh; 'Kent Leung (kleung)'; 'Mark de Jong' Cc: cdni@ietf.org; 'ZhouZhipeng' Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Dear all, I think that a good approach would be to proceed in cdni-use cases to ensure realistic/short-term use cases and then proceed to the advanced use cases that the Future Media Networks (FMN) cluster of projects have submitted under the cdni-advanced-use-cases ID. Best Regards, Theodore From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com] Sent: Thursday, October 27, 2011 12:04 AM To: Kent Leung (kleung); Mark de Jong Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt So are we defining a limited set of use cases or should we ensure that use cases at the very least ensure that the realistic use cases both deployed today and ones planed are captured in the use cases document? Alan _____ From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: October-26-11 5:02 PM To: Mark de Jong; Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt I also agree with Ben that content adaptation is an optimization that is out of scope. We have enough to do in the WG already. Kent From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Mark de Jong Sent: Wednesday, October 26, 2011 1:21 PM To: Alan Kavanagh Cc: cdni@ietf.org; ZhouZhipeng Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Hi Alan, As Ben stated the overall discussion right now is about delivery, not on adaptation. It is hard enough to get consensus on the delivery aspect already not to mention your requirement from content adaptation added to that, so I agree with Ben we should stick with the delivery aspect for the first specs. I can imagine this could be a discussion later on but please let us keep the scope of this be clean and transparent. It is of benefit of everyone to get the first specs as fast as possible. Thanks. Met vriendelijke groet, Kind regards, Mark de Jong International Business Developer Jet-Stream BV E-mail: mark@jet-stream.com Office: +31 (0)50 5261820 Mobile: +31 (0)6 81108263 Fax: +31 (0)50 5264214 - Event: Meet us at Streaming Media Europe, 17-18 October, London, UK - Event: Meet us at Online Video Strategies, 19 October, London, UK - Event: Meet us at CDN World Summit, 25-28 October, London, UK - News: Pre-request your Technology Whitepaper now and be the first to have it, check www.jet-stream.com - News: Check http://www.jet-stream.com to download our 'Six Trends in CDNs' brochure - Blog: www.jet-stream.com/blog/ - VideoExchange: www.vdo-x.net - Streamzilla: www.streamzillacdn.com - Corporate: www.jet-stream.com On 26, Oct,2011, at 8:33 PM, Alan Kavanagh wrote: Ben Im assuming then based on your comments below are you suggesting we are going to have a number of versions of the CDN-I Metadata? I sympathise with what you are pointing out below and do agree that there is some work to be done, but I still feel that content adaptation is to me a fundamental requirement to what collectively we should address in the CDN-I WG. I do agree with you that content adaptation is an optimization between CDN's but it's a very important one that I know Network Service Providers particularly require. Alan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: October-12-11 1:13 PM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 12 Oct 2011, at 10:22, ZhouZhipeng wrote: Hello Ben, The UE may select the content format on the CP web. After that the user only desires to get his selected content. But how the content is transferred to the client is not worried by the user. The CP may create a special format as required by the user and ask the CDN to deliver to user. While CP may give a HD format content to uCDN and the dCDN may then transform to the format as the user select. Lots of things may be possible to do and CDN providers offer many additional services on top of the "core" service of content delivery. However, our objective (based on my interpretation of the CDNI charter) is to focus on what is necessary to interconnect CDNs to deliver content from a CSP to an End User that is targeted and deployable within a short time frame (18-24 months). Content transformation/adaptation is not an essential requirement in order to achieve that aim (we can deliver content from CSPs to End Users via multiple CDNs without needing or requiring any CDN supports content adaptation). In my opinion we have enough work to do already without trying to expand the scope of our work to include additional requirements that do not help us address our core objectives as laid out in the CDNI charter. In this case, it is nothing related to how the user select formats on CP website. So, it is the CP and user to decide the content format not the CDN(your assert is not correct and seems you take that assert as your base for the discussion). As for "the core CDN functionality offered by CDNs today", I have ever raised an email before that your company's webpage has claimed supporting media transformation and multi-screen service. Perhaps, I like asking you list some features that you feel are the core functionalities by existing main stream CDNs. Thus we may compare and take deep look. I think the core functionality maps pretty well to the CDNI interfaces, namely: Request Routing, Metadata configuration, log production and control plus content acquisition and content delivery. I guess many people have the experience/knowledge of content related service. The user and CP only care whether the CDN providers may satisfy their requirement while not care the internal process. Just as GSM/PSTN interconnection, the user only care successful interconnection while not care how the voice is transformed in process. Besides, I like raise a case: Given currently BBC recruits CDN providers that may support 10 media formats. One candidate is your company, another is CDN-X. The users are located in France. So both your company and CDN-X should connect a France CDN provider(CDN-Y). If your company's solution is to send 10 streams of different format of one content to CDN-Y; While CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct some adaptation. Comparing these two solutions, for your company and CDN-X, absolutely the cost of CDN-X is much lower. For CDN-Y, in solution-1, it should receive/forward 10 streams ; while in solution-2, it should only receive 1 stream but need to take transformation to output 10 streams. Which solution is more competitive. it is Solution 1, right. Remember the price from BBC is same to both your company and CDN-X or BBC would select one CDN provider with the lower price. If a CDN provider may not get the contract from CP, how it may say it is not a core functionality. What you are describing is a possible optimization that a particular CDN may wish to implement not a core functionality required to enable content delivery between interconnected CDNs. I can think of many optimizations that a CDN could implement to differentiate their service but the internal workings of an individual CDN are out of scope of our charter. So to repeat my position for a final time: Content adaptation is not a core function required to enable content delivery between interconnected CDNs and therefore given the workload we already have to specify solutions that do address the core functionality required to interconnect CDNs I do not think we should be trying to add more work into that workload as it will only distract us from achieving our goal of producing deployable solutions within the timeframe we are being told by operators they needs solutions within. Ben So, if we all realize that currently the media type is rich, the CDN providers should survive in the existing ecosystem and support the media types as required by the market. Back to the case of GSM/G.711, it just when concerning the interconnection, the transformation should at once be solved. Otherwise the interconnection may not be operated. Br, Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Wednesday, October 12, 2011 12:19 AM To: ZhouZhipeng Cc: philip.eardley@bt.com; cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Zhipeng, On 11 Oct 2011, at 05:16, ZhouZhipeng wrote: Ben and Philip, I like to respond your concern in this one email: Ben, I feel what we are now discussing is what is the "core" function of CDN. As you say, CDN is used to deliver content. That is absolutely correct that the delivery capability is the core requirement for CDN system. While CDN is used to provide the content delivery service. What means service. It should include "time" "location" and "media type", etc. These features are all the core feature for a service. If we only concern "delivering one data block", I am not sure whether the issues such as "logging" "geographic constraint" are the core of CDN. For "without explicit knowledge of what that content actually is ", I am not sure whether the wording is accurate since generally a CDN may claim it support different medias. By this opportunity, I like to share a use case: a call from a GSM phone to a PSTN telephone, the voice stream should be transformed from GSM voice to G.711. For the user, he does not need to know what type of data has been transferred, but the operator has done some work to interconnect two systems, right. I like to know whether you may accept that my use case is similar to this case above. I don't think your use case is similar to the analogy of mobile networks being interconnected to PSTN networks. In the case of content delivery the negotiation is done between the User/Client and the Content Provider and the CDN is just used to execute/perform the delivery that has been negotiated. The CDN is not involved in the decision making of what representations the Content Provider decides to offer to the User/Client or in what representations the User/Client decides to request. As for you said selecting media by the "portal", you may see the way " uCDN delivers multiple media streams to dCDN" is not good than "uCDN delivers one media stream to dCDN and dCDN takes some adaptation to support multiple media types". Now what you're talking about is an optimisation, not a core function required to actually deliver the content (and report, bill, etc. for that delivery). My position is that we should focus on how to enable the interconnection of the core CDN functionality offered by CDNs today (which is also my interpretation of the scope of the CDNI working group as expressed in its charter) because doing so is a significant piece of work in itself. Let's not start trying to add in additional functionality beyond what the majority of CDNs support today as that will just delay us getting usable specifications into the market in a timely fashion IMO. Ben A good question is "security" since I have done six years on the DRM and like to promote the DRM all around the world:) If the content is needed to be protected, generally you may know all the systems should be granted by the content owner. Here I also like to clarify that not only the media itself but the information related to service itself (such as the geographic constraint) should be protected also. So, trust is not a problem for the media. Philip, Thank you that you feel Content Adaption is an issue for "Requirements" but I do not know why it is not for Use case. I like to clarify to U that it is important for you operator since it may save investment if the system may support different services. For us vendor, we are happy operator may install a system for the mobile service and another system for the FBB service. But the reality is all operators ask us to provide a system that may support different service systems. Frankly, Ben and Philip, I remember I have explained somewhere that to implement this is rather simple . At least the Use case and Requirement are informational to be referred in future work. So I do really feel you may accept it. Of course I like to respond your more concern and comments. Thanks. Zhipeng -----Original Message----- From: philip.eardley@bt.com [mailto:philip.eardley@bt.com] Sent: Monday, October 10, 2011 11:22 PM To: ben@niven-jenkins.co.uk; ZhouZhipeng Cc: cdni@ietf.org Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Ben, Zhipeng, all, I think that Content Adaptation is more an issue for the Requirements doc than for the Use cases draft. The key question is whether we want the CDNI interfaces to be able to cope with a scenario where (say) HD/SD conversion is done in the dCDN & to signal about this. I think that coping with this scenario is a second order requirement, ie we should not worry about it in the initial standards-track work. I don't know, did we ever decide whether the Use cases doc is restricted to "initial" scenarios, or whether it's all-encompassing, ie covering "future" scenarios as well? Scott, Reading some of your examples, they seem to be valid even if content adaptation (HD/SD) is out of scope. - a dCDN might for some reason be unwilling to distribute HD? - a CSP might want to make sure the dCDN can use HLS encapsulation? But these sorts of examples seem to be static policy things (to do with the capabilities & preferences of the CDNs & CSP), rather than metadata associated with a particular piece of content. In the discussion so far, I think negotiation about static policy stuff is rather out of scope(?) On security considerations, an interesting question is whether trust is transitive. Don't think it need be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically trusts the dCDN. However, i suspect this can get arbitrarily complex - so one possibility is to say that we will only handle cases where the trust is transitive. Best wishes phil Philip Eardley Research and Technology Strategy This email contains BT information, which may be privileged or confidential. It's meant only for the individual(s) or entity named above. If you're not the intended recipient, note that disclosing, copying, distributing or using this information is prohibited. If you've received this email in error, please let me know immediately on the email address above. Thank you. We monitor our email system, and may record your emails. British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no: 1800000 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: 10 October 2011 12:04 To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Colleagues, IMO Section 5.1.3 should be removed from the Use Cases draft. Content Adaptation (i.e. taking in a content item in one format and transforming it to another format or representation) is not a "core" function of a CDN which typically delivers the content that is requested without explicit knowledge of what that content actually is. Let's not forget that in building an end to end content service the CDN is only one component and is the component tasked with executing the delivery of a specific representation (version/copy/format etc.) of the selected content not the component tasked with deciding (or applying policy) on which version/copy/representation of content should be delivered. The decision as to which version/copy/representation to offer and allow to be delivered to a given device/user is implemented outside of the CDN (e.g. by the "portal" where the user first makes their content selection prior to the CDN becoming involved in the delivery of the selected content). Ben On 8 Oct 2011, at 08:20, ZhouZhipeng wrote: Following Scott's comments on section 5.1.3, I feel Scott's description on the use case of HD and SD is not exactly correct. If one movie has two formats of HD and SD, then we have two content with different identifier. In DRM scope, the basic unit is a content copy. Here the first bullet "a subset of encodings deliverable to specific devices," has listed the case of content adaptation. In last month, I have contacted the Authors of this document and taken some email exchanges with Grant and Philip (BT). I have shown BT with some information that I know in this case and area to explain the content flexibility is currently a basic requirement for CDN service and related negotiation is needed in the CDN interconnection. Meanwhile, I should also invite you in this group raising your comments or questions on this case since I hope my use case may be incorporated in the use case draft. If you have any more question or comments, pls share in this thread. Thanks. Zhipeng -----Original Message----- From: Scott Wainner [mailto:swainner@cisco.com] Sent: Friday, September 30, 2011 8:02 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Section 2.3 Nomadic Users This description falls under the category of Geographic Extension yet the third paragraph states the case where a different device is used in the same CDN coverage area. The intent of this use case needs to be clarified. Perhaps the use case is trying to address the scenario where a Nomadic User-A with an agreement allowing access to content from CSP-A via uCDN moves to a dCDN in a different region. The dCDN is allowed to distribute the content of CSP-A to User-A; however, not other users in the region of the dCDN are allowed to retrieve the content unless they too have such an agreement. Section 5.1.3 Content Encoding Restrictions Need to clarify if we're talking about the restrictions on the delivery of specific content or the restrictions on the ability of a CDN to deliver specific content. I certainly understand the case where a CSP will restrict the distribution of content to a "managed path" if such content is HD while allowing the content distribution via an un-managed path if such content is SD (same could apply to encryption methods, delivery methods, etc.). On the contrary, the dCDN may have its own restrictions of blocking the distribution of HD content while allowing the distribution of SD content. o first bullet makes sense if the dCDN can perform a subset of encapsulations for a reference set of media (e.g. HLS, HSS, but not DASH) o second bullet makes sense where the dCDN doesn't want to offer high bit-rate variants of the media o third bullet make sense if the policy addresses QoE but I don't think subscriber rights/authorizations apply. Section 10 Security Considerations Aside from the security considerations WITHIN the uCDN and dCDN, I think we can describe this in four contexts: a. The relationship between the CSP and the uCDN (the principle contract arrangement for distribution) b. The relationship between the uCDN and dCDN (the transitive trust relationship that extends the contract defined in (a) above) c. The relationship between the User and dCDN (the recognition of right to download predicated on (b) above) d. The relationship between the User and CSP (the contract authorizing the user access to the content) The user is not interested in the a-b nor the b-c relationship. The user is only interested in the transparency and interoperability of the security relationship between d-b or d-c to the point that the authorization granted in d-a is viable when the delivery is initiated via either d-b or d-c. As an example, the uCDN might use URL appended tokens for authentication while dCDN might use URL appended hashes. The user doesn't want to know about the distinct methods, but transparency is only afforded if the methods are interoperable clearly defined when the delegation for content delivery is executed. Clearly, the choice of authentication method is determined by the respective CDN's. Scott _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni ------=_NextPart_000_0054_01CC97FC.54696D90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Alan,

 

I also fully agree with your point. As the timeframe is rather short = I think that both the Framework and the Metadata should be built around = one document.

 

However, the draft we have sent is the result of many discussions, = PhC and research done by a large number of companies and participants = from 6 project.

So, I believe it is worth a discussion. Unfortunately, I’ll not = be able to participate at this IETF meeting, but our colleague Emile = Stephan (Orange) will and he may present the = draft.

Of course there are two options:

a)      = To try to merge the two documents towards a joined WG working = document, which could be also the base for the Framework and the = Metadata specification or

b)      = Keep the one that you are already working on and just extend/update = this one as forward looking one.

In either case, I will be very happy to help and = contribute.

 

Best Regards,

Theodore

 

 

 

 

From:= Alan = Kavanagh [mailto:alan.kavanagh@ericsson.com]
Sent: Monday, = October 31, 2011 6:03 PM
To: zahariad@synelixis.com; 'Kent = Leung (kleung)'; 'Mark de Jong'
Cc: cdni@ietf.org; = 'ZhouZhipeng'
Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Hi= Theodore

 

I = do tend to agree with your point, though i would like one Use Case = document as the baseline for which the Framework adn Metadata etc use to = be built around. I do see the merit in taking on work that should be = fullfilled within a given time limit and im all for that as long as we = ensure all use cases are captured and not ignored. Im not too picky on = where it should be done (current use case or another = doc).

 

Al= an

 

From:= Theodore = Zahariadis [mailto:zahariad@synelixis.com]
Sent: = October-30-11 7:29 AM
To: Alan Kavanagh; 'Kent Leung = (kleung)'; 'Mark de Jong'
Cc: cdni@ietf.org; = 'ZhouZhipeng'
Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

Dear all,

 

I think that a good approach would be to proceed in cdni-use cases to = ensure realistic/short-term use cases and then proceed to the advanced = use cases that the Future Media Networks (FMN) cluster of projects have = submitted under the cdni-advanced-use-cases ID.

 

Best Regards,

Theodore

 

 

From:= = Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]
Sent: = Thursday, October 27, 2011 12:04 AM
To: Kent Leung (kleung); = Mark de Jong
Cc: cdni@ietf.org; ZhouZhipeng
Subject: = Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

So= are we defining a limited set of use cases or should we ensure that use = cases at the very least ensure that the realistic use cases both = deployed today and ones planed are captured in the use cases document? =

 

Al= an

 

From:= Kent Leung = (kleung) [mailto:kleung@cisco.com]
Sent: October-26-11 5:02 = PM
To: Mark de Jong; Alan Kavanagh
Cc: = cdni@ietf.org; ZhouZhipeng
Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

I also agree with Ben that content adaptation is an optimization that = is out of scope.  We have enough to do in the WG = already.

 

Kent

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Mark de Jong
Sent: Wednesday, October 26, 2011 1:21 = PM
To: Alan Kavanagh
Cc: cdni@ietf.org; = ZhouZhipeng
Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Hi = Alan,

 

As Ben stated the overall = discussion right now is about delivery, not on adaptation. It is hard = enough to get consensus on the delivery aspect already not to mention = your requirement from content adaptation added to that, so I agree with = Ben we should stick with the delivery aspect for the first specs. I = can imagine this could be a discussion later on but please let us keep = the scope of this be clean and transparent. It is of benefit of everyone = to get the first specs as fast as possible. = Thanks.

 

<= div>

= Met vriendelijke groet,

= Kind regards,=

Mark de Jong
International Business = Developer
Jet-Stream = BV

E-mail: mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214

<= o:p> 

= - Event:=  = Meet us at Streaming Media Europe, 17-18 October, London, = UK

= - Event:=  Meet us at Online Video Strategies, 19 October, London, = UK

= - Event:=  Meet us at CDN World Summit, 25-28 October, London, = UK

= -=  = News:=  Pre-request your Technology Whitepaper now and be the first to = have it, check www.jet-stream.com

= - News: Check http://www.jet-stream.com to = download our 'Six Trends in CDNs' brochure

 

= -=  = Blog:=  = www.jet-stream.com/blog/

= -=  = VideoExchange:=  = www.vdo-x.net

= -=  = Streamzilla:=  = www.streamzillacdn.com<= /span>

= -=  = Corporate:=  = www.jet-stream.com

=
<= p class=3DMsoNormal> 

On 26, Oct,2011, at 8:33 PM, Alan = Kavanagh wrote:

 

Ben

Im assuming = then based on your comments below are you suggesting we are going to = have a number of versions of the CDN-I Metadata?

I sympathise = with what you are pointing out below and do agree that there is some = work to be done, but I still feel that content adaptation is to me a = fundamental requirement to what collectively we should address in the = CDN-I WG. I do agree with you that content adaptation is an optimization = between CDN's but it's a very important one that I know Network Service = Providers particularly require.

Alan

-----Original = Message-----
From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
Sent: = October-12-11 1:13 PM
To: ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] = I-D Action: draft-ietf-cdni-use-cases-00.txt

Zhipeng,

On = 12 Oct 2011, at 10:22, ZhouZhipeng wrote:

Hello = Ben,

The UE may select the content = format on the CP web. After that the user only desires to get his = selected content.

But how the content is transferred = to the client is not worried by the = user.

The CP may create a special format = as required by the user and ask the CDN to deliver to = user.

While CP may give a HD format = content to uCDN and the dCDN may then transform to the format as the = user select.


Lots of things may = be possible to do and CDN providers offer many additional services on = top of the "core" service of content delivery. However, our = objective (based on my interpretation of the CDNI charter) is to focus = on what is necessary to interconnect CDNs to deliver content from a CSP = to an End User that is targeted and deployable within a short time frame = (18-24 months).

Content transformation/adaptation is not an = essential requirement in order to achieve that aim (we can deliver = content from CSPs to End Users via multiple CDNs without needing or = requiring any CDN supports content adaptation).

In my opinion we = have enough work to do already without trying to expand the scope of our = work to include additional requirements that do not help us address our = core objectives as laid out in the CDNI charter.

In this case, it is nothing related = to how the user select formats on CP = website.

So, it is the CP and user to decide = the content format not the CDN(your assert is not correct and seems you = take that assert as your base for the = discussion).

 

As for "the core CDN = functionality offered by CDNs today", I have ever raised an email = before that your company's webpage has claimed supporting media = transformation and multi-screen = service.

Perhaps, I like asking you list = some features that you feel are the core functionalities by existing = main stream CDNs. Thus we may compare and take deep = look.


I think the core = functionality maps pretty well to the CDNI interfaces, namely: Request = Routing, Metadata configuration, log production and control plus content = acquisition and content delivery.

I guess many people have the = experience/knowledge of content related service. The user and CP only = care whether the CDN providers may satisfy their requirement while not = care the internal process. Just as GSM/PSTN interconnection, the user = only care successful interconnection while not care how the voice is = transformed in process.

 

Besides, I like raise a = case:

Given currently BBC recruits CDN = providers that may support 10 media = formats.

One candidate is your company, = another is CDN-X. The users are located in = France.

So both your company and CDN-X = should connect a France CDN = provider(CDN-Y).

If your company's solution is to = send 10 streams of different = format

of one content to CDN-Y; While = CDN-X's solution is to send 1 stream to CDN-Y while CDN-Y may conduct = some adaptation.

Comparing these two solutions, for = your company and CDN-X, absolutely the cost of CDN-X is much = lower.

For CDN-Y, in solution-1, it should = receive/forward 10 streams ; while in solution-2, it should only receive = 1 stream but need to take transformation to output 10 = streams.

 

Which solution is more competitive. = it is Solution 1, right. Remember the price from BBC is same to both = your company and CDN-X or BBC would select one CDN provider with the = lower price.

If a CDN provider may not get the = contract from CP, how it may say it is not a core = functionality.


What you are = describing is a possible optimization that a particular CDN may wish to = implement not a core functionality required to enable content delivery = between interconnected CDNs. I can think of many optimizations that a = CDN could implement to differentiate their service but the internal = workings of an individual CDN are out of scope of our charter.

So = to repeat my position for a final time: Content adaptation is not a core = function required to enable content delivery between interconnected CDNs = and therefore given the workload we already have to specify solutions = that do address the core functionality required to interconnect CDNs I = do not think we should be trying to add more work into that workload as = it will only distract us from achieving our goal of producing deployable = solutions within the timeframe we are being told by operators they needs = solutions within.

Ben

So, if we all realize that = currently the media type is rich, the CDN providers should survive in = the existing ecosystem and support the media types as required by the = market.

 

Back to the case of GSM/G.711, it = just when concerning the interconnection, the transformation should at = once be solved. Otherwise the interconnection may not be = operated.

 

Br,

Zhipeng

 

 

 

 

-----Original = Message-----

From: Ben Niven-Jenkins = [mailto:ben@niven-jenkins.co.uk]

Sent: Wednesday, October 12, 2011 = 12:19 AM

To: = ZhouZhipeng

Cc: philip.eardley@bt.com; cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Zhipeng,

 

On 11 Oct 2011, at 05:16, = ZhouZhipeng wrote:

 

Ben and = Philip,

I like to respond your concern in = this one = email:

 

Ben,

I feel what we are now discussing = is what is the "core" function of = CDN.

As you say, CDN is used to deliver = content. That is absolutely correct that the delivery capability is the = core requirement for CDN = system.

While CDN is used to provide the = content delivery = service.

What means service. It should = include "time" "location" and "media = type", etc. These features are all the core feature for a = service.

If we only concern "delivering = one data block", I am not sure whether the issues such as = "logging" "geographic constraint" are the core of = CDN.

 

For "without explicit = knowledge of what that content actually is ", I am not sure whether = the wording is accurate since generally a CDN may claim it support = different = medias.

By this opportunity, I like to = share a use case: a call from a GSM phone to a PSTN telephone, the voice = stream should be transformed from GSM voice to = G.711.

For the user, he does not need to = know what type of data has been transferred, but the operator has done = some work to interconnect two systems, = right.

I like to know whether you may = accept that my use case is similar to this case = above.

 

I don't think your use case is = similar to the analogy of mobile networks being interconnected to PSTN = networks. In the case of content delivery the negotiation is done = between the User/Client and the Content Provider and the CDN is just = used to execute/perform the delivery that has been negotiated. The CDN = is not involved in the decision making of what representations the = Content Provider decides to offer to the User/Client or in what = representations the User/Client decides to = request.

 

As for you said selecting media by = the "portal", you may see the way " uCDN delivers = multiple media streams to dCDN" is not good than "uCDN = delivers one media stream to dCDN and dCDN takes some adaptation to = support multiple media = types".

 

Now what you're talking about is an = optimisation, not a core function required to actually deliver the = content (and report, bill, etc. for that = delivery).

 

My position is that we should focus = on how to enable the interconnection of the core CDN functionality = offered by CDNs today (which is also my interpretation of the scope of = the CDNI working group as expressed in its charter) because doing so is = a significant piece of work in itself. Let's not start trying to add in = additional functionality beyond what the majority of CDNs support today = as that will just delay us getting usable specifications into the market = in a timely fashion IMO.

 

Ben

 

A good question is = "security" since I have done six years on the = DRM

and like to promote the DRM all = around the world:) If the content is needed to be protected, generally = you may know all the systems should be granted by the content = owner.

Here I also like to clarify that = not only the media itself but the information related to service itself = (such as the geographic constraint) should be protected = also.

So, trust is not a problem for the = media.

 

Philip,

Thank you that you feel Content = Adaption is an issue for "Requirements" but I do not know why = it is not for Use = case.

I like to clarify to U that it is = important for you operator since it may save investment if the system = may support different = services.

For us vendor, we are happy = operator may install a system for the mobile service and another system = for the FBB = service.

But the reality is all operators = ask us to provide a system that may support different service = systems.

 

Frankly, Ben and Philip, I remember = I have explained somewhere that to implement this is rather simple = .

At least the Use case and = Requirement are informational to be referred in future work. So I do = really feel you may accept = it.

Of course I like to respond your = more concern and = comments.

Thanks.

Zhipeng

 

 

 

-----Original = Message-----

From: philip.eardley@bt.com = [mailto:philip.eardley@bt.com]

Sent: Monday, October 10, 2011 = 11:22 PM

To: ben@niven-jenkins.co.uk; = ZhouZhipeng

Cc: cdni@ietf.org

Subject: RE: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Ben, Zhipeng, = all,

 

I think that Content Adaptation is = more an issue for the Requirements doc than for the Use cases = draft.

 

The key question is whether we want = the CDNI interfaces to be able to cope with a scenario where (say) HD/SD = conversion is done in the dCDN & to signal about = this.

 

I think that coping with this = scenario is a second order requirement, ie we should not worry about it = in the initial standards-track work. I don't know, did we ever decide = whether the Use cases doc is restricted to "initial" = scenarios, or whether it's all-encompassing, ie covering = "future" scenarios as = well?

 

Scott,

Reading some of your examples, they = seem to be valid even if content adaptation (HD/SD) is out of = scope.

- a dCDN might for some reason be = unwilling to distribute = HD?

- a CSP might want to make sure the = dCDN can use HLS = encapsulation?

But these sorts of examples seem to = be static policy things (to = do

with the capabilities & = preferences of the CDNs & CSP), rather = than

metadata associated with a = particular piece of content. In = the

discussion so far, I think = negotiation about static policy stuff = is

rather out of = scope(?)

 

On security considerations, an = interesting question is whether trust is transitive. Don't think it need = be - just because CSP trusts uCDN, and uCDN trusts dCDN doesn't mean = that the CSP automatically trusts the dCDN. However, i suspect this can = get arbitrarily complex - so one possibility is to say that we will only = handle cases where the trust is = transitive.

 

Best = wishes

phil

 

 

Philip = Eardley

Research and Technology = Strategy

 

This email contains BT information, = which may be privileged or confidential. It's meant only for the = individual(s) or entity named above. If you're not the intended = recipient, note that disclosing, copying, distributing or using this = information is prohibited. If you've received this email in error, = please let me know immediately on the email address above. Thank you. We = monitor our email system, and may record your = emails.

British Telecommunications = plc

Registered office: 81 Newgate = Street London EC1A 7AJ Registered = in

England no: = 1800000

 

 

-----Original = Message-----

From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On = Behalf

Of Ben = Niven-Jenkins

Sent: 10 October 2011 = 12:04

To: = ZhouZhipeng

Cc: cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Colleagues,

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

 

IMO Section 5.1.3 should be removed = from the Use Cases draft. Content Adaptation (i.e. taking in a content = item in one format and transforming it to another format or = representation) is not a "core" function of a CDN which = typically delivers the content that is requested without explicit = knowledge of what that content actually = is.

 

Let's not forget that in building = an end to end content service the CDN is only one component and is the = component tasked with executing the delivery of a specific = representation (version/copy/format etc.) of the selected content not = the component tasked with deciding (or applying policy) on which = version/copy/representation of content should be = delivered.

 

The decision as to which = version/copy/representation to offer and allow to be delivered to a = given device/user is implemented outside of the CDN (e.g. by the = "portal" where the user first makes their content selection = prior to the CDN becoming involved in the delivery of the selected = content).

 

Ben

 

On 8 Oct 2011, at 08:20, = ZhouZhipeng = wrote:

 

Following Scott's comments on = section 5.1.3, I feel Scott's description on the use case of HD and SD = is not exactly = correct.

If one movie has two formats of HD = and SD, then we have two content with different identifier. In DRM = scope, the basic unit is a content = copy.

 

Here the first bullet "a = subset of encodings deliverable to specific devices," has listed = the case of content = adaptation.

<= blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'>

In last month, I have contacted the = Authors of this document and taken some email exchanges with Grant and = Philip = (BT).

I have shown BT with some = information that I know in this case and area to explain the content = flexibility is currently a basic requirement for CDN service and related = negotiation is needed in the CDN = interconnection.

Meanwhile, I should also invite you = in this group raising your comments or questions on this case since I = hope my use case may be incorporated in the use case = draft.

 

If you have any more question or = comments, pls share in this = thread.

Thanks.

Zhipeng

 

 

 

 

 

 

-----Original = Message-----

=

From: Scott Wainner = [mailto:swainner@cisco.com]

Sent: Friday, September 30, 2011 = 8:02 = AM

To: cdni@ietf.org

Subject: Re: [CDNi] I-D Action: = draft-ietf-cdni-use-cases-00.txt

 

Section 2.3 Nomadic = Users

This description falls under the = category of Geographic = Extension

yet the third paragraph states the = case where a different device = is

used in the same CDN coverage area. =  The intent of this use = case

needs to be clarified. =  Perhaps the use case is trying to = address

the scenario where a Nomadic User-A = with an agreement = allowing

access to content from CSP-A via = uCDN moves to a dCDN in a = different

region.  The dCDN is allowed = to distribute the content of CSP-A = to

User-A; however, not other users in = the region of the dCDN = are

allowed to retrieve the content = unless they too have such an = agreement.

 

Section 5.1.3 Content Encoding = Restrictions Need to clarify if = we're

talking about the restrictions on = the delivery of specific = content

or the restrictions on the ability = of a CDN to deliver = specific

content.  I certainly = understand the case where a CSP will = restrict

the distribution of content to a = "managed path" if such content = is

HD while allowing the content = distribution via an un-managed path = if

such content is SD (same could = apply to encryption methods, = delivery

methods, etc.).  On the = contrary, the dCDN may have its = own

restrictions of blocking the = distribution of HD content = while

allowing the distribution of SD = content.

 

o first bullet makes sense if the = dCDN can perform a subset = of

encapsulations for a reference set = of media (e.g. HLS, HSS, but = not

DASH) o second bullet makes sense = where the dCDN doesn't want = to

offer high bit-rate variants of the = media o third bullet make = sense

if the policy addresses QoE but I = don't think = subscriber

rights/authorizations = apply.

 

Section 10 Security = Considerations

 

Aside from the security = considerations WITHIN the uCDN and dCDN, = I

think we can describe this in four = contexts:

 

a. The relationship between the CSP = and the uCDN (the principle = contract

arrangement for = distribution)

b. The relationship between the = uCDN and dCDN (the transitive = trust

relationship that extends the = contract defined in (a) above) c. = The

relationship between the User and = dCDN (the recognition of right = to

download predicated on (b) above) = d. The relationship between = the

User and CSP (the contract = authorizing the user access to = the

content)

 

The user is not interested in the = a-b nor the b-c relationship. = The

user is only interested in the = transparency and interoperability = of

the security relationship between = d-b or d-c to the point that = the

authorization granted in d-a is = viable when the delivery = is

initiated via either d-b or d-c. =  As an example, the uCDN might = use

URL appended tokens for = authentication while dCDN might use = URL

appended hashes.  The user = doesn't want to know about the = distinct

methods, but transparency is only = afforded if the methods = are

interoperable clearly defined when = the delegation for = content

delivery is executed. =  Clearly, the choice of authentication method is determined by the = respective = CDN's.

 

Scott

 

_______________________________________________

CDNi mailing = list

CDNi@ietf.org

https://www.ietf.org/= mailman/listinfo/cdni

=

 

_______________________________________________

CDNi mailing = list

CDNi@ietf.org

https://www.ietf.org/= mailman/listinfo/cdni

=

 


_______________________________________________
CDNi = mailing list
CDNi@ietf.org
https://www.ietf.org/= mailman/listinfo/cdni
____________________________________________= ___
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/m= ailman/listinfo/cdni

 

------=_NextPart_000_0054_01CC97FC.54696D90-- From bdavie@cisco.com Mon Oct 31 12:24:59 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 696D711E812A for ; Mon, 31 Oct 2011 12:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdD2719F9wLM for ; Mon, 31 Oct 2011 12:24:58 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4C54211E80CB for ; Mon, 31 Oct 2011 12:24:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bdavie@cisco.com; l=5840; q=dns/txt; s=iport; t=1320089098; x=1321298698; h=from:mime-version:subject:date:references:cc:to: message-id; bh=SEC6mDn2CNZCr48WXRU3ZfrvJWRepVBjknsjlGDpVZ8=; b=Y040Kbcif9Lwk2bagYal+9ox/0TpD0WlwDj2EOan2UYDMgN1oYhubjC5 LGv8Wer3HnOrriECBjaTml7ZbbrUhHmU+W2BUhIrRmhP+BkySZZaBuAJW 34hOAfcqhty9VJwJ3iJytK+580B3tpUWoQQxS+JoRKBMPCphCyq01jW8S U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMHAPv0rk6rRDoJ/2dsb2JhbABDmiaPD4EFgXIBAQEBAgESAV8FAgULHAMBAi9NAggZIodglWEBnj2IIWEElA6Rew X-IronPort-AV: E=Sophos;i="4.69,433,1315180800"; d="scan'208,217";a="11481081" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 31 Oct 2011 19:24:45 +0000 Received: from dhcp-161-44-173-105.cisco.com (dhcp-161-44-173-105.cisco.com [161.44.173.105]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p9VJOiHU002273; Mon, 31 Oct 2011 19:24:44 GMT From: Bruce Davie Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-77-331984470 Date: Mon, 31 Oct 2011 15:24:44 -0400 References: <20111031192301.18956.17387.idtracker@ietfa.amsl.com> To: cdni@ietf.org Message-Id: <0031646E-1F32-4AAC-BF36-5C723B9141A1@cisco.com> X-Mailer: Apple Mail (2.1084) Subject: [CDNi] Fwd: New Version Notification for draft-davie-cdni-framework-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 19:24:59 -0000 --Apple-Mail-77-331984470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I presented version -00 of this draft in Quebec City. Please post = comments to the list. Regards, Bruce Davie Begin forwarded message: > From: internet-drafts@ietf.org > Date: October 31, 2011 3:23:01 PM EDT > To: bsd@cisco.com > Cc: lpeterson@verivue.com, bsd@cisco.com > Subject: New Version Notification for = draft-davie-cdni-framework-01.txt >=20 > A new version of I-D, draft-davie-cdni-framework-01.txt has been = successfully submitted by Bruce Davie and posted to the IETF repository. >=20 > Filename: draft-davie-cdni-framework > Revision: 01 > Title: Framework for CDN Interconnection > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 52 >=20 > Abstract: > This document presents a framework for Content Distribution Network > Interconnection (CDNI). The purpose of the framework is to provide > an overall picture of the problem space of CDNI and to describe the > relationships among the various components necessary to interconnect > CDNs. CDN Interconnection requires the specification of several > interfaces and mechanisms to address issues such as request routing, > metadata exchange, and the acquisition of content by one CDN from > another. The intent of this document is to outline what each > interface needs to accomplish, and to describe how these interfaces > and mechanisms fit together, while leaving their detailed > specification to other documents. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail-77-331984470 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = presented version -00 of this draft in Quebec City. Please post comments = to the list.

Regards,
Bruce = Davie


Begin forwarded message:

Date: October 31, 2011 3:23:01 PM EDT
Subject: New Version = Notification for = draft-davie-cdni-framework-01.txt

A new = version of I-D, draft-davie-cdni-framework-01.txt has been successfully = submitted by Bruce Davie and posted to the IETF = repository.

Filename: = draft-davie-cdni-framework
Revision: 01
Title: = Framework for CDN Interconnection
Creation date: = 2011-10-31
WG ID: Individual Submission
Number = of pages: 52

Abstract:
  This document presents a = framework for Content Distribution Network
=   Interconnection (CDNI).  The purpose of the framework = is to provide
  an overall picture of the problem space of = CDNI and to describe the
  relationships among the various = components necessary to interconnect
  CDNs.  CDN = Interconnection requires the specification of several
=   interfaces and mechanisms to address issues such as request = routing,
  metadata exchange, and the acquisition of = content by one CDN from
  another.  The intent of = this document is to outline what each
  interface needs to = accomplish, and to describe how these interfaces
  and = mechanisms fit together, while leaving their detailed
=   specification to other documents.




The = IETF Secretariat

= --Apple-Mail-77-331984470-- From emile.stephan@orange.com Mon Oct 31 15:36:33 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B321F0D25 for ; Mon, 31 Oct 2011 15:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBqzO-KdFD8l for ; Mon, 31 Oct 2011 15:36:30 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4F38B1F0D30 for ; Mon, 31 Oct 2011 15:36:30 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0DDF19B0002; Mon, 31 Oct 2011 23:37:31 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 019BB9B0001; Mon, 31 Oct 2011 23:37:31 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 31 Oct 2011 23:36:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC981D.876EBC8B" Date: Mon, 31 Oct 2011 23:36:23 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201FE4F05@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136D0BEA@PACDCEXMB05.cable.comcast.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Control and Metadata interfaces Thread-Index: AQHMlVbjkrelRHW/30KgzwKHb064PJWRtmZAgATCMZA= References: <78BCE9D8-7C4F-4162-9F6B-867240993EE1@cisco.com> <1CA25301D2219F40B3AA37201F0EACD1136D0BEA@PACDCEXMB05.cable.comcast.com> From: To: , , X-OriginalArrivalTime: 31 Oct 2011 22:36:29.0376 (UTC) FILETIME=[88383400:01CC981D] Subject: [CDNi] Control and Metadata interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 22:36:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC981D.876EBC8B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi =20 in draft-stephan-cdni-usecases-metadata-00 we identify situations which = require the support and the activation of RRi, Ca or Log features either = on the fly or in batch. Their selection and their activation require = information from the control interface (examples: Mi, RRi, Ca, Log = server's addresses) and from the metadata interface (example: content = distribution policies). We made some assumptions on the bootstrapping = and then considered that the elements of information of the control = interface were present in the metadata objects too (examples: = purge_mode flag, CAi server for an specific option of a feature ...). =20 =20 In fact there is a big overlapping between these 2 interfaces. Section = 4.5 of draft-davie-cdni-framework-00 and section 5 of = draft-caulfield-cdni-metadata-core-00 identify the same open issue. =20 Hence I propose the following:=20 - The control interface is split in 2 parts:=20 o bootstrapping of the CDN interconnexion; o control of the contents distribution; - The control of the contents distribution and the Metadata = interface share the same framework (datamodel parts, protocols...); - The framework document specifies precisely the bootstrapping = operations and the framework; =20 Regards Emile =20 =20 De : cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de = Woundy, Richard Envoy=E9 : vendredi 28 octobre 2011 15:07 =C0 : Francois Le Faucheur; cdni@ietf.org Objet : Re: [CDNi] Content Adaptation =20 I agree with Francois, both as co-chair and an individual. J =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Francois Le Faucheur Sent: Friday, October 28, 2011 5:49 AM To: cdni@ietf.org Subject: [CDNi] Content Adaptation =20 Folks, Speaking as a co-chair. I have been through the recent exchange on content adaptation (aka the = poorly-titled "Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt" = thread) and wanted to share a few thoughts. First, some messages might have given the impression that content = adaptation was required for a CDNI solution to be able to deal with = multiple types of terminal/resolution/sizes etc. So at the risk of = restating the obvious, let's be very explicit that this is obviously not = the case. A very simple/common way to support multiple types of = terminal/resolution/sizes in one CDN, or in a multi-CDN environment, is = to have different contents/URIs for each profile. So content adaptation is not _required_ to be supported by CDNI, but is = a candidate optimisation to do some of the same things in a different = way. Second, some messages suggested that content adaptation was a very = strong win (aka transfer 1 flow instead of 10 flows across CDNs). As = Richard pointed out already, this ignores a number of considerations = such as the cost associated with performing the actual content = adaptation downstream. Anyways, I think content adaptation may be better = seen as a trade-off that can indeed be positive in some environments, = rather than an obvious huge win. Also, without the content adaptation optimization, while the content = maybe passed across CDNs multiple times (in different formats), it is = worth noting that the smaller res/size/quality representations may = actually amount to much smaller size/bandwidth than the highest = res/size/quality, so it is not quite a multiplying factor.=20 Lastly, while the content adaptation optimization may reduce further the = inter-CDN transfer from 1-10 flows down to 1 flow, the base CDNI = solution allows a content to be transferred across CDNS 1-10 times total = instead of once per user accessing the content (as would be the case if = the uCDN pumps the same traffic to every users because it cannot = interoperate with the dCDN) which can result in a gain factor of 10s, = 100s, 1000s,..... I have the impression that the key arguments have now been exposed (some = of them even repeatedly) through the long thread. So I would suggest to = pause that discussion, unless _new_ arguments need to be brought into = the discussion, and then we can poll for consensus in Taipei and then on = the list. Thanks Francois PS: Please think of using specific Subject lines for the various threads = and don't hesitate to branch off with a different "Subject" when an = initial thread morphs into a different topic. This helps the discussion. =20 ------_=_NextPart_001_01CC981D.876EBC8B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

in draft-stephan-cdni-usecases-metadata-00 we identify situations = which require the support and the activation of RRi, Ca or Log features = either on the fly or in batch. Their selection and their activation = require information from the control interface (examples: Mi, RRi, Ca, = Log server’s addresses) and from the metadata interface (example: = content distribution policies). We made some assumptions=A0 on the = bootstrapping and then considered that the elements of information of = the control interface were present in the =A0metadata objects too = (examples: purge_mode flag, CAi server for an specific option of a = feature …). =A0=A0

 

In fact there is a big overlapping between these 2 interfaces. = Section 4.5 of draft-davie-cdni-framework-00 and =A0section 5 of = draft-caulfield-cdni-metadata-core-00 identify the same open = issue.

 

Hence I propose the following:

-          = The control interface is split in 2 parts:

o   bootstrapping of the CDN interconnexion;

o   control of the contents distribution;

-          = The control of the contents distribution and the Metadata interface = share the same framework (datamodel parts, = protocols…);

-          = The framework document specifies precisely the bootstrapping = operations and the framework;

 

Regards

Emile

 

 

De : = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de Woundy, Richard
Envoy=E9 : vendredi 28 octobre = 2011 15:07
=C0 : Francois Le Faucheur; = cdni@ietf.org
Objet : Re: [CDNi] Content = Adaptation

 

I agree with Francois, both as co-chair and an individual. = J

 

From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Francois Le Faucheur
Sent: Friday, October 28, 2011 5:49 = AM
To: cdni@ietf.org
Subject: [CDNi] Content = Adaptation

 

Folks,

Speaking as a co-chair.

I have been = through the recent exchange on content adaptation (aka the poorly-titled = "Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt" = thread) and wanted to share a few thoughts.

First, some messages = might have given the impression that content adaptation was required for = a CDNI solution to be able to deal with multiple types of = terminal/resolution/sizes etc. So at the risk of restating the obvious, = let's be very explicit that this is obviously not the case. A very = simple/common way to support multiple types of terminal/resolution/sizes = in one CDN, or in a multi-CDN environment, is to have different = contents/URIs for each profile.
So content adaptation is not = _required_ to be supported by CDNI, but is a candidate optimisation to = do some of the same things in a different way.

Second, some = messages suggested that content adaptation was a very strong win (aka = transfer 1 flow instead of 10 flows across CDNs). As Richard pointed out = already, this ignores a number of considerations such as the cost = associated with performing the actual content adaptation downstream. = Anyways, I think content adaptation may be better seen as a trade-off = that can indeed be positive in some environments, rather than an obvious = huge win.

Also, without the content adaptation optimization, while = the content maybe passed across CDNs multiple times (in different = formats), it is worth noting that the smaller res/size/quality = representations may actually amount to much smaller size/bandwidth than = the highest res/size/quality, so it is not quite a multiplying = factor. 
Lastly, while the content adaptation optimization may = reduce further the inter-CDN transfer from 1-10 flows down to  1 = flow, the base CDNI solution allows a content to be transferred across = CDNS 1-10 times total instead of once per user accessing the content (as = would be the case if the uCDN pumps the same traffic to every users = because it cannot interoperate with the dCDN) which can result in a = gain factor of 10s, 100s, = 1000s,.....


I have the impression that the = key arguments have now been exposed (some of them even repeatedly) = through the long thread. So I would suggest to pause that discussion, = unless _new_ arguments need to be brought into the discussion, and then = we can poll for consensus in Taipei and then on the = list.

Thanks

Francois

PS: Please think of using = specific Subject lines for the various threads and don't hesitate to = branch off with a different "Subject" when an initial thread = morphs into a different topic. This helps the = discussion.

 

------_=_NextPart_001_01CC981D.876EBC8B-- From kevin.ma@azukisystems.com Mon Oct 31 16:36:43 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D9421F8E6F for ; Mon, 31 Oct 2011 16:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4VWwbGYcNoe for ; Mon, 31 Oct 2011 16:36:43 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9158E21F8E71 for ; Mon, 31 Oct 2011 16:36:42 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 202288BDB23 for ; Mon, 31 Oct 2011 19:36:42 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB028.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id B6E108BD97A for ; Mon, 31 Oct 2011 19:36:41 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB028.mail.lan ([10.110.17.28]) with mapi; Mon, 31 Oct 2011 19:36:23 -0400 From: Kevin J Ma To: "cdni@ietf.org" Date: Mon, 31 Oct 2011 19:36:39 -0400 Thread-Topic: New Version Notification for draft-ma-cdni-metadata-01.txt Thread-Index: AcyYJBmMY8Bw7e5LSai/Do6RDtbqsQAAGxFg Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6A69184@MAILR002.mail.lan> References: <20111031232338.28460.6679.idtracker@ietfa.amsl.com> In-Reply-To: <20111031232338.28460.6679.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-ma-cdni-metadata-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:36:43 -0000 QW4gdXBkYXRlZCB2ZXJzaW9uIG9mIGRyYWZ0LW1hLWNkbmktbWV0YWRhdGEgaGFzIGJlZW4gdXBs b2FkZWQuDQpJdCBmaXhlcyBzb21lIHR5cG9zLCBpbmNvcnBvcmF0ZXMgc29tZSBvZiB0aGUgY29t bWVudHMgcmVjZWl2ZWQNCmZyb20gdGhlIGxpc3QsIGFuZCBhZGRzIHNvbWUgY29yZSBtZXRhZGF0 YSBkZWZpbml0aW9ucy4NCg0KY29tbWVudHMgd2VsY29tZS4NCg0KdGhhbnguDQoNCi0tICBLZXZp biBKLiBNYQ0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tYS1jZG5pLW1ldGFkYXRh LTAxLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEtldmluIE1hIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1tYS1jZG5p LW1ldGFkYXRhDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBDb250ZW50IERpc3RyaWJ1dGlvbiBO ZXR3b3JrIEludGVyY29ubmVjdGlvbiAoQ0ROSSkgTWV0YWRhdGEgSW50ZXJmYWNlDQpDcmVhdGlv biBkYXRlOgkgMjAxMS0xMC0zMQ0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1i ZXIgb2YgcGFnZXM6IDMzDQoNCg0K From kevin.ma@azukisystems.com Mon Oct 31 16:36:48 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5941811E838E for ; Mon, 31 Oct 2011 16:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7pHEp4vSmHLH for ; Mon, 31 Oct 2011 16:36:46 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC8A11E839D for ; Mon, 31 Oct 2011 16:36:46 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1408D416BED; Mon, 31 Oct 2011 19:36:46 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id DA3D0416D4E; Mon, 31 Oct 2011 19:36:44 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Mon, 31 Oct 2011 19:36:33 -0400 From: Kevin J Ma To: Ben Niven-Jenkins Date: Mon, 31 Oct 2011 19:36:43 -0400 Thread-Topic: [CDNi] Some questions regarding draft-ma-cdni-metadata Thread-Index: AcySSqv+v7NHpQeIRLK+dgF63KrbJQFvZRmg Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6A69186@MAILR002.mail.lan> References: <842E1148-9AFD-4A39-BBB3-89CAAB9E833A@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B668260C@MAILR002.mail.lan> <30D279D6-3F64-4E1F-A221-D293EE0261D7@niven-jenkins.co.uk> <291CC3F9E50E7641901A54E85D0977C651B6682920@MAILR002.mail.lan> <943A317A-AE56-464A-8CDB-A806332368BC@niven-jenkins.co.uk> In-Reply-To: <943A317A-AE56-464A-8CDB-A806332368BC@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Some questions regarding draft-ma-cdni-metadata X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:36:48 -0000 Hi Ben, responses inline: > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Monday, October 24, 2011 8:44 AM > To: Kevin J Ma > Cc: cdni@ietf.org > Subject: Re: [CDNi] Some questions regarding draft-ma-cdni-metadata > > Kevin, > > On 18 Oct 2011, at 17:03, Kevin J Ma wrote: > >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > >> On 17 Oct 2011, at 19:26, Kevin J Ma wrote: > >>> I attempted to create an extensible representation for metadata and a > >>> complete protocol for manipulating metadata, though, not all users of > >>> the interface will need all aspects. Do you feel that the protocol i= s > >>> deficient for non-authoritative CDN use, or that authoritative CDNs d= o > >>> not need the metadata interface? > >> > >> I think that we should stick to the scope of work we have been > chartered > >> to address, in the case of CDNI Metadata that is an interface that > "will > >> allow the CDNs to exchange content distribution metadata of inter-CDN > >> scope". > >> > >> If the interface we specify is also usable in other scenarios then > that's > >> great but I don't think we should be actively looking to design an > >> interface that is usable across a multitude of scenarios that are not > in > >> scope of CDNI because it's a distraction and likely to defocus our > >> efforts. Our charter is not to define a new CP->CDN provisioning > interface > >> (they already exist) so we shouldn't be burning cycles working on > things > >> that are out of charter. > > > > I personally do not see a difference between uCDN->dCDN and CP->uCDN. > > If in supporting uCDN->dCDN you get CP->uCDN, I think that is a bonus. > > I do not think we should ignore uCDN->dCDN just because it might be > > useful to CPs. Is the argument that a uCDN should never need to push > > metadata to a dCDN and therefore we do not need uCDN->dCDN support? > > My argument is that CP->uCDN and uCDN->dCDN are different beasts and in > supporting uCDN->dCDN you do not get a sufficient interface for CP->uCDN. > > We thought about this when writing draft-jenkins-cdni-metadata and we cam= e > to the conclusion that CP->uCDN is a provisioning interface whereas for > CDNI no provisioning is required, the dCDN only needs how to execute the > already-provisioned (in the uCDN) CDNI metadata. > > A multi-tenanted CP->uCDN provisioning interface requires a different > feature set and a richer data model than a uCDN->dCDN interface that just > needs to transfer already-provisioned CDNI metadata for a dCDN to execute > it. > > For example, a multi-tentanted CP->uCDN provisioning interface needs to > support features such as: > - User & Role based access control and a user account hierarchy that > allows different business entities to control different levels of that > hierarchy. > - Metadata access permissions as different users (at different levels in > the account hierarchy) may not have read or read/write access to all type= s > of metadata record and because users at different levels in the account > hierarchy have the requirement to add additional metadata > properties/policies (e.g. a Reseller may want to always have their off- > shore QA team added to any Delivery ACL to enable them to troubleshoot). > - Service/Account templates to simply provisioning. > etc. > > When it comes to executing the CDN metadata (i.e. what a surrogate needs > to know to perform the actual content delivery) none of the above feature= s > really matter, the CDN metadata can be flattened into a simpler CDNI > metadata data model that removes some of the complexities required in a > multi-tenanted provisioning data model as knowledge of how the CDNI > Metadata got into the system (and who is allowed to do what at which leve= l > of the account hierarchy) is not needed when all the Surrogate cares abou= t > is if and how it should delivery the actual content. > > So your assertion that a uCDN->dCDN interface automatically gives you a > sufficient CP->uCDN interface does not IMO hold true. Fair enough. Is it fair then to say that: though a CP may require more functionality than the uCDN, there is no reason why the CP cannot use that subset of functionality provided to uCDNs if it fits a portion (or all) of the CP needs? > It doesn't matter whether the CDNI Metadata interface is push from uCDN t= o > dCDN or pull from dCDN to uCDN, what is required to build a sufficient CP= - > uCDN provisioning interface is much more than what is required purely for > a sufficient CDNI Metadata interface. My opinion is we should concentrate > on what we're chartered to do (which is a CDNI Metadata interface) and no= t > try and expand that scope to be much wider than it is currently. > > > > >>> My concern with defining all the semantics of metadata and designing = a > >>> protocol around that, is you typically end up with a less extensible > >>> design. I would not want to have to update the metadata interface rf= c > >>> just to support a new piece of metadata in the future. I am not > saying > >>> that we should not define metadata, I just think it should be separat= e > >>> from the data model and the protocol, so I concentrated on those > first. > >>> I definitely feel that we should define a base set of metadata that > all > >>> CDNs should support. I do not think the draft prevents that. > >> > >> We agree on the fact that the CDNI metadata protocol specification > doesn't > >> need to define all possible properties/semantics for all possible > delivery > >> protocols and that properties and semantics for different delivery > >> protocols can be defined in separate documents. > >> > >> The CDNI metadata draft that Grant/David/I authored doesn't preclude > >> semantics/properties being defined in other documents (and implies tha= t > is > >> likely to be the case - see my response to Spencer just now). The base > set > >> of properties that are described in our draft could easily be broken > out > >> into a separate document if the consensus of the group is to do so. We > >> included the base properties and interface specification in a single > >> document so that readers could see how the interface could be > constructed > >> and applied using a set of common base semantics/properties for HTTP > >> delivery supported by deployed CDNs today. > >> > >> So if we put aside the question of where to define the actual > properties > >> and their semantics we're left with the data model and > interface/protocol > >> itself. So let's compare and contrast some key aspects of flexibility > >> between the different proposals. > >> > >> Cache-ability & Latency: > >> With the CDNI Metadata model we've proposed we think we've managed to > >> define a data model that is as simple as possible but no simpler. It > has a > >> minimum number of data objects to allow objects that are likely to to > be > >> large or reused to be broken out into separate resources to provide > >> efficiency and at the same time objects that may well have different > >> cache-ability lifetimes can be broken out into separate resources. The > >> interface specification allows inlining so that all related objects fo= r > a > >> Site can be included in a single request/response so we provide the > >> ability to have a simple implementation but also the flexibility to > >> optimise the implementation to balance object size and cache-ability > >> against number of requests/re-validations required. > > > > The protocol in my draft also supports bulk retrieval, but if there is > > a nuance of inlining that is missing, I could certainly look at it. > > Though I did not address cacheability, I think it could be applied at > > the bulk response level as you describe? > > My point was not that your proposal couldn't do bulk retrieval but that b= y > having a data model that is "too simple" rather than having achieving you= r > aim of a "more extensible" model/interface you actually have a > model/interface that is less flexible and less extensible than ours. > > Your model essentially ignores the reality that there are different types > of CDNI Metadata which are likely to have different "lifetimes" (TTLs), > different levels of reusability across CDN services & CPs and will contai= n > varying amounts of data. > > To give just one example: Think about the situation I mentioned earlier o= f > a Reseller (or CDN provider) wanting to add their off-shore QA team to al= l > Delivery ACLs to enable them to perform QA/troubleshooting/etc. Your mode= l > provides no ability (that I can see) to avoid having to list all the QA I= P > addresses against every every Metadata record (which are defined per URI) > in every Domain that will be interconnected. That's a hell of a lot of > unnecessary duplication. The inital draft did not include any specific metadata definitions, however there is nothing that precludes rich semantic interpretation of a given metadata value. It could be thought of more as a layered data model where from the protocol perspective the data is a simple opaque string of bytes, but that string may have greater meaning when taken in the context of the named metadata. > >> By keeping your model basically flat you force an implementation to > >> repeatedly have to transfer data that is common across a number of > >> Hostnames/Domains (e.g. the definition of Locations) and you force the > >> cache-ability for all data within a hostname/domain to be the same > whether > >> it is specific to a hostname/domain or common across multiple > >> hostnames/domains. You therefore do not provide any ability for > >> implementations to optimise based on their knowledge (or configured > >> policies) of the different types of data that combine to describe the > >> CDNI Metadata for a Site/domain/hostname. > >> > >> Self-description: > >> The links between objects in our model and the representations of the > >> different objects in our model are self-describing through the use of > >> relationships and media-types within the interface so a client can > easily > >> determine what data objects are being referenced and what data objects > it > >> is receiving and use the appropriate processing function to interpret > >> their contents. It is easy to add new data objects to our model if > >> required by defining new relationships and/or media types. In contrast > >> your representations aren't self-describing and so force a tighter > >> coupling between the client and server and they require some out of > band > >> process to ensure that coupling is maintained. > > > > The individual pieces of metadata have a defined type. If the CDN > > supports a given piece of metadata, it will know what the type is. The > > metadata distribution protocol, imo, does not need to know the type > > as long as the CDN who receives the metadata understands it? Knowing > > the type is not necessarily enough information to know what to do with > > it, the full definition of the metadata is required either way? > > I don't see anything in your proposal that indicates what the type (or > protocol version) a particular piece of metadata has so I therefore assum= e > it must be known by some other method (e.g. the protocol version is agree= d > out of band, the type is inferred from something) that has the consequenc= e > of requiring tighter coupling between client & server. > > As an example, think through how if your proposal is deployed would you > migrate to a newer version of the protocol and the level of explicit > knowledge and coupling between clients & servers required to do so. > > With self-describing objects and standard HTTP content negotiation to > negotiate a version of the objects media-type that both client & server > support it is, for example, possible to deploy a new protocol version of > our proposal on the server without requiring any changes on the clients > while retaining full backward compatibility. Clients than can be upgraded > independently of one another over a period of time while still retaining > backwards compatibility. > > I don't see any way to do that with your proposal without requiring > configuration on the server to tell it what version to expect from each > client and updating that configuration in lock-step with updating the > client requiring tight client/server coupling and coupled out of band > configuration. A version field for the protocol could certainly be added, though, the initial version could be assumed, until a new version is introduced. Versioning for the metadata itself I assumed would be part of the metadata definition, possibly embedded as part of the name field. > >> Bootstrapping & Coupling: > >> Similarly, with the CDNI Metadata interface/protocol we have proposed, > the > >> configuration/bootstrapping of the interface is as simple as possible > but > >> no simpler (a single URI) from which the dCDN can discover the locatio= n > of > >> all the CDNI metadata records they have access to. It also allows the > uCDN > >> to define the URI format (and hostname it's provided by) as they see > fit. > >> The uCDN has maximum flexibility to organise the different CDNI > metadata > >> objects and complete control over how they extend their implementation > to > >> support additional data objects or how they support mapping different > >> dCDNs to different sets of (or versions of) CDNI metadata. > >> > >> Your proposal imposes a greater configuration/bootstrapping burden on > the > >> dCDN as there is no way for it to discover the domains it has access > to, > >> it needs to know the URI/hostname of the uCDN's Metadata interface and > the > >> domains to query against that interface. The use of fixed paths in the > URI > >> that map to the different data object enforces rigidity on the uCDN's > CDNI > >> Metadata implementation (and tight coupling between the client and > server) > >> and means that if the uCDN wishes to extend its implementation to > support > >> additional objects it risks picking paths that may later clash with > paths > >> defined by newer versions of your protocol. > > > > Your SiteFeed object provides Site information (which is fairly > analogous > > to domain information). Domain information could also be put into a > feed, > > however, I assume that business processes drive what goes into the > SiteFeed. > > Of course it's possible to modify your proposal to look more like ours :-= ) > but my overall argument is that our proposal does everything yours does i= n > a more flexible & extensible way with the exception of defining an Agent > object which isn't relevant to CDNI Metadata anyway. > > > Is the SiteFeed configured offline, as part of some business process? > > If so, then is it better to configure Site information as a feed in > > the uCDN, or as domains in the dCDN. I do not have a strong feeling > > either way, but I do not see our schemes as being so different. > > They're not the same thing though. The SiteFeed enables a dCDN to > bootstrap itself. Whether it is configured offline or automatically > generated by the uCDN based on some configured policy and/or other data i= t > has automatically obtained (e.g. another SiteFeed when the uCDN is acting > as a dCDN for another CDN) is an implementation decision for each > individual CDN. > > Your proposal doesn't include a proposal for bootstrapping unless you're > suggesting the uCDN POST Domains into the dCDN in advance of the dCDN > requiring the associated CDNI Metadata (but your draft doesn't propose > that so I'm just guessing)? That is certainly an option. Though how to bootstrap is not explicitly defined, the tools necessary to do so (i.e., the POST APIs) are provided. thanx. -- Kevin J. Ma > Ben > > > > > thanx. > > > > -- Kevin J. Ma > > > >> Taking the above factors into consideration I believe that our propose= d > >> data model and interface specification is flexible and extensible > enough > >> to address the current and future needs of CDNI. > >> > >> Ben > >> > >> > >> > > From kevin.ma@azukisystems.com Mon Oct 31 16:40:43 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F5711E83A1 for ; Mon, 31 Oct 2011 16:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uHNRHzLhpzc for ; Mon, 31 Oct 2011 16:40:43 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id AD38111E83A9 for ; Mon, 31 Oct 2011 16:40:42 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 65C58417004; Mon, 31 Oct 2011 19:40:42 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id D5DB4416F0C; Mon, 31 Oct 2011 19:40:41 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Mon, 31 Oct 2011 19:40:38 -0400 From: Kevin J Ma To: Bruce Davie , "cdni@ietf.org" Date: Mon, 31 Oct 2011 19:40:40 -0400 Thread-Topic: [CDNi] Fwd: New Version Notification for draft-davie-cdni-framework-01.txt Thread-Index: AcyYAs9AHvP/2fjzR4+jYawE3cRW5AAGetDQ Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6A69188@MAILR002.mail.lan> References: <20111031192301.18956.17387.idtracker@ietfa.amsl.com> <0031646E-1F32-4AAC-BF36-5C723B9141A1@cisco.com> In-Reply-To: <0031646E-1F32-4AAC-BF36-5C723B9141A1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C651B6A69188MAILR002maill_" MIME-Version: 1.0 Subject: Re: [CDNi] Fwd: New Version Notification for draft-davie-cdni-framework-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:40:44 -0000 --_000_291CC3F9E50E7641901A54E85D0977C651B6A69188MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bruce, Given the change suggesting the MI for purge/pre-positioning, will there be a request to change the requirements (CNTL-1 and CNTL-4) to move purge/pre-position out of the CI? As I recall, wrt purge, requirement CNTL-2 (cascaded completion notification aggregation) was an significant consideration in selecting the CI over the MI? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Bru= ce Davie Sent: Monday, October 31, 2011 3:25 PM To: cdni@ietf.org Subject: [CDNi] Fwd: New Version Notification for draft-davie-cdni-framewor= k-01.txt I presented version -00 of this draft in Quebec City. Please post comments = to the list. Regards, Bruce Davie Begin forwarded message: From: internet-drafts@ietf.org Date: October 31, 2011 3:23:01 PM EDT To: bsd@cisco.com Cc: lpeterson@verivue.com, bsd@cisco.com Subject: New Version Notification for draft-davie-cdni-framework-01.txt A new version of I-D, draft-davie-cdni-framework-01.txt has been successful= ly submitted by Bruce Davie and posted to the IETF repository. Filename: draft-davie-cdni-framework Revision: 01 Title: Framework for CDN Interconnection Creation date: 2011-10-31 WG ID: Individual Submission Number of pages: 52 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, metadata exchange, and the acquisition of content by one CDN from another. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. The IETF Secretariat --_000_291CC3F9E50E7641901A54E85D0977C651B6A69188MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bruce,

<= p class=3DMsoNormal> 

  Given the change suggesting the= MI for purge/pre-positioning, will

  there = be a request to change the requirements (CNTL-1 and CNTL-4)

  to move purge/pre-position out of the CI?  As I reca= ll, wrt purge,

  requirement CNTL-2 (cascade= d completion notification aggregation)

  was= an significant consideration in selecting the CI over the MI?

 

thanx.

 

--  Kevin J. Ma

 

 

From: cdni-bounces@ietf.org [mailto:cd= ni-bounces@ietf.org] On Behalf Of Bruce Davie
Sent: Monday= , October 31, 2011 3:25 PM
To: cdni@ietf.org
Subject: [= CDNi] Fwd: New Version Notification for draft-davie-cdni-framework-01.txt

 

<= p class=3DMsoNormal>I presented version -00 of this draft in Quebec City. P= lease post comments to the list.

 

Regards,

<= /div>

Bruce Davie

 

 

Begin forwarded message:



Date: Octo= ber 31, 2011 3:23:01 PM EDT

Subj= ect: New Version Notification for draft-davie-cdni-framework-01.txt<= /b>

 

A new version of I-D, draft-davie-cdni-framework-01.txt ha= s been successfully submitted by Bruce Davie and posted to the IETF reposit= ory.

Filename:    &= nbsp;  draft-davie-cdni-framework
Revision:       01
Title:        &nb= sp;     Framework for CDN Interconnection
Cr= eation date:     &nbs= p;      2011-10-31
WG ID:          =            Indivi= dual Submission
Number of pages: 52

Abstract:
  This= document presents a framework for Content Distribution Network
 &n= bsp;Interconnection (CDNI).  The purpose of the framework is to provid= e
  an overall picture of the problem space of CDNI and to des= cribe the
  relationships among the various components necessa= ry to interconnect
  CDNs.  CDN Interconnection requires = the specification of several
  interfaces and mechanisms to ad= dress issues such as request routing,
  metadata exchange, and= the acquisition of content by one CDN from
  another.  T= he intent of this document is to outline what each
  interface= needs to accomplish, and to describe how these interfaces
  a= nd mechanisms fit together, while leaving their detailed
  spe= cification to other documents.




The IETF Secretariat=

 

= --_000_291CC3F9E50E7641901A54E85D0977C651B6A69188MAILR002maill_-- From kevin.ma@azukisystems.com Mon Oct 31 16:45:22 2011 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B381F0D8C for ; Mon, 31 Oct 2011 16:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id INIPRxeQnl3P for ; Mon, 31 Oct 2011 16:45:22 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF5B1F0D70 for ; Mon, 31 Oct 2011 16:45:22 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 3DE527A0F24; Mon, 31 Oct 2011 19:36:43 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E132B7A0E35; Mon, 31 Oct 2011 19:36:42 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Mon, 31 Oct 2011 19:36:42 -0400 From: Kevin J Ma To: Francois Le Faucheur , "cdni@ietf.org" Date: Mon, 31 Oct 2011 19:36:41 -0400 Thread-Topic: [CDNi] IETF82 - CDNI WG requests for slots Thread-Index: AcySbuZ8DzPnwSvfQbiETK3Hh+7vogFnZivQ Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6A69185@MAILR002.mail.lan> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_291CC3F9E50E7641901A54E85D0977C651B6A69185MAILR002maill_" MIME-Version: 1.0 Subject: Re: [CDNi] IETF82 - CDNI WG requests for slots X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 23:45:23 -0000 --_000_291CC3F9E50E7641901A54E85D0977C651B6A69185MAILR002maill_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Francois/Rich, I would like to request a slot for the following draft: http://tools.ietf.org/html/draft-ma-cdni-metadata-01 thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: Monday, October 24, 2011 1:04 PM To: cdni@ietf.org Subject: [CDNi] IETF82 - CDNI WG requests for slots Hello All, We'd like to ask any interested parties to let us know about their request = for a slot at our WG meeting planned for IETF82. Regards, Francois & Rich --_000_291CC3F9E50E7641901A54E85D0977C651B6A69185MAILR002maill_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Francois/Rich,=

 

  I would like to request a = slot for the following draft:

 

  http://tools.ietf.org/html/draft-ma-cdni-metadata-01

 

thanx.

 

--  Kevin J. Ma<= /span>

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Be= half Of Francois Le Faucheur
Sent: Monday, October 24, 2011 1= :04 PM
To: cdni@ietf.org
Subject: [CDNi] IETF82 - CDNI = WG requests for slots

 

Hello All,

We'd like to a= sk any interested parties to let us know about their request for a slot at&= nbsp;our WG meeting planned for IETF82.

Regards,
Francois & R= ich

 

= --_000_291CC3F9E50E7641901A54E85D0977C651B6A69185MAILR002maill_--