From ben@niven-jenkins.co.uk Tue Nov 1 06:39: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 A78431F0C87 for ; Tue, 1 Nov 2011 06:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.431 X-Spam-Level: X-Spam-Status: No, score=-103.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 2UXqDoaYJe0k for ; Tue, 1 Nov 2011 06:39:15 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 207C41F0C42 for ; Tue, 1 Nov 2011 06:39:15 -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 1RLEYa-00076H-SZ; Tue, 01 Nov 2011 13:39:14 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B6A69186@MAILR002.mail.lan> Date: Tue, 1 Nov 2011 13:39:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <291CC3F9E50E7641901A54E85D0977C651B6A69186@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, 01 Nov 2011 13:39:17 -0000 Kevin, Please see inline. On 31 Oct 2011, at 23:36, Kevin J Ma wrote: >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> On 18 Oct 2011, at 17:03, Kevin J Ma wrote: >>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >>>> 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? >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> So your assertion that a uCDN->dCDN interface automatically gives you = a >> sufficient CP->uCDN interface does not IMO hold true. >=20 > 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? Let's take a step back. You asserted that your proposal was an extensible and complete proposal = for manipulating metadata whether that was between uCDNs and dCDNs or = between CSPs and uCDNs and that one "bonus" over other proposals was = that it was suitable for uCDNs to expose to CSPs. I asserted that other proposal are more flexible and extensible for CDNI = metadata between uCDN and dCDN. I also asserted that your "bonus" = doesn't exist because your proposal is not complete enough to be = sufficient for a CSP->uCDN interface. I have previously stated a view that we should stick to the scope of = work we have been chartered to do and not distract ourselves and = needlessly burn cycles trying to define a complete CSP->uCDN interface = when we are only chartered to define a uCDN-dCDN interface. We currently have 4 proposals for CDNI Metadata on the table and so = rather than discussing whether some subset of a proposal could be used = by some subset of CSPs in a use case that is outside of the charter of = the WG, I'd rather discuss the merits (or demerits) of the proposals for = the use cases the WG is actually chartered to solve so we can hopefully = reach consensus on a single approach for the CDNI metadata interface. To that end I believe I have put forward strong arguments in my previous = mails in this thread as to why the advantages you assert for your = proposal do not hold true and strong arguments for why another proposal = than yours is better suited for modelling and transferring CDNI Metadata = between uCDNs and dCDNs. Ben >> 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. >>=20 >> >>=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. >>>>=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? >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >=20 > 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. >=20 >>>> 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? >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 > 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. >=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, >>> however, I assume that business processes drive what goes into the >> SiteFeed. >>=20 >> 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. >>=20 >>> 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. >>=20 >> 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. >>=20 >> 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)? >=20 > 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. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> Ben >>=20 >>>=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 >=20 From ben@niven-jenkins.co.uk Tue Nov 1 08:10: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 143E411E81C4 for ; Tue, 1 Nov 2011 08:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.438 X-Spam-Level: X-Spam-Status: No, score=-103.438 tagged_above=-999 required=5 tests=[AWL=0.161, 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 OeNV97LxoVE7 for ; Tue, 1 Nov 2011 08:10:57 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 21CF811E81BD for ; Tue, 1 Nov 2011 08:10:57 -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 1RLFzM-0004IV-1v; Tue, 01 Nov 2011 15:10:56 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201FE4F05@ftrdmel0.rd.francetelecom.fr> Date: Tue, 1 Nov 2011 15:10:52 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <78BCE9D8-7C4F-4162-9F6B-867240993EE1@cisco.com> <1CA25301D2219F40B3AA37201F0EACD1136D0BEA@PACDCEXMB05.cable.comcast.com> <843DA8228A1BA74CA31FB4E111A5C46201FE4F05@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [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: Tue, 01 Nov 2011 15:10:58 -0000 Emile, Colleagues, On 31 Oct 2011, at 22:36, = wrote: > 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=85); > - The framework document specifies precisely the = bootstrapping operations and the framework; I agree that as we work through the CDNI solution components and how = they fit together the exact functionality placed under each interface = needs to be firmed up compared to what we have currently in the Problem = Statement and Bruce's framework draft. I shared some thoughts with some folks offline about the CDNI Control = interface and the two functions of bootstrapping & control of = content/metadata and where they might best fit in the context of CDNI = interfaces but as you bring it up here I'll repeat some of my thoughts = on the list. Bootstrapping/(fairly) static capability advertisement: I tend to think that the CDNI Metadata is essentially (content service = level) configuration information and the CDNI Metadata interface is = about distributing configuration between interconnected CDNs. In the case of bootstrapping of the CDNI interfaces and communicating = static (or fairly static) information about capabilities and policies = they can also (IMO) be thought of as essentially CDN/CDNI level = configuration information. Although the current proposals for CDNI Metadata data models & interface = specifications only address CDNI Metadata at present I think it should = be possible to build a data model for CDNI bootstrapping/capabilities = that can reuse, for example, the interface specification and encoding in = proposed draft-jenkins-cdni-metadata. New objects (and associated = relationships & media types) would need to be specified but that should = be fairly straightforward and the base interface proposed could be = reused for both content service configuration (aka CDNI Metadata) and = CDN/CDNI configuration (aka bootstrapping/capabilities). So it would seem to me a reasonable proposal to move the = bootstrapping/capability elements currently nominally placed under "CDNI = Control" to become part of the CDNI Metadata interface Control of content: In the case of control of content although draft-davie-cdni-framework-01 = puts forward the view that "a purge is equivalent to a statement that = the availability window for that content has now expired" I think the = requirements placed on purging/invalidating/pre-positioning content = require functionality not covered by the current CDNI Metadata = proposals. In contrast to the distribution of CDNI Metadata which is a dCDN = discovering (or being told) the content service level configuration it = needs, invalidating/purging content is the uCDN requesting the dCDN = perform some task on its behalf (e.g. purge this item of actual = content). A key factor that IMO separates purge/pre-position from CDNI Metadata is = the timing & feedback aspects. When a dCDN pulls CDNI Metadata from a = uCDN (or when a uCDN pushes CDNI Metadata into a dCDN) it's reasonable = for the uCDN to assume the dCDN has some mechanism to distribute that so = it is available to Surrogates when they require it. In the case of push = (via a HTTP POST for e.g.) the dCDN's response of "201 Created" is = saying "I got that metadata record and created a resource for it on the = server you POSTed to" it says nothing about whether or not the Metadata = was distributed to the rest of the system (same for pull via GET except = the acceptance by the dCDN is implicit). In the case of purge/pre-position the uCDN will want explicit feedback = to know that the purge/pre-position "task" it has requested has been = distributed within the dCDN and completed by the dCDN. The dCDN's "201 = Created" response would be saying "I got that request for purge and I = have created a resource [task] for it on the server you POSTed to". If = we're being RESTful the Location: header in the 201 response would link = to a resource that could be queried by the uCDN to check the progress of = the task. The nature of purge/pre-position requests means they may take = some time to complete and so trying to overload the meaning of the 201 = with "I got that task and I've completed it" doesn't seem realistic to = me. Therefore purge/invalidate/pre-position of actual content (as opposed to = CDNI Metadata) is in my mind a separate beast to distributing the actual = CDNI Metadata and requires a different behaviour from the interface used = to implement purge/invalidate/pre-position from that used to distribute = CDNI Metadata. Whether we incorporate that different behaviour under the banner of a = "CDNI Control interface" or an extended/richer "CDNI Metadata interface" = is to some extent semantics but I do think it needs something more than = is required purely for the distribution of CDNI Metadata between = interconnected CDNs. Ben From swainner@cisco.com Tue Nov 1 12: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 A95AD21F8CAB for ; Tue, 1 Nov 2011 12:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.398 X-Spam-Level: X-Spam-Status: No, score=-9.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, 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 iDihNeLOLaGI for ; Tue, 1 Nov 2011 12:49:30 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5A19921F8CA4 for ; Tue, 1 Nov 2011 12:49:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=167356; q=dns/txt; s=iport; t=1320176966; x=1321386566; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=hmuAP29AmC9R0ls0OReh43tMU8WY+un2xn9xW/J6sIA=; b=WDX1xplEAxhFdjZo0rh5FlBEO0yweo2p7Ixn0BWDqC1Qd7SdvJ1M9jt6 A8m2yfiOX3UusTAS4XEEfPUDlH8E+LJVAV6AuCBvULPorNiAvvGCENR+n 5A213jI9zE41TtYAg0/S1qxq0Vwa+5zDF4e0fFJW89A6PvRQ3fbx1So2Z 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscAAC5MsE6Q/khL/2dsb2JhbABDgk2XHo4ygSqBBYFyAQEBAwEBAQEPAQcBEhwlBAYGBwICCxEBAwEBAQkWAQEGBwkDAgECAQQRHwMGCBADBgIBARUBAQeHYAiXFgGeMgKJBQSUD4o3h0Q X-IronPort-AV: E=Sophos;i="4.69,439,1315180800"; d="scan'208,217";a="120544941" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 01 Nov 2011 19:47:28 +0000 Received: from stealth-10-32-245-57.cisco.com (stealth-10-32-245-57.cisco.com [10.32.245.57]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA1JlNBD018256 for ; Tue, 1 Nov 2011 19:47:24 GMT Message-ID: <4EB04CCD.7070707@cisco.com> Date: Tue, 01 Nov 2011 15:47:25 -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: <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> In-Reply-To: <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> Content-Type: multipart/alternative; boundary="------------090408010502050308010207" 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, 01 Nov 2011 19:49:39 -0000 This is a multi-part message in MIME format. --------------090408010502050308010207 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Perhaps the answer to this dilemma is very simple ... In the CDNI interface, we simply offer a binary option of the following: 0) content may not be adapted 1) content may be adapted I suspect that the majority of the CDNI relationships will set the flag to "0" indicating the asset is not allowed to be adapted. The reason can be anything including contractual between the CP and uCDN, the content is encrypted, the uCDN preference, etc. Now if the flag is set to "1", it is incumbent upon the dCDN to figure out how to modify the content without changing the URL references, etc. Scott On 10/27/11 7:22 AM, Woundy, Richard wrote: > >In your companyâEUR^(TM)s 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 ; Alan Kavanagh > > *Cc*: 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âEUR^(TM)s website, I just find some information that > addresses âEURoe Vodafone subscribers complained about video > performance.âEUR? > > 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âEUR^(TM)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 > --------------090408010502050308010207 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Perhaps the answer to this dilemma is very simple ...

In the CDNI interface, we simply offer a binary option of the following:

0) content may not be adapted
1) content may be adapted

I suspect that the majority of the CDNI relationships will set the flag to "0" indicating the asset is not allowed to be adapted.  The reason can be anything including contractual between the CP and uCDN, the content is encrypted, the uCDN preference, etc.

Now if the flag is set to "1", it is incumbent upon the dCDN to figure out how to modify the content without changing the URL references, etc.

Scott

On 10/27/11 7:22 AM, Woundy, Richard wrote:
>In your company’s 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’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

 

- 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

 


--------------090408010502050308010207-- From zhouzhipeng@huawei.com Wed Nov 2 00:30: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 560E711E80AC for ; Wed, 2 Nov 2011 00:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.267 X-Spam-Level: X-Spam-Status: No, score=-5.267 tagged_above=-999 required=5 tests=[AWL=0.131, 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 Svco0N2GpeB2 for ; Wed, 2 Nov 2011 00:30:23 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0878411E809A for ; Wed, 2 Nov 2011 00:30:17 -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 <0LU000C0KVI2H1@szxga03-in.huawei.com> for cdni@ietf.org; Wed, 02 Nov 2011 15:30:03 +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 <0LU0007MHVH4V5@szxga03-in.huawei.com> for cdni@ietf.org; Wed, 02 Nov 2011 15:30:02 +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 AER86747; Wed, 02 Nov 2011 15:30:01 +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; Wed, 02 Nov 2011 15:29:54 +0800 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.117]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 02 Nov 2011 15:29:52 +0800 Date: Wed, 02 Nov 2011 07:29:51 +0000 From: ZhouZhipeng In-reply-to: <4EB04CCD.7070707@cisco.com> X-Originating-IP: [10.138.73.38] To: Scott Wainner , "cdni@ietf.org" Message-id: <260A32EFD5C9EB47AD504929D005DF6217F6DADF@SZXEML519-MBX.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_pUz9GlNEpleNbHhlmXY4ow)" 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+T11t9RIj65WZKAJg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <4EB04CCD.7070707@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: Wed, 02 Nov 2011 07:30:27 -0000 --Boundary_(ID_pUz9GlNEpleNbHhlmXY4ow) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGkgU2NvdHQsDQpUaGlzIHRvcGljIHBlcmhhcHMgbWF5IG5vdCBiZSBzbyBzaW1wbGUgYXMgMCBv ciAxLCBvdGhlcndpc2Ugd2Ugd291bGQgbm90IGhhdmUgdGFrZW4gc28gbXVjaCB0aW1lIGRpc2N1 c3Npbmcgb24gaXQuDQpUaGUgb3JpZ2luYWwgcXVlc3Rpb24gaXM6IGlmIHRvIHN1cHBvcnQgY29u dGVudCBhZGFwdGF0aW9uLCB3aGVyZSAsIHdoYXQgc29sdXRpb24oaS5lLiB0cmFuc2Zvcm1hdGlv biwgbWV0YWRhdGEsIGV0YykgYW5kICBob3cgbXVjaCBjb3N0IHdvdWxkIGJlIG5lZWRlZC4NCklm IHRoZXJlIGlzIG5vIGFwcHJvcHJpYXRlIHNjZW5hcmlvIHRvIGltcGxlbWVudCB0aGUgY29udGVu dCBhZGFwdGF0aW9uLCB0aGUgdXNlIGNhc2UgYW5kIHJlcXVpcmVtZW50IHdvdWxkIGJlIG5vdCBp biB0aGUgc3RhbmRhcmQgd29yay4NClNvIHdlIGhhdmUgZXZhbHVhdGVkIG1hbnkgaXNzdWVzIGFu ZCBzdGlsbCBhcmUgd29ya2luZyB0byBnaXZlIGEgY29tcGxldGUgdmlldy4NCkZyb20gbXkgc2lk ZSBhbmQgc29tZSBvdGhlciBleHBlcnRzLCBzb21lIGludGVybmFsIHdvcmtzIGhhdmUgYmVlbiBk b25lIG9uIHRoaXMuIFBlcmhhcHMgZGlmZmVyZW50IHBlb3BsZSBob2xkIGVpdGhlciBhIHBvc2l0 aXZlICBvciBhIG5lZ2F0aXZlIHZpZXdwb2ludCBmb3IgaXQuDQpUaGUgd29yayAoaW5jbHVkaW5n IG9mZmxpbmUgZGlzY3Vzc2lvbnMpIGlzIHN0aWxsIGdvaW5nIG9uIGFuZCBJIHdvdWxkIGdpdmUg bXkgY29tcGxldGUgYW5hbHlzaXMgYW5kIHNvbHV0aW9uIHByb3Bvc2FsIG9uIHRoaXMgdG9waWMu DQpIb3cgYWJvdXQgdG8gbGV04oCZcyBkbyB0aGUgZmluYWwgZXZhbHVhdGlvbiB0aGVuLg0KDQo+ IE5vdyBpZiB0aGUgZmxhZyBpcyBzZXQgdG8gIjEiLCBpdCBpcyBpbmN1bWJlbnQgdXBvbiB0aGUg ZENETiB0byBmaWd1cmUgb3V0IGhvdyB0byBtb2RpZnkgdGhlIGNvbnRlbnQgd2l0aG91dCBjaGFu Z2luZyB0aGUgVVJMIHJlZmVyZW5jZXMsIGV0Yy4NCldlIG1heSBoYXZlIGRpZmZlcmVudCB3YXlz LiBGb3IgZXhhbXBsZSB3aHkgdG8gY29uc3RyaWN0IHRoYXQgd2l0aCB0aGUgc2FtZSBVUkwgZm9y IGRpZmZlcmVudCBjb250ZW50IGNvcGllcy4NCkFuZCwgUkZDMjI5NSAoVHJhbnNwYXJlbnQgQ29u dGVudCBOZWdvdGlhdGlvbiBpbiBIVFRQKSBwZXJoYXBzIG1heSBiZSB0aGUgaW5mb3JtYXRpb24g Zm9yIHJlZmVyZW5jZSB0b28uDQoNCldlbGNvbWUgeW91ciBtb3JlIGlkZWFzIG9uIHRoaXMgdG9w aWMuDQpUaGFua3MuDQpaaGlwZW5nDQoNCg0KDQpGcm9tOiBTY290dCBXYWlubmVyIFttYWlsdG86 c3dhaW5uZXJAY2lzY28uY29tXQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAwMiwgMjAxMSAz OjQ3IEFNDQpUbzogY2RuaUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQpQZXJoYXBzIHRoZSBhbnN3ZXIg dG8gdGhpcyBkaWxlbW1hIGlzIHZlcnkgc2ltcGxlIC4uLg0KDQpJbiB0aGUgQ0ROSSBpbnRlcmZh Y2UsIHdlIHNpbXBseSBvZmZlciBhIGJpbmFyeSBvcHRpb24gb2YgdGhlIGZvbGxvd2luZzoNCg0K MCkgY29udGVudCBtYXkgbm90IGJlIGFkYXB0ZWQNCjEpIGNvbnRlbnQgbWF5IGJlIGFkYXB0ZWQN Cg0KSSBzdXNwZWN0IHRoYXQgdGhlIG1ham9yaXR5IG9mIHRoZSBDRE5JIHJlbGF0aW9uc2hpcHMg d2lsbCBzZXQgdGhlIGZsYWcgdG8gIjAiIGluZGljYXRpbmcgdGhlIGFzc2V0IGlzIG5vdCBhbGxv d2VkIHRvIGJlIGFkYXB0ZWQuICBUaGUgcmVhc29uIGNhbiBiZSBhbnl0aGluZyBpbmNsdWRpbmcg Y29udHJhY3R1YWwgYmV0d2VlbiB0aGUgQ1AgYW5kIHVDRE4sIHRoZSBjb250ZW50IGlzIGVuY3J5 cHRlZCwgdGhlIHVDRE4gcHJlZmVyZW5jZSwgZXRjLg0KDQpOb3cgaWYgdGhlIGZsYWcgaXMgc2V0 IHRvICIxIiwgaXQgaXMgaW5jdW1iZW50IHVwb24gdGhlIGRDRE4gdG8gZmlndXJlIG91dCBob3cg dG8gbW9kaWZ5IHRoZSBjb250ZW50IHdpdGhvdXQgY2hhbmdpbmcgdGhlIFVSTCByZWZlcmVuY2Vz LCBldGMuDQoNClNjb3R0DQoNCk9uIDEwLzI3LzExIDc6MjIgQU0sIFdvdW5keSwgUmljaGFyZCB3 cm90ZToNCj5JbiB5b3VyIGNvbXBhbnnDouKCrOKEonMgd2Vic2l0ZSwgSSBqdXN0IGZpbmQgc29t ZSBpbmZvcm1hdGlvbg0KDQpJIGhhdmUgdG8gc3RlcCBpbiBhcyBjby1jaGFpciBoZXJlLg0KDQpU aGUgZ29hbCBvZiB0aGlzIFdHIGlzIG5vdCB0byBhbGlnbiB2ZW5kb3IgcHJvZHVjdCByb2FkbWFw cywgb3IgdG8gZXF1YWxpemUgYWxsIHZlbmRvciBvZmZlcmluZ3MsIG9yIHRvIHNwZWNpZnkgdGhl IGVudGlyZSBDRE5JIGVjb3N5c3RlbS4gVGhlIGdvYWwgb2YgdGhpcyBXRyBpcyB0byBlbmFibGUg dGhlIGludGVyY29ubmVjdGlvbiBhbmQgaW50ZXJvcGVyYXRpb24gb2YgdHdvIG9yIG1vcmUgQ0RO cywgd2l0aGluIHRoZSBib3VuZHMgb2YgdGhlIENETkkgd2cgY2hhcnRlci4NCg0KSXQgaXMgT0sg dG8gaGF2ZSBhIGRpc2N1c3Npb24gYWJvdXQgd2hldGhlciBjb250ZW50IGFkYXB0YXRpb24gbmVl ZHMgdG8gYmUgcGVyZm9ybWVkIGJ5IHRoZSBkQ0ROLCBzaW5jZSB0aGF0IGRlY2lzaW9uIGltcGFj dHMgdGhlIHVDRE4tZENETiBpbnRlcmZhY2UuIFNvIGxldCdzIGZpbmQgYSBwcm9kdWN0aXZlIHdh eSB0byBkaXNjdXNzIHRoaXMgb24gdGhlIG1haWxpbmcgbGlzdCwgYW5kIHRvIGNsb3NlIHRoZSBk aXNjdXNzaW9uIGJ5IElFVEYgODIgKGlmIG5vdCBzb29uZXIpLg0KDQpDYW4gc29tZW9uZSBkZXNj cmliZSByZWFsLWxpZmUgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBDRE4gKG9yIGVkZ2UgY2Fj aGUtYmFzZWQpIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBuZWVkZWQgdG9kYXkgaW4gYSBwcm9kdWN0 aW9uIGVudmlyb25tZW50LCBvciBzaG9ydGx5PyBOb3QgbWVyZWx5IGEgZmVhdHVyZSBpbiBhIHZl bmRvcidzIHByb2R1Y3QgbWF0ZXJpYWxzPw0KDQpTcGVha2luZyBhcyBhbiBpbmRpdmlkdWFsLCBJ IGNhbiBmaW5kIGEgbG90IG9mIGV4YW1wbGVzIHdoZXJlIGRvd25zdHJlYW0gY29udGVudCBhZGFw dGF0aW9uIGlzIG5vdCBuZWVkZWQsIGFuZCBhbnkgYWRhcHRhdGlvbiBpcyByZWFsbHkgcGFydCBv ZiB0aGUgQ1AgLSB1Q0ROIGludGVyZmFjZSAod2hpY2ggaXMgb3V0IG9mIHRoZSBzY29wZSBvZiBv dXIgY2hhcnRlcikuDQoNCi0tIFJpY2gNCg0KDQpGcm9tOiBaaG91WmhpcGVuZyBbbWFpbHRvOnpo b3V6aGlwZW5nQGh1YXdlaS5jb21dDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSAw Mzo0NSBBTQ0KVG86IE1hcmsgZGUgSm9uZyA8bWFya0BqZXQtc3RyZWFtLm5sPjxtYWlsdG86bWFy a0BqZXQtc3RyZWFtLm5sPjsgQWxhbiBLYXZhbmFnaCA8YWxhbi5rYXZhbmFnaEBlcmljc3Nvbi5j b20+PG1haWx0bzphbGFuLmthdmFuYWdoQGVyaWNzc29uLmNvbT4NCkNjOiBjZG5pQGlldGYub3Jn PG1haWx0bzpjZG5pQGlldGYub3JnPiA8Y2RuaUBpZXRmLm9yZz48bWFpbHRvOmNkbmlAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2Ut Y2FzZXMtMDAudHh0DQoNCkhlbGxvIE1hcmssDQpOaWNlIHRvIG1lZXQgeW91IG9uIGxpbmUuDQpJ biB5b3VyIGNvbXBhbnnDouKCrOKEonMgd2Vic2l0ZSwgSSBqdXN0IGZpbmQgc29tZSBpbmZvcm1h dGlvbiB0aGF0IGFkZHJlc3NlcyDDouKCrMWTIFZvZGFmb25lIHN1YnNjcmliZXJzIGNvbXBsYWlu ZWQgYWJvdXQgdmlkZW8gcGVyZm9ybWFuY2Uuw6LigqzCnQ0KU2VlOg0KaHR0cDovL3d3dy5qZXQt c3RyZWFtLm5sL3NlYXJjaC8/c2VhcmNoPXRyYW5zY29kaW5nDQoNCkRlYXIgYWxsIGluIHRoaXMg Z3JvdXAsDQpJbiBsYXN0IGZldyBkYXlzLCBleGNlcHQgdGhlIHB1YmxpYyBlbWFpbCBkaXNjdXNz aW9ucyBJIGhhdmUgY29udGFjdGVkIHdpdGggc29tZSBwZW9wbGUgYW5kIGRpc2N1c3NlZCB3aXRo IG15IG93biBjb2xsZWFndWVzIG9mIGFsbCBkZXRhaWxzIG9uIHRoaXMgaXNzdWUuDQpGaXJzdCwg YWx0aG91Z2ggdGhlIG1hcmtldCByZXF1aXJlbWVudCBmb3IgaXQgaXMgdmVyeSBpbXBvcnRhbnQs IEkgZmVlbCBJw6LigqzihKJkIGJldHRlciBzaG93IHVwIG1vcmUgaW5mb3JtYXRpb24gb24gdGhl IHByb2NlZHVyZSBpbnZvbHZlZC4gSSBoYXZlIGV4cGxhaW5lZCBtYW55IHRpbWVzIHRoYXQgdG8g c3VwcG9ydCBjb250ZW50IGFkYXB0YXRpb24gaXMgcmF0aGVyIHNpbXBsZSB3aGlsZSB0aGUgd29y ZGluZyBpcyBub3QgZW5vdWdoLg0KSSBhbSBidXN5IG1ha2luZyBzb21lIGNvbnRyaWJ1dGlvbnMg b24gdGhpcyBhbmQgcGxhbiB0byB1cGxvYWQgdG8gRVRTSSBtZWV0aW5nIGFuZCBJRVRGIENETkku DQpCeSB0aGVzZSB3b3JrICBJIGZlZWwgdGhlIHBlb3BsZSBtYXkgY2F0Y2ggYSB3aG9sZSB2aWV3 IG9uIHRoaXMgaXNzdWUuDQpTZWNvbmQsIGZvciB0aGF0IGZ1bmN0aW9uYWxpdHksIGluIGltcGxl bWVudGF0aW9uLCBpZiBzb21lIGVudGl0eSBkb2VzIG5vdCBjaG9vc2UgdG8gc3VwcG9ydCBpdCwg aXQgbWF5IGJlIG9rLiBTaW5jZSBpdCBtYXkgYmUgbmVnb3RpYXRlZCBiZXR3ZWVuIHR3byBDRE5z Lg0KSWYgZENETiBkb2VzIG5vdCBzdXBwb3J0IHRoYXQsIGl0IG1heSBiZSB0aGUgdUNETiByZXNw b25zaWJsZSB0byBjb21wbGV0ZSB0aGUgdHJhbnNjb2RpbmcgYW5kIGRlbGl2ZXIgdGhlIGNvbnRl bnQgb2YgbXVsdGlwbGUgZm9ybWF0cyBhbmQgcmF0ZXMgdG8gZENETi4NClRoaXJkLCBhbHRob3Vn aCBDRE5JIGlzIGEgbmV3IGFyY2hpdGVjdHVyZSwgd2hpbGUgdGhlIGNvbnRlbnQgb3BlcmF0aW5n IGhhcyBiZWVuIGV4aXN0ZWQgZm9yIHllYXJzLiBBcyBJIGtub3cgdGhlIGNvbnRlbnQgZnJvbSBV U0EgdG8gdGhlIGRvd25zdHJlYW0gb3BlcmF0b3IgaXMgdHJhbnNmZXJyZWQgb24gb25lIGNvcHkg YW5kIHRoZSBkb3duc3RyZWFtIG9wZXJhdG9yIHdpbGwgaGFuZGxlIHRoZSB0cmFuc2NvZGluZy4N Cg0KUGVyaGFwcywgdGhlIGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBtb3JlIG9uIHRoZSBtb2JpbGUg b3BlcmF0aW5nLiBCdXQgSSBmZWVsIGN1cnJlbnRseSBtb3N0IG9wZXJhdG9yIHdpbGwgYmUgYSBh bGwgc2VydmljZSBvcGVyYXRvci4gQW5kIGZvciB0aGUgQ0ROIHByb3ZpZGVycywgaXQgbWF5IGJl IGJldHRlciB0byBzdXBwb3J0IGFsbCBraW5kcyBvZiBzZXJ2aWNlLg0KQmVzaWRlcywgSSBsaWtl IHNheSB0aGF0IHRoZSB0ZWNobm9sb2d5IG9uIHRoaXMgdG9waWMgaGFzIGJlZW4gZm9yIG1hbnkg eWVhcnMgYW5kIGhhcyBiZWVuIHJhdGhlciBtYXR1cmUsIGV2ZW4gc29tZSBpdGVtcyBpbiBpZXRm IHN1Y2ggYXMgcmZjMzUwNyBpY2FwLiBTbyBmcm9tIHRoZSB0ZWNobmlxdWUgcG9pbnQgb2Ygdmll dywgaXQgaXMgYSBuYXR1cmUgYWN0aW9uIHRvIGJlIGludm9sdmVkIGluIENETiBpbnRlcmNvbm5l Y3Rpb24uDQpUaGFua3MuDQpaaGlwZW5nDQoNCg0KDQpGcm9tOiBNYXJrIGRlIEpvbmcgW21haWx0 bzptYXJrQGpldC1zdHJlYW0ubmxdDQpTZW50OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSA0 OjIxIEFNDQpUbzogQWxhbiBLYXZhbmFnaA0KQ2M6IEJlbiBOaXZlbi1KZW5raW5zOyBaaG91Wmhp cGVuZzsgY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb Q0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0KSGkg QWxhbiwNCg0KQXMgQmVuIHN0YXRlZCB0aGUgb3ZlcmFsbCBkaXNjdXNzaW9uIHJpZ2h0IG5vdyBp cyBhYm91dCBkZWxpdmVyeSwgbm90IG9uIGFkYXB0YXRpb24uIEl0IGlzIGhhcmQgZW5vdWdoIHRv IGdldCBjb25zZW5zdXMgb24gdGhlIGRlbGl2ZXJ5IGFzcGVjdCBhbHJlYWR5IG5vdCB0byBtZW50 aW9uIHlvdXIgcmVxdWlyZW1lbnQgZnJvbSBjb250ZW50IGFkYXB0YXRpb24gYWRkZWQgdG8gdGhh dCwgc28gSSBhZ3JlZSB3aXRoIEJlbiB3ZSBzaG91bGQgc3RpY2sgd2l0aCB0aGUgZGVsaXZlcnkg YXNwZWN0IGZvciB0aGUgZmlyc3Qgc3BlY3MuIEkgY2FuIGltYWdpbmUgdGhpcyBjb3VsZCBiZSBh IGRpc2N1c3Npb24gbGF0ZXIgb24gYnV0IHBsZWFzZSBsZXQgdXMga2VlcCB0aGUgc2NvcGUgb2Yg dGhpcyBiZSBjbGVhbiBhbmQgdHJhbnNwYXJlbnQuIEl0IGlzIG9mIGJlbmVmaXQgb2YgZXZlcnlv bmUgdG8gZ2V0IHRoZSBmaXJzdCBzcGVjcyBhcyBmYXN0IGFzIHBvc3NpYmxlLiBUaGFua3MuDQoN Ck1ldCB2cmllbmRlbGlqa2UgZ3JvZXQsDQpLaW5kIHJlZ2FyZHMsDQoNCk1hcmsgZGUgSm9uZw0K SW50ZXJuYXRpb25hbCBCdXNpbmVzcyBEZXZlbG9wZXINCkpldC1TdHJlYW0gQlYNCg0KRS1tYWls OiBtYXJrQGpldC1zdHJlYW0uY29tPG1haWx0bzptYXJrQGpldC1zdHJlYW0uY29tPg0KT2ZmaWNl OiArMzEgKDApNTAgNTI2MTgyMA0KTW9iaWxlOiArMzEgKDApNiA4MTEwODI2Mw0KRmF4OiArMzEg KDApNTAgNTI2NDIxNA0KDQotIEV2ZW50OiBNZWV0IHVzIGF0IFN0cmVhbWluZyBNZWRpYSBFdXJv cGUsIDE3LTE4IE9jdG9iZXIsIExvbmRvbiwgVUsNCi0gRXZlbnQ6IE1lZXQgdXMgYXQgT25saW5l IFZpZGVvIFN0cmF0ZWdpZXMsIDE5IE9jdG9iZXIsIExvbmRvbiwgVUsNCi0gRXZlbnQ6IE1lZXQg dXMgYXQgQ0ROIFdvcmxkIFN1bW1pdCwgMjUtMjggT2N0b2JlciwgTG9uZG9uLCBVSw0KLSBOZXdz OiBQcmUtcmVxdWVzdCB5b3VyIFRlY2hub2xvZ3kgV2hpdGVwYXBlciBub3cgYW5kIGJlIHRoZSBm aXJzdCB0byBoYXZlIGl0LCBjaGVjayB3d3cuamV0LXN0cmVhbS5jb208aHR0cDovL3d3dy5qZXQt c3RyZWFtLmNvbT4NCi0gTmV3czogQ2hlY2sgaHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbSB0byBk b3dubG9hZCBvdXIgJ1NpeCBUcmVuZHMgaW4gQ0ROcycgYnJvY2h1cmUNCg0KLSBCbG9nOiB3d3cu amV0LXN0cmVhbS5jb20vYmxvZy88aHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbS9ibG9nLz4NCi0g VmlkZW9FeGNoYW5nZTogd3d3LnZkby14Lm5ldDxodHRwOi8vd3d3LnZkby14Lm5ldD4NCi0gU3Ry ZWFtemlsbGE6IHd3dy5zdHJlYW16aWxsYWNkbi5jb208aHR0cDovL3d3dy5zdHJlYW16aWxsYWNk bi5jb20+DQotIENvcnBvcmF0ZTogd3d3LmpldC1zdHJlYW0uY29tPGh0dHA6Ly93d3cuamV0LXN0 cmVhbS5jb20+DQoNCk9uIDI2LCBPY3QsMjAxMSwgYXQgODozMyBQTSwgQWxhbiBLYXZhbmFnaCB3 cm90ZToNCg0KDQoNCkJlbg0KDQpJbSBhc3N1bWluZyB0aGVuIGJhc2VkIG9uIHlvdXIgY29tbWVu dHMgYmVsb3cgYXJlIHlvdSBzdWdnZXN0aW5nIHdlIGFyZSBnb2luZyB0byBoYXZlIGEgbnVtYmVy IG9mIHZlcnNpb25zIG9mIHRoZSBDRE4tSSBNZXRhZGF0YT8NCg0KSSBzeW1wYXRoaXNlIHdpdGgg d2hhdCB5b3UgYXJlIHBvaW50aW5nIG91dCBiZWxvdyBhbmQgZG8gYWdyZWUgdGhhdCB0aGVyZSBp cyBzb21lIHdvcmsgdG8gYmUgZG9uZSwgYnV0IEkgc3RpbGwgZmVlbCB0aGF0IGNvbnRlbnQgYWRh cHRhdGlvbiBpcyB0byBtZSBhIGZ1bmRhbWVudGFsIHJlcXVpcmVtZW50IHRvIHdoYXQgY29sbGVj dGl2ZWx5IHdlIHNob3VsZCBhZGRyZXNzIGluIHRoZSBDRE4tSSBXRy4gSSBkbyBhZ3JlZSB3aXRo IHlvdSB0aGF0IGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBhbiBvcHRpbWl6YXRpb24gYmV0d2VlbiBD RE4ncyBidXQgaXQncyBhIHZlcnkgaW1wb3J0YW50IG9uZSB0aGF0IEkga25vdyBOZXR3b3JrIFNl cnZpY2UgUHJvdmlkZXJzIHBhcnRpY3VsYXJseSByZXF1aXJlLg0KDQpBbGFuDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBjZG5pLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNk bmktYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBCZW4gTml2ZW4tSmVua2lucw0KU2VudDogT2N0b2Jlci0xMi0xMSAxOjEzIFBNDQpU bzogWmhvdVpoaXBlbmcNCkNjOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtDRE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2Vz LTAwLnR4dA0KDQpaaGlwZW5nLA0KDQpPbiAxMiBPY3QgMjAxMSwgYXQgMTA6MjIsIFpob3VaaGlw ZW5nIHdyb3RlOg0KDQoNCg0KSGVsbG8gQmVuLA0KVGhlIFVFIG1heSBzZWxlY3QgdGhlIGNvbnRl bnQgZm9ybWF0IG9uIHRoZSBDUCB3ZWIuIEFmdGVyIHRoYXQgdGhlIHVzZXIgb25seSBkZXNpcmVz IHRvIGdldCBoaXMgc2VsZWN0ZWQgY29udGVudC4NCkJ1dCBob3cgdGhlIGNvbnRlbnQgaXMgdHJh bnNmZXJyZWQgdG8gdGhlIGNsaWVudCBpcyBub3Qgd29ycmllZCBieSB0aGUgdXNlci4NClRoZSBD UCBtYXkgY3JlYXRlIGEgc3BlY2lhbCBmb3JtYXQgYXMgcmVxdWlyZWQgYnkgdGhlIHVzZXIgYW5k IGFzayB0aGUgQ0ROIHRvIGRlbGl2ZXIgdG8gdXNlci4NCldoaWxlIENQIG1heSBnaXZlIGEgSEQg Zm9ybWF0IGNvbnRlbnQgdG8gdUNETiBhbmQgdGhlIGRDRE4gbWF5IHRoZW4gdHJhbnNmb3JtIHRv IHRoZSBmb3JtYXQgYXMgdGhlIHVzZXIgc2VsZWN0Lg0KDQpMb3RzIG9mIHRoaW5ncyBtYXkgYmUg cG9zc2libGUgdG8gZG8gYW5kIENETiBwcm92aWRlcnMgb2ZmZXIgbWFueSBhZGRpdGlvbmFsIHNl cnZpY2VzIG9uIHRvcCBvZiB0aGUgImNvcmUiIHNlcnZpY2Ugb2YgY29udGVudCBkZWxpdmVyeS4g SG93ZXZlciwgb3VyIG9iamVjdGl2ZSAoYmFzZWQgb24gbXkgaW50ZXJwcmV0YXRpb24gb2YgdGhl IENETkkgY2hhcnRlcikgaXMgdG8gZm9jdXMgb24gd2hhdCBpcyBuZWNlc3NhcnkgdG8gaW50ZXJj b25uZWN0IENETnMgdG8gZGVsaXZlciBjb250ZW50IGZyb20gYSBDU1AgdG8gYW4gRW5kIFVzZXIg dGhhdCBpcyB0YXJnZXRlZCBhbmQgZGVwbG95YWJsZSB3aXRoaW4gYSBzaG9ydCB0aW1lIGZyYW1l ICgxOC0yNCBtb250aHMpLg0KDQpDb250ZW50IHRyYW5zZm9ybWF0aW9uL2FkYXB0YXRpb24gaXMg bm90IGFuIGVzc2VudGlhbCByZXF1aXJlbWVudCBpbiBvcmRlciB0byBhY2hpZXZlIHRoYXQgYWlt ICh3ZSBjYW4gZGVsaXZlciBjb250ZW50IGZyb20gQ1NQcyB0byBFbmQgVXNlcnMgdmlhIG11bHRp cGxlIENETnMgd2l0aG91dCBuZWVkaW5nIG9yIHJlcXVpcmluZyBhbnkgQ0ROIHN1cHBvcnRzIGNv bnRlbnQgYWRhcHRhdGlvbikuDQoNCkluIG15IG9waW5pb24gd2UgaGF2ZSBlbm91Z2ggd29yayB0 byBkbyBhbHJlYWR5IHdpdGhvdXQgdHJ5aW5nIHRvIGV4cGFuZCB0aGUgc2NvcGUgb2Ygb3VyIHdv cmsgdG8gaW5jbHVkZSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyB0aGF0IGRvIG5vdCBoZWxwIHVz IGFkZHJlc3Mgb3VyIGNvcmUgb2JqZWN0aXZlcyBhcyBsYWlkIG91dCBpbiB0aGUgQ0ROSSBjaGFy dGVyLg0KDQoNCg0KSW4gdGhpcyBjYXNlLCBpdCBpcyBub3RoaW5nIHJlbGF0ZWQgdG8gaG93IHRo ZSB1c2VyIHNlbGVjdCBmb3JtYXRzIG9uIENQIHdlYnNpdGUuDQpTbywgaXQgaXMgdGhlIENQIGFu ZCB1c2VyIHRvIGRlY2lkZSB0aGUgY29udGVudCBmb3JtYXQgbm90IHRoZSBDRE4oeW91ciBhc3Nl cnQgaXMgbm90IGNvcnJlY3QgYW5kIHNlZW1zIHlvdSB0YWtlIHRoYXQgYXNzZXJ0IGFzIHlvdXIg YmFzZSBmb3IgdGhlIGRpc2N1c3Npb24pLg0KDQpBcyBmb3IgInRoZSBjb3JlIENETiBmdW5jdGlv bmFsaXR5IG9mZmVyZWQgYnkgQ0ROcyB0b2RheSIsIEkgaGF2ZSBldmVyIHJhaXNlZCBhbiBlbWFp bCBiZWZvcmUgdGhhdCB5b3VyIGNvbXBhbnkncyB3ZWJwYWdlIGhhcyBjbGFpbWVkIHN1cHBvcnRp bmcgbWVkaWEgdHJhbnNmb3JtYXRpb24gYW5kIG11bHRpLXNjcmVlbiBzZXJ2aWNlLg0KUGVyaGFw cywgSSBsaWtlIGFza2luZyB5b3UgbGlzdCBzb21lIGZlYXR1cmVzIHRoYXQgeW91IGZlZWwgYXJl IHRoZSBjb3JlIGZ1bmN0aW9uYWxpdGllcyBieSBleGlzdGluZyBtYWluIHN0cmVhbSBDRE5zLiBU aHVzIHdlIG1heSBjb21wYXJlIGFuZCB0YWtlIGRlZXAgbG9vay4NCg0KSSB0aGluayB0aGUgY29y ZSBmdW5jdGlvbmFsaXR5IG1hcHMgcHJldHR5IHdlbGwgdG8gdGhlIENETkkgaW50ZXJmYWNlcywg bmFtZWx5OiBSZXF1ZXN0IFJvdXRpbmcsIE1ldGFkYXRhIGNvbmZpZ3VyYXRpb24sIGxvZyBwcm9k dWN0aW9uIGFuZCBjb250cm9sIHBsdXMgY29udGVudCBhY3F1aXNpdGlvbiBhbmQgY29udGVudCBk ZWxpdmVyeS4NCg0KDQoNCkkgZ3Vlc3MgbWFueSBwZW9wbGUgaGF2ZSB0aGUgZXhwZXJpZW5jZS9r bm93bGVkZ2Ugb2YgY29udGVudCByZWxhdGVkIHNlcnZpY2UuIFRoZSB1c2VyIGFuZCBDUCBvbmx5 IGNhcmUgd2hldGhlciB0aGUgQ0ROIHByb3ZpZGVycyBtYXkgc2F0aXNmeSB0aGVpciByZXF1aXJl bWVudCB3aGlsZSBub3QgY2FyZSB0aGUgaW50ZXJuYWwgcHJvY2Vzcy4gSnVzdCBhcyBHU00vUFNU TiBpbnRlcmNvbm5lY3Rpb24sIHRoZSB1c2VyIG9ubHkgY2FyZSBzdWNjZXNzZnVsIGludGVyY29u bmVjdGlvbiB3aGlsZSBub3QgY2FyZSBob3cgdGhlIHZvaWNlIGlzIHRyYW5zZm9ybWVkIGluIHBy b2Nlc3MuDQoNCkJlc2lkZXMsIEkgbGlrZSByYWlzZSBhIGNhc2U6DQpHaXZlbiBjdXJyZW50bHkg QkJDIHJlY3J1aXRzIENETiBwcm92aWRlcnMgdGhhdCBtYXkgc3VwcG9ydCAxMCBtZWRpYSBmb3Jt YXRzLg0KT25lIGNhbmRpZGF0ZSBpcyB5b3VyIGNvbXBhbnksIGFub3RoZXIgaXMgQ0ROLVguIFRo ZSB1c2VycyBhcmUgbG9jYXRlZCBpbiBGcmFuY2UuDQpTbyBib3RoIHlvdXIgY29tcGFueSBhbmQg Q0ROLVggc2hvdWxkIGNvbm5lY3QgYSBGcmFuY2UgQ0ROIHByb3ZpZGVyKENETi1ZKS4NCklmIHlv dXIgY29tcGFueSdzIHNvbHV0aW9uIGlzIHRvIHNlbmQgMTAgc3RyZWFtcyBvZiBkaWZmZXJlbnQg Zm9ybWF0DQpvZiBvbmUgY29udGVudCB0byBDRE4tWTsgV2hpbGUgQ0ROLVgncyBzb2x1dGlvbiBp cyB0byBzZW5kIDEgc3RyZWFtIHRvIENETi1ZIHdoaWxlIENETi1ZIG1heSBjb25kdWN0IHNvbWUg YWRhcHRhdGlvbi4NCkNvbXBhcmluZyB0aGVzZSB0d28gc29sdXRpb25zLCBmb3IgeW91ciBjb21w YW55IGFuZCBDRE4tWCwgYWJzb2x1dGVseSB0aGUgY29zdCBvZiBDRE4tWCBpcyBtdWNoIGxvd2Vy Lg0KRm9yIENETi1ZLCBpbiBzb2x1dGlvbi0xLCBpdCBzaG91bGQgcmVjZWl2ZS9mb3J3YXJkIDEw IHN0cmVhbXMgOyB3aGlsZSBpbiBzb2x1dGlvbi0yLCBpdCBzaG91bGQgb25seSByZWNlaXZlIDEg c3RyZWFtIGJ1dCBuZWVkIHRvIHRha2UgdHJhbnNmb3JtYXRpb24gdG8gb3V0cHV0IDEwIHN0cmVh bXMuDQoNCldoaWNoIHNvbHV0aW9uIGlzIG1vcmUgY29tcGV0aXRpdmUuIGl0IGlzIFNvbHV0aW9u IDEsIHJpZ2h0LiBSZW1lbWJlciB0aGUgcHJpY2UgZnJvbSBCQkMgaXMgc2FtZSB0byBib3RoIHlv dXIgY29tcGFueSBhbmQgQ0ROLVggb3IgQkJDIHdvdWxkIHNlbGVjdCBvbmUgQ0ROIHByb3ZpZGVy IHdpdGggdGhlIGxvd2VyIHByaWNlLg0KSWYgYSBDRE4gcHJvdmlkZXIgbWF5IG5vdCBnZXQgdGhl IGNvbnRyYWN0IGZyb20gQ1AsIGhvdyBpdCBtYXkgc2F5IGl0IGlzIG5vdCBhIGNvcmUgZnVuY3Rp b25hbGl0eS4NCg0KV2hhdCB5b3UgYXJlIGRlc2NyaWJpbmcgaXMgYSBwb3NzaWJsZSBvcHRpbWl6 YXRpb24gdGhhdCBhIHBhcnRpY3VsYXIgQ0ROIG1heSB3aXNoIHRvIGltcGxlbWVudCBub3QgYSBj b3JlIGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQgdG8gZW5hYmxlIGNvbnRlbnQgZGVsaXZlcnkgYmV0 d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5zLiBJIGNhbiB0aGluayBvZiBtYW55IG9wdGltaXphdGlv bnMgdGhhdCBhIENETiBjb3VsZCBpbXBsZW1lbnQgdG8gZGlmZmVyZW50aWF0ZSB0aGVpciBzZXJ2 aWNlIGJ1dCB0aGUgaW50ZXJuYWwgd29ya2luZ3Mgb2YgYW4gaW5kaXZpZHVhbCBDRE4gYXJlIG91 dCBvZiBzY29wZSBvZiBvdXIgY2hhcnRlci4NCg0KU28gdG8gcmVwZWF0IG15IHBvc2l0aW9uIGZv ciBhIGZpbmFsIHRpbWU6IENvbnRlbnQgYWRhcHRhdGlvbiBpcyBub3QgYSBjb3JlIGZ1bmN0aW9u IHJlcXVpcmVkIHRvIGVuYWJsZSBjb250ZW50IGRlbGl2ZXJ5IGJldHdlZW4gaW50ZXJjb25uZWN0 ZWQgQ0ROcyBhbmQgdGhlcmVmb3JlIGdpdmVuIHRoZSB3b3JrbG9hZCB3ZSBhbHJlYWR5IGhhdmUg dG8gc3BlY2lmeSBzb2x1dGlvbnMgdGhhdCBkbyBhZGRyZXNzIHRoZSBjb3JlIGZ1bmN0aW9uYWxp dHkgcmVxdWlyZWQgdG8gaW50ZXJjb25uZWN0IENETnMgSSBkbyBub3QgdGhpbmsgd2Ugc2hvdWxk IGJlIHRyeWluZyB0byBhZGQgbW9yZSB3b3JrIGludG8gdGhhdCB3b3JrbG9hZCBhcyBpdCB3aWxs IG9ubHkgZGlzdHJhY3QgdXMgZnJvbSBhY2hpZXZpbmcgb3VyIGdvYWwgb2YgcHJvZHVjaW5nIGRl cGxveWFibGUgc29sdXRpb25zIHdpdGhpbiB0aGUgdGltZWZyYW1lIHdlIGFyZSBiZWluZyB0b2xk IGJ5IG9wZXJhdG9ycyB0aGV5IG5lZWRzIHNvbHV0aW9ucyB3aXRoaW4uDQoNCkJlbg0KDQoNCg0K U28sIGlmIHdlIGFsbCByZWFsaXplIHRoYXQgY3VycmVudGx5IHRoZSBtZWRpYSB0eXBlIGlzIHJp Y2gsIHRoZSBDRE4gcHJvdmlkZXJzIHNob3VsZCBzdXJ2aXZlIGluIHRoZSBleGlzdGluZyBlY29z eXN0ZW0gYW5kIHN1cHBvcnQgdGhlIG1lZGlhIHR5cGVzIGFzIHJlcXVpcmVkIGJ5IHRoZSBtYXJr ZXQuDQoNCkJhY2sgdG8gdGhlIGNhc2Ugb2YgR1NNL0cuNzExLCBpdCBqdXN0IHdoZW4gY29uY2Vy bmluZyB0aGUgaW50ZXJjb25uZWN0aW9uLCB0aGUgdHJhbnNmb3JtYXRpb24gc2hvdWxkIGF0IG9u Y2UgYmUgc29sdmVkLiBPdGhlcndpc2UgdGhlIGludGVyY29ubmVjdGlvbiBtYXkgbm90IGJlIG9w ZXJhdGVkLg0KDQpCciwNClpoaXBlbmcNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IEJlbiBOaXZlbi1KZW5raW5zIFttYWlsdG86YmVuQG5pdmVuLWplbmtpbnMuY28u dWtdDQpTZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIwMTEgMTI6MTkgQU0NClRvOiBaaG91 WmhpcGVuZw0KQ2M6IHBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxtYWlsdG86cGhpbGlwLmVhcmRsZXlA YnQuY29tPjsgY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0wMC50eHQNCg0K WmhpcGVuZywNCg0KT24gMTEgT2N0IDIwMTEsIGF0IDA1OjE2LCBaaG91WmhpcGVuZyB3cm90ZToN Cg0KQmVuIGFuZCBQaGlsaXAsDQpJIGxpa2UgdG8gcmVzcG9uZCB5b3VyIGNvbmNlcm4gaW4gdGhp cyBvbmUgZW1haWw6DQoNCkJlbiwNCkkgZmVlbCB3aGF0IHdlIGFyZSBub3cgZGlzY3Vzc2luZyBp cyB3aGF0IGlzIHRoZSAiY29yZSIgZnVuY3Rpb24gb2YgQ0ROLg0KQXMgeW91IHNheSwgQ0ROIGlz IHVzZWQgdG8gZGVsaXZlciBjb250ZW50LiBUaGF0IGlzIGFic29sdXRlbHkgY29ycmVjdCB0aGF0 IHRoZSBkZWxpdmVyeSBjYXBhYmlsaXR5IGlzIHRoZSBjb3JlIHJlcXVpcmVtZW50IGZvciBDRE4g c3lzdGVtLg0KV2hpbGUgQ0ROIGlzIHVzZWQgdG8gcHJvdmlkZSB0aGUgY29udGVudCBkZWxpdmVy eSBzZXJ2aWNlLg0KV2hhdCBtZWFucyBzZXJ2aWNlLiBJdCBzaG91bGQgaW5jbHVkZSAidGltZSIg ImxvY2F0aW9uIiBhbmQgIm1lZGlhIHR5cGUiLCBldGMuIFRoZXNlIGZlYXR1cmVzIGFyZSBhbGwg dGhlIGNvcmUgZmVhdHVyZSBmb3IgYSBzZXJ2aWNlLg0KSWYgd2Ugb25seSBjb25jZXJuICJkZWxp dmVyaW5nIG9uZSBkYXRhIGJsb2NrIiwgSSBhbSBub3Qgc3VyZSB3aGV0aGVyIHRoZSBpc3N1ZXMg c3VjaCBhcyAibG9nZ2luZyIgImdlb2dyYXBoaWMgY29uc3RyYWludCIgYXJlIHRoZSBjb3JlIG9m IENETi4NCg0KRm9yICJ3aXRob3V0IGV4cGxpY2l0IGtub3dsZWRnZSBvZiB3aGF0IHRoYXQgY29u dGVudCBhY3R1YWxseSBpcyAiLCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIHdvcmRpbmcgaXMg YWNjdXJhdGUgc2luY2UgZ2VuZXJhbGx5IGEgQ0ROIG1heSBjbGFpbSBpdCBzdXBwb3J0IGRpZmZl cmVudCBtZWRpYXMuDQpCeSB0aGlzIG9wcG9ydHVuaXR5LCBJIGxpa2UgdG8gc2hhcmUgYSB1c2Ug Y2FzZTogYSBjYWxsIGZyb20gYSBHU00gcGhvbmUgdG8gYSBQU1ROIHRlbGVwaG9uZSwgdGhlIHZv aWNlIHN0cmVhbSBzaG91bGQgYmUgdHJhbnNmb3JtZWQgZnJvbSBHU00gdm9pY2UgdG8gRy43MTEu DQpGb3IgdGhlIHVzZXIsIGhlIGRvZXMgbm90IG5lZWQgdG8ga25vdyB3aGF0IHR5cGUgb2YgZGF0 YSBoYXMgYmVlbiB0cmFuc2ZlcnJlZCwgYnV0IHRoZSBvcGVyYXRvciBoYXMgZG9uZSBzb21lIHdv cmsgdG8gaW50ZXJjb25uZWN0IHR3byBzeXN0ZW1zLCByaWdodC4NCkkgbGlrZSB0byBrbm93IHdo ZXRoZXIgeW91IG1heSBhY2NlcHQgdGhhdCBteSB1c2UgY2FzZSBpcyBzaW1pbGFyIHRvIHRoaXMg Y2FzZSBhYm92ZS4NCg0KSSBkb24ndCB0aGluayB5b3VyIHVzZSBjYXNlIGlzIHNpbWlsYXIgdG8g dGhlIGFuYWxvZ3kgb2YgbW9iaWxlIG5ldHdvcmtzIGJlaW5nIGludGVyY29ubmVjdGVkIHRvIFBT VE4gbmV0d29ya3MuIEluIHRoZSBjYXNlIG9mIGNvbnRlbnQgZGVsaXZlcnkgdGhlIG5lZ290aWF0 aW9uIGlzIGRvbmUgYmV0d2VlbiB0aGUgVXNlci9DbGllbnQgYW5kIHRoZSBDb250ZW50IFByb3Zp ZGVyIGFuZCB0aGUgQ0ROIGlzIGp1c3QgdXNlZCB0byBleGVjdXRlL3BlcmZvcm0gdGhlIGRlbGl2 ZXJ5IHRoYXQgaGFzIGJlZW4gbmVnb3RpYXRlZC4gVGhlIENETiBpcyBub3QgaW52b2x2ZWQgaW4g dGhlIGRlY2lzaW9uIG1ha2luZyBvZiB3aGF0IHJlcHJlc2VudGF0aW9ucyB0aGUgQ29udGVudCBQ cm92aWRlciBkZWNpZGVzIHRvIG9mZmVyIHRvIHRoZSBVc2VyL0NsaWVudCBvciBpbiB3aGF0IHJl cHJlc2VudGF0aW9ucyB0aGUgVXNlci9DbGllbnQgZGVjaWRlcyB0byByZXF1ZXN0Lg0KDQpBcyBm b3IgeW91IHNhaWQgc2VsZWN0aW5nIG1lZGlhIGJ5IHRoZSAicG9ydGFsIiwgeW91IG1heSBzZWUg dGhlIHdheSAiIHVDRE4gZGVsaXZlcnMgbXVsdGlwbGUgbWVkaWEgc3RyZWFtcyB0byBkQ0ROIiBp cyBub3QgZ29vZCB0aGFuICJ1Q0ROIGRlbGl2ZXJzIG9uZSBtZWRpYSBzdHJlYW0gdG8gZENETiBh bmQgZENETiB0YWtlcyBzb21lIGFkYXB0YXRpb24gdG8gc3VwcG9ydCBtdWx0aXBsZSBtZWRpYSB0 eXBlcyIuDQoNCk5vdyB3aGF0IHlvdSdyZSB0YWxraW5nIGFib3V0IGlzIGFuIG9wdGltaXNhdGlv biwgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBhY3R1YWxseSBkZWxpdmVyIHRoZSBj b250ZW50IChhbmQgcmVwb3J0LCBiaWxsLCBldGMuIGZvciB0aGF0IGRlbGl2ZXJ5KS4NCg0KTXkg cG9zaXRpb24gaXMgdGhhdCB3ZSBzaG91bGQgZm9jdXMgb24gaG93IHRvIGVuYWJsZSB0aGUgaW50 ZXJjb25uZWN0aW9uIG9mIHRoZSBjb3JlIENETiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgQ0RO cyB0b2RheSAod2hpY2ggaXMgYWxzbyBteSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgc2NvcGUgb2Yg dGhlIENETkkgd29ya2luZyBncm91cCBhcyBleHByZXNzZWQgaW4gaXRzIGNoYXJ0ZXIpIGJlY2F1 c2UgZG9pbmcgc28gaXMgYSBzaWduaWZpY2FudCBwaWVjZSBvZiB3b3JrIGluIGl0c2VsZi4gTGV0 J3Mgbm90IHN0YXJ0IHRyeWluZyB0byBhZGQgaW4gYWRkaXRpb25hbCBmdW5jdGlvbmFsaXR5IGJl eW9uZCB3aGF0IHRoZSBtYWpvcml0eSBvZiBDRE5zIHN1cHBvcnQgdG9kYXkgYXMgdGhhdCB3aWxs IGp1c3QgZGVsYXkgdXMgZ2V0dGluZyB1c2FibGUgc3BlY2lmaWNhdGlvbnMgaW50byB0aGUgbWFy a2V0IGluIGEgdGltZWx5IGZhc2hpb24gSU1PLg0KDQpCZW4NCg0KQSBnb29kIHF1ZXN0aW9uIGlz ICJzZWN1cml0eSIgc2luY2UgSSBoYXZlIGRvbmUgc2l4IHllYXJzIG9uIHRoZSBEUk0NCmFuZCBs aWtlIHRvIHByb21vdGUgdGhlIERSTSBhbGwgYXJvdW5kIHRoZSB3b3JsZDopIElmIHRoZSBjb250 ZW50IGlzIG5lZWRlZCB0byBiZSBwcm90ZWN0ZWQsIGdlbmVyYWxseSB5b3UgbWF5IGtub3cgYWxs IHRoZSBzeXN0ZW1zIHNob3VsZCBiZSBncmFudGVkIGJ5IHRoZSBjb250ZW50IG93bmVyLg0KSGVy ZSBJIGFsc28gbGlrZSB0byBjbGFyaWZ5IHRoYXQgbm90IG9ubHkgdGhlIG1lZGlhIGl0c2VsZiBi dXQgdGhlIGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gc2VydmljZSBpdHNlbGYgKHN1Y2ggYXMgdGhl IGdlb2dyYXBoaWMgY29uc3RyYWludCkgc2hvdWxkIGJlIHByb3RlY3RlZCBhbHNvLg0KU28sIHRy dXN0IGlzIG5vdCBhIHByb2JsZW0gZm9yIHRoZSBtZWRpYS4NCg0KUGhpbGlwLA0KVGhhbmsgeW91 IHRoYXQgeW91IGZlZWwgQ29udGVudCBBZGFwdGlvbiBpcyBhbiBpc3N1ZSBmb3IgIlJlcXVpcmVt ZW50cyIgYnV0IEkgZG8gbm90IGtub3cgd2h5IGl0IGlzIG5vdCBmb3IgVXNlIGNhc2UuDQpJIGxp a2UgdG8gY2xhcmlmeSB0byBVIHRoYXQgaXQgaXMgaW1wb3J0YW50IGZvciB5b3Ugb3BlcmF0b3Ig c2luY2UgaXQgbWF5IHNhdmUgaW52ZXN0bWVudCBpZiB0aGUgc3lzdGVtIG1heSBzdXBwb3J0IGRp ZmZlcmVudCBzZXJ2aWNlcy4NCkZvciB1cyB2ZW5kb3IsIHdlIGFyZSBoYXBweSBvcGVyYXRvciBt YXkgaW5zdGFsbCBhIHN5c3RlbSBmb3IgdGhlIG1vYmlsZSBzZXJ2aWNlIGFuZCBhbm90aGVyIHN5 c3RlbSBmb3IgdGhlIEZCQiBzZXJ2aWNlLg0KQnV0IHRoZSByZWFsaXR5IGlzIGFsbCBvcGVyYXRv cnMgYXNrIHVzIHRvIHByb3ZpZGUgYSBzeXN0ZW0gdGhhdCBtYXkgc3VwcG9ydCBkaWZmZXJlbnQg c2VydmljZSBzeXN0ZW1zLg0KDQpGcmFua2x5LCBCZW4gYW5kIFBoaWxpcCwgSSByZW1lbWJlciBJ IGhhdmUgZXhwbGFpbmVkIHNvbWV3aGVyZSB0aGF0IHRvIGltcGxlbWVudCB0aGlzIGlzIHJhdGhl ciBzaW1wbGUgLg0KQXQgbGVhc3QgdGhlIFVzZSBjYXNlIGFuZCBSZXF1aXJlbWVudCBhcmUgaW5m b3JtYXRpb25hbCB0byBiZSByZWZlcnJlZCBpbiBmdXR1cmUgd29yay4gU28gSSBkbyByZWFsbHkg ZmVlbCB5b3UgbWF5IGFjY2VwdCBpdC4NCk9mIGNvdXJzZSBJIGxpa2UgdG8gcmVzcG9uZCB5b3Vy IG1vcmUgY29uY2VybiBhbmQgY29tbWVudHMuDQpUaGFua3MuDQpaaGlwZW5nDQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogcGhpbGlwLmVhcmRsZXlAYnQuY29tPG1haWx0 bzpwaGlsaXAuZWFyZGxleUBidC5jb20+IFttYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tXQ0K U2VudDogTW9uZGF5LCBPY3RvYmVyIDEwLCAyMDExIDExOjIyIFBNDQpUbzogYmVuQG5pdmVuLWpl bmtpbnMuY28udWs8bWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPjsgWmhvdVpoaXBlbmcN CkNjOiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtD RE5pXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNkbmktdXNlLWNhc2VzLTAwLnR4dA0KDQpCZW4s IFpoaXBlbmcsIGFsbCwNCg0KSSB0aGluayB0aGF0IENvbnRlbnQgQWRhcHRhdGlvbiBpcyBtb3Jl IGFuIGlzc3VlIGZvciB0aGUgUmVxdWlyZW1lbnRzIGRvYyB0aGFuIGZvciB0aGUgVXNlIGNhc2Vz IGRyYWZ0Lg0KDQpUaGUga2V5IHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ugd2FudCB0aGUgQ0ROSSBp bnRlcmZhY2VzIHRvIGJlIGFibGUgdG8gY29wZSB3aXRoIGEgc2NlbmFyaW8gd2hlcmUgKHNheSkg SEQvU0QgY29udmVyc2lvbiBpcyBkb25lIGluIHRoZSBkQ0ROICYgdG8gc2lnbmFsIGFib3V0IHRo aXMuDQoNCkkgdGhpbmsgdGhhdCBjb3Bpbmcgd2l0aCB0aGlzIHNjZW5hcmlvIGlzIGEgc2Vjb25k IG9yZGVyIHJlcXVpcmVtZW50LCBpZSB3ZSBzaG91bGQgbm90IHdvcnJ5IGFib3V0IGl0IGluIHRo ZSBpbml0aWFsIHN0YW5kYXJkcy10cmFjayB3b3JrLiBJIGRvbid0IGtub3csIGRpZCB3ZSBldmVy IGRlY2lkZSB3aGV0aGVyIHRoZSBVc2UgY2FzZXMgZG9jIGlzIHJlc3RyaWN0ZWQgdG8gImluaXRp YWwiIHNjZW5hcmlvcywgb3Igd2hldGhlciBpdCdzIGFsbC1lbmNvbXBhc3NpbmcsIGllIGNvdmVy aW5nICJmdXR1cmUiIHNjZW5hcmlvcyBhcyB3ZWxsPw0KDQpTY290dCwNClJlYWRpbmcgc29tZSBv ZiB5b3VyIGV4YW1wbGVzLCB0aGV5IHNlZW0gdG8gYmUgdmFsaWQgZXZlbiBpZiBjb250ZW50IGFk YXB0YXRpb24gKEhEL1NEKSBpcyBvdXQgb2Ygc2NvcGUuDQotIGEgZENETiBtaWdodCBmb3Igc29t ZSByZWFzb24gYmUgdW53aWxsaW5nIHRvIGRpc3RyaWJ1dGUgSEQ/DQotIGEgQ1NQIG1pZ2h0IHdh bnQgdG8gbWFrZSBzdXJlIHRoZSBkQ0ROIGNhbiB1c2UgSExTIGVuY2Fwc3VsYXRpb24/DQpCdXQg dGhlc2Ugc29ydHMgb2YgZXhhbXBsZXMgc2VlbSB0byBiZSBzdGF0aWMgcG9saWN5IHRoaW5ncyAo dG8gZG8NCndpdGggdGhlIGNhcGFiaWxpdGllcyAmIHByZWZlcmVuY2VzIG9mIHRoZSBDRE5zICYg Q1NQKSwgcmF0aGVyIHRoYW4NCm1ldGFkYXRhIGFzc29jaWF0ZWQgd2l0aCBhIHBhcnRpY3VsYXIg cGllY2Ugb2YgY29udGVudC4gSW4gdGhlDQpkaXNjdXNzaW9uIHNvIGZhciwgSSB0aGluayBuZWdv dGlhdGlvbiBhYm91dCBzdGF0aWMgcG9saWN5IHN0dWZmIGlzDQpyYXRoZXIgb3V0IG9mIHNjb3Bl KD8pDQoNCk9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbiBpbnRlcmVzdGluZyBxdWVzdGlv biBpcyB3aGV0aGVyIHRydXN0IGlzIHRyYW5zaXRpdmUuIERvbid0IHRoaW5rIGl0IG5lZWQgYmUg LSBqdXN0IGJlY2F1c2UgQ1NQIHRydXN0cyB1Q0ROLCBhbmQgdUNETiB0cnVzdHMgZENETiBkb2Vz bid0IG1lYW4gdGhhdCB0aGUgQ1NQIGF1dG9tYXRpY2FsbHkgdHJ1c3RzIHRoZSBkQ0ROLiBIb3dl dmVyLCBpIHN1c3BlY3QgdGhpcyBjYW4gZ2V0IGFyYml0cmFyaWx5IGNvbXBsZXggLSBzbyBvbmUg cG9zc2liaWxpdHkgaXMgdG8gc2F5IHRoYXQgd2Ugd2lsbCBvbmx5IGhhbmRsZSBjYXNlcyB3aGVy ZSB0aGUgdHJ1c3QgaXMgdHJhbnNpdGl2ZS4NCg0KQmVzdCB3aXNoZXMNCnBoaWwNCg0KDQpQaGls aXAgRWFyZGxleQ0KUmVzZWFyY2ggYW5kIFRlY2hub2xvZ3kgU3RyYXRlZ3kNCg0KVGhpcyBlbWFp bCBjb250YWlucyBCVCBpbmZvcm1hdGlvbiwgd2hpY2ggbWF5IGJlIHByaXZpbGVnZWQgb3IgY29u ZmlkZW50aWFsLiBJdCdzIG1lYW50IG9ubHkgZm9yIHRoZSBpbmRpdmlkdWFsKHMpIG9yIGVudGl0 eSBuYW1lZCBhYm92ZS4gSWYgeW91J3JlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBub3Rl IHRoYXQgZGlzY2xvc2luZywgY29weWluZywgZGlzdHJpYnV0aW5nIG9yIHVzaW5nIHRoaXMgaW5m b3JtYXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91J3ZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBsZXQgbWUga25vdyBpbW1lZGlhdGVseSBvbiB0aGUgZW1haWwgYWRkcmVz cyBhYm92ZS4gVGhhbmsgeW91LiBXZSBtb25pdG9yIG91ciBlbWFpbCBzeXN0ZW0sIGFuZCBtYXkg cmVjb3JkIHlvdXIgZW1haWxzLg0KQnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgcGxjDQpSZWdp c3RlcmVkIG9mZmljZTogODEgTmV3Z2F0ZSBTdHJlZXQgTG9uZG9uIEVDMUEgN0FKIFJlZ2lzdGVy ZWQgaW4NCkVuZ2xhbmQgbm86IDE4MDAwMDANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogY2RuaS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5v cmc+IFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCk9mIEJlbiBOaXZl bi1KZW5raW5zDQpTZW50OiAxMCBPY3RvYmVyIDIwMTEgMTI6MDQNClRvOiBaaG91WmhpcGVuZw0K Q2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0NE TmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0DQoNCkNvbGxl YWd1ZXMsDQoNCklNTyBTZWN0aW9uIDUuMS4zIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIFVz ZSBDYXNlcyBkcmFmdC4gQ29udGVudCBBZGFwdGF0aW9uIChpLmUuIHRha2luZyBpbiBhIGNvbnRl bnQgaXRlbSBpbiBvbmUgZm9ybWF0IGFuZCB0cmFuc2Zvcm1pbmcgaXQgdG8gYW5vdGhlciBmb3Jt YXQgb3IgcmVwcmVzZW50YXRpb24pIGlzIG5vdCBhICJjb3JlIiBmdW5jdGlvbiBvZiBhIENETiB3 aGljaCB0eXBpY2FsbHkgZGVsaXZlcnMgdGhlIGNvbnRlbnQgdGhhdCBpcyByZXF1ZXN0ZWQgd2l0 aG91dCBleHBsaWNpdCBrbm93bGVkZ2Ugb2Ygd2hhdCB0aGF0IGNvbnRlbnQgYWN0dWFsbHkgaXMu DQoNCkxldCdzIG5vdCBmb3JnZXQgdGhhdCBpbiBidWlsZGluZyBhbiBlbmQgdG8gZW5kIGNvbnRl bnQgc2VydmljZSB0aGUgQ0ROIGlzIG9ubHkgb25lIGNvbXBvbmVudCBhbmQgaXMgdGhlIGNvbXBv bmVudCB0YXNrZWQgd2l0aCBleGVjdXRpbmcgdGhlIGRlbGl2ZXJ5IG9mIGEgc3BlY2lmaWMgcmVw cmVzZW50YXRpb24gKHZlcnNpb24vY29weS9mb3JtYXQgZXRjLikgb2YgdGhlIHNlbGVjdGVkIGNv bnRlbnQgbm90IHRoZSBjb21wb25lbnQgdGFza2VkIHdpdGggZGVjaWRpbmcgKG9yIGFwcGx5aW5n IHBvbGljeSkgb24gd2hpY2ggdmVyc2lvbi9jb3B5L3JlcHJlc2VudGF0aW9uIG9mIGNvbnRlbnQg c2hvdWxkIGJlIGRlbGl2ZXJlZC4NCg0KVGhlIGRlY2lzaW9uIGFzIHRvIHdoaWNoIHZlcnNpb24v Y29weS9yZXByZXNlbnRhdGlvbiB0byBvZmZlciBhbmQgYWxsb3cgdG8gYmUgZGVsaXZlcmVkIHRv IGEgZ2l2ZW4gZGV2aWNlL3VzZXIgaXMgaW1wbGVtZW50ZWQgb3V0c2lkZSBvZiB0aGUgQ0ROIChl LmcuIGJ5IHRoZSAicG9ydGFsIiB3aGVyZSB0aGUgdXNlciBmaXJzdCBtYWtlcyB0aGVpciBjb250 ZW50IHNlbGVjdGlvbiBwcmlvciB0byB0aGUgQ0ROIGJlY29taW5nIGludm9sdmVkIGluIHRoZSBk ZWxpdmVyeSBvZiB0aGUgc2VsZWN0ZWQgY29udGVudCkuDQoNCkJlbg0KDQpPbiA4IE9jdCAyMDEx LCBhdCAwODoyMCwgWmhvdVpoaXBlbmcgd3JvdGU6DQoNCkZvbGxvd2luZyBTY290dCdzIGNvbW1l bnRzIG9uIHNlY3Rpb24gNS4xLjMsIEkgZmVlbCBTY290dCdzIGRlc2NyaXB0aW9uIG9uIHRoZSB1 c2UgY2FzZSBvZiBIRCBhbmQgU0QgaXMgbm90IGV4YWN0bHkgY29ycmVjdC4NCklmIG9uZSBtb3Zp ZSBoYXMgdHdvIGZvcm1hdHMgb2YgSEQgYW5kIFNELCB0aGVuIHdlIGhhdmUgdHdvIGNvbnRlbnQg d2l0aCBkaWZmZXJlbnQgaWRlbnRpZmllci4gSW4gRFJNIHNjb3BlLCB0aGUgYmFzaWMgdW5pdCBp cyBhIGNvbnRlbnQgY29weS4NCg0KSGVyZSB0aGUgZmlyc3QgYnVsbGV0ICJhIHN1YnNldCBvZiBl bmNvZGluZ3MgZGVsaXZlcmFibGUgdG8gc3BlY2lmaWMgZGV2aWNlcywiIGhhcyBsaXN0ZWQgdGhl IGNhc2Ugb2YgY29udGVudCBhZGFwdGF0aW9uLg0KSW4gbGFzdCBtb250aCwgSSBoYXZlIGNvbnRh Y3RlZCB0aGUgQXV0aG9ycyBvZiB0aGlzIGRvY3VtZW50IGFuZCB0YWtlbiBzb21lIGVtYWlsIGV4 Y2hhbmdlcyB3aXRoIEdyYW50IGFuZCBQaGlsaXAgKEJUKS4NCkkgaGF2ZSBzaG93biBCVCB3aXRo IHNvbWUgaW5mb3JtYXRpb24gdGhhdCBJIGtub3cgaW4gdGhpcyBjYXNlIGFuZCBhcmVhIHRvIGV4 cGxhaW4gdGhlIGNvbnRlbnQgZmxleGliaWxpdHkgaXMgY3VycmVudGx5IGEgYmFzaWMgcmVxdWly ZW1lbnQgZm9yIENETiBzZXJ2aWNlIGFuZCByZWxhdGVkIG5lZ290aWF0aW9uIGlzIG5lZWRlZCBp biB0aGUgQ0ROIGludGVyY29ubmVjdGlvbi4NCk1lYW53aGlsZSwgSSBzaG91bGQgYWxzbyBpbnZp dGUgeW91IGluIHRoaXMgZ3JvdXAgcmFpc2luZyB5b3VyIGNvbW1lbnRzIG9yIHF1ZXN0aW9ucyBv biB0aGlzIGNhc2Ugc2luY2UgSSBob3BlIG15IHVzZSBjYXNlIG1heSBiZSBpbmNvcnBvcmF0ZWQg aW4gdGhlIHVzZSBjYXNlIGRyYWZ0Lg0KDQpJZiB5b3UgaGF2ZSBhbnkgbW9yZSBxdWVzdGlvbiBv ciBjb21tZW50cywgcGxzIHNoYXJlIGluIHRoaXMgdGhyZWFkLg0KVGhhbmtzLg0KWmhpcGVuZw0K DQoNCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFNjb3R0IFdhaW5u ZXIgW21haWx0bzpzd2Fpbm5lckBjaXNjby5jb21dDQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAz MCwgMjAxMSA4OjAyIEFNDQpUbzogY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNl cy0wMC50eHQNCg0KU2VjdGlvbiAyLjMgTm9tYWRpYyBVc2Vycw0KVGhpcyBkZXNjcmlwdGlvbiBm YWxscyB1bmRlciB0aGUgY2F0ZWdvcnkgb2YgR2VvZ3JhcGhpYyBFeHRlbnNpb24NCnlldCB0aGUg dGhpcmQgcGFyYWdyYXBoIHN0YXRlcyB0aGUgY2FzZSB3aGVyZSBhIGRpZmZlcmVudCBkZXZpY2Ug aXMNCnVzZWQgaW4gdGhlIHNhbWUgQ0ROIGNvdmVyYWdlIGFyZWEuICBUaGUgaW50ZW50IG9mIHRo aXMgdXNlIGNhc2UNCm5lZWRzIHRvIGJlIGNsYXJpZmllZC4gIFBlcmhhcHMgdGhlIHVzZSBjYXNl IGlzIHRyeWluZyB0byBhZGRyZXNzDQp0aGUgc2NlbmFyaW8gd2hlcmUgYSBOb21hZGljIFVzZXIt QSB3aXRoIGFuIGFncmVlbWVudCBhbGxvd2luZw0KYWNjZXNzIHRvIGNvbnRlbnQgZnJvbSBDU1At QSB2aWEgdUNETiBtb3ZlcyB0byBhIGRDRE4gaW4gYSBkaWZmZXJlbnQNCnJlZ2lvbi4gIFRoZSBk Q0ROIGlzIGFsbG93ZWQgdG8gZGlzdHJpYnV0ZSB0aGUgY29udGVudCBvZiBDU1AtQSB0bw0KVXNl ci1BOyBob3dldmVyLCBub3Qgb3RoZXIgdXNlcnMgaW4gdGhlIHJlZ2lvbiBvZiB0aGUgZENETiBh cmUNCmFsbG93ZWQgdG8gcmV0cmlldmUgdGhlIGNvbnRlbnQgdW5sZXNzIHRoZXkgdG9vIGhhdmUg c3VjaCBhbiBhZ3JlZW1lbnQuDQoNClNlY3Rpb24gNS4xLjMgQ29udGVudCBFbmNvZGluZyBSZXN0 cmljdGlvbnMgTmVlZCB0byBjbGFyaWZ5IGlmIHdlJ3JlDQp0YWxraW5nIGFib3V0IHRoZSByZXN0 cmljdGlvbnMgb24gdGhlIGRlbGl2ZXJ5IG9mIHNwZWNpZmljIGNvbnRlbnQNCm9yIHRoZSByZXN0 cmljdGlvbnMgb24gdGhlIGFiaWxpdHkgb2YgYSBDRE4gdG8gZGVsaXZlciBzcGVjaWZpYw0KY29u dGVudC4gIEkgY2VydGFpbmx5IHVuZGVyc3RhbmQgdGhlIGNhc2Ugd2hlcmUgYSBDU1Agd2lsbCBy ZXN0cmljdA0KdGhlIGRpc3RyaWJ1dGlvbiBvZiBjb250ZW50IHRvIGEgIm1hbmFnZWQgcGF0aCIg aWYgc3VjaCBjb250ZW50IGlzDQpIRCB3aGlsZSBhbGxvd2luZyB0aGUgY29udGVudCBkaXN0cmli dXRpb24gdmlhIGFuIHVuLW1hbmFnZWQgcGF0aCBpZg0Kc3VjaCBjb250ZW50IGlzIFNEIChzYW1l IGNvdWxkIGFwcGx5IHRvIGVuY3J5cHRpb24gbWV0aG9kcywgZGVsaXZlcnkNCm1ldGhvZHMsIGV0 Yy4pLiAgT24gdGhlIGNvbnRyYXJ5LCB0aGUgZENETiBtYXkgaGF2ZSBpdHMgb3duDQpyZXN0cmlj dGlvbnMgb2YgYmxvY2tpbmcgdGhlIGRpc3RyaWJ1dGlvbiBvZiBIRCBjb250ZW50IHdoaWxlDQph bGxvd2luZyB0aGUgZGlzdHJpYnV0aW9uIG9mIFNEIGNvbnRlbnQuDQoNCm8gZmlyc3QgYnVsbGV0 IG1ha2VzIHNlbnNlIGlmIHRoZSBkQ0ROIGNhbiBwZXJmb3JtIGEgc3Vic2V0IG9mDQplbmNhcHN1 bGF0aW9ucyBmb3IgYSByZWZlcmVuY2Ugc2V0IG9mIG1lZGlhIChlLmcuIEhMUywgSFNTLCBidXQg bm90DQpEQVNIKSBvIHNlY29uZCBidWxsZXQgbWFrZXMgc2Vuc2Ugd2hlcmUgdGhlIGRDRE4gZG9l c24ndCB3YW50IHRvDQpvZmZlciBoaWdoIGJpdC1yYXRlIHZhcmlhbnRzIG9mIHRoZSBtZWRpYSBv IHRoaXJkIGJ1bGxldCBtYWtlIHNlbnNlDQppZiB0aGUgcG9saWN5IGFkZHJlc3NlcyBRb0UgYnV0 IEkgZG9uJ3QgdGhpbmsgc3Vic2NyaWJlcg0KcmlnaHRzL2F1dGhvcml6YXRpb25zIGFwcGx5Lg0K DQpTZWN0aW9uIDEwIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zDQoNCkFzaWRlIGZyb20gdGhlIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIFdJVEhJTiB0aGUgdUNETiBhbmQgZENETiwgSQ0KdGhpbmsg d2UgY2FuIGRlc2NyaWJlIHRoaXMgaW4gZm91ciBjb250ZXh0czoNCg0KYS4gVGhlIHJlbGF0aW9u c2hpcCBiZXR3ZWVuIHRoZSBDU1AgYW5kIHRoZSB1Q0ROICh0aGUgcHJpbmNpcGxlIGNvbnRyYWN0 DQphcnJhbmdlbWVudCBmb3IgZGlzdHJpYnV0aW9uKQ0KYi4gVGhlIHJlbGF0aW9uc2hpcCBiZXR3 ZWVuIHRoZSB1Q0ROIGFuZCBkQ0ROICh0aGUgdHJhbnNpdGl2ZSB0cnVzdA0KcmVsYXRpb25zaGlw IHRoYXQgZXh0ZW5kcyB0aGUgY29udHJhY3QgZGVmaW5lZCBpbiAoYSkgYWJvdmUpIGMuIFRoZQ0K cmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIFVzZXIgYW5kIGRDRE4gKHRoZSByZWNvZ25pdGlvbiBv ZiByaWdodCB0bw0KZG93bmxvYWQgcHJlZGljYXRlZCBvbiAoYikgYWJvdmUpIGQuIFRoZSByZWxh dGlvbnNoaXAgYmV0d2VlbiB0aGUNClVzZXIgYW5kIENTUCAodGhlIGNvbnRyYWN0IGF1dGhvcml6 aW5nIHRoZSB1c2VyIGFjY2VzcyB0byB0aGUNCmNvbnRlbnQpDQoNClRoZSB1c2VyIGlzIG5vdCBp bnRlcmVzdGVkIGluIHRoZSBhLWIgbm9yIHRoZSBiLWMgcmVsYXRpb25zaGlwLiBUaGUNCnVzZXIg aXMgb25seSBpbnRlcmVzdGVkIGluIHRoZSB0cmFuc3BhcmVuY3kgYW5kIGludGVyb3BlcmFiaWxp dHkgb2YNCnRoZSBzZWN1cml0eSByZWxhdGlvbnNoaXAgYmV0d2VlbiBkLWIgb3IgZC1jIHRvIHRo ZSBwb2ludCB0aGF0IHRoZQ0KYXV0aG9yaXphdGlvbiBncmFudGVkIGluIGQtYSBpcyB2aWFibGUg d2hlbiB0aGUgZGVsaXZlcnkgaXMNCmluaXRpYXRlZCB2aWEgZWl0aGVyIGQtYiBvciBkLWMuICBB cyBhbiBleGFtcGxlLCB0aGUgdUNETiBtaWdodCB1c2UNClVSTCBhcHBlbmRlZCB0b2tlbnMgZm9y IGF1dGhlbnRpY2F0aW9uIHdoaWxlIGRDRE4gbWlnaHQgdXNlIFVSTA0KYXBwZW5kZWQgaGFzaGVz LiAgVGhlIHVzZXIgZG9lc24ndCB3YW50IHRvIGtub3cgYWJvdXQgdGhlIGRpc3RpbmN0DQptZXRo b2RzLCBidXQgdHJhbnNwYXJlbmN5IGlzIG9ubHkgYWZmb3JkZWQgaWYgdGhlIG1ldGhvZHMgYXJl DQppbnRlcm9wZXJhYmxlIGNsZWFybHkgZGVmaW5lZCB3aGVuIHRoZSBkZWxlZ2F0aW9uIGZvciBj b250ZW50DQpkZWxpdmVyeSBpcyBleGVjdXRlZC4gIENsZWFybHksIHRoZSBjaG9pY2Ugb2YgYXV0 aGVudGljYXRpb24gbWV0aG9kIGlzIGRldGVybWluZWQgYnkgdGhlIHJlc3BlY3RpdmUgQ0ROJ3Mu DQoNClNjb3R0DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRmLm9y Zz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5nIGxp c3QNCkNETmlAaWV0Zi5vcmc8bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KQ0ROaSBtYWlsaW5nIGxpc3QNCkNETmlAaWV0Zi5vcmc8 bWFpbHRvOkNETmlAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NkbmkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRmLm9yZz4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQoNCg== --Boundary_(ID_pUz9GlNEpleNbHhlmXY4ow) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9z ZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxp YnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAx IDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjsNCgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtc3R5bGUtc3Bh bjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1j b252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi IGxhbmc9IlpILUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFNjb3R0LDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyB0b3BpYyBwZXJoYXBzIG1heSBub3Qg YmUgc28gc2ltcGxlIGFzIDAgb3IgMSwgb3RoZXJ3aXNlIHdlIHdvdWxkIG5vdCBoYXZlIHRha2Vu IHNvIG11Y2ggdGltZSBkaXNjdXNzaW5nIG9uIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+VGhlIG9yaWdpbmFsIHF1ZXN0aW9uIGlzOiBpZiB0byBzdXBwb3J0 IGNvbnRlbnQgYWRhcHRhdGlvbiwgd2hlcmUgLCB3aGF0IHNvbHV0aW9uKGkuZS4gdHJhbnNmb3Jt YXRpb24sIG1ldGFkYXRhLCBldGMpIGFuZCAmbmJzcDtob3cgbXVjaCBjb3N0IHdvdWxkDQogYmUg bmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhl cmUgaXMgbm8gYXBwcm9wcmlhdGUgc2NlbmFyaW8gdG8gaW1wbGVtZW50IHRoZSBjb250ZW50IGFk YXB0YXRpb24sIHRoZSB1c2UgY2FzZSBhbmQgcmVxdWlyZW1lbnQgd291bGQgYmUgbm90IGluIHRo ZSBzdGFuZGFyZCB3b3JrLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+U28gd2UgaGF2ZSBldmFsdWF0ZWQgbWFueSBpc3N1ZXMgYW5kIHN0aWxsIGFyZSB3b3JraW5n IHRvIGdpdmUgYSBjb21wbGV0ZSB2aWV3Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5Gcm9tIG15IHNpZGUgYW5kIHNvbWUgb3RoZXIgZXhwZXJ0cywgc29tZSBp bnRlcm5hbCB3b3JrcyBoYXZlIGJlZW4gZG9uZSBvbiB0aGlzLiBQZXJoYXBzIGRpZmZlcmVudCBw ZW9wbGUgaG9sZCBlaXRoZXIgYSBwb3NpdGl2ZSAmbmJzcDtvciBhIG5lZ2F0aXZlDQogdmlld3Bv aW50IGZvciBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRo ZSB3b3JrIChpbmNsdWRpbmcgb2ZmbGluZSBkaXNjdXNzaW9ucykgaXMgc3RpbGwgZ29pbmcgb24g YW5kIEkgd291bGQgZ2l2ZSBteSBjb21wbGV0ZSBhbmFseXNpcyBhbmQgc29sdXRpb24gcHJvcG9z YWwgb24gdGhpcyB0b3BpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkhvdyBhYm91dCB0byBsZXTigJlzIGRvIHRoZSBmaW5hbCBldmFsdWF0aW9uIHRoZW4uDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+IE5vdyBpZiB0aGUgZmxhZyBpcyBzZXQgdG8gJnF1b3Q7MSZxdW90OywgaXQgaXMg aW5jdW1iZW50IHVwb24gdGhlIGRDRE4gdG8gZmlndXJlIG91dCBob3cgdG8gbW9kaWZ5IHRoZSBj b250ZW50IHdpdGhvdXQgY2hhbmdpbmcNCiB0aGUgVVJMIHJlZmVyZW5jZXMsIGV0Yy48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+V2UgbWF5IGhhdmUgZGlmZmVyZW50IHdheXMuIEZvciBleGFtcGxlIHdoeSB0byBj b25zdHJpY3QgdGhhdCB3aXRoIHRoZSBzYW1lIFVSTCBmb3IgZGlmZmVyZW50IGNvbnRlbnQgY29w aWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFu ZCwgUkZDMjI5NSAoVHJhbnNwYXJlbnQgQ29udGVudCBOZWdvdGlhdGlvbiBpbiBIVFRQKQ0KPC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPnBlcmhhcHMgbWF5IGJlIHRoZSBpbmZvcm1hdGlvbiBmb3IgcmVmZXJlbmNlIHRvby48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2VsY29tZSB5b3VyIG1vcmUgaWRl YXMgb24gdGhpcyB0b3BpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPlRoYW5rcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlpo aXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOndp bmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6d2luZG93dGV4dCI+IFNjb3R0IFdhaW5uZXIgW21haWx0bzpzd2Fpbm5l ckBjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAwMiwg MjAxMSAzOjQ3IEFNPGJyPg0KPGI+VG86PC9iPiBjZG5pQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbQ0ROaV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jZG5pLXVzZS1jYXNlcy0w MC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QZXJoYXBzIHRoZSBhbnN3 ZXIgdG8gdGhpcyBkaWxlbW1hIGlzIHZlcnkgc2ltcGxlIC4uLjxicj4NCjxicj4NCkluIHRoZSBD RE5JIGludGVyZmFjZSwgd2Ugc2ltcGx5IG9mZmVyIGEgYmluYXJ5IG9wdGlvbiBvZiB0aGUgZm9s bG93aW5nOjxicj4NCjxicj4NCjApIGNvbnRlbnQgbWF5IG5vdCBiZSBhZGFwdGVkPGJyPg0KMSkg Y29udGVudCBtYXkgYmUgYWRhcHRlZDxicj4NCjxicj4NCkkgc3VzcGVjdCB0aGF0IHRoZSBtYWpv cml0eSBvZiB0aGUgQ0ROSSByZWxhdGlvbnNoaXBzIHdpbGwgc2V0IHRoZSBmbGFnIHRvICZxdW90 OzAmcXVvdDsgaW5kaWNhdGluZyB0aGUgYXNzZXQgaXMgbm90IGFsbG93ZWQgdG8gYmUgYWRhcHRl ZC4mbmJzcDsgVGhlIHJlYXNvbiBjYW4gYmUgYW55dGhpbmcgaW5jbHVkaW5nIGNvbnRyYWN0dWFs IGJldHdlZW4gdGhlIENQIGFuZCB1Q0ROLCB0aGUgY29udGVudCBpcyBlbmNyeXB0ZWQsIHRoZSB1 Q0ROIHByZWZlcmVuY2UsIGV0Yy48YnI+DQo8YnI+DQpOb3cgaWYgdGhlIGZsYWcgaXMgc2V0IHRv ICZxdW90OzEmcXVvdDssIGl0IGlzIGluY3VtYmVudCB1cG9uIHRoZSBkQ0ROIHRvIGZpZ3VyZSBv dXQgaG93IHRvIG1vZGlmeSB0aGUgY29udGVudCB3aXRob3V0IGNoYW5naW5nIHRoZSBVUkwgcmVm ZXJlbmNlcywgZXRjLjxicj4NCjxicj4NClNjb3R0PGJyPg0KPGJyPg0KT24gMTAvMjcvMTEgNzoy MiBBTSwgV291bmR5LCBSaWNoYXJkIHdyb3RlOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZndDtJbiB5b3VyIGNvbXBhbnnDouKCrOKEonMgd2Vic2l0ZSwgSSBq dXN0IGZpbmQgc29tZSBpbmZvcm1hdGlvbjxicj4NCjxicj4NCkkgaGF2ZSB0byBzdGVwIGluIGFz IGNvLWNoYWlyIGhlcmUuPGJyPg0KPGJyPg0KVGhlIGdvYWwgb2YgdGhpcyBXRyBpcyBub3QgdG8g YWxpZ24gdmVuZG9yIHByb2R1Y3Qgcm9hZG1hcHMsIG9yIHRvIGVxdWFsaXplIGFsbCB2ZW5kb3Ig b2ZmZXJpbmdzLCBvciB0byBzcGVjaWZ5IHRoZSBlbnRpcmUgQ0ROSSBlY29zeXN0ZW0uIFRoZSBn b2FsIG9mIHRoaXMgV0cgaXMgdG8gZW5hYmxlIHRoZSBpbnRlcmNvbm5lY3Rpb24gYW5kIGludGVy b3BlcmF0aW9uIG9mIHR3byBvciBtb3JlIENETnMsIHdpdGhpbiB0aGUgYm91bmRzIG9mIHRoZQ0K IENETkkgd2cgY2hhcnRlci48YnI+DQo8YnI+DQpJdCBpcyBPSyB0byBoYXZlIGEgZGlzY3Vzc2lv biBhYm91dCB3aGV0aGVyIGNvbnRlbnQgYWRhcHRhdGlvbiBuZWVkcyB0byBiZSBwZXJmb3JtZWQg YnkgdGhlIGRDRE4sIHNpbmNlIHRoYXQgZGVjaXNpb24gaW1wYWN0cyB0aGUgdUNETi1kQ0ROIGlu dGVyZmFjZS4gU28gbGV0J3MgZmluZCBhIHByb2R1Y3RpdmUgd2F5IHRvIGRpc2N1c3MgdGhpcyBv biB0aGUgbWFpbGluZyBsaXN0LCBhbmQgdG8gY2xvc2UgdGhlIGRpc2N1c3Npb24gYnkgSUVURiA4 Mg0KIChpZiBub3Qgc29vbmVyKS48YnI+DQo8YnI+DQpDYW4gc29tZW9uZSBkZXNjcmliZSByZWFs LWxpZmUgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBDRE4gKG9yIGVkZ2UgY2FjaGUtYmFzZWQp IGNvbnRlbnQgYWRhcHRhdGlvbiBpcyBuZWVkZWQgdG9kYXkgaW4gYSBwcm9kdWN0aW9uIGVudmly b25tZW50LCBvciBzaG9ydGx5PyBOb3QgbWVyZWx5IGEgZmVhdHVyZSBpbiBhIHZlbmRvcidzIHBy b2R1Y3QgbWF0ZXJpYWxzPzxicj4NCjxicj4NClNwZWFraW5nIGFzIGFuIGluZGl2aWR1YWwsIEkg Y2FuIGZpbmQgYSBsb3Qgb2YgZXhhbXBsZXMgd2hlcmUgZG93bnN0cmVhbSBjb250ZW50IGFkYXB0 YXRpb24gaXMgbm90IG5lZWRlZCwgYW5kIGFueSBhZGFwdGF0aW9uIGlzIHJlYWxseSBwYXJ0IG9m IHRoZSBDUCAtIHVDRE4gaW50ZXJmYWNlICh3aGljaCBpcyBvdXQgb2YgdGhlIHNjb3BlIG9mIG91 ciBjaGFydGVyKS48YnI+DQo8YnI+DQotLSBSaWNoPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb208L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+OiBaaG91WmhpcGVuZyBbPGEgaHJlZj0ibWFpbHRvOnpob3V6aGlw ZW5nQGh1YXdlaS5jb20iPm1haWx0bzp6aG91emhpcGVuZ0BodWF3ZWkuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ8L2I+OiBUaHVyc2RheSwgT2N0b2JlciAyNywgMjAxMSAwMzo0NSBBTTxicj4NCjxi PlRvPC9iPjogTWFyayBkZSBKb25nIDxhIGhyZWY9Im1haWx0bzptYXJrQGpldC1zdHJlYW0ubmwi PiZsdDttYXJrQGpldC1zdHJlYW0ubmwmZ3Q7PC9hPjsgQWxhbiBLYXZhbmFnaA0KPGEgaHJlZj0i bWFpbHRvOmFsYW4ua2F2YW5hZ2hAZXJpY3Nzb24uY29tIj4mbHQ7YWxhbi5rYXZhbmFnaEBlcmlj c3Nvbi5jb20mZ3Q7PC9hPiA8YnI+DQo8Yj5DYzwvYj46IDxhIGhyZWY9Im1haWx0bzpjZG5pQGll dGYub3JnIj5jZG5pQGlldGYub3JnPC9hPiA8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+ DQombHQ7Y2RuaUBpZXRmLm9yZyZndDs8L2E+IDxicj4NCjxiPlN1YmplY3Q8L2I+OiBSZTogW0NE TmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0IDxicj4NCjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhlbGxvIE1hcmssPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5pY2UgdG8g bWVldCB5b3Ugb24gbGluZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SW4geW91ciBjb21wYW55w6LigqzihKJzIHdl YnNpdGUsIEkganVzdCBmaW5kIHNvbWUgaW5mb3JtYXRpb24gdGhhdCBhZGRyZXNzZXMgw6LigqzF kw0KPC9zcGFuPjxzcGFuIGxhbmc9Ik5MIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzRDNTY1 QztsYXlvdXQtZ3JpZC1tb2RlOmxpbmUiPlZvZGFmb25lIHN1YnNjcmliZXJzIGNvbXBsYWluZWQg YWJvdXQgdmlkZW8gcGVyZm9ybWFuY2Uuw6LigqwmIzE1Nzs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2VlOjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48YSBocmVmPSJodHRwOi8vd3d3LmpldC1zdHJlYW0ubmwvc2VhcmNoLz9zZWFyY2g9 dHJhbnNjb2RpbmciPmh0dHA6Ly93d3cuamV0LXN0cmVhbS5ubC9zZWFyY2gvP3NlYXJjaD10cmFu c2NvZGluZzwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkRlYXIgYWxsIGluIHRo aXMgZ3JvdXAsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIGxhc3QgZmV3IGRheXMsIGV4Y2VwdCB0aGUgcHVibGlj IGVtYWlsIGRpc2N1c3Npb25zIEkgaGF2ZSBjb250YWN0ZWQgd2l0aCBzb21lIHBlb3BsZSBhbmQg ZGlzY3Vzc2VkIHdpdGggbXkgb3duIGNvbGxlYWd1ZXMgb2YgYWxsIGRldGFpbHMgb24NCiB0aGlz IGlzc3VlLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5GaXJzdCwgYWx0aG91Z2ggdGhlIG1hcmtldCByZXF1aXJlbWVu dCBmb3IgaXQgaXMgdmVyeSBpbXBvcnRhbnQsIEkgZmVlbCBJw6LigqzihKJkIGJldHRlciBzaG93 IHVwIG1vcmUgaW5mb3JtYXRpb24gb24gdGhlIHByb2NlZHVyZSBpbnZvbHZlZC4gSSBoYXZlDQog ZXhwbGFpbmVkIG1hbnkgdGltZXMgdGhhdCB0byBzdXBwb3J0IGNvbnRlbnQgYWRhcHRhdGlvbiBp cyByYXRoZXIgc2ltcGxlIHdoaWxlIHRoZSB3b3JkaW5nIGlzIG5vdCBlbm91Z2guPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkkgYW0gYnVzeSBtYWtpbmcgc29tZSBjb250cmlidXRpb25zIG9uIHRoaXMgYW5kIHBsYW4g dG8gdXBsb2FkIHRvIEVUU0kgbWVldGluZyBhbmQgSUVURiBDRE5JLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CeSB0 aGVzZSB3b3JrJm5ic3A7IEkgZmVlbCB0aGUgcGVvcGxlIG1heSBjYXRjaCBhIHdob2xlIHZpZXcg b24gdGhpcyBpc3N1ZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U2Vjb25kLCBmb3IgdGhhdCBmdW5jdGlvbmFsaXR5 LCBpbiBpbXBsZW1lbnRhdGlvbiwgaWYgc29tZSBlbnRpdHkgZG9lcyBub3QgY2hvb3NlIHRvIHN1 cHBvcnQgaXQsIGl0IG1heSBiZSBvay4gU2luY2UgaXQgbWF5IGJlIG5lZ290aWF0ZWQgYmV0d2Vl bg0KIHR3byBDRE5zLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiBkQ0ROIGRvZXMgbm90IHN1cHBvcnQgdGhhdCwg aXQgbWF5IGJlIHRoZSB1Q0ROIHJlc3BvbnNpYmxlIHRvIGNvbXBsZXRlIHRoZSB0cmFuc2NvZGlu ZyBhbmQgZGVsaXZlciB0aGUgY29udGVudCBvZiBtdWx0aXBsZSBmb3JtYXRzIGFuZCByYXRlcw0K IHRvIGRDRE4uPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXJkLCBhbHRob3VnaCBDRE5JIGlzIGEgbmV3IGFyY2hp dGVjdHVyZSwgd2hpbGUgdGhlIGNvbnRlbnQgb3BlcmF0aW5nIGhhcyBiZWVuIGV4aXN0ZWQgZm9y IHllYXJzLiBBcyBJIGtub3cgdGhlIGNvbnRlbnQgZnJvbSBVU0EgdG8gdGhlIGRvd25zdHJlYW0N CiBvcGVyYXRvciBpcyB0cmFuc2ZlcnJlZCBvbiBvbmUgY29weSBhbmQgdGhlIGRvd25zdHJlYW0g b3BlcmF0b3Igd2lsbCBoYW5kbGUgdGhlIHRyYW5zY29kaW5nLg0KPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5QZXJoYXBzLCB0aGUgY29udGVudCBhZGFwdGF0aW9uIGlzIG1vcmUgb24g dGhlIG1vYmlsZSBvcGVyYXRpbmcuIEJ1dCBJIGZlZWwgY3VycmVudGx5IG1vc3Qgb3BlcmF0b3Ig d2lsbCBiZSBhIGFsbCBzZXJ2aWNlIG9wZXJhdG9yLiBBbmQgZm9yIHRoZQ0KIENETiBwcm92aWRl cnMsIGl0IG1heSBiZSBiZXR0ZXIgdG8gc3VwcG9ydCBhbGwga2luZHMgb2Ygc2VydmljZS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+QmVzaWRlcywgSSBsaWtlIHNheSB0aGF0IHRoZSB0ZWNobm9sb2d5IG9uIHRoaXMg dG9waWMgaGFzIGJlZW4gZm9yIG1hbnkgeWVhcnMgYW5kIGhhcyBiZWVuIHJhdGhlciBtYXR1cmUs IGV2ZW4gc29tZSBpdGVtcyBpbiBpZXRmIHN1Y2ggYXMgcmZjMzUwNw0KIGljYXAuIFNvIGZyb20g dGhlIHRlY2huaXF1ZSBwb2ludCBvZiB2aWV3LCBpdCBpcyBhIG5hdHVyZSBhY3Rpb24gdG8gYmUg aW52b2x2ZWQgaW4gQ0ROIGludGVyY29ubmVjdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzLjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5aaGlwZW5nPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWFyayBk ZSBKb25nIFs8YSBocmVmPSJtYWlsdG86bWFya0BqZXQtc3RyZWFtLm5sIj5tYWlsdG86bWFya0Bq ZXQtc3RyZWFtLm5sPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAy NywgMjAxMSA0OjIxIEFNPGJyPg0KPGI+VG86PC9iPiBBbGFuIEthdmFuYWdoPGJyPg0KPGI+Q2M6 PC9iPiBCZW4gTml2ZW4tSmVua2luczsgWmhvdVpoaXBlbmc7IDxhIGhyZWY9Im1haWx0bzpjZG5p QGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0NE TmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBB bGFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIEJlbiBzdGF0 ZWQgdGhlIG92ZXJhbGwgZGlzY3Vzc2lvbiByaWdodCBub3cgaXMgYWJvdXQgZGVsaXZlcnksIG5v dCBvbiBhZGFwdGF0aW9uLiBJdCBpcyBoYXJkIGVub3VnaCB0byBnZXQgY29uc2Vuc3VzIG9uIHRo ZSBkZWxpdmVyeSBhc3BlY3QgYWxyZWFkeSBub3QgdG8gbWVudGlvbiB5b3VyIHJlcXVpcmVtZW50 IGZyb20gY29udGVudCBhZGFwdGF0aW9uIGFkZGVkIHRvIHRoYXQsDQogc28gSSBhZ3JlZSB3aXRo IEJlbiB3ZSBzaG91bGQgc3RpY2sgd2l0aCB0aGUgZGVsaXZlcnkgYXNwZWN0IGZvciB0aGUgZmly c3Qgc3BlY3MuJm5ic3A7SSBjYW4gaW1hZ2luZSB0aGlzIGNvdWxkIGJlIGEgZGlzY3Vzc2lvbiBs YXRlciBvbiBidXQgcGxlYXNlIGxldCB1cyBrZWVwIHRoZSBzY29wZSBvZiB0aGlzIGJlIGNsZWFu IGFuZCB0cmFuc3BhcmVudC4gSXQgaXMgb2YgYmVuZWZpdCBvZiBldmVyeW9uZSB0byBnZXQgdGhl IGZpcnN0IHNwZWNzIGFzIGZhc3QNCiBhcyBwb3NzaWJsZS4gVGhhbmtzLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJh cHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pk1ldCB2cmllbmRlbGlqa2UgZ3JvZXQsPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+S2luZCByZWdhcmRzLDwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iYXBw bGUtc3R5bGUtc3BhbiI+TWFyayBkZSBKb25nPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBs ZS1zdHlsZS1zcGFuIj5JbnRlcm5hdGlvbmFsIEJ1c2luZXNzIERldmVsb3Blcjwvc3Bhbj48YnI+ DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+SmV0LVN0cmVhbSBCVjwvc3Bhbj48YnI+ DQo8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+RS1tYWlsOiA8YSBocmVmPSJt YWlsdG86bWFya0BqZXQtc3RyZWFtLmNvbSI+bWFya0BqZXQtc3RyZWFtLmNvbTwvYT48L3NwYW4+ PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPk9mZmljZTogJiM0MzszMSAoMCk1 MCA1MjYxODIwPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj5Nb2Jp bGU6ICYjNDM7MzEgKDApNiA4MTEwODI2Mzwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUt c3R5bGUtc3BhbiI+RmF4OiAmIzQzOzMxICgwKTUwIDUyNjQyMTQ8L3NwYW4+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5 bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIEV2 ZW50Ojwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5NZWV0DQogdXMgYXQgU3RyZWFtaW5nIE1lZGlhIEV1cm9wZSwg MTctMTggT2N0b2JlciwgTG9uZG9uLCBVSzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIEV2ZW50Ojwvc3Bhbj48L2I+PC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwO01lZXQNCiB1cyBhdCBPbmxpbmUgVmlkZW8gU3RyYXRlZ2llcywg MTkgT2N0b2JlciwgTG9uZG9uLCBVSzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4tIEV2ZW50Ojwvc3Bhbj48L2I+PC9zcGFuPjxzcGFu IGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwO01lZXQNCiB1cyBhdCBDRE4gV29ybGQgU3VtbWl0LCAyNS0yOCBPY3Rv YmVyLCBMb25kb24sIFVLPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPi08L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5OZXdzOjwvc3Bhbj48L2I+PC9zcGFuPjxz cGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPiZuYnNwO1ByZS1yZXF1ZXN0DQogeW91ciBUZWNobm9sb2d5IFdoaXRlcGFw ZXIgbm93IGFuZCBiZSB0aGUgZmlyc3QgdG8gaGF2ZSBpdCwgY2hlY2sgPGEgaHJlZj0iaHR0cDov L3d3dy5qZXQtc3RyZWFtLmNvbSI+DQp3d3cuamV0LXN0cmVhbS5jb208L2E+PC9zcGFuPjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LSZuYnNwOzxiPk5ld3M6Jm5i c3A7PC9iPkNoZWNrJm5ic3A7PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbSI+aHR0 cDovL3d3dy5qZXQtc3RyZWFtLmNvbTwvYT4gdG8gZG93bmxvYWQgb3VyICdTaXggVHJlbmRzIGlu IENETnMnIGJyb2NodXJlPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBs ZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi08 L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5CbG9nOjwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDov L3d3dy5qZXQtc3RyZWFtLmNvbS9ibG9nLyI+d3d3LmpldC1zdHJlYW0uY29tL2Jsb2cvPC9hPjwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHls ZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi08L3NwYW4+ PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFz cz0iYXBwbGUtc3R5bGUtc3BhbiI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5WaWRlb0V4Y2hhbmdlOjwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+Jm5ic3A7PC9zcGFuPjwvYj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNw YW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0 cDovL3d3dy52ZG8teC5uZXQiPnd3dy52ZG8teC5uZXQ8L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFu Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlN0cmVhbXppbGxh Ojwvc3Bhbj48L2I+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjwv Yj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5zdHJlYW16aWxsYWNk bi5jb20iPnd3dy5zdHJlYW16aWxsYWNkbi5jb208L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ni41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkNvcnBvcmF0ZTo8L3Nw YW4+PC9iPjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo2LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjYuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+PGEgaHJlZj0iaHR0cDovL3d3dy5qZXQtc3RyZWFtLmNvbSI+d3d3LmpldC1z dHJlYW0uY29tPC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+T24gMjYsIE9jdCwyMDExLCBhdCA4OjMzIFBNLCBBbGFuIEthdmFuYWdoIHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVuPGJy Pg0KPGJyPg0KSW0gYXNzdW1pbmcgdGhlbiBiYXNlZCBvbiB5b3VyIGNvbW1lbnRzIGJlbG93IGFy ZSB5b3Ugc3VnZ2VzdGluZyB3ZSBhcmUgZ29pbmcgdG8gaGF2ZSBhIG51bWJlciBvZiB2ZXJzaW9u cyBvZiB0aGUgQ0ROLUkgTWV0YWRhdGE/PGJyPg0KPGJyPg0KSSBzeW1wYXRoaXNlIHdpdGggd2hh dCB5b3UgYXJlIHBvaW50aW5nIG91dCBiZWxvdyBhbmQgZG8gYWdyZWUgdGhhdCB0aGVyZSBpcyBz b21lIHdvcmsgdG8gYmUgZG9uZSwgYnV0IEkgc3RpbGwgZmVlbCB0aGF0IGNvbnRlbnQgYWRhcHRh dGlvbiBpcyB0byBtZSBhIGZ1bmRhbWVudGFsIHJlcXVpcmVtZW50IHRvIHdoYXQgY29sbGVjdGl2 ZWx5IHdlIHNob3VsZCBhZGRyZXNzIGluIHRoZSBDRE4tSSBXRy4gSSBkbyBhZ3JlZSB3aXRoIHlv dSB0aGF0IGNvbnRlbnQNCiBhZGFwdGF0aW9uIGlzIGFuIG9wdGltaXphdGlvbiBiZXR3ZWVuIENE TidzIGJ1dCBpdCdzIGEgdmVyeSBpbXBvcnRhbnQgb25lIHRoYXQgSSBrbm93IE5ldHdvcmsgU2Vy dmljZSBQcm92aWRlcnMgcGFydGljdWxhcmx5IHJlcXVpcmUuPGJyPg0KPGJyPg0KQWxhbjxicj4N Cjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogPGEgaHJlZj0ibWFp bHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZyI+Y2RuaS1ib3VuY2VzQGlldGYub3JnPC9hPiBbPGEg aHJlZj0ibWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmNkbmktYm91bmNlc0Bp ZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBCZW4gTml2ZW4tSmVua2luczxicj4NClNlbnQ6IE9j dG9iZXItMTItMTEgMToxMyBQTTxicj4NClRvOiBaaG91WmhpcGVuZzxicj4NCkNjOiA8YSBocmVm PSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBS ZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PGJy Pg0KPGJyPg0KWmhpcGVuZyw8YnI+DQo8YnI+DQpPbiAxMiBPY3QgMjAxMSwgYXQgMTA6MjIsIFpo b3VaaGlwZW5nIHdyb3RlOjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBCZW4s PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhlIFVFIG1heSBzZWxlY3QgdGhlIGNvbnRlbnQgZm9ybWF0IG9uIHRoZSBDUCB3 ZWIuIEFmdGVyIHRoYXQgdGhlIHVzZXIgb25seSBkZXNpcmVzIHRvIGdldCBoaXMgc2VsZWN0ZWQg Y29udGVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CdXQgaG93IHRoZSBjb250ZW50IGlzIHRy YW5zZmVycmVkIHRvIHRoZSBjbGllbnQgaXMgbm90IHdvcnJpZWQgYnkgdGhlIHVzZXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+VGhlIENQIG1heSBjcmVhdGUgYSBzcGVjaWFsIGZvcm1hdCBhcyBy ZXF1aXJlZCBieSB0aGUgdXNlciBhbmQgYXNrIHRoZSBDRE4gdG8gZGVsaXZlciB0byB1c2VyLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoaWxlIENQIG1heSBnaXZlIGEgSEQgZm9ybWF0IGNvbnRl bnQgdG8gdUNETiBhbmQgdGhlIGRDRE4gbWF5IHRoZW4gdHJhbnNmb3JtIHRvIHRoZSBmb3JtYXQg YXMgdGhlIHVzZXIgc2VsZWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpMb3RzIG9mIHRo aW5ncyBtYXkgYmUgcG9zc2libGUgdG8gZG8gYW5kIENETiBwcm92aWRlcnMgb2ZmZXIgbWFueSBh ZGRpdGlvbmFsIHNlcnZpY2VzIG9uIHRvcCBvZiB0aGUgJnF1b3Q7Y29yZSZxdW90OyBzZXJ2aWNl IG9mIGNvbnRlbnQgZGVsaXZlcnkuIEhvd2V2ZXIsIG91ciBvYmplY3RpdmUgKGJhc2VkIG9uIG15 IGludGVycHJldGF0aW9uIG9mIHRoZSBDRE5JIGNoYXJ0ZXIpIGlzIHRvIGZvY3VzIG9uIHdoYXQg aXMgbmVjZXNzYXJ5IHRvIGludGVyY29ubmVjdA0KIENETnMgdG8gZGVsaXZlciBjb250ZW50IGZy b20gYSBDU1AgdG8gYW4gRW5kIFVzZXIgdGhhdCBpcyB0YXJnZXRlZCBhbmQgZGVwbG95YWJsZSB3 aXRoaW4gYSBzaG9ydCB0aW1lIGZyYW1lICgxOC0yNCBtb250aHMpLjxicj4NCjxicj4NCkNvbnRl bnQgdHJhbnNmb3JtYXRpb24vYWRhcHRhdGlvbiBpcyBub3QgYW4gZXNzZW50aWFsIHJlcXVpcmVt ZW50IGluIG9yZGVyIHRvIGFjaGlldmUgdGhhdCBhaW0gKHdlIGNhbiBkZWxpdmVyIGNvbnRlbnQg ZnJvbSBDU1BzIHRvIEVuZCBVc2VycyB2aWEgbXVsdGlwbGUgQ0ROcyB3aXRob3V0IG5lZWRpbmcg b3IgcmVxdWlyaW5nIGFueSBDRE4gc3VwcG9ydHMgY29udGVudCBhZGFwdGF0aW9uKS48YnI+DQo8 YnI+DQpJbiBteSBvcGluaW9uIHdlIGhhdmUgZW5vdWdoIHdvcmsgdG8gZG8gYWxyZWFkeSB3aXRo b3V0IHRyeWluZyB0byBleHBhbmQgdGhlIHNjb3BlIG9mIG91ciB3b3JrIHRvIGluY2x1ZGUgYWRk aXRpb25hbCByZXF1aXJlbWVudHMgdGhhdCBkbyBub3QgaGVscCB1cyBhZGRyZXNzIG91ciBjb3Jl IG9iamVjdGl2ZXMgYXMgbGFpZCBvdXQgaW4gdGhlIENETkkgY2hhcnRlci48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhpcyBjYXNlLCBpdCBpcyBub3RoaW5nIHJlbGF0ZWQgdG8g aG93IHRoZSB1c2VyIHNlbGVjdCBmb3JtYXRzIG9uIENQIHdlYnNpdGUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U28sIGl0 IGlzIHRoZSBDUCBhbmQgdXNlciB0byBkZWNpZGUgdGhlIGNvbnRlbnQgZm9ybWF0IG5vdCB0aGUg Q0ROKHlvdXIgYXNzZXJ0IGlzIG5vdCBjb3JyZWN0IGFuZCBzZWVtcyB5b3UgdGFrZSB0aGF0IGFz c2VydCBhcyB5b3VyIGJhc2UgZm9yIHRoZSBkaXNjdXNzaW9uKS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBmb3IgJnF1b3Q7dGhlIGNvcmUg Q0ROIGZ1bmN0aW9uYWxpdHkgb2ZmZXJlZCBieSBDRE5zIHRvZGF5JnF1b3Q7LCBJIGhhdmUgZXZl ciByYWlzZWQgYW4gZW1haWwgYmVmb3JlIHRoYXQgeW91ciBjb21wYW55J3Mgd2VicGFnZSBoYXMg Y2xhaW1lZCBzdXBwb3J0aW5nIG1lZGlhIHRyYW5zZm9ybWF0aW9uIGFuZCBtdWx0aS1zY3JlZW4g c2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QZXJoYXBzLCBJIGxpa2UgYXNraW5nIHlv dSBsaXN0IHNvbWUgZmVhdHVyZXMgdGhhdCB5b3UgZmVlbCBhcmUgdGhlIGNvcmUgZnVuY3Rpb25h bGl0aWVzIGJ5IGV4aXN0aW5nIG1haW4gc3RyZWFtIENETnMuIFRodXMgd2UgbWF5IGNvbXBhcmUg YW5kIHRha2UgZGVlcCBsb29rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpJIHRoaW5rIHRo ZSBjb3JlIGZ1bmN0aW9uYWxpdHkgbWFwcyBwcmV0dHkgd2VsbCB0byB0aGUgQ0ROSSBpbnRlcmZh Y2VzLCBuYW1lbHk6IFJlcXVlc3QgUm91dGluZywgTWV0YWRhdGEgY29uZmlndXJhdGlvbiwgbG9n IHByb2R1Y3Rpb24gYW5kIGNvbnRyb2wgcGx1cyBjb250ZW50IGFjcXVpc2l0aW9uIGFuZCBjb250 ZW50IGRlbGl2ZXJ5Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGd1ZXNzIG1hbnkg cGVvcGxlIGhhdmUgdGhlIGV4cGVyaWVuY2Uva25vd2xlZGdlIG9mIGNvbnRlbnQgcmVsYXRlZCBz ZXJ2aWNlLiBUaGUgdXNlciBhbmQgQ1Agb25seSBjYXJlIHdoZXRoZXIgdGhlIENETiBwcm92aWRl cnMgbWF5IHNhdGlzZnkgdGhlaXIgcmVxdWlyZW1lbnQgd2hpbGUgbm90IGNhcmUgdGhlIGludGVy bmFsIHByb2Nlc3MuIEp1c3QgYXMgR1NNL1BTVE4gaW50ZXJjb25uZWN0aW9uLA0KIHRoZSB1c2Vy IG9ubHkgY2FyZSBzdWNjZXNzZnVsIGludGVyY29ubmVjdGlvbiB3aGlsZSBub3QgY2FyZSBob3cg dGhlIHZvaWNlIGlzIHRyYW5zZm9ybWVkIGluIHByb2Nlc3MuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+QmVzaWRlcywgSSBsaWtlIHJhaXNlIGEgY2FzZTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5HaXZlbiBjdXJyZW50bHkgQkJDIHJlY3J1aXRzIENETiBwcm92aWRlcnMg dGhhdCBtYXkgc3VwcG9ydCAxMCBtZWRpYSBmb3JtYXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uZSBjYW5kaWRhdGUgaXMgeW91ciBjb21wYW55LCBhbm90aGVyIGlzIENETi1YLiBUaGUgdXNl cnMgYXJlIGxvY2F0ZWQgaW4gRnJhbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvIGJvdGgg eW91ciBjb21wYW55IGFuZCBDRE4tWCBzaG91bGQgY29ubmVjdCBhIEZyYW5jZSBDRE4gcHJvdmlk ZXIoQ0ROLVkpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHlvdXIgY29tcGFueSdzIHNvbHV0 aW9uIGlzIHRvIHNlbmQgMTAgc3RyZWFtcyBvZiBkaWZmZXJlbnQgZm9ybWF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+b2Ygb25lIGNvbnRlbnQgdG8gQ0ROLVk7IFdoaWxlIENETi1YJ3Mgc29sdXRp b24gaXMgdG8gc2VuZCAxIHN0cmVhbSB0byBDRE4tWSB3aGlsZSBDRE4tWSBtYXkgY29uZHVjdCBz b21lIGFkYXB0YXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q29tcGFyaW5nIHRoZXNlIHR3 byBzb2x1dGlvbnMsIGZvciB5b3VyIGNvbXBhbnkgYW5kIENETi1YLCBhYnNvbHV0ZWx5IHRoZSBj b3N0IG9mIENETi1YIGlzIG11Y2ggbG93ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIENE Ti1ZLCBpbiBzb2x1dGlvbi0xLCBpdCBzaG91bGQgcmVjZWl2ZS9mb3J3YXJkIDEwIHN0cmVhbXMg OyB3aGlsZSBpbiBzb2x1dGlvbi0yLCBpdCBzaG91bGQgb25seSByZWNlaXZlIDEgc3RyZWFtIGJ1 dCBuZWVkIHRvIHRha2UgdHJhbnNmb3JtYXRpb24gdG8gb3V0cHV0IDEwIHN0cmVhbXMuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+V2hpY2ggc29s dXRpb24gaXMgbW9yZSBjb21wZXRpdGl2ZS4gaXQgaXMgU29sdXRpb24gMSwgcmlnaHQuIFJlbWVt YmVyIHRoZSBwcmljZSBmcm9tIEJCQyBpcyBzYW1lIHRvIGJvdGggeW91ciBjb21wYW55IGFuZCBD RE4tWCBvciBCQkMgd291bGQgc2VsZWN0IG9uZSBDRE4gcHJvdmlkZXIgd2l0aCB0aGUgbG93ZXIg cHJpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgYSBDRE4gcHJvdmlkZXIgbWF5IG5vdCBn ZXQgdGhlIGNvbnRyYWN0IGZyb20gQ1AsIGhvdyBpdCBtYXkgc2F5IGl0IGlzIG5vdCBhIGNvcmUg ZnVuY3Rpb25hbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KV2hhdCB5b3UgYXJlIGRl c2NyaWJpbmcgaXMgYSBwb3NzaWJsZSBvcHRpbWl6YXRpb24gdGhhdCBhIHBhcnRpY3VsYXIgQ0RO IG1heSB3aXNoIHRvIGltcGxlbWVudCBub3QgYSBjb3JlIGZ1bmN0aW9uYWxpdHkgcmVxdWlyZWQg dG8gZW5hYmxlIGNvbnRlbnQgZGVsaXZlcnkgYmV0d2VlbiBpbnRlcmNvbm5lY3RlZCBDRE5zLiBJ IGNhbiB0aGluayBvZiBtYW55IG9wdGltaXphdGlvbnMgdGhhdCBhIENETiBjb3VsZCBpbXBsZW1l bnQgdG8gZGlmZmVyZW50aWF0ZQ0KIHRoZWlyIHNlcnZpY2UgYnV0IHRoZSBpbnRlcm5hbCB3b3Jr aW5ncyBvZiBhbiBpbmRpdmlkdWFsIENETiBhcmUgb3V0IG9mIHNjb3BlIG9mIG91ciBjaGFydGVy Ljxicj4NCjxicj4NClNvIHRvIHJlcGVhdCBteSBwb3NpdGlvbiBmb3IgYSBmaW5hbCB0aW1lOiBD b250ZW50IGFkYXB0YXRpb24gaXMgbm90IGEgY29yZSBmdW5jdGlvbiByZXF1aXJlZCB0byBlbmFi bGUgY29udGVudCBkZWxpdmVyeSBiZXR3ZWVuIGludGVyY29ubmVjdGVkIENETnMgYW5kIHRoZXJl Zm9yZSBnaXZlbiB0aGUgd29ya2xvYWQgd2UgYWxyZWFkeSBoYXZlIHRvIHNwZWNpZnkgc29sdXRp b25zIHRoYXQgZG8gYWRkcmVzcyB0aGUgY29yZSBmdW5jdGlvbmFsaXR5DQogcmVxdWlyZWQgdG8g aW50ZXJjb25uZWN0IENETnMgSSBkbyBub3QgdGhpbmsgd2Ugc2hvdWxkIGJlIHRyeWluZyB0byBh ZGQgbW9yZSB3b3JrIGludG8gdGhhdCB3b3JrbG9hZCBhcyBpdCB3aWxsIG9ubHkgZGlzdHJhY3Qg dXMgZnJvbSBhY2hpZXZpbmcgb3VyIGdvYWwgb2YgcHJvZHVjaW5nIGRlcGxveWFibGUgc29sdXRp b25zIHdpdGhpbiB0aGUgdGltZWZyYW1lIHdlIGFyZSBiZWluZyB0b2xkIGJ5IG9wZXJhdG9ycyB0 aGV5IG5lZWRzIHNvbHV0aW9ucw0KIHdpdGhpbi48YnI+DQo8YnI+DQpCZW48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+U28sIGlmIHdlIGFsbCByZWFsaXplIHRoYXQgY3VycmVudGx5IHRo ZSBtZWRpYSB0eXBlIGlzIHJpY2gsIHRoZSBDRE4gcHJvdmlkZXJzIHNob3VsZCBzdXJ2aXZlIGlu IHRoZSBleGlzdGluZyBlY29zeXN0ZW0gYW5kIHN1cHBvcnQgdGhlIG1lZGlhIHR5cGVzIGFzIHJl cXVpcmVkIGJ5IHRoZSBtYXJrZXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+QmFjayB0byB0aGUgY2FzZSBvZiBHU00vRy43MTEsIGl0IGp1c3Qgd2hlbiBjb25jZXJuaW5n IHRoZSBpbnRlcmNvbm5lY3Rpb24sIHRoZSB0cmFuc2Zvcm1hdGlvbiBzaG91bGQgYXQgb25jZSBi ZSBzb2x2ZWQuIE90aGVyd2lzZSB0aGUgaW50ZXJjb25uZWN0aW9uIG1heSBub3QgYmUgb3BlcmF0 ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ QnIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WmhpcGVuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ RnJvbTogQmVuIE5pdmVuLUplbmtpbnMgWzxhIGhyZWY9Im1haWx0bzpiZW5Abml2ZW4tamVua2lu cy5jby51ayI+bWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPC9hPl08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5TZW50OiBXZWRuZXNkYXksIE9jdG9iZXIgMTIsIDIwMTEgMTI6MTkgQU08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5UbzogWmhvdVpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5DYzogPGEgaHJlZj0ibWFpbHRvOnBoaWxpcC5lYXJkbGV5QGJ0LmNvbSI+DQpwaGlsaXAuZWFy ZGxleUBidC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRm Lm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJqZWN0OiBSZTogW0NETmldIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+WmhpcGVuZyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiAxMSBPY3QgMjAxMSwg YXQgMDU6MTYsIFpob3VaaGlwZW5nIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVuIGFuZCBQaGlsaXAsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGxpa2UgdG8gcmVzcG9uZCB5b3VyIGNvbmNlcm4g aW4gdGhpcyBvbmUgZW1haWw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlbiw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgZmVlbCB3aGF0IHdlIGFyZSBu b3cgZGlzY3Vzc2luZyBpcyB3aGF0IGlzIHRoZSAmcXVvdDtjb3JlJnF1b3Q7IGZ1bmN0aW9uIG9m IENETi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIHlvdSBzYXks IENETiBpcyB1c2VkIHRvIGRlbGl2ZXIgY29udGVudC4gVGhhdCBpcyBhYnNvbHV0ZWx5IGNvcnJl Y3QgdGhhdCB0aGUgZGVsaXZlcnkgY2FwYWJpbGl0eSBpcyB0aGUgY29yZSByZXF1aXJlbWVudCBm b3IgQ0ROIHN5c3RlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldo aWxlIENETiBpcyB1c2VkIHRvIHByb3ZpZGUgdGhlIGNvbnRlbnQgZGVsaXZlcnkgc2VydmljZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoYXQgbWVhbnMgc2Vydmlj ZS4gSXQgc2hvdWxkIGluY2x1ZGUgJnF1b3Q7dGltZSZxdW90OyAmcXVvdDtsb2NhdGlvbiZxdW90 OyBhbmQgJnF1b3Q7bWVkaWEgdHlwZSZxdW90OywgZXRjLiBUaGVzZSBmZWF0dXJlcyBhcmUgYWxs IHRoZSBjb3JlIGZlYXR1cmUgZm9yIGEgc2VydmljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPklmIHdlIG9ubHkgY29uY2VybiAmcXVvdDtkZWxpdmVyaW5nIG9uZSBk YXRhIGJsb2NrJnF1b3Q7LCBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhlIGlzc3VlcyBzdWNoIGFz ICZxdW90O2xvZ2dpbmcmcXVvdDsgJnF1b3Q7Z2VvZ3JhcGhpYyBjb25zdHJhaW50JnF1b3Q7IGFy ZSB0aGUgY29yZSBvZiBDRE4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciAmcXVv dDt3aXRob3V0IGV4cGxpY2l0IGtub3dsZWRnZSBvZiB3aGF0IHRoYXQgY29udGVudCBhY3R1YWxs eSBpcyAmcXVvdDssIEkgYW0gbm90IHN1cmUgd2hldGhlciB0aGUgd29yZGluZyBpcyBhY2N1cmF0 ZSBzaW5jZSBnZW5lcmFsbHkgYSBDRE4gbWF5IGNsYWltIGl0IHN1cHBvcnQgZGlmZmVyZW50IG1l ZGlhcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ5IHRoaXMgb3Bw b3J0dW5pdHksIEkgbGlrZSB0byBzaGFyZSBhIHVzZSBjYXNlOiBhIGNhbGwgZnJvbSBhIEdTTSBw aG9uZSB0byBhIFBTVE4gdGVsZXBob25lLCB0aGUgdm9pY2Ugc3RyZWFtIHNob3VsZCBiZSB0cmFu c2Zvcm1lZCBmcm9tIEdTTSB2b2ljZSB0byBHLjcxMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkZvciB0aGUgdXNlciwgaGUgZG9lcyBub3QgbmVlZCB0byBrbm93IHdo YXQgdHlwZSBvZiBkYXRhIGhhcyBiZWVuIHRyYW5zZmVycmVkLCBidXQgdGhlIG9wZXJhdG9yIGhh cyBkb25lIHNvbWUgd29yayB0byBpbnRlcmNvbm5lY3QgdHdvIHN5c3RlbXMsIHJpZ2h0LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBsaWtlIHRvIGtub3cgd2hldGhl ciB5b3UgbWF5IGFjY2VwdCB0aGF0IG15IHVzZSBjYXNlIGlzIHNpbWlsYXIgdG8gdGhpcyBjYXNl IGFib3ZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkkgZG9uJ3QgdGhpbmsgeW91ciB1c2UgY2FzZSBpcyBzaW1pbGFy IHRvIHRoZSBhbmFsb2d5IG9mIG1vYmlsZSBuZXR3b3JrcyBiZWluZyBpbnRlcmNvbm5lY3RlZCB0 byBQU1ROIG5ldHdvcmtzLiBJbiB0aGUgY2FzZSBvZiBjb250ZW50IGRlbGl2ZXJ5IHRoZSBuZWdv dGlhdGlvbiBpcyBkb25lIGJldHdlZW4gdGhlIFVzZXIvQ2xpZW50IGFuZCB0aGUgQ29udGVudCBQ cm92aWRlcg0KIGFuZCB0aGUgQ0ROIGlzIGp1c3QgdXNlZCB0byBleGVjdXRlL3BlcmZvcm0gdGhl IGRlbGl2ZXJ5IHRoYXQgaGFzIGJlZW4gbmVnb3RpYXRlZC4gVGhlIENETiBpcyBub3QgaW52b2x2 ZWQgaW4gdGhlIGRlY2lzaW9uIG1ha2luZyBvZiB3aGF0IHJlcHJlc2VudGF0aW9ucyB0aGUgQ29u dGVudCBQcm92aWRlciBkZWNpZGVzIHRvIG9mZmVyIHRvIHRoZSBVc2VyL0NsaWVudCBvciBpbiB3 aGF0IHJlcHJlc2VudGF0aW9ucyB0aGUgVXNlci9DbGllbnQgZGVjaWRlcw0KIHRvIHJlcXVlc3Qu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5B cyBmb3IgeW91IHNhaWQgc2VsZWN0aW5nIG1lZGlhIGJ5IHRoZSAmcXVvdDtwb3J0YWwmcXVvdDss IHlvdSBtYXkgc2VlIHRoZSB3YXkgJnF1b3Q7IHVDRE4gZGVsaXZlcnMgbXVsdGlwbGUgbWVkaWEg c3RyZWFtcyB0byBkQ0ROJnF1b3Q7IGlzIG5vdCBnb29kIHRoYW4gJnF1b3Q7dUNETiBkZWxpdmVy cyBvbmUgbWVkaWEgc3RyZWFtIHRvIGRDRE4gYW5kIGRDRE4gdGFrZXMgc29tZSBhZGFwdGF0aW9u IHRvIHN1cHBvcnQgbXVsdGlwbGUNCiBtZWRpYSB0eXBlcyZxdW90Oy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3cg d2hhdCB5b3UncmUgdGFsa2luZyBhYm91dCBpcyBhbiBvcHRpbWlzYXRpb24sIG5vdCBhIGNvcmUg ZnVuY3Rpb24gcmVxdWlyZWQgdG8gYWN0dWFsbHkgZGVsaXZlciB0aGUgY29udGVudCAoYW5kIHJl cG9ydCwgYmlsbCwgZXRjLiBmb3IgdGhhdCBkZWxpdmVyeSkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TXkgcG9zaXRpb24gaXMgdGhhdCB3ZSBz aG91bGQgZm9jdXMgb24gaG93IHRvIGVuYWJsZSB0aGUgaW50ZXJjb25uZWN0aW9uIG9mIHRoZSBj b3JlIENETiBmdW5jdGlvbmFsaXR5IG9mZmVyZWQgYnkgQ0ROcyB0b2RheSAod2hpY2ggaXMgYWxz byBteSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgc2NvcGUgb2YgdGhlIENETkkgd29ya2luZyBncm91 cCBhcyBleHByZXNzZWQgaW4gaXRzDQogY2hhcnRlcikgYmVjYXVzZSBkb2luZyBzbyBpcyBhIHNp Z25pZmljYW50IHBpZWNlIG9mIHdvcmsgaW4gaXRzZWxmLiBMZXQncyBub3Qgc3RhcnQgdHJ5aW5n IHRvIGFkZCBpbiBhZGRpdGlvbmFsIGZ1bmN0aW9uYWxpdHkgYmV5b25kIHdoYXQgdGhlIG1ham9y aXR5IG9mIENETnMgc3VwcG9ydCB0b2RheSBhcyB0aGF0IHdpbGwganVzdCBkZWxheSB1cyBnZXR0 aW5nIHVzYWJsZSBzcGVjaWZpY2F0aW9ucyBpbnRvIHRoZSBtYXJrZXQgaW4gYSB0aW1lbHkNCiBm YXNoaW9uIElNTy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5CZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkEgZ29vZCBxdWVzdGlvbiBpcyAmcXVvdDtzZWN1cml0eSZxdW90OyBzaW5jZSBJ IGhhdmUgZG9uZSBzaXggeWVhcnMgb24gdGhlIERSTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+YW5kIGxpa2UgdG8gcHJvbW90ZSB0aGUgRFJNIGFsbCBhcm91bmQgdGhl IHdvcmxkOikgSWYgdGhlIGNvbnRlbnQgaXMgbmVlZGVkIHRvIGJlIHByb3RlY3RlZCwgZ2VuZXJh bGx5IHlvdSBtYXkga25vdyBhbGwgdGhlIHN5c3RlbXMgc2hvdWxkIGJlIGdyYW50ZWQgYnkgdGhl IGNvbnRlbnQgb3duZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5I ZXJlIEkgYWxzbyBsaWtlIHRvIGNsYXJpZnkgdGhhdCBub3Qgb25seSB0aGUgbWVkaWEgaXRzZWxm IGJ1dCB0aGUgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBzZXJ2aWNlIGl0c2VsZiAoc3VjaCBhcyB0 aGUgZ2VvZ3JhcGhpYyBjb25zdHJhaW50KSBzaG91bGQgYmUgcHJvdGVjdGVkIGFsc28uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TbywgdHJ1c3QgaXMgbm90IGEgcHJv YmxlbSBmb3IgdGhlIG1lZGlhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QaGlsaXAs PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFuayB5b3UgdGhhdCB5 b3UgZmVlbCBDb250ZW50IEFkYXB0aW9uIGlzIGFuIGlzc3VlIGZvciAmcXVvdDtSZXF1aXJlbWVu dHMmcXVvdDsgYnV0IEkgZG8gbm90IGtub3cgd2h5IGl0IGlzIG5vdCBmb3IgVXNlIGNhc2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGxpa2UgdG8gY2xhcmlmeSB0 byBVIHRoYXQgaXQgaXMgaW1wb3J0YW50IGZvciB5b3Ugb3BlcmF0b3Igc2luY2UgaXQgbWF5IHNh dmUgaW52ZXN0bWVudCBpZiB0aGUgc3lzdGVtIG1heSBzdXBwb3J0IGRpZmZlcmVudCBzZXJ2aWNl cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciB1cyB2ZW5kb3Is IHdlIGFyZSBoYXBweSBvcGVyYXRvciBtYXkgaW5zdGFsbCBhIHN5c3RlbSBmb3IgdGhlIG1vYmls ZSBzZXJ2aWNlIGFuZCBhbm90aGVyIHN5c3RlbSBmb3IgdGhlIEZCQiBzZXJ2aWNlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IHRoZSByZWFsaXR5IGlzIGFsbCBv cGVyYXRvcnMgYXNrIHVzIHRvIHByb3ZpZGUgYSBzeXN0ZW0gdGhhdCBtYXkgc3VwcG9ydCBkaWZm ZXJlbnQgc2VydmljZSBzeXN0ZW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5GcmFu a2x5LCBCZW4gYW5kIFBoaWxpcCwgSSByZW1lbWJlciBJIGhhdmUgZXhwbGFpbmVkIHNvbWV3aGVy ZSB0aGF0IHRvIGltcGxlbWVudCB0aGlzIGlzIHJhdGhlciBzaW1wbGUgLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QXQgbGVhc3QgdGhlIFVzZSBjYXNlIGFuZCBSZXF1 aXJlbWVudCBhcmUgaW5mb3JtYXRpb25hbCB0byBiZSByZWZlcnJlZCBpbiBmdXR1cmUgd29yay4g U28gSSBkbyByZWFsbHkgZmVlbCB5b3UgbWF5IGFjY2VwdCBpdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9mIGNvdXJzZSBJIGxpa2UgdG8gcmVzcG9uZCB5b3VyIG1v cmUgY29uY2VybiBhbmQgY29tbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5a aGlwZW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTogPGEgaHJlZj0ibWFpbHRvOnBoaWxpcC5l YXJkbGV5QGJ0LmNvbSI+DQpwaGlsaXAuZWFyZGxleUBidC5jb208L2E+IFs8YSBocmVmPSJtYWls dG86cGhpbGlwLmVhcmRsZXlAYnQuY29tIj5tYWlsdG86cGhpbGlwLmVhcmRsZXlAYnQuY29tPC9h Pl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlbnQ6IE1vbmRheSwg T2N0b2JlciAxMCwgMjAxMSAxMToyMiBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VG86IDxhIGhyZWY9Im1haWx0bzpiZW5Abml2ZW4tamVua2lucy5jby51ayI+DQpi ZW5Abml2ZW4tamVua2lucy5jby51azwvYT47IFpob3VaaGlwZW5nPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DYzogPGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmci PmNkbmlAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5TdWJqZWN0OiBSRTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2Fz ZXMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlbiwgWmhpcGVuZywgYWxs LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIHRoaW5rIHRoYXQgQ29udGVudCBBZGFw dGF0aW9uIGlzIG1vcmUgYW4gaXNzdWUgZm9yIHRoZSBSZXF1aXJlbWVudHMgZG9jIHRoYW4gZm9y IHRoZSBVc2UgY2FzZXMgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBr ZXkgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSB3YW50IHRoZSBDRE5JIGludGVyZmFjZXMgdG8gYmUg YWJsZSB0byBjb3BlIHdpdGggYSBzY2VuYXJpbyB3aGVyZSAoc2F5KSBIRC9TRCBjb252ZXJzaW9u IGlzIGRvbmUgaW4gdGhlIGRDRE4gJmFtcDsgdG8gc2lnbmFsIGFib3V0IHRoaXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgdGhpbmsgdGhhdCBjb3Bpbmcgd2l0aCB0aGlzIHNjZW5h cmlvIGlzIGEgc2Vjb25kIG9yZGVyIHJlcXVpcmVtZW50LCBpZSB3ZSBzaG91bGQgbm90IHdvcnJ5 IGFib3V0IGl0IGluIHRoZSBpbml0aWFsIHN0YW5kYXJkcy10cmFjayB3b3JrLiBJIGRvbid0IGtu b3csIGRpZCB3ZSBldmVyIGRlY2lkZSB3aGV0aGVyIHRoZSBVc2UgY2FzZXMgZG9jIGlzIHJlc3Ry aWN0ZWQgdG8gJnF1b3Q7aW5pdGlhbCZxdW90Ow0KIHNjZW5hcmlvcywgb3Igd2hldGhlciBpdCdz IGFsbC1lbmNvbXBhc3NpbmcsIGllIGNvdmVyaW5nICZxdW90O2Z1dHVyZSZxdW90OyBzY2VuYXJp b3MgYXMgd2VsbD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2NvdHQsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWFkaW5nIHNvbWUgb2YgeW91ciBleGFt cGxlcywgdGhleSBzZWVtIHRvIGJlIHZhbGlkIGV2ZW4gaWYgY29udGVudCBhZGFwdGF0aW9uIChI RC9TRCkgaXMgb3V0IG9mIHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+LSBhIGRDRE4gbWlnaHQgZm9yIHNvbWUgcmVhc29uIGJlIHVud2lsbGluZyB0byBkaXN0 cmlidXRlIEhEPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LSBhIENT UCBtaWdodCB3YW50IHRvIG1ha2Ugc3VyZSB0aGUgZENETiBjYW4gdXNlIEhMUyBlbmNhcHN1bGF0 aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IHRoZXNlIHNv cnRzIG9mIGV4YW1wbGVzIHNlZW0gdG8gYmUgc3RhdGljIHBvbGljeSB0aGluZ3MgKHRvIGRvPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj53aXRoIHRoZSBjYXBhYmlsaXRp ZXMgJmFtcDsgcHJlZmVyZW5jZXMgb2YgdGhlIENETnMgJmFtcDsgQ1NQKSwgcmF0aGVyIHRoYW48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPm1ldGFkYXRhIGFzc29jaWF0 ZWQgd2l0aCBhIHBhcnRpY3VsYXIgcGllY2Ugb2YgY29udGVudC4gSW4gdGhlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5kaXNjdXNzaW9uIHNvIGZhciwgSSB0aGluayBu ZWdvdGlhdGlvbiBhYm91dCBzdGF0aWMgcG9saWN5IHN0dWZmIGlzPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5yYXRoZXIgb3V0IG9mIHNjb3BlKD8pPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9uIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBhbiBpbnRlcmVz dGluZyBxdWVzdGlvbiBpcyB3aGV0aGVyIHRydXN0IGlzIHRyYW5zaXRpdmUuIERvbid0IHRoaW5r IGl0IG5lZWQgYmUgLSBqdXN0IGJlY2F1c2UgQ1NQIHRydXN0cyB1Q0ROLCBhbmQgdUNETiB0cnVz dHMgZENETiBkb2Vzbid0IG1lYW4gdGhhdCB0aGUgQ1NQIGF1dG9tYXRpY2FsbHkgdHJ1c3RzIHRo ZSBkQ0ROLg0KIEhvd2V2ZXIsIGkgc3VzcGVjdCB0aGlzIGNhbiBnZXQgYXJiaXRyYXJpbHkgY29t cGxleCAtIHNvIG9uZSBwb3NzaWJpbGl0eSBpcyB0byBzYXkgdGhhdCB3ZSB3aWxsIG9ubHkgaGFu ZGxlIGNhc2VzIHdoZXJlIHRoZSB0cnVzdCBpcyB0cmFuc2l0aXZlLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5CZXN0IHdpc2hlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+cGhpbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBoaWxpcCBFYXJkbGV5PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXNlYXJjaCBhbmQgVGVjaG5vbG9neSBT dHJhdGVneTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGVtYWlsIGNvbnRhaW5z IEJUIGluZm9ybWF0aW9uLCB3aGljaCBtYXkgYmUgcHJpdmlsZWdlZCBvciBjb25maWRlbnRpYWwu IEl0J3MgbWVhbnQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwocykgb3IgZW50aXR5IG5hbWVkIGFi b3ZlLiBJZiB5b3UncmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG5vdGUgdGhhdCBkaXNj bG9zaW5nLCBjb3B5aW5nLCBkaXN0cmlidXRpbmcNCiBvciB1c2luZyB0aGlzIGluZm9ybWF0aW9u IGlzIHByb2hpYml0ZWQuIElmIHlvdSd2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2UgbGV0IG1lIGtub3cgaW1tZWRpYXRlbHkgb24gdGhlIGVtYWlsIGFkZHJlc3MgYWJvdmUu IFRoYW5rIHlvdS4gV2UgbW9uaXRvciBvdXIgZW1haWwgc3lzdGVtLCBhbmQgbWF5IHJlY29yZCB5 b3VyIGVtYWlscy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJyaXRp c2ggVGVsZWNvbW11bmljYXRpb25zIHBsYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+UmVnaXN0ZXJlZCBvZmZpY2U6IDgxIE5ld2dhdGUgU3RyZWV0IExvbmRvbiBFQzFB IDdBSiBSZWdpc3RlcmVkIGluPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5FbmdsYW5kIG5vOiAxODAwMDAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 IDxhIGhyZWY9Im1haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmciPg0KY2RuaS1ib3VuY2VzQGll dGYub3JnPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmNkbmktYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv OmNkbmktYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T2YgQmVuIE5pdmVuLUplbmtpbnM8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlbnQ6IDEwIE9jdG9iZXIgMjAxMSAxMjowNDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VG86IFpob3VaaGlwZW5nPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5DYzogPGEgaHJlZj0ibWFpbHRvOmNk bmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5TdWJqZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt Y2RuaS11c2UtY2FzZXMtMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNvbGxl YWd1ZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPklNTyBTZWN0aW9uIDUuMS4zIHNo b3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIFVzZSBDYXNlcyBkcmFmdC4gQ29udGVudCBBZGFwdGF0 aW9uIChpLmUuIHRha2luZyBpbiBhIGNvbnRlbnQgaXRlbSBpbiBvbmUgZm9ybWF0IGFuZCB0cmFu c2Zvcm1pbmcgaXQgdG8gYW5vdGhlciBmb3JtYXQgb3IgcmVwcmVzZW50YXRpb24pIGlzIG5vdCBh ICZxdW90O2NvcmUmcXVvdDsgZnVuY3Rpb24gb2YgYSBDRE4NCiB3aGljaCB0eXBpY2FsbHkgZGVs aXZlcnMgdGhlIGNvbnRlbnQgdGhhdCBpcyByZXF1ZXN0ZWQgd2l0aG91dCBleHBsaWNpdCBrbm93 bGVkZ2Ugb2Ygd2hhdCB0aGF0IGNvbnRlbnQgYWN0dWFsbHkgaXMuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPkxldCdzIG5vdCBmb3JnZXQgdGhhdCBpbiBidWlsZGluZyBhbiBlbmQgdG8g ZW5kIGNvbnRlbnQgc2VydmljZSB0aGUgQ0ROIGlzIG9ubHkgb25lIGNvbXBvbmVudCBhbmQgaXMg dGhlIGNvbXBvbmVudCB0YXNrZWQgd2l0aCBleGVjdXRpbmcgdGhlIGRlbGl2ZXJ5IG9mIGEgc3Bl Y2lmaWMgcmVwcmVzZW50YXRpb24gKHZlcnNpb24vY29weS9mb3JtYXQgZXRjLikgb2YgdGhlIHNl bGVjdGVkDQogY29udGVudCBub3QgdGhlIGNvbXBvbmVudCB0YXNrZWQgd2l0aCBkZWNpZGluZyAo b3IgYXBwbHlpbmcgcG9saWN5KSBvbiB3aGljaCB2ZXJzaW9uL2NvcHkvcmVwcmVzZW50YXRpb24g b2YgY29udGVudCBzaG91bGQgYmUgZGVsaXZlcmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGUgZGVjaXNpb24gYXMgdG8gd2hpY2ggdmVyc2lvbi9jb3B5L3JlcHJlc2VudGF0aW9u IHRvIG9mZmVyIGFuZCBhbGxvdyB0byBiZSBkZWxpdmVyZWQgdG8gYSBnaXZlbiBkZXZpY2UvdXNl ciBpcyBpbXBsZW1lbnRlZCBvdXRzaWRlIG9mIHRoZSBDRE4gKGUuZy4gYnkgdGhlICZxdW90O3Bv cnRhbCZxdW90OyB3aGVyZSB0aGUgdXNlciBmaXJzdCBtYWtlcyB0aGVpciBjb250ZW50IHNlbGVj dGlvbg0KIHByaW9yIHRvIHRoZSBDRE4gYmVjb21pbmcgaW52b2x2ZWQgaW4gdGhlIGRlbGl2ZXJ5 IG9mIHRoZSBzZWxlY3RlZCBjb250ZW50KS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ QmVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDggT2N0IDIwMTEsIGF0IDA4OjIw LCBaaG91WmhpcGVuZyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gb2xs b3dpbmcgU2NvdHQncyBjb21tZW50cyBvbiBzZWN0aW9uIDUuMS4zLCBJIGZlZWwgU2NvdHQncyBk ZXNjcmlwdGlvbiBvbiB0aGUgdXNlIGNhc2Ugb2YgSEQgYW5kIFNEIGlzIG5vdCBleGFjdGx5IGNv cnJlY3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPklmIG9uZSBtb3ZpZSBoYXMgdHdvIGZvcm1hdHMgb2YgSEQgYW5kIFNELCB0aGVuIHdl IGhhdmUgdHdvIGNvbnRlbnQgd2l0aCBkaWZmZXJlbnQgaWRlbnRpZmllci4gSW4gRFJNIHNjb3Bl LCB0aGUgYmFzaWMgdW5pdCBpcyBhIGNvbnRlbnQgY29weS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkhlcmUgdGhlIGZpcnN0 IGJ1bGxldCAmcXVvdDthIHN1YnNldCBvZiBlbmNvZGluZ3MgZGVsaXZlcmFibGUgdG8gc3BlY2lm aWMgZGV2aWNlcywmcXVvdDsgaGFzIGxpc3RlZCB0aGUgY2FzZSBvZiBjb250ZW50IGFkYXB0YXRp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkluIGxhc3QgbW9udGgsIEkgaGF2ZSBjb250YWN0ZWQgdGhlIEF1dGhvcnMgb2YgdGhpcyBk b2N1bWVudCBhbmQgdGFrZW4gc29tZSBlbWFpbCBleGNoYW5nZXMgd2l0aCBHcmFudCBhbmQgUGhp bGlwIChCVCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkkgaGF2ZSBzaG93biBCVCB3aXRoIHNvbWUgaW5mb3JtYXRpb24gdGhhdCBJIGtu b3cgaW4gdGhpcyBjYXNlIGFuZCBhcmVhIHRvIGV4cGxhaW4gdGhlIGNvbnRlbnQgZmxleGliaWxp dHkgaXMgY3VycmVudGx5IGEgYmFzaWMgcmVxdWlyZW1lbnQgZm9yIENETiBzZXJ2aWNlIGFuZCBy ZWxhdGVkIG5lZ290aWF0aW9uIGlzIG5lZWRlZCBpbiB0aGUgQ0ROIGludGVyY29ubmVjdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ TWVhbndoaWxlLCBJIHNob3VsZCBhbHNvIGludml0ZSB5b3UgaW4gdGhpcyBncm91cCByYWlzaW5n IHlvdXIgY29tbWVudHMgb3IgcXVlc3Rpb25zIG9uIHRoaXMgY2FzZSBzaW5jZSBJIGhvcGUgbXkg dXNlIGNhc2UgbWF5IGJlIGluY29ycG9yYXRlZCBpbiB0aGUgdXNlIGNhc2UgZHJhZnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5JZiB5b3UgaGF2ZSBhbnkgbW9yZSBxdWVzdGlvbiBvciBjb21tZW50cywgcGxzIHNoYXJlIGlu IHRoaXMgdGhyZWFkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5UaGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlpoaXBlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTogU2NvdHQgV2Fp bm5lciBbPGEgaHJlZj0ibWFpbHRvOnN3YWlubmVyQGNpc2NvLmNvbSI+bWFpbHRvOnN3YWlubmVy QGNpc2NvLmNvbTwvYT5dPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPlNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDMwLCAyMDExIDg6MDIgQU08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ VG86IDxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TdWJq ZWN0OiBSZTogW0NETmldIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2RuaS11c2UtY2FzZXMtMDAu dHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5TZWN0aW9uIDIuMyBOb21hZGljIFVzZXJzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoaXMgZGVzY3JpcHRpb24gZmFs bHMgdW5kZXIgdGhlIGNhdGVnb3J5IG9mIEdlb2dyYXBoaWMgRXh0ZW5zaW9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnlldCB0aGUgdGhp cmQgcGFyYWdyYXBoIHN0YXRlcyB0aGUgY2FzZSB3aGVyZSBhIGRpZmZlcmVudCBkZXZpY2UgaXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ dXNlZCBpbiB0aGUgc2FtZSBDRE4gY292ZXJhZ2UgYXJlYS4gJm5ic3A7VGhlIGludGVudCBvZiB0 aGlzIHVzZSBjYXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPm5lZWRzIHRvIGJlIGNsYXJpZmllZC4gJm5ic3A7UGVyaGFwcyB0aGUgdXNl IGNhc2UgaXMgdHJ5aW5nIHRvIGFkZHJlc3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+dGhlIHNjZW5hcmlvIHdoZXJlIGEgTm9tYWRpYyBV c2VyLUEgd2l0aCBhbiBhZ3JlZW1lbnQgYWxsb3dpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YWNjZXNzIHRvIGNvbnRlbnQgZnJvbSBD U1AtQSB2aWEgdUNETiBtb3ZlcyB0byBhIGRDRE4gaW4gYSBkaWZmZXJlbnQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+cmVnaW9uLiAmbmJz cDtUaGUgZENETiBpcyBhbGxvd2VkIHRvIGRpc3RyaWJ1dGUgdGhlIGNvbnRlbnQgb2YgQ1NQLUEg dG88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+VXNlci1BOyBob3dldmVyLCBub3Qgb3RoZXIgdXNlcnMgaW4gdGhlIHJlZ2lvbiBvZiB0aGUg ZENETiBhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+YWxsb3dlZCB0byByZXRyaWV2ZSB0aGUgY29udGVudCB1bmxlc3MgdGhleSB0b28g aGF2ZSBzdWNoIGFuIGFncmVlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlY3Rpb24gNS4xLjMgQ29udGVudCBFbmNv ZGluZyBSZXN0cmljdGlvbnMgTmVlZCB0byBjbGFyaWZ5IGlmIHdlJ3JlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnRhbGtpbmcgYWJvdXQg dGhlIHJlc3RyaWN0aW9ucyBvbiB0aGUgZGVsaXZlcnkgb2Ygc3BlY2lmaWMgY29udGVudDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vciB0 aGUgcmVzdHJpY3Rpb25zIG9uIHRoZSBhYmlsaXR5IG9mIGEgQ0ROIHRvIGRlbGl2ZXIgc3BlY2lm aWM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Y29udGVudC4gJm5ic3A7SSBjZXJ0YWlubHkgdW5kZXJzdGFuZCB0aGUgY2FzZSB3aGVyZSBh IENTUCB3aWxsIHJlc3RyaWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPnRoZSBkaXN0cmlidXRpb24gb2YgY29udGVudCB0byBhICZxdW90 O21hbmFnZWQgcGF0aCZxdW90OyBpZiBzdWNoIGNvbnRlbnQgaXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SEQgd2hpbGUgYWxsb3dpbmcg dGhlIGNvbnRlbnQgZGlzdHJpYnV0aW9uIHZpYSBhbiB1bi1tYW5hZ2VkIHBhdGggaWY8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+c3VjaCBj b250ZW50IGlzIFNEIChzYW1lIGNvdWxkIGFwcGx5IHRvIGVuY3J5cHRpb24gbWV0aG9kcywgZGVs aXZlcnk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+bWV0aG9kcywgZXRjLikuICZuYnNwO09uIHRoZSBjb250cmFyeSwgdGhlIGRDRE4gbWF5 IGhhdmUgaXRzIG93bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5yZXN0cmljdGlvbnMgb2YgYmxvY2tpbmcgdGhlIGRpc3RyaWJ1dGlvbiBv ZiBIRCBjb250ZW50IHdoaWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPmFsbG93aW5nIHRoZSBkaXN0cmlidXRpb24gb2YgU0QgY29udGVu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPm8gZmlyc3QgYnVsbGV0IG1ha2VzIHNlbnNlIGlmIHRoZSBkQ0ROIGNhbiBwZXJm b3JtIGEgc3Vic2V0IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPmVuY2Fwc3VsYXRpb25zIGZvciBhIHJlZmVyZW5jZSBzZXQgb2YgbWVk aWEgKGUuZy4gSExTLCBIU1MsIGJ1dCBub3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+REFTSCkgbyBzZWNvbmQgYnVsbGV0IG1ha2VzIHNl bnNlIHdoZXJlIHRoZSBkQ0ROIGRvZXNuJ3Qgd2FudCB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5vZmZlciBoaWdoIGJpdC1yYXRlIHZh cmlhbnRzIG9mIHRoZSBtZWRpYSBvIHRoaXJkIGJ1bGxldCBtYWtlIHNlbnNlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmlmIHRoZSBwb2xp Y3kgYWRkcmVzc2VzIFFvRSBidXQgSSBkb24ndCB0aGluayBzdWJzY3JpYmVyPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJpZ2h0cy9hdXRo b3JpemF0aW9ucyBhcHBseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlNlY3Rpb24gMTAgU2VjdXJpdHkgQ29uc2lkZXJhdGlv bnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkFzaWRlIGZyb20gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIFdJVEhJTiB0 aGUgdUNETiBhbmQgZENETiwgSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj50aGluayB3ZSBjYW4gZGVzY3JpYmUgdGhpcyBpbiBmb3VyIGNv bnRleHRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90 ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+YS4gVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBDU1AgYW5kIHRo ZSB1Q0ROICh0aGUgcHJpbmNpcGxlIGNvbnRyYWN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmFycmFuZ2VtZW50IGZvciBkaXN0cmlidXRp b24pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPmIuIFRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgdUNETiBhbmQgZENETiAodGhlIHRy YW5zaXRpdmUgdHJ1c3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Js b2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+cmVsYXRpb25zaGlwIHRoYXQgZXh0ZW5kcyB0aGUgY29udHJhY3QgZGVm aW5lZCBpbiAoYSkgYWJvdmUpIGMuIFRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5yZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgVXNlciBh bmQgZENETiAodGhlIHJlY29nbml0aW9uIG9mIHJpZ2h0IHRvPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmRvd25sb2FkIHByZWRpY2F0ZWQg b24gKGIpIGFib3ZlKSBkLiBUaGUgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlVzZXIgYW5kIENT UCAodGhlIGNvbnRyYWN0IGF1dGhvcml6aW5nIHRoZSB1c2VyIGFjY2VzcyB0byB0aGU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Y29udGVu dCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1 b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoZSB1c2VyIGlzIG5vdCBpbnRlcmVzdGVkIGluIHRoZSBhLWIgbm9yIHRoZSBi LWMgcmVsYXRpb25zaGlwLiBUaGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+dXNlciBpcyBvbmx5IGludGVyZXN0ZWQgaW4gdGhlIHRyYW5z cGFyZW5jeSBhbmQgaW50ZXJvcGVyYWJpbGl0eSBvZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50aGUgc2VjdXJpdHkgcmVsYXRpb25zaGlw IGJldHdlZW4gZC1iIG9yIGQtYyB0byB0aGUgcG9pbnQgdGhhdCB0aGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+YXV0aG9yaXphdGlvbiBn cmFudGVkIGluIGQtYSBpcyB2aWFibGUgd2hlbiB0aGUgZGVsaXZlcnkgaXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+aW5pdGlhdGVkIHZp YSBlaXRoZXIgZC1iIG9yIGQtYy4gJm5ic3A7QXMgYW4gZXhhbXBsZSwgdGhlIHVDRE4gbWlnaHQg dXNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPlVSTCBhcHBlbmRlZCB0b2tlbnMgZm9yIGF1dGhlbnRpY2F0aW9uIHdoaWxlIGRDRE4gbWln aHQgdXNlIFVSTDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5hcHBlbmRlZCBoYXNoZXMuICZuYnNwO1RoZSB1c2VyIGRvZXNuJ3Qgd2FudCB0 byBrbm93IGFib3V0IHRoZSBkaXN0aW5jdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5tZXRob2RzLCBidXQgdHJhbnNwYXJlbmN5IGlzIG9u bHkgYWZmb3JkZWQgaWYgdGhlIG1ldGhvZHMgYXJlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPmludGVyb3BlcmFibGUgY2xlYXJseSBkZWZp bmVkIHdoZW4gdGhlIGRlbGVnYXRpb24gZm9yIGNvbnRlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ZGVsaXZlcnkgaXMgZXhlY3V0ZWQu ICZuYnNwO0NsZWFybHksIHRoZSBjaG9pY2Ugb2YgYXV0aGVudGljYXRpb24gbWV0aG9kIGlzIGRl dGVybWluZWQgYnkgdGhlIHJlc3BlY3RpdmUgQ0ROJ3MuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5TY290dDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q0ROaSBtYWlsaW5n IGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0ibWFpbHRvOkNETmlAaWV0Zi5vcmciPkNETmlAaWV0Zi5vcmc8L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Q0ROaSBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxhIGhyZWY9Im1haWx0bzpDRE5pQGlldGYub3JnIj5DRE5pQGlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2Nkbmk8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpDRE5pIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpDRE5pQGlldGYub3Jn Ij5DRE5pQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY2RuaSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jZG5pPC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KQ0ROaSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q0ROaUBp ZXRmLm9yZyI+Q0ROaUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmkiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY2RuaTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --Boundary_(ID_pUz9GlNEpleNbHhlmXY4ow)-- From emile.stephan@orange.com Wed Nov 2 07:20: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 9DF421F0C73 for ; Wed, 2 Nov 2011 07:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 REd58XBmS2ZG for ; Wed, 2 Nov 2011 07:20:02 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id DBE7F1F0C6B for ; Wed, 2 Nov 2011 07:20:01 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A44288B8005; Wed, 2 Nov 2011 15:21:23 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 9593F6C0001; Wed, 2 Nov 2011 15:21:23 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 15:20:00 +0100 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: Wed, 2 Nov 2011 15:19:58 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201FE5136@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B6A69184@MAILR002.mail.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] draft-ma-cdni-metadata-01.txt: mD objects extensibility Thread-Index: AcyYJBmMY8Bw7e5LSai/Do6RDtbqsQAAGxFgAETNuMA= References: <20111031232338.28460.6679.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C651B6A69184@MAILR002.mail.lan> From: To: , X-OriginalArrivalTime: 02 Nov 2011 14:20:00.0715 (UTC) FILETIME=[819EC1B0:01CC996A] Cc: bsd@cisco.com Subject: [CDNi] draft-ma-cdni-metadata-01.txt: mD objects extensibility 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, 02 Nov 2011 14:20:03 -0000 Hi Kevin, Following are my thoughts on v01. IMO, It is obvious that the framework of CDNi will include objects = extensibility and consequently support opaque metadata. The draft should = focus on the identification of the information elements required to = support the awareness and the restriction of the 7 interfaces listed in = the introduction rather than promoting the need of opaque metadata. So I propose that we add something like following in = draft-davie-cdni-framework: "5 Data modeling Framework 5.1 Objects extensibility CDNs interoperate to distribute content services that may require the = exchange of specific metadata. Consequently each object is extensible and includes a field 'extension' for this purpose. This applies to all = CDNi interfaces. " Regards Emile > -----Message d'origine----- > De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de > Kevin J Ma > Envoy=E9=A0: mardi 1 novembre 2011 00:37 > =C0=A0: cdni@ietf.org > Objet=A0: [CDNi] FW: New Version Notification = fordraft-ma-cdni-metadata- > 01.txt >=20 > An updated version of draft-ma-cdni-metadata has been uploaded. > It fixes some typos, incorporates some of the comments received > from the list, and adds some core metadata definitions. >=20 > comments welcome. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >=20 > A new version of I-D, draft-ma-cdni-metadata-01.txt has been > successfully submitted by Kevin Ma and posted to the IETF repository. >=20 > Filename: draft-ma-cdni-metadata > Revision: 01 > Title: Content Distribution Network Interconnection (CDNI) > Metadata Interface > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 33 >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From emile.stephan@orange.com Wed Nov 2 08:00:41 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 1C75311E80B6 for ; Wed, 2 Nov 2011 08:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 l9WLjXTUc8zS for ; Wed, 2 Nov 2011 08:00:40 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 16D2B11E8099 for ; Wed, 2 Nov 2011 08:00:40 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 45FCAFCC001; Wed, 2 Nov 2011 16:00:39 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 35243FC4001; Wed, 2 Nov 2011 16:00:39 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 16:00:39 +0100 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: Wed, 2 Nov 2011 16:00:37 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201FE5171@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] Control and Metadata interfaces Thread-Index: AcyYqHUmKTVcvctXRhCTBy8VbBP49wAib9tQ References: <78BCE9D8-7C4F-4162-9F6B-867240993EE1@cisco.com> <1CA25301D2219F40B3AA37201F0EACD1136D0BEA@PACDCEXMB05.cable.comcast.com> <843DA8228A1BA74CA31FB4E111A5C46201FE4F05@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 02 Nov 2011 15:00:39.0289 (UTC) FILETIME=[2F1F9E90:01CC9970] Cc: cdni@ietf.org Subject: Re: [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: Wed, 02 Nov 2011 15:00:41 -0000 Hi Ben and Bruce, See inline > -----Message d'origine----- > De=A0: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Envoy=E9=A0: mardi 1 novembre 2011 16:11 > =C0=A0: STEPHAN Emile RD-CORE-LAN > Cc=A0: Richard_Woundy@cable.comcast.com; flefauch@cisco.com; > cdni@ietf.org > Objet=A0: Re: [CDNi] Control and Metadata interfaces >=20 > Emile, Colleagues, >=20 > On 31 Oct 2011, at 22:36, > wrote: > > 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; >=20 > I agree that as we work through the CDNI solution components and how > they fit together the exact functionality placed under each interface > needs to be firmed up compared to what we have currently in the = Problem > Statement and Bruce's framework draft. IMO, this is preventing to go in the detail of the works. Hence IMO we = must asap specify the bootstrapping and the information elements that = must be exchanged during this step. >=20 > I shared some thoughts with some folks offline about the CDNI Control > interface and the two functions of bootstrapping & control of > content/metadata and where they might best fit in the context of CDNI > interfaces but as you bring it up here I'll repeat some of my thoughts > on the list. >=20 > Bootstrapping/(fairly) static capability advertisement: I share your approach but in draft-stephan-cdni-usecase-metadata we = clearly indentify that an object can be really static in a situation and = extremely dynamic in another. This is why I promote that the control = interface and the metadata interface share the same datamodeling = framework and a subset of objects too. >=20 > I tend to think that the CDNI Metadata is essentially (content service > level) configuration information and the CDNI Metadata interface is > about distributing configuration between interconnected CDNs. >=20 > In the case of bootstrapping of the CDNI interfaces and communicating > static (or fairly static) information about capabilities and policies > they can also (IMO) be thought of as essentially CDN/CDNI level > configuration information. >=20 > Although the current proposals for CDNI Metadata data models & > interface specifications only address CDNI Metadata at present I think > it should be possible to build a data model for CDNI > bootstrapping/capabilities that can reuse, for example, the interface > specification and encoding in proposed draft-jenkins-cdni-metadata. = New > objects (and associated relationships & media types) would need to be > specified but that should be fairly straightforward and the base > interface proposed could be reused for both content service > configuration (aka CDNI Metadata) and CDN/CDNI configuration (aka > bootstrapping/capabilities). >=20 > So it would seem to me a reasonable proposal to move the > bootstrapping/capability elements currently nominally placed under > "CDNI Control" to become part of the CDNI Metadata interface >=20 >=20 > Control of content: >=20 > In the case of control of content although draft-davie-cdni-framework- > 01 puts forward the view that "a purge is equivalent to a statement > that the availability window for that content has now expired" I think > the requirements placed on purging/invalidating/pre-positioning = content > require functionality not covered by the current CDNI Metadata > proposals. =20 I agree. CSP require explicit purge. This is an operation of control.=20 >=20 > In contrast to the distribution of CDNI Metadata which is a dCDN > discovering (or being told) the content service level configuration it > needs, invalidating/purging content is the uCDN requesting the dCDN > perform some task on its behalf (e.g. purge this item of actual > content). >=20 > A key factor that IMO separates purge/pre-position from CDNI Metadata > is the timing & feedback aspects. When a dCDN pulls CDNI Metadata from > a uCDN (or when a uCDN pushes CDNI Metadata into a dCDN) it's > reasonable for the uCDN to assume the dCDN has some mechanism to > distribute that so it is available to Surrogates when they require it. > In the case of push (via a HTTP POST for e.g.) the dCDN's response of > "201 Created" is saying "I got that metadata record and created a > resource for it on the server you POSTed to" it says nothing about > whether or not the Metadata was distributed to the rest of the system > (same for pull via GET except the acceptance by the dCDN is implicit). >=20 > In the case of purge/pre-position the uCDN will want explicit feedback > to know that the purge/pre-position "task" it has requested has been > distributed within the dCDN and completed by the dCDN. The dCDN's "201 > Created" response would be saying "I got that request for purge and I > have created a resource [task] for it on the server you POSTed to". If > we're being RESTful the Location: header in the 201 response would = link > to a resource that could be queried by the uCDN to check the progress > of the task. The nature of purge/pre-position requests means they may > take some time to complete and so trying to overload the meaning of = the > 201 with "I got that task and I've completed it" doesn't seem = realistic > to me. >=20 > Therefore purge/invalidate/pre-position of actual content (as opposed > to CDNI Metadata) is in my mind a separate beast to distributing the > actual CDNI Metadata and requires a different behaviour from the > interface used to implement purge/invalidate/pre-position from that > used to distribute CDNI Metadata. >=20 > Whether we incorporate that different behaviour under the banner of a > "CDNI Control interface" or an extended/richer "CDNI Metadata > interface" is to some extent semantics but I do think it needs > something more than is required purely for the distribution of CDNI > Metadata between interconnected CDNs. >=20 > Ben >=20 Here is my proposal refined: - The framework document splits the control interface in 2 parts: o bootstrapping of the CDN interconnection; o control of the contents distribution; - The control of the contents distribution and the Metadata interface = share the same datamodeling framework (datamodel parts, protocols...); - The framework document specifies precisely the bootstrapping = (operations and information elements) - The framework document specifies the datamodeling framework; Regards Emile From kevin.ma@azukisystems.com Wed Nov 2 15:31: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 F3A5311E8109 for ; Wed, 2 Nov 2011 15:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 5AwNP1RMZyOm for ; Wed, 2 Nov 2011 15:31:43 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5123411E80F1 for ; Wed, 2 Nov 2011 15:31:43 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id AC6CC554860; Wed, 2 Nov 2011 18:31:42 -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 55F0D554A6C; Wed, 2 Nov 2011 18:31:42 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Wed, 2 Nov 2011 18:30:39 -0400 From: Kevin J Ma To: "emile.stephan@orange.com" , "cdni@ietf.org" Date: Wed, 2 Nov 2011 18:30:51 -0400 Thread-Topic: [CDNi] draft-ma-cdni-metadata-01.txt: mD objects extensibility Thread-Index: AcyYJBmMY8Bw7e5LSai/Do6RDtbqsQAAGxFgAETNuMAAEwxMwA== Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6B12954@MAILR002.mail.lan> References: <20111031232338.28460.6679.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C651B6A69184@MAILR002.mail.lan> <843DA8228A1BA74CA31FB4E111A5C46201FE5136@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <843DA8228A1BA74CA31FB4E111A5C46201FE5136@ftrdmel0.rd.francetelecom.fr> 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: "bsd@cisco.com" Subject: Re: [CDNi] draft-ma-cdni-metadata-01.txt: mD objects extensibility 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, 02 Nov 2011 22:31:44 -0000 Hi Emile, By extensible, I mean that uCDNs should be able to define their own private metadata (if they want) to describe delivery functions that they support and if a dCDN understands it then that's great, but if not then the uCDN should be able to specify whether or not the dCDN must decline to serve the content. In general, I favor a protocol which has opaque data encapsulation, using a layered approach, but, there are certainly other ways to do it, and the WG may choose to go a different route. I don't know if an 'extension' field is the best approach, but I hope that the CDNI MI specification will ultimately support vendor defined metadata. thanx. -- Kevin J. Ma > -----Original Message----- > From: emile.stephan@orange.com [mailto:emile.stephan@orange.com] > Sent: Wednesday, November 02, 2011 10:20 AM > To: Kevin J Ma; cdni@ietf.org > Cc: ben@niven-jenkins.co.uk; mcaulfie@cisco.com; bsd@cisco.com > Subject: [CDNi] draft-ma-cdni-metadata-01.txt: mD objects extensibility >=20 > Hi Kevin, >=20 > Following are my thoughts on v01. >=20 > IMO, It is obvious that the framework of CDNi will include objects > extensibility and consequently support opaque metadata. The draft should > focus on the identification of the information elements required to > support the awareness and the restriction of the 7 interfaces listed in > the introduction rather than promoting the need of opaque metadata. >=20 > So I propose that we add something like following in draft-davie-cdni- > framework: >=20 > "5 Data modeling Framework > 5.1 Objects extensibility >=20 > CDNs interoperate to distribute content services that may require the > exchange of > specific metadata. Consequently each object is extensible and > includes a field 'extension' for this purpose. This applies to all CDN= i > interfaces. > " >=20 > Regards > Emile >=20 > > -----Message d'origine----- > > De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part = de > > Kevin J Ma > > Envoy=E9=A0: mardi 1 novembre 2011 00:37 > > =C0=A0: cdni@ietf.org > > Objet=A0: [CDNi] FW: New Version Notification fordraft-ma-cdni-metadata= - > > 01.txt > > > > An updated version of draft-ma-cdni-metadata has been uploaded. > > It fixes some typos, incorporates some of the comments received > > from the list, and adds some core metadata definitions. > > > > comments welcome. > > > > thanx. > > > > -- Kevin J. Ma > > > > > > A new version of I-D, draft-ma-cdni-metadata-01.txt has been > > successfully submitted by Kevin Ma and posted to the IETF repository. > > > > Filename: draft-ma-cdni-metadata > > Revision: 01 > > Title: Content Distribution Network Interconnection (CDNI) > > Metadata Interface > > Creation date: 2011-10-31 > > WG ID: Individual Submission > > Number of pages: 33 > > > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From richard_woundy@cable.comcast.com Wed Nov 2 17:05: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 1D74111E80E0 for ; Wed, 2 Nov 2011 17:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.011 X-Spam-Level: X-Spam-Status: No, score=-102.011 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, 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 MzGIp2386BQA for ; Wed, 2 Nov 2011 17:05:57 -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 6BD6211E8073 for ; Wed, 2 Nov 2011 17:05:57 -0700 (PDT) Received: from ([24.40.55.40]) by copdcimo01.cable.comcast.com with ESMTP id 5503630.59892220; Wed, 02 Nov 2011 18:13:43 -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.0339.001; Wed, 2 Nov 2011 20:05:45 -0400 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: Tentative agenda for IETF 82 Thread-Index: AcyZvFR0ZdxxVtBFTfyb+Eghl5goNA== Date: Thu, 3 Nov 2011 00:05:44 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1136DAD47@PACDCEXMB05.cable.comcast.com> 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: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1136DAD47PACDCEXMB05cabl_" MIME-Version: 1.0 Subject: [CDNi] Tentative agenda for 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: Thu, 03 Nov 2011 00:05:58 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1136DAD47PACDCEXMB05cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, I uploaded a tentative agenda to http://www.ietf.org/proceedings/82/agenda/= cdni.html. We need to lock down topics and presenters by Monday November 7. Also let t= he co-chairs know if any topics are missing. -- Rich --_000_1CA25301D2219F40B3AA37201F0EACD1136DAD47PACDCEXMB05cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

I uploaded a tentative agenda to http://www.ietf.org/proceedings/82/agenda/cdni.html.

 

We need to lock down topics and presenters by Monday= November 7. Also let the co-chairs know if any topics are missing.

 

-- Rich

--_000_1CA25301D2219F40B3AA37201F0EACD1136DAD47PACDCEXMB05cabl_-- From emile.stephan@orange.com Thu Nov 3 01:11: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 B5D8311E80C9 for ; Thu, 3 Nov 2011 01:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 TWJCyD00jEvJ for ; Thu, 3 Nov 2011 01:11:29 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id AD07711E80A3 for ; Thu, 3 Nov 2011 01:11:28 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A62B18B807B; Thu, 3 Nov 2011 09:12:48 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 99B048B804D; Thu, 3 Nov 2011 09:12:48 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Nov 2011 09:11:25 +0100 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: Thu, 3 Nov 2011 09:11:21 +0100 Message-ID: <843DA8228A1BA74CA31FB4E111A5C46201FE526A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B6B12954@MAILR002.mail.lan> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] draft-ma-cdni-metadata-01.txt: mD objects extensibility Thread-Index: AcyYJBmMY8Bw7e5LSai/Do6RDtbqsQAAGxFgAETNuMAAEwxMwAAe13kA References: <20111031232338.28460.6679.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C651B6A69184@MAILR002.mail.lan> <843DA8228A1BA74CA31FB4E111A5C46201FE5136@ftrdmel0.rd.francetelecom.fr> <291CC3F9E50E7641901A54E85D0977C651B6B12954@MAILR002.mail.lan> From: To: , X-OriginalArrivalTime: 03 Nov 2011 08:11:25.0779 (UTC) FILETIME=[2E811230:01CC9A00] Cc: bsd@cisco.com Subject: Re: [CDNi] draft-ma-cdni-metadata-01.txt: mD objects extensibility 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, 03 Nov 2011 08:11:29 -0000 Hi Kevin, See below. > -----Message d'origine----- > De=A0: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Envoy=E9=A0: mercredi 2 novembre 2011 23:31 > =C0=A0: STEPHAN Emile RD-CORE-LAN; cdni@ietf.org > Cc=A0: ben@niven-jenkins.co.uk; mcaulfie@cisco.com; bsd@cisco.com > Objet=A0: RE: [CDNi] draft-ma-cdni-metadata-01.txt: mD objects > extensibility >=20 > Hi Emile, >=20 > By extensible, I mean that uCDNs should be able to define their own > private metadata (if they want) to describe delivery functions that > they support and if a dCDN understands it then that's great, but if > not then the uCDN should be able to specify whether or not the dCDN > must decline to serve the content. >=20 > In general, I favor a protocol which has opaque data encapsulation, > using a layered approach, but, there are certainly other ways to do > it, and the WG may choose to go a different route. I don't know if > an 'extension' field is the best approach, but I hope that the CDNI > MI specification will ultimately support vendor defined metadata. IMO, we don't need to lost time and energy on this point. To go further we need to add the support of proprietary defined metadata = in the req and framework documents. Regards Emile >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > > -----Original Message----- > > From: emile.stephan@orange.com [mailto:emile.stephan@orange.com] > > Sent: Wednesday, November 02, 2011 10:20 AM > > To: Kevin J Ma; cdni@ietf.org > > Cc: ben@niven-jenkins.co.uk; mcaulfie@cisco.com; bsd@cisco.com > > Subject: [CDNi] draft-ma-cdni-metadata-01.txt: mD objects > extensibility > > > > Hi Kevin, > > > > Following are my thoughts on v01. > > > > IMO, It is obvious that the framework of CDNi will include objects > > extensibility and consequently support opaque metadata. The draft > should > > focus on the identification of the information elements required to > > support the awareness and the restriction of the 7 interfaces listed > in > > the introduction rather than promoting the need of opaque metadata. > > > > So I propose that we add something like following in draft-davie- > cdni- > > framework: > > > > "5 Data modeling Framework > > 5.1 Objects extensibility > > > > CDNs interoperate to distribute content services that may require > the > > exchange of > > specific metadata. Consequently each object is extensible and > > includes a field 'extension' for this purpose. This applies to = all > CDNi > > interfaces. > > " > > > > Regards > > Emile > > > > > -----Message d'origine----- > > > De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la > part de > > > Kevin J Ma > > > Envoy=E9=A0: mardi 1 novembre 2011 00:37 > > > =C0=A0: cdni@ietf.org > > > Objet=A0: [CDNi] FW: New Version Notification fordraft-ma-cdni- > metadata- > > > 01.txt > > > > > > An updated version of draft-ma-cdni-metadata has been uploaded. > > > It fixes some typos, incorporates some of the comments received > > > from the list, and adds some core metadata definitions. > > > > > > comments welcome. > > > > > > thanx. > > > > > > -- Kevin J. Ma > > > > > > > > > A new version of I-D, draft-ma-cdni-metadata-01.txt has been > > > successfully submitted by Kevin Ma and posted to the IETF > repository. > > > > > > Filename: draft-ma-cdni-metadata > > > Revision: 01 > > > Title: Content Distribution Network Interconnection (CDNI) > > > Metadata Interface > > > Creation date: 2011-10-31 > > > WG ID: Individual Submission > > > Number of pages: 33 > > > > > > > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Thu Nov 3 06:39: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 C470611E8087 for ; Thu, 3 Nov 2011 06:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.021 X-Spam-Level: X-Spam-Status: No, score=-7.021 tagged_above=-999 required=5 tests=[AWL=1.705, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, 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 z5ayGMKY2FY2 for ; Thu, 3 Nov 2011 06:39:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC1B1F0C5F for ; Thu, 3 Nov 2011 06:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=34019; q=dns/txt; s=iport; t=1320327589; x=1321537189; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=0rba/2mG/C/G4okq4WQ6G2KQUOmkhGAMx052iG42OQk=; b=MEj6liT2Tg98W7jGQGFnS+QfikHCuetCVgBUWTrTuA1oQ6zFSqk/kCs4 d1rKjXxD9K77wJ8jL6zE8+N5gEH5CAw7MawU8gLTL4mgEQ+agkA7lY5NW XrnIK59oGZtObQzxYeYBqfTWs0jK4pQUineoICw/NO9DZQo/8zVHxtd0u I=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,450,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="120718938" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2011 13:39:48 +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 pA3Ddk6O018531; Thu, 3 Nov 2011 13:39:46 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-167-570487841 From: Francois Le Faucheur In-Reply-To: Date: Thu, 3 Nov 2011 14:39:47 +0100 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: 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: Thu, 03 Nov 2011 13:39:51 -0000 --Apple-Mail-167-570487841 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ben, >>=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/ >=20 > I've just rearranged the ordering slightly so the "however, no = standards..." comes after the example. >=20 > 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. I had considered that option but I don't think that works either, = because the "However..." now seems to refer to the preceding sentence = (ie stuff out of scope) rather than the earlier sentences explaining = that CDN interconnection is needed.=20 >=20 > If you still prefer s/For example/As an example/ I can pick that up in = the next revision? That would be my vote. Thanks. Francois >=20 >>> contract with an "authoritative" CDN for the delivery content >>=20 >> s/delivery content/delivery of content/ >=20 > Done. >=20 >>> 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/ >=20 > Done. >=20 >>=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 >=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-167-570487841 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-168-570487842 --Apple-Mail-168-570487842 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Ben,


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.

I = had considered that option but I don't think that works either, because = the "However..." now seems to refer to the preceding sentence (ie stuff = out of scope) rather than the earlier sentences explaining that CDN = interconnection is needed. 


If you still prefer s/For example/As an example/ = I can pick that up in the next = revision?

That would be my = vote.

Thanks.

Francois



contract with an = "authoritative" CDN for the delivery = content

s/delivery = content/delivery of = content/

Done.

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/

Done.



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
a CDN and between one CDN and = another CDN are out of scope of this =
document.

Ben

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

<image001.jpg>

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




<green.gif>
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






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-168-570487842 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-168-570487842-- --Apple-Mail-167-570487841-- From flefauch@cisco.com Thu Nov 3 06:43:36 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 79EA711E8105 for ; Thu, 3 Nov 2011 06:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.383 X-Spam-Level: X-Spam-Status: No, score=-8.383 tagged_above=-999 required=5 tests=[AWL=2.216, 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 GsRxGlW5kjuu for ; Thu, 3 Nov 2011 06:43:35 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0E44C11E8087 for ; Thu, 3 Nov 2011 06:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=5794; q=dns/txt; s=iport; t=1320327815; x=1321537415; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vvZpSPrYIS64vy/+HdvnZFXUc3o4vyRAV8SiwX42AYs=; b=B924VUU4ygWcYQ/cEPY0QorzZeXWjT2MDwo8vT8ZPQ4nJP+c+jqlVW8r XQn6lMwhmoTCZxePK5zB0WU2l+pvmK/zeEg83Bp0PO9g8N/xn0tq5lSQ0 f2ZVF59bSBoyW4FrjpMuz5rZctEezHSwKVlxg3LueAywIbQP2w0YeA4R8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKaZsk6Q/khM/2dsb2JhbABEqXaBBYFyAQEBAwESASc2AgcQCxguVwY1h2CWHAGedIg9YgSUGJFm X-IronPort-AV: E=Sophos;i="4.69,450,1315180800"; d="scan'208";a="120719363" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2011 13:43:34 +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 pA3DhQhd019239; Thu, 3 Nov 2011 13:43:26 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <1B23FC2D-45E0-4FDC-BD2A-B8FF1AD1075E@niven-jenkins.co.uk> Date: Thu, 3 Nov 2011 14:43:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <92DF7C97-78FF-4B13-A9BC-26C8F060BE4E@cisco.com> References: <0AE82B0F-82E9-4D06-8960-B3EB0D61B63A@niven-jenkins.co.uk> <58F25507-696C-4B8F-9DA6-9B7315CE32AC@cisco.com> <1B23FC2D-45E0-4FDC-BD2A-B8FF1AD1075E@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: Thu, 03 Nov 2011 13:43:36 -0000 All these are fine by me. Thanks Francois On 31 Oct 2011, at 13:08, Ben Niven-Jenkins wrote: >=20 > On 28 Oct 2011, at 02:02, Francois Le Faucheur wrote: >=20 >> 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: >=20 > Done. >=20 >> * 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). >=20 > 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. >=20 > 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 >>=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 >=20 > Done. >=20 >> 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 >=20 > Done.=20 >=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. >> " >=20 > Done. >=20 >> 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 >=20 > Done throughout the document. >=20 >> 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). >=20 > Done but I tweaked the wording slightly, the final words I went with = are: >=20 > 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). >=20 > Ben >=20 From ben@niven-jenkins.co.uk Thu Nov 3 10:00: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 3FBCB11E809D for ; Thu, 3 Nov 2011 10:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.192 X-Spam-Level: X-Spam-Status: No, score=-103.192 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 gwtH-Asz4IVF for ; Thu, 3 Nov 2011 10:00:51 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4B64911E8083 for ; Thu, 3 Nov 2011 10:00:51 -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 1RM0em-0002PT-3y; Thu, 03 Nov 2011 17:00:48 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Thu, 3 Nov 2011 17:00:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <119EBF23-8A42-40ED-9388-41BD6261E872@niven-jenkins.co.uk> 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: Thu, 03 Nov 2011 17:00:52 -0000 Francois, >> If you still prefer s/For example/As an example/ I can pick that up = in the next revision? >=20 > That would be my vote. I've made this change in my working copy of -02 so it'll be reflected = the next time we publish an updated version. Ben On 3 Nov 2011, at 13:39, Francois Le Faucheur wrote: > Hi Ben, >=20 >>>=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/ >>=20 >> I've just rearranged the ordering slightly so the "however, no = standards..." comes after the example. >>=20 >> 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. >=20 > I had considered that option but I don't think that works either, = because the "However..." now seems to refer to the preceding sentence = (ie stuff out of scope) rather than the earlier sentences explaining = that CDN interconnection is needed.=20 >=20 >>=20 >> If you still prefer s/For example/As an example/ I can pick that up = in the next revision? >=20 > That would be my vote. >=20 > Thanks. >=20 > Francois >=20 >=20 >>=20 >>>> contract with an "authoritative" CDN for the delivery content >>>=20 >>> s/delivery content/delivery of content/ >>=20 >> Done. >>=20 >>>> 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/ >>=20 >> Done. >>=20 >>>=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 >>=20 >=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 flefauch@cisco.com Thu Nov 3 10:33:35 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 D948B1F0CAD for ; Thu, 3 Nov 2011 10:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.394 X-Spam-Level: X-Spam-Status: No, score=-7.394 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, 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 eiL6fYExpJwy for ; Thu, 3 Nov 2011 10:33: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 53E3E1F0C7C for ; Thu, 3 Nov 2011 10:33:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=26028; q=dns/txt; s=iport; t=1320341609; x=1321551209; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=lNMTTQerwyJyeI5ZVyKeHChcaPnMzenOce5otlJW5nk=; b=RBfJk4aDCr2hvW0Cgt8ZolPh9nKDDu4ETYyw8ERvxtS4r4MYyig8Rozs s/N7FCWQvat9uMKjt3+AVu2tBw3b1ERV5gAb/xit0/KqcwVl7OB4E5EvU Yw2z7FLa5xsVWp3LtZReVxn26Rhl3eyMmZm5RDNAzBqpdb4304oF3VXRt M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAACDQsk6Q/khL/2dsb2JhbABEmgWOW4EhgQWBcgEBAQMBAQEBDwEHLyUCAgcFBwICHAQBAQEnBxYRHwkIEAkaAQeHYAiWHgGeaAKIO2IElBiKPIcq X-IronPort-AV: E=Sophos;i="4.69,451,1315180800"; d="scan'208";a="59141559" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 03 Nov 2011 17:33:24 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA3HXL5Q002347; Thu, 3 Nov 2011 17:33:22 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Francois Le Faucheur In-Reply-To: <005301cc97eb$90e09d90$b2a1d8b0$@com> Date: Thu, 3 Nov 2011 18:33:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <94109E9C-A6B3-4952-94C9-B4CC2C127149@cisco.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><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> <005301cc97eb$90e09d90$b2a1d8b0$@com> To: draft-fmn-cdni-advanced-use-cases@tools.ietf.org X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: [CDNi] Advanced Use Cases 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, 03 Nov 2011 17:33:36 -0000 Authors of draft-fmn-cdni-advanced-use-cases, (as a WG co-chair) The abstract of the document states: " 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.=20 " Also, from looking at the I-D, it seems that some of these advanced use = cases are indeed beyond the current scope of the working group: * e.g. "The first use case introduces a Caching-CDN = interconnection that put emphasis on the in-the network caching = mechanism."=20 * e.g. Use case 2 for CDN-CDN interconnection at (very) large = scale i.e. "there do exist non-linearities which do not occur at small = to medium scale, but occur at large scale". "So this proposal aims at recommending that = this "cdn-cdn interconnections at large scale" use case be considered in = case of WG re-chartering (once the present goals will be reached). * e.g. Use Case 4: Dynamic expansion of CDN capacity and = geographical reach : "The newly created resources are provided by the = network provider but under the control of the CDN provider." * e.g. "Relationship between CDNI and Information-Centric = Networking" =09 Based on this, would it be an acceptable approach for you guys to: * keep progressing this document as a standalone document = investigating uses cases beyond current scope, and * only potentially feed into ietf-cdni-usecases (and possibly = ietf-cdni-requirements) the very specific subset of your document that = relates to the current scope of the WG? Cheers Francois On 31 Oct 2011, at 17:38, Theodore Zahariadis wrote: > Dear Alan, >=20 > 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. >=20 > 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=92ll 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. >=20 > Best Regards, > Theodore >=20 >=20 >=20 >=20 > From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 > 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 >=20 > Hi Theodore >=20 > 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). >=20 > Alan >=20 > From: Theodore Zahariadis [mailto:zahariad@synelixis.com]=20 > 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 >=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 > Alan >=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 >=20 > 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, >=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 > 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 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Thu Nov 3 10:56: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 015971F0C4F for ; Thu, 3 Nov 2011 10:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.683 X-Spam-Level: X-Spam-Status: No, score=-7.683 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_75=0.6, 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 WqpKvgxhQB9Q for ; Thu, 3 Nov 2011 10:56:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5931F0C40 for ; Thu, 3 Nov 2011 10:56:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=33943; q=dns/txt; s=iport; t=1320343001; x=1321552601; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=iAB9res8OeBy3ZF+obWhomSG+HYa44XBykSJuAeNAYc=; b=UHqpOhI6eqbVpYy2rJzYP+rNHdaQQyRRd1jYTFDvD8rlg7bV6NgLJUd1 FZjy2/nbbhWeBtf2wRWMPP21WQW1aQdHNG5OvUcPnZlzADqycNIK5aiQj Rax/nhft0cA6gh023+3AwO0lETsM8VRYMUx4y+fudMUAdn+TZVMnmdoJs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuQAAHDVsk6Q/khL/2dsb2JhbABEmgaOW4EhgQWBcgEBAQMBAQEBDwEHAS4lBAELBwICCxEBAwEBAScHFhEfAwYIEAkUBQEBB4dgCJYVAY41kDQCiDtiBJQYijyHKg X-IronPort-AV: E=Sophos;i="4.69,451,1315180800"; d="scan'208";a="120743794" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 03 Nov 2011 17:56:39 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA3HubI1006908 for ; Thu, 3 Nov 2011 17:56:38 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Francois Le Faucheur In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6217F6D1F9@SZXEML519-MBX.china.huawei.com> Date: Thu, 3 Nov 2011 18:56:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3F1DB47B-5614-4FE4-BF02-D091F84ACDBE@cisco.com> 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> To: cdni@ietf.org X-Mailer: Apple Mail (2.1084) 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, 03 Nov 2011 17:56:45 -0000 Folks, (as a WG co-chair) It is great that the CDNI topic has attracted new faces (or "voices" I = should say until we get together in Taipei) that we have not heard/seen = around the IETF before. To ensure we operate as effectively as possible, = I would like to encourage those that are not so familiar with the IETF = to take the time to familiarize themselves with the IETF process, in = particular by checking out the "The Tao of IETF: A Novice's Guide to the = Internet Engineering Task Force" = (https://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/). In particular, it is good to keep in mind the following statement: "Participation in the IETF or of its WGs is not fee-based or = organizationally defined, but is based upon self-identification and = active participation by individuals." So that discussions in IETF is expected to be based on technical = arguments made by individuals and not based on company affiliation, = positions or strategies. Cheers Francois On 31 Oct 2011, at 10:04, ZhouZhipeng wrote: > Sorry, not KPN. It is Ray from TNO. > Zhipeng > =20 > =20 > From: ZhouZhipeng=20 > Sent: Monday, October 31, 2011 4:49 PM > To: 'Francois Le Faucheur' > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Dear Francois, and all, > Thanks for all the group=92s attention on this topic. > I am also happy that my proposal has gotten so much valuable = response/questions/ comments. > That will be very helpful for all of us to catch a complete = understanding and solution for this market demand. > While I feel till now the topic itself has not been completely = analyzed and I am busy doing the work. I will expose my contribution = soon after I complete that work. > Meanwhile I hope the group may allow some more time for people to = consider it. Perhaps some more people will emerge in the group mail = list. > Currently, some people has claimed their preference. I feel perhaps = not a few people have supported this use case(the authors of = draft-fmn-cdni-advanced-use-cases-00, Alan from Ericsson, ChinaMobile, = Chinatelecom, perhaps also KPN, and me). > =20 > I have explained that for CDN-A and CDN-B, they may negotiate whether = to support the CDNI adaptation solution. Hence such optional arrangement = will only bring benefit when both upstream and downstream agrees that at = their appropriate situation. > =20 > So, I sincerely suggest two Chairs and the whole group may allow some = more days for this topic. I suggest after the Taipei meeting . > By then we all will get a clearer understanding and decision. > =20 > Thanks. > Zhipeng > =20 > =20 > =20 > From: Francois Le Faucheur [mailto:flefauch@cisco.com]=20 > Sent: Friday, October 28, 2011 9:50 PM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > =20 > Hi again Zhipeng, > =20 > 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. > =20 > 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. > =20 > Cheers > =20 > Francois > =20 > =20 > On 28 Oct 2011, at 11:25, ZhouZhipeng wrote: > =20 >=20 > 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 > =20 From flefauch@cisco.com Thu Nov 3 11:36: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 B709811E8107 for ; Thu, 3 Nov 2011 11:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=-1.668, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, 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 QGAual5eI6cs for ; Thu, 3 Nov 2011 11:36:37 -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 93CD911E80DA for ; Thu, 3 Nov 2011 11:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=43876; q=dns/txt; s=iport; t=1320345395; x=1321554995; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=9/+NfLX4fT7CEqsCZP/iB36usAT73jLP3pBSflYI75E=; b=JWoVSyEKyfCRN69NewuhCXJJleGoDpwWj2dN3/r92/3MiiROjmXOCqZH DPmZPYIhxfRd5LvfGXbg46eFluYEevgvUKVA5vE93Q4WcCb/o65U5Hi6a JzUHhpaGBoJhQ99DLck71uQAUkePuODJcsjERGUSNzCdIxx6Hz13Hggod o=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,451,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147";a="2366242" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-4.cisco.com with ESMTP; 03 Nov 2011 18:36:34 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA3IaTE8000365; Thu, 3 Nov 2011 18:36:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/mixed; boundary=Apple-Mail-298-588282015 From: Francois Le Faucheur In-Reply-To: <4EB04CCD.7070707@cisco.com> Date: Thu, 3 Nov 2011 19:36:21 +0100 Message-Id: References: <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <4EB04CCD.7070707@cisco.com> To: Scott Wainner X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org 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: Thu, 03 Nov 2011 18:36:39 -0000 --Apple-Mail-298-588282015 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 All, As mentioned earlier: 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. Scott and all, This option was also brought up during the last IETF. It seems a = reasonable trade-off as it would represent very little work for the WG = (i.e. one extra binary metadata information to convey along the rest of = the metadata) and allows dCDN to do local content adaptation when given = free-reins by the uCDN (presumably in line with the CSP policies) and = allows uCDN to prevent content adaptation when incompatible with CSP = policy. When polling the WG in Taipei, we could include that option in the poll = (in addition to the option of not dealing with content adaptation at = all, and the option of trying to fully enable content adaptation). Francois On 1 Nov 2011, at 20:47, Scott Wainner wrote: > Perhaps the answer to this dilemma is very simple ... >=20 > In the CDNI interface, we simply offer a binary option of the = following: >=20 > 0) content may not be adapted > 1) content may be adapted >=20 > I suspect that the majority of the CDNI relationships will set the = flag to "0" indicating the asset is not allowed to be adapted. The = reason can be anything including contractual between the CP and uCDN, = the content is encrypted, the uCDN preference, etc. >=20 > Now if the flag is set to "1", it is incumbent upon the dCDN to figure = out how to modify the content without changing the URL references, etc. >=20 > Scott >=20 > On 10/27/11 7:22 AM, Woundy, Richard wrote: >> >In your company=C3=A2=E2=82=AC=E2=84=A2s 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=C3=A2=E2=82=AC=E2=84=A2s website, I just find some = information that addresses =C3=A2=E2=82=AC=C5=93 Vodafone subscribers = complained about video performance.=C3=A2=E2=82=AC=C2=9D >> 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=C3=A2=E2=82=AC=E2=84=A2d 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 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-298-588282015 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-298-588282015 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-298-588282015 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-298-588282015 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-298-588282015-- From alan.kavanagh@ericsson.com Thu Nov 3 12:28: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 E653E1F0CAF for ; Thu, 3 Nov 2011 12:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.048 X-Spam-Level: X-Spam-Status: No, score=-6.048 tagged_above=-999 required=5 tests=[AWL=0.550, 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 j95PR2Ah-BA6 for ; Thu, 3 Nov 2011 12:28:03 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id D8FC41F0CAB for ; Thu, 3 Nov 2011 12:28:02 -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 pA3JS0pK018560; Thu, 3 Nov 2011 14:28:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Thu, 3 Nov 2011 15:28:01 -0400 From: Alan Kavanagh To: Francois Le Faucheur , "cdni@ietf.org" Date: Thu, 3 Nov 2011 15:28:00 -0400 Thread-Topic: [CDNi] Content Adaptation Thread-Index: AcyVVvzqtUVaLaabQgGf0eu7xLKPrQFBf2kA Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9D4F@EUSAACMS0701.eamcs.ericsson.se> 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: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_1B6D0317D3AD964FBF3956DEFA3524D51710BD9D4FEUSAACMS0701e_" 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: Thu, 03 Nov 2011 19:28:04 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D51710BD9D4FEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois Thanks for putting some light on this, most appreciated. I fully agree that Content Adaptation is definitely an optimization in term= s of delivery from the CSP/origin Server to the CDN Provider itself, send 1= copy and not 10 etc saves on bandwidth which implies you need smaller pipe= s and don't have to worry about the transcoding etc, makes perfect sense. H= owever i do believe its important for CDN_I to include this and ill explain= why. A lot of CSP's don't do content adaptation as they either don't have = the expertise or don't want to manage that side of the content they produce= , they only want to have it distributed to a wide variety of devices etc an= d they give that job of Content Adaptation to the CDN Provider to take care= of as part of their business agreement between the Content Provider and Di= stributor and this model is growing quite a lot as im sure all CDN vendors = alike here would agree with and don't see that diminishing. Similarly as new codec's and end devices with different screen density's co= me to the market i believe the CDN is better equipped to handle this than t= he CSP. The CDN does the Content Adaptation for lots of CSP's it has servic= e agreements with so they typically do this as opposed to have lots of CSP'= s do this themselves, its not just transport savings but also CAPEX/OPEX an= d expertise the CSP may not have. The savings here is for the CSP not the e= nd user as i note you have below and agree, but the cost burden here is the= CSP in the first place and same also between CDSP's.....transport/bandwidt= h is never free and when optimization which translates into cost savings ca= n be achieve its imperative it is used. I think Richard had a good proposal which was to bring some presentations t= o Taipei or next meeting as time is short to the group and take it from tha= t on how to proceed. Ill try and work with others to provide input on some = use cases describing this as i feel it will help the discussion and help it= conclude i hope :-) Alan ________________________________ From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: October-28-11 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_1B6D0317D3AD964FBF3956DEFA3524D51710BD9D4FEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois
 
Thanks for putting some light on this, most=20 appreciated.
 
I=20 fully agree that Content Adaptation is definitely an optimization in terms = of=20 delivery from the CSP/origin Server to the CDN Provider itself, send 1 copy= and=20 not 10 etc saves on bandwidth which implies you need smaller pipes and don'= t=20 have to worry about the transcoding etc, makes perfect sense. However i do= =20 believe its important for CDN_I to include this and ill explain why. A lot = of=20 CSP's don't do content adaptation as they either don't have the expertise o= r=20 don't want to manage that side of the content they produce, they only want = to=20 have it distributed to a wide variety of devices etc and they give that job= of=20 Content Adaptation to the CDN Provider to take care of as part of their bus= iness=20 agreement between the Content Provider and Distributor and this model is gr= owing=20 quite a lot as im sure all CDN vendors alike here would agree with and don'= t see=20 that diminishing.
 
Similarly as new codec's and end devices with different screen den= sity's=20 come to the market i believe the CDN is better equipped to handle this than= the=20 CSP. The CDN does the Content Adaptation for lots of CSP's it has service=20 agreements with so they typically do this as opposed to have lots of CSP's = do=20 this themselves, its not just transport savings but also CAPEX/OPEX and=20 expertise the CSP may not have. The savings here is for the CSP not the end= user=20 as i note you have below and agree, but the cost burden here is the CSP in = the=20 first place and same also between CDSP's.....transport/bandwidth is never f= ree=20 and when optimization which translates into cost savings can be achieve its= =20 imperative it is used.
 
I=20 think Richard had a good proposal which was to bring some presentations to= =20 Taipei or next meeting as time is short to the group and take it from = that=20 on how to proceed. Ill try and work with others to provide input on some us= e=20 cases describing this as i feel it will help the discussion and help it con= clude=20 i hope :-)
 
Alan

From: cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le=20 Faucheur
Sent: October-28-11 5:49 AM
To:=20 cdni@ietf.org
Subject: [CDNi] Content Adaptation

Folks,

Speaking as a co-chair.

I have been through= the=20 recent exchange on content adaptation (aka the poorly-titled "Re: [CDNi] I-= D=20 Action: draft-ietf-cdni-use-cases-00.txt" thread) and wanted to share a few= =20 thoughts.

First, some messages might have given the impression that= =20 content adaptation was required for a CDNI solution to be able to deal with= =20 multiple types of terminal/resolution/sizes etc. So at the risk of restatin= g the=20 obvious, let's be very explicit that this is obviously not the case. A very= =20 simple/common way to support multiple types of terminal/resolution/sizes in= one=20 CDN, or in a multi-CDN environment, is to have different contents/URIs for = each=20 profile.
So content adaptation is not _required_ to be supported by CDNI= , but=20 is a candidate optimisation to do some of the same things in a different=20 way.

Second, some messages suggested that content adaptation was a v= ery=20 strong win (aka transfer 1 flow instead of 10 flows across CDNs). As Richar= d=20 pointed out already, this ignores a number of considerations such as the co= st=20 associated with performing the actual content adaptation downstream. Anyway= s, I=20 think content adaptation may be better seen as a trade-off that can indeed = be=20 positive in some environments, rather than an obvious huge win.
Also, without the content adaptation optimization, while the content m= aybe=20 passed across CDNs multiple times (in different formats), it is worth notin= g=20 that the smaller res/size/quality representations may actually amount to mu= ch=20 smaller size/bandwidth than the highest res/size/quality, so it is not quit= e a=20 multiplying factor. 
Lastly, while the content adaptation optimizat= ion=20 may reduce further the inter-CDN transfer from 1-10 flows down to  1 f= low,=20 the base CDNI solution allows a content to be transferred across CDNS 1-10 = times=20 total instead of once per user accessing the content (as would be the case = if=20 the uCDN pumps the same traffic to every users because it cannot interopera= te=20 with the dCDN) which can result in a gain factor of 10s, 100s,=20 1000s,.....

I have the impression that the key arguments have now been exposed= =20 (some of them even repeatedly) through the long thread. So I would suggest = to=20 pause that discussion, unless _new_ arguments need to be brought into the=20 discussion, and then we can poll for consensus in Taipei and then on the=20 list.

Thanks

Francois

PS: Please think of using specif= ic=20 Subject lines for the various threads and don't hesitate to branch off with= a=20 different "Subject" when an initial thread morphs into a different topic. T= his=20 helps the discussion.

--_000_1B6D0317D3AD964FBF3956DEFA3524D51710BD9D4FEUSAACMS0701e_-- From alan.kavanagh@ericsson.com Thu Nov 3 12:44: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 B73EE1F0CAB for ; Thu, 3 Nov 2011 12:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.227 X-Spam-Level: X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[AWL=-0.429, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=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 OKW7pf6-G7qS for ; Thu, 3 Nov 2011 12:44:46 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3C83D1F0CC1 for ; Thu, 3 Nov 2011 12:44:46 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pA3JgDQ6019371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Nov 2011 14:42:39 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Thu, 3 Nov 2011 15:42:26 -0400 From: Alan Kavanagh To: Francois Le Faucheur , ZhouZhipeng Date: Thu, 3 Nov 2011 15:42:24 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Thread-Index: AcyVeISzo45qaejHRZegWYxfp5P+qwE5nv+Q Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9D74@EUSAACMS0701.eamcs.ericsson.se> References: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> <817779F3-8F95-42BA-9DA3-34EF81DFDB71@cisco.com> In-Reply-To: <817779F3-8F95-42BA-9DA3-34EF81DFDB71@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_1B6D0317D3AD964FBF3956DEFA3524D51710BD9D74EUSAACMS0701e_" 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, 03 Nov 2011 19:44:59 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D51710BD9D74EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois I dont believe its a lot of work, we are talking about a couple of addition= al Metadata objects which i feel is very trivial to have added, right? Alan ________________________________ From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: October-28-11 9:46 AM To: ZhouZhipeng Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt 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 cou= ld conceive an approach for content adaptation that suits him. The question= here is rather whether it is justified for the Working Group to focus ener= gy 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 sol= ution in place. You have made it clear that you feel the WG should indeed dedicate energy o= n that problem right away and explained your rationale. Thank you. Others h= ave 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= 's request, I like to show my information although perhaps not complete rig= ht now. 1) I have done some work to collect different company's requirements an= d opinions on this functionality. One, I feel most of us have already been aware of the service of content ad= aptation, and I also sent an email yesterday that Vodaphone now is requirin= g the solution to enhance the performance of its mobile video service. Second, here is an article about CISCO : "Cisco urges mobile operators to a= dd value to CDN services" http://www.totaltele.com/view.aspx?ID=3D468705 Besides, I have checked many CDN company's websites. Many claim to support = transcoding while some may not. 2) For the wording "content adaptation", it should be clarified here th= at it may be two kinds. One is only the transformation of encapsulation format. For example the H.2= 64 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 t= he TS stream and then encapsulated them into different formats(APPLE,Adobe.= ..) to different devices. For this kind of transformation, the computing cost is very very low and ma= y be nearly neglected. The other is to transcoding. For example to support different bitrates. S= ince encoder is a high value facility, we should compare the capital cost o= f 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. >From whole system point of view, either A or B would transcode while the ba= ndwidth 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 inst= all 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 t= o put the transcoder at the receiver Node B. In fact I have investigated this issue for much time. While in different ar= ea the price of bandwidth may be different. And the transport burden betwe= en 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 bandwidt= h quality for business would be guaranteed). I query that the bandwidth pri= ce in China may be 50% higher. I do not know how much the price will be for the bandwidth from Amsterdam t= o Paris (cross country in the same continent). But I feel the price from N= ewYork 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 re= nting multiple times broadband. Some people have told me that for the operator himself probably the bandwid= th cost would be very low in the internal capital counting. But for the ind= ependent 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 adaptatio= n. 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 co= mplete 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 com= plete 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. 3) As for the procedure of content adaptation, I just draft a diagram a= s below: You may see the solution is rather clear and the metadata needed would be c= lear also. Dear, By my analysis above, I kindly invite your ideas whether it may be an appli= cable 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 functio= nality it would be very good while it does not impact others that do not im= plement it. Thanks. Zhipeng From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] Sent: Thursday, October 27, 2011 7:23 PM To: ZhouZhipeng; 'mark@jet-stream.nl'; 'alan.ka= vanagh@ericsson.com' Cc: 'cdni@ietf.org'; Woundy, Richard Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >In your company's 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 co= ntent 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 >; Alan Kava= nagh > Cc: 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's website, I just find some information that addresses " Vo= dafone subscribers complained about video performance." See: http://www.jet-stream.nl/search/?search=3Dtranscoding 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 is= sue. 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 explaine= d 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 meet= ing 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 t= he transcoding and deliver the content of multiple formats and rates to dCD= N. 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 o= perator 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 pr= oviders, it may be better to support all kinds of service. Besides, I like say that the technology on this topic has been for many yea= rs and has been rather mature, even some items in ietf such as rfc3507 ica= p. So from the technique point of view, it is a nature action to be involve= d 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 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 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_1B6D0317D3AD964FBF3956DEFA3524D51710BD9D74EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <= BASE=20 href=3Dx-msg://454/>
Hi Francois
 
I=20 dont believe its a lot of work, we are talking about a couple of additional= =20 Metadata objects which i feel is very trivial to have added,=20 right?
 
Alan

From: cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le=20 Faucheur
Sent: October-28-11 9:46 AM
To:=20 ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: [CDNi] I-D=20 Action: draft-ietf-cdni-use-cases-00.txt

Hi again Zhipeng,

There is one other point I should have brought up in my previous=20 message:
The question is not so much whether there are benefits to allowing con= tent=20 adaptation for some environments, nor whether one particular individual cou= ld=20 conceive an approach for content adaptation that suits him. The question he= re is=20 rather whether it is justified for the Working Group to focus energy on tha= t=20 problem right now in order to develop a consensus-based approach that suits= the=20 community as a whole, while we don't even have the base solution in place.<= /DIV>

You have made it clear that you feel the WG should indeed dedicate ene= rgy=20 on that problem right away and explained your rationale. Thank you. Others = have=20 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 to= pic. As=20 Richard’s request, I like to show my information although perhaps n= ot complete=20 right now.
1)     I have done some work to collect different company’s r= equirements=20 and opinions on this functionality.
One, I feel most of us have already been aware of the servic= e of=20 content adaptation, and I also sent an email yesterday that Vodaphone now= is=20 requiring the solution to enhance the performance of its mobile video=20 service.
Second, here is an article about CISCO : “Cisco urges = mobile=20 operators to add value to CDN services” http://www.totalt= ele.com/view.aspx?ID=3D468705
Besides, I have checked many CDN company’s websites. M= any claim to=20 support transcoding while some may not.
2)     For the wording “content adaptation”, it should = be clarified here=20 that it may be two kinds. One is only the transformation of encapsulation format. For = example=20 the H.264 stream is encapsulated in APPLE and Adobe format=20 respectively. I know that Comcast has a project that needs to pick the H.2= 64=20 media from the TS stream and then encapsulated them into different=20 formats(APPLE,Adobe…) to different devices. For this kind of transformation, the computing cost is very = very=20 low and may be nearly neglected. The other is to transcoding.  For example to support di= fferent=20 bitrates.  Since encoder is a high value facility, we should compare= the=20 capital cost of encoder and transport cost. Just take a simple model: content is delivered from Node A t= o Node=20 B. <image002.png> There are two solutions: 1)     A have the transcoder and deliver multi-format content to=20 B 2)     B have the transcoder; A only delivers one format content to= B and=20 B would transcode. From whole system point of view, either A or B would transco= de=20 while the bandwidth would be saved in solution B. Hence solution B is=20 better. Now provided the bandwidth is paid by B and B should decide = whether=20 to install transcoder. (Richard has said to set transcoder in each edge=20 server) If the cost of renting bandwidth (for a few months) is more= =20 expensive than the price of transcoder supporting the same bandwidth, it = would=20 be better to put the transcoder at the receiver Node=20 B. In fact I have investigated this issue for much time. While = in=20 different area the price of bandwidth may be different.  And the=20 transport burden between two distant places or over a bad nature environm= ent=20 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 fe= el the=20 bandwidth quality for business would be guaranteed). I query that the=20 bandwidth price in China may be 50% higher. I do not know how much the price will be for the bandwidth f= rom=20 Amsterdam to Paris (cross country in the same continent).  But I fee= l the=20 price from NewYork to Paris would absolutely be very high.  As for t= he=20 Encoder, it also varies. Perhaps the price in China will be higher than i= n=20 USA. And in fact the price of bandwidth and encoder depends mostly on the= =20 concrete business items. For example the price to Huawei may be lower tha= n the=20 public price. By my current evaluation in China it is better using the tra= nscoder=20 than renting multiple times broadband. Some people have told me that for the operator himself proba= bly the=20 bandwidth cost would be very low in the internal capital counting. But fo= r the=20 independent CDN, it may another thing. So, my suggestion is to let different ways co-exist. I have= =20 announced that to let two sides negotiate whether to assign dCDN for the= =20 content adaptation. In fact, from CP to CDN,  there are the real businesses= that=20 either let CP to provide multi-format content or let the CDN to receive o= ne=20 format and complete the transformation, depending on the concrete=20 business. By the same logic, form uCDN to dCDN, it may be either the u= CDN to=20 provide multi-format content or the dCDN to receive one format content an= d=20 then complete the transformation. Currently there is not the real CDN-CDN connection, hence we= are=20 basing our knowledge on the related solution to make our=20 solutions. 3)     As for the procedure of content adaptation, I just draft a d= iagram=20 as below: <image004.png> You may see the solution is rather clear and the metadata ne= eded=20 would be clear also. Dear, By my analysis above, I kindly invite your ideas whether it = may be=20 an applicable and simple part in the CDNI item, provided that the solutio= n is=20 open to the types of content adaptation and may be optionally implemented= in=20 the real solutions/business. I feel for those operators that need such=20 functionality it would be very good while it does not impact others that = do=20 not implement it. Thanks. Zhipeng
From:<= SPAN=20 class=3DApple-converted-space> Woundy, Richard=20 [mailto:Richard_Woundy@cable.comcast.com] 
Sent: Thursday, October 27, 2011 7:2= 3=20 PM
To: ZhouZhipeng; 'mark@jet-stream.nl'; 'alan.kavanagh@ericsson.com'
Cc: 'cdni@ietf.org'; Woundy,=20 Richard
Subject: Re:=20 [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt
>In=20 your company’s website, I just find some information

I have = to step in=20 as co-chair here.

The goal of this WG is not to align vendor produ= ct=20 roadmaps, or to equalize all vendor offerings, or to specify the entire C= DNI=20 ecosystem. The goal of this WG is to enable the interconnection and=20 interoperation of two or more CDNs, within the bounds of the CDNI wg=20 charter.

It is OK to have a discussion about whether content adapt= ation=20 needs to be performed by the dCDN, since that decision impacts the uCDN-d= CDN=20 interface. So let's find a productive way to discuss this on the mailing = list,=20 and to close the discussion by IETF 82 (if not sooner).

Can someon= e=20 describe real-life examples where downstream CDN (or edge cache-based) co= ntent=20 adaptation is needed today in a production environment, or shortly? Not m= erely=20 a feature in a vendor's product materials?

Speaking as an individu= al, I=20 can find a lot of examples where downstream content adaptation is not nee= ded,=20 and any adaptation is really part of the CP - uCDN interface (which is ou= t of=20 the scope of our charter).

-- Rich

  From:= =20 ZhouZhipeng [mailto:zhouzhipeng@huawei.com] 
Sent: Thursday, Oct= ober=20 27, 2011 03:45 AM
To: Mark de Jong <mark@jet-stream.nl>; Alan Kavan= agh=20 <alan.kavanagh@ericsson.com= > 
Cc: cdni@ietf.org <cdni@ietf.org> 
Subject: Re: [CDNi]= I-D=20 Action: draft-ietf-cdni-use-cases-00.txt 
  Hello=20 Mark, Nice=20 to meet you on line. In=20 your company’s website, I just find some information that addresses= “ Vodafone=20 subscribers complained about video performance.” See: http://www= .jet-stream.nl/search/?search=3Dtranscoding Dear=20 all in this group, In=20 last few days, except the public email discussions I have contacted with = some=20 people and discussed with my own colleagues of all details on this=20 issue. First,=20 although the market requirement for it is very important, I feel I’= d better=20 show up more information on the procedure involved. I have explained many= =20 times that to support content adaptation is rather simple while the wordi= ng is=20 not enough. I=20 am busy making some contributions on this and plan to upload to ETSI meet= ing=20 and IETF CDNI. By=20 these work  I feel the people may catch a whole view on this=20 issue. Second,=20 for that functionality, in implementation, if some entity does not choose= to=20 support it, it may be ok. Since it may be negotiated between  two CDNs. If=20 dCDN does not support that, it may be the uCDN responsible to complete th= e=20 transcoding and deliver the content of multiple formats and rates to=20 dCDN. Third,=20 although CDNI is a new architecture, while the content operating has been= =20 existed for years. As I know the content from USA to the downstream opera= tor=20 is transferred on one copy and the downstream operator will handle the=20 transcoding. Perhaps,=20 the content adaptation is more on the mobile operating. But I feel curren= tly=20 most operator will be a all service operator. And for the CDN providers, = it=20 may be better to support all kinds of service. Besides,=20 I like say that the technology on this topic has been for many years and = has=20 been rather mature, even some items in ietf such as rfc3507  icap. So from the technique p= oint of=20 view, it is a nature action to be involved in CDN=20 interconnection. Thanks. Zhipeng
From:<= SPAN=20 class=3DApple-converted-space> Mark de Jong=20 [mailto:mark@jet-stream.nl] 
Sent: Thursday, October 27, 2011 4:2= 1=20 AM
To: Alan=20 Kavanagh
Cc: Be= n=20 Niven-Jenkins; ZhouZhipeng; cdni@ietf.org
Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt
Hi Alan,
As Ben stated the overall discussion right now is about deli= very,=20 not on adaptation. It is hard enough to get consensus on the delivery asp= ect=20 already not to mention your requirement from content adaptation added to = that,=20 so I agree with Ben we should stick with the delivery aspect for the firs= t=20 specs. I can imagine this could be a discussion later on but please = let=20 us keep the scope of this be clean and transparent. It is of benefit of=20 everyone to get the first specs as fast as possible.=20 Thanks.
mark@jet-stream.com
Office: +31 (0)50 5261820
Mobile: +31 (0)6 81108263
Fax: +31 (0)50 5264214
www.jet-stream.com
http://www.jet-stream.com to download our 'Six Trends in= CDNs'=20 brochure
www.jet-stream.com/blog/
www.vdo-x.net
www.streamzillacdn.com<= /SPAN>
www.jet-stream.com
On 26, Oct,2011, at 8:33 PM, Alan Kavanagh=20 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 [mailto:cdni-bounces@ietf.org]= On=20 Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To:=20 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. After = that=20 the user only desires to get his selected=20 content.
But how the content is transferred to the client is not wo= rried=20 by the user.
The CP may create a special format as required by the user= and=20 ask the CDN to deliver to user.
While CP may give a HD format content to uCDN and the dCDN= may=20 then transform to the format as the user=20 select.


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

Content transformation/adaptation is not an essent= ial=20 requirement in order to achieve that aim (we can deliver content from CSP= s 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 alrea= dy=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=20 the CDNI charter.

In this case, it is nothing related to how the user select f= ormats=20 on CP website.
So, it is the CP and user to decide the content format not= the=20 CDN(your assert is not correct and seems you take that assert as your b= ase=20 for the discussion).
As for "the core CDN functionality offered by CDNs today",= I have=20 ever raised an email before that your company's webpage has claimed=20 supporting media transformation and multi-screen=20 service.
Perhaps, I like asking you list some features that you fee= l are=20 the core functionalities by existing main stream CDNs. Thus we may comp= are=20 and take deep look.


I think the core functionality maps pretty well to the C= DNI=20 interfaces, namely: Request Routing, Metadata configuration, log producti= on=20 and control plus content acquisition and content=20 delivery.

I guess many people have the experience/knowledge of content= =20 related service. The user and CP only care whether the CDN providers may= =20 satisfy their requirement while not care the internal process. Just as=20 GSM/PSTN interconnection, the user only care successful interconnection w= hile=20 not care how the voice is transformed in process.
Besides, I like raise a case:
Given currently BBC recruits CDN providers that may suppor= t 10=20 media formats.
One candidate is your company, another is CDN-X. The users= are=20 located in France.
So both your company and CDN-X should connect a France CDN= =20 provider(CDN-Y).
If your company's solution is to send 10 streams of differ= ent=20 format
of one content to CDN-Y; While CDN-X's solution is to send= 1=20 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=20 lower.
For CDN-Y, in solution-1, it should receive/forward 10 str= eams ;=20 while in solution-2, it should only receive 1 stream but need to take=20 transformation to output 10 streams.
Which solution is more competitive. it is Solution 1, righ= t.=20 Remember the price from BBC is same to both your company and CDN-X or B= BC=20 would select one CDN provider with the lower=20 price.
If a CDN provider may not get the contract from CP, how it= may=20 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= =20 enable content delivery between interconnected CDNs. I can think of many= =20 optimizations that a CDN could implement to differentiate their service b= ut=20 the internal workings of an individual CDN are out of scope of our=20 charter.

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

Ben

So, if we all realize that currently the media type is rich,= the=20 CDN providers should survive in the existing ecosystem and support the me= dia=20 types as required by the market.
Back to the case of GSM/G.711, it just when concerning the= =20 interconnection, the transformation should at once be solved. Otherwise= the=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 is abso= lutely=20 correct that the delivery capability is the core requirement for CDN= =20 system.
While CDN is used to provide the content delivery=20 service.
What means service. It should include "time" "location" = and=20 "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= sure=20 whether the issues such as "logging" "geographic constraint" are the = core=20 of CDN.
For "without explicit knowledge of what that content act= ually=20 is ", I am not sure whether the wording is accurate since generally a= CDN=20 may claim it support different=20 medias.
By this opportunity, I like to share a use case: a call = from a=20 GSM phone to a PSTN telephone, the voice stream should be transformed= from=20 GSM voice to G.711.
For the user, he does not need to know what type of data= has=20 been transferred, but the operator has done some work to interconnect= two=20 systems, right.
I like to know whether you may accept that my use case i= s=20 similar to this case above.
I don't think your use case is similar to the analogy of m= obile=20 networks being interconnected to PSTN networks. In the case of content= =20 delivery the negotiation is done between the User/Client and the Conten= t=20 Provider and the CDN is just used to execute/perform the delivery that = has=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/Clien= t or=20 in what representations the User/Client decides to=20 request.
As for you said selecting media by the "portal", you may= see=20 the way " uCDN delivers multiple media streams to dCDN" is not good t= han=20 "uCDN delivers one media stream to dCDN and dCDN takes some adaptatio= n to=20 support multiple media=20 types".
Now what you're talking about is an optimisation, not a co= re=20 function required to actually deliver the content (and report, bill, et= c.=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 (wh= ich=20 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 done six year= s on=20 the DRM
and like to promote the DRM all around the world:) If th= e=20 content is needed to be protected, generally you may know all the sys= tems=20 should be granted by the content=20 owner.
Here I also like to clarify that not only the media itse= lf but=20 the information related to service itself (such as the geographic=20 constraint) should be protected=20 also.
So, trust is not a problem for the=20 media.
Philip,
Thank you that you feel Content Adaption is an issue 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 you oper= ator=20 since it may save investment if the system may support different=20 services.
For us vendor, we are happy operator may install a syste= m for=20 the mobile service and another system for the FBB=20 service.
But the reality is all operators ask us to provide a sys= tem=20 that may support different service=20 systems.
Frankly, Ben and Philip, I remember I have explained som= ewhere=20 that to implement this is rather simple=20 .
At least the Use case and Requirement are informational = to be=20 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 [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 an issue for the= =20 Requirements doc than for the Use cases=20 draft.
The key question is whether we want the CDNI interfaces = to be=20 able to cope with a scenario where (say) HD/SD conversion is done in = the=20 dCDN & to signal about=20 this.
I think that coping with this scenario is a second order= =20 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 be valid eve= n if=20 content adaptation (HD/SD) is out of=20 scope.
- a dCDN might for some reason be unwilling to distribut= e=20 HD?
- a CSP might want to make sure the dCDN can use HLS=20 encapsulation?
But these sorts of examples seem to be static policy thi= ngs (to=20 do
with the capabilities & preferences of the CDNs &= ; CSP),=20 rather than
metadata associated with a particular piece of content. = In=20 the
discussion so far, I think negotiation about static poli= cy=20 stuff is
rather out of=20 scope(?)
On security considerations, an interesting question is w= hether=20 trust is transitive. Don't think it need be - just because CSP trusts= =20 uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically tr= usts=20 the dCDN. However, i suspect this can get arbitrarily complex - so on= e=20 possibility is to say that we will only handle cases where the trust = is=20 transitive.
Best wishes
phil
Philip Eardley
Research and Technology=20 Strategy
This email contains BT information, which may be privile= ged or=20 confidential. It's meant only for the individual(s) or entity named a= bove.=20 If you're not the intended recipient, note that disclosing, copying,= =20 distributing or using this information is prohibited. If you've recei= ved=20 this email in error, please let me know immediately on the email addr= ess=20 above. Thank you. We monitor our email system, and may record your=20 emails.
British Telecommunications=20 plc
Registered office: 81 Newgate Street London EC1A 7AJ Reg= istered=20 in
England no:=20 1800000
-----Original=20 Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.= org] On=20 Behalf
Of Ben=20 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 Cases d= raft.=20 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 reques= ted=20 without explicit knowledge of what that content actually=20 is.
Let's not forget that in building an end to end content = service=20 the CDN is only one component and is the component tasked with execut= ing=20 the delivery of a specific representation (version/copy/format etc.) = of=20 the selected content not the component tasked with deciding (or apply= ing=20 policy) on which version/copy/representation of content should be=20 delivered.
The decision as to which version/copy/representation to = offer=20 and allow to be delivered to a given device/user is implemented outsi= de of=20 the CDN (e.g. by the "portal" where the user first makes their conten= t=20 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 feel Sc= ott's=20 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 hav= e two=20 content with different identifier. In DRM scope, the basic unit is = a=20 content copy.
Here the first bullet "a subset of encodings deliverab= le to=20 specific devices," has listed the case of content=20 adaptation.
In last month, I have contacted the Authors of this do= cument=20 and taken some email exchanges with Grant and Philip=20 (BT).
I have shown BT with some information that I know in t= his=20 case and area to explain the content flexibility is currently a bas= ic=20 requirement for CDN service and related negotiation is needed in th= e CDN=20 interconnection.
<= /BLOCKQUOTE>
Meanwhile, I should also invite you in this group rais= ing=20 your comments or questions on this case since I hope my use case ma= y be=20 incorporated in the use case=20 draft.
If you have any more question or comments, pls share i= n this=20 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 of Geographi= c=20 Extension
yet the third paragraph states the case where a differ= ent=20 device is
used in the same CDN coverage area.  The intent o= f this=20 use case
needs to be clarified.  Perhaps the use case is t= rying=20 to address
the scenario where a Nomadic User-A with an agreement= =20 allowing
access to content from CSP-A via uCDN moves to a dCDN = in a=20 different
region.  The dCDN is allowed to distribute the co= ntent=20 of CSP-A to
User-A; however, not other users in the region of the = dCDN=20 are
allowed to retrieve the content unless they too have s= uch an=20 agreement.
Section 5.1.3 Content Encoding Restrictions Need to cl= arify=20 if we're
talking about the restrictions on the delivery of spec= ific=20 content
or the restrictions on the ability of a CDN to deliver= =20 specific
content.  I certainly understand the case where a= CSP=20 will restrict
the distribution of content to a "managed path" if suc= h=20 content is
HD while allowing the content distribution via an un-m= anaged=20 path if
such content is SD (same could apply to encryption met= hods,=20 delivery
methods, etc.).  On the contrary, the dCDN may ha= ve its=20 own
restrictions of blocking the distribution of HD conten= t=20 while
allowing the distribution of SD=20 content.
o first bullet makes sense if the dCDN can perform a s= ubset=20 of
encapsulations for a reference set of media (e.g. HLS,= HSS,=20 but not
DASH) o second bullet makes sense where the dCDN doesn= 't want=20 to
offer high bit-rate variants of the media o third bull= et make=20 sense
if the policy addresses QoE but I don't think=20 subscriber
rights/authorizations=20 apply.
Section 10 Security=20 Considerations
Aside from the security considerations WITHIN the uCDN= and=20 dCDN, I
think we can describe this in four=20 contexts:
a. The relationship between the CSP and the uCDN (the= =20 principle=20 contract
arrangement for=20 distribution)
b. The relationship between the uCDN and dCDN (the tra= nsitive=20 trust
relationship that extends the contract defined in (a) = above)=20 c. The
relationship between the User and dCDN (the recognitio= n of=20 right to
download predicated on (b) above) d. The relationship = between=20 the
User and CSP (the contract authorizing the user access= to=20 the
content)
The user is not interested in the a-b nor the b-c=20 relationship.=20 The
user is only interested in the transparency and=20 interoperability=20 of
the security relationship between d-b or d-c to the po= int=20 that the
authorization granted in d-a is viable when the delive= ry=20 is
initiated via either d-b or d-c.  As an example, = the=20 uCDN might use
URL appended tokens for authentication while dCDN migh= t use=20 URL
appended hashes.  The user doesn't want to know a= bout=20 the distinct
methods, but transparency is only afforded if the meth= ods=20 are
interoperable clearly defined when the delegation for= =20 content
delivery is executed.  Clearly, the choice of=20 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 = mailing=20 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/= mailman/listinfo/cdni

--_000_1B6D0317D3AD964FBF3956DEFA3524D51710BD9D74EUSAACMS0701e_-- From flefauch@cisco.com Thu Nov 3 13:01: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 A8DFE1F0CB6 for ; Thu, 3 Nov 2011 13:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.014 X-Spam-Level: X-Spam-Status: No, score=-6.014 tagged_above=-999 required=5 tests=[AWL=0.584, 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 s-MljdoVuJi7 for ; Thu, 3 Nov 2011 13:01:23 -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 998E91F0CAD for ; Thu, 3 Nov 2011 13:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=16274; q=dns/txt; s=iport; t=1320350483; x=1321560083; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=D8M3yr4TMrqUo1tIVe1i7E2lDY+UamOaE/DtNZxljjw=; b=WZeOUkmSeE8Xz8k0PzrpgYIRJw9SFvBOyYucEJyIt8N8TIMC3W4iSWz7 KtdTgWgULzkRvPcVEjVGTcsHOtieM5E7J7idmNeZqRCAq9dtNz48QnlsE 4OIQ4+wRBvCC7Gp95oqOZMeQWEml/jDKegQDwG7WKD14WN8Fhuke9/YwU U=; X-IronPort-AV: E=Sophos;i="4.69,451,1315180800"; d="scan'208,217";a="12218303" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 03 Nov 2011 20:01:23 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA3K1JY9020872; Thu, 3 Nov 2011 20:01:20 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-332-593369828 From: Francois Le Faucheur In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9D4F@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 3 Nov 2011 21:01:09 +0100 Message-Id: <05BA9A9C-1B03-4A50-9B7C-01BB4B62814F@cisco.com> References: <78BCE9D8-7C4F-4162-9F6B-867240993EE1@cisco.com> <1B6D0317D3AD964FBF3956DEFA3524D51710BD9D4F@EUSAACMS0701.eamcs.ericsson.se> To: Alan Kavanagh X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" 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: Thu, 03 Nov 2011 20:01:24 -0000 --Apple-Mail-332-593369828 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Alan, On 3 Nov 2011, at 20:28, Alan Kavanagh wrote: > Hi Francois > =20 > Thanks for putting some light on this, most appreciated. > =20 > I fully agree that Content Adaptation is definitely an optimization in = terms of delivery from the CSP/origin Server to the CDN Provider itself, = send 1 copy and not 10 etc saves on bandwidth which implies you need = smaller pipes and don't have to worry about the transcoding etc, makes = perfect sense. However i do believe its important for CDN_I to include = this and ill explain why. A lot of CSP's don't do content adaptation as = they either don't have the expertise or don't want to manage that side = of the content they produce, they only want to have it distributed to a = wide variety of devices etc and they give that job of Content Adaptation = to the CDN Provider to take care of as part of their business agreement = between the Content Provider and Distributor and this model is growing = quite a lot as im sure all CDN vendors alike here would agree with and = don't see that diminishing. Right, but having the CSP delegate content adaptation to "the CDNs" does = not translate in a requirement for CDNI to support content adaptation. = Specifically, the content adaptation can be performed by the = authoritative CDN (aka the upmost CDN). CDNI support of content = adaptation is only needed if the dCDN needs to do further content = adaptation beyond what the uCDN has already done. In fact, Richard has already made that point: > 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). The point you make above seems like a good argument for why it would be = good to support content adaptation in a CSP-uCDN interface but not an = argument for why it is needed in CDNI interfaces. Francois > =20 > Similarly as new codec's and end devices with different screen = density's come to the market i believe the CDN is better equipped to = handle this than the CSP. The CDN does the Content Adaptation for lots = of CSP's it has service agreements with so they typically do this as = opposed to have lots of CSP's do this themselves, its not just transport = savings but also CAPEX/OPEX and expertise the CSP may not have. The = savings here is for the CSP not the end user as i note you have below = and agree, but the cost burden here is the CSP in the first place and = same also between CDSP's.....transport/bandwidth is never free and when = optimization which translates into cost savings can be achieve its = imperative it is used. > =20 > I think Richard had a good proposal which was to bring some = presentations to Taipei or next meeting > as time is short to the group and take it from that on how to proceed. = Ill try and work with others to provide input on some use cases = describing this as i feel it will help the discussion and help it = conclude i hope :-) > =20 > Alan >=20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Francois Le Faucheur > Sent: October-28-11 5:49 AM > To: cdni@ietf.org > Subject: [CDNi] Content Adaptation >=20 > Folks, >=20 > Speaking as a co-chair. >=20 > 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. >=20 > 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. >=20 > 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,..... >=20 > 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. >=20 > Thanks >=20 > Francois >=20 > 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 --Apple-Mail-332-593369828 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Alan,

On 3 Nov 2011, at 20:28, Alan Kavanagh = wrote:

Hi Francois
 
Thanks for putting some light on this, most=20 appreciated.
 
I=20 fully agree that Content Adaptation is definitely an optimization in = terms of=20 delivery from the CSP/origin Server to the CDN Provider itself, send 1 = copy and=20 not 10 etc saves on bandwidth which implies you need smaller pipes and = don't=20 have to worry about the transcoding etc, makes perfect sense. However i = do=20 believe its important for CDN_I to include this and ill explain why. A = lot of=20 CSP's don't do content adaptation as they either don't have the = expertise or=20 don't want to manage that side of the content they produce, they only = want to=20 have it distributed to a wide variety of devices etc and they give that = job of=20 Content Adaptation to the CDN Provider to take care of as part of their = business=20 agreement between the Content Provider and Distributor and this model is = growing=20 quite a lot as im sure all CDN vendors alike here would agree with and = don't see=20 that = diminishing.

Rig= ht, but having the CSP delegate content adaptation to "the CDNs" does = not translate in a requirement for CDNI to support content adaptation. = Specifically, the content adaptation can be performed by the = authoritative CDN (aka the upmost CDN). CDNI support of content = adaptation is only needed if the dCDN needs to do further content = adaptation beyond what the uCDN has already done.
In fact, = Richard has already made that point:
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).

The = point you make above seems like a good argument for why it would be good = to support content adaptation in a CSP-uCDN interface but not an = argument for why it is needed in CDNI = interfaces.

Francois

 
Similarly as new codec's and end devices with = different screen density's=20 come to the market i believe the CDN is better equipped to handle this = than the=20 CSP. The CDN does the Content Adaptation for lots of CSP's it has = service=20 agreements with so they typically do this as opposed to have lots of = CSP's do=20 this themselves, its not just transport savings but also CAPEX/OPEX and=20= expertise the CSP may not have. The savings here is for the CSP not the = end user=20 as i note you have below and agree, but the cost burden here is the CSP = in the=20 first place and same also between CDSP's.....transport/bandwidth is = never free=20 and when optimization which translates into cost savings can be achieve = its=20 imperative it is used.
 
I=20 think Richard had a good proposal which was to bring some presentations = to=20 Taipei or next meeting
as time is short to the group and take it from that=20 on how to proceed. Ill try and work with others to provide input on some = use=20 cases describing this as i feel it will help the discussion and help it = conclude=20 i hope :-)
 
Alan

From: cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le=20 Faucheur
Sent: October-28-11 5:49 AM
To:=20 cdni@ietf.org
Subject: = [CDNi] Content Adaptation

Folks,

Speaking as a co-chair.

I have been = through the=20 recent exchange on content adaptation (aka the poorly-titled "Re: [CDNi] = I-D=20 Action: draft-ietf-cdni-use-cases-00.txt" thread) and wanted to share a = few=20 thoughts.

First, some messages might have given the impression = that=20 content adaptation was required for a CDNI solution to be able to deal = with=20 multiple types of terminal/resolution/sizes etc. So at the risk of = restating the=20 obvious, let's be very explicit that this is obviously not the case. A = very=20 simple/common way to support multiple types of terminal/resolution/sizes = in one=20 CDN, or in a multi-CDN environment, is to have different contents/URIs = for each=20 profile.
So content adaptation is not _required_ to be supported by = CDNI, but=20 is a candidate optimisation to do some of the same things in a different=20= way.

Second, some messages suggested that content adaptation was = a very=20 strong win (aka transfer 1 flow instead of 10 flows across CDNs). As = Richard=20 pointed out already, this ignores a number of considerations such as the = cost=20 associated with performing the actual content adaptation downstream. = Anyways, I=20 think content adaptation may be better seen as a trade-off that can = indeed be=20 positive in some environments, rather than an obvious huge win.
Also, without the content adaptation optimization, while the = content maybe=20 passed across CDNs multiple times (in different formats), it is worth = noting=20 that the smaller res/size/quality representations may actually amount to = much=20 smaller size/bandwidth than the highest res/size/quality, so it is not = quite a=20 multiplying factor. 
Lastly, while the content adaptation = optimization=20 may reduce further the inter-CDN transfer from 1-10 flows down to =  1 flow,=20 the base CDNI solution allows a content to be transferred across CDNS = 1-10 times=20 total instead of once per user accessing the content (as would be the = case if=20 the uCDN pumps the same traffic to every users because it cannot = interoperate=20 with the dCDN) which can result in a gain factor of 10s, 100s,=20 1000s,.....

I have the impression that the key arguments have now been = exposed=20 (some of them even repeatedly) through the long thread. So I would = suggest to=20 pause that discussion, unless _new_ arguments need to be brought into = the=20 discussion, and then we can poll for consensus in Taipei and then on the=20= list.

Thanks

Francois

PS: Please think of using = specific=20 Subject lines for the various threads and don't hesitate to branch off = with a=20 different "Subject" when an initial thread morphs into a different = topic. This=20 helps the discussion.


= --Apple-Mail-332-593369828-- From flefauch@cisco.com Thu Nov 3 13:08: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 6308B1F0C56 for ; Thu, 3 Nov 2011 13:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.44 X-Spam-Level: X-Spam-Status: No, score=-4.44 tagged_above=-999 required=5 tests=[AWL=-2.458, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_75=0.6, MIME_QP_LONG_LINE=1.396, 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 cH9hm+9AmHEx for ; Thu, 3 Nov 2011 13:08:18 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id EA2711F0C35 for ; Thu, 3 Nov 2011 13:08:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=199121; q=dns/txt; s=iport; t=1320350894; x=1321560494; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=RGGR5jaPQiNwBiLD8O2PONhOxQnC9bJyfQExqbX3pjo=; b=Vrf3VObKBrh0xWk6ZuFTNnmod3OuO84GsPLjcAdZQ3fK/a845LnReOhx 0C5lMxBZfWkVopL3HXNTyERK5b82b3m8gCiyl3MBZ1W2kJMurq5mPYdTj VCxeAuPOXAeMCHPK5PzWACQJk85mBCCsdk+xQZgVXm1xzfgOz3/TgTkVw k=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQAAMLzsk6Q/khR/2dsb2JhbABEgk2BXU+VDoUBiVouc4EFgXIBAQEDAQEBAQIBBgYBBwEIAgkbGwoEBwUHAgIJCQoBAwEBAQUBAQsOAQYDAgICFAEECQIBHwMGCAYKCAEUBQEBB4dgCJV+AYxLgWqQQAKICDNiBIJZjBRShFmDHocehyo X-IronPort-AV: E=Sophos;i="4.69,452,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="2368747" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-3.cisco.com with ESMTP; 03 Nov 2011 20:08:11 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA3K84mm009531; Thu, 3 Nov 2011 20:08:04 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-346-593774679 From: Francois Le Faucheur In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9D74@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 3 Nov 2011 21:07:54 +0100 Message-Id: <1E2D7E53-C195-420C-A4BF-DA81FB6F8ADB@cisco.com> References: <260A32EFD5C9EB47AD504929D005DF6217F6B6FB@SZXEML519-MBX.china.huawei.com> <1CA25301D2219F40B3AA37201F0EACD1136C1D7D@PACDCEXMB05.cable.comcast.com> <260A32EFD5C9EB47AD504929D005DF6217F6CBBB@SZXEML519-MBX.china.huawei.com> <817779F3-8F95-42BA-9DA3-34EF81DFDB71@cisco.com> <1B6D0317D3AD964FBF3956DEFA3524D51710BD9D74@EUSAACMS0701.eamcs.ericsson.se> To: Alan Kavanagh X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org 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: Thu, 03 Nov 2011 20:08:22 -0000 --Apple-Mail-346-593774679 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Alan, (as an individual) On 3 Nov 2011, at 20:42, Alan Kavanagh wrote: > Hi Francois > =20 > I dont believe its a lot of work, we are talking about a couple of = additional Metadata objects which i feel is very trivial to have added, = right? I do believe fully covering content adaptation in CDNI would actually be = a lot of work. Partly because it is a space of fast innovation and = proprietary approaches. Partly because I would bet that each of us would = actually come up with a different set of additional metadata objects and = it woudl take a long time to converge on an agreeable set. Francois > =20 > Alan >=20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of Francois Le Faucheur > Sent: October-28-11 9:46 AM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt >=20 > Hi again Zhipeng, >=20 > 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. >=20 > 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. >=20 > Cheers >=20 > Francois >=20 >=20 > On 28 Oct 2011, at 11:25, ZhouZhipeng wrote: >=20 >> 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. >> 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. >> 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. >> 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. >> 3) As for the procedure of content adaptation, I just draft a = diagram as below: >> >> You may see the solution is rather clear and the metadata needed = would be clear also. >> 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 >> 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 >> >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 >> 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. >> 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]=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 >> 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, >>=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 >> - 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: >>=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). >> 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. >> 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. >>=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. >> 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 >>=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 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=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-346-593774679 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-347-593774680 --Apple-Mail-347-593774680 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Francois
 
I=20 dont believe its a lot of work, we are talking about a couple of = additional=20 Metadata objects which i feel is very trivial to have added,=20 right?

I do = believe fully covering content adaptation in CDNI would actually be a = lot of work. Partly because it is a space of fast innovation and = proprietary approaches. Partly because I would bet that each of us would = actually come up with a different set of additional metadata objects and = it woudl take a long time to converge on an agreeable = set.

Francois


 
Alan

From: cdni-bounces@ietf.org=20 [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le=20 Faucheur
Sent: October-28-11 9:46 AM
To:=20 ZhouZhipeng
Cc: cdni@ietf.org
Subject: Re: = [CDNi] I-D=20 Action: draft-ietf-cdni-use-cases-00.txt

Hi again Zhipeng,

There is one other point I should have brought up in my previous=20 message:
The question is not so much whether there are benefits to allowing = content=20 adaptation for some environments, nor whether one particular individual = could=20 conceive an approach for content adaptation that suits him. The question = here is=20 rather whether it is justified for the Working Group to focus energy on = that=20 problem right now in order to develop a consensus-based approach that = suits the=20 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=20 on that problem right away and explained your rationale. Thank you. = Others have=20 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=20 Richard=E2=80=99s request, I like to show my information although = perhaps not complete=20 right now.
1)     I have done some work to collect different company=E2=80=99= s requirements=20 and opinions on this functionality.
One, I feel most of us have already been = aware of the service of=20 content adaptation, and I also sent an email yesterday that Vodaphone = now is=20 requiring the solution to enhance the performance of its mobile video=20= service.
Second, here is an article about CISCO : = =E2=80=9CCisco urges mobile=20 operators to add value to CDN services=E2=80=9D http://www.totalte= le.com/view.aspx?ID=3D468705
Besides, I have checked many CDN company=E2=80= =99s websites. Many claim to=20 support transcoding while some may not.
2)     For the wording =E2=80=9Ccontent adaptation=E2=80=9D, it = should be clarified here=20 that it may be two kinds.
One is only the transformation of = encapsulation format. For example=20 the H.264 stream is encapsulated in APPLE and Adobe format=20 respectively.
I know that Comcast has a project that needs = to pick the H.264=20 media from the TS stream and then encapsulated them into different=20 formats(APPLE,Adobe=E2=80=A6) to different = devices.
For this kind of transformation, the = computing cost is very very=20 low and may be nearly neglected.
The other is to transcoding.  For = example to support different=20 bitrates.  Since encoder is a high value facility, we should = compare the=20 capital cost of encoder and transport cost.
Just take a simple model: content is = delivered from Node A to Node=20 B.
<image002.png>
There are two = solutions:
1)     A have the transcoder and deliver multi-format content to=20= B
2)     B have the transcoder; A only delivers one format content = to B and=20 B would transcode.
=46rom whole system point of view, either A = or B would transcode=20 while the bandwidth would be saved in solution B. Hence solution B is=20= better.
Now provided the bandwidth is paid by B and = B should decide whether=20 to install transcoder.
(Richard has said to set transcoder in each = edge=20 server)
If the cost of renting bandwidth (for a few = months) is more=20 expensive than the price of transcoder supporting the same bandwidth, = it would=20 be better to put the transcoder at the receiver Node=20 B.
In fact I have investigated this issue for = much time. While in=20 different area the price of bandwidth may be different.  And the=20= transport burden between two distant places or over a bad nature = environment=20 would be much higher.
In Verizon, the package for 10-15mbps is $90 = per month (I feel the=20 bandwidth quality for business would be guaranteed). I query that the=20= bandwidth price in China may be 50% higher.
I do not know how much the price will be for = the bandwidth from=20 Amsterdam to Paris (cross country in the same continent).  But I = feel the=20 price from NewYork to Paris would absolutely be very high.  As = for the=20 Encoder, it also varies. Perhaps the price in China will be higher = than in=20 USA. And in fact the price of bandwidth and encoder depends mostly on = the=20 concrete business items. For example the price to Huawei may be lower = than the=20 public price.
By my current evaluation in China it is = better using the transcoder=20 than renting multiple times broadband.
Some people have told me that for the = operator himself probably the=20 bandwidth cost would be very low in the internal capital counting. But = for the=20 independent CDN, it may another thing.
So, my suggestion is to let different ways = co-exist. I have=20 announced that to let two sides negotiate whether to assign dCDN for = the=20 content adaptation.
In fact, from CP to CDN,  there are the = real businesses that=20 either let CP to provide multi-format content or let the CDN to = receive one=20 format and complete the transformation, depending on the concrete=20 business.
By the same logic, form uCDN to dCDN, it may = be either the uCDN to=20 provide multi-format content or the dCDN to receive one format content = and=20 then complete the transformation.
Currently there is not the real CDN-CDN = connection, hence we are=20 basing our knowledge on the related solution to make our=20 solutions.
3)     As for the procedure of content adaptation, I just draft = a diagram=20 as below:
<image004.png>
You may see the solution is rather clear and = the metadata needed=20 would be clear also.
Dear,
By my analysis above, I kindly invite your = ideas whether it may be=20 an applicable and simple part in the CDNI item, provided that the = solution is=20 open to the types of content adaptation and may be optionally = implemented in=20 the real solutions/business. I feel for those operators that need such=20= functionality it would be very good while it does not impact others = that do=20 not implement it.
Thanks.
Zhipeng
From: Woundy, = Richard=20 [mailto:Richard_Woundy@cable.comcast.com] 
Sent: Thursday, October 27, 2011 = 7:23=20 PM
To: ZhouZhipeng; 'mark@jet-stream.nl'; 'alan.kavanagh@ericsson.com'
Cc: 'cdni@ietf.org'; Woundy,=20 Richard
Subject: Re:=20 [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt
>In=20 your company=E2=80=99s website, I just find some information

I = have to step in=20 as co-chair here.

The goal of this WG is not to align vendor = product=20 roadmaps, or to equalize all vendor offerings, or to specify the = entire CDNI=20 ecosystem. The goal of this WG is to enable the interconnection and=20 interoperation of two or more CDNs, within the bounds of the CDNI wg=20= charter.

It is OK to have a discussion about whether content = adaptation=20 needs to be performed by the dCDN, since that decision impacts the = uCDN-dCDN=20 interface. So let's find a productive way to discuss this on the = mailing list,=20 and to close the discussion by IETF 82 (if not sooner).

Can = someone=20 describe real-life examples where downstream CDN (or edge cache-based) = content=20 adaptation is needed today in a production environment, or shortly? = Not merely=20 a feature in a vendor's product materials?

Speaking as an = individual, I=20 can find a lot of examples where downstream content adaptation is not = needed,=20 and any adaptation is really part of the CP - uCDN interface (which is = out of=20 the scope of our charter).

-- Rich

 
From:=20 ZhouZhipeng [mailto:zhouzhipeng@huawei.com] 
Sent: Thursday, = October=20 27, 2011 03:45 AM
To: Mark de Jong <mark@jet-stream.nl>; Alan = Kavanagh=20 <alan.kavanagh@ericsson.com&= gt; 
Cc: cdni@ietf.org <cdni@ietf.org> 
Subject: Re: = [CDNi] I-D=20 Action: draft-ietf-cdni-use-cases-00.txt 
 
Hello=20= Mark,
Nice=20 to meet you on line.
In=20 your company=E2=80=99s website, I just find some information that = addresses =E2=80=9C Vodafone=20 subscribers complained about video performance.=E2=80=9D
See:
Dear=20 all in this group,
In=20 last few days, except the public email discussions I have contacted = with some=20 people and discussed with my own colleagues of all details on this=20 issue.
First,=20= although the market requirement for it is very important, I feel I=E2=80= =99d better=20 show up more information on the procedure involved. I have explained = many=20 times that to support content adaptation is rather simple while the = wording is=20 not enough.
I=20 am busy making some contributions on this and plan to upload to ETSI = meeting=20 and IETF CDNI.
By=20 these work  I feel the people may catch a whole view on this=20 issue.
Second,=20= for that functionality, in implementation, if some entity does not = choose to=20 support it, it may be ok. Since it may be negotiated between  two = CDNs.
If=20 dCDN does not support that, it may be the uCDN responsible to complete = the=20 transcoding and deliver the content of multiple formats and rates to=20= dCDN.
Third,=20= although CDNI is a new architecture, while the content operating has = been=20 existed for years. As I know the content from USA to the downstream = operator=20 is transferred on one copy and the downstream operator will handle the=20= transcoding.
Perhaps,=20 the content adaptation is more on the mobile operating. But I feel = currently=20 most operator will be a all service operator. And for the CDN = providers, it=20 may be better to support all kinds of service.
Besides,=20 I like say that the technology on this topic has been for many years = and has=20 been rather mature, even some items in ietf such as rfc3507  icap. So from the = technique point of=20 view, it is a nature action to be involved in CDN=20 interconnection.
Thanks.
Zhipeng
From: Mark de = Jong=20 [mailto:mark@jet-stream.nl] 
Sent: Thursday, October 27, 2011 = 4:21=20 AM
To: Alan=20= Kavanagh
Cc: Ben=20 Niven-Jenkins; ZhouZhipeng; cdni@ietf.org
Subject: Re: [CDNi] I-D Action:=20 draft-ietf-cdni-use-cases-00.txt
Hi = Alan,
As Ben stated the overall = discussion right now is about delivery,=20 not on adaptation. It is hard enough to get consensus on the delivery = aspect=20 already not to mention your requirement from content adaptation added = to that,=20 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 let=20 us keep the scope of this be clean and transparent. It is of benefit = of=20 everyone to get the first specs as fast as possible.=20 Thanks.
Met=20 vriendelijke groet,
Kind=20 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=20 us at Streaming Media Europe, 17-18 October, London, = UK
-=20 Event: Meet=20 us at Online Video Strategies, 19 October, London, = UK
-=20 Event: Meet=20 us at CDN World Summit, 25-28 October, London, UK
- News: Pre-request=20= 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'=20 brochure
- VideoExchange: www.vdo-x.net
- Streamzilla: www.streamzillacdn.com<= /span>
- Corporate: www.jet-stream.com
On 26, Oct,2011, at 8:33 = PM, Alan Kavanagh=20 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 = should=20 address in the CDN-I WG. I do agree with you that content adaptation = is an=20 optimization between CDN's but it's a very important one that I know = Network=20 Service Providers particularly = require.

Alan

-----Original=20 Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On=20 Behalf Of Ben Niven-Jenkins
Sent: October-12-11 1:13 PM
To:=20 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. After that=20 the user only desires to get his selected=20 content.
But how the content is = transferred to the client is not worried=20 by the user.
The CP may create a = special format as required by the user and=20 ask the CDN to deliver to user.
While CP may give a HD = format content to uCDN and the dCDN may=20 then transform to the format as the user=20 select.


Lots of things may be possible = to do and CDN providers offer=20 many additional services on top of the "core" service of content = delivery.=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 CSP=20 to an End User that is targeted and deployable within a short time = frame=20 (18-24 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=20 the CDNI charter.

In this case, it is = nothing related to how the user select formats=20 on CP website.
So, it is the CP and user = to decide the content format not the=20 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 today", I have=20 ever raised an email before that your company's webpage has claimed=20= supporting media transformation and multi-screen=20 service.
Perhaps, I like asking = you list some features that you feel are=20 the core functionalities by existing main stream CDNs. Thus we may = compare=20 and take deep look.


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

I guess many people have = the experience/knowledge of content=20 related service. The user and CP only care whether the CDN providers = may=20 satisfy their requirement while not care the internal process. Just as=20= GSM/PSTN interconnection, the user only care successful = interconnection while=20 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=20 media formats.
One candidate is your = company, another is CDN-X. The users are=20 located in France.
So both your company and = CDN-X should connect a France CDN=20 provider(CDN-Y).
If your company's = solution is to send 10 streams of different=20 format
of one content to CDN-Y; = While CDN-X's solution is to send 1=20 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=20 lower.
For CDN-Y, in solution-1, = it should receive/forward 10 streams ;=20 while in solution-2, it should only receive 1 stream but need to = take=20 transformation to output 10 = streams.
Which solution is more = competitive. it is Solution 1, right.=20 Remember the price from BBC is same to both your company and CDN-X = or BBC=20 would select one CDN provider with the lower=20 price.
If a CDN provider may not = get the contract from CP, how it may=20 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=20 enable content delivery between interconnected CDNs. I can think of = many=20 optimizations that a CDN could implement to differentiate their = service but=20 the internal workings of an individual CDN are out of scope of our=20 charter.

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

Ben

So, if we all realize = that currently the media type is rich, the=20 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 concerning the=20 interconnection, the transformation should at once be solved. = Otherwise the=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
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 is absolutely=20 correct that the delivery capability is the core requirement for = CDN=20 system.
While CDN is used to = provide the content delivery=20 service.
What means service. It = should include "time" "location" and=20 "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 sure=20 whether the issues such as "logging" "geographic constraint" are = the core=20 of CDN.
For "without explicit = knowledge of what that content actually=20 is ", I am not sure whether the wording is accurate since = generally a CDN=20 may claim it support different=20 medias.
By this opportunity, I = like to share a use case: a call from a=20 GSM phone to a PSTN telephone, the voice stream should be = transformed from=20 GSM voice to = G.711.
For the user, he does not = need to know what type of data has=20 been transferred, but the operator has done some work to = interconnect two=20 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 analogy of mobile=20 networks being interconnected to PSTN networks. In the case of = content=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 has=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=20 in what representations the User/Client decides to=20 request.
As for you said selecting = media by the "portal", you may see=20 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=20 types".
Now what you're talking = about is an optimisation, not a core=20 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 = (which=20 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 = work in=20 itself. Let's not start trying to add in additional functionality = beyond=20 what the majority of CDNs support today as that will just delay us = getting=20 usable specifications into the market in a timely fashion=20 IMO.
Ben
A good question is = "security" since I have done six years on=20 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 = systems=20 should be granted by the content=20 owner.
Here I also like to = clarify that not only the media itself but=20 the information related to service itself (such as the geographic=20= constraint) should be protected=20 also.
So, trust is not a = problem for the=20 media.
Philip,
Thank you that you feel = Content Adaption is an issue 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 you operator=20 since it may save investment if the system may support different=20= services.
For us vendor, we are = happy operator may install a system for=20 the mobile service and another system for the FBB=20 service.
But the reality is all = operators ask us to provide a system=20 that may support different service=20 systems.
Frankly, Ben and Philip, = I remember I have explained somewhere=20 that to implement this is rather simple=20 .
At least the Use case and = Requirement are informational to be=20 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 [mailto:philip.eardley@bt.com= ]
Sent: Monday, October 10, = 2011 11:22=20 PM
To: ben@niven-jenkins.co.uk;=20 ZhouZhipeng
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 an issue for the=20 Requirements doc than for the Use cases=20 draft.
The key question is = whether we want the CDNI interfaces to be=20 able to cope with a scenario where (say) HD/SD conversion is done = in the=20 dCDN & to signal about=20 this.
I think that coping with = this scenario is a second order=20 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 = Use=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 be valid even if=20 content adaptation (HD/SD) is out of=20 scope.
- a dCDN might for some = reason be unwilling to distribute=20 HD?
- a CSP might want to = make sure the dCDN can use HLS=20 encapsulation?
But these sorts of = examples seem to be static policy things (to=20 do
with the capabilities = & preferences of the CDNs & CSP),=20 rather than
metadata associated with = a particular piece of content. In=20 the
discussion so far, I = think negotiation about static policy=20 stuff is
rather out of=20 scope(?)
On security = considerations, an interesting question is whether=20 trust is transitive. Don't think it need be - just because CSP = trusts=20 uCDN, and uCDN trusts dCDN doesn't mean that the CSP automatically = trusts=20 the dCDN. However, i suspect this can get arbitrarily complex - so = one=20 possibility is to say that we will only handle cases where the = trust is=20 transitive.
Best = wishes
phil
Philip = Eardley
Research and Technology=20= Strategy
This email contains BT = information, which may be privileged or=20 confidential. It's meant only for the individual(s) or entity = named above.=20 If you're not the intended recipient, note that disclosing, = copying,=20 distributing or using this information is prohibited. If you've = received=20 this email in error, please let me know immediately on the email = address=20 above. Thank you. We monitor our email system, and may record your=20= emails.
British = Telecommunications=20 plc
Registered office: 81 = Newgate Street London EC1A 7AJ Registered=20 in
England no:=20 1800000
-----Original=20 Message-----
From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On=20 Behalf
Of Ben=20 Niven-Jenkins
Sent: 10 October 2011=20 12:04
To: = ZhouZhipeng
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 Cases draft.=20 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 = requested=20 without explicit knowledge of what that content actually=20 is.
Let's not forget that in = building an end to end content service=20 the CDN is only one component and is the component tasked with = executing=20 the delivery of a specific representation (version/copy/format = etc.) of=20 the selected content not the component tasked with deciding (or = applying=20 policy) on which version/copy/representation of content should be=20= delivered.
The decision as to which = version/copy/representation to offer=20 and allow to be delivered to a given device/user is implemented = outside of=20 the CDN (e.g. by the "portal" where the user first makes their = content=20 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 feel Scott's=20 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 two=20 content with different identifier. In DRM scope, the basic unit = is a=20 content = copy.
Here the first bullet "a = subset of encodings deliverable to=20 specific devices," has listed the case of content=20 = adaptation.
=
In last month, I have = contacted the Authors of this document=20 and taken some email exchanges with Grant and Philip=20 = (BT).
I have shown BT with some = information that I know in this=20 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 group raising=20 your comments or questions on this case since I hope my use case = may be=20 incorporated in the use case=20 = draft.
If you have any more = question or comments, pls share in this=20 = thread.
Thanks.
Zhipeng
-----Original=20 = Message-----
From: Scott Wainner=20 = [mailto:swainner@cisco.com]
Sent: Friday, September = 30, 2011 8:02=20 = AM
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 of Geographic=20 = Extension
yet the third paragraph = states the case where a different=20 device = is
used in the same CDN = coverage area.  The intent of this=20 use = case
needs to be clarified. =  Perhaps the use case is trying=20 to = address
the scenario where a = Nomadic User-A with an agreement=20 = allowing
access to content from = CSP-A via uCDN moves to a dCDN in a=20 = different
region.  The dCDN is = allowed to distribute the content=20 of CSP-A = to
User-A; however, not = other users in the region of the dCDN=20 = are
allowed to retrieve the = content unless they too have such an=20 = agreement.
Section 5.1.3 Content = Encoding Restrictions Need to clarify=20 if = we're
talking about the = restrictions on the delivery of specific=20 = content
or the restrictions on = the ability of a CDN to deliver=20 = specific
content.  I = certainly understand the case where a CSP=20 will = restrict
the distribution of = content to a "managed path" if such=20 content = is
HD while allowing the = content distribution via an un-managed=20 path = if
such content is SD (same = could apply to encryption methods,=20 = delivery
methods, etc.).  On = the contrary, the dCDN may have its=20 = own
restrictions of blocking = the distribution of HD content=20 = while
allowing the distribution = of SD=20 = content.
o first bullet makes = sense if the dCDN can perform a subset=20 = of
encapsulations for a = reference set of media (e.g. HLS, HSS,=20 but = not
DASH) o second bullet = makes sense where the dCDN doesn't want=20 = to
offer high bit-rate = variants of the media o third bullet make=20 = sense
if the policy addresses = QoE but I don't think=20 = subscriber
rights/authorizations=20 = apply.
Section 10 Security=20 = Considerations
Aside from the security = considerations WITHIN the uCDN and=20 dCDN, = I
think we can describe = this in four=20 = contexts:
a. The relationship = between the CSP and the uCDN (the=20 principle=20 = contract
arrangement for=20 = distribution)
b. The relationship = between the uCDN and dCDN (the transitive=20 = trust
relationship that extends = the contract defined in (a) above)=20 c. = The
relationship between the = User and dCDN (the recognition of=20 right = to
download predicated on = (b) above) d. The relationship between=20 = the
User and CSP (the = contract authorizing the user access to=20 = the
content)
<= /blockquote>
The user is not = interested in the a-b nor the b-c=20 relationship.=20 The
user is only interested = in the transparency and=20 interoperability=20 of
the security relationship = between d-b or d-c to the point=20 that = the
authorization granted in = d-a is viable when the delivery=20 = is
initiated via either d-b = or d-c.  As an example, the=20 uCDN might = use
URL appended tokens for = authentication while dCDN might use=20 = URL
appended hashes. =  The user doesn't want to know about=20 the = distinct
methods, but transparency = is only afforded if the methods=20 = are
interoperable clearly = defined when the delegation for=20 = content
delivery is executed. =  Clearly, the choice of=20 authentication method is determined by the respective=20 = CDN's.
Scott
_______________________________________________<= /span>
CDNi mailing=20 list
=
_______________________________________________<= /span>
CDNi mailing = list
=


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

_______________________= ________________________
CDNi=20 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-347-593774680 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-347-593774680-- --Apple-Mail-346-593774679-- From alan.kavanagh@ericsson.com Thu Nov 3 15:08: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 CE7C01F0CA4 for ; Thu, 3 Nov 2011 15:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.073 X-Spam-Level: X-Spam-Status: No, score=-6.073 tagged_above=-999 required=5 tests=[AWL=0.525, 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 sxJaX5iXTbpB for ; Thu, 3 Nov 2011 15:08:24 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 12E051F0C79 for ; Thu, 3 Nov 2011 15:08:21 -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 pA3M8HQn019842; Thu, 3 Nov 2011 17:08:18 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.52]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 3 Nov 2011 18:08:13 -0400 From: Alan Kavanagh To: "gilles.bertrand@orange.com" , "emile.stephan@orange.com" , "grant.watson@bt.com" , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" Date: Thu, 3 Nov 2011 18:08:13 -0400 Thread-Topic: draft-ietf-cdni-cases-00 Thread-Index: AcyadRRdhlXhbegIQbqsQJnwtuqUpA== Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> 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_1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFCEUSAACMS0701e_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] draft-ietf-cdni-cases-00 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, 03 Nov 2011 22:08:24 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFCEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors A couple of questions and suggestions in relation to the current cdni-use-c= ases-00 draft. Hope these comments/suggestions helps improve the draft. I a= lso have some questions noted below. * Section 1.1. You mention Access CDN. Is this more an operator own and = managed CDN in the Access Domain that may have access to end user informati= on or are you talking about a given Access CDN having access to the end-use= rs profile, im assuming its the former but felt its not clear in the draft. * Section 1.3. First bullet " improve the experience for the End User; f= or instance delivery has lower latency and better robustness". Suggest to add and reduce Round= Trip Time as content is positioned closer to end user. * Section 1.3. Third bullet mentions reduced electricity consumption, co= uld you expand on that and say how this is achieved? * Section 1.3. Suggest to add CSP-3 in Figure-1 to be consistent. * Section 1.4. I understand what you are conveying here, makes sense. I = would however clarify that CDN's even external ones to interconnect with ot= hers today but use a Proprietary interface to do so etc. * Section 2.3. Is their enough movement of nomadic users are moving to c= ache content in the first place?....im thinking here than you may be nomadi= c but also geo-blocked, believe that should be very clearly clarified. * Section 3.1. "However, unexpected spikes in content popularity may dri= ve load...." suggest to "flash crowds" after content popularity. * Section 3.1 Offloading. It should be noted that this use case would re= quire knowledge about the other CDN to know if the other CDN has the resour= ces to offload the requests in the first place and also if the content is a= vailable in the CDN being offloaded too. * Section 4.1. Im having difficulty in seeing how number 1 is a typical = CDN use case of today? IMHO i dont not agree that its a typical model. * Section 4.1. example 2. "the ability to deliver content over a protoco= l that is required by specific mobile devices and not supported by CDN-A." = Can you give some examples on this as im having a hard time seeing this in = reality? * Section 10. Shouldn't it also cover a section on Authorization to view= content and Authorization with Origin Server? Best Regards Alan --_000_1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFCEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Authors
 
A couple = of=20 questions and suggestions in relation to the current cdni-use-cases-00 draf= t.=20 Hope these comments/suggestions helps improve the draft. I also have s= ome=20 questions noted below.
  • Section = 1.1. You=20 mention Access CDN. Is this more an operator own and managed CDN in the A= ccess=20 Domain that may have access to end user information or are you talking ab= out a=20 given Access CDN having access to the end-users profile, im assuming its = the=20 former but felt its not clear in the draft.
  • Section = 1.3. First=20 bullet " improve the experience for the End User; for instance delivery=20 has
          lower latency and better robustness= ".=20 Suggest to add and reduce Round Trip Time as content is positioned closer= to=20 end user.
  • Section = 1.3. Third=20 bullet mentions reduced electricity consumption, could you expand on that= and=20 say how this is achieved?
  • Section = 1.3.=20 Suggest to add CSP-3 in Figure-1 to be consistent.
  • Section = 1.4. I=20 understand what you are conveying here, makes sense. I would however clar= ify=20 that CDN's even external ones to interconnect with others today but use a= =20 Proprietary interface to do so etc.
  • Section = 2.3. Is=20 their enough movement of nomadic users are moving to cache content in the= =20 first place?....im thinking here than you may be nomadic but also geo-blo= cked,=20 believe that should be very clearly clarified.
  • Section = 3.1.=20 "However, unexpected spikes in content popularity may drive load...." sug= gest=20 to "flash crowds" after content popularity.
  • Section = 3.1=20 Offloading. It should be noted that this use case would require knowledge= =20 about the other CDN to know if the other CDN has the resources to offload= the=20 requests in the first place and also if the content is available in the C= DN=20 being offloaded too.
  • Section = 4.1. Im=20 having difficulty in seeing how number 1 is a typical CDN use case of tod= ay?=20 IMHO i dont not agree that its a typical model.
  • Section = 4.1.=20 example 2. "the ability to deliver content over a protocol that is requir= ed by=20 specific mobile devices and not supported by CDN-A." Can you give some=20 examples on this as im having a hard time seeing this in reality?=20
  • Section = 10.=20 Shouldn't it also cover a section on Authorization to view content and=20 Authorization with Origin Server?
Best=20 Regards
Alan
--_000_1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFCEUSAACMS0701e_-- From zhouzhipeng@huawei.com Fri Nov 4 01:14: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 E7C5B21F8B4D for ; Fri, 4 Nov 2011 01:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.675 X-Spam-Level: X-Spam-Status: No, score=-4.675 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, 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 kQijFRV+ioNB for ; Fri, 4 Nov 2011 01:14:16 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD9A21F8B4E for ; Fri, 4 Nov 2011 01:14:15 -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 <0LU4005Q0MRXCA@szxga05-in.huawei.com> for cdni@ietf.org; Fri, 04 Nov 2011 16:11:57 +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 <0LU4008AEMRO1W@szxga05-in.huawei.com> for cdni@ietf.org; Fri, 04 Nov 2011 16:11:57 +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 AEW29789; Fri, 04 Nov 2011 16:11:56 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 16:11:50 +0800 Received: from SZXEML519-MBX.china.huawei.com ([169.254.3.117]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Fri, 04 Nov 2011 16:11:49 +0800 Date: Fri, 04 Nov 2011 08:11:47 +0000 From: ZhouZhipeng In-reply-to: <3F1DB47B-5614-4FE4-BF02-D091F84ACDBE@cisco.com> X-Originating-IP: [10.138.73.38] To: Francois Le Faucheur , "cdni@ietf.org" Message-id: <260A32EFD5C9EB47AD504929D005DF6217F6DF94@SZXEML519-MBX.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: AQHMmlIM0p1toKNg4Uy+T11t9RIj65WcXZlA 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> <3F1DB47B-5614-4FE4-BF02-D091F84ACDBE@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: Fri, 04 Nov 2011 08:14:19 -0000 Sure Francois, I am a little sorry for that because I have contacted several people within a company so not convenient to list multiple names. I will be careful for that in the future. Zhipeng -----Original Message----- From: Francois Le Faucheur [mailto:flefauch@cisco.com] Sent: Friday, November 04, 2011 1:57 AM To: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt Folks, (as a WG co-chair) It is great that the CDNI topic has attracted new faces (or "voices" I should say until we get together in Taipei) that we have not heard/seen around the IETF before. To ensure we operate as effectively as possible, I would like to encourage those that are not so familiar with the IETF to take the time to familiarize themselves with the IETF process, in particular by checking out the "The Tao of IETF: A Novice's Guide to the Internet Engineering Task Force" (https://datatracker.ietf.org/doc/draft-hoffman-tao4677bis/). In particular, it is good to keep in mind the following statement: "Participation in the IETF or of its WGs is not fee-based or organizationally defined, but is based upon self-identification and active participation by individuals." So that discussions in IETF is expected to be based on technical arguments made by individuals and not based on company affiliation, positions or strategies. Cheers Francois On 31 Oct 2011, at 10:04, ZhouZhipeng wrote: > Sorry, not KPN. It is Ray from TNO. > Zhipeng > > > From: ZhouZhipeng > Sent: Monday, October 31, 2011 4:49 PM > To: 'Francois Le Faucheur' > Cc: cdni@ietf.org > Subject: RE: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > Dear Francois, and all, > Thanks for all the group's attention on this topic. > I am also happy that my proposal has gotten so much valuable response/questions/ comments. > That will be very helpful for all of us to catch a complete understanding and solution for this market demand. > While I feel till now the topic itself has not been completely analyzed and I am busy doing the work. I will expose my contribution soon after I complete that work. > Meanwhile I hope the group may allow some more time for people to consider it. Perhaps some more people will emerge in the group mail list. > Currently, some people has claimed their preference. I feel perhaps not a few people have supported this use case(the authors of draft-fmn-cdni-advanced-use-cases-00, Alan from Ericsson, ChinaMobile, Chinatelecom, perhaps also KPN, and me). > > I have explained that for CDN-A and CDN-B, they may negotiate whether to support the CDNI adaptation solution. Hence such optional arrangement will only bring benefit when both upstream and downstream agrees that at their appropriate situation. > > So, I sincerely suggest two Chairs and the whole group may allow some more days for this topic. I suggest after the Taipei meeting . > By then we all will get a clearer understanding and decision. > > Thanks. > Zhipeng > > > > From: Francois Le Faucheur [mailto:flefauch@cisco.com] > Sent: Friday, October 28, 2011 9:50 PM > To: ZhouZhipeng > Cc: cdni@ietf.org > Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-use-cases-00.txt > > 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's request, I like to show my information although perhaps not complete right now. > > 1) I have done some work to collect different company'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 : "Cisco urges mobile operators to add value to CDN services" http://www.totaltele.com/view.aspx?ID=468705 > Besides, I have checked many CDN company's websites. Many claim to support transcoding while some may not. > > 2) For the wording "content adaptation", 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...) 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. > From 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. > > 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. > > 3) As for the procedure of content adaptation, I just draft a diagram as below: > > > You may see the solution is rather clear and the metadata needed would be clear also. > > 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 > > > From: Woundy, Richard [mailto:Richard_Woundy@cable.comcast.com] > 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 > > >In your company's 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 ; Alan Kavanagh > Cc: 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'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 > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > From zahariad@synelixis.com Fri Nov 4 01:58: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 B19E021F8BE9 for ; Fri, 4 Nov 2011 01:58:19 -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=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 UCOBgbirSH3G for ; Fri, 4 Nov 2011 01:58:17 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [IPv6:2605:dc00:100:2::a2]) by ietfa.amsl.com (Postfix) with SMTP id 28C3921F8C10 for ; Fri, 4 Nov 2011 01:58:17 -0700 (PDT) Received: (qmail 13304 invoked by uid 0); 4 Nov 2011 08:58:16 -0000 Received: from unknown (HELO box521.bluehost.com) (74.220.219.121) by oproxy9.bluehost.com with SMTP; 4 Nov 2011 08:58:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=synelixis.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From:Reply-To; bh=eXSZrFq2QH+4D6GJWOInIrQ38xNrSdfWJJi9LAVSW8Q=; b=J3+0reSKpq+HNV8tYDaJXEX9iF9lqgkDC2rjwmLe6df6oOv4GTJMlUYSZgBDUgz4X9dAJuf/9EMzijb4lvPvjilJOCeIX9HNR88+3fW8giAZ8BQJYBf67phZGR3Wx9Xv; Received: from [195.130.64.9] (helo=acer) by box521.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RMFVo-0001su-S5; Fri, 04 Nov 2011 02:52:33 -0600 From: "Theodore Zahariadis" To: "'Francois Le Faucheur'" , 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> <005301cc97eb$90e09d90$b2a1d8b0$@com> <9410 9E9C-A6B3-4952-94C9-B4 CC2C127149@cisco.com> In-Reply-To: <94109E9C-A6B3-4952-94C9-B4CC2C127149@cisco.com> Date: Fri, 4 Nov 2011 10:52:13 +0200 Organization: Synelixis Solutions Ltd Message-ID: <00ab01cc9acf$1852a940$48f7fbc0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyaTr5vdk7ljPtMSXy0vGRY+gJwEgAfDUMg 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: 'Future Media Networks Cluster' , cdni@ietf.org Subject: Re: [CDNi] Advanced Use Cases 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: Fri, 04 Nov 2011 08:58:19 -0000 Dear Francois, Thanks for the reply. We basically fully agree on the proposed approach. The idea behind this draft was to provide a placeholder for CDNi use cases beyond the immediate goals of the current WG charter, but are actively being investigated by our ongoing research projects (some members of which are closely involved in the current WG drafts). While we don't want to detract from the immediate concerns of the WG, we welcome/encourage all comments and contributions to this catalogue, which can remain as a standard alone document. We'll also check how some of the advanced use case ideas, may feed directly into ietf-cdni-usecases and ietf-cdni-requirements, while others will remain as future work, which may provide useful hints as to where some options for protocol design, etc. might be left open. Personally I also believe that at least some issues (e.g. Caching-CDN interconnection) could be important even in the metadata specification draft. Best Regards, Theodore -----Original Message----- From: Francois Le Faucheur [mailto:flefauch@cisco.com] Sent: Thursday, November 03, 2011 7:33 PM To: draft-fmn-cdni-advanced-use-cases@tools.ietf.org Cc: cdni@ietf.org Subject: Advanced Use Cases Authors of draft-fmn-cdni-advanced-use-cases, (as a WG co-chair) The abstract of the document states: " 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. " Also, from looking at the I-D, it seems that some of these advanced use cases are indeed beyond the current scope of the working group: * e.g. "The first use case introduces a Caching-CDN interconnection that put emphasis on the in-the network caching mechanism." * e.g. Use case 2 for CDN-CDN interconnection at (very) large scale i.e. "there do exist non-linearities which do not occur at small to medium scale, but occur at large scale". "So this proposal aims at recommending that this "cdn-cdn interconnections at large scale" use case be considered in case of WG re-chartering (once the present goals will be reached). * e.g. Use Case 4: Dynamic expansion of CDN capacity and geographical reach : "The newly created resources are provided by the network provider but under the control of the CDN provider." * e.g. "Relationship between CDNI and Information-Centric Networking" Based on this, would it be an acceptable approach for you guys to: * keep progressing this document as a standalone document investigating uses cases beyond current scope, and * only potentially feed into ietf-cdni-usecases (and possibly ietf-cdni-requirements) the very specific subset of your document that relates to the current scope of the WG? Cheers Francois On 31 Oct 2011, at 17:38, Theodore Zahariadis wrote: > 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 > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Fri Nov 4 02:00: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 52F3621F8C2B for ; Fri, 4 Nov 2011 02:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.042 X-Spam-Level: X-Spam-Status: No, score=-7.042 tagged_above=-999 required=5 tests=[AWL=0.691, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-8, 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 3yE4w0cg9b3v for ; Fri, 4 Nov 2011 02:00:53 -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 B0FC221F8C15 for ; Fri, 4 Nov 2011 02:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=28366; q=dns/txt; s=iport; t=1320397251; x=1321606851; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fNkNOl/56Ae9sGfm5/EyJx2i4zEo2WO6buhYdGIHie8=; b=LjXeDmqyiqWSBcsHb47ADtmTjdNOMWEdY3Ja44BXAoX5Lw2+uSWRCAYC p38Rhai/a8UJdgCFoDvPjUtgcjBAtv4VqFlPIhxb3HTwciYb15lsyFSZk 4eJHzWKFaeVnARAv0TZI9r+yP6AR5/Lp0fnVfCpgvqoK3yuKqyWDIzJj4 Q=; X-IronPort-AV: E=Sophos;i="4.69,455,1315180800"; d="scan'208";a="59183193" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 04 Nov 2011 09:00:48 +0000 Received: from [144.254.53.252] ([144.254.53.252]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pA490lmr002462; Fri, 4 Nov 2011 09:00:48 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Francois Le Faucheur In-Reply-To: <00ab01cc9acf$1852a940$48f7fbc0$@com> Date: Fri, 4 Nov 2011 10:00:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8EC22774-E0F0-4C12-8054-36D8ED4DE8A3@cisco.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><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> <005301cc97eb$90e09d90$b2a1d8b0$@com> <9410 9E9C-A6B3-4952-94C9-B4 CC2C127149@cisco.com> <00ab01cc9acf$1852a940$48f7fbc0$@com> To: X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org, draft-fmn-cdni-advanced-use-cases@tools.ietf.org Subject: Re: [CDNi] Advanced Use Cases 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, 04 Nov 2011 09:00:55 -0000 On 4 Nov 2011, at 09:52, Theodore Zahariadis wrote: > Dear Francois, >=20 > Thanks for the reply. We basically fully agree on the proposed = approach. Great. So we have a plan.=20 Tx Francois >=20 > The idea behind this draft was to provide a placeholder for CDNi use = cases > beyond the immediate goals of the current WG charter, but are actively = being > investigated by our ongoing research projects (some members of which = are > closely involved in the current WG drafts).=20 >=20 > While we don't want to detract from the immediate concerns of the WG, = we > welcome/encourage all comments and contributions to this catalogue, = which > can remain as a standard alone document. >=20 > We'll also check how some of the advanced use case ideas, may feed = directly > into ietf-cdni-usecases and ietf-cdni-requirements, while others will = remain > as future work, which may provide useful hints as to where some = options=20 > for protocol design, etc. might be left open. >=20 > Personally I also believe that at least some issues (e.g. Caching-CDN > interconnection) could be important even in the metadata specification > draft. >=20 > Best Regards, > Theodore >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Francois Le Faucheur [mailto:flefauch@cisco.com]=20 > Sent: Thursday, November 03, 2011 7:33 PM > To: draft-fmn-cdni-advanced-use-cases@tools.ietf.org > Cc: cdni@ietf.org > Subject: Advanced Use Cases >=20 > Authors of draft-fmn-cdni-advanced-use-cases, >=20 > (as a WG co-chair) >=20 >=20 > The abstract of the document states: > " > 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.=20 > " >=20 > Also, from looking at the I-D, it seems that some of these advanced = use > cases are indeed beyond the current scope of the working group: > * e.g. "The first use case introduces a Caching-CDN = interconnection > that put emphasis on the in-the network caching mechanism."=20 > * e.g. Use case 2 for CDN-CDN interconnection at (very) large = scale > i.e. "there do exist non-linearities which do not occur at small to = medium > scale, > but occur at large scale". "So this proposal aims at recommending = that > this "cdn-cdn interconnections at large scale" use case be considered = in > case of WG re-chartering (once the present goals will be reached). > * e.g. Use Case 4: Dynamic expansion of CDN capacity and > geographical reach : "The newly created resources are provided by the > network provider but under the control of the CDN provider." > * e.g. "Relationship between CDNI and Information-Centric > Networking" > =09 > Based on this, would it be an acceptable approach for you guys to: > * keep progressing this document as a standalone document > investigating uses cases beyond current scope, and > * only potentially feed into ietf-cdni-usecases (and possibly > ietf-cdni-requirements) the very specific subset of your document that > relates to the current scope of the WG? >=20 > Cheers >=20 > Francois >=20 >=20 > On 31 Oct 2011, at 17:38, Theodore Zahariadis wrote: >=20 >> Dear Alan, >>=20 >> 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. >>=20 >> 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. >>=20 >> Best Regards, >> Theodore >>=20 >>=20 >>=20 >>=20 >> From: Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 >> 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 >>=20 >> Hi Theodore >>=20 >> 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). >>=20 >> Alan >>=20 >> From: Theodore Zahariadis [mailto:zahariad@synelixis.com]=20 >> 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 >>=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 >> Alan >>=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 >>=20 >> 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, >>=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 >> 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 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 >=20 From hexiaoyan@huawei.com Fri Nov 4 02: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 88E8921F8BE5 for ; Fri, 4 Nov 2011 02:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.993 X-Spam-Level: X-Spam-Status: No, score=-5.993 tagged_above=-999 required=5 tests=[AWL=0.606, 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 dYAIqeFkQ96R for ; Fri, 4 Nov 2011 02:12:02 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8CF21F8B7B for ; Fri, 4 Nov 2011 02:12:02 -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 <0LU400FHUPGYBN@szxga04-in.huawei.com> for cdni@ietf.org; Fri, 04 Nov 2011 17:10:10 +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 <0LU4003Y7PGX9D@szxga04-in.huawei.com> for cdni@ietf.org; Fri, 04 Nov 2011 17:10: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 AEW32315; Fri, 04 Nov 2011 17:09:55 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 17:09:47 +0800 Received: from w36710x (10.144.5.9) by smtpscn.huawei.com (10.82.67.93) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 04 Nov 2011 17:09:45 +0800 Date: Fri, 04 Nov 2011 17:09:43 +0800 From: HeXiaoyan In-reply-to: <843DA8228A1BA74CA31FB4E111A5C46201FE5171@ftrdmel0.rd.francetelecom.fr> X-Originating-IP: [10.144.5.9] To: emile.stephan@orange.com, ben@niven-jenkins.co.uk, bdavie@cisco.com Message-id: <01c601cc9ad1$7e69d850$7b3d88f0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-cn Content-transfer-encoding: quoted-printable Thread-index: AcyYqHUmKTVcvctXRhCTBy8VbBP49wAib9tQAGJJhEA= X-CFilter-Loop: Reflected References: <78BCE9D8-7C4F-4162-9F6B-867240993EE1@cisco.com> <1CA25301D2219F40B3AA37201F0EACD1136D0BEA@PACDCEXMB05.cable.comcast.com> <843DA8228A1BA74CA31FB4E111A5C46201FE4F05@ftrdmel0.rd.francetelecom.fr> <843DA8228A1BA74CA31FB4E111A5C46201FE5171@ftrdmel0.rd.francetelecom.fr> Cc: cdni@ietf.org Subject: Re: [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: Fri, 04 Nov 2011 09:12:03 -0000 Hi Stephan and Ben, Following your discussion on capability advertisement, here is my view, > > So it would seem to me a reasonable proposal to move the > > bootstrapping/capability elements currently nominally placed under > > "CDNI Control" to become part of the CDNI Metadata interface I did not find any explicit capability exchange requirement under the = CDNI Control interface except REQ-2 under the Request-Routing one, so are you proposing to move REQ-2 to CDNI Control/Metadata interface or anything else? In my understanding, bootstrapping of CDNI interfaces means getting some info necessary for CDNI startup and the info used for bootstrapping are usually static, as some of the capability info of a dCDN change = occasionally and need to be updated to the upCDN from time to time , e.g. = UsedDeliveryBW defined in section 4.2.1 of draft-xiaoyan-cdni-request-routing-protocol-00.txt, hence I don't think capability advertisement should be part of bootstrapping and it is not appropriate to put it under the Control interface. Putting capability advertisement function under the MI scope is not so appropriate either, the current definition of CDNI Metadata if pretty = clear, as Ben said, it is kind of content service configuration data, the MI is used to exchange such data, I don't understand why we need to mud up the concept of CDNI Metadata with a totally different type of data, = capability of a CDN. In practice CDN today, the service configuration interface and = the capability report interface are two different, keep consistent with that would be good. =20 >From above, keep the capability exchange function in Request Routing interface to facilitate request redirection as present or put it under another new introduced independent interface is preferred. =20 Thanks. Best Regards Xiaoyan(Susan) He > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf = Of > emile.stephan@orange.com > Sent: Wednesday, November 02, 2011 11:01 PM > To: ben@niven-jenkins.co.uk; bdavie@cisco.com > Cc: cdni@ietf.org > Subject: Re: [CDNi] Control and Metadata interfaces >=20 > Hi Ben and Bruce, >=20 > See inline >=20 > > -----Message d'origine----- > > De=A0: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > > Envoy=E9=A0: mardi 1 novembre 2011 16:11 > > =C0=A0: STEPHAN Emile RD-CORE-LAN > > Cc=A0: Richard_Woundy@cable.comcast.com; flefauch@cisco.com; > > cdni@ietf.org > > Objet=A0: Re: [CDNi] Control and Metadata interfaces > > > > Emile, Colleagues, > > > > On 31 Oct 2011, at 22:36, > > wrote: > > > 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; > > > > I agree that as we work through the CDNI solution components and how > > they fit together the exact functionality placed under each = interface > > needs to be firmed up compared to what we have currently in the = Problem > > Statement and Bruce's framework draft. >=20 >=20 > IMO, this is preventing to go in the detail of the works. Hence IMO we must > asap specify the bootstrapping and the information elements that must = be > exchanged during this step. >=20 > > > > I shared some thoughts with some folks offline about the CDNI = Control > > interface and the two functions of bootstrapping & control of > > content/metadata and where they might best fit in the context of = CDNI > > interfaces but as you bring it up here I'll repeat some of my = thoughts > > on the list. > > > > Bootstrapping/(fairly) static capability advertisement: >=20 > I share your approach but in draft-stephan-cdni-usecase-metadata we clearly > indentify that an object can be really static in a situation and = extremely > dynamic in another. This is why I promote that the control interface = and the > metadata interface share the same datamodeling framework and a subset = of > objects too. >=20 >=20 > > > > I tend to think that the CDNI Metadata is essentially (content = service > > level) configuration information and the CDNI Metadata interface is > > about distributing configuration between interconnected CDNs. > > > > In the case of bootstrapping of the CDNI interfaces and = communicating > > static (or fairly static) information about capabilities and = policies > > they can also (IMO) be thought of as essentially CDN/CDNI level > > configuration information. > > > > Although the current proposals for CDNI Metadata data models & > > interface specifications only address CDNI Metadata at present I = think > > it should be possible to build a data model for CDNI > > bootstrapping/capabilities that can reuse, for example, the = interface > > specification and encoding in proposed draft-jenkins-cdni-metadata. = New > > objects (and associated relationships & media types) would need to = be > > specified but that should be fairly straightforward and the base > > interface proposed could be reused for both content service > > configuration (aka CDNI Metadata) and CDN/CDNI configuration (aka > > bootstrapping/capabilities). > > > > So it would seem to me a reasonable proposal to move the > > bootstrapping/capability elements currently nominally placed under > > "CDNI Control" to become part of the CDNI Metadata interface > > > > > > Control of content: > > > > In the case of control of content although = draft-davie-cdni-framework- > > 01 puts forward the view that "a purge is equivalent to a statement > > that the availability window for that content has now expired" I = think > > the requirements placed on purging/invalidating/pre-positioning = content > > require functionality not covered by the current CDNI Metadata > > proposals. >=20 > I agree. CSP require explicit purge. This is an operation of control. >=20 > > > > In contrast to the distribution of CDNI Metadata which is a dCDN > > discovering (or being told) the content service level configuration = it > > needs, invalidating/purging content is the uCDN requesting the dCDN > > perform some task on its behalf (e.g. purge this item of actual > > content). > > > > A key factor that IMO separates purge/pre-position from CDNI = Metadata > > is the timing & feedback aspects. When a dCDN pulls CDNI Metadata = from > > a uCDN (or when a uCDN pushes CDNI Metadata into a dCDN) it's > > reasonable for the uCDN to assume the dCDN has some mechanism to > > distribute that so it is available to Surrogates when they require = it. > > In the case of push (via a HTTP POST for e.g.) the dCDN's response = of > > "201 Created" is saying "I got that metadata record and created a > > resource for it on the server you POSTed to" it says nothing about > > whether or not the Metadata was distributed to the rest of the = system > > (same for pull via GET except the acceptance by the dCDN is = implicit). > > > > In the case of purge/pre-position the uCDN will want explicit = feedback > > to know that the purge/pre-position "task" it has requested has been > > distributed within the dCDN and completed by the dCDN. The dCDN's = "201 > > Created" response would be saying "I got that request for purge and = I > > have created a resource [task] for it on the server you POSTed to". = If > > we're being RESTful the Location: header in the 201 response would = link > > to a resource that could be queried by the uCDN to check the = progress > > of the task. The nature of purge/pre-position requests means they = may > > take some time to complete and so trying to overload the meaning of = the > > 201 with "I got that task and I've completed it" doesn't seem = realistic > > to me. > > > > Therefore purge/invalidate/pre-position of actual content (as = opposed > > to CDNI Metadata) is in my mind a separate beast to distributing the > > actual CDNI Metadata and requires a different behaviour from the > > interface used to implement purge/invalidate/pre-position from that > > used to distribute CDNI Metadata. > > > > Whether we incorporate that different behaviour under the banner of = a > > "CDNI Control interface" or an extended/richer "CDNI Metadata > > interface" is to some extent semantics but I do think it needs > > something more than is required purely for the distribution of CDNI > > Metadata between interconnected CDNs. > > > > Ben > > >=20 > Here is my proposal refined: > - The framework document splits the control interface in 2 parts: > o bootstrapping of the CDN interconnection; > o control of the contents distribution; > - The control of the contents distribution and the Metadata = interface share > the same datamodeling framework (datamodel parts, protocols...); > - The framework document specifies precisely the bootstrapping (operations > and information elements) > - The framework document specifies the datamodeling framework; >=20 > Regards > Emile >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From gilles.bertrand@orange.com Mon Nov 7 02:20: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 82B7A21F8ADE for ; Mon, 7 Nov 2011 02:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 IHniEV956enF for ; Mon, 7 Nov 2011 02:20:14 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB9E21F8AD8 for ; Mon, 7 Nov 2011 02:20:14 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 20A298B800A; Mon, 7 Nov 2011 11:21:36 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 0AD718B8009; Mon, 7 Nov 2011 11:21:36 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 Nov 2011 11:20:13 +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_01CC9D36.D57FD874" Date: Mon, 7 Nov 2011 11:19:00 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-cdni-cases-00 Thread-Index: AcyadRRdhlXhbegIQbqsQJnwtuqUpACvZ/1Q References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> From: To: , , , , , X-OriginalArrivalTime: 07 Nov 2011 10:20:13.0070 (UTC) FILETIME=[D5FB1AE0:01CC9D36] Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 07 Nov 2011 10:20:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC9D36.D57FD874 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Alan, =20 Thanks for your review of the I-D. I added my answers in line. * Section 1.1. You mention Access CDN. Is this more an operator own and managed CDN in the Access Domain that may have access to end user information or are you talking about a given Access CDN having access to the end-users profile, im assuming its the former but felt its not clear in the draft.=20 I did not understand your question. Could you please rephrase? Thanks.=20 * Section 1.3. First bullet " improve the experience for the End User; for instance delivery has lower latency and better robustness". Suggest to add and reduce Round Trip Time as content is positioned closer to end user. By lower latency, we mean decrease the round trip time between the user and the delivery server.=20 * Section 1.3. Third bullet mentions reduced electricity consumption, could you expand on that and say how this is achieved? Popular content is delivered through the CDN rather than through the content provider's servers. Therefore, the content providers' infrastructure can be smaller (less servers etc). * Section 1.3. Suggest to add CSP-3 in Figure-1 to be consistent. To be consistent with what? * Section 1.4. I understand what you are conveying here, makes sense. I would however clarify that CDN's even external ones to interconnect with others today but use a Proprietary interface to do so etc. Do you know examples of production CDNs interconnected through proprietary interfaces today? * Section 2.3. Is their enough movement of nomadic users are moving to cache content in the first place?....im thinking here than you may be nomadic but also geo-blocked, believe that should be very clearly clarified. We will clarify this section in the next version of the I-D. * Section 3.1. "However, unexpected spikes in content popularity may drive load...." suggest to "flash crowds" after content popularity. ok * Section 3.1 Offloading. It should be noted that this use case would require knowledge about the other CDN to know if the other CDN has the resources to offload the requests in the first place and also if the content is available in the CDN being offloaded too. I agree: the CDN on which requests are offloaded must be able to handle the offloaded requests. This introduces requirements on the metadata (and control) interfaces. * Section 4.1. Im having difficulty in seeing how number 1 is a typical CDN use case of today? IMHO i dont not agree that its a typical model. We do not assert that it is a typical CDN use case today. It is rather one of the cases where CDNI would be useful.=20 * Section 10. Shouldn't it also cover a section on Authorization to view content and Authorization with Origin Server? Yes it would be interesting to mention these issues. We will extend this section in the next version of the I-D. Best regards, =20 Gilles =20 ------_=_NextPart_001_01CC9D36.D57FD874 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Alan,

 

Thanks for your review of the I-D. I added my answers in = line.

  • Section 1.1. = You mention Access CDN. Is this more an operator own and managed CDN in = the Access Domain that may have access to end user information or are = you talking about a given Access CDN having access to the end-users = profile, im assuming its the former but felt its not clear in the draft. =

I did not understand your question. Could you please rephrase? = Thanks.

  • Section 1.3. = First bullet " improve the experience for the End User; for = instance delivery has
          lower latency = and better robustness". Suggest to add and reduce Round Trip Time = as content is positioned closer to end = user.

By lower latency, we mean decrease the round trip time between the = user and the delivery server.

  • Section 1.3. = Third bullet mentions reduced electricity consumption, could you expand = on that and say how this is achieved?

Popular content is delivered through the CDN rather than through the = content provider's servers. Therefore, the content providers' = infrastructure can be smaller (less servers = etc).

  • Section 1.3. = Suggest to add CSP-3 in Figure-1 to be = consistent.

To be consistent with what?

  • Section 1.4. = I understand what you are conveying here, makes sense. I would however = clarify that CDN's even external ones to interconnect with others today = but use a Proprietary interface to do so = etc.

Do you know examples of production CDNs interconnected through = proprietary interfaces today?

  • Section 2.3. = Is their enough movement of nomadic users are moving to cache content in = the first place?....im thinking here than you may be nomadic but also = geo-blocked, believe that should be very clearly = clarified.

We will clarify this section in the next version of the = I-D.

  • Section 3.1. = "However, unexpected spikes in content popularity may drive = load...." suggest to "flash crowds" after content = popularity.

ok

  • Section 3.1 = Offloading. It should be noted that this use case would require = knowledge about the other CDN to know if the other CDN has the resources = to offload the requests in the first place and also if the content is = available in the CDN being offloaded too.

I agree: the CDN on which requests are offloaded must be able to = handle the offloaded requests. This introduces requirements on the = metadata (and control) interfaces.

  • Section 4.1. = Im having difficulty in seeing how number 1 is a typical CDN use case of = today? IMHO i dont not agree that its a typical = model.

We do not assert that it is a typical CDN use case today. It is = rather one of the cases where CDNI would be useful. =

  • Section 10. = Shouldn't it also cover a section on Authorization to view content and = Authorization with Origin Server?

Yes it would be interesting to mention these issues. We will extend = this section in the next version of the I-D.

Best regards,

 

Gilles

 

------_=_NextPart_001_01CC9D36.D57FD874-- From bdavie@cisco.com Mon Nov 7 15:02: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 B1F621F0C44 for ; Mon, 7 Nov 2011 15:02:56 -0800 (PST) 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 TX9u9-TDzbAL for ; Mon, 7 Nov 2011 15:02:56 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id F0E3E1F0C3E for ; Mon, 7 Nov 2011 15:02:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bdavie@cisco.com; l=17072; q=dns/txt; s=iport; t=1320706976; x=1321916576; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=e8Nb3JQBRZL3BFJtEEPgQo/0UjQlVSX2+hX50qLrNVQ=; b=ReXk8RkynmfbPXkTvTPkwzsSrvb6jKJAKcz4ylt9C7f8T+c/pzD8VSiP tJDoDNYjEKnPUUZHK/rjYnVEmlfAKkaQy4tbOxx6C3z21VtP/1om+jO/s 00rk1vcDk6UANuT+tmNw4DDjgTPdtO5BNKaPLYEpEhAxwbpMP9ZZbpgkq I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtYAAM1iuE6rRDoH/2dsb2JhbABDgk2XPo9qgQWBcgEBAQMBEgFfBQIFCwsRAwEBASgHRgkIBhMih2CZYwGeeohIYwSIC4wWhTGMWQ X-IronPort-AV: E=Sophos;i="4.69,472,1315180800"; d="scan'208,217";a="12833649" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 07 Nov 2011 23:02:55 +0000 Received: from [10.32.241.78] ([10.32.241.78]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA7N2stK001760; Mon, 7 Nov 2011 23:02:54 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-9-949878578 From: Bruce Davie In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B6A69188@MAILR002.mail.lan> Date: Mon, 7 Nov 2011 18:02:58 -0500 Message-Id: References: <20111031192301.18956.17387.idtracker@ietfa.amsl.com> <0031646E-1F32-4AAC-BF36-5C723B9141A1@cisco.com> <291CC3F9E50E7641901A54E85D0977C651B6A69188@MAILR002.mail.lan> To: Kevin J Ma X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" 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, 07 Nov 2011 23:02:56 -0000 --Apple-Mail-9-949878578 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Kevin, I guess the WG really needs to tackle a bunch of issues around what is = metadata and what is control, and when we can reach consensus on that, = we can decide if we need to change the requirements doc to reflect it. = But, yes, I would expect some changes in the requirements doc might = result if the purge & pre-position operations move as we suggest. Bruce On Oct 31, 2011, at 7:40 PM, Kevin J Ma wrote: > Hi Bruce, > =20 > 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? > =20 > thanx. > =20 > -- Kevin J. Ma > =20 > =20 > From: cdni-bounces@ietf.org [mailto:cdni-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 > =20 > I presented version -00 of this draft in Quebec City. Please post = comments to the list. > =20 > Regards, > Bruce Davie > =20 > =20 > Begin forwarded message: >=20 >=20 > 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 > =20 --Apple-Mail-9-949878578 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Kevin,
 I guess the WG really needs to = tackle a bunch of issues around what is metadata and what is control, = and when we can reach consensus on that, we can decide if we need to = change the requirements doc to reflect it. But, yes, I would expect some = changes in the requirements doc might result if the purge & = pre-position operations move as we = suggest.

Bruce


=
On Oct 31, 2011, at 7:40 PM, Kevin J Ma wrote:

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 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
 
I presented version -00 = of this draft in Quebec City. Please post comments to the = list.
Bruce = Davie
Begin forwarded = message:
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-frame= work
Revision:       01
Title:        &= nbsp;     Framework for CDN = Interconnection
Creation date:        &= nbsp;   2011-10-31
WG = ID:        &= nbsp;            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
; Wed, 9 Nov 2011 12:17:15 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Nov 2011 13:17:29 +0100 Message-Id: To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] Updated Agenda & Presentation Material 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, 09 Nov 2011 12:17:17 -0000 Folks, Rich & I posted an updated agenda with expected presenters and tentative = time allocation: http://www.ietf.org/proceedings/82/agenda/cdni.html Slides will be made accessible (as they are provided to us) from the = IETF Meeting Material page: https://datatracker.ietf.org/meeting/82/materials.html Notes to presenters: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Please send the chairs your slides by the end of the day Sunday Nov 13 = latest. This will ensure we have all slides uploaded in time.=20 Additional reminders (courtesy of Lou Berger): " - Allotted time includes setup/presentation *and* discussion. - Please allow sufficient time for discussion on any issues and = questions you have for the WG. Keep in mind that WG discussion and = feedback are the main reasons for presenting. - To maximize presentation time, the secretary/chairs will post all = slides prior to the session and present from a single laptop. Any file = or laptop swapping will come out of the presenters allotted time and is = not considered to be good use of the WG's time. " Francois= From flefauch@cisco.com Sat Nov 12 12:18: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 6CEF821F84DD for ; Sat, 12 Nov 2011 12:18:22 -0800 (PST) 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_31=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 HXx+PFIN6j31 for ; Sat, 12 Nov 2011 12:18:21 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 79A7D21F84DC for ; Sat, 12 Nov 2011 12:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=5395; q=dns/txt; s=iport; t=1321129101; x=1322338701; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=9HhdsnkE7Kg4bzSOvMNQugOZSt0TH1rPDQYm3D9pDHw=; b=NijFZ5RT7jovksWwLTiX62S1tiPoVRaGPdHjklwcYicUbIMEg/WiHa00 FH12vf+Ads7aucQTKKOi7/flVZBZncImxcNMGZerf/UnswfgRTxmDSm5w /E+BPEM/v0O6/hV6Q9zq2BN/KjraN3HyyDUm/stFsUcAlF3VR39spHSmy 0=; X-IronPort-AV: E=Sophos;i="4.69,500,1315180800"; d="scan'208";a="35370289" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-5.cisco.com with ESMTP; 12 Nov 2011 20:18:21 +0000 Received: from rtp-vpn5-960.cisco.com (rtp-vpn5-960.cisco.com [10.82.235.195]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id pACKIJYd032025; Sat, 12 Nov 2011 20:18:20 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Nov 2011 04:18:18 +0800 Message-Id: <778E7C62-393C-4C63-9763-D03BDFC7A7F9@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] comments on ietf-cdni-use-cases-00 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, 12 Nov 2011 20:18:22 -0000 Gilles et al, My individual's comments on latest version of use-cases. High level comments: ***) cost reduction/incremental revenue use cases for access network: I believe one fairly significant use case of CDNI is where: * an access provider carries to its subscribers a lot of content = coming from a 3rd party CSP and injected into the access network by an = Authoritative CDN provider=20 * the access provider wants to=20 (i) reduce the corresponding traffic load (eg by caching = instead of carrying the same content many times) (ii) influence/control the traffic ingestion points (iii) possibly derive some incremental revenue for = transport of that traffic The access provider may elect to use a CDN in his network and offer a = CDNI interconnection to the authoritative CDN. This allows the access = provider to perform caching in a managed way (in particular so it can = influence traffic acquisition paths, so that full visibility and control = is retained for the CSP, etc). I don't think that use case is really covered. It ends up being similar = to the Footprint extension usecase, but the footprint extension usecase = is described more from teh uCDN viewpoint whereas here I feel it is = useful to describe the use case from the dCDN/access provider viewpoint. ***) section 2, 3 and 4 are in good shape but I am still not comfortable = withs section 5. In particular, section 5 mixes delivery policies that are indeed = relevant to CDNs with "policies" that in my opinion pertain to some = service layer above the CDN and are irrelevant to CDNs. A good example of that issue would be "resolution-based constraints" of = 5.1 and of course the content encoding restrictions of 5.1.3. I don't = think we want the CDNs/CDNI to have to be aware about which user is = allowed to access which resolution , or which encoding is deliverable to = specific devices. These functional requirements can be better achieved = in my opinion by the Content Portal making decision of whether a request = is allowed based on any combination of any criteria and then only leave = it to the CDN to validate that the requst has been authorised (eg via = URI signing or token). Alos , I find that some text is way too specific and looks like a = Requirement (that shoudl be proposed to cdni-requirements) and not like = usecases. More specific comments: *) in abstract & introduction: " This document outlines real world use-cases (not technical solutions) = for interconnecting CDNs. ... This document describes a number of use cases that motivate CDN = Interconnection. " One of these two sentences seems redundant. * ) 1.1: " CDN peering: A business relation between two CDN providers based on one = or more CDN Interconnections. " This definition is not used anywhere (and "peering" brings a lot of = connotations), please remove that definition. *) 1.1 Some definitions ("aCDN", "Delivering CDN"...) seem generally useful. = Can you work with the authors of problem-statement and framework to = locate them in the relevant document. *) 1.3 Figure 1: * shows a CSP-2 attached to CDN-B but is not discussed * does not show CSP-3 attached to CDN-A that is discussed in the = text. Please align figure and text. *)1.3 paragraph above Fig 1. "When a User Agent that is connected to CDN Provider B=92s network = requests Content from CSP-1, the Content is actually delivered from = CDN-B" I think this is a little too specific description in this section that = is very generic. I suggest the text indicates that the request is served = by CDN-B because CDN-A feels that it will be better served by CDN-B, and = then only indicate that the reason to do so _may_, _for example_, be = becaue B is an access network and the user is directly attached to it. *) 3.2.1: " In partial failure scenarios, a CDN Provider could redirect some = requests towards another CDN, which must be able to serve the redirected = requests or, depending on traffic management policies, to forward these = requests to the CSP=92s origin server. " I can parse the last part of that sentence ("to forward these requests = to the CSP=92s origin server") in two ways: (a) another CDN which must be able to ...forward these requests = to the CSP=92s origin server (b) a CDN Provider could redirect some requests towards another = CDN ... or forward these requests to the CSP=92s origin server. Can you change text so it is unambiguous? If you meant (a) , that does not make sense to me. *) section 5: I suggest replacing title of "Policy Enforcement" by something more = precise like "Enforcement of Content Delivery Policy" *) section 5.1.3 I still believe this shoudl mostly be removed from the document. *) section 5.2: " There are situations where one CDN Provider cannot or does not want to = operate all the functions of a uCDN, e.g., a CDN exchange, which handles = request routing (and possibly log retrieval) but delegates all content = delivery to the surrogates of other dCDNs. " I don;t see the point of that text and how it relates to what is = discussed in section 5.2. I also have a whole series of editorial suggestions, that I'll pass = offline. Can we meet in Taipei to discuss these comments as well as how to deal = with section 5? Cheers Francois From ben@niven-jenkins.co.uk Sun Nov 13 18:21: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 7D63E1F0C53 for ; Sun, 13 Nov 2011 18:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 9lPARMr7ZU3F for ; Sun, 13 Nov 2011 18:21:12 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 304081F0C6E for ; Sun, 13 Nov 2011 18:21:12 -0800 (PST) Received: from dhcp-15fb.meeting.ietf.org ([130.129.21.251]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RPmAY-0005LL-0N; Mon, 14 Nov 2011 02:21:11 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <778E7C62-393C-4C63-9763-D03BDFC7A7F9@cisco.com> Date: Mon, 14 Nov 2011 02:21:05 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1C783FEC-98D0-4A44-9187-C51A8E6DDE2F@niven-jenkins.co.uk> References: <778E7C62-393C-4C63-9763-D03BDFC7A7F9@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] comments on ietf-cdni-use-cases-00 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, 14 Nov 2011 02:21:27 -0000 On 12 Nov 2011, at 20:18, Francois Le Faucheur wrote: > In particular, section 5 mixes delivery policies that are indeed = relevant to CDNs with "policies" that in my opinion pertain to some = service layer above the CDN and are irrelevant to CDNs. > A good example of that issue would be "resolution-based constraints" = of 5.1 and of course the content encoding restrictions of 5.1.3. I don't = think we want the CDNs/CDNI to have to be aware about which user is = allowed to access which resolution , or which encoding is deliverable to = specific devices. These functional requirements can be better achieved = in my opinion by the Content Portal making decision of whether a request = is allowed based on any combination of any criteria and then only leave = it to the CDN to validate that the requst has been authorised (eg via = URI signing or token). +1. The same can be said for the "temporal restrictions" which can be = achieved using a combination of the content portal and CDN data plane = functions (e.g. Expires/Cache-Control headers)=20 Ben From flefauch@cisco.com Sun Nov 13 19:09: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 DFFF11F0CB0 for ; Sun, 13 Nov 2011 19:09:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 O6LsPswFSOmz for ; Sun, 13 Nov 2011 19:09:04 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C7FC51F0CAD for ; Sun, 13 Nov 2011 19:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=12392; q=dns/txt; s=iport; t=1321240144; x=1322449744; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=XKSo8CcfqN8LP0XuWx/8Xb5P8H4EBbKuuk/OfpP6ETs=; b=Qkr4yf+380KrPrjJbLbNQjOh+3qWswpWEo0GLV9mSC3WcJjc/GUXrlEH OVxxzel7AkNmhkHoYa4v8Sts8vt41mPPS91i5eATiNdIoTyhr52MN69ec H7AvBYgqJ1OZtrkC87BT1ireXqudEG+n31uwjYZ0pWVeP9ioGSPobB1Yg o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJKFwE6tJXHB/2dsb2JhbABCgk2nL4EFgXIBAQEDAQEBAQ8BWwsFCwtGJzAGEwkSB4dgCJl4AZ09iRxjBIgOjCCSBg X-IronPort-AV: E=Sophos;i="4.69,505,1315180800"; d="scan'208,217";a="35587613" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2011 03:09:03 +0000 Received: from rtp-vpn3-1616.cisco.com (rtp-vpn3-1616.cisco.com [10.82.222.87]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAE391hd031842; Mon, 14 Nov 2011 03:09:02 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-49--664445430 From: Francois Le Faucheur In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE1D90ED8E@DAPHNIS.office.hd> Date: Mon, 14 Nov 2011 11:08:58 +0800 Message-Id: <2586E43D-9C06-4656-A848-35E20CF74015@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE1D90ED8E@DAPHNIS.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [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: Mon, 14 Nov 2011 03:09:05 -0000 --Apple-Mail-49--664445430 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hello Jan, (as an individual) I understand that your document : (i) discusses how ALTO could be used to effectively allow = selection of dCDN Surrogate directly by the uCDN request router, AND (ii) mentions that ALTO could potentially be used to facilitate = dCDN selection by uCDN. Regarding (i), it is not clear to me that allow selection of dCDN = Surrogate directly by the uCDN request router is a desirable goal = considering the combination of the following: (a) the Working Group has agreed that the solution should not = rely on dCDN exposing too much "internal" information:=20 " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. " (b) in general, selection of dCDN Surrogate is likely to depend = on a number of criteria, including criteria beyond network proximity = information (e.g. Surrogate cache/resource/status considerations), do I = don't think that exposing dCDN proximity information to uCDN would be = sufficient. In fact, I see that you have noticed that point since your = draft does mention: "An implicit assumption for the example in Figure 1 to work is that the = CDN entry point for the downstream CDN only depends on the location of = the end user." Regarding (ii), I believe facilitating dCDN selection by uCDN is indeed = a strong goal, but the draft does not yet discuss details of how ALTO = could be used there. Cheers Francois On 19 Oct 2011, at 23:52, Jan Seedorf wrote: > CDNi folks, ALTO folks, > =20 > I have just submitted a new draft which discusses how ALTO could help = in CDNi request routing: > =20 > Abstract: > =93=85 This document focusses on the Request Routing Interface of = CDNi, and more specifically on how the solutions currently being defined = in the Application 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 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.=94 > =20 > http://www.ietf.org/id/draft-seedorf-alto-for-cdni-00.txt > =20 > Comments (from CDNi WG and ALTO WG) are welcome, > =20 > - Jan > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-49--664445430 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hello Jan,

(as an = individual)

I understand that your document = :
= (i) discusses how ALTO could be used to effectively allow = selection of dCDN Surrogate directly by the uCDN request router, = AND
= (ii) mentions that ALTO could potentially be used to facilitate = dCDN selection by uCDN.

Regarding (i), it is = not clear to me that allow selection of dCDN Surrogate directly by the = uCDN request router is a desirable goal considering the combination of = the following:
(a) the Working Group has agreed = that the solution should not rely on dCDN exposing too much "internal" = information: 
"
GEN-4 =   [HIGH] The CDNI solution shall not require intra-CDN
  =          information to be exposed to other = CDNs for effective and
          =  efficient delivery of the content.  Examples of = intra-CDN
           information = include surrogate topology, surrogate status,
      =      cached content, etc.
= "
(b) in general, selection of dCDN = Surrogate is likely to depend on a number of criteria, including = criteria beyond network proximity information (e.g. Surrogate = cache/resource/status considerations), do I don't think that exposing = dCDN proximity information to uCDN would be sufficient. In fact, I see = that you have noticed that point since your draft does = mention:
"An implicit assumption for the example in Figure 1 = to work is that the CDN entry point for the downstream CDN only depends = on the location of the end = user."


Regarding (ii), I = believe facilitating dCDN selection by uCDN is indeed a strong = goal, but the draft does not yet discuss details of how ALTO could be = used = there.

Cheers

Francois





<= div>On 19 Oct 2011, at 23:52, Jan Seedorf wrote:

CDNi folks, = ALTO folks,
I have just = submitted a new draft which discusses how ALTO could help in CDNi = request routing:
=93=85 This = document focusses on the Request Routing Interface of CDNi, and more = specifically on how the solutions currently being defined in the = Application 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 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.=94

= --Apple-Mail-49--664445430-- From Jan.Seedorf@neclab.eu Sun Nov 13 22:33: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 15D4311E81ED for ; Sun, 13 Nov 2011 22:33:56 -0800 (PST) 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 wZyW5rOgQDaY for ; Sun, 13 Nov 2011 22:33:52 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2701411E8094 for ; Sun, 13 Nov 2011 22:33:50 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2B31928000086; Mon, 14 Nov 2011 07:33:43 +0100 (CET) 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 6rGxRnUH3V05; Mon, 14 Nov 2011 07:33:43 +0100 (CET) Received: from ENCELADUS.office.hd (ENCELADUS.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id F21FB28000080; Mon, 14 Nov 2011 07:33:32 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 07:33:12 +0100 From: Jan Seedorf To: Francois Le Faucheur Thread-Topic: [CDNi] Draft submitted on ALTO for CDNi request routing Thread-Index: AcyOdsKTya0HC6UWS0CBvXWXbwsQkgT+5vIAAAifzuA= Date: Mon, 14 Nov 2011 06:33:11 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE24E80085@Polydeuces.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE1D90ED8E@DAPHNIS.office.hd> <2586E43D-9C06-4656-A848-35E20CF74015@cisco.com> In-Reply-To: <2586E43D-9C06-4656-A848-35E20CF74015@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: multipart/alternative; boundary="_000_2779C9F0771F974CAD742BAE6D9904FE24E80085Polydeucesoffic_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [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: Mon, 14 Nov 2011 06:33:56 -0000 --_000_2779C9F0771F974CAD742BAE6D9904FE24E80085Polydeucesoffic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Francois, Thanks for your comments on the draft. Please find my answers below inline: Regarding (i), it is not clear to me that allow selection of dCDN Surrogate= directly by the uCDN request router is a desirable goal considering the co= mbination of the following: (a) the Working Group has agreed that the solution should n= ot rely on dCDN exposing too much "internal" information: " GEN-4 [HIGH] The CDNI solution shall not require intra-CD= N information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. " Jan: Actually, ALTO is designed in a way that leaves the degree of detail b= eing disclosed through ALTO information at the ALTO server's (i.e. in this = case at the dCDN's) discretion. To be concrete, ALTO is exactly a way to re= commend a surrogate without disclosing the interior topology of the dCDN. (b) in general, selection of dCDN Surrogate is likely to de= pend on a number of criteria, including criteria beyond network proximity i= nformation (e.g. Surrogate cache/resource/status considerations), do I don'= t think that exposing dCDN proximity information to uCDN would be sufficien= t. In fact, I see that you have noticed that point since your draft does me= ntion: "An implicit assumption for the example in Figure 1 to work is that the CDN= entry point for the downstream CDN only depends on the location of the end= user." Jan: Maybe I should clarify (I think it says somehow in the draft as well) = that the draft does not propose to have ALTO as the CDNi request routing it= self, but rather that ALTO can be a part of it. Having said that, I think t= hat the data contained in an ALTO cost map could be a combination of proxim= ity/status/other criteria, again being combined totally at the dCDNs discre= tion and without disclosing these details to the uCDN. The ALTO cost value = would just be a means to signal to the uCDN which surrogate is preferred fr= om the dCDNs perspective. Regarding (ii), I believe facilitating dCDN selection by uCDN is indeed a s= trong goal, but the draft does not yet discuss details of how ALTO could be= used there. Jan: indeed, this needs to be detailed in future versions of the draft. One= example would be that ALTO maps from several candidate dCDNs could provide= information to the uCDN of the footprint of these dCDNs or how close to th= e end user each dCDN can offer a surrogate. But such use cases need to be t= hought through a bit more. I hope my answers clarified a bit, especially that ALTO information can be = used in a way that it does not disclose (too many) details of the network t= opology. - Jan From: Francois Le Faucheur [mailto:flefauch@cisco.com] Sent: Monday, November 14, 2011 11:09 AM To: Jan Seedorf Cc: cdni@ietf.org Subject: Re: [CDNi] Draft submitted on ALTO for CDNi request routing Hello Jan, (as an individual) I understand that your document : (i) discusses how ALTO could be used to effectively allow selecti= on of dCDN Surrogate directly by the uCDN request router, AND (ii) mentions that ALTO could potentially be used to facilitate d= CDN selection by uCDN. Regarding (i), it is not clear to me that allow selection of dCDN Surrogate= directly by the uCDN request router is a desirable goal considering the co= mbination of the following: (a) the Working Group has agreed that the solution should not rel= y on dCDN exposing too much "internal" information: " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information to be exposed to other CDNs for effective and efficient delivery of the content. Examples of intra-CDN information include surrogate topology, surrogate status, cached content, etc. " (b) in general, selection of dCDN Surrogate is likely to depend o= n a number of criteria, including criteria beyond network proximity informa= tion (e.g. Surrogate cache/resource/status considerations), do I don't thin= k that exposing dCDN proximity information to uCDN would be sufficient. In = fact, I see that you have noticed that point since your draft does mention: "An implicit assumption for the example in Figure 1 to work is that the CDN= entry point for the downstream CDN only depends on the location of the end= user." Regarding (ii), I believe facilitating dCDN selection by uCDN is indeed a s= trong goal, but the draft does not yet discuss details of how ALTO could be= used there. Cheers Francois On 19 Oct 2011, at 23:52, Jan Seedorf wrote: 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 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_2779C9F0771F974CAD742BAE6D9904FE24E80085Polydeucesoffic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --_000_2779C9F0771F974CAD742BAE6D9904FE24E80085Polydeucesoffic_-- From zhouzhipeng@huawei.com Sun Nov 13 23:11: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 AB74D11E80AA for ; Sun, 13 Nov 2011 23:11:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 CSm0lZkX9wrL for ; Sun, 13 Nov 2011 23:11:00 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 943EA21F8CCF for ; Sun, 13 Nov 2011 23:10:59 -0800 (PST) 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 <0LUN00HWK2GY3N@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 14 Nov 2011 15:07:46 +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 <0LUN00GBJ2GXDP@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 14 Nov 2011 15:07:46 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA44121; Mon, 14 Nov 2011 15:07:07 +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.323.3; Mon, 14 Nov 2011 15:07:04 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.4]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 15:06:56 +0800 Date: Mon, 14 Nov 2011 07:06:54 +0000 From: ZhouZhipeng In-reply-to: <778E7C62-393C-4C63-9763-D03BDFC7A7F9@cisco.com> X-Originating-IP: [10.138.73.38] To: Francois Le Faucheur , "cdni@ietf.org" Message-id: <260A32EFD5C9EB47AD504929D005DF6217F817FE@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] comments on ietf-cdni-use-cases-00 Thread-index: AQHMoj7zaB/KmJHpUke32aBlAEUjuJWr7VlQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <778E7C62-393C-4C63-9763-D03BDFC7A7F9@cisco.com> Subject: Re: [CDNi] comments on ietf-cdni-use-cases-00 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, 14 Nov 2011 07:11:07 -0000 Hi Francois, Just a high level comment on your sentence: "from the dCDN/access provider viewpoint." I feel the CDN or CDNi is based on the viewpoint of the whole system to evaluate the benefit from implementing the caching system, not on part of the system. E.g. it may reduce the system cost(end to end) via CDN comparing with the system without CDN. If we consider CP as the consumer of CDNs and CDNs as the consumer of access provider, the description on "CDN to CDN" is clear to address the whole system. Generally , CDN is a layer over access network. Hence "CDN may reduce the traffic load" is equal to "CDN may reduce the access network's load" . Just my two cents for reference. Zhipeng -----Original Message----- From: Francois Le Faucheur [mailto:flefauch@cisco.com] Sent: Sunday, November 13, 2011 4:18 AM To: cdni@ietf.org Subject: [CDNi] comments on ietf-cdni-use-cases-00 Gilles et al, My individual's comments on latest version of use-cases. High level comments: ***) cost reduction/incremental revenue use cases for access network: I believe one fairly significant use case of CDNI is where: * an access provider carries to its subscribers a lot of content coming from a 3rd party CSP and injected into the access network by an Authoritative CDN provider * the access provider wants to (i) reduce the corresponding traffic load (eg by caching instead of carrying the same content many times) (ii) influence/control the traffic ingestion points (iii) possibly derive some incremental revenue for transport of that traffic The access provider may elect to use a CDN in his network and offer a CDNI interconnection to the authoritative CDN. This allows the access provider to perform caching in a managed way (in particular so it can influence traffic acquisition paths, so that full visibility and control is retained for the CSP, etc). I don't think that use case is really covered. It ends up being similar to the Footprint extension usecase, but the footprint extension usecase is described more from teh uCDN viewpoint whereas here I feel it is useful to describe the use case from the dCDN/access provider viewpoint. ***) section 2, 3 and 4 are in good shape but I am still not comfortable withs section 5. In particular, section 5 mixes delivery policies that are indeed relevant to CDNs with "policies" that in my opinion pertain to some service layer above the CDN and are irrelevant to CDNs. A good example of that issue would be "resolution-based constraints" of 5.1 and of course the content encoding restrictions of 5.1.3. I don't think we want the CDNs/CDNI to have to be aware about which user is allowed to access which resolution , or which encoding is deliverable to specific devices. These functional requirements can be better achieved in my opinion by the Content Portal making decision of whether a request is allowed based on any combination of any criteria and then only leave it to the CDN to validate that the requst has been authorised (eg via URI signing or token). Alos , I find that some text is way too specific and looks like a Requirement (that shoudl be proposed to cdni-requirements) and not like usecases. More specific comments: *) in abstract & introduction: " This document outlines real world use-cases (not technical solutions) for interconnecting CDNs. ... This document describes a number of use cases that motivate CDN Interconnection. " One of these two sentences seems redundant. * ) 1.1: " CDN peering: A business relation between two CDN providers based on one or more CDN Interconnections. " This definition is not used anywhere (and "peering" brings a lot of connotations), please remove that definition. *) 1.1 Some definitions ("aCDN", "Delivering CDN"...) seem generally useful. Can you work with the authors of problem-statement and framework to locate them in the relevant document. *) 1.3 Figure 1: * shows a CSP-2 attached to CDN-B but is not discussed * does not show CSP-3 attached to CDN-A that is discussed in the text. Please align figure and text. *)1.3 paragraph above Fig 1. "When a User Agent that is connected to CDN Provider B's network requests Content from CSP-1, the Content is actually delivered from CDN-B" I think this is a little too specific description in this section that is very generic. I suggest the text indicates that the request is served by CDN-B because CDN-A feels that it will be better served by CDN-B, and then only indicate that the reason to do so _may_, _for example_, be becaue B is an access network and the user is directly attached to it. *) 3.2.1: " In partial failure scenarios, a CDN Provider could redirect some requests towards another CDN, which must be able to serve the redirected requests or, depending on traffic management policies, to forward these requests to the CSP's origin server. " I can parse the last part of that sentence ("to forward these requests to the CSP's origin server") in two ways: (a) another CDN which must be able to ...forward these requests to the CSP's origin server (b) a CDN Provider could redirect some requests towards another CDN ... or forward these requests to the CSP's origin server. Can you change text so it is unambiguous? If you meant (a) , that does not make sense to me. *) section 5: I suggest replacing title of "Policy Enforcement" by something more precise like "Enforcement of Content Delivery Policy" *) section 5.1.3 I still believe this shoudl mostly be removed from the document. *) section 5.2: " There are situations where one CDN Provider cannot or does not want to operate all the functions of a uCDN, e.g., a CDN exchange, which handles request routing (and possibly log retrieval) but delegates all content delivery to the surrogates of other dCDNs. " I don;t see the point of that text and how it relates to what is discussed in section 5.2. I also have a whole series of editorial suggestions, that I'll pass offline. Can we meet in Taipei to discuss these comments as well as how to deal with section 5? Cheers Francois From zhouzhipeng@huawei.com Mon Nov 14 01:09: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 8183721F8F34 for ; Mon, 14 Nov 2011 01:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.857 X-Spam-Level: X-Spam-Status: No, score=-5.857 tagged_above=-999 required=5 tests=[AWL=0.742, 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 reW2d4Oq9K3l for ; Mon, 14 Nov 2011 01:09:29 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 54D7021F8F21 for ; Mon, 14 Nov 2011 01:09:29 -0800 (PST) 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 <0LUN00G6T7ZEPC@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 14 Nov 2011 17:06:51 +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 <0LUN005KT7XORC@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 14 Nov 2011 17:06:50 +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 AEZ02925; Mon, 14 Nov 2011 17:06:50 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 17:06:47 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.4]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 17:06:41 +0800 Date: Mon, 14 Nov 2011 09:06:39 +0000 From: ZhouZhipeng In-reply-to: <1C783FEC-98D0-4A44-9187-C51A8E6DDE2F@niven-jenkins.co.uk> X-Originating-IP: [10.138.73.38] To: Ben Niven-Jenkins , Francois Le Faucheur Message-id: <260A32EFD5C9EB47AD504929D005DF6217F8188E@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] comments on ietf-cdni-use-cases-00 Thread-index: AQHMopdoaB/KmJHpUke32aBlAEUjuJWsEpXg X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <778E7C62-393C-4C63-9763-D03BDFC7A7F9@cisco.com> <1C783FEC-98D0-4A44-9187-C51A8E6DDE2F@niven-jenkins.co.uk> Cc: "cdni@ietf.org" Subject: Re: [CDNi] comments on ietf-cdni-use-cases-00 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, 14 Nov 2011 09:09:30 -0000 Hi Ben and Francois, Besides what I have explained for the bandwidth efficiency on this use case, I have a scenario to the portal issue : if the content has three optional formats and 3 optional stream rates, hence total 9 options, how the portal may be nice to display all these options on each content item. Second, do we wish the normal user to be so clear on the technical details when they consume the content. Thanks. Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Monday, November 14, 2011 10:21 AM To: Francois Le Faucheur Cc: cdni@ietf.org Subject: Re: [CDNi] comments on ietf-cdni-use-cases-00 On 12 Nov 2011, at 20:18, Francois Le Faucheur wrote: > In particular, section 5 mixes delivery policies that are indeed relevant to CDNs with "policies" that in my opinion pertain to some service layer above the CDN and are irrelevant to CDNs. > A good example of that issue would be "resolution-based constraints" of 5.1 and of course the content encoding restrictions of 5.1.3. I don't think we want the CDNs/CDNI to have to be aware about which user is allowed to access which resolution , or which encoding is deliverable to specific devices. These functional requirements can be better achieved in my opinion by the Content Portal making decision of whether a request is allowed based on any combination of any criteria and then only leave it to the CDN to validate that the requst has been authorised (eg via URI signing or token). +1. The same can be said for the "temporal restrictions" which can be achieved using a combination of the content portal and CDN data plane functions (e.g. Expires/Cache-Control headers) Ben From zhouzhipeng@huawei.com Mon Nov 14 01:40: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 3349421F8D98 for ; Mon, 14 Nov 2011 01:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.894 X-Spam-Level: X-Spam-Status: No, score=-5.894 tagged_above=-999 required=5 tests=[AWL=0.705, 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 2h7iY7PpXj31 for ; Mon, 14 Nov 2011 01:40:54 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 51EFC21F8F31 for ; Mon, 14 Nov 2011 01:40:22 -0800 (PST) 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 <0LUN00GLL922V8@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 14 Nov 2011 17:30: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 <0LUN003409225N@szxga04-in.huawei.com> for cdni@ietf.org; Mon, 14 Nov 2011 17:30:02 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA60325; Mon, 14 Nov 2011 17:30:02 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 14 Nov 2011 17:30:00 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.4]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0323.003; Mon, 14 Nov 2011 17:29:50 +0800 Date: Mon, 14 Nov 2011 09:29:49 +0000 From: ZhouZhipeng X-Originating-IP: [10.138.73.38] To: "cdni@ietf.org" Message-id: <260A32EFD5C9EB47AD504929D005DF6217F818CE@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-index: Acyggdmu2OVJc6xEQgGld0hk/yeqHwCLdryA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BF6p BzZC BzhK B15q DcRB FUO2 GELL Hk6i Hp2o IZtc I8bh JGHG JVRY Jd0H Kr6l LAf3; 1; YwBkAG4AaQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {EE0FE79D-3ECC-4461-8AB6-0AE944F2F224}; egBoAG8AdQB6AGgAaQBwAGUAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Mon, 14 Nov 2011 09:29:47 GMT;RgBZAEkAOgA= x-cr-puzzleid: {EE0FE79D-3ECC-4461-8AB6-0AE944F2F224} X-CFilter-Loop: Reflected Subject: [CDNi] FYI: 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, 14 Nov 2011 09:40:58 -0000 -----Original Message----- From: owner-iif-arch@lists.atis.org [mailto:owner-iif-arch@lists.atis.org] = On Behalf Of Michael A Dolan Sent: Friday, November 11, 2011 10:55 PM To: iif-arch@lists.atis.org Subject: [IIF-ARCH] FW: Streaming Media Magazine: DASH uses CFF FYI MPEG DASH: The File Format of the Future? - Streaming Media Magazine "If HLS were perfect, DASH would not exist," said Thierry Fautier, Harmonic's senior director of telco solutions, referring to Apple's proprietary HTTP Live Streaming (HLS) protocol and the newer MPEG-backed Dynamic Adaptive Streaming over HTTP (MPEG DASH) standard specification. =A0 "What Apple has introduced to IETF (Internet Engineering Task Force) is merely an informational draft," added another panelist on the five-person panel. "We don't see that they're necessarily planning to push HLS as a tru= e internet standard." =A0 The MPEG DASH panel, led by Microsoft's Iraj Sodagar, who has chaired the MPEG subcommittee on DASH for the past year, was a hot ticket at the 2011 Streaming Media West show, held this week at the Hyatt Regency Century Plaz= a in Los Angeles. A standing-room only crowd listened to representatives from a number of companies that are on the MPEG-DASH promoters' group. =A0 "More than 50 companies and 90 experts have contributed to the MPEG-DASH specification," said Sodagar during his introductory remarks, "including Apple, Adobe, and all the companies represented here today. The proposed first-step of MPEG-DASH is on the verge of completion, and we feel we took best of best practices and incorporated them into the standard." =A0 "The growth of video over mobile networks is exponential, from a Qualcomm perspective," said Mike Luby, Qualcomm's vice president of technology. "As such we see getting standardization around video as very important and we participated heavily in the standards committee to make sure there was an adaptive-optimized common format that can be delivered via standard web servers, using common encryption." =A0 The common file format (CFF) that Luby refers to is based on the UltraViole= t CFF that the Digital Entertainment Content Ecosystem (DECE) published along with a Common Encryption (CENC) scheme that uses five distinct digital rights management (DRM) schemes in an interoperable manner. =A0 "We also see a value in unmuxed audio and video," added Luby, using an example of non-multiplexed elementary audio streams in a variety of languages for an "online DVD" equivalent as an example. "Above all, we welcome the chance to use a modern file format all delivered in an open standard." =A0 Will Law, Akamai's principal architect for media engineering, offered his perspective from a content delivery network (CDN) perspective. =A0 "We're pushing 8.5 terabits today," said Law, referring to a recent peak record that Akamai set for simultaneous CDN content delivery. =A0 "We've spent the past five years delivering a variety of adaptive video formats-SmoothHD, HDNI, HLS and HDS-all of which are 80 percent the same bu= t 100 percent incompatible," said Law. =A0 "We need to use HTTP to keep up with the demand curve for video on the web, but we can't do it with proprietary servers, since that means splitting our resources into three parts and trying to deliver equally to all three parts," he added. "What we really need to do is use all our edge cache servers for one standard, so that we and our users can focus on content and marketing rather than replicating the same thing three times for three separate streaming server solutions." =A0 Asked by an audience member about the benefit of an HTTP solution, using standard HTTP servers, for Akamai as a CDN, Law said he felt Akamai's intelligent cloud could do some interesting things at the edge of DASH that standard HTTP servers cannot do. =A0 A representative from Netflix, senior engineer Mark Watson, said that MPEG-DASH was a natural extension of what his company is already doing to deliver fragmented MPEG-4 video via HTTP to a large number of streaming customers. =A0 "We're already using these file formats, and we see huge cache efficiencies of a single file format," said Watson. "We feel we can lower CDN costs by using a standard web but we also see the DRM agnosticism of MPEG-DASH acros= s multiple consumer electronics devices using Common Encryption (CENC) will benefit premium content owners whose content we deliver. =A0 Watson also alluded to the online DVD equivalent, thanks in part to the use of elementary streams (those not multiplexed together like Apple's proprietary HLS protocol). =A0 "We see unmuxed audio and video elementary streams as a way to effortlessly allow multi-language experiences," said Watson, "mimicking the offline multi-audio DVD experience. In doing so, we see a huge benefit to having an open standard that's a collaboration of a number of companies in the streaming space." =A0 Ericsson's David Price, vice president of business development for the company's compression business, said consumer behavior and a move to mobile devices is driving the need for a common standard. =A0 "Changes in consumer behavior that are driving the need for MPEG-DASH, at least according to our consumersurveys where we interview people from 40 countries," said Price. "We saw a need for a common delivery solution when we started into 3GPP unicastyears ago, and those learnings form much of the basis of MPEG-DASH, along with technology contributions from other companie= s on this panel." =A0 "We also see a need to make money in the ecosystem," added Price. "Ericsson sees there's a need for content management systems, third-party billing and back-office solutions. We all agree on the efficacy of the standard for delivery and to create a robust ecosystem." =A0 Panelists were asked about the expected timeframe for DASH-compliant players, and Price stressed interoperability is key. =A0 "Even though we don't know where the tipping point will be for DASH, as HLS is widespread," said Price, "we think that the time spent on the commonalit= y of MPEG-DASH will be time well spent. Everyone at this table wants to promote interoperability. =A0 Harmonic's Fautier said it's about the need to move to television-sized audiences. =A0 "We've been successful with our ProMedia transcoding products," said Fautier, "but we feel that there's a need for a standard to be able to scal= e adaptive streaming to a TV-sized audience. To that end, all our ProMedia solutions are software upgradable to MPEG-DASH using a special software license." =A0 Fautier also said that, in connected TV space in Europe, there's a move to go to MPEG-DASH. =A0 "We expect to see a common file format with common encryption beginning in 2012," said Fautier, "perhaps using Marlin, one of the five DRM schemes, as a standard. France and Spain will be implementing first." From flefauch@cisco.com Mon Nov 14 09:03: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 CB1261F0CC1 for ; Mon, 14 Nov 2011 09:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=-0.560, 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 WKnwzuM6g9kx for ; Mon, 14 Nov 2011 09:03:54 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB201F0CC0 for ; Mon, 14 Nov 2011 09:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=73136; q=dns/txt; s=iport; t=1321290233; x=1322499833; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=12YcSlXaqrzwjclKSXsEsMD9H9R1lSqm94efR01tlAk=; b=lqh1XOJOPdWiINBXH8Zw5UQ9DkAGLDVDvDQA6gEKWMTOFSh6KyTdAzjB fJdpljkpvgIW+rTfFZ7yjyHMo7zNemxK6y1zZhRfU4b0daG2XHpiKL6GY 13J5TVd+FmvfZgikv8Ebs/8Pn7f5SnULWBxKDgmLvCsIAPrKrCr1aZ+iD U=; X-Files: image001.jpg, green.gif : 11041, 87 X-IronPort-AV: E=Sophos;i="4.69,510,1315180800"; d="gif'147?jpg'147,145?scan'147,145,208,145,147,217";a="35823651" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 14 Nov 2011 17:03:53 +0000 Received: from rtp-vpn6-1977.cisco.com (rtp-vpn6-1977.cisco.com [10.82.255.192]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAEH3o6E032283; Mon, 14 Nov 2011 17:03:51 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-126--614356940 From: Francois Le Faucheur In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE24E80085@Polydeuces.office.hd> Date: Tue, 15 Nov 2011 01:03:46 +0800 Message-Id: <2C1F3DA5-AEBC-450F-A3D3-E489F79D1FCC@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE1D90ED8E@DAPHNIS.office.hd> <2586E43D-9C06-4656-A848-35E20CF74015@cisco.com> <2779C9F0771F974CAD742BAE6D9904FE24E80085@Polydeuces.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [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: Mon, 14 Nov 2011 17:03:55 -0000 --Apple-Mail-126--614356940 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 14 Nov 2011, at 14:33, Jan Seedorf wrote: > Dear Francois, > =20 > Thanks for your comments on the draft. Please find my answers below = inline: > =20 > Regarding (i), it is not clear to me that allow selection of dCDN = Surrogate directly by the uCDN request router is a desirable goal = considering the combination of the following: > (a) the Working Group has agreed that the solution = should not rely on dCDN exposing too much "internal" information: > " > GEN-4 [HIGH] The CDNI solution shall not require = intra-CDN > information to be exposed to other CDNs for effective and > efficient delivery of the content. Examples of intra-CDN > information include surrogate topology, surrogate status, > cached content, etc. > " > Jan: Actually, ALTO is designed in a way that leaves the degree of = detail being disclosed through ALTO information at the ALTO server=92s = (i.e. in this case at the dCDN=92s) discretion. To be concrete, ALTO is = exactly a way to recommend a surrogate without disclosing the interior = topology of the dCDN. > =20 > (b) in general, selection of dCDN Surrogate is likely = to depend on a number of criteria, including criteria beyond network = proximity information (e.g. Surrogate cache/resource/status = considerations), do I don't think that exposing dCDN proximity = information to uCDN would be sufficient. In fact, I see that you have = noticed that point since your draft does mention: > "An implicit assumption for the example in Figure 1 to work is that = the CDN entry point for the downstream CDN only depends on the location = of the end user." > =20 > Jan: Maybe I should clarify (I think it says somehow in the draft as = well) that the draft does not propose to have ALTO as the CDNi request = routing itself, > but rather that ALTO can be a part of it. > Having said that, I think that the data contained in an ALTO cost map = could be a combination of proximity/status/other criteria, again being = combined totally at the dCDNs discretion and without disclosing these = details to the uCDN. The ALTO cost value would just be a means to signal = to the uCDN which surrogate is preferred from the dCDNs perspective. Let's say for argument sake that the dCDN wants to select a surrogate = taking into account 3 metrics: * Metric-1 that depends on enduser IP address and is fairly = static * Metric-2 that depends on the content URI (because dCDN wants = to increase cache hit ratio) * Metric-3 that is fairly dynamic (eg Surrogate load). Assuming the dCDN is willing to make this information visible, I can see = that the dCDN could provide a network map that would allow uCDN to take = into account Metric-1. Do you agree that ALTO itself would not naturally allow uCDN to factor = Metric-2 and Metric-3? And even whether it is ALTO or something else, would you agree that a = solution allowing uCDN to factor in something like Metric-3 would = probably involve exposing quite a bit of dCDN information and updating = it very frequently? > =20 > Regarding (ii), I believe facilitating dCDN selection by uCDN is = indeed a strong goal, but the draft does not yet discuss details of how = ALTO could be used there. > =20 > Jan: indeed, this needs to be detailed in future versions of the = draft. One example would be that ALTO maps from several candidate dCDNs = could provide information to the uCDN of the footprint of these dCDNs or = how close to the end user each dCDN can offer a surrogate. But such use = cases need to be thought through a bit more. > =20 > I hope my answers clarified a bit, especially that ALTO information = can be used in a way that it does not disclose (too many) details of the = network topology. See above. I would agree that, _if we want to support a solution where the uCDN = performs dCDN surrogate selection_, then ALTO could be used to provide = _some_ basic info that could be used by the uCDN in the dCDN Surrogate = selection. But because surrogate selection in a CDN is a sophisticated = multi-dimension dynamic vendor-specific decision, I am not convinced = that it is possible to convey to the uCDN the _rest_ of the info that is = really needed to make the complete surrogate selection in a way that is = scalable, fresh-enough, covers all the fancy selection criteria out = there and at the same time ensures the dCDN does not expose more than it = wishes. In other words I don't think it is realistic to expect that uCDN = can do dCDN surrogate selection on behalf of dCDN. I'm interested in other opinions here. Cheers Francois > =20 > =20 > - Jan > =20 > =20 > From: Francois Le Faucheur [mailto:flefauch@cisco.com]=20 > Sent: Monday, November 14, 2011 11:09 AM > To: Jan Seedorf > Cc: cdni@ietf.org > Subject: Re: [CDNi] Draft submitted on ALTO for CDNi request routing > =20 > Hello Jan, > =20 > (as an individual) > =20 > I understand that your document : > (i) discusses how ALTO could be used to effectively allow = selection of dCDN Surrogate directly by the uCDN request router, AND > (ii) mentions that ALTO could potentially be used to = facilitate dCDN selection by uCDN. > =20 > Regarding (i), it is not clear to me that allow selection of dCDN = Surrogate directly by the uCDN request router is a desirable goal = considering the combination of the following: > (a) the Working Group has agreed that the solution should = not rely on dCDN exposing too much "internal" information:=20 > " > GEN-4 [HIGH] The CDNI solution shall not require intra-CDN > information to be exposed to other CDNs for effective and > efficient delivery of the content. Examples of intra-CDN > information include surrogate topology, surrogate status, > cached content, etc. > " > (b) in general, selection of dCDN Surrogate is likely to = depend on a number of criteria, including criteria beyond network = proximity information (e.g. Surrogate cache/resource/status = considerations), do I don't think that exposing dCDN proximity = information to uCDN would be sufficient. In fact, I see that you have = noticed that point since your draft does mention: > "An implicit assumption for the example in Figure 1 to work is that = the CDN entry point for the downstream CDN only depends on the location = of the end user." > =20 > =20 > Regarding (ii), I believe facilitating dCDN selection by uCDN is = indeed a strong goal, but the draft does not yet discuss details of how = ALTO could be used there. > =20 > Cheers > =20 > Francois > =20 > =20 > =20 > =20 > =20 > On 19 Oct 2011, at 23:52, Jan Seedorf wrote: >=20 >=20 > CDNi folks, ALTO folks, > =20 > I have just submitted a new draft which discusses how ALTO could help = in CDNi request routing: > =20 > Abstract: > =93=85 This document focusses on the Request Routing Interface of = CDNi, and more specifically on how the solutions currently being defined = in the Application 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 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.=94 > =20 > http://www.ietf.org/id/draft-seedorf-alto-for-cdni-00.txt > =20 > Comments (from CDNi WG and ALTO WG) are welcome, > =20 > - Jan > _______________________________________________ > 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-126--614356940 Content-Type: multipart/related; type="text/html"; boundary=Apple-Mail-127--614356940 --Apple-Mail-127--614356940 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 14 Nov 2011, at 14:33, Jan Seedorf = wrote:

Dear = Francois,
Thanks for = your comments on the draft. Please find my answers below = inline:
Regarding (i), it is not = clear to me that allow selection of dCDN Surrogate directly by the uCDN = request router is a desirable goal considering the combination of the = following:
Jan: = Actually, ALTO is designed in a way that leaves the degree of detail = being disclosed through ALTO information at the ALTO server=92s (i.e. in = this case at the dCDN=92s) discretion. To be concrete, ALTO is exactly a = way to recommend a surrogate without disclosing the interior topology of = the dCDN.
"An implicit assumption = for the example in Figure 1 to work is that the CDN entry point for the = downstream CDN only depends on the location of the end = user."
Jan: Maybe = I should clarify (I think it says somehow in the draft as well) that the = draft does not propose to have ALTO as the CDNi request routing = itself,
but rather = that ALTO can be a part of it. =
Having said = that, I think that the data contained in an ALTO cost map could be a = combination of proximity/status/other criteria, again being combined = totally at the dCDNs discretion and without disclosing these details to = the uCDN. The ALTO cost value would just be a means to signal to the = uCDN which surrogate is preferred from the dCDNs = perspective.

<= /div>
Let's say for argument sake that the dCDN wants to select a = surrogate taking into account 3 metrics:
* = Metric-1 that depends on enduser IP address and is fairly = static
= * Metric-2 that depends on the content URI (because dCDN = wants to increase cache hit ratio)
* = Metric-3 that is fairly dynamic (eg Surrogate = load).

Assuming the dCDN is willing to make = this information visible, I can see that the dCDN could provide a = network map that would allow uCDN to take into account = Metric-1.

Do you agree that ALTO itself would = not naturally allow uCDN to factor Metric-2 and Metric-3?
And = even whether it is ALTO or something else, would you agree that a = solution allowing uCDN to factor in something like Metric-3 would = probably involve exposing quite a bit of dCDN information and updating = it very frequently?


Regarding (ii), I = believe facilitating dCDN selection by uCDN is indeed a strong goal, but = the draft does not yet discuss details of how ALTO could be used = there.
Jan: = indeed, this needs to be detailed in future versions of the draft. One = example would be that ALTO maps from several candidate dCDNs could = provide information to the uCDN of the footprint of these dCDNs or how = close to the end user each dCDN can offer a surrogate. But such use = cases need to be thought through a bit = more.
I hope my = answers clarified a bit, especially that ALTO information can be used in = a way that it does not disclose (too many) details of the network = topology.

See above.
I would agree that, _if we want to support a = solution where the uCDN performs dCDN surrogate selection_, then ALTO = could be used to provide _some_ basic info that could be used by the = uCDN in the dCDN Surrogate selection. But because surrogate selection in = a CDN is a sophisticated multi-dimension dynamic vendor-specific = decision, I am not convinced that it is possible to convey to the uCDN = the _rest_ of the info that is really needed to make the complete = surrogate selection in a way that is scalable, fresh-enough, covers all = the fancy selection criteria out there and at the same time ensures the = dCDN does not expose more than it wishes. In other words I don't think = it is realistic to expect that uCDN can do dCDN surrogate selection on = behalf of dCDN.
I'm interested in other opinions = here.

Cheers

Francois


-          <= /font>Jan
 
 
From: Francois Le Faucheur = [mailto:flefauch@cisco.com] 
Sent: Monday, November 14, 2011 = 11:09 AM
To: Jan Seedorf
Cc: cdni@ietf.org
 Re: [CDNi] Draft submitted = on ALTO for CDNi request = routing
Hello = Jan,
(as an = individual)
I understand that your document = :
 (i) = discusses how ALTO could be used to effectively allow selection of dCDN = Surrogate directly by the uCDN request router, = AND
 (ii) = mentions that ALTO could potentially be used to facilitate dCDN = selection by uCDN.
Regarding (i), it is not clear to me that = allow selection of dCDN Surrogate directly by the uCDN request router is = a desirable goal considering the combination of the = following:
 (a) = the Working Group has agreed that the solution should not rely on dCDN = exposing too much "internal" = information: 
 "
 GEN-4 =   [HIGH] The CDNI solution shall not require intra-CDN
  =          information to be exposed to other = CDNs for effective and
          =  efficient delivery of the content.  Examples of = intra-CDN
           information = include surrogate topology, surrogate status,
      =      cached content, etc.
 "
 (b) in = general, selection of dCDN Surrogate is likely to depend on a number of = criteria, including criteria beyond network proximity information (e.g. = Surrogate cache/resource/status considerations), do I don't think that = exposing dCDN proximity information to uCDN would be sufficient. In = fact, I see that you have noticed that point since your draft does = mention:
"An implicit = assumption for the example in Figure 1 to work is that the CDN entry = point for the downstream CDN only depends on the location of the end = user."
Regarding (ii), I believe facilitating = dCDN selection by uCDN is indeed a strong goal, but the draft does not = yet discuss details of how ALTO could be used = there.
On 19 Oct = 2011, at 23:52, Jan Seedorf = wrote:
CDNi folks, ALTO = folks,
I have just submitted a new draft which discusses = how ALTO could help in CDNi request = routing:
 
=93=85 This document focusses on the Request Routing = Interface of CDNi, and more specifically on how the solutions currently = being defined in the Application 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 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.=94
 

= Dear Francois,

=  

= Thanks for your comments on the draft. Please fi= nd my answers below inline:

=  

Regarding (i), it is not clear to me that allow selectio= n of dCDN Surrogate directly by the uCDN request router is a desirable goal considering the combination of the following:

         &n= bsp;      (a) the Working Group has agreed that th= e solution should not rely on dCDN exposing too much "internal" information:

         &n= bsp;            = ;          "

         &n= bsp;      GEN-4   [HIGH] The CDNI soluti= on shall not require intra-CDN

         &n= bsp; information to be exposed to other CDNs for effective and

         &n= bsp; efficient delivery of the content.  Examples of intra-CDN

         &n= bsp; information include surrogate topology, surrogate status,

         &n= bsp; cached content, etc.

         &n= bsp;            = ;          "

= Jan: Actually, ALTO is designed in a way that le= aves the degree of detail being disclosed through ALTO information at the ALTO server’s (i.e. in this case at the dCDN’s) discret= ion. To be concrete, ALTO is exactly a way to recommend a surrogate without= disclosing the interior topology of the dCDN.

=  

         &n= bsp;      (b) in general, selection of dCDN Surrog= ate is likely to depend on a number of criteria, including criteria beyond network proximity information (e.g. Surrogate cache/resource/status= considerations), do I don't think that exposing dCDN proximity information= to uCDN would be sufficient. In fact, I see that you have noticed that poi= nt since your draft does mention:

"An implicit assumption for the example in Figure 1= to work is that the CDN entry point for the downstream CDN only depends on the location of the end user."

 

= Jan: Maybe I should clarify (I think it says som= ehow in the draft as well) that the draft does not propose to have ALTO as the CDNi request routing itself, but rather that ALTO can be = a part of it. Having said that, I think that the data contained in an ALTO = cost map could be a combination of proximity/status/other criteria, again b= eing combined totally at the dCDNs discretion and without disclosing these details to the uCDN. The ALTO cost= value would just be a means to signal to the uCDN which surrogate is prefe= rred from the dCDNs perspective.

=  

Regarding (ii), I believe facilitating dCDN selection by= uCDN is indeed a strong goal, but the draft does not yet discuss details of how ALTO could be used there.

 

= Jan: indeed, this needs to be detailed in future= versions of the draft. One example would be that ALTO maps from several candidate dCDNs could provide information to the uCDN of the footp= rint of these dCDNs or how close to the end user each dCDN can offer a surr= ogate. But such use cases need to be thought through a bit more.=

=  

= I hope my answers clarified a bit, especially th= at ALTO information can be used in a way that it does not disclose (too many) details of the network topology.

=  

=  

-          Jan

=  

=  

From: Francois Le Faucheur [mailto:flefauch@cisco.com]
Sent: Monday, November 14, 2= 011 11:09 AM
To: Jan Seedorf
Cc: cdni@ietf.org
Subject: Re: [CDNi] Draft su= bmitted on ALTO for CDNi request routing

 

Hello Jan,

 

(as an individual)

 

I understand that your document :<= /font>

   &nb= sp;      (i) discusses how ALTO could be used to effectively al= low selection of dCDN Surrogate directly by the uCDN request router, AND

   &nb= sp;      (ii) mentions that ALTO could potentially be used to f= acilitate dCDN selection by uCDN.

 

Regarding (i), it is not clear to me that allow sele= ction of dCDN Surrogate directly by the uCDN request router is a desirable = goal considering the combination of the following:

   &nb= sp;      (a) the Working Group has agreed that the solution sho= uld not rely on dCDN exposing too much "internal" information:&nb= sp;

   &nb= sp;            =       "

   &nb= sp;      GEN-4   [HIGH] The CDNI solution shall not requir= e intra-CDN
           information to be exposed to other= CDNs for effective and
           efficient delivery of the content.=  Examples of intra-CDN
           information include surrogate topo= logy, surrogate status,
           cached content, etc.

   &nb= sp;            =       "

   &nb= sp;      (b) in general, selection of dCDN Surrogate is likely = to depend on a number of criteria, including criteria beyond network proxim= ity information (e.g. Surrogate cache/resource/status considerations), do I= don't think that exposing dCDN proximity information to uCDN would be sufficient. In fact, I see that you= have noticed that point since your draft does mention:

"An implicit assumption for the example in Figu= re 1 to work is that the CDN entry point for the downstream CDN only depend= s on the location of the end user."

 

 

Regarding (ii), I believe facilitating dCDN sel= ection by uCDN is indeed a strong goal, but the draft does not yet discuss = details of how ALTO could be used there.

 

Cheers

 

Francois

 

 

 

 

 

On 19 Oct 2011, at 23:52, Jan Seedorf wrote:



= 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.”

=  

=  

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

=  

-          Jan

_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/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-127--614356940 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-127--614356940-- --Apple-Mail-126--614356940-- From alan.kavanagh@ericsson.com Mon Nov 14 13:56: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 720AA11E8160 for ; Mon, 14 Nov 2011 13:56:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.132 X-Spam-Level: X-Spam-Status: No, score=-6.132 tagged_above=-999 required=5 tests=[AWL=0.466, 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 yZ-h+XCHZq74 for ; Mon, 14 Nov 2011 13:56:09 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0111911E815B for ; Mon, 14 Nov 2011 13:56:08 -0800 (PST) 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 pAELtneI026435; Mon, 14 Nov 2011 15:56:04 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 14 Nov 2011 16:55:57 -0500 From: Alan Kavanagh To: "gilles.bertrand@orange.com" , "emile.stephan@orange.com" , "grant.watson@bt.com" , "trevor.burbridge@bt.com" , "philip.eardley@bt.com" , "kevin.ma@azukisystems.com" Date: Mon, 14 Nov 2011 16:55:57 -0500 Thread-Topic: draft-ietf-cdni-cases-00 Thread-Index: AcyadRRdhlXhbegIQbqsQJnwtuqUpACvZ/1QAV7k6HA= Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> 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_1B6D0317D3AD964FBF3956DEFA3524D51711E69B20EUSAACMS0701e_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 14 Nov 2011 21:56:10 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D51711E69B20EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gilles Responses inline below. Alan ________________________________ From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] Sent: November-07-11 5:19 AM To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; trevor.bu= rbridge@bt.com; philip.eardley@bt.com; kevin.ma@azukisystems.com Cc: cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 Hi Alan, Thanks for your review of the I-D. I added my answers in line. * Section 1.1. You mention Access CDN. Is this more an operator own and = managed CDN in the Access Domain that may have access to end user informati= on or are you talking about a given Access CDN having access to the end-use= rs profile, im assuming its the former but felt its not clear in the draft. I did not understand your question. Could you please rephrase? Thanks. A.K.--> my point here is that you tying Access CDN with end users profile i= nformation such as given subscriber profile information an Access Network P= rovider has such as data line rate etc. So my point was are you stating the= Access CDN has an i/f to sub mgmt that Access Network Provider knows? * Section 1.3. First bullet " improve the experience for the End User; f= or instance delivery has lower latency and better robustness". Suggest to add and reduce Round= Trip Time as content is positioned closer to end user. By lower latency, we mean decrease the round trip time between the user and= the delivery server. A.K.--> yes my point exactly, just needs to be reworded in the draft for ea= sier reading. * Section 1.3. Third bullet mentions reduced electricity consumption, co= uld you expand on that and say how this is achieved? Popular content is delivered through the CDN rather than through the conten= t provider's servers. Therefore, the content providers' infrastructure can = be smaller (less servers etc). A.K.--> I think that example should be noted in the draft such that caching= reduces transport in certain network segments which may in turn imply redu= ce electric consumption etc. * Section 1.3. Suggest to add CSP-3 in Figure-1 to be consistent. To be consistent with what? A.K.--> Reading section 1.3 last paragraph you give another example of a "C= SP-3", but CSP-3 is not shown in figure 1, so makes sense to add CSP-3 to F= igure-1. * Section 1.4. I understand what you are conveying here, makes sense. I = would however clarify that CDN's even external ones to interconnect with ot= hers today but use a Proprietary interface to do so etc. Do you know examples of production CDNs interconnected through proprietary = interfaces today? A.K.--> Yes, lots of them :-). If you like i can craft some text to add to = this section of use cases and my main point is to convey what is in the cur= rent market place to give a better reflection of the current technology lan= dscape and market place, so im sure this is simple to add, but if you need = me ill provide the text. * Section 2.3. Is their enough movement of nomadic users are moving to c= ache content in the first place?....im thinking here than you may be nomadi= c but also geo-blocked, believe that should be very clearly clarified. We will clarify this section in the next version of the I-D. A.K.--> Cheers Gilles, look forward to that, if you need some examples etc = just ping me. * Section 3.1. "However, unexpected spikes in content popularity may dri= ve load...." suggest to "flash crowds" after content popularity. ok * Section 3.1 Offloading. It should be noted that this use case would re= quire knowledge about the other CDN to know if the other CDN has the resour= ces to offload the requests in the first place and also if the content is a= vailable in the CDN being offloaded too. I agree: the CDN on which requests are offloaded must be able to handle the= offloaded requests. This introduces requirements on the metadata (and cont= rol) interfaces. A.K.--> Yes, my point exactly, it would be useful to point that out in your= draft to make it complete and also have it noted in the "CDNI Requirements= Draft" . * Section 4.1. Im having difficulty in seeing how number 1 is a typical = CDN use case of today? IMHO i dont not agree that its a typical model. We do not assert that it is a typical CDN use case today. It is rather one = of the cases where CDNI would be useful. A.K.--> Agree, though it might be useful to describe a "typical CDN usecase= deployed today" which should be inserted into the draft. What we dont want= to misrepresent is how its working today ;-) * Section 10. Shouldn't it also cover a section on Authorization to view= content and Authorization with Origin Server? Yes it would be interesting to mention these issues. We will extend this se= ction in the next version of the I-D. A.K.--> cheers Gilles, i think that would really help complete the draft an= d help us in ensuring we tackel these issues in the relevant drafts etc. Best regards, Gilles --_000_1B6D0317D3AD964FBF3956DEFA3524D51711E69B20EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Gilles
 
Responses inline below.
 
Alan

From: gilles.bertrand@orange.com=20 [mailto:gilles.bertrand@orange.com]
Sent: November-07-11 5:19=20 AM
To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.c= om;=20 trevor.burbridge@bt.com; philip.eardley@bt.com;=20 kevin.ma@azukisystems.com
Cc: cdni@ietf.org
Subject: RE= :=20 draft-ietf-cdni-cases-00

Hi=20 Alan,

 

Thanks=20 for your review of the I-D. I added my answers in line.

  • Section 1.1.= You=20 mention Access CDN. Is this more an operator own and managed CDN in the A= ccess=20 Domain that may have access to end user information or are you talking ab= out a=20 given Access CDN having access to the end-users profile, im assuming its = the=20 former but felt its not clear in the draft.

I=20 did not understand your question. Could you please rephrase? Thanks. <= SPAN=20 class=3D212501709-14112011> 

A.K.= --> my=20 point here is that you tying Access CDN with end users profile informa= tion=20 such as given subscriber profile information an Access Network Provider has= such=20 as data line rate etc. So my point was are you stating the Access CDN = has=20 an i/f to sub mgmt that Access Network=20 Provider knows? 

  • Section 1.3.= First=20 bullet " improve the experience for the End User; for instance delivery=20 has
          lower latency and better robustness= ".=20 Suggest to add and reduce Round Trip Time as content is positioned closer= to=20 end user.

By=20 lower latency, we mean decrease the round trip time between the user and th= e=20 delivery server.  

A.K.= --> yes my=20 point exactly, just needs to be reworded in the draft for easier=20 reading. 

  • Section 1.3.= Third=20 bullet mentions reduced electricity consumption, could you expand on that= and=20 say how this is achieved?

Popular=20 content is delivered through the CDN rather than through the content provid= er's=20 servers. Therefore, the content providers' infrastructure can be smaller (l= ess=20 servers etc).  

A.K.= --> I=20 think that example should be noted in the draft such that caching redu= ces=20 transport in certain network segments which may in turn imply reduce electr= ic=20 consumption etc. 

  • Section 1.3.= =20 Suggest to add CSP-3 in Figure-1 to be consistent.
    • =

To=20 be consistent with what? 

A.K.= -->=20 Reading section 1.3 last paragraph you give another example of a "CSP-3", b= ut=20 CSP-3 is not shown in figure 1, so makes sense to add CSP-3 to=20 Figure-1. 

  • Section 1.4.= I=20 understand what you are conveying here, makes sense. I would however clar= ify=20 that CDN's even external ones to interconnect with others today but use a= =20 Proprietary interface to do so etc.

Do=20 you know examples of production CDNs interconnected through proprietary=20 interfaces today? 

A.K.= --> Yes,=20 lots of them :-). If you like i can craft some text to add to this section = of=20 use cases and my main point is to convey what is in the current market= =20 place to give a better reflection of the current technology landscape = and=20 market place, so im sure this is simple to add, but if you need me ill prov= ide=20 the text. 

  • Section 2.3.= Is=20 their enough movement of nomadic users are moving to cache content in the= =20 first place?....im thinking here than you may be nomadic but also geo-blo= cked,=20 believe that should be very clearly clarified.

    • We=20 will clarify this section in the next version of the I-D. 

    A.K.= -->=20 Cheers Gilles, look forward to that, if you need some examples et= c=20 just ping me. 

    • Section 3.1.= =20 "However, unexpected spikes in content popularity may drive load...." sug= gest=20 to "flash crowds" after content popularity.

    ok

    • Section 3.1= =20 Offloading. It should be noted that this use case would require knowledge= =20 about the other CDN to know if the other CDN has the resources to offload= the=20 requests in the first place and also if the content is available in the C= DN=20 being offloaded too.

    I=20 agree: the CDN on which requests are offloaded must be able to handle the=20 offloaded requests. This introduces requirements on the metadata (and contr= ol)=20 interfaces. 

    A.K.= --> Yes,=20 my point exactly, it would be useful to point that out in your draft to mak= e it=20 complete and also have it noted in the "CDNI=20 Requirements Draft" .

    • Section 4.1.= Im=20 having difficulty in seeing how number 1 is a typical CDN use case of tod= ay?=20 IMHO i dont not agree that its a typical model.

      • We=20 do not assert that it is a typical CDN use case today. It is rather one of = the=20 cases where CDNI would be useful.  

      A.K.--> Agree, though it might be useful to describe = a=20 "typical CDN usecase deployed today" which should be inserted into the draf= t.=20 What we dont want to misrepresent is how its working today=20 ;-) 

      • Section 10.= =20 Shouldn't it also cover a section on Authorization to view content and=20 Authorization with Origin Server?

      Yes=20 it would be interesting to mention these issues. We will extend this sectio= n in=20 the next version of the I-D. 

       

      A.K.= --> cheers=20 Gilles, i think that would really help complete the draft and help us= =20 in ensuring we tackel these issues in the relevant drafts=20 etc.

       

      Best=20 regards,

      Subject: Re: [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: Tue, 15 Nov 2011 02:18:48 -0000 --_005_2779C9F0771F974CAD742BAE6D9904FE24E80A3BPolydeucesoffic_ Content-Type: multipart/alternative; boundary="_000_2779C9F0771F974CAD742BAE6D9904FE24E80A3BPolydeucesoffic_" --_000_2779C9F0771F974CAD742BAE6D9904FE24E80A3BPolydeucesoffic_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBGcmFuY29pcywNCg0KSSBhY3R1YWxseSBhZ3JlZSB3aXRoIG1vc3Qgb2YgeW91ciBwb2lu dHMuIFBsZWFzZSBmaW5kIG15IHJlcGx5IGlubGluZSBiZWxvd+KApg0KDQpGcm9tOiBGcmFuY29p cyBMZSBGYXVjaGV1ciBbbWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbV0NClNlbnQ6IFR1ZXNkYXks IE5vdmVtYmVyIDE1LCAyMDExIDE6MDQgQU0NClRvOiBKYW4gU2VlZG9yZg0KQ2M6IEZyYW5jb2lz IExlIEZhdWNoZXVyOyBjZG5pQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0NETmldIERyYWZ0IHN1 Ym1pdHRlZCBvbiBBTFRPIGZvciBDRE5pIHJlcXVlc3Qgcm91dGluZw0KDQoNCk9uIDE0IE5vdiAy MDExLCBhdCAxNDozMywgSmFuIFNlZWRvcmYgd3JvdGU6DQoNCg0KRGVhciBGcmFuY29pcywNCg0K VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIG9uIHRoZSBkcmFmdC4gUGxlYXNlIGZpbmQgbXkgYW5z d2VycyBiZWxvdyBpbmxpbmU6DQoNClJlZ2FyZGluZyAoaSksIGl0IGlzIG5vdCBjbGVhciB0byBt ZSB0aGF0IGFsbG93IHNlbGVjdGlvbiBvZiBkQ0ROIFN1cnJvZ2F0ZSBkaXJlY3RseSBieSB0aGUg dUNETiByZXF1ZXN0IHJvdXRlciBpcyBhIGRlc2lyYWJsZSBnb2FsIGNvbnNpZGVyaW5nIHRoZSBj b21iaW5hdGlvbiBvZiB0aGUgZm9sbG93aW5nOg0KICAgICAgICAgICAgICAgIChhKSB0aGUgV29y a2luZyBHcm91cCBoYXMgYWdyZWVkIHRoYXQgdGhlIHNvbHV0aW9uIHNob3VsZCBub3QgcmVseSBv biBkQ0ROIGV4cG9zaW5nIHRvbyBtdWNoICJpbnRlcm5hbCIgaW5mb3JtYXRpb246DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICINCiAgICAgICAgICAgICAgICBHRU4tNCAgIFtISUdI XSBUaGUgQ0ROSSBzb2x1dGlvbiBzaGFsbCBub3QgcmVxdWlyZSBpbnRyYS1DRE4NCiAgICAgICAg ICAgaW5mb3JtYXRpb24gdG8gYmUgZXhwb3NlZCB0byBvdGhlciBDRE5zIGZvciBlZmZlY3RpdmUg YW5kDQogICAgICAgICAgIGVmZmljaWVudCBkZWxpdmVyeSBvZiB0aGUgY29udGVudC4gIEV4YW1w bGVzIG9mIGludHJhLUNETg0KICAgICAgICAgICBpbmZvcm1hdGlvbiBpbmNsdWRlIHN1cnJvZ2F0 ZSB0b3BvbG9neSwgc3Vycm9nYXRlIHN0YXR1cywNCiAgICAgICAgICAgY2FjaGVkIGNvbnRlbnQs IGV0Yy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIg0KSmFuOiBBY3R1YWxseSwg QUxUTyBpcyBkZXNpZ25lZCBpbiBhIHdheSB0aGF0IGxlYXZlcyB0aGUgZGVncmVlIG9mIGRldGFp bCBiZWluZyBkaXNjbG9zZWQgdGhyb3VnaCBBTFRPIGluZm9ybWF0aW9uIGF0IHRoZSBBTFRPIHNl cnZlcuKAmXMgKGkuZS4gaW4gdGhpcyBjYXNlIGF0IHRoZSBkQ0RO4oCZcykgZGlzY3JldGlvbi4g VG8gYmUgY29uY3JldGUsIEFMVE8gaXMgZXhhY3RseSBhIHdheSB0byByZWNvbW1lbmQgYSBzdXJy b2dhdGUgd2l0aG91dCBkaXNjbG9zaW5nIHRoZSBpbnRlcmlvciB0b3BvbG9neSBvZiB0aGUgZENE Ti4NCg0KICAgICAgICAgICAgICAgIChiKSBpbiBnZW5lcmFsLCBzZWxlY3Rpb24gb2YgZENETiBT dXJyb2dhdGUgaXMgbGlrZWx5IHRvIGRlcGVuZCBvbiBhIG51bWJlciBvZiBjcml0ZXJpYSwgaW5j bHVkaW5nIGNyaXRlcmlhIGJleW9uZCBuZXR3b3JrIHByb3hpbWl0eSBpbmZvcm1hdGlvbiAoZS5n LiBTdXJyb2dhdGUgY2FjaGUvcmVzb3VyY2Uvc3RhdHVzIGNvbnNpZGVyYXRpb25zKSwgZG8gSSBk b24ndCB0aGluayB0aGF0IGV4cG9zaW5nIGRDRE4gcHJveGltaXR5IGluZm9ybWF0aW9uIHRvIHVD RE4gd291bGQgYmUgc3VmZmljaWVudC4gSW4gZmFjdCwgSSBzZWUgdGhhdCB5b3UgaGF2ZSBub3Rp Y2VkIHRoYXQgcG9pbnQgc2luY2UgeW91ciBkcmFmdCBkb2VzIG1lbnRpb246DQoiQW4gaW1wbGlj aXQgYXNzdW1wdGlvbiBmb3IgdGhlIGV4YW1wbGUgaW4gRmlndXJlIDEgdG8gd29yayBpcyB0aGF0 IHRoZSBDRE4gZW50cnkgcG9pbnQgZm9yIHRoZSBkb3duc3RyZWFtIENETiBvbmx5IGRlcGVuZHMg b24gdGhlIGxvY2F0aW9uIG9mIHRoZSBlbmQgdXNlci4iDQoNCkphbjogTWF5YmUgSSBzaG91bGQg Y2xhcmlmeSAoSSB0aGluayBpdCBzYXlzIHNvbWVob3cgaW4gdGhlIGRyYWZ0IGFzIHdlbGwpIHRo YXQgdGhlIGRyYWZ0IGRvZXMgbm90IHByb3Bvc2UgdG8gaGF2ZSBBTFRPIGFzIHRoZSBDRE5pIHJl cXVlc3Qgcm91dGluZyBpdHNlbGYsDQpidXQgcmF0aGVyIHRoYXQgQUxUTyBjYW4gYmUgYSBwYXJ0 IG9mIGl0Lg0KSGF2aW5nIHNhaWQgdGhhdCwgSSB0aGluayB0aGF0IHRoZSBkYXRhIGNvbnRhaW5l ZCBpbiBhbiBBTFRPIGNvc3QgbWFwIGNvdWxkIGJlIGEgY29tYmluYXRpb24gb2YgcHJveGltaXR5 L3N0YXR1cy9vdGhlciBjcml0ZXJpYSwgYWdhaW4gYmVpbmcgY29tYmluZWQgdG90YWxseSBhdCB0 aGUgZENETnMgZGlzY3JldGlvbiBhbmQgd2l0aG91dCBkaXNjbG9zaW5nIHRoZXNlIGRldGFpbHMg dG8gdGhlIHVDRE4uIFRoZSBBTFRPIGNvc3QgdmFsdWUgd291bGQganVzdCBiZSBhIG1lYW5zIHRv IHNpZ25hbCB0byB0aGUgdUNETiB3aGljaCBzdXJyb2dhdGUgaXMgcHJlZmVycmVkIGZyb20gdGhl IGRDRE5zIHBlcnNwZWN0aXZlLg0KDQpMZXQncyBzYXkgZm9yIGFyZ3VtZW50IHNha2UgdGhhdCB0 aGUgZENETiB3YW50cyB0byBzZWxlY3QgYSBzdXJyb2dhdGUgdGFraW5nIGludG8gYWNjb3VudCAz IG1ldHJpY3M6DQogICAgICAgICAgKiBNZXRyaWMtMSB0aGF0IGRlcGVuZHMgb24gZW5kdXNlciBJ UCBhZGRyZXNzIGFuZCBpcyBmYWlybHkgc3RhdGljDQogICAgICAgICAgKiBNZXRyaWMtMiB0aGF0 IGRlcGVuZHMgb24gdGhlIGNvbnRlbnQgVVJJIChiZWNhdXNlIGRDRE4gd2FudHMgdG8gaW5jcmVh c2UgY2FjaGUgaGl0IHJhdGlvKQ0KICAgICAgICAgICogTWV0cmljLTMgdGhhdCBpcyBmYWlybHkg ZHluYW1pYyAoZWcgU3Vycm9nYXRlIGxvYWQpLg0KDQpBc3N1bWluZyB0aGUgZENETiBpcyB3aWxs aW5nIHRvIG1ha2UgdGhpcyBpbmZvcm1hdGlvbiB2aXNpYmxlLCBJIGNhbiBzZWUgdGhhdCB0aGUg ZENETiBjb3VsZCBwcm92aWRlIGEgbmV0d29yayBtYXAgdGhhdCB3b3VsZCBhbGxvdyB1Q0ROIHRv IHRha2UgaW50byBhY2NvdW50IE1ldHJpYy0xLg0KDQpEbyB5b3UgYWdyZWUgdGhhdCBBTFRPIGl0 c2VsZiB3b3VsZCBub3QgbmF0dXJhbGx5IGFsbG93IHVDRE4gdG8gZmFjdG9yIE1ldHJpYy0yIGFu ZCBNZXRyaWMtMz8NCkFuZCBldmVuIHdoZXRoZXIgaXQgaXMgQUxUTyBvciBzb21ldGhpbmcgZWxz ZSwgd291bGQgeW91IGFncmVlIHRoYXQgYSBzb2x1dGlvbiBhbGxvd2luZyB1Q0ROIHRvIGZhY3Rv ciBpbiBzb21ldGhpbmcgbGlrZSBNZXRyaWMtMyB3b3VsZCBwcm9iYWJseSBpbnZvbHZlIGV4cG9z aW5nIHF1aXRlIGEgYml0IG9mIGRDRE4gaW5mb3JtYXRpb24gYW5kIHVwZGF0aW5nIGl0IHZlcnkg ZnJlcXVlbnRseT8NCg0KSmFuOiBZZXMsIEkgYWdyZWUuIEFMVE8gaXMg4oCTIGFzIGRlc2NyaWJl ZCBpbiBSRkMgNTY5MyDigJMgZm9yIGluZm9ybWF0aW9uIHRoYXQgZG9lcyBub3QgY2hhbmdlIGZy ZXF1ZW50bHkgKFJGQyA1NjkzOiDigJxUaGUga2luZCBvZiBpbmZvcm1hdGlvbiB0aGF0IGlzIG1l YW5pbmdmdWwgdG8gY29udmV5IHRvIGFwcGxpY2F0aW9ucyB2aWEgYW4gb3V0LW9mLWJhbmQgQUxU TyBzZXJ2aWNlIGlzIGFueSBpbmZvcm1hdGlvbiB0aGF0IGFwcGxpY2F0aW9ucyBjYW5ub3QgZWFz aWx5IG9idGFpbiB0aGVtc2VsdmVzIGFuZCB0aGF0IGNoYW5nZXMgb24gYSBtdWNoIGxvbmdlciB0 aW1lIHNjYWxlIHRoYW4gdGhlIGluc3RhbnRhbmVvdXMgaW5mb3JtYXRpb24gdXNlZCBmb3IgY29u Z2VzdGlvbiBjb250cm9sIG9uIHRoZSB0cmFuc3BvcnQgbGF5ZXLigJ0pLiBFc3BlY2lhbGx5IG1l dHJpYy0yIGlzIGRlZmluaXRlbHkgc29tZXRoaW5nIEFMVE8gY2Fubm90IHByb3ZpZGUsIGFuZCBt ZXRyaWMgMyBpZiBpdCBpcyDigJxmYWlybHnigJ0gZHluYW1pYyBpcyBvdXQgb2Ygc2NvcGUgZm9y IEFMVE8uDQoNCg0KUmVnYXJkaW5nIChpaSksIEkgYmVsaWV2ZSBmYWNpbGl0YXRpbmcgZENETiBz ZWxlY3Rpb24gYnkgdUNETiBpcyBpbmRlZWQgYSBzdHJvbmcgZ29hbCwgYnV0IHRoZSBkcmFmdCBk b2VzIG5vdCB5ZXQgZGlzY3VzcyBkZXRhaWxzIG9mIGhvdyBBTFRPIGNvdWxkIGJlIHVzZWQgdGhl cmUuDQoNCkphbjogaW5kZWVkLCB0aGlzIG5lZWRzIHRvIGJlIGRldGFpbGVkIGluIGZ1dHVyZSB2 ZXJzaW9ucyBvZiB0aGUgZHJhZnQuIE9uZSBleGFtcGxlIHdvdWxkIGJlIHRoYXQgQUxUTyBtYXBz IGZyb20gc2V2ZXJhbCBjYW5kaWRhdGUgZENETnMgY291bGQgcHJvdmlkZSBpbmZvcm1hdGlvbiB0 byB0aGUgdUNETiBvZiB0aGUgZm9vdHByaW50IG9mIHRoZXNlIGRDRE5zIG9yIGhvdyBjbG9zZSB0 byB0aGUgZW5kIHVzZXIgZWFjaCBkQ0ROIGNhbiBvZmZlciBhIHN1cnJvZ2F0ZS4gQnV0IHN1Y2gg dXNlIGNhc2VzIG5lZWQgdG8gYmUgdGhvdWdodCB0aHJvdWdoIGEgYml0IG1vcmUuDQoNCkkgaG9w ZSBteSBhbnN3ZXJzIGNsYXJpZmllZCBhIGJpdCwgZXNwZWNpYWxseSB0aGF0IEFMVE8gaW5mb3Jt YXRpb24gY2FuIGJlIHVzZWQgaW4gYSB3YXkgdGhhdCBpdCBkb2VzIG5vdCBkaXNjbG9zZSAodG9v IG1hbnkpIGRldGFpbHMgb2YgdGhlIG5ldHdvcmsgdG9wb2xvZ3kuDQoNClNlZSBhYm92ZS4NCkkg d291bGQgYWdyZWUgdGhhdCwgX2lmIHdlIHdhbnQgdG8gc3VwcG9ydCBhIHNvbHV0aW9uIHdoZXJl IHRoZSB1Q0ROIHBlcmZvcm1zIGRDRE4gc3Vycm9nYXRlIHNlbGVjdGlvbl8sIHRoZW4gQUxUTyBj b3VsZCBiZSB1c2VkIHRvIHByb3ZpZGUgX3NvbWVfIGJhc2ljIGluZm8gdGhhdCBjb3VsZCBiZSB1 c2VkIGJ5IHRoZSB1Q0ROIGluIHRoZSBkQ0ROIFN1cnJvZ2F0ZSBzZWxlY3Rpb24uIEJ1dCBiZWNh dXNlIHN1cnJvZ2F0ZSBzZWxlY3Rpb24gaW4gYSBDRE4gaXMgYSBzb3BoaXN0aWNhdGVkIG11bHRp LWRpbWVuc2lvbiBkeW5hbWljIHZlbmRvci1zcGVjaWZpYyBkZWNpc2lvbiwgSSBhbSBub3QgY29u dmluY2VkIHRoYXQgaXQgaXMgcG9zc2libGUgdG8gY29udmV5IHRvIHRoZSB1Q0ROIHRoZSBfcmVz dF8gb2YgdGhlIGluZm8gdGhhdCBpcyByZWFsbHkgbmVlZGVkIHRvIG1ha2UgdGhlIGNvbXBsZXRl IHN1cnJvZ2F0ZSBzZWxlY3Rpb24gaW4gYSB3YXkgdGhhdCBpcyBzY2FsYWJsZSwgZnJlc2gtZW5v dWdoLCBjb3ZlcnMgYWxsIHRoZSBmYW5jeSBzZWxlY3Rpb24gY3JpdGVyaWEgb3V0IHRoZXJlIGFu ZCBhdCB0aGUgc2FtZSB0aW1lIGVuc3VyZXMgdGhlIGRDRE4gZG9lcyBub3QgZXhwb3NlIG1vcmUg dGhhbiBpdCB3aXNoZXMuIEluIG90aGVyIHdvcmRzIEkgZG9uJ3QgdGhpbmsgaXQgaXMgcmVhbGlz dGljIHRvIGV4cGVjdCB0aGF0IHVDRE4gY2FuIGRvIGRDRE4gc3Vycm9nYXRlIHNlbGVjdGlvbiBv biBiZWhhbGYgb2YgZENETi4NCkknbSBpbnRlcmVzdGVkIGluIG90aGVyIG9waW5pb25zIGhlcmUu DQoNCkphbjogSSB0aGluayB3ZSBoYXZlIHRvIHNlcGFyYXRlIOKAnHN1cnJvZ2F0ZSBzZWxlY3Rp b27igJ0gYW5kIOKAnENETiBlbnRyeSBwb2ludOKAnSBzZWxlY3Rpb24uIExldOKAmXMgYXNzdW1l IGEgZENETiBpbiB0aGUgVVMgZG9lcyBub3Qgd2FudCBhbGwgcmVxdWVzdHMgZnJvbSBvdGhlciBj b3VudHJpZXPigJkgdUNETnMgdG8gYXJyaXZlIGF0IGEgc2luZ2xlIGdhdGV3YXksIGJ1dCBoYXMg c2V2ZXJhbCDigJxlbnRyeSBwb2ludHPigJ0gZm9yIHJlcXVlc3RzIGZyb20gYSB1Q0ROLCBzYXkg Zm9yIHNpbXBsaWNpdHkgaW4gU2VhdHRsZSwgT3JsYW5kbywgTG9zIEFuZ2VsZXMsIGFuZCBOZXcg WW9yay4gSGVyZSBJIGNhbiBzZWUgaG93IHByb3ZpZGluZyBhbiBBTFRPIG1hcCB0byB1Q0ROcyBj YW4gaGVscCB0aGVzZSB1Q0ROcyB0byBkZWNpZGUgd2hlcmUgdG8gZGlyZWN0IHJlcXVlc3RzIHRv IChpLmUuIHRvIHdoaWNoIGVudHJ5IHBvaW50IG91dCBvZiBzZXZlcmFsIGNhbmRpZGF0ZSBvbmVz KSBkZXBlbmRpbmcgb24gdGhlIGxvY2F0aW9uIChpLmUuIElQIGFkZHJlc3MpIG9mIHRoZSBlbmQg dXNlci4gRm9yIGluc3RhbmNlLCBhIHVDRE4gY291bGQgdXNlIEFMVE8gaW5mb3JtYXRpb24gdG8g ZGVjaWRlIHRvIHdoaWNoIGVudHJ5IHBvaW50IG9mIHRoZSBkQ0ROIGl0IHdvdWxkIGRpcmVjdCBh IHJlcXVlc3QgY29taW5nIGZyb20gYW4gZW5kIHVzZXIgaW4gU3QuIExvdWlzLg0KDQpGaW5hbGx5 LCBJIGFtIG9mIGNvdXJzZSBhbHNvIGludGVyZXN0ZWQgaW4gb3RoZXIgb3BpbmlvbnMgZnJvbSB0 aGUgV0cuDQoNCg0KLSAgICAgICAgICBKYW4NCg0KQ2hlZXJzDQoNCkZyYW5jb2lzDQoNCg0KDQoN Cg0KLSAgICAgICAgICBKYW4NCg0KDQpGcm9tOiBGcmFuY29pcyBMZSBGYXVjaGV1ciBbbWFpbHRv OmZsZWZhdWNoQGNpc2NvLmNvbV08bWFpbHRvOlttYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tXT4N ClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMTQsIDIwMTEgMTE6MDkgQU0NClRvOiBKYW4gU2VlZG9y Zg0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTog W0NETmldIERyYWZ0IHN1Ym1pdHRlZCBvbiBBTFRPIGZvciBDRE5pIHJlcXVlc3Qgcm91dGluZw0K DQpIZWxsbyBKYW4sDQoNCihhcyBhbiBpbmRpdmlkdWFsKQ0KDQpJIHVuZGVyc3RhbmQgdGhhdCB5 b3VyIGRvY3VtZW50IDoNCiAgICAgICAgICAoaSkgZGlzY3Vzc2VzIGhvdyBBTFRPIGNvdWxkIGJl IHVzZWQgdG8gZWZmZWN0aXZlbHkgYWxsb3cgc2VsZWN0aW9uIG9mIGRDRE4gU3Vycm9nYXRlIGRp cmVjdGx5IGJ5IHRoZSB1Q0ROIHJlcXVlc3Qgcm91dGVyLCBBTkQNCiAgICAgICAgICAoaWkpIG1l bnRpb25zIHRoYXQgQUxUTyBjb3VsZCBwb3RlbnRpYWxseSBiZSB1c2VkIHRvIGZhY2lsaXRhdGUg ZENETiBzZWxlY3Rpb24gYnkgdUNETi4NCg0KUmVnYXJkaW5nIChpKSwgaXQgaXMgbm90IGNsZWFy IHRvIG1lIHRoYXQgYWxsb3cgc2VsZWN0aW9uIG9mIGRDRE4gU3Vycm9nYXRlIGRpcmVjdGx5IGJ5 IHRoZSB1Q0ROIHJlcXVlc3Qgcm91dGVyIGlzIGEgZGVzaXJhYmxlIGdvYWwgY29uc2lkZXJpbmcg dGhlIGNvbWJpbmF0aW9uIG9mIHRoZSBmb2xsb3dpbmc6DQogICAgICAgICAgKGEpIHRoZSBXb3Jr aW5nIEdyb3VwIGhhcyBhZ3JlZWQgdGhhdCB0aGUgc29sdXRpb24gc2hvdWxkIG5vdCByZWx5IG9u IGRDRE4gZXhwb3NpbmcgdG9vIG11Y2ggImludGVybmFsIiBpbmZvcm1hdGlvbjoNCiAgICAgICAg ICAgICAgICAgICAgICAiDQogICAgICAgICAgR0VOLTQgICBbSElHSF0gVGhlIENETkkgc29sdXRp b24gc2hhbGwgbm90IHJlcXVpcmUgaW50cmEtQ0RODQogICAgICAgICAgIGluZm9ybWF0aW9uIHRv IGJlIGV4cG9zZWQgdG8gb3RoZXIgQ0ROcyBmb3IgZWZmZWN0aXZlIGFuZA0KICAgICAgICAgICBl ZmZpY2llbnQgZGVsaXZlcnkgb2YgdGhlIGNvbnRlbnQuICBFeGFtcGxlcyBvZiBpbnRyYS1DRE4N CiAgICAgICAgICAgaW5mb3JtYXRpb24gaW5jbHVkZSBzdXJyb2dhdGUgdG9wb2xvZ3ksIHN1cnJv Z2F0ZSBzdGF0dXMsDQogICAgICAgICAgIGNhY2hlZCBjb250ZW50LCBldGMuDQogICAgICAgICAg ICAgICAgICAgICAgIg0KICAgICAgICAgIChiKSBpbiBnZW5lcmFsLCBzZWxlY3Rpb24gb2YgZENE TiBTdXJyb2dhdGUgaXMgbGlrZWx5IHRvIGRlcGVuZCBvbiBhIG51bWJlciBvZiBjcml0ZXJpYSwg aW5jbHVkaW5nIGNyaXRlcmlhIGJleW9uZCBuZXR3b3JrIHByb3hpbWl0eSBpbmZvcm1hdGlvbiAo ZS5nLiBTdXJyb2dhdGUgY2FjaGUvcmVzb3VyY2Uvc3RhdHVzIGNvbnNpZGVyYXRpb25zKSwgZG8g SSBkb24ndCB0aGluayB0aGF0IGV4cG9zaW5nIGRDRE4gcHJveGltaXR5IGluZm9ybWF0aW9uIHRv IHVDRE4gd291bGQgYmUgc3VmZmljaWVudC4gSW4gZmFjdCwgSSBzZWUgdGhhdCB5b3UgaGF2ZSBu b3RpY2VkIHRoYXQgcG9pbnQgc2luY2UgeW91ciBkcmFmdCBkb2VzIG1lbnRpb246DQoiQW4gaW1w bGljaXQgYXNzdW1wdGlvbiBmb3IgdGhlIGV4YW1wbGUgaW4gRmlndXJlIDEgdG8gd29yayBpcyB0 aGF0IHRoZSBDRE4gZW50cnkgcG9pbnQgZm9yIHRoZSBkb3duc3RyZWFtIENETiBvbmx5IGRlcGVu ZHMgb24gdGhlIGxvY2F0aW9uIG9mIHRoZSBlbmQgdXNlci4iDQoNCg0KUmVnYXJkaW5nIChpaSks IEkgYmVsaWV2ZSBmYWNpbGl0YXRpbmcgZENETiBzZWxlY3Rpb24gYnkgdUNETiBpcyBpbmRlZWQg YSBzdHJvbmcgZ29hbCwgYnV0IHRoZSBkcmFmdCBkb2VzIG5vdCB5ZXQgZGlzY3VzcyBkZXRhaWxz IG9mIGhvdyBBTFRPIGNvdWxkIGJlIHVzZWQgdGhlcmUuDQoNCkNoZWVycw0KDQpGcmFuY29pcw0K DQoNCg0KDQoNCk9uIDE5IE9jdCAyMDExLCBhdCAyMzo1MiwgSmFuIFNlZWRvcmYgd3JvdGU6DQoN Cg0KDQpDRE5pIGZvbGtzLCBBTFRPIGZvbGtzLA0KDQpJIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBu ZXcgZHJhZnQgd2hpY2ggZGlzY3Vzc2VzIGhvdyBBTFRPIGNvdWxkIGhlbHAgaW4gQ0ROaSByZXF1 ZXN0IHJvdXRpbmc6DQoNCkFic3RyYWN0Og0K4oCc4oCmIFRoaXMgZG9jdW1lbnQgZm9jdXNzZXMg b24gdGhlIFJlcXVlc3QgUm91dGluZyBJbnRlcmZhY2Ugb2YgQ0ROaSwgYW5kIG1vcmUgc3BlY2lm aWNhbGx5IG9uIGhvdyB0aGUgc29sdXRpb25zIGN1cnJlbnRseSBiZWluZyBkZWZpbmVkIGluIHRo ZSBBcHBsaWNhdGlvbiBMYXllciBUcmFmZmljIE9wdGltaXphdGlvbiAoQUxUTykgV0cgY2FuIGlt cHJvdmUgQ0ROaSByZXF1ZXN0IHJvdXRpbmcuICBUaGUgb3ZlcmFsbCBpbnRlbnRpb24gYmVoaW5k IHRoaXMgZG9jdW1lbnQgaXMgdG8gZm9zdGVyIGRpc2N1c3Npb25zIChpbiB0aGUgQ0ROaSBhcyB3 ZWxsIGFzIGluIHRoZSBBTFRPIFdHKSByZWdhcmRpbmcgYSkgaWYsIGIpIGhvdywgYW5kIGMpIHVu ZGVyIHdoYXQgY29uZGl0aW9ucyBBTFRPIGNhbiBiZSB1c2VmdWwgdG8gb3B0aW1pemUgQ0ROaSBy ZXF1ZXN0IHJvdXRpbmcuICBBcyBiYXNpcyBmb3IgdGhpcyBkaXNjdXNzaW9uLCB0aGlzIGRvY3Vt ZW50IHByb3ZpZGVzIGNvbmNyZXRlIGV4YW1wbGVzIG9mIGhvdyBBTFRPIGNhbiBiZSBpbnRlZ3Jh dGVkIHdpdGhpbiBDRE5pIHJlcXVlc3Qgcm91dGluZy4gIFRoZSBleGFtcGxlcyBpbiB0aGlzICAg ZG9jdW1lbnQgYXJlIGJhc2VkIG9uIHRoZSB1c2UgY2FzZXMgYW5kIGV4YW1wbGVzIGN1cnJlbnRs eSBiZWluZyBkaXNjdXNzZWQgaW4gdGhlIENETmkgV0cu4oCdDQoNCmh0dHA6Ly93d3cuaWV0Zi5v cmcvaWQvZHJhZnQtc2VlZG9yZi1hbHRvLWZvci1jZG5pLTAwLnR4dA0KDQpDb21tZW50cyAoZnJv bSBDRE5pIFdHIGFuZCBBTFRPIFdHKSBhcmUgd2VsY29tZSwNCg0KLSAgICAgICAgICBKYW4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDRE5pIG1haWxp bmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQoNCg0KW2NpZDppbWFnZTAwMS5qcGdA MDFDQ0EzN0QuMTI3QkUyNTBdDQoNCg0KDQpGcmFuY29pcyBMZSBGYXVjaGV1cg0KRGlzdGluZ3Vp c2hlZCBFbmdpbmVlcg0KQ29ycG9yYXRlIERldmVsb3BtZW50DQpmbGVmYXVjaEBjaXNjby5jb208 bWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbT4NClBob25lOiArMzMgNDkgNzIzIDI2MTkNCk1vYmls ZTogKzMzIDYgMTkgOTggNTAgOTANCg0KDQoNCkNpc2NvIFN5c3RlbXMgRnJhbmNlDQpHcmVlbnNp ZGUNCjQwMCBBdmUgZGUgUm91bWFuaWxsZQ0KMDY0MTAgU29waGlhIEFudGlwb2xpcw0KRnJhbmNl DQpDaXNjby5jb208aHR0cDovL3d3dy5jaXNjby5jb20+DQoNCg0KDQoNCltjaWQ6aW1hZ2UwMDIu Z2lmQDAxQ0NBMzdELjEyN0JFMjUwXQ0KDQogVGhpbmsgYmVmb3JlIHlvdSBwcmludC4NCg0KDQpU aGlzIGVtYWlsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlh bCBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcs IHVzZSwgZGlzdHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGF1dGhv cml6ZWQgdG8gcmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksIHBsZWFzZSBjb250YWN0IHRoZSBz ZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlbGV0ZSBhbGwgY29waWVzIG9mIHRoaXMgbWVzc2Fn ZS4NCg0KQ2lzY28gU3lzdGVtcyBGcmFuY2UsIFNvY2nDqXTDqSDDoCByZXNwb25zYWJpaXTDqSBs aW1pdMOpZSwgUnVlIENhbWlsbGUgRGVzbW91bGlucyDigJMgSW1tIEF0bGFudGlzIFphYyBGb3J1 bSBTZWluZSBJbG90IDcgOTIxMzAgSXNzeSBsZXMgTW91bGluZWF1eCwgQXUgY2FwaXRhbCBkZSA5 MS40NzAg4oKsLCAzNDkgMTY2IDU2MSBSQ1MgTmFudGVycmUsIERpcmVjdGV1ciBkZSBsYSBwdWJs aWNhdGlvbjogSmVhbi1MdWMgTWljaGVsIEdpdm9uZS4NCg0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBp bmZvcm1hdGlvbiBnbyB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19i dXNpbmVzcy9sZWdhbC9jcmkvaW5kZXguaHRtbA0KDQoNCg0K --_000_2779C9F0771F974CAD742BAE6D9904FE24E80A3BPolydeucesoffic_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPGJhc2Ug aHJlZj0ieC1tc2c6Ly8yNTYvIj48IS0tW2lmICFtc29dPjxzdHlsZT52XDoqIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3 XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgj ZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQg RGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUaW1l czsNCglwYW5vc2UtMToyIDIgNiAzIDUgNCA1IDIgMyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uYXBwbGUtc3R5bGUtc3Bhbg0K CXttc28tc3R5bGUtbmFtZTphcHBsZS1zdHlsZS1zcGFuO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4N Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQt c3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25U ZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTEzMTQ3OTE3MjsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE1MDk4MDczMTIgMjA4Mzk1 Mjc2NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjIwLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6Q2FsaWJyaTt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjU2LjI1cHQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjkyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MTI4LjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE2NC4yNXB0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgltYXJnaW4tbGVmdDoyMDAuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoy MzYuMjVwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjcyLjI1cHQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CW1hcmdpbi1sZWZ0OjMwOC4yNXB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RGVhciBGcmFuY29pcyw8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J IGFjdHVhbGx5IGFncmVlIHdpdGggbW9zdCBvZiB5b3VyIHBvaW50cy4gUGxlYXNlIGZpbmQgbXkg cmVwbHkgaW5saW5lIGJlbG934oCmPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztmb250 LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250IHNpemU9IjIiIGZhY2U9 IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBGcmFuY29pcw0KIExlIEZhdWNo ZXVyIFttYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9u dC13ZWlnaHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAxNSwgMjAx MSAxOjA0IEFNPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bh bj48L2I+IEphbiBTZWVkb3JmPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi PkNjOjwvc3Bhbj48L2I+IEZyYW5jb2lzIExlIEZhdWNoZXVyOyBjZG5pQGlldGYub3JnPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6 IFtDRE5pXSBEcmFmdCBzdWJtaXR0ZWQgb24gQUxUTyBmb3IgQ0ROaSByZXF1ZXN0IHJvdXRpbmc8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5PbiAxNCBOb3YgMjAxMSwgYXQgMTQ6MzMsIEphbiBTZWVkb3JmIHdyb3RlOjxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+RGVhciBGcmFuY29pcyw8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3Mg Zm9yIHlvdXIgY29tbWVudHMgb24gdGhlIGRyYWZ0LiBQbGVhc2UgZmluZCBteSBhbnN3ZXJzIGJl bG93IGlubGluZTo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9 IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9InJlZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+UmVnYXJkaW5nIChpKSwgaXQgaXMg bm90IGNsZWFyIHRvIG1lIHRoYXQgYWxsb3cgc2VsZWN0aW9uIG9mIGRDRE4gU3Vycm9nYXRlIGRp cmVjdGx5IGJ5IHRoZSB1Q0ROIHJlcXVlc3Qgcm91dGVyIGlzIGEgZGVzaXJhYmxlDQogZ29hbCBj b25zaWRlcmluZyB0aGUgY29tYmluYXRpb24gb2YgdGhlIGZvbGxvd2luZzo8L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9InJlZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChh KSB0aGUgV29ya2luZyBHcm91cCBoYXMgYWdyZWVkIHRoYXQgdGhlIHNvbHV0aW9uIHNob3VsZCBu b3QgcmVseSBvbiBkQ0ROIGV4cG9zaW5nIHRvbyBtdWNoICZxdW90O2ludGVybmFsJnF1b3Q7DQog aW5mb3JtYXRpb246PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJyZWQiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmcXVvdDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9InJlZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdFTi00Jm5ic3A7Jm5ic3A7IFtISUdIXSBUaGUgQ0ROSSBz b2x1dGlvbiBzaGFsbCBub3QgcmVxdWlyZSBpbnRyYS1DRE48L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9InJlZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIHRvIGJlIGV4cG9zZWQgdG8gb3RoZXIgQ0ROcyBm b3IgZWZmZWN0aXZlIGFuZDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0icmVkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZWZm aWNpZW50IGRlbGl2ZXJ5IG9mIHRoZSBjb250ZW50LiZuYnNwOyBFeGFtcGxlcyBvZiBpbnRyYS1D RE48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9InJlZCIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIGluY2x1 ZGUgc3Vycm9nYXRlIHRvcG9sb2d5LCBzdXJyb2dhdGUgc3RhdHVzLDwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBjb2xvcj0icmVkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgY2FjaGVkIGNvbnRlbnQsIGV0Yy48L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9InJlZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZxdW90Ozwvc3Bhbj48L2ZvbnQ+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkphbjogQWN0dWFsbHksIEFMVE8gaXMgZGVzaWduZWQg aW4gYSB3YXkgdGhhdCBsZWF2ZXMgdGhlIGRlZ3JlZSBvZiBkZXRhaWwgYmVpbmcgZGlzY2xvc2Vk IHRocm91Z2ggQUxUTyBpbmZvcm1hdGlvbg0KIGF0IHRoZSBBTFRPIHNlcnZlcuKAmXMgKGkuZS4g aW4gdGhpcyBjYXNlIGF0IHRoZSBkQ0RO4oCZcykgZGlzY3JldGlvbi4gVG8gYmUgY29uY3JldGUs IEFMVE8gaXMgZXhhY3RseSBhIHdheSB0byByZWNvbW1lbmQgYSBzdXJyb2dhdGUgd2l0aG91dCBk aXNjbG9zaW5nIHRoZSBpbnRlcmlvciB0b3BvbG9neSBvZiB0aGUgZENETi48L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgY29sb3I9InJlZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOnJlZCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IChiKSBpbiBnZW5l cmFsLCBzZWxlY3Rpb24gb2YgZENETiBTdXJyb2dhdGUgaXMgbGlrZWx5IHRvIGRlcGVuZCBvbiBh IG51bWJlciBvZiBjcml0ZXJpYSwgaW5jbHVkaW5nIGNyaXRlcmlhDQogYmV5b25kIG5ldHdvcmsg cHJveGltaXR5IGluZm9ybWF0aW9uIChlLmcuIFN1cnJvZ2F0ZSBjYWNoZS9yZXNvdXJjZS9zdGF0 dXMgY29uc2lkZXJhdGlvbnMpLCBkbyBJIGRvbid0IHRoaW5rIHRoYXQgZXhwb3NpbmcgZENETiBw cm94aW1pdHkgaW5mb3JtYXRpb24gdG8gdUNETiB3b3VsZCBiZSBzdWZmaWNpZW50LiBJbiBmYWN0 LCBJIHNlZSB0aGF0IHlvdSBoYXZlIG5vdGljZWQgdGhhdCBwb2ludCBzaW5jZSB5b3VyIGRyYWZ0 IGRvZXMgbWVudGlvbjo8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9InJlZCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOnJlZCI+JnF1b3Q7QW4g aW1wbGljaXQgYXNzdW1wdGlvbiBmb3IgdGhlIGV4YW1wbGUgaW4gRmlndXJlIDEgdG8gd29yayBp cyB0aGF0IHRoZSBDRE4gZW50cnkgcG9pbnQgZm9yIHRoZSBkb3duc3RyZWFtIENETiBvbmx5IGRl cGVuZHMNCiBvbiB0aGUgbG9jYXRpb24gb2YgdGhlIGVuZCB1c2VyLiZxdW90Ozwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIyIiBjb2xvcj0icmVkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6cmVkIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29s b3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5KYW46IE1heWJlIEkgc2hvdWxkIGNsYXJpZnkgKEkgdGhpbmsgaXQgc2F5 cyBzb21laG93IGluIHRoZSBkcmFmdCBhcyB3ZWxsKSB0aGF0IHRoZSBkcmFmdCBkb2VzIG5vdCBw cm9wb3NlIHRvDQogaGF2ZSBBTFRPIGFzIHRoZSBDRE5pIHJlcXVlc3Qgcm91dGluZyBpdHNlbGYs PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5idXQgcmF0aGVyIHRoYXQgQUxUTyBjYW4gYmUgYSBwYXJ0IG9mIGl0Lg0KPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5 N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IYXZpbmcgc2FpZCB0aGF0LCBJIHRoaW5rIHRoYXQgdGhlIGRhdGEgY29udGFpbmVkIGlu IGFuIEFMVE8gY29zdCBtYXAgY291bGQgYmUgYSBjb21iaW5hdGlvbiBvZiBwcm94aW1pdHkvc3Rh dHVzL290aGVyDQogY3JpdGVyaWEsIGFnYWluIGJlaW5nIGNvbWJpbmVkIHRvdGFsbHkgYXQgdGhl IGRDRE5zIGRpc2NyZXRpb24gYW5kIHdpdGhvdXQgZGlzY2xvc2luZyB0aGVzZSBkZXRhaWxzIHRv IHRoZSB1Q0ROLiBUaGUgQUxUTyBjb3N0IHZhbHVlIHdvdWxkIGp1c3QgYmUgYSBtZWFucyB0byBz aWduYWwgdG8gdGhlIHVDRE4gd2hpY2ggc3Vycm9nYXRlIGlzIHByZWZlcnJlZCBmcm9tIHRoZSBk Q0ROcyBwZXJzcGVjdGl2ZS48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+TGV0J3Mgc2F5IGZvciBhcmd1bWVudCBz YWtlIHRoYXQgdGhlIGRDRE4gd2FudHMgdG8gc2VsZWN0IGEgc3Vycm9nYXRlIHRha2luZyBpbnRv IGFjY291bnQgMyBtZXRyaWNzOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4i Pjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+KiBNZXRyaWMtMSB0aGF0IGRlcGVuZHMg b24gZW5kdXNlciBJUCBhZGRyZXNzIGFuZCBpcyBmYWlybHkgc3RhdGljPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUt dGFiLXNwYW4iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvZm9udD48L3NwYW4+KiBNZXRyaWMtMiB0aGF0 IGRlcGVuZHMgb24gdGhlIGNvbnRlbnQgVVJJIChiZWNhdXNlIGRDRE4gd2FudHMgdG8gaW5jcmVh c2UgY2FjaGUgaGl0IHJhdGlvKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj48Zm9udCBzaXplPSIz IiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L2ZvbnQ+PC9zcGFuPiogTWV0cmljLTMgdGhhdCBpcyBmYWlybHkgZHluYW1pYyAoZWcm bmJzcDtTdXJyb2dhdGUgbG9hZCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ QXNzdW1pbmcgdGhlIGRDRE4gaXMgd2lsbGluZyB0byBtYWtlIHRoaXMgaW5mb3JtYXRpb24gdmlz aWJsZSwgSSBjYW4gc2VlIHRoYXQgdGhlIGRDRE4gY291bGQgcHJvdmlkZSBhIG5ldHdvcmsgbWFw IHRoYXQgd291bGQgYWxsb3cgdUNETiB0byB0YWtlIGludG8gYWNjb3VudCBNZXRyaWMtMS48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkRvIHlvdSBhZ3Jl ZSB0aGF0IEFMVE8gaXRzZWxmIHdvdWxkIG5vdCBuYXR1cmFsbHkgYWxsb3cgdUNETiB0byBmYWN0 b3IgTWV0cmljLTIgYW5kIE1ldHJpYy0zPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BbmQgZXZlbiB3 aGV0aGVyIGl0IGlzIEFMVE8gb3Igc29tZXRoaW5nIGVsc2UsIHdvdWxkIHlvdSBhZ3JlZSB0aGF0 IGEgc29sdXRpb24gYWxsb3dpbmcgdUNETiB0byBmYWN0b3IgaW4gc29tZXRoaW5nIGxpa2UgTWV0 cmljLTMgd291bGQgcHJvYmFibHkgaW52b2x2ZSBleHBvc2luZyBxdWl0ZQ0KIGEgYml0IG9mIGRD RE4gaW5mb3JtYXRpb24gYW5kIHVwZGF0aW5nIGl0IHZlcnkgZnJlcXVlbnRseT88bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMwMDk5MDAiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzAw OTkwMCI+SmFuOiBZZXMsIEkgYWdyZWUuIEFMVE8gaXMg4oCTIGFzIGRlc2NyaWJlZCBpbiBSRkMg NTY5MyDigJMgZm9yIGluZm9ybWF0aW9uIHRoYXQgZG9lcyBub3QgY2hhbmdlIGZyZXF1ZW50bHkg KFJGQyA1NjkzOiDigJxUaGUga2luZCBvZiBpbmZvcm1hdGlvbg0KIHRoYXQgaXMgbWVhbmluZ2Z1 bCB0byBjb252ZXkgdG8gYXBwbGljYXRpb25zIHZpYSBhbiBvdXQtb2YtYmFuZCBBTFRPIHNlcnZp Y2UgaXMgYW55IGluZm9ybWF0aW9uIHRoYXQgYXBwbGljYXRpb25zIGNhbm5vdCBlYXNpbHkgb2J0 YWluIHRoZW1zZWx2ZXMgYW5kIHRoYXQgY2hhbmdlcyBvbiBhIG11Y2ggbG9uZ2VyIHRpbWUgc2Nh bGUgdGhhbiB0aGUgaW5zdGFudGFuZW91cyBpbmZvcm1hdGlvbiB1c2VkIGZvciBjb25nZXN0aW9u IGNvbnRyb2wgb24NCiB0aGUgdHJhbnNwb3J0IGxheWVy4oCdKS4gRXNwZWNpYWxseSBtZXRyaWMt MiBpcyBkZWZpbml0ZWx5IHNvbWV0aGluZyBBTFRPIGNhbm5vdCBwcm92aWRlLCBhbmQgbWV0cmlj IDMgaWYgaXQgaXMg4oCcZmFpcmx54oCdIGR5bmFtaWMgaXMgb3V0IG9mIHNjb3BlIGZvciBBTFRP Ljxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSJyZWQiIGZhY2U9IkNhbGlicmkiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpyZWQiPlJlZ2FyZGluZyAoaWkpLCBJIGJl bGlldmUgZmFjaWxpdGF0aW5nIGRDRE4gc2VsZWN0aW9uIGJ5IHVDRE4gaXMgaW5kZWVkIGEgc3Ry b25nIGdvYWwsIGJ1dCB0aGUgZHJhZnQgZG9lcyBub3QgeWV0IGRpc2N1c3MNCiBkZXRhaWxzIG9m IGhvdyBBTFRPIGNvdWxkIGJlIHVzZWQgdGhlcmUuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNv bG9yPSJyZWQiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpyZWQiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkph bjogaW5kZWVkLCB0aGlzIG5lZWRzIHRvIGJlIGRldGFpbGVkIGluIGZ1dHVyZSB2ZXJzaW9ucyBv ZiB0aGUgZHJhZnQuIE9uZSBleGFtcGxlIHdvdWxkIGJlIHRoYXQgQUxUTyBtYXBzIGZyb20NCiBz ZXZlcmFsIGNhbmRpZGF0ZSBkQ0ROcyBjb3VsZCBwcm92aWRlIGluZm9ybWF0aW9uIHRvIHRoZSB1 Q0ROIG9mIHRoZSBmb290cHJpbnQgb2YgdGhlc2UgZENETnMgb3IgaG93IGNsb3NlIHRvIHRoZSBl bmQgdXNlciBlYWNoIGRDRE4gY2FuIG9mZmVyIGEgc3Vycm9nYXRlLiBCdXQgc3VjaCB1c2UgY2Fz ZXMgbmVlZCB0byBiZSB0aG91Z2h0IHRocm91Z2ggYSBiaXQgbW9yZS48L3NwYW4+PC9mb250Pjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg Y29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5JIGhvcGUgbXkgYW5zd2VycyBjbGFyaWZpZWQgYSBiaXQsIGVzcGVj aWFsbHkgdGhhdCBBTFRPIGluZm9ybWF0aW9uIGNhbiBiZSB1c2VkIGluIGEgd2F5IHRoYXQgaXQg ZG9lcyBub3QgZGlzY2xvc2UNCiAodG9vIG1hbnkpIGRldGFpbHMgb2YgdGhlIG5ldHdvcmsgdG9w b2xvZ3kuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPlNlZSBhYm92ZS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SSB3b3VsZCBhZ3JlZSB0aGF0 LCBfaWYgd2Ugd2FudCB0byBzdXBwb3J0IGEgc29sdXRpb24gd2hlcmUgdGhlIHVDRE4gcGVyZm9y bXMgZENETiBzdXJyb2dhdGUgc2VsZWN0aW9uXywgdGhlbiBBTFRPIGNvdWxkIGJlIHVzZWQgdG8g cHJvdmlkZSBfc29tZV8gYmFzaWMgaW5mbyB0aGF0IGNvdWxkDQogYmUgdXNlZCBieSB0aGUgdUNE TiBpbiB0aGUgZENETiBTdXJyb2dhdGUgc2VsZWN0aW9uLiBCdXQgYmVjYXVzZSBzdXJyb2dhdGUg c2VsZWN0aW9uIGluIGEgQ0ROIGlzIGEgc29waGlzdGljYXRlZCBtdWx0aS1kaW1lbnNpb24gZHlu YW1pYyB2ZW5kb3Itc3BlY2lmaWMgZGVjaXNpb24sIEkgYW0gbm90IGNvbnZpbmNlZCB0aGF0IGl0 IGlzIHBvc3NpYmxlIHRvIGNvbnZleSB0byB0aGUgdUNETiB0aGUgX3Jlc3RfIG9mIHRoZSBpbmZv IHRoYXQgaXMgcmVhbGx5DQogbmVlZGVkIHRvIG1ha2UgdGhlIGNvbXBsZXRlIHN1cnJvZ2F0ZSBz ZWxlY3Rpb24gaW4gYSB3YXkgdGhhdCBpcyBzY2FsYWJsZSwgZnJlc2gtZW5vdWdoLCBjb3ZlcnMg YWxsIHRoZSBmYW5jeSBzZWxlY3Rpb24gY3JpdGVyaWEgb3V0IHRoZXJlIGFuZCBhdCB0aGUgc2Ft ZSB0aW1lIGVuc3VyZXMgdGhlIGRDRE4gZG9lcyBub3QgZXhwb3NlIG1vcmUgdGhhbiBpdCB3aXNo ZXMuIEluIG90aGVyIHdvcmRzIEkgZG9uJ3QgdGhpbmsgaXQgaXMgcmVhbGlzdGljDQogdG8gZXhw ZWN0IHRoYXQgdUNETiBjYW4gZG8gZENETiBzdXJyb2dhdGUgc2VsZWN0aW9uIG9uIGJlaGFsZiBv ZiBkQ0ROLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5JJ20gaW50ZXJlc3RlZCBpbiBvdGhlciBvcGlu aW9ucyBoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBjb2xvcj0iIzAwOTkwMCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDk5MDAiPkphbjogSSB0aGluayB3ZSBoYXZlIHRvIHNlcGFy YXRlIOKAnHN1cnJvZ2F0ZSBzZWxlY3Rpb27igJ0gYW5kIOKAnENETiBlbnRyeSBwb2ludOKAnSBz ZWxlY3Rpb24uIExldOKAmXMgYXNzdW1lIGEgZENETiBpbg0KIHRoZSBVUyBkb2VzIG5vdCB3YW50 IGFsbCByZXF1ZXN0cyBmcm9tIG90aGVyIGNvdW50cmllc+KAmSB1Q0ROcyB0byBhcnJpdmUgYXQg YSBzaW5nbGUgZ2F0ZXdheSwgYnV0IGhhcyBzZXZlcmFsIOKAnGVudHJ5IHBvaW50c+KAnSBmb3Ig cmVxdWVzdHMgZnJvbSBhIHVDRE4sIHNheSBmb3Igc2ltcGxpY2l0eSBpbiBTZWF0dGxlLCBPcmxh bmRvLCBMb3MgQW5nZWxlcywgYW5kIE5ldyBZb3JrLiBIZXJlIEkgY2FuIHNlZSBob3cgcHJvdmlk aW5nIGFuIEFMVE8gbWFwDQogdG8gdUNETnMgY2FuIGhlbHAgdGhlc2UgdUNETnMgdG8gZGVjaWRl IHdoZXJlIHRvIGRpcmVjdCByZXF1ZXN0cyB0byAoaS5lLiB0byB3aGljaCBlbnRyeSBwb2ludCBv dXQgb2Ygc2V2ZXJhbCBjYW5kaWRhdGUgb25lcykgZGVwZW5kaW5nIG9uIHRoZSBsb2NhdGlvbiAo aS5lLiBJUCBhZGRyZXNzKSBvZiB0aGUgZW5kIHVzZXIuIEZvciBpbnN0YW5jZSwgYSB1Q0ROIGNv dWxkIHVzZSBBTFRPIGluZm9ybWF0aW9uIHRvIGRlY2lkZSB0byB3aGljaCBlbnRyeQ0KIHBvaW50 IG9mIHRoZSBkQ0ROIGl0IHdvdWxkIGRpcmVjdCBhIHJlcXVlc3QgY29taW5nIGZyb20gYW4gZW5k IHVzZXIgaW4gU3QuIExvdWlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwOTkwMCIgZmFjZT0iQ2FsaWJy aSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDk5MDAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzAwOTkwMCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMwMDk5MDAiPkZpbmFsbHksIEkgYW0gb2YgY291cnNlIGFsc28gaW50ZXJl c3RlZCBpbiBvdGhlciBvcGluaW9ucyBmcm9tIHRoZSBXRy48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMwMDk5 MDAiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMDA5 OTAwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoyMC4yNXB0O3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzAwOTkwMCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMwMDk5MDAiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08 Zm9udCBzaXplPSIxIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9mb250Pjwvc3Bhbj48L3Nw YW4+PC9mb250PjwhW2VuZGlmXT48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzAwOTkwMCIgZmFjZT0i Q2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDk5MDAiPkphbjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5DaGVl cnM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkZyYW5j b2lzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluIj48Zm9udCBzaXpl PSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPi08L3NwYW4+PC9mb250Pjxmb250IHNpemU9IjEiIGNvbG9y PSIjMWY0OTdkIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9mb250 Pjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SmFuPC9zcGFuPjwvZm9udD48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9y PSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci13aWR0aDppbml0aWFsO2JvcmRlci1jb2xvcjpp bml0aWFsIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjtib3JkZXItd2lkdGg6aW5p dGlhbDtib3JkZXItY29sb3I6aW5pdGlhbCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iVGFob21hIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztmb250LXdlaWdodDpib2xkIj5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxmb250IHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxmb250IHNp emU9IjIiIGZhY2U9IlRhaG9tYSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyYW5jb2lz DQogTGUgRmF1Y2hldXIgPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29t XSI+W21haWx0bzpmbGVmYXVjaEBjaXNjby5jb21dPC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+U2VudDo8L3NwYW4+PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj5Nb25kYXksIE5vdmVtYmVyIDE0LCAyMDExIDExOjA5IEFNPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkphbiBTZWVkb3JmPGJyPg0K PGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkNjOjwvc3Bhbj48L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpj ZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPjxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbQ0ROaV0gRHJhZnQgc3VibWl0dGVkIG9uIEFM VE8gZm9yIENETmkgcmVxdWVzdCByb3V0aW5nPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhlbGxvIEphbiw8bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPihhcyBhbiBpbmRpdmlkdWFsKTxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+SSB1bmRlcnN0YW5kIHRoYXQgeW91ciBkb2N1bWVudCA6PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48 L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPihp KSBkaXNjdXNzZXMgaG93IEFMVE8gY291bGQgYmUgdXNlZCB0byBlZmZlY3RpdmVseSBhbGxvdyBz ZWxlY3Rpb24NCiBvZiBkQ0ROIFN1cnJvZ2F0ZSBkaXJlY3RseSBieSB0aGUgdUNETiByZXF1ZXN0 IHJvdXRlciwgQU5EPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxmb250 IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj4oaWkpIG1lbnRpb25zIHRoYXQgQUxUTyBjb3VsZCBwb3RlbnRpYWxs eSBiZSB1c2VkIHRvIGZhY2lsaXRhdGUNCiBkQ0ROIHNlbGVjdGlvbiBieSB1Q0ROLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PlJlZ2FyZGluZyAoaSksIGl0IGlzIG5vdCBjbGVhciB0byBtZSB0aGF0IGFsbG93IHNlbGVjdGlv biBvZiBkQ0ROIFN1cnJvZ2F0ZSBkaXJlY3RseSBieSB0aGUgdUNETiByZXF1ZXN0IHJvdXRlciBp cyBhIGRlc2lyYWJsZSBnb2FsIGNvbnNpZGVyaW5nIHRoZSBjb21iaW5hdGlvbiBvZiB0aGUNCiBm b2xsb3dpbmc6PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWIt c3BhbiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPihhKSB0aGUgV29ya2luZyBHcm91cCBoYXMgYWdy ZWVkIHRoYXQgdGhlIHNvbHV0aW9uIHNob3VsZCBub3QgcmVseQ0KIG9uIGRDRE4gZXhwb3Npbmcg dG9vIG11Y2ggJnF1b3Q7aW50ZXJuYWwmcXVvdDsgaW5mb3JtYXRpb246Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwv c3Bhbj48L2ZvbnQ+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+ PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkdFTi00ICZuYnNwOyBbSElHSF0gVGhlIENETkkgc29sdXRp b24gc2hhbGwgbm90IHJlcXVpcmUgaW50cmEtQ0ROPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtpbmZvcm1hdGlvbiB0byBiZSBleHBvc2VkIHRvIG90aGVyIENE TnMgZm9yIGVmZmVjdGl2ZSBhbmQ8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2VmZmljaWVudCBkZWxpdmVyeSBvZiB0aGUgY29udGVudC4gJm5ic3A7RXhhbXBs ZXMgb2YgaW50cmEtQ0ROPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtpbmZvcm1hdGlvbiBpbmNsdWRlIHN1cnJvZ2F0ZSB0b3BvbG9neSwgc3Vycm9nYXRlIHN0 YXR1cyw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2NhY2hl ZCBjb250ZW50LCBldGMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxm b250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9zcGFuPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj4mcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGNsYXNzPSJhcHBsZS10YWItc3BhbiI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvZm9udD48L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPihiKSBpbiBnZW5l cmFsLCBzZWxlY3Rpb24gb2YgZENETiBTdXJyb2dhdGUgaXMgbGlrZWx5IHRvIGRlcGVuZA0KIG9u IGEgbnVtYmVyIG9mIGNyaXRlcmlhLCBpbmNsdWRpbmcgY3JpdGVyaWEgYmV5b25kIG5ldHdvcmsg cHJveGltaXR5IGluZm9ybWF0aW9uIChlLmcuIFN1cnJvZ2F0ZSBjYWNoZS9yZXNvdXJjZS9zdGF0 dXMgY29uc2lkZXJhdGlvbnMpLCBkbyBJIGRvbid0IHRoaW5rIHRoYXQgZXhwb3NpbmcgZENETiBw cm94aW1pdHkgaW5mb3JtYXRpb24gdG8gdUNETiB3b3VsZCBiZSBzdWZmaWNpZW50LiBJbiBmYWN0 LCBJIHNlZSB0aGF0IHlvdSBoYXZlIG5vdGljZWQNCiB0aGF0IHBvaW50IHNpbmNlIHlvdXIgZHJh ZnQgZG9lcyBtZW50aW9uOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+JnF1b3Q7QW4gaW1wbGljaXQg YXNzdW1wdGlvbiBmb3IgdGhlIGV4YW1wbGUgaW4gRmlndXJlIDEgdG8gd29yayBpcyB0aGF0IHRo ZSBDRE4gZW50cnkgcG9pbnQgZm9yIHRoZSBkb3duc3RyZWFtIENETiBvbmx5IGRlcGVuZHMgb24g dGhlIGxvY2F0aW9uIG9mIHRoZSBlbmQgdXNlci4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5SZWdhcmRpbmcgKGlp KSwgSSBiZWxpZXZlJm5ic3A7ZmFjaWxpdGF0aW5nIGRDRE4gc2VsZWN0aW9uIGJ5IHVDRE4gaXMg aW5kZWVkIGEgc3Ryb25nIGdvYWwsIGJ1dCB0aGUgZHJhZnQgZG9lcyBub3QgeWV0IGRpc2N1c3Mg ZGV0YWlscyBvZiBob3cgQUxUTyBjb3VsZCBiZSB1c2VkIHRoZXJlLjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5GcmFuY29pczxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5PbiAxOSBPY3QgMjAxMSwgYXQgMjM6NTIsIEphbiBTZWVkb3JmIHdyb3RlOjxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q0ROaSBmb2xrcywgQUxUTyBmb2xr cyw8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMxZjQ5N2Qi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5JIGhhdmUganVzdCBzdWJtaXR0ZWQgYSBuZXcgZHJhZnQgd2hpY2ggZGlzY3Vzc2Vz IGhvdyBBTFRPIGNvdWxkIGhlbHAgaW4gQ0ROaSByZXF1ZXN0IHJvdXRpbmc6PC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdkIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QWJzdHJh Y3Q6PC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGNvbG9yPSIjMWY0OTdk IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+4oCc4oCmIFRoaXMgZG9jdW1lbnQgZm9jdXNzZXMgb24gdGhlIFJlcXVlc3QgUm91dGluZyBJ bnRlcmZhY2Ugb2YgQ0ROaSwgYW5kIG1vcmUgc3BlY2lmaWNhbGx5IG9uIGhvdyB0aGUgc29sdXRp b25zDQogY3VycmVudGx5IGJlaW5nIGRlZmluZWQgaW4gdGhlIEFwcGxpY2F0aW9uIExheWVyIFRy YWZmaWMgT3B0aW1pemF0aW9uIChBTFRPKSBXRyBjYW4gaW1wcm92ZSBDRE5pIHJlcXVlc3Qgcm91 dGluZy4mbmJzcDsgVGhlIG92ZXJhbGwgaW50ZW50aW9uIGJlaGluZCB0aGlzIGRvY3VtZW50IGlz IHRvIGZvc3RlciBkaXNjdXNzaW9ucyAoaW4gdGhlIENETmkgYXMgd2VsbCBhcyBpbiB0aGUgQUxU TyBXRykgcmVnYXJkaW5nIGEpIGlmLCBiKSBob3csIGFuZCBjKSB1bmRlcg0KIHdoYXQgY29uZGl0 aW9ucyBBTFRPIGNhbiBiZSB1c2VmdWwgdG8gb3B0aW1pemUgQ0ROaSByZXF1ZXN0IHJvdXRpbmcu Jm5ic3A7IEFzIGJhc2lzIGZvciB0aGlzIGRpc2N1c3Npb24sIHRoaXMgZG9jdW1lbnQgcHJvdmlk ZXMgY29uY3JldGUgZXhhbXBsZXMgb2YgaG93IEFMVE8gY2FuIGJlIGludGVncmF0ZWQgd2l0aGlu IENETmkgcmVxdWVzdCByb3V0aW5nLiZuYnNwOyBUaGUgZXhhbXBsZXMgaW4gdGhpcyZuYnNwOyAm bmJzcDtkb2N1bWVudCBhcmUgYmFzZWQgb24gdGhlIHVzZSBjYXNlcw0KIGFuZCBleGFtcGxlcyBj dXJyZW50bHkgYmVpbmcgZGlzY3Vzc2VkIGluIHRoZSBDRE5pIFdHLuKAnTwvc3Bhbj48L2ZvbnQ+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2Fs aWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9 Imh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtc2VlZG9yZi1hbHRvLWZvci1jZG5pLTAwLnR4 dCI+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1zZWVkb3JmLWFsdG8tZm9yLWNkbmktMDAu dHh0PC9hPjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFm NDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xv cj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkNvbW1lbnRzIChmcm9tIENETmkgV0cgYW5kIEFMVE8gV0cpIGFyZSB3ZWxj b21lLDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBjb2xvcj0iIzFmNDk3 ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6MjAuMjVwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbiI+PGZvbnQgc2l6ZT0iMiIgY29sb3I9IiMx ZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4tPC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzFmNDk3ZCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvZm9udD48Zm9udCBzaXplPSIy IiBjb2xvcj0iIzFmNDk3ZCIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkphbjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0ROaSBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Q0ROaUBpZXRmLm9yZyI+Q0ROaUBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NkbmkiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaTwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjMiIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIzIiBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+DQo8dGFibGUgY2xhc3M9 Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0i MCIgd2lkdGg9IjU0MyIgc3R5bGU9IndpZHRoOjQwNy4yNXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0 ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMyIgY29sb3I9IiMxZjQ5N2QiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjE1 NCIgaGVpZ2h0PSIxMDAiIGlkPSJfeDAwMzZfMjA0YjQ3MC1iNDc4LTQzYTAtYTYxOC1lMDU4NmQ1 MDkyMDYiIHNyYz0iY2lkOmltYWdlMDAxLmpwZ0AwMUNDQTM3RC4xMjdCRTI1MCI+PC9zcGFuPjwv Zm9udD48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PGZvbnQgc2l6ZT0iNCIgY29sb3I9 ImJsYWNrIiBmYWNlPSJUaW1lcyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMy41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMmcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSI1NDMiIHN0eWxlPSJ3aWR0aDo0MDcuMjVwdDtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6aW5pdGlh bDstd2Via2l0LWJhY2tncm91bmQtY2xpcDogaW5pdGlhbDstd2Via2l0LWJhY2tncm91bmQtb3Jp Z2luOiBpbml0aWFsO2JhY2tncm91bmQtY29sb3I6aW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDpu by1yZXBlYXQ7YmFja2dyb3VuZC1wb3NpdGlvbi14OjUwJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6 MCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+ PC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Zm9udCBzaXplPSI0IiBjb2xvcj0iYmxhY2si IGZhY2U9IlRpbWVzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjaztkaXNwbGF5Om5v bmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3NwYW4+PC9wPg0KPHRhYmxlIGNs YXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRp bmc9IjAiIHdpZHRoPSI1NDMiIHN0eWxlPSJ3aWR0aDo0MDcuMjVwdDtiYWNrZ3JvdW5kLWF0dGFj aG1lbnQ6aW5pdGlhbDstd2Via2l0LWJhY2tncm91bmQtY2xpcDogaW5pdGlhbDstd2Via2l0LWJh Y2tncm91bmQtb3JpZ2luOiBpbml0aWFsO2JhY2tncm91bmQtY29sb3I6aW5pdGlhbDtiYWNrZ3Jv dW5kLXJlcGVhdDpuby1yZXBlYXQ7YmFja2dyb3VuZC1wb3NpdGlvbi14OjUwJTtiYWNrZ3JvdW5k LXBvc2l0aW9uLXk6MCUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRv cCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAxMS4yNXB0IC4yNWluIj4NCjxwIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGI+PGZvbnQgc2l6ZT0iMSIgY29sb3I9IiM2NjY2NjYiIGZhY2U9 IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzY2NjY2Njtmb250LXdlaWdo dDpib2xkIj48YnI+DQo8c3Ryb25nPjxiPjxmb250IGZhY2U9IkFyaWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJh bmNvaXMgTGUgRmF1Y2hldXI8L3NwYW4+PC9mb250PjwvYj48L3N0cm9uZz48L3NwYW4+PC9mb250 PjwvYj48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzY2NjY2NiIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2NjY2Ij48YnI+DQo8c3Ryb25nPjxiPjxmb250IGZh Y2U9IkFyaWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGlzdGluZ3Vpc2hlZCBFbmdpbmVlcjwvc3Bhbj48L2ZvbnQ+ PC9iPjwvc3Ryb25nPjxicj4NCjxzdHJvbmc+PGI+PGZvbnQgZmFjZT0iQXJpYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Db3Jwb3JhdGUgRGV2ZWxvcG1lbnQ8L3NwYW4+PC9mb250PjwvYj48L3N0cm9uZz48YnI+DQo8 YSBocmVmPSJtYWlsdG86ZmxlZmF1Y2hAY2lzY28uY29tIj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+ PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2NjYiPmZsZWZhdWNoQGNpc2NvLmNvbTwvc3Bhbj48L2Zv bnQ+PC9hPjxicj4NClBob25lOiZuYnNwOzxzdHJvbmc+PGI+PGZvbnQgZmFjZT0iQXJpYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4mIzQzOzMzIDQ5IDcyMyAyNjE5PC9zcGFuPjwvZm9udD48L2I+PC9zdHJvbmc+PGJy Pg0KTW9iaWxlOiZuYnNwOzxzdHJvbmc+PGI+PGZvbnQgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4m IzQzOzMzIDYgMTkgOTggNTAgOTA8L3NwYW4+PC9mb250PjwvYj48L3N0cm9uZz48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC90ZD4NCjx0ZCBub3dyYXA9IiIgdmFs aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gNy41cHQgMTUuMHB0Ij4NCjxwIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHN0cm9uZz48Yj48Zm9udCBzaXplPSIxIiBjb2xvcj0i IzY2NjY2NiIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojNjY2 NjY2Ij5DaXNjbyBTeXN0ZW1zIEZyYW5jZTwvc3Bhbj48L2ZvbnQ+PC9iPjwvc3Ryb25nPjxmb250 IHNpemU9IjEiIGNvbG9yPSIjNjY2NjY2IiBmYWNlPSJBcmlhbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPjxicj4NCkdyZWVuc2lkZTxicj4NCjQwMCBBdmUgZGUgUm91 bWFuaWxsZTxicj4NCjA2NDEwIFNvcGhpYSBBbnRpcG9saXM8YnI+DQpGcmFuY2U8YnI+DQo8YSBo cmVmPSJodHRwOi8vd3d3LmNpc2NvLmNvbSI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxzcGFuIHN0 eWxlPSJjb2xvcjojNjY2NjY2Ij5DaXNjby5jb208L3NwYW4+PC9mb250PjwvYT48bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC90ZD4NCjx0ZCB3aWR0aD0iMjAwIiBzdHlsZT0id2lkdGg6 MTUwLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Zm9udCBzaXplPSIzIiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9 IjQiIGNvbG9yPSJibGFjayIgZmFjZT0iSGVsdmV0aWNhIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGltZyBib3JkZXI9IjAiIHdpZHRoPSIxOCIgaGVp Z2h0PSIxOSIgaWQ9ImU0MDBmNWQwLTE3ZmQtNGUzYy1hZDM0LWE0NDFkMWNmZjIzMyIgc3JjPSJj aWQ6aW1hZ2UwMDIuZ2lmQDAxQ0NBMzdELjEyN0JFMjUwIj48L3NwYW4+PC9mb250PjxzcGFuIGNs YXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48Zm9udCBzaXplPSI0IiBjb2xvcj0iYmxhY2siIGZhY2U9 IlRpbWVzIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9mb250Pjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3Jk ZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjQwMCIgc3R5bGU9 IndpZHRoOjMwMC4wcHQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAw aW4gMGluIDBpbiI+PC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIC4y NWluIDBpbiAuMjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIxIiBjb2xv cj0iIzAwOTkwMCIgZmFjZT0iQXJpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDA5OTAwIj4mbmJzcDtUaGluayBiZWZvcmUgeW91IHByaW50LjxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzo1LjI1cHQg LjI1aW4gNC41cHQgLjI1aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48Zm9udCBzaXplPSIxIiBjb2xvcj0iIzk5OTk5OSIgZmFjZT0iQXJpYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojOTk5OTk5Ij48YnI+DQpUaGlzIGVtYWls IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJpdmlsZWdlZCBtYXRlcmlhbCBmb3IgdGhl IHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQuIEFueSByZXZpZXcsIHVzZSwgZGlz dHJpYnV0aW9uIG9yIGRpc2Nsb3N1cmUgYnkgb3RoZXJzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQu IElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgKG9yIGF1dGhvcml6ZWQgdG8g cmVjZWl2ZSBmb3IgdGhlIHJlY2lwaWVudCksDQogcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBi eSByZXBseSBlbWFpbCBhbmQgZGVsZXRlIGFsbCBjb3BpZXMgb2YgdGhpcyBtZXNzYWdlLjxicj4N Cjxicj4NCkNpc2NvIFN5c3RlbXMgRnJhbmNlLCBTb2Npw6l0w6kgw6AgcmVzcG9uc2FiaWl0w6kg bGltaXTDqWUsIFJ1ZSBDYW1pbGxlIERlc21vdWxpbnMg4oCTIEltbSBBdGxhbnRpcyBaYWMgRm9y dW0gU2VpbmUgSWxvdCA3IDkyMTMwIElzc3kgbGVzIE1vdWxpbmVhdXgsIEF1IGNhcGl0YWwgZGUg OTEuNDcwIOKCrCwgMzQ5IDE2NiA1NjEgUkNTIE5hbnRlcnJlLCBEaXJlY3RldXIgZGUgbGEgcHVi bGljYXRpb246IEplYW4tTHVjIE1pY2hlbCBHaXZvbmUuPGJyPg0KPGJyPg0KRm9yIGNvcnBvcmF0 ZSBsZWdhbCBpbmZvcm1hdGlvbiBnbyB0bzo8YnI+DQo8YSBocmVmPSJodHRwOi8vd3d3LmNpc2Nv LmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0bWwiPmh0dHA6 Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdhbC9jcmkvaW5kZXgu aHRtbDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ri b2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMyIgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_2779C9F0771F974CAD742BAE6D9904FE24E80A3BPolydeucesoffic_-- --_005_2779C9F0771F974CAD742BAE6D9904FE24E80A3BPolydeucesoffic_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=11041; creation-date="Tue, 15 Nov 2011 02:18:30 GMT"; modification-date="Tue, 15 Nov 2011 02:18:30 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_2779C9F0771F974CAD742BAE6D9904FE24E80A3BPolydeucesoffic_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=87; creation-date="Tue, 15 Nov 2011 02:18:31 GMT"; modification-date="Tue, 15 Nov 2011 02:18:31 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --_005_2779C9F0771F974CAD742BAE6D9904FE24E80A3BPolydeucesoffic_-- From gilles.bertrand@orange.com Mon Nov 14 21:03: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 60CFC1F0C84 for ; Mon, 14 Nov 2011 21:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 RwI+nY-RYEUL for ; Mon, 14 Nov 2011 21:03:09 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1211F0C4F for ; Mon, 14 Nov 2011 21:03:09 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C5BC0140006; Tue, 15 Nov 2011 06:03:07 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id B35E8140005; Tue, 15 Nov 2011 06:03:07 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 06:03:07 +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_01CCA353.DCC32395" Date: Tue, 15 Nov 2011 06:02:10 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF02DC8772@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-cdni-cases-00 Thread-Index: AcyadRRdhlXhbegIQbqsQJnwtuqUpACvZ/1QAV7k6HAAKJIQsA== References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> From: To: X-OriginalArrivalTime: 15 Nov 2011 05:03:07.0612 (UTC) FILETIME=[DD3A99C0:01CCA353] Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 15 Nov 2011 05:03:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA353.DCC32395 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Kent, =20 As raised by Alan in his e-mail below, in an offload use case the uCDN would require information on the dCDNs to be aware of the amount of traffic it can offload to every dCDN. I think this requirement is already covered through the request routing interface as REQ-2 includes the advertising of information about dCDN resources. Maybe we might add a few words to REQ-2 to mention explicitly that resource information could be needed for offload situations.=20 =20 I am not 100% clear today if the offload use case introduces specific requirements on other interfaces (e.g., control and metadata) in addition to the request routing interface. I see some specificity in this use case, for instance, the duration during which the uCDN will use the dCDN resources can be short in an offload situation (e.g., duration of a flash crowd) as compared to a footprint extension use case. =20 Best regards, =20 Gilles =20 =20 ________________________________ From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20 Sent: November-07-11 5:19 AM To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; trevor.burbridge@bt.com; philip.eardley@bt.com; kevin.ma@azukisystems.com Cc: cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 (...) =20 Section 3.1 Offloading. It should be noted that this use case would require knowledge about the other CDN to know if the other CDN has the resources to offload the requests in the first place and also if the content is available in the CDN being offloaded too. I agree: the CDN on which requests are offloaded must be able to handle the offloaded requests. This (may) introduce requirements on the metadata (and control) interfaces.=20 A.K.--> Yes, my point exactly, it would be useful to point that out in your draft to make it complete and also have it noted in the "CDNI Requirements Draft" . (...) =20 (...) ------_=_NextPart_001_01CCA353.DCC32395 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

      Hi Kent,

       

      As raised by Alan in his e-mail below, in an offload use case the = uCDN would require information on the dCDNs to be aware of the amount of = traffic it can offload to every dCDN. I think this requirement is = already covered through the request routing interface as REQ-2 includes = the advertising of information about dCDN resources. Maybe we might add = a few words to REQ-2 to mention explicitly that resource information = could be needed for offload situations.

       

      I am not 100% clear today if the offload use case introduces specific = requirements on other interfaces (e.g., control and metadata) in = addition to the request routing interface. I see some specificity in = this use case, for instance, the duration during which the uCDN will use = the dCDN resources can be short in an offload situation (e.g., duration = of a flash crowd) as compared to a footprint extension use = case.

       

      Best regards,

       

      Gilles

       

       

      From:= gilles.bertrand@orange.com= [mailto:gilles.bertrand@orange.= com]
      Sent: November-07-11 5:19 AM
      To: Alan = Kavanagh; emile.stephan@orange.com; = grant.watson@bt.com; trevor.burbridge@bt.com; philip.eardley@bt.com; kevin.ma@azukisystems.comCc: cdni@ietf.org
      Subject: RE: = draft-ietf-cdni-cases-00

      (…)

       

      Section 3.1 = Offloading. It should be noted that this use case would require = knowledge about the other CDN to know if the other CDN has the resources = to offload the requests in the first place and also if the content is = available in the CDN being offloaded too.

      I agree: the CDN on which requests are offloaded must be able to = handle the offloaded requests. This (may)  introduce requirements on the metadata (and control) = interfaces.&n= bsp;

      A.= K.--> Yes, my point exactly, it would be useful to point that out in = your draft to make it complete and also have it noted in the "CDNI = Requirements Draft" .<= /span>

      (…)

       

      (…)

      ------_=_NextPart_001_01CCA353.DCC32395-- From gilles.bertrand@orange.com Mon Nov 14 21:10: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 1B5ED11E815C for ; Mon, 14 Nov 2011 21:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[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 RfgjnV3DpKpV for ; Mon, 14 Nov 2011 21:10:17 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id B17DC21F8B8E for ; Mon, 14 Nov 2011 21:10:10 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 97AC46DC001; Tue, 15 Nov 2011 06:20:25 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 899A6858001; Tue, 15 Nov 2011 06:20:25 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 06:10:09 +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_01CCA354.D82F07D1" Date: Tue, 15 Nov 2011 06:09:41 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF02DC8774@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-cdni-cases-00 Thread-Index: AcyadRRdhlXhbegIQbqsQJnwtuqUpACvZ/1QAV7k6HAAJ3q0EA== References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> From: To: , , , , , X-OriginalArrivalTime: 15 Nov 2011 05:10:09.0386 (UTC) FILETIME=[D8A034A0:01CCA354] Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 15 Nov 2011 05:10:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA354.D82F07D1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Alan Thanks for your feedback. Please see my answers inline. if you attend IETF#82 physically, I'll be happy to meet you to discuss = any remaining issue. Cheers, Gilles =20 De : Alan Kavanagh [mailto:alan.kavanagh@ericsson.com]=20 Envoy=E9 : mardi 15 novembre 2011 05:56 =C0 : BERTRAND Gilles RD-CORE-ISS; STEPHAN Emile RD-CORE-LAN; = grant.watson@bt.com; trevor.burbridge@bt.com; philip.eardley@bt.com; = kevin.ma@azukisystems.com Cc : cdni@ietf.org Objet : RE: draft-ietf-cdni-cases-00 =20 Hi Gilles =20 Responses inline below. =20 Alan =20 (...) * Section 1.1. You mention Access CDN. Is this more an operator own and = managed CDN in the Access Domain that may have access to end user = information or are you talking about a given Access CDN having access to = the end-users profile, im assuming its the former but felt its not clear = in the draft.=20 I did not understand your question. Could you please rephrase? Thanks. =20 A.K.--> my point here is that you tying Access CDN with end users = profile information such as given subscriber profile information an = Access Network Provider has such as data line rate etc. So my point was = are you stating the Access CDN has an i/f to sub mgmt that Access = Network Provider knows?=20 Gilles: The definition of an access CDN is intended to be a bit more = generic than this. Through this definition we want to reflect the fact = that a CDN connected to the end-user's access might have specific = information that could help in providing a better delivery service. You = provide relevant example of such information in your answer above.=20 * Section 1.3. First bullet " improve the experience for the End User; = for instance delivery has lower latency and better robustness". Suggest to add and reduce = Round Trip Time as content is positioned closer to end user. By lower latency, we mean decrease the round trip time between the user = and the delivery server. =20 A.K.--> yes my point exactly, just needs to be reworded in the draft for = easier reading.=20 Gilles: OK, I have added a few words to clarify * Section 1.3. Third bullet mentions reduced electricity consumption, = could you expand on that and say how this is achieved? Popular content is delivered through the CDN rather than through the = content provider's servers. Therefore, the content providers' = infrastructure can be smaller (less servers etc). =20 A.K.--> I think that example should be noted in the draft such that = caching reduces transport in certain network segments which may in turn = imply reduce electric consumption etc.=20 Gilles: OK, I have added a few words to clarify * Section 1.3. Suggest to add CSP-3 in Figure-1 to be consistent. To be consistent with what?=20 A.K.--> Reading section 1.3 last paragraph you give another example of a = "CSP-3", but CSP-3 is not shown in figure 1, so makes sense to add CSP-3 = to Figure-1.=20 Gilles: thanks for the clarification. I have done the modification, it = will appear in the next version of the I-D. * Section 1.4. I understand what you are conveying here, makes sense. I = would however clarify that CDN's even external ones to interconnect with = others today but use a Proprietary interface to do so etc. Do you know examples of production CDNs interconnected through = proprietary interfaces today?=20 A.K.--> Yes, lots of them :-). If you like i can craft some text to add = to this section of use cases and my main point is to convey what is in = the current market place to give a better reflection of the current = technology landscape and market place, so im sure this is simple to add, = but if you need me ill provide the text.=20 Gilles: I am aware of many lab tests/trials/etc for CDN interconnection. = But today, I know very few examples of production CDNs interconnected = through proprietary interfaces. So I am quite interested by the numerous = examples you mention J.=20 (...) * Section 3.1 Offloading. It should be noted that this use case would = require knowledge about the other CDN to know if the other CDN has the = resources to offload the requests in the first place and also if the = content is available in the CDN being offloaded too. I agree: the CDN on which requests are offloaded must be able to handle = the offloaded requests. This introduces requirements on the metadata = (and control) interfaces.=20 A.K.--> Yes, my point exactly, it would be useful to point that out in = your draft to make it complete and also have it noted in the "CDNI = Requirements Draft" . Gilles: OK I have added a sentence and forwarded your remark to Kent. (...) ------_=_NextPart_001_01CCA354.D82F07D1 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

      Hi Alan

      Thanks for your feedback. Please see my answers = inline.

      if you attend IETF#82 physically, I'll be happy to meet you to = discuss any remaining issue.

      Cheers,

      Gilles

       

      De : Alan = Kavanagh [mailto:alan.kavanagh@ericsson.com]
      Envoy=E9 : = mardi 15 novembre 2011 05:56
      =C0 : BERTRAND Gilles = RD-CORE-ISS; STEPHAN Emile RD-CORE-LAN; grant.watson@bt.com; = trevor.burbridge@bt.com; philip.eardley@bt.com; = kevin.ma@azukisystems.com
      Cc : = cdni@ietf.org
      Objet : RE: = draft-ietf-cdni-cases-00

       

      Hi= Gilles

       

      Re= sponses inline below.

       

      Al= an

       

      (…)

      • Section 1.1. = You mention Access CDN. Is this more an operator own and managed CDN in = the Access Domain that may have access to end user information or are = you talking about a given Access CDN having access to the end-users = profile, im assuming its the former but felt its not clear in the draft. =

      I did not understand your question. Could you please rephrase? = Thanks. &n= bsp;

      A.= K.--> my point here is that you tying Access CDN with end users = profile information such as given subscriber profile information an = Access Network Provider has such as data line rate etc. So my point = was are you stating the Access CDN has an i/f to sub mgmt that Access = Network Provider knows? 

      Gilles: The definition of an access CDN is intended to be a bit more = generic than this. Through this definition we want to reflect the fact = that a CDN connected to the end-user's access might have specific = information that could help in providing a better delivery service. You = provide relevant example of such information in your answer above. =

      • Section 1.3. = First bullet " improve the experience for the End User; for = instance delivery has
              lower latency = and better robustness". Suggest to add and reduce Round Trip Time = as content is positioned closer to end user.

      By lower latency, we mean decrease the round trip time between the = user and the delivery server. &n= bsp;

      A.= K.--> yes my point exactly, just needs to be reworded in the draft = for easier reading. 

      Gilles: OK, I have added a few words to = clarify

      • Section 1.3. = Third bullet mentions reduced electricity consumption, could you expand = on that and say how this is achieved?

      Popular content is delivered through the CDN rather than through the = content provider's servers. Therefore, the content providers' = infrastructure can be smaller (less servers etc).&n= bsp; 

      A.= K.--> I think that example should be noted in the draft such = that caching reduces transport in certain network segments which may in = turn imply reduce electric consumption etc. 

      Gilles: OK, I have added a few words to = clarify

      • Section 1.3. = Suggest to add CSP-3 in Figure-1 to be consistent.

      To be consistent with what?&n= bsp;

      A.= K.--> Reading section 1.3 last paragraph you give another example of = a "CSP-3", but CSP-3 is not shown in figure 1, so makes = sense to add CSP-3 to Figure-1. 

      Gilles: thanks for the clarification. I have done the modification, = it will appear in the next version of the I-D.

      • Section 1.4. = I understand what you are conveying here, makes sense. I would however = clarify that CDN's even external ones to interconnect with others today = but use a Proprietary interface to do so etc.

      Do you know examples of production CDNs interconnected through = proprietary interfaces today?&n= bsp;

      A.= K.--> Yes, lots of them :-). If you like i can craft some text to add = to this section of use cases and my main point is to convey what is = in the current market place to give a better reflection of the = current technology landscape and market place, so im sure this is = simple to add, but if you need me ill provide the text. 

      Gilles: I am aware of many lab tests/trials/etc for CDN = interconnection. But today, I know very few examples of = production CDNs interconnected through proprietary interfaces. So = I am quite interested by the numerous examples you mention J.

      (…)

      • Section 3.1 = Offloading. It should be noted that this use case would require = knowledge about the other CDN to know if the other CDN has the resources = to offload the requests in the first place and also if the content is = available in the CDN being offloaded too.

      I agree: the CDN on which requests are offloaded must be able to = handle the offloaded requests. This introduces requirements on the = metadata (and control) interfaces.&n= bsp;

      A.= K.--> Yes, my point exactly, it would be useful to point that out in = your draft to make it complete and also have it noted in the "CDNI = Requirements Draft" .<= /span>

      Gilles: OK I have added a sentence and forwarded your remark to = Kent.

      (…)

      ------_=_NextPart_001_01CCA354.D82F07D1-- From ben@niven-jenkins.co.uk Tue Nov 15 00:15:47 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 9C77811E8171 for ; Tue, 15 Nov 2011 00:15:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.049 X-Spam-Level: X-Spam-Status: No, score=-103.049 tagged_above=-999 required=5 tests=[AWL=0.550, 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 JyWt8Ugxmuqj for ; Tue, 15 Nov 2011 00:15:43 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7190811E814A for ; Tue, 15 Nov 2011 00:15:42 -0800 (PST) Received: from dhcp-15fb.meeting.ietf.org ([130.129.21.251]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RQEBA-0001lI-8e; Tue, 15 Nov 2011 08:15:41 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <260A32EFD5C9EB47AD504929D005DF6217F8188E@SZXEML519-MBS.china.huawei.com> Date: Tue, 15 Nov 2011 08:15:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <317ADF98-AFB8-46C7-B049-9979B8226A53@niven-jenkins.co.uk> References: <778E7C62-393C-4C63-9763-D03BDFC7A7F9@cisco.com> <1C783FEC-98D0-4A44-9187-C51A8E6DDE2F@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6217F8188E@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: [CDNi] Content Portals (Re: comments on ietf-cdni-use-cases-00) 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, 15 Nov 2011 08:15:47 -0000 Zhipeng, On 14 Nov 2011, at 09:06, ZhouZhipeng wrote: > Hi Ben and Francois, > Besides what I have explained for the bandwidth efficiency on this use = case, I have a scenario to the portal issue : if the content has three = optional formats and 3 optional stream rates, hence total 9 options, how = the portal may be nice to display all these options on each content = item. I'm not sure what the relevance of that is to CDNI. It's up to the = Content Provider how they arrange their portal and how they present = options to End Users. > Second, do we wish the normal user to be so clear on the technical = details when they consume the content. Again this is nothing to do with CDNI. The content portals I use and I = am aware of manage to present multiple options to their users without = requiring users to understand the technical details. For example by = describing/presenting different versions as HD, SD, Mobile, PC, TV etc. = and in many cases only offering the options that the Content Provider = wants to offer to the particular device/client the End User is using. Ben >=20 > Thanks. > Zhipeng >=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Sent: Monday, November 14, 2011 10:21 AM > To: Francois Le Faucheur > Cc: cdni@ietf.org > Subject: Re: [CDNi] comments on ietf-cdni-use-cases-00 >=20 >=20 > On 12 Nov 2011, at 20:18, Francois Le Faucheur wrote: >> In particular, section 5 mixes delivery policies that are indeed = relevant to CDNs with "policies" that in my opinion pertain to some = service layer above the CDN and are irrelevant to CDNs. >> A good example of that issue would be "resolution-based constraints" = of 5.1 and of course the content encoding restrictions of 5.1.3. I don't = think we want the CDNs/CDNI to have to be aware about which user is = allowed to access which resolution , or which encoding is deliverable to = specific devices. These functional requirements can be better achieved = in my opinion by the Content Portal making decision of whether a request = is allowed based on any combination of any criteria and then only leave = it to the CDN to validate that the requst has been authorised (eg via = URI signing or token). >=20 > +1. >=20 > The same can be said for the "temporal restrictions" which can be = achieved using a combination of the content portal and CDN data plane = functions (e.g. Expires/Cache-Control headers)=20 >=20 > Ben >=20 >=20 From zhouzhipeng@huawei.com Tue Nov 15 00:48: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 64EED21F8E21 for ; Tue, 15 Nov 2011 00:48:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, J_CHICKENPOX_54=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 Sd6otYxTwKJ8 for ; Tue, 15 Nov 2011 00:48:53 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5124021F8DFD for ; Tue, 15 Nov 2011 00:48:53 -0800 (PST) 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 <0LUP0058R1T8JS@szxga04-in.huawei.com> for cdni@ietf.org; Tue, 15 Nov 2011 16:48:44 +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 <0LUP00MYO1T820@szxga04-in.huawei.com> for cdni@ietf.org; Tue, 15 Nov 2011 16:48:44 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB27527; Tue, 15 Nov 2011 16:48:43 +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.323.3; Tue, 15 Nov 2011 16:48:38 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.4]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.003; Tue, 15 Nov 2011 16:48:33 +0800 Date: Tue, 15 Nov 2011 08:48:32 +0000 From: ZhouZhipeng In-reply-to: <317ADF98-AFB8-46C7-B049-9979B8226A53@niven-jenkins.co.uk> X-Originating-IP: [10.138.73.38] To: Ben Niven-Jenkins Message-id: <260A32EFD5C9EB47AD504929D005DF6217F81D55@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: Content Portals (Re: [CDNi] comments on ietf-cdni-use-cases-00) Thread-index: AQHMo27Jbh7nxhNr7Ue5jJka6pjvgZWtltlA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <778E7C62-393C-4C63-9763-D03BDFC7A7F9@cisco.com> <1C783FEC-98D0-4A44-9187-C51A8E6DDE2F@niven-jenkins.co.uk> <260A32EFD5C9EB47AD504929D005DF6217F8188E@SZXEML519-MBS.china.huawei.com> <317ADF98-AFB8-46C7-B049-9979B8226A53@niven-jenkins.co.uk> Cc: "cdni@ietf.org" Subject: Re: [CDNi] Content Portals (Re: comments on ietf-cdni-use-cases-00) 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, 15 Nov 2011 08:48:54 -0000 Ben, Good afternoon, 1) we have discussed many times that we may reduce the bandwidth between uCDN and dCDN. 2) Francois had said in previous email that Content Portal may help for delivering different formats while I explained that it is not just that simple even for portal issue. You may assign a terminal only one file format but if the CDN should serve for different types of terminals then the CDN server should hold content with different formats. 3) In fact adaptation is not an identical issue of portal. The adaptation scenario is as below: a. the adaptation is conducted between Server and Client automatically. For example, once bandwidth on access network has changed during the service, the new rate stream will be delivered to the terminal without the user's operation. b. see the scenario of multi-screen service: The user may move among home, office, outside. Therefore he may use different terminals( TV, PC, Mobile phone) to see the same content without break(when he goes out home the content will be delivered to his smart phone) and the user would hope the operation may be as simple as possible( let the device to do the adaptation). Above all, if the dCDN should hold multiple formats content, whether we may give a solution that only one content copy being delivered to dCDN. Thanks. Zhipeng -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] Sent: Tuesday, November 15, 2011 4:16 PM To: ZhouZhipeng Cc: Francois Le Faucheur; cdni@ietf.org Subject: Content Portals (Re: [CDNi] comments on ietf-cdni-use-cases-00) Zhipeng, On 14 Nov 2011, at 09:06, ZhouZhipeng wrote: > Hi Ben and Francois, > Besides what I have explained for the bandwidth efficiency on this use case, I have a scenario to the portal issue : if the content has three optional formats and 3 optional stream rates, hence total 9 options, how the portal may be nice to display all these options on each content item. I'm not sure what the relevance of that is to CDNI. It's up to the Content Provider how they arrange their portal and how they present options to End Users. > Second, do we wish the normal user to be so clear on the technical details when they consume the content. Again this is nothing to do with CDNI. The content portals I use and I am aware of manage to present multiple options to their users without requiring users to understand the technical details. For example by describing/presenting different versions as HD, SD, Mobile, PC, TV etc. and in many cases only offering the options that the Content Provider wants to offer to the particular device/client the End User is using. Ben > > Thanks. > Zhipeng > > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] > Sent: Monday, November 14, 2011 10:21 AM > To: Francois Le Faucheur > Cc: cdni@ietf.org > Subject: Re: [CDNi] comments on ietf-cdni-use-cases-00 > > > On 12 Nov 2011, at 20:18, Francois Le Faucheur wrote: >> In particular, section 5 mixes delivery policies that are indeed relevant to CDNs with "policies" that in my opinion pertain to some service layer above the CDN and are irrelevant to CDNs. >> A good example of that issue would be "resolution-based constraints" of 5.1 and of course the content encoding restrictions of 5.1.3. I don't think we want the CDNs/CDNI to have to be aware about which user is allowed to access which resolution , or which encoding is deliverable to specific devices. These functional requirements can be better achieved in my opinion by the Content Portal making decision of whether a request is allowed based on any combination of any criteria and then only leave it to the CDN to validate that the requst has been authorised (eg via URI signing or token). > > +1. > > The same can be said for the "temporal restrictions" which can be achieved using a combination of the content portal and CDN data plane functions (e.g. Expires/Cache-Control headers) > > Ben > > From kleung@cisco.com Tue Nov 15 00:52: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 ABC0C21F8FF5 for ; Tue, 15 Nov 2011 00:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 55N4kZ+jGISF for ; Tue, 15 Nov 2011 00:52:20 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 893F021F8E21 for ; Tue, 15 Nov 2011 00:52:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=13687; q=dns/txt; s=iport; t=1321347140; x=1322556740; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=+d966Vknz/5wBUg66q1X4vmzqjEQOVwdZY9IiwH6muA=; b=VFQtM+zxZzlJIGkZC69+6EIH8hYigpbvsUAp4V4a1ZWS9WA+OZ2YNfQT UIuwh/mXzjmq6ff6T2EjE1AkdxqO2v/ped/0AbzoA6eVujUxpQsut6dLV uqAHlSbA3V2ue3mInEBrA1VDs/aDt+9sBGI3l5kev8Gvs8I/erouwJCE/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkAABYnwk6rRDoJ/2dsb2JhbABDgk2XGJAFgQWBcgEBAQQSAQkLBgNJEAIBCBEEAQELBhcBBgFFCQgBAQQTCBqkGQGfCIkhYwSIEZFjjFc X-IronPort-AV: E=Sophos;i="4.69,513,1315180800"; d="scan'208,217";a="12582736" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 15 Nov 2011 08:52:20 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAF8qJas010487; Tue, 15 Nov 2011 08:52:20 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 00:52:19 -0800 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_01CCA373.E20762AB" Date: Tue, 15 Nov 2011 00:52:17 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC521046FE71@xmb-sjc-235.amer.cisco.com> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF02DC8772@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-cdni-cases-00 Thread-Index: AcyadRRdhlXhbegIQbqsQJnwtuqUpACvZ/1QAV7k6HAAKJIQsAAIkLMQ References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02DC8772@ftrdmel0.rd.francetelecom.fr> From: "Kent Leung (kleung)" To: X-OriginalArrivalTime: 15 Nov 2011 08:52:19.0898 (UTC) FILETIME=[E23AE9A0:01CCA373] Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 15 Nov 2011 08:52:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA373.E20762AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gilles. I'm not sure if the requirements should be written explicitly to map to use cases unless the functions are for that purpose only. In this case, there could be numerous reasons why dCDN provides its resource information to the uCDN. =20 The discussion below indicates a need for RRI requirement, which can be traced to REQ-2. Is this not sufficient? =20 Kent =20 From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20 Sent: Tuesday, November 15, 2011 1:02 PM To: Kent Leung (kleung) Cc: alan.kavanagh@ericsson.com; cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 =20 Hi Kent, =20 As raised by Alan in his e-mail below, in an offload use case the uCDN would require information on the dCDNs to be aware of the amount of traffic it can offload to every dCDN. I think this requirement is already covered through the request routing interface as REQ-2 includes the advertising of information about dCDN resources. Maybe we might add a few words to REQ-2 to mention explicitly that resource information could be needed for offload situations.=20 =20 I am not 100% clear today if the offload use case introduces specific requirements on other interfaces (e.g., control and metadata) in addition to the request routing interface. I see some specificity in this use case, for instance, the duration during which the uCDN will use the dCDN resources can be short in an offload situation (e.g., duration of a flash crowd) as compared to a footprint extension use case. =20 Best regards, =20 Gilles =20 =20 ________________________________ From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20 Sent: November-07-11 5:19 AM To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; trevor.burbridge@bt.com; philip.eardley@bt.com; kevin.ma@azukisystems.com Cc: cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 (...) =20 Section 3.1 Offloading. It should be noted that this use case would require knowledge about the other CDN to know if the other CDN has the resources to offload the requests in the first place and also if the content is available in the CDN being offloaded too. I agree: the CDN on which requests are offloaded must be able to handle the offloaded requests. This (may) introduce requirements on the metadata (and control) interfaces.=20 A.K.--> Yes, my point exactly, it would be useful to point that out in your draft to make it complete and also have it noted in the "CDNI Requirements Draft" . (...) =20 (...) ------_=_NextPart_001_01CCA373.E20762AB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Hi Gilles.  I’m not sure if the requirements should be = written explicitly to map to use cases unless the functions are for that = purpose only.  In this case, there could be numerous reasons why = dCDN provides its resource information to the = uCDN.

       

      The discussion below indicates a need for RRI requirement, which can = be traced to REQ-2.  Is this not = sufficient?

       

      Kent

       

      From:= = gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] =
      Sent: Tuesday, November 15, 2011 1:02 PM
      To: Kent = Leung (kleung)
      Cc: alan.kavanagh@ericsson.com; = cdni@ietf.org
      Subject: RE: = draft-ietf-cdni-cases-00

       

      Hi Kent,

       

      As raised by Alan in his e-mail below, in an offload use case the = uCDN would require information on the dCDNs to be aware of the amount of = traffic it can offload to every dCDN. I think this requirement is = already covered through the request routing interface as REQ-2 includes = the advertising of information about dCDN resources. Maybe we might add = a few words to REQ-2 to mention explicitly that resource information = could be needed for offload situations.

       

      I am not 100% clear today if the offload use case introduces specific = requirements on other interfaces (e.g., control and metadata) in = addition to the request routing interface. I see some specificity in = this use case, for instance, the duration during which the uCDN will use = the dCDN resources can be short in an offload situation (e.g., duration = of a flash crowd) as compared to a footprint extension use = case.

       

      Best regards,

       

      Gilles

       

       

      From:= = gilles.bertrand@orange.com= [mailto:gilles.bertrand@orange.= com]
      Sent: November-07-11 5:19 AM
      To: Alan = Kavanagh; emile.stephan@orange.com; = grant.watson@bt.com; trevor.burbridge@bt.com; philip.eardley@bt.com; kevin.ma@azukisystems.comCc: cdni@ietf.org
      Subject: RE: = draft-ietf-cdni-cases-00

      (…)

       

      Section 3.1 = Offloading. It should be noted that this use case would require = knowledge about the other CDN to know if the other CDN has the resources = to offload the requests in the first place and also if the content is = available in the CDN being offloaded too.

      I agree: the CDN on which requests are offloaded must be able to = handle the offloaded requests. This (may)  introduce requirements = on the metadata (and control) interfaces.&n= bsp;

      A.= K.--> Yes, my point exactly, it would be useful to point that out in = your draft to make it complete and also have it noted in the "CDNI = Requirements Draft" .<= /span>

      (…)

       

      (…)

      ------_=_NextPart_001_01CCA373.E20762AB-- From gilles.bertrand@orange.com Tue Nov 15 01:07: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 69BEC21F8FE7 for ; Tue, 15 Nov 2011 01:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[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 R23aX1NJ8tZr for ; Tue, 15 Nov 2011 01:07:09 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4A721F8FD7 for ; Tue, 15 Nov 2011 01:07:08 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3900E6DC001; Tue, 15 Nov 2011 10:17:23 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 2E7F9858001; Tue, 15 Nov 2011 10:17:23 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Nov 2011 10:07:06 +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_01CCA375.F2611A41" Date: Tue, 15 Nov 2011 10:02:16 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF02DC881D@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC521046FE71@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-cdni-cases-00 Thread-Index: AcyadRRdhlXhbegIQbqsQJnwtuqUpACvZ/1QAV7k6HAAKJIQsAAIkLMQAACSEqA= References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02DC8772@ftrdmel0.rd.francetelecom.fr> <2979E38DD6FC6544B789C8DAD7BAFC521046FE71@xmb-sjc-235.amer.cisco.com> From: To: X-OriginalArrivalTime: 15 Nov 2011 09:07:06.0872 (UTC) FILETIME=[F2E86780:01CCA375] Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 15 Nov 2011 09:07:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA375.F2611A41 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kent, =20 Please see my answer below. =20 Gilles =20 De : Kent Leung (kleung) [mailto:kleung@cisco.com]=20 Envoy=E9 : mardi 15 novembre 2011 16:52 =C0 : BERTRAND Gilles RD-CORE-ISS Cc : alan.kavanagh@ericsson.com; cdni@ietf.org Objet : RE: draft-ietf-cdni-cases-00 =20 Hi Gilles. I'm not sure if the requirements should be written = explicitly to map to use cases unless the functions are for that purpose = only. In this case, there could be numerous reasons why dCDN provides = its resource information to the uCDN. =20 Gilles: I agree =20 The discussion below indicates a need for RRI requirement, which can be = traced to REQ-2. Is this not sufficient? =20 Gilles: I think it's sufficient indeed. =20 Kent =20 From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20 Sent: Tuesday, November 15, 2011 1:02 PM To: Kent Leung (kleung) Cc: alan.kavanagh@ericsson.com; cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 =20 Hi Kent, =20 As raised by Alan in his e-mail below, in an offload use case the uCDN = would require information on the dCDNs to be aware of the amount of = traffic it can offload to every dCDN. I think this requirement is = already covered through the request routing interface as REQ-2 includes = the advertising of information about dCDN resources. Maybe we might add = a few words to REQ-2 to mention explicitly that resource information = could be needed for offload situations.=20 =20 I am not 100% clear today if the offload use case introduces specific = requirements on other interfaces (e.g., control and metadata) in = addition to the request routing interface. I see some specificity in = this use case, for instance, the duration during which the uCDN will use = the dCDN resources can be short in an offload situation (e.g., duration = of a flash crowd) as compared to a footprint extension use case. =20 Best regards, =20 Gilles =20 =20 ________________________________ From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20 Sent: November-07-11 5:19 AM To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; = trevor.burbridge@bt.com; philip.eardley@bt.com; = kevin.ma@azukisystems.com Cc: cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 (...) =20 Section 3.1 Offloading. It should be noted that this use case would = require knowledge about the other CDN to know if the other CDN has the = resources to offload the requests in the first place and also if the = content is available in the CDN being offloaded too. I agree: the CDN on which requests are offloaded must be able to handle = the offloaded requests. This (may) introduce requirements on the = metadata (and control) interfaces.=20 A.K.--> Yes, my point exactly, it would be useful to point that out in = your draft to make it complete and also have it noted in the "CDNI = Requirements Draft" . (...) =20 (...) ------_=_NextPart_001_01CCA375.F2611A41 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

      Hi Kent,

       

      Please see my answer below.

       

      Gilles

       

      De : Kent Leung = (kleung) [mailto:kleung@cisco.com]
      Envoy=E9 : mardi 15 = novembre 2011 16:52
      =C0 : BERTRAND Gilles = RD-CORE-ISS
      Cc : alan.kavanagh@ericsson.com; = cdni@ietf.org
      Objet : RE: = draft-ietf-cdni-cases-00

       

      Hi Gilles.  I’m not sure if the requirements should be = written explicitly to map to use cases unless the functions are for that = purpose only.  In this case, there could be numerous reasons why = dCDN provides its resource information to the = uCDN.

       

      Gilles: I agree

       

      The discussion below indicates a need for RRI requirement, which can = be traced to REQ-2.  Is this not = sufficient?

       

      Gilles: I think it's sufficient indeed.

       

      Kent

       

      From:= gilles.bertrand@orange.com= [mailto:gilles.bertrand@orange.= com]
      Sent: Tuesday, November 15, 2011 1:02 = PM
      To: Kent Leung (kleung)
      Cc: alan.kavanagh@ericsson.com= ; cdni@ietf.org
      Subject: = RE: draft-ietf-cdni-cases-00

       

      Hi Kent,

       

      As raised by Alan in his e-mail below, in an offload use case the = uCDN would require information on the dCDNs to be aware of the amount of = traffic it can offload to every dCDN. I think this requirement is = already covered through the request routing interface as REQ-2 includes = the advertising of information about dCDN resources. Maybe we might add = a few words to REQ-2 to mention explicitly that resource information = could be needed for offload situations.

       

      I am not 100% clear today if the offload use case introduces specific = requirements on other interfaces (e.g., control and metadata) in = addition to the request routing interface. I see some specificity in = this use case, for instance, the duration during which the uCDN will use = the dCDN resources can be short in an offload situation (e.g., duration = of a flash crowd) as compared to a footprint extension use = case.

       

      Best regards,

       

      Gilles

       

       

      From:= gilles.bertrand@orange.com= [mailto:gilles.bertrand@orange.= com]
      Sent: November-07-11 5:19 AM
      To: Alan = Kavanagh; emile.stephan@orange.com; = grant.watson@bt.com; trevor.burbridge@bt.com; philip.eardley@bt.com; kevin.ma@azukisystems.comCc: cdni@ietf.org
      Subject: RE: = draft-ietf-cdni-cases-00

      (…)

       

      Section 3.1 = Offloading. It should be noted that this use case would require = knowledge about the other CDN to know if the other CDN has the resources = to offload the requests in the first place and also if the content is = available in the CDN being offloaded too.

      I agree: the CDN on which requests are offloaded must be able to = handle the offloaded requests. This (may)  introduce requirements = on the metadata (and control) interfaces.&n= bsp;

      A.= K.--> Yes, my point exactly, it would be useful to point that out in = your draft to make it complete and also have it noted in the "CDNI = Requirements Draft" .<= /span>

      (…)

       

      (…)

      ------_=_NextPart_001_01CCA375.F2611A41-- From ben@niven-jenkins.co.uk Tue Nov 15 01:35: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 8C0E411E81A6 for ; Tue, 15 Nov 2011 01:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.232 X-Spam-Level: X-Spam-Status: No, score=-103.232 tagged_above=-999 required=5 tests=[AWL=0.367, 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 CKhi2rLQnL4l for ; Tue, 15 Nov 2011 01:35:10 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 1090311E81A5 for ; Tue, 15 Nov 2011 01:35:10 -0800 (PST) Received: from dhcp-15fb.meeting.ietf.org ([130.129.21.251]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RQFQ4-00069i-7S; Tue, 15 Nov 2011 09:35:09 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF02DC8772@ftrdmel0.rd.francetelecom.fr> Date: Tue, 15 Nov 2011 09:35:03 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7C7A0647-3CDA-4ED0-AF76-D48DFF8C1FE7@niven-jenkins.co.uk> References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02DC8772@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: [CDNi] dCDN capacity & offload (Re: draft-ietf-cdni-cases-00) 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, 15 Nov 2011 09:35:11 -0000 On 15 Nov 2011, at 05:02, wrote: > As raised by Alan in his e-mail below, in an offload use case the uCDN = would require information on the dCDNs to be aware of the amount of = traffic it can offload to every dCDN. I think this requirement is = already covered through the request routing interface as REQ-2 includes = the advertising of information about dCDN resources. Maybe we might add = a few words to REQ-2 to mention explicitly that resource information = could be needed for offload situations. This might not be what you meant (and if that's the case I apologise and = just ignore me) but I'm not convinced that the uCDN needs to know how = much capacity the dCDN has available. Instead it just needs to know if = the dCDN is prepared "to do more work" on behalf of the uCDN. Ben > =20 > I am not 100% clear today if the offload use case introduces specific = requirements on other interfaces (e.g., control and metadata) in = addition to the request routing interface. I see some specificity in = this use case, for instance, the duration during which the uCDN will use = the dCDN resources can be short in an offload situation (e.g., duration = of a flash crowd) as compared to a footprint extension use case. > =20 > Best regards, > =20 > Gilles > =20 > =20 > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20= > Sent: November-07-11 5:19 AM > To: Alan Kavanagh; emile.stephan@orange.com; = grant.watson@bt.com;trevor.burbridge@bt.com; philip.eardley@bt.com; = kevin.ma@azukisystems.com > Cc: cdni@ietf.org > Subject: RE: draft-ietf-cdni-cases-00 >=20 > (=85) > =20 > Section 3.1 Offloading. It should be noted that this use case would = require knowledge about the other CDN to know if the other CDN has the = resources to offload the requests in the first place and also if the = content is available in the CDN being offloaded too. > I agree: the CDN on which requests are offloaded must be able to = handle the offloaded requests. This (may) introduce requirements on the = metadata (and control) interfaces.=20 > A.K.--> Yes, my point exactly, it would be useful to point that out in = your draft to make it complete and also have it noted in the "CDNI = Requirements Draft" . > (=85) > =20 > (=85) > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Tue Nov 15 04:03: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 05CE621F8EA2 for ; Tue, 15 Nov 2011 04:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.262 X-Spam-Level: X-Spam-Status: No, score=-6.262 tagged_above=-999 required=5 tests=[AWL=0.337, 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 nLcSKdgVpm0y for ; Tue, 15 Nov 2011 04:03:24 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 32BF621F8EA0 for ; Tue, 15 Nov 2011 04:03:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=373; q=dns/txt; s=iport; t=1321358604; x=1322568204; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=/LIKUPeedc5m8NmXHmucLKt7ggaWqY12mpqSWnXSIP4=; b=Exqb63OMucnUvMsfPqnaQbd8f4PAUDvH3qjaEk+34zZcXX5SphrVNGJS R2MixfqCVQ3FWOaBXjLanQrPQ6g0mqfr1FrKHQWIYWtDbmAbg4KBkUrtK 9/nuhoReUohnPgIHtWAXLgCGz4Zpkzrn8TdTAUdXe1H5Um5M4onSgRyBw A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAKRTwk6tJXG8/2dsb2JhbABDqWqBBYILASeCModomhGBJgGfBQSGb4IyYwSID4whkgc X-IronPort-AV: E=Sophos;i="4.69,514,1315180800"; d="scan'208";a="36091250" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 15 Nov 2011 12:03:22 +0000 Received: from rtp-vpn3-1874.cisco.com (rtp-vpn3-1874.cisco.com [10.82.223.90]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAFC3Le6027219 for ; Tue, 15 Nov 2011 12:03:22 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2011 20:03:19 +0800 Message-Id: To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] CDNI WG meeting presentations 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, 15 Nov 2011 12:03:25 -0000 Folks, Just FYI, all the presentations are available from the IETF Meeting = Material page: https://datatracker.ietf.org/meeting/82/materials.html Looking forward to tomorrow's discussions. Francois & Rich PS: to presenters: you may want to double-check that the version = uploaded is indeed exactly the one you expect. If not yell at Rich and = me, asap. From alan.kavanagh@ericsson.com Tue Nov 15 16:58: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 805F311E80B2 for ; Tue, 15 Nov 2011 16:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.178 X-Spam-Level: X-Spam-Status: No, score=-6.178 tagged_above=-999 required=5 tests=[AWL=0.420, 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 848SwcGJipQj for ; Tue, 15 Nov 2011 16:58:35 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 2467E11E8082 for ; Tue, 15 Nov 2011 16:58:35 -0800 (PST) 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 pAG0wULU015225; Tue, 15 Nov 2011 18:58:32 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 15 Nov 2011 19:58:28 -0500 From: Alan Kavanagh To: "Kent Leung (kleung)" , "gilles.bertrand@orange.com" Date: Tue, 15 Nov 2011 19:56:48 -0500 Thread-Topic: draft-ietf-cdni-cases-00 Thread-Index: AcyadRRdhlXhbegIQbqsQJnwtuqUpACvZ/1QAV7k6HAAKJIQsAAIkLMQACHZBjA= Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A359@EUSAACMS0701.eamcs.ericsson.se> References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02DC8772@ftrdmel0.rd.francetelecom.fr> <2979E38DD6FC6544B789C8DAD7BAFC521046FE71@xmb-sjc-235.amer.cisco.com> In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC521046FE71@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_1B6D0317D3AD964FBF3956DEFA3524D51711E6A359EUSAACMS0701e_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 16 Nov 2011 00:58:39 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D51711E6A359EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Kent What might be useful is to jut capture the requirement somewhere as i belie= ve their will be numerous ways to address the overload case and i can see c= hanges required not just on CDN-I metadata i/f as GIlles is pointing out to= o, so for now lets capture the requirement. Alan ________________________________ From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: November-15-11 3:52 AM To: gilles.bertrand@orange.com Cc: Alan Kavanagh; cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 Hi Gilles. I'm not sure if the requirements should be written explicitly t= o map to use cases unless the functions are for that purpose only. In this= case, there could be numerous reasons why dCDN provides its resource infor= mation to the uCDN. The discussion below indicates a need for RRI requirement, which can be tra= ced to REQ-2. Is this not sufficient? Kent From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] Sent: Tuesday, November 15, 2011 1:02 PM To: Kent Leung (kleung) Cc: alan.kavanagh@ericsson.com; cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 Hi Kent, As raised by Alan in his e-mail below, in an offload use case the uCDN woul= d require information on the dCDNs to be aware of the amount of traffic it = can offload to every dCDN. I think this requirement is already covered thro= ugh the request routing interface as REQ-2 includes the advertising of info= rmation about dCDN resources. Maybe we might add a few words to REQ-2 to me= ntion explicitly that resource information could be needed for offload situ= ations. I am not 100% clear today if the offload use case introduces specific requi= rements on other interfaces (e.g., control and metadata) in addition to the= request routing interface. I see some specificity in this use case, for in= stance, the duration during which the uCDN will use the dCDN resources can = be short in an offload situation (e.g., duration of a flash crowd) as compa= red to a footprint extension use case. Best regards, Gilles ________________________________ From: gilles.bertrand@orange.com [mailto= :gilles.bertrand@orange.com] Sent: November-07-11 5:19 AM To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; trevor.burbridge@bt.com= ; philip.eardley@bt.com; kevin.ma@azukisystems.com Cc: cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 (...) Section 3.1 Offloading. It should be noted that this use case would require= knowledge about the other CDN to know if the other CDN has the resources t= o offload the requests in the first place and also if the content is availa= ble in the CDN being offloaded too. I agree: the CDN on which requests are offloaded must be able to handle the= offloaded requests. This (may) introduce requirements on the metadata (an= d control) interfaces. A.K.--> Yes, my point exactly, it would be useful to point that out in your= draft to make it complete and also have it noted in the "CDNI Requirements= Draft" . (...) (...) --_000_1B6D0317D3AD964FBF3956DEFA3524D51711E6A359EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
      Hi Kent
       
      What might be useful is to jut capture the require= ment=20 somewhere as i believe their will be numerous ways to address the overload = case=20 and i can see changes required not just on CDN-I metadata i/f as GIlles is= =20 pointing out too, so for now lets capture the requirement.
       
      Alan

      From: Kent Leung (kleung)=20 [mailto:kleung@cisco.com]
      Sent: November-15-11 3:52 AM
      To:= =20 gilles.bertrand@orange.com
      Cc: Alan Kavanagh;=20 cdni@ietf.org
      Subject: RE:=20 draft-ietf-cdni-cases-00

      Hi=20 Gilles.  I’m not sure if the requirements should be written expl= icitly to=20 map to use cases unless the functions are for that purpose only.  In t= his=20 case, there could be numerous reasons why dCDN provides its resource inform= ation=20 to the uCDN.

       

      The=20 discussion below indicates a need for RRI requirement, which can be traced = to=20 REQ-2.  Is this not sufficient?

       

      Kent

       

      From:<= /B>=20 gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]
      Sent:= =20 Tuesday, November 15, 2011 1:02 PM
      To: Kent Leung=20 (kleung)
      Cc: alan.kavanagh@ericsson.com;=20 cdni@ietf.org
      Subject: RE:=20 draft-ietf-cdni-cases-00

       

      Hi=20 Kent,

       

      As=20 raised by Alan in his e-mail below, in an offload use case the uCDN would=20 require information on the dCDNs to be aware of the amount of traffic it ca= n=20 offload to every dCDN. I think this requirement is already covered through = the=20 request routing interface as REQ-2 includes the advertising of information = about=20 dCDN resources. Maybe we might add a few words to REQ-2 to mention explicit= ly=20 that resource information could be needed for offload situations.=20

       

      I=20 am not 100% clear today if the offload use case introduces specific require= ments=20 on other interfaces (e.g., control and metadata) in addition to the request= =20 routing interface. I see some specificity in this use case, for instance, t= he=20 duration during which the uCDN will use the dCDN resources can be short in = an=20 offload situation (e.g., duration of a flash crowd) as compared to a footpr= int=20 extension use case.

       

      Best=20 regards,

       

       

      From:<= /B> gilles.bertrand@orange.com [= mailto:gilles.bertrand@orange.co= m]=20
      Sent: November-07-11 5:19 AM
      To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; trevor.burbridge@bt.com; philip.eardley@bt.com; kevin.ma@azukisystems.com
      = Cc:=20 cdni@ietf.org
      Subject: RE:=20 draft-ietf-cdni-cases-00

      (…)

       

      Section 3.1=20 Offloading. It should be noted that this use case would require knowledge a= bout=20 the other CDN to know if the other CDN has the resources to offload the req= uests=20 in the first place and also if the content is available in the CDN being=20 offloaded too.

      I=20 agree: the CDN on which requests are offloaded must be able to handle the=20 offloaded requests. This (may)  introduce requirements on the metadata= (and=20 control) interfaces.&= nbsp;

      A= .K.-->=20 Yes, my point exactly, it would be useful to point that out in your draft t= o=20 make it complete and also have it noted in the "CDNI=20 Requirements Draft" .= (…)

       

      To: Alan Kavanagh , "Kent Leung (kleung)" , "gilles.bertrand@orange.com" Thread-Topic: [CDNi] draft-ietf-cdni-cases-00 Thread-Index: AQHMpAPGyX90X1he+kODtf49YY+ujw== Date: Wed, 16 Nov 2011 02:02:22 +0000 Message-ID: In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A359@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 x-originating-ip: [147.191.125.12] Content-Type: multipart/alternative; boundary="_000_CAE882A01872Eyiuleecablecomcastcom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 16 Nov 2011 02:02:35 -0000 --_000_CAE882A01872Eyiuleecablecomcastcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Alan, I struggle how explicit we need to put in the requirement. Do you think a s= ub-bullet like: "information to signal overload to uCDN" is sufficient? Can= you suggest some text which you think REQ-2 doesn't capture? We would like= people to discuss the new text in the ML. Thanks, Yiu From: Alan Kavanagh > Date: Tue, 15 Nov 2011 19:56:48 -0500 To: "Kent Leung (kleung)" >, "gil= les.bertrand@orange.com" > Cc: "cdni@ietf.org" > Subject: Re: [CDNi] draft-ietf-cdni-cases-00 Hi Kent What might be useful is to jut capture the requirement somewhere as i belie= ve their will be numerous ways to address the overload case and i can see c= hanges required not just on CDN-I metadata i/f as GIlles is pointing out to= o, so for now lets capture the requirement. Alan ________________________________ From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: November-15-11 3:52 AM To: gilles.bertrand@orange.com Cc: Alan Kavanagh; cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 Hi Gilles. I=92m not sure if the requirements should be written explicitly= to map to use cases unless the functions are for that purpose only. In th= is case, there could be numerous reasons why dCDN provides its resource inf= ormation to the uCDN. The discussion below indicates a need for RRI requirement, which can be tra= ced to REQ-2. Is this not sufficient? Kent From: gilles.bertrand@orange.com [mailto= :gilles.bertrand@orange.com] Sent: Tuesday, November 15, 2011 1:02 PM To: Kent Leung (kleung) Cc: alan.kavanagh@ericsson.com; cdni@iet= f.org Subject: RE: draft-ietf-cdni-cases-00 Hi Kent, As raised by Alan in his e-mail below, in an offload use case the uCDN woul= d require information on the dCDNs to be aware of the amount of traffic it = can offload to every dCDN. I think this requirement is already covered thro= ugh the request routing interface as REQ-2 includes the advertising of info= rmation about dCDN resources. Maybe we might add a few words to REQ-2 to me= ntion explicitly that resource information could be needed for offload situ= ations. I am not 100% clear today if the offload use case introduces specific requi= rements on other interfaces (e.g., control and metadata) in addition to the= request routing interface. I see some specificity in this use case, for in= stance, the duration during which the uCDN will use the dCDN resources can = be short in an offload situation (e.g., duration of a flash crowd) as compa= red to a footprint extension use case. Best regards, Gilles ________________________________ From: gilles.bertrand@orange.com [mailto= :gilles.bertrand@orange.com] Sent: November-07-11 5:19 AM To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; trevor.burbridge@bt.com= ; philip.eardley@bt.com; kevin.ma@azukisystems.com Cc: cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 (=85) Section 3.1 Offloading. It should be noted that this use case would require= knowledge about the other CDN to know if the other CDN has the resources t= o offload the requests in the first place and also if the content is availa= ble in the CDN being offloaded too. I agree: the CDN on which requests are offloaded must be able to handle the= offloaded requests. This (may) introduce requirements on the metadata (an= d control) interfaces. A.K.--> Yes, my point exactly, it would be useful to point that out in your= draft to make it complete and also have it noted in the "CDNI Requirements= Draft" . (=85) (=85) _______________________________________________ CDNi mailing list CDNi@ietf= .org https://www.ietf.org/mailman/listinfo/cdni --_000_CAE882A01872Eyiuleecablecomcastcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <91AA6BC811C3734384779B480C532ECD@cable.comcast.com> Content-Transfer-Encoding: quoted-printable

      Hi Alan,

      I struggle how explicit we need to put in the requirement. Do you thin= k a sub-bullet like: "information to signal overload to uCDN" is = sufficient? Can you suggest some text which you think REQ-2 doesn't ca= pture? We would like people to discuss the new text in the ML.

      Thanks,
      Yiu

      From: Alan Kavanagh <alan.kavanagh@ericsson.com>
      Date: Tue, 15 Nov 2011 19:56:48 -05= 00
      To: "Kent Leung (kleung)"= <kleung@cisco.com>, "gilles.bertrand@orange.com&= quot; <gilles.bertrand@ora= nge.com>
      Cc: "cdni@ietf.org" <cdni@i= etf.org>
      Subject: Re: [CDNi] draft-ietf-cdni= -cases-00

      Hi Kent
       
      What might be useful is to jut ca= pture the requirement somewhere as i believe their will be numerous ways to= address the overload case and i can see changes required not just on CDN-I metadata i/f as GIlles is pointing out too, so = for now lets capture the requirement.
       
      Alan

      From: Kent Leung (kleung) [mailto:kleung@cisco.com]
      Sent: November-15-11 3:52 AM
      To: gilles.bertrand@or= ange.com
      Cc: Alan Kavanagh; cdni@ietf.org
      Subject: RE: draft-ietf-cdni-cases-00

      Hi Gilles.  I=92m not sure if= the requirements should be written explicitly to map to use cases unless t= he functions are for that purpose only.  In this case, there could be numerous reasons why dCDN provides its resource = information to the uCDN.

       

      The discussion below indicates a n= eed for RRI requirement, which can be traced to REQ-2.  Is this not su= fficient?

       

      Kent

       

      From: gilles.bertrand@orange.com [mailto:gilles.bertrand@ora= nge.com]
      Sent: Tuesday, November 15, 2011 1:02 PM
      To: Kent Leung (kleung)
      Cc: alan.kavanagh@eric= sson.com; cdni@ietf.org
      Subject: RE: draft-ietf-cdni-cases-00

       

      Hi Kent,

       

      As raised by Alan in his e-mail be= low, in an offload use case the uCDN would require information on the dCDNs= to be aware of the amount of traffic it can offload to every dCDN. I think this requirement is already covered = through the request routing interface as REQ-2 includes the advertising of = information about dCDN resources. Maybe we might add a few words to REQ-2 t= o mention explicitly that resource information could be needed for offload situations.

       

      I am not 100% clear today if the o= ffload use case introduces specific requirements on other interfaces (e.g.,= control and metadata) in addition to the request routing interface. I see some specificity in this use case, fo= r instance, the duration during which the uCDN will use the dCDN resources = can be short in an offload situation (e.g., duration of a flash crowd) as c= ompared to a footprint extension use case.

       

      Best regards,

       

      Gilles

       

       

      From: gilles.bertrand@orange.com [mailto:gilles.bertrand@ora= nge.com]
      Sent: November-07-11 5:19 AM
      To: Alan Kavanagh; emile= .stephan@orange.com; grant.watson@bt.com; trevor.burbridge@bt.com; phili= p.eardley@bt.com; kevin.ma@azukisystems.com<= br> Cc: cdni@ietf.org
      Subject: RE: draft-ietf-cdni-cases-00

      (=85)

       

      Section 3.1 Offloading. It should be noted that this use case= would require knowledge about the other CDN to know if the other CDN has t= he resources to offload the requests in the first place and also if the content is available in the CDN being o= ffloaded too.

      I agree: the CDN on which requests are offloaded must be = able to handle the offloaded requests. This (may)  introduce requireme= nts on the metadata (and control) interfaces. <= /o:p>

      A.K.--> Yes, my point exactly, it would be useful to point that out = in your draft to make it complete and also have it noted in the "CDNI = Requirements Draft" .

      (=85)

       

      (=85)

      _______________________________________________ CDNi mailing list CDNi@ietf.org ht= tps://www.ietf.org/mailman/listinfo/cdni       --_000_CAE882A01872Eyiuleecablecomcastcom_-- From alan.kavanagh@ericsson.com Tue Nov 15 18:16: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 DBD7F21F8DF2 for ; Tue, 15 Nov 2011 18:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.216 X-Spam-Level: X-Spam-Status: No, score=-6.216 tagged_above=-999 required=5 tests=[AWL=0.382, 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 zjtWhsezlCYU for ; Tue, 15 Nov 2011 18:16:00 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3551921F8DEF for ; Tue, 15 Nov 2011 18:16:00 -0800 (PST) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAG2Fv0m024445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2011 20:15:58 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 15 Nov 2011 21:15:57 -0500 From: Alan Kavanagh To: "Lee, Yiu" , "Kent Leung (kleung)" , "gilles.bertrand@orange.com" Date: Tue, 15 Nov 2011 21:15:55 -0500 Thread-Topic: [CDNi] draft-ietf-cdni-cases-00 Thread-Index: AQHMpAPGyX90X1he+kODtf49YY+uj5WuwCIw Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A38A@EUSAACMS0701.eamcs.ericsson.se> References: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A359@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_1B6D0317D3AD964FBF3956DEFA3524D51711E6A38AEUSAACMS0701e_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 16 Nov 2011 02:16:05 -0000 --_000_1B6D0317D3AD964FBF3956DEFA3524D51711E6A38AEUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yiu I never said it has to be explicit, then again capturing in the Requirement= s document suffices :-) Sure here is some text it just needs to be captured. " dCDN Should inform t= he uCDN it can not handle any requests at this time", I dont think it needs= to be noted as to why at a given instance of time the request can not be h= andled, if others feel different i would like to hear why. My only further = comment is the oposite, i.e. to inform the uCDN when it can handle requests= again. BR Alan ________________________________ From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com] Sent: November-15-11 9:02 PM To: Alan Kavanagh; Kent Leung (kleung); gilles.bertrand@orange.com Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 Hi Alan, I struggle how explicit we need to put in the requirement. Do you think a s= ub-bullet like: "information to signal overload to uCDN" is sufficient? Can= you suggest some text which you think REQ-2 doesn't capture? We would like= people to discuss the new text in the ML. Thanks, Yiu From: Alan Kavanagh > Date: Tue, 15 Nov 2011 19:56:48 -0500 To: "Kent Leung (kleung)" >, "gil= les.bertrand@orange.com" > Cc: "cdni@ietf.org" > Subject: Re: [CDNi] draft-ietf-cdni-cases-00 Hi Kent What might be useful is to jut capture the requirement somewhere as i belie= ve their will be numerous ways to address the overload case and i can see c= hanges required not just on CDN-I metadata i/f as GIlles is pointing out to= o, so for now lets capture the requirement. Alan ________________________________ From: Kent Leung (kleung) [mailto:kleung@cisco.com] Sent: November-15-11 3:52 AM To: gilles.bertrand@orange.com Cc: Alan Kavanagh; cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 Hi Gilles. I'm not sure if the requirements should be written explicitly t= o map to use cases unless the functions are for that purpose only. In this= case, there could be numerous reasons why dCDN provides its resource infor= mation to the uCDN. The discussion below indicates a need for RRI requirement, which can be tra= ced to REQ-2. Is this not sufficient? Kent From: gilles.bertrand@orange.com [mailto= :gilles.bertrand@orange.com] Sent: Tuesday, November 15, 2011 1:02 PM To: Kent Leung (kleung) Cc: alan.kavanagh@ericsson.com; cdni@iet= f.org Subject: RE: draft-ietf-cdni-cases-00 Hi Kent, As raised by Alan in his e-mail below, in an offload use case the uCDN woul= d require information on the dCDNs to be aware of the amount of traffic it = can offload to every dCDN. I think this requirement is already covered thro= ugh the request routing interface as REQ-2 includes the advertising of info= rmation about dCDN resources. Maybe we might add a few words to REQ-2 to me= ntion explicitly that resource information could be needed for offload situ= ations. I am not 100% clear today if the offload use case introduces specific requi= rements on other interfaces (e.g., control and metadata) in addition to the= request routing interface. I see some specificity in this use case, for in= stance, the duration during which the uCDN will use the dCDN resources can = be short in an offload situation (e.g., duration of a flash crowd) as compa= red to a footprint extension use case. Best regards, Gilles ________________________________ From: gilles.bertrand@orange.com [mailto= :gilles.bertrand@orange.com] Sent: November-07-11 5:19 AM To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; trevor.burbridge@bt.com= ; philip.eardley@bt.com; kevin.ma@azukisystems.com Cc: cdni@ietf.org Subject: RE: draft-ietf-cdni-cases-00 (...) Section 3.1 Offloading. It should be noted that this use case would require= knowledge about the other CDN to know if the other CDN has the resources t= o offload the requests in the first place and also if the content is availa= ble in the CDN being offloaded too. I agree: the CDN on which requests are offloaded must be able to handle the= offloaded requests. This (may) introduce requirements on the metadata (an= d control) interfaces. A.K.--> Yes, my point exactly, it would be useful to point that out in your= draft to make it complete and also have it noted in the "CDNI Requirements= Draft" . (...) (...) _______________________________________________ CDNi mailing list CDNi@ietf= .org https://www.ietf.org/mailman/listinfo/cdni --_000_1B6D0317D3AD964FBF3956DEFA3524D51711E6A38AEUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
      Hi=20 Yiu
       
      I never said=20 it has to be explicit, then again capturing in the Requirements document=20 suffices :-)
       
      Sure here is=20 some text it just needs to be captured. " dCDN Should inform the uCDN = it=20 can not handle any requests at this time", I dont think it needs to be note= d as=20 to why at a given instance of time the request can not be handled, if other= s=20 feel different i would like to hear why. My only further comment is the opo= site,=20 i.e. to inform the uCDN when it can handle requests=20 again. 
       
      BR
      Alan

      From: Lee, Yiu=20 [mailto:Yiu_Lee@Cable.Comcast.com]
      Sent: November-15-11 9:02=20 PM
      To: Alan Kavanagh; Kent Leung (kleung);=20 gilles.bertrand@orange.com
      Cc: cdni@ietf.org
      Subject: R= e:=20 [CDNi] draft-ietf-cdni-cases-00

      Hi Alan,

      I struggle how explicit we need to put in the requirement. Do you thin= k a=20 sub-bullet like: "information to signal overload to uCDN" is=20 sufficient? Can you suggest some text which you think REQ-2 doesn't=20 capture? We would like people to discuss the new text in the ML.

      Thanks,
      Yiu

      From: Alan Kavanagh <alan.kavanagh@ericsson.com&g= t;
      Date: Tue, 15 Nov 2011 19:56:48 -0500To: "Kent Leung (kleung)" <kleung@cisco.com>, "gilles.bertrand@orange.com" = <gilles.bertrand@orange.com&g= t;
      Cc: "cdni@ietf.org" <cdni@ietf.org>
      Subject: Re: [CDNi]=20 draft-ietf-cdni-cases-00

      Hi Kent
       
      What might be useful is to jut capture the require= ment=20 somewhere as i believe their will be numerous ways to address the overload = case=20 and i can see changes required not just on CDN-I metadata i/f as GIlles is= =20 pointing out too, so for now lets capture the requirement.
       
      Alan

      From: Kent Leung (kleung) [mailto:kleung@cisco.com]
      Sent:<= /B>=20 November-15-11 3:52 AM
      To: gilles.bertrand@orange.comCc:=20 Alan Kavanagh; cdni@ietf.org
      Subject: RE:=20 draft-ietf-cdni-cases-00

      Hi=20 Gilles.  I’m not sure if the requirements should be written expl= icitly to=20 map to use cases unless the functions are for that purpose only.  In t= his=20 case, there could be numerous reasons why dCDN provides its resource inform= ation=20 to the uCDN.

      The=20 discussion below indicates a need for RRI requirement, which can be traced = to=20 REQ-2.  Is this not sufficient?

      Kent

      From:= gilles.bertrand@orange.com [= mailto:gilles.bertrand@orange.co= m]=20
      Sent: Tuesday, November 15, 2011 1:02 PM
      To: Kent Leun= g=20 (kleung)
      Cc: alan.kavanagh@ericsson.com; = cdni@ietf.org
      Subject: RE:=20 draft-ietf-cdni-cases-00

      Hi=20 Kent,

      As=20 raised by Alan in his e-mail below, in an offload use case the uCDN would=20 require information on the dCDNs to be aware of the amount of traffic it ca= n=20 offload to every dCDN. I think this requirement is already covered through = the=20 request routing interface as REQ-2 includes the advertising of information = about=20 dCDN resources. Maybe we might add a few words to REQ-2 to mention explicit= ly=20 that resource information could be needed for offload situations.=20

      I=20 am not 100% clear today if the offload use case introduces specific require= ments=20 on other interfaces (e.g., control and metadata) in addition to the request= =20 routing interface. I see some specificity in this use case, for instance, t= he=20 duration during which the uCDN will use the dCDN resources can be short in = an=20 offload situation (e.g., duration of a flash crowd) as compared to a footpr= int=20 extension use case.

      Best=20 regards,

      Gilles

      From:= gilles.bertrand@orange.com [= mailto:gilles.bertrand@orange.co= m]=20
      Sent: November-07-11 5:19 AM
      To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; trevor.burbridge@bt.com; philip.eardley@bt.com; kevin.ma@azukisystems.com
      = Cc:=20 cdni@ietf.org
      Subject: RE:=20 draft-ietf-cdni-cases-00

      (…)

      Section 3.1 Offlo= ading.=20 It should be noted that this use case would require knowledge about the oth= er=20 CDN to know if the other CDN has the resources to offload the requests in t= he=20 first place and also if the content is available in the CDN being offloaded= =20 too.

      I=20 agree: the CDN on which requests are offloaded must be able to handle the=20 offloaded requests. This (may)  introduce requirements on the metadata= (and=20 control) interfaces.&nbs= p;

      A.K.= -->=20 Yes, my point exactly, it would be useful to point that out in your draft t= o=20 make it complete and also have it noted in the "CDNI=20 Requirements Draft" .

      (…)

      (…)

      ______________= _________________________________=20 CDNi mailing list CDNi@ietf.org https://www.ietf.org/ma= ilman/listinfo/cdni=20 --_000_1B6D0317D3AD964FBF3956DEFA3524D51711E6A38AEUSAACMS0701e_-- From alan.kavanagh@ericsson.com Tue Nov 15 18:44: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 0AD491F0CAF for ; Tue, 15 Nov 2011 18:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.350, 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 Sg-SOZ9yKIoE for ; Tue, 15 Nov 2011 18:43:55 -0800 (PST) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 749CE1F0CAD for ; Tue, 15 Nov 2011 18:43:55 -0800 (PST) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id pAG2hsnx025330 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2011 20:43:54 -0600 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.111]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Tue, 15 Nov 2011 21:43:53 -0500 From: Alan Kavanagh To: Ben Niven-Jenkins , "gilles.bertrand@orange.com" Date: Tue, 15 Nov 2011 21:43:52 -0500 Thread-Topic: [CDNi] dCDN capacity & offload (Re: draft-ietf-cdni-cases-00) Thread-Index: AcyjeecgiIY9n35tQCy/z7ZQaBXY7gAj3FlA Message-ID: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A393@EUSAACMS0701.eamcs.ericsson.se> References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr> <1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se> <8E09C72DBC577D489F13A71228C0B7BF02DC8772@ftrdmel0.rd.francetelecom.fr> <7C7A0647-3CDA-4ED0-AF76-D48DFF8C1FE7@niven-jenkins.co.uk> In-Reply-To: <7C7A0647-3CDA-4ED0-AF76-D48DFF8C1FE7@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] dCDN capacity & offload (Re: draft-ietf-cdni-cases-00) 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, 16 Nov 2011 02:44:00 -0000 Sure, I don't believe you need to send that info, as that can cause other p= roblems I can forsee. What makes more sense as I just hinted is to just say= you CAN-NOT server this request and that is all. I fully agree you don't n= eed to disclose any detailed information, my view is its just a yes I can s= erve or no I cant serve at this given time. Alan=20 -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben= Niven-Jenkins Sent: November-15-11 4:35 AM To: gilles.bertrand@orange.com Cc: cdni@ietf.org Subject: [CDNi] dCDN capacity & offload (Re: draft-ietf-cdni-cases-00) On 15 Nov 2011, at 05:02, wrote: > As raised by Alan in his e-mail below, in an offload use case the uCDN wo= uld require information on the dCDNs to be aware of the amount of traffic i= t can offload to every dCDN. I think this requirement is already covered th= rough the request routing interface as REQ-2 includes the advertising of in= formation about dCDN resources. Maybe we might add a few words to REQ-2 to = mention explicitly that resource information could be needed for offload si= tuations. This might not be what you meant (and if that's the case I apologise and ju= st ignore me) but I'm not convinced that the uCDN needs to know how much ca= pacity the dCDN has available. Instead it just needs to know if the dCDN is= prepared "to do more work" on behalf of the uCDN. Ben > =20 > I am not 100% clear today if the offload use case introduces specific req= uirements on other interfaces (e.g., control and metadata) in addition to t= he request routing interface. I see some specificity in this use case, for = instance, the duration during which the uCDN will use the dCDN resources ca= n be short in an offload situation (e.g., duration of a flash crowd) as com= pared to a footprint extension use case. > =20 > Best regards, > =20 > Gilles > =20 > =20 > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > Sent: November-07-11 5:19 AM > To: Alan Kavanagh; emile.stephan@orange.com;=20 > grant.watson@bt.com;trevor.burbridge@bt.com; philip.eardley@bt.com;=20 > kevin.ma@azukisystems.com > Cc: cdni@ietf.org > Subject: RE: draft-ietf-cdni-cases-00 >=20 > (...) > =20 > Section 3.1 Offloading. It should be noted that this use case would requi= re knowledge about the other CDN to know if the other CDN has the resources= to offload the requests in the first place and also if the content is avai= lable in the CDN being offloaded too. > I agree: the CDN on which requests are offloaded must be able to handle t= he offloaded requests. This (may) introduce requirements on the metadata (= and control) interfaces.=20 > A.K.--> Yes, my point exactly, it would be useful to point that out in yo= ur draft to make it complete and also have it noted in the "CDNI Requiremen= ts Draft" . > (...) > =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 Martin.Stiemerling@neclab.eu Tue Nov 15 19:00: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 E0A5321F8F25 for ; Tue, 15 Nov 2011 19:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 DeIChLGpZKD9 for ; Tue, 15 Nov 2011 19:00:28 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 782BE21F8F1F for ; Tue, 15 Nov 2011 19:00:28 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 774FF280000FA for ; Wed, 16 Nov 2011 04:00:27 +0100 (CET) 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 8FAPyOeqMw2j for ; Wed, 16 Nov 2011 04:00:27 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 5D95828000080 for ; Wed, 16 Nov 2011 04:00:22 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 04:00:22 +0100 From: Martin Stiemerling To: "cdni@ietf.org" Thread-Topic: BGP and prefix hijacking (CDN footprint capability ) Thread-Index: AcykC4+M9yzdU4gXSEeFRyfO2olZYQ== Date: Wed, 16 Nov 2011 03:00:21 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.203] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] BGP and prefix hijacking (CDN footprint capability ) 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, 16 Nov 2011 03:00:33 -0000 Hi all, Just to follow-up the current discussion about using BGP for CDN footprint = capability handling we had in the CDNi session some minutes ago.=20 BGP is vulnerable to letting ISPs announcing IP prefixes which they are act= ually not own by them: http://en.wikipedia.org/wiki/IP_hijacking This will cause that the traffic for particular prefixes to not reach the i= ntended destination, actually creating a black hole for this traffic. This links documents also a very prominent case of prefix hijacking.=20 This would be also applicable if using BPG (and variants of it) for the CDN= footprint capability handling. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014=20 From flefauch@cisco.com Tue Nov 15 20:36: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 0E57F11E80F0 for ; Tue, 15 Nov 2011 20:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=0.252, 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 r7NZs8IRz1aZ for ; Tue, 15 Nov 2011 20:36:32 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4105011E80D7 for ; Tue, 15 Nov 2011 20:36:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=4226; q=dns/txt; s=iport; t=1321418192; x=1322627792; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=fGLNJwSgCVqbXEPIy3kjSI5yLybFy06mCy3SfT0ZZOI=; b=C+RHWXGbFLHum2EwzcPJa84ncvKjW3LCunI4D0uLxYUAiMcwycs9Qxsx Sce/BkcK8h6KPiPFXXCk87G3Yw+llpYIxAugjgEOxONDzl7ybS9MRkG4v 2BaCtOQKK+qR9YxFCj4uhj3YU+Xyz6abeJBviYC7FU2+VvNXckumHKAIh c=; X-IronPort-AV: E=Sophos;i="4.69,519,1315180800"; d="scan'208,217";a="36409734" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 16 Nov 2011 04:36:32 +0000 Received: from rtp-vpn4-1180.cisco.com (rtp-vpn4-1180.cisco.com [10.82.212.156]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAG4aU5E032136; Wed, 16 Nov 2011 04:36:30 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-356--486394678 From: Francois Le Faucheur In-Reply-To: Date: Wed, 16 Nov 2011 12:36:28 +0800 Message-Id: <49DD48EB-FF78-416C-829D-AD4E22F03142@cisco.com> References: To: Martin Stiemerling X-Mailer: Apple Mail (2.1084) Cc: "cdni@ietf.org" Subject: Re: [CDNi] BGP and prefix hijacking (CDN footprint capability ) 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, 16 Nov 2011 04:36:37 -0000 --Apple-Mail-356--486394678 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin, I think: * what can be concluded from this information is that the CDNI = WG really needs to consider the security aspects associated with = "Footprint & Capabilities Advertisement". * what certainly can not be concluded from this information is = that one approach on the table (e.g. BGP) is less suitable than another = (e.g. ALTO, Web-services based) for "Footprint & Capabilities = Advertisement". Are we in line? Thanks Francois On 16 Nov 2011, at 11:00, Martin Stiemerling wrote: > Hi all, >=20 > Just to follow-up the current discussion about using BGP for CDN = footprint capability handling we had in the CDNi session some minutes = ago.=20 >=20 > BGP is vulnerable to letting ISPs announcing IP prefixes which they = are actually not own by them: > http://en.wikipedia.org/wiki/IP_hijacking >=20 > This will cause that the traffic for particular prefixes to not reach = the intended destination, actually creating a black hole for this = traffic. >=20 > This links documents also a very prominent case of prefix hijacking.=20= >=20 > This would be also applicable if using BPG (and variants of it) for = the CDN footprint capability handling. >=20 > Martin >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014=20 >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-356--486394678 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Martin,

      I think:
      = * what can be concluded from this information is that the = CDNI WG really needs to consider the security aspects associated with = "Footprint & Capabilities Advertisement".
      * what = certainly can not be concluded from this information is that one = approach on the table (e.g. BGP) is less suitable than another =  (e.g. ALTO, Web-services based) for "Footprint & Capabilities = Advertisement".

      Are we in = line?

      Thanks

      Francois

      On 16 Nov 2011, at 11:00, Martin Stiemerling = wrote:

      Hi all,

      Just to follow-up the current = discussion about using BGP for CDN footprint capability handling we had = in the CDNi session some minutes ago.

      BGP is vulnerable to = letting ISPs announcing IP prefixes which they are actually not own by = them:
      http://en.wikipedia.org= /wiki/IP_hijacking

      This will cause that the traffic for = particular prefixes to not reach the intended destination, actually = creating a black hole for this traffic.

      This links documents also = a very prominent case of prefix hijacking.

      This would be also = applicable if using BPG (and variants of it) for the CDN footprint = capability handling.

      =  Martin

      martin.stiemerling@neclab.eu

      NEC Laboratories = Europe - Network Research Division NEC Europe Limited | Registered = Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 =


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

      Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 13:11:14 +0800 Message-Id: <0F5F628D-CD78-4AF6-9638-4F93F6DDF2B1@cisco.com> To: Bruce Davie , Larry Peterson Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: [CDNi] Discussing "Adaptive Streaming" more in cdni-framework 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, 16 Nov 2011 05:11:23 -0000 Bruce, Larry, I just wanted to pass on a suggestion made during the WG session. =46rom talking to people this week, it became clear to me that: * just about everyone expects a CDNI mesh to support content = delivery via HTTP Adaptive Streaming * people have different expectations about how CDNI supports = this. So my suggestion is that the framework very explicitly addresses this = question (perhaps even as a standalone section, so people can easily = find the discussion on that specific question). In line with the general = current approach of the framework, the expectation would not be that the = framework mandates a given approach, but explores the design spaces, and = helps analysis and converging on if/what CDNI interfaces need to support = something specific for adaptive. A few aspects that come to mind are: * Request Routing: should/can request routing be performed more = efficiently than once per segment? * Acquisition: should/can acquisition be performed on a = per-segment basis or differently? * Logging: the framework already brings up the point about = logging for adaptive in section 4.3 =20 * Metadata: is any specific metadata required. Can you consider expanding the discussion on adaptive streaming in the = next rev? Thanks Francois From lpeterson@verivue.com Wed Nov 16 04:55: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 92AB711E8085 for ; Wed, 16 Nov 2011 04:55:11 -0800 (PST) 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 nUQ3aFqUm92K for ; Wed, 16 Nov 2011 04:55:11 -0800 (PST) Received: from exprod8og108.obsmtp.com (exprod8og108.obsmtp.com [64.18.3.96]) by ietfa.amsl.com (Postfix) with ESMTP id 563EA11E8083 for ; Wed, 16 Nov 2011 04:55:09 -0800 (PST) Received: from vvexch.verivue.com ([173.237.194.68]) (using TLSv1) by exprod8ob108.postini.com ([64.18.7.12]) with SMTP ID DSNKTsOynPcN8Pq9dcfqPGArM/RAGRzVQB1n@postini.com; Wed, 16 Nov 2011 04:55:10 PST Received: from vvexch.verivue.com ([10.160.6.20]) by vvexch.verivue.com ([10.160.6.20]) with mapi; Wed, 16 Nov 2011 07:54:51 -0500 From: "Peterson, Larry" To: Francois Le Faucheur , Bruce Davie Date: Wed, 16 Nov 2011 07:54:50 -0500 Thread-Topic: Discussing "Adaptive Streaming" more in cdni-framework Thread-Index: AcykHi4G6pEbzKtMQGOHhIxwq4XbIwAQL+ur Message-ID: 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_CA37919E3D994F638133D2FA1900C2FFverivuecom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Discussing "Adaptive Streaming" more in cdni-framework 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, 16 Nov 2011 12:55:11 -0000 --_000_CA37919E3D994F638133D2FA1900C2FFverivuecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. We need to explicitly discuss adaptive streaming in the framework = doc. Sent from my Verizon Wireless Phone ----- Reply message ----- From: "Francois Le Faucheur" To: "Bruce Davie" , "Peterson, Larry" Cc: "Le Faucheur Francois" , "Aaron Falk" , "cdni@ietf.org" Subject: Discussing "Adaptive Streaming" more in cdni-framework Date: Wed, Nov 16, 2011 12:11 am Bruce, Larry, I just wanted to pass on a suggestion made during the WG session. >From talking to people this week, it became clear to me that: * just about everyone expects a CDNI mesh to support content delive= ry via HTTP Adaptive Streaming * people have different expectations about how CDNI supports this. So my suggestion is that the framework very explicitly addresses this quest= ion (perhaps even as a standalone section, so people can easily find the di= scussion on that specific question). In line with the general current appro= ach of the framework, the expectation would not be that the framework manda= tes a given approach, but explores the design spaces, and helps analysis an= d converging on if/what CDNI interfaces need to support something specific = for adaptive. A few aspects that come to mind are: * Request Routing: should/can request routing be performed more eff= iciently than once per segment? * Acquisition: should/can acquisition be performed on a per-segment= basis or differently? * Logging: the framework already brings up the point about logging = for adaptive in section 4.3 * Metadata: is any specific metadata required. Can you consider expanding the discussion on adaptive streaming in the next= rev? Thanks Francois --_000_CA37919E3D994F638133D2FA1900C2FFverivuecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree. We need to explicitly discuss adaptive streaming in = the framework doc.

      Sent from my Verizon Wireless Phone

      ----- Reply message -----
      From: "Franc= ois Le Faucheur" <flefauch@cisco.com>
      To: "Bruce Davie&q= uot; <bdavie@cisco.com>, "Peterson, Larry" <lpeterson@ve= rivue.com>
      Cc: "Le Faucheur Francois" <flefauch@cisco.co= m>, "Aaron Falk" <aaron.falk@gmail.com>, "cdni@ietf= .org" <cdni@ietf.org>
      Subject: Discussing "Adaptive Stre= aming" more in cdni-framework
      Date: Wed, Nov 16, 2011 12:11 am
      <= br>


      Bruce, Larry,

      I just wanted to pass on a suggestion made during the WG session.

      >From talking to people this week, it became clear to me that:
              * just about everyone expects a = CDNI mesh to support content delivery via HTTP Adaptive Streaming
              * people have different expectat= ions about how CDNI supports this.

      So my suggestion is that the framework very explicitly addresses this quest= ion (perhaps even as a standalone section, so people can easily find the di= scussion on that specific question). In line with the general current appro= ach of the framework, the expectation would not be that the framework manda= tes a given approach, but explores the design spaces, and helps analysis an= d converging on if/what CDNI interfaces need to support something specific = for adaptive.
      A few aspects that come to mind are:
              * Request Routing: should/can re= quest routing be performed more efficiently than once per segment?
              * Acquisition: should/can acquis= ition be performed on a per-segment basis or differently?
              * Logging: the framework already= brings up the point about logging for adaptive in section 4.3 
              * Metadata: is any specific meta= data required.

      Can you consider expanding the discussion on adaptive streaming in the next= rev?

      Thanks

      Francois




       --_000_CA37919E3D994F638133D2FA1900C2FFverivuecom_-- From swainner@cisco.com Wed Nov 16 05:16: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 4A03921F9635 for ; Wed, 16 Nov 2011 05:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.523 X-Spam-Level: X-Spam-Status: No, score=-4.523 tagged_above=-999 required=5 tests=[AWL=2.075, 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 BEKg+vG2-3Sk for ; Wed, 16 Nov 2011 05:16:19 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 3986C21F9503 for ; Wed, 16 Nov 2011 05:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=swainner@cisco.com; l=13131; q=dns/txt; s=iport; t=1321449379; x=1322658979; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=SebH0iL5Nq2PERd7+n8HtISjDkwHY17yOsuXoBy6eMo=; b=GiS1Z1nJm2Rdh9seBmP70hJypzKC+bd0aKh/hM8wB9uhQ7qZUnhIeN6B B9kfPpiHQvZjkbKSzgbZcGRHOvvi0M8AM0bUPuwEtONdTXHexdbVU8Weh L5YbJRDTr5e75Er9MOsHJmsXkY+F9fvaiNf1J3ZQr8vfCLJiwug5T0sko Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGm2w06rRDoG/2dsb2JhbABDqXeBBYFyAQEBAwEBAQEPARQGQQoNBAsRBAEBAQkWCAcJAwIBAgEVHwkIEwYCAQEeh2AImjsBnmUEihcEiBSMIJIa X-IronPort-AV: E=Sophos;i="4.69,521,1315180800"; d="scan'208,217";a="14542955" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 16 Nov 2011 13:16:19 +0000 Received: from stealth-10-32-245-62.cisco.com (stealth-10-32-245-62.cisco.com [10.32.245.62]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAGDGIs6016340 for ; Wed, 16 Nov 2011 13:16:18 GMT Message-ID: <4EC3B78C.6030104@cisco.com> Date: Wed, 16 Nov 2011 08:15:56 -0500 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: cdni@ietf.org References: <1B6D0317D3AD964FBF3956DEFA3524D51710BD9EFC@EUSAACMS0701.eamcs.ericsson.se><8E09C72DBC577D489F13A71228C0B7BF02D8D6CA@ftrdmel0.rd.francetelecom.fr><1B6D0317D3AD964FBF3956DEFA3524D51711E69B20@EUSAACMS0701.eamcs.ericsson.se><8E09C72DBC577D489F13A71228C0B7BF02DC8772@ftrdmel0.rd.francetelecom.fr><7C7A0647-3CDA-4ED0-AF76-D48DFF8C1FE7@niven-jenkins.co.uk> <1B6D0317D3AD964FBF3956DEFA3524D51711E6A393@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A393@EUSAACMS0701.eamcs.ericsson.se> Content-Type: multipart/alternative; boundary="------------090800040807090701000606" Subject: Re: [CDNi] dCDN capacity & offload (Re: draft-ietf-cdni-cases-00) 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, 16 Nov 2011 13:16:20 -0000 This is a multi-part message in MIME format. --------------090800040807090701000606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I presume we're talking about a binary decision (CAN SERVE / CANNOT SERVE) for a given class of services. I also presume that the uCDN has made a decision that this particular dCDN is the right CDN to deliver the content (because the dCDN said it CAN SERVE and the uCDN determined that dCDN was the best choice). We're not talking about isolated overload situations within the dCDN. Given the uCDN has determined that the dCDN CAN SERVE, that dCDN must serve the content even if the dCDN cannot serve it from the most efficient location within the dCDN. I would also think that the uCDN will dampen the loading to prevent a scenario where the following happens: 1) dCDN CAN SERVE 2) uCDN loads up the dCDN up 3) dCDN CANNOT SERVE because of the loading from uCDN 4) uCDN off-loads that dCDN 5) return to 1 Is there merit in adding another condition advertised by the dCDN that the uCDN can use in the evaluation criteria (e.g. CANNOT SERVE, OFF-LOAD, CAN SERVE). The dCDN can determine under what conditions it wants to OFF-LOAD that class of traffic (internal threshold, internal network fault, maintenance, etc.). Scott On 11/15/11 9:43 PM, Alan Kavanagh wrote: > > Sure, I don't believe you need to send that info, as that can cause > other problems I can forsee. What makes more sense as I just hinted is > to just say you CAN-NOT server this request and that is all. I fully > agree you don't need to disclose any detailed information, my view is > its just a yes I can serve or no I cant serve at this given time. > > Alan > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of Ben Niven-Jenkins > Sent: November-15-11 4:35 AM > To: gilles.bertrand@orange.com > Cc: cdni@ietf.org > Subject: [CDNi] dCDN capacity & offload (Re: draft-ietf-cdni-cases-00) > > > On 15 Nov 2011, at 05:02, wrote: > > As raised by Alan in his e-mail below, in an offload use case the > uCDN would require information on the dCDNs to be aware of the amount > of traffic it can offload to every dCDN. I think this requirement is > already covered through the request routing interface as REQ-2 > includes the advertising of information about dCDN resources. Maybe we > might add a few words to REQ-2 to mention explicitly that resource > information could be needed for offload situations. > > This might not be what you meant (and if that's the case I apologise > and just ignore me) but I'm not convinced that the uCDN needs to know > how much capacity the dCDN has available. Instead it just needs to > know if the dCDN is prepared "to do more work" on behalf of the uCDN. > > Ben > > > > > I am not 100% clear today if the offload use case introduces > specific requirements on other interfaces (e.g., control and metadata) > in addition to the request routing interface. I see some specificity > in this use case, for instance, the duration during which the uCDN > will use the dCDN resources can be short in an offload situation > (e.g., duration of a flash crowd) as compared to a footprint extension > use case. > > > > Best regards, > > > > Gilles > > > > > > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com] > > Sent: November-07-11 5:19 AM > > To: Alan Kavanagh; emile.stephan@orange.com; > > grant.watson@bt.com;trevor.burbridge@bt.com; philip.eardley@bt.com; > > kevin.ma@azukisystems.com > > Cc: cdni@ietf.org > > Subject: RE: draft-ietf-cdni-cases-00 > > > > (...) > > > > Section 3.1 Offloading. It should be noted that this use case would > require knowledge about the other CDN to know if the other CDN has the > resources to offload the requests in the first place and also if the > content is available in the CDN being offloaded too. > > I agree: the CDN on which requests are offloaded must be able to > handle the offloaded requests. This (may) introduce requirements on > the metadata (and control) interfaces. > > A.K.--> Yes, my point exactly, it would be useful to point that out > in your draft to make it complete and also have it noted in the "CDNI > Requirements Draft" . > > (...) > > > > (...) > > _______________________________________________ > > 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 > --------------090800040807090701000606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I presume we're talking about a binary decision (CAN SERVE / CANNOT SERVE) for a given class of services.

      I also presume that the uCDN has made a decision that this particular dCDN is the right CDN to deliver the content (because the dCDN said it CAN SERVE and the uCDN determined that dCDN was the best choice).  We're not talking about isolated overload situations within the dCDN.  Given the uCDN has determined that the dCDN CAN SERVE, that dCDN must serve the content even if the dCDN cannot serve it from the most efficient location within the dCDN.

      I would also think that the uCDN will dampen the loading to prevent a scenario where the following happens:

      1) dCDN CAN SERVE
      2) uCDN loads up the dCDN up
      3) dCDN CANNOT SERVE because of the loading from uCDN
      4) uCDN off-loads that dCDN
      5) return to 1

      Is there merit in adding another condition advertised by the dCDN that the uCDN can use in the evaluation criteria (e.g. CANNOT SERVE, OFF-LOAD, CAN SERVE).  The dCDN can determine under what conditions it wants to OFF-LOAD that class of traffic (internal threshold, internal network fault, maintenance, etc.).

      Scott

      On 11/15/11 9:43 PM, Alan Kavanagh wrote:
      Re: [CDNi] dCDN capacity & offload (Re: draft-ietf-cdni-cases-00)

      Sure, I don't believe you need to send that info, as that can cause other problems I can forsee. What makes more sense as I just hinted is to just say you CAN-NOT server this request and that is all. I fully agree you don't need to disclose any detailed information, my view is its just a yes I can serve or no I cant serve at this given time.

      Alan

      -----Original Message-----
      From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins
      Sent: November-15-11 4:35 AM
      To: gilles.bertrand@orange.com
      Cc: cdni@ietf.org
      Subject: [CDNi] dCDN capacity & offload (Re: draft-ietf-cdni-cases-00)


      On 15 Nov 2011, at 05:02, <gilles.bertrand@orange.com> wrote:
      > As raised by Alan in his e-mail below, in an offload use case the uCDN would require information on the dCDNs to be aware of the amount of traffic it can offload to every dCDN. I think this requirement is already covered through the request routing interface as REQ-2 includes the advertising of information about dCDN resources. Maybe we might add a few words to REQ-2 to mention explicitly that resource information could be needed for offload situations.

      This might not be what you meant (and if that's the case I apologise and just ignore me) but I'm not convinced that the uCDN needs to know how much capacity the dCDN has available. Instead it just needs to know if the dCDN is prepared "to do more work" on behalf of the uCDN.

      Ben

      > 
      > I am not 100% clear today if the offload use case introduces specific requirements on other interfaces (e.g., control and metadata) in addition to the request routing interface. I see some specificity in this use case, for instance, the duration during which the uCDN will use the dCDN resources can be short in an offload situation (e.g., duration of a flash crowd) as compared to a footprint extension use case.
      > 
      > Best regards,
      > 
      > Gilles
      > 
      > 
      > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]
      > Sent: November-07-11 5:19 AM
      > To: Alan Kavanagh; emile.stephan@orange.com;
      > grant.watson@bt.com;trevor.burbridge@bt.com; philip.eardley@bt.com;
      > kevin.ma@azukisystems.com
      > Cc: cdni@ietf.org
      > Subject: RE: draft-ietf-cdni-cases-00
      >
      > (...)
      > 
      > Section 3.1 Offloading. It should be noted that this use case would require knowledge about the other CDN to know if the other CDN has the resources to offload the requests in the first place and also if the content is available in the CDN being offloaded too.
      > I agree: the CDN on which requests are offloaded must be able to handle the offloaded requests. This (may)  introduce requirements on the metadata (and control) interfaces.
      > A.K.--> Yes, my point exactly, it would be useful to point that out in your draft to make it complete and also have it noted in the "CDNI Requirements Draft" .
      > (...)
      > 
      > (...)
      > _______________________________________________
      > 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


      --------------090800040807090701000606-- From christian.timmerer@itec.uni-klu.ac.at Wed Nov 16 06: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 C741921F969D for ; Wed, 16 Nov 2011 06:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.429 X-Spam-Level: X-Spam-Status: No, score=-1.429 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, 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 OgxVsRBc3rkO for ; Wed, 16 Nov 2011 06:17:39 -0800 (PST) Received: from mailsrv.uni-klu.ac.at (mailsrv.uni-klu.ac.at [143.205.180.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C39921F8BF7 for ; Wed, 16 Nov 2011 06:17:39 -0800 (PST) Received: from mailsrv.uni-klu.ac.at (localhost [127.0.0.1]) by mailsrv.uni-klu.ac.at (Postfix) with ESMTP id A627585154; Wed, 16 Nov 2011 15:17:38 +0100 (CET) Received: from mailsrv.itec.uni-klu.ac.at (mailsrv-itec.uni-klu.ac.at [143.205.176.139]) by mailsrv.uni-klu.ac.at (Postfix) with ESMTP id 9790285135; Wed, 16 Nov 2011 15:17:37 +0100 (CET) Received: from mailsrv.itec.uni-klu.ac.at (localhost [127.0.0.1]) by mailsrv.itec.uni-klu.ac.at (Postfix) with ESMTP id 7C1FC13805E2; Wed, 16 Nov 2011 15:17:37 +0100 (CET) Received: from nbmac2.itec.uni-klu.ac.at (nbmac2.itec.uni-klu.ac.at [143.205.122.140]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailsrv.itec.uni-klu.ac.at (Postfix) with ESMTPSA id 6668E1380196; Wed, 16 Nov 2011 15:17:37 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_3328712F-2FBC-420A-A6FE-20755C803845" From: Christian Timmerer (ITEC) In-Reply-To: Date: Wed, 16 Nov 2011 15:17:35 +0100 Message-Id: <54E731E9-CCE5-42BF-9F1C-63F5893B606B@itec.uni-klu.ac.at> References: To: "Peterson, Larry" , Francois Le Faucheur , Bruce Davie X-Mailer: Apple Mail (2.1251.1) X-AV-Checked: ClamAV at mailsrv.itec.uni-klu.ac.at X-Virus-Scanned: ClamAV using ClamSMTP Cc: cdni@ietf.org Subject: Re: [CDNi] Discussing "Adaptive Streaming" more in cdni-framework 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, 16 Nov 2011 14:17:40 -0000 --Apple-Mail=_3328712F-2FBC-420A-A6FE-20755C803845 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >=20 > Bruce, Larry, >=20 > I just wanted to pass on a suggestion made during the WG session. >=20 > =46rom talking to people this week, it became clear to me that: > * just about everyone expects a CDNI mesh to support content = delivery via HTTP Adaptive Streaming > * people have different expectations about how CDNI supports = this. >=20 > So my suggestion is that the framework very explicitly addresses this = question (perhaps even as a standalone section, so people can easily = find the discussion on that specific question). In line with the general = current approach of the framework, the expectation would not be that the = framework mandates a given approach, but explores the design spaces, and = helps analysis and converging on if/what CDNI interfaces need to support = something specific for adaptive. > A few aspects that come to mind are: > * Request Routing: should/can request routing be performed = more efficiently than once per segment? > * Acquisition: should/can acquisition be performed on a = per-segment basis or differently? Depending on whether segments or subsegments are used. In the former = case, the content is physically divided into segments, each individually = addressable by HTTP URL whereas in the latter case, the content is = logically divided into segments, each individually addressable by HTTP = byte range requests. > * Logging: the framework already brings up the point about = logging for adaptive in section 4.3 =20 For example, MPEG-DASH defines already some metrics that are related to = what is defined in section 4.3 but, of course, go beyond and are = specific to DASH. However, some are probably applicable in a more = general HTTP adaptive streaming context. > * Metadata: is any specific metadata required. The manifest file, for example. Best regards, -Christian >=20 > Can you consider expanding the discussion on adaptive streaming in the = next rev? >=20 > Thanks >=20 > Francois >=20 >=20 >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail=_3328712F-2FBC-420A-A6FE-20755C803845 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
      Bruce, = Larry,

      I just wanted to pass on a suggestion made during the WG = session.

      =46rom talking to people this week, it became clear to = me that:
              * just about = everyone expects a CDNI mesh to support content delivery via HTTP = Adaptive Streaming
              * = people have different expectations about how CDNI supports = this.

      So my suggestion is that the framework very explicitly = addresses this question (perhaps even as a standalone section, so people = can easily find the discussion on that specific question). In line with = the general current approach of the framework, the expectation would not = be that the framework mandates a given approach, but explores the design = spaces, and helps analysis and converging on if/what CDNI interfaces = need to support something specific for adaptive.
      A few aspects that = come to mind are:
              * = Request Routing: should/can request routing be performed more = efficiently than once per = segment?
              * Acquisition: = should/can acquisition be performed on a per-segment basis or = differently?
      Depending on = whether segments or subsegments are used. In the former case, the = content is physically divided into segments, each individually = addressable by HTTP URL whereas in the latter case, the content is = logically divided into segments, each individually addressable by HTTP = byte range requests.

              * = Logging: the framework already brings up the point about logging for = adaptive in section 4.3  
      For example, MPEG-DASH defines already some metrics that = are related to what is defined in section 4.3 but, of course, go beyond = and are specific to DASH. However, some are probably applicable in a = more general HTTP adaptive streaming = context.

              * = Metadata: is any specific metadata = required.
      The manifest file, = for example.

      Best = regards,
       -Christian


      Can you consider expanding the = discussion on adaptive streaming in the next = rev?

      Thanks

      Francois




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

      = --Apple-Mail=_3328712F-2FBC-420A-A6FE-20755C803845-- From kevin.ma@azukisystems.com Wed Nov 16 10:24:41 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 1490511E80D2 for ; Wed, 16 Nov 2011 10:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, 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 MXNYkGUjHJhH for ; Wed, 16 Nov 2011 10:24:40 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6F76811E808C for ; Wed, 16 Nov 2011 10:24:40 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id B82D97B4D5B; Wed, 16 Nov 2011 13:24:39 -0500 (EST) 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 5C4667B4D3F; Wed, 16 Nov 2011 13:24:39 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.15]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Wed, 16 Nov 2011 13:24:34 -0500 From: Kevin J Ma To: Serge Manning , "cdni@ietf.org" Date: Wed, 16 Nov 2011 13:24:37 -0500 Thread-Topic: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI Thread-Index: AcyQOxse4JWFVMU1TkeAjhuT/i/3wwUEcUOQ Message-ID: <291CC3F9E50E7641901A54E85D0977C651B6CD51F6@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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Wed, 16 Nov 2011 18:24:41 -0000 Serge (and Kent), Some questions/comments on the requirements in the draft: LOG-A1/A2 seem like a good idea. They seem to mimic the existing LOG-2/3 requirements, respectively, which seems fine, but do we need to have separate requirements for these or can we just update LOG-2/3 to include failures? One question about LOG-2 and LOG-A1: is the text "deliveries to User Agents" intended to imply that the data should track and be aggregatable per unique user? We may want to clarify that? LOG-A3/A4 sound reasonable. Should we include bandwidth or other usage metrics as well and can they all be included in one usage metric requirement (similar to META-14)? The example metrics in LOG-A3 seem like they could be exposing intra-CDN information (e.g., total GB)? Does this go against the GEN-4 requirement? LOG-A5 could be interpreted as either: a) configure the dCDN to do storage reporting, or b) ask the dCDN to immediately send out logs? If the latter, it seems to overlap with the existing LOG-9 requirement? Are LOG-A3/A4 intended to be periodic, or only on-demand? If the latter, then is it just an issue of raising LOG-9 from LOW to MED? Note: LOG-9/A5 should probably be included in the 'trigger' discussion? LOG-A6 seems like two requirements, that could be parts of a more generic set of LOG-A3/A5 requirements? LOG-A7 sounds ok, but is the confirmation from the delete request not sufficient? Is a log of individual deleted objects only meaningful if the object was there to be deleted, i.e. does it need to compare against everything that was acquired but not yet evicted? LOG-A8/A9 seem reasonable, though they feel more like a MED than a HIGH to me. Assuming they are HIGH, could we just update the existing LOG-7 requirement to include extensibility? Is there an existing log description language that could/should be used here? CNTL-A1 seems to overlap with the existing CNTL-2 requirement. Could we just fix the wording in CNTL-2? CNTL-A2 may need to clarify who created the sub-objects? If the dCDN created the sub-objects, then that may be intra-CDN information that falls under the GEN-4 requirement? Otherwise, it feels like a normal delete failure? Is this requirement to get a more detailed error in the CNTL-A3 case? CNTL-A3 seems to have a couple of aspects. I think bulk delete is already covered by the existing CNTL-1 requirement. The second part which lists filters for bulk delete seems to imply that the dCDN needs to know what the content is and who it belongs to? That seems like it may need some type of companion metadata requirement? CNTL-A4 feels out of scope. Reservation seems more like a precondition to interconnecting? Is the reservation just a suggestion to, or a requirement for, the dCDN? Is there an existing reservation protocol that could/should be used here? Maybe a use case would be helpful to describe the CDNI scope? thanx. -- Kevin J. Ma From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Ser= ge Manning Sent: Friday, October 21, 2011 5:47 PM To: cdni@ietf.org Subject: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI 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= =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-reqs Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 Additional Content Distribution Network Intercon= nection (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 From Martin.Stiemerling@neclab.eu Wed Nov 16 17:25: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 4FA0F1F0C51 for ; Wed, 16 Nov 2011 17:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.348 X-Spam-Level: X-Spam-Status: No, score=-102.348 tagged_above=-999 required=5 tests=[AWL=0.250, 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 2RENmy8yMr+B for ; Wed, 16 Nov 2011 17:25:48 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 422871F0C4A for ; Wed, 16 Nov 2011 17:25:48 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 43C84280000FD; Thu, 17 Nov 2011 02:25:47 +0100 (CET) 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 lYonCtMXSlxh; Thu, 17 Nov 2011 02:25:47 +0100 (CET) Received: from METHONE.office.hd (Methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 22DFD280000FA; Thu, 17 Nov 2011 02:25:37 +0100 (CET) Received: from Polydeuces.office.hd ([169.254.3.40]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 17 Nov 2011 02:25:37 +0100 From: Martin Stiemerling To: Francois Le Faucheur Thread-Topic: [CDNi] BGP and prefix hijacking (CDN footprint capability ) Thread-Index: AcykC4+M9yzdU4gXSEeFRyfO2olZYQABVzgAAC2wppA= Date: Thu, 17 Nov 2011 01:25:36 +0000 Message-ID: References: <49DD48EB-FF78-416C-829D-AD4E22F03142@cisco.com> In-Reply-To: <49DD48EB-FF78-416C-829D-AD4E22F03142@cisco.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.206] Content-Type: multipart/alternative; boundary="_000_E84E7B8FF3F2314DA16E48EC89AB49F024E870B7Polydeucesoffic_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] BGP and prefix hijacking (CDN footprint capability ) 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, 17 Nov 2011 01:25:50 -0000 --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E870B7Polydeucesoffic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, Yes, we are on the same side. I see Jon's proposal a good way forward, i.e., to initially work on the sem= antics required for this. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 From: Francois Le Faucheur [mailto:flefauch@cisco.com] Sent: Wednesday, November 16, 2011 5:36 AM To: Martin Stiemerling Cc: Francois Le Faucheur; cdni@ietf.org Subject: Re: [CDNi] BGP and prefix hijacking (CDN footprint capability ) Hi Martin, I think: * what can be concluded from this information is that the CDNI WG= really needs to consider the security aspects associated with "Footprint &= Capabilities Advertisement". * what certainly can not be concluded from this information is th= at one approach on the table (e.g. BGP) is less suitable than another (e.g= . ALTO, Web-services based) for "Footprint & Capabilities Advertisement". Are we in line? Thanks Francois On 16 Nov 2011, at 11:00, Martin Stiemerling wrote: Hi all, Just to follow-up the current discussion about using BGP for CDN footprint = capability handling we had in the CDNi session some minutes ago. BGP is vulnerable to letting ISPs announcing IP prefixes which they are act= ually not own by them: http://en.wikipedia.org/wiki/IP_hijacking This will cause that the traffic for particular prefixes to not reach the i= ntended destination, actually creating a black hole for this traffic. This links documents also a very prominent case of prefix hijacking. This would be also applicable if using BPG (and variants of it) for the CDN= footprint capability handling. Martin martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E870B7Polydeucesoffic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Hi Francois,

       <= /p>

      Yes, we are on the same s= ide.

       <= /p>

      I see Jon’s proposa= l a good way forward, i.e., to initially work on the semantics required for= this.

       <= /p>

        Martin<= /span>

       <= /p>

      martin.stiemerling@neclab.eu

       <= /p>

      NEC Laboratories Europe -= Network Research Division NEC Europe Limited | Registered Office: NEC Hous= e, 1 Victoria Road, London W3 6BL | Registered in England 2832014

       <= /p>

      From: Francois= Le Faucheur [mailto:flefauch@cisco.com]
      Sent: Wednesday, November 16, 2011 5:36 AM
      To: Martin Stiemerling
      Cc: Francois Le Faucheur; cdni@ietf.org
      Subject: Re: [CDNi] BGP and prefix hijacking (CDN footprint capabili= ty )

       

      Hi Martin,

       

      I think:

         &nb= sp;      * what can be concluded from = this information is that the CDNI WG really needs to consider the security = aspects associated with "Footprint & Capabilities Advertisement&qu= ot;.

         &nb= sp;      * what certainly can not be conclu= ded from this information is that one approach on the table (e.g. BGP) is l= ess suitable than another  (e.g. ALTO, Web-services based) for "F= ootprint & Capabilities Advertisement".

       

      Are we in line?

       

      Thanks

       

      Francois

       

      On 16 Nov 2011, at 11:00, Martin Stiemerling wrote:<= o:p>



      Hi all,

      Just to follow-up the current discussion about using BGP for CDN footprint = capability handling we had in the CDNi session some minutes ago.

      BGP is vulnerable to letting ISPs announcing IP prefixes which they are act= ually not own by them:
      http://en.wikipedia.o= rg/wiki/IP_hijacking

      This will cause that the traffic for particular prefixes to not reach the i= ntended destination, actually creating a black hole for this traffic.

      This links documents also a very prominent case of prefix hijacking.

      This would be also applicable if using BPG (and variants of it) for the CDN= footprint capability handling.

       Martin

      martin.stiemerling@neclab.e= u

      NEC Laboratories Europe - Network Research Division NEC Europe Limited | Re= gistered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in = England 2832014


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

       

       

      --_000_E84E7B8FF3F2314DA16E48EC89AB49F024E870B7Polydeucesoffic_-- From eburger-l@standardstrack.com Thu Nov 17 02:14: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 A942D21F9B76 for ; Thu, 17 Nov 2011 02:14:43 -0800 (PST) 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 1MPkCcz8qcmr for ; Thu, 17 Nov 2011 02:14:40 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.254.120]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC8821F9B82 for ; Thu, 17 Nov 2011 02:14:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=N+STA7Y2rpSVQNvaRipJA9yus84vkME5VYyB/w0qoXfBtccuhzbSkfrdA55+r6ukbeH0Kkmh8XjIv0xdAMydRBlAgDDtK6jt2N4E1b2wUxANW8En/6E54nSJARmJPSeY; Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:60083 helo=[192.168.15.184]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RQyzP-00078L-QW for cdni@ietf.org; Thu, 17 Nov 2011 02:14:40 -0800 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Eric Burger In-Reply-To: Date: Thu, 17 Nov 2011 05:14:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5450AA2D-04B5-4040-A755-10D532E50CF4@standardstrack.com> References: <49DD48EB-FF78-416C-829D-AD4E22F03142@cisco.com> To: cdni@ietf.org X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [CDNi] BGP and prefix hijacking (CDN footprint capability ) 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, 17 Nov 2011 10:14:43 -0000 +1. It is neither a BGP nor ALTO thing, it is a generic thing. On Nov 16, 2011, at 8:25 PM, Martin Stiemerling wrote: > Hi Francois, > =20 > Yes, we are on the same side. > =20 > I see Jon=92s proposal a good way forward, i.e., to initially work on = the semantics required for this. > =20 > Martin > =20 > martin.stiemerling@neclab.eu > =20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014 > =20 > From: Francois Le Faucheur [mailto:flefauch@cisco.com]=20 > Sent: Wednesday, November 16, 2011 5:36 AM > To: Martin Stiemerling > Cc: Francois Le Faucheur; cdni@ietf.org > Subject: Re: [CDNi] BGP and prefix hijacking (CDN footprint capability = ) > =20 > Hi Martin, > =20 > I think: > * what can be concluded from this information is that the = CDNI WG really needs to consider the security aspects associated with = "Footprint & Capabilities Advertisement". > * what certainly can not be concluded from this information = is that one approach on the table (e.g. BGP) is less suitable than = another (e.g. ALTO, Web-services based) for "Footprint & Capabilities = Advertisement". > =20 > Are we in line? > =20 > Thanks > =20 > Francois > =20 > On 16 Nov 2011, at 11:00, Martin Stiemerling wrote: >=20 >=20 > Hi all, >=20 > Just to follow-up the current discussion about using BGP for CDN = footprint capability handling we had in the CDNi session some minutes = ago.=20 >=20 > BGP is vulnerable to letting ISPs announcing IP prefixes which they = are actually not own by them: > http://en.wikipedia.org/wiki/IP_hijacking >=20 > This will cause that the traffic for particular prefixes to not reach = the intended destination, actually creating a black hole for this = traffic. >=20 > This links documents also a very prominent case of prefix hijacking.=20= >=20 > This would be also applicable if using BPG (and variants of it) for = the CDN footprint capability handling. >=20 > Martin >=20 > martin.stiemerling@neclab.eu >=20 > NEC Laboratories Europe - Network Research Division NEC Europe Limited = | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | = Registered in England 2832014=20 >=20 >=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 From flefauch@cisco.com Thu Nov 17 17:35: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 E9B2111E809F for ; Thu, 17 Nov 2011 17:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.43 X-Spam-Level: X-Spam-Status: No, score=-6.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 LUh5PuEuPlCX for ; Thu, 17 Nov 2011 17:35:20 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 41E8411E8094 for ; Thu, 17 Nov 2011 17:35:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=230; q=dns/txt; s=iport; t=1321580120; x=1322789720; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=QadGbNK3xW9l3/XRe5gJ3jG5ZXe2guh8zr/ujez0jpA=; b=ZoQWNf+hYxQJvThexqjNjfLub14H+1kpvjnngBV32YhrNbFhxC5+12uf WaKPqE3XL1SURDawju9jKjVHN4idf1CJSIOpm/obBlUdslzK27wQQco0T TqudWMgxSbgC+jVYaojmJ1JyFmqGqkgv5XAoOECVZlinVFfDQE5XetES7 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAO+1xU6tJXG+/2dsb2JhbABCqkKBBYILASeCMp5RgSYBni2HAoIyYwSIE4wikgk X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; d="scan'208";a="37119209" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 18 Nov 2011 01:35:20 +0000 Received: from rtp-vpn1-488.cisco.com (rtp-vpn1-488.cisco.com [10.82.225.232]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAI1ZDag002337 for ; Fri, 18 Nov 2011 01:35:19 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2011 08:09:06 +0800 Message-Id: <0A321EC4-33EE-4316-B24C-7F36378830A7@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] Adopting draft-davie-cdni-framework-01 as a working group document 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, 18 Nov 2011 01:35:21 -0000 Hello, There was clear support at the IETF-82 CDNI meeting to adopt = draft-davie-cdni-framework-01 as a working group document. We will do so = in a week unless we hear opposition on the list. Cheers Francois & Rich= From flefauch@cisco.com Thu Nov 17 17:35: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 87B5611E809F for ; Thu, 17 Nov 2011 17:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.454 X-Spam-Level: X-Spam-Status: No, score=-6.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 mLP2L85xXTvH for ; Thu, 17 Nov 2011 17:35:21 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1148311E8094 for ; Thu, 17 Nov 2011 17:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=1093; q=dns/txt; s=iport; t=1321580121; x=1322789721; h=from:subject:date:message-id:to:mime-version; bh=qI7EwiiSZb7LMIw3JmEc5N6mT8l7IMpew+r7Ewi1Zks=; b=j5bvxOCKiagChjcUgC1PwL1AHeepubOGPiSQ6IerhOFt0uhxZjcZVEuO yWU16G0bQUMc7QBekS6JtObgxB1GuZC158xty1Mp7gZ6vd+J4+fd0nrxW KH35FHGWD0QuRR/4bkJ8QRPvNXi0+2Ca9Ci27N7EZ1iFjHWcnBPtLK+WF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAD62xU6tJXG+/2dsb2JhbABCqkKBBYFpBR0BgQQBgVSFJoIylnuBJgGeLYcCgjJjBIgTjCKSCQ X-IronPort-AV: E=Sophos;i="4.69,530,1315180800"; d="scan'208,217";a="37112121" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 18 Nov 2011 01:35:18 +0000 Received: from rtp-vpn1-488.cisco.com (rtp-vpn1-488.cisco.com [10.82.225.232]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAI1ZDaf002337 for ; Fri, 18 Nov 2011 01:35:18 GMT From: Francois Le Faucheur Content-Type: multipart/alternative; boundary=Apple-Mail-39--329779620 Date: Fri, 18 Nov 2011 08:06:43 +0800 Message-Id: To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] Progressing draft-ietf-cdni-problem-statement-01 to working group 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, 18 Nov 2011 01:35:21 -0000 --Apple-Mail-39--329779620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, There was clear support at the IETF-82 CDNI meeting to progress = draft-ietf-cdni-problem-statement-01 to working group Last Call. We will = do so in a week or so unless we hear opposition on the list. Cheers Francois & Rich --Apple-Mail-39--329779620 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hello,

      There was clear support at the IETF-82 CDNI meeting to progress draft-ietf-cdni-problem-statement-01 to working group Last Call. We will do so in a week or so unless we hear opposition on the list.

      Cheers

      Francois & Rich


      --Apple-Mail-39--329779620-- From zhouzhipeng@huawei.com Thu Nov 17 19:07:35 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 B9DDD1F0C80 for ; Thu, 17 Nov 2011 19:07:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.944 X-Spam-Level: X-Spam-Status: No, score=-5.944 tagged_above=-999 required=5 tests=[AWL=0.654, 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 HRLDhHgMBMnj for ; Thu, 17 Nov 2011 19:07:33 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7991F0C34 for ; Thu, 17 Nov 2011 19:07:33 -0800 (PST) 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 <0LUU00J4V60CCZ@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 18 Nov 2011 11:07:24 +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 <0LUU00F8N60ACG@szxga03-in.huawei.com> for cdni@ietf.org; Fri, 18 Nov 2011 11:07:24 +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 AFB55482; Fri, 18 Nov 2011 11:07:03 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 18 Nov 2011 11:06:56 +0800 Received: from SZXEML519-MBS.china.huawei.com ([169.254.7.4]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Fri, 18 Nov 2011 11:06:55 +0800 Date: Fri, 18 Nov 2011 03:06:53 +0000 From: ZhouZhipeng In-reply-to: <54E731E9-CCE5-42BF-9F1C-63F5893B606B@itec.uni-klu.ac.at> X-Originating-IP: [10.138.73.38] To: Christian Timmerer , "Peterson, Larry" , Francois Le Faucheur , Bruce Davie Message-id: <260A32EFD5C9EB47AD504929D005DF6217F8258B@SZXEML519-MBS.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_NKwYro48LTGUPDnqoSJGAg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: [CDNi] Discussing "Adaptive Streaming" more in cdni-framework Thread-index: AQHMpJp2+6lmUQgUJUWPimBbMauwJJWx85dA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <54E731E9-CCE5-42BF-9F1C-63F5893B606B@itec.uni-klu.ac.at> Cc: "cdni@ietf.org" Subject: Re: [CDNi] Discussing "Adaptive Streaming" more in cdni-framework 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, 18 Nov 2011 03:07:35 -0000 --Boundary_(ID_NKwYro48LTGUPDnqoSJGAg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT All, As for "* Acquisition: should/can acquisition be performed on a per-segment basis or differently?", the essence is whether there is much benefit by delivering part(segment) of the content to uCDN rather than delivering whole content to uCDN . Generally, it should be the whole content been delivered to the uCDN while the uCDN may provide adaptive streaming service to UE. Thanks. Zhipeng From: Christian Timmerer [mailto:christian.timmerer@itec.uni-klu.ac.at] Sent: Wednesday, November 16, 2011 10:18 PM To: Peterson, Larry; Francois Le Faucheur; Bruce Davie Cc: cdni@ietf.org Subject: Re: [CDNi] Discussing "Adaptive Streaming" more in cdni-framework Bruce, Larry, I just wanted to pass on a suggestion made during the WG session. >From talking to people this week, it became clear to me that: * just about everyone expects a CDNI mesh to support content delivery via HTTP Adaptive Streaming * people have different expectations about how CDNI supports this. So my suggestion is that the framework very explicitly addresses this question (perhaps even as a standalone section, so people can easily find the discussion on that specific question). In line with the general current approach of the framework, the expectation would not be that the framework mandates a given approach, but explores the design spaces, and helps analysis and converging on if/what CDNI interfaces need to support something specific for adaptive. A few aspects that come to mind are: * Request Routing: should/can request routing be performed more efficiently than once per segment? * Acquisition: should/can acquisition be performed on a per-segment basis or differently? Depending on whether segments or subsegments are used. In the former case, the content is physically divided into segments, each individually addressable by HTTP URL whereas in the latter case, the content is logically divided into segments, each individually addressable by HTTP byte range requests. * Logging: the framework already brings up the point about logging for adaptive in section 4.3 For example, MPEG-DASH defines already some metrics that are related to what is defined in section 4.3 but, of course, go beyond and are specific to DASH. However, some are probably applicable in a more general HTTP adaptive streaming context. * Metadata: is any specific metadata required. The manifest file, for example. Best regards, -Christian Can you consider expanding the discussion on adaptive streaming in the next rev? Thanks Francois _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --Boundary_(ID_NKwYro48LTGUPDnqoSJGAg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

      All,

      As for “* Acquisition: should/can acquisition be performed on a per-segment basis or differently?”, the essence is whether there is much benefit by delivering part(segment) of the content to uCDN rather than delivering whole content to uCDN . Generally, it should be the whole content been delivered to the uCDN while the  uCDN may provide adaptive streaming service to UE.

      Thanks.

      Zhipeng

       

       

       

      From: Christian Timmerer [mailto:christian.timmerer@itec.uni-klu.ac.at]
      Sent: Wednesday, November 16, 2011 10:18 PM
      To: Peterson, Larry; Francois Le Faucheur; Bruce Davie
      Cc: cdni@ietf.org
      Subject: Re: [CDNi] Discussing "Adaptive Streaming" more in cdni-framework

       

       

      Bruce, Larry,

      I just wanted to pass on a suggestion made during the WG session.

      >From talking to people this week, it became clear to me that:
              * just about everyone expects a CDNI mesh to support content delivery via HTTP Adaptive Streaming
              * people have different expectations about how CDNI supports this.

      So my suggestion is that the framework very explicitly addresses this question (perhaps even as a standalone section, so people can easily find the discussion on that specific question). In line with the general current approach of the framework, the expectation would not be that the framework mandates a given approach, but explores the design spaces, and helps analysis and converging on if/what CDNI interfaces need to support something specific for adaptive.
      A few aspects that come to mind are:
              * Request Routing: should/can request routing be performed more efficiently than once per segment?
              * Acquisition: should/can acquisition be performed on a per-segment basis or differently?

      Depending on whether segments or subsegments are used. In the former case, the content is physically divided into segments, each individually addressable by HTTP URL whereas in the latter case, the content is logically divided into segments, each individually addressable by HTTP byte range requests.



              * Logging: the framework already brings up the point about logging for adaptive in section 4.3  

      For example, MPEG-DASH defines already some metrics that are related to what is defined in section 4.3 but, of course, go beyond and are specific to DASH. However, some are probably applicable in a more general HTTP adaptive streaming context.

       

              * Metadata: is any specific metadata required.

      The manifest file, for example.

       

      Best regards,

       -Christian

       


      Can you consider expanding the discussion on adaptive streaming in the next rev?

      Thanks

      Francois



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

       

      --Boundary_(ID_NKwYro48LTGUPDnqoSJGAg)-- From sergem913@gmail.com Thu Nov 17 22:25: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 2FB6711E80B0 for ; Thu, 17 Nov 2011 22:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.447 X-Spam-Level: X-Spam-Status: No, score=-3.447 tagged_above=-999 required=5 tests=[AWL=-0.076, 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 Y5BI9Y8rJ1R9 for ; Thu, 17 Nov 2011 22:25:38 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 73B2B11E808B for ; Thu, 17 Nov 2011 22:25:38 -0800 (PST) Received: by faap16 with SMTP id p16so5898558faa.31 for ; Thu, 17 Nov 2011 22:25:37 -0800 (PST) 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=roqzkI5iBUc9N7Mqc0R5zQlDIGWv19DqvB0sv1wEhUs=; b=WyqnaVBCCrkYZJpEk6Ry3IKbbz2AXkTe7nqsmknmZqZtkPmJsex2kcsa03o0XO9eD3 bNAZ6PqIlp8TMAMELVpZksERyYrw7WllG9ehPPkWkj6XIoXiuYkDYinSuo05U78Xc4Ga np9+Z8Vyqm0kOf7xJCrdYnE70WpkWmEad9Roc= MIME-Version: 1.0 Received: by 10.152.132.39 with SMTP id or7mr1070653lab.14.1321597536977; Thu, 17 Nov 2011 22:25:36 -0800 (PST) Received: by 10.152.132.229 with HTTP; Thu, 17 Nov 2011 22:25:36 -0800 (PST) In-Reply-To: <291CC3F9E50E7641901A54E85D0977C651B6CD51F6@MAILR002.mail.lan> References: <291CC3F9E50E7641901A54E85D0977C651B6CD51F6@MAILR002.mail.lan> Date: Fri, 18 Nov 2011 00:25:36 -0600 Message-ID: From: Serge Manning To: Kevin J Ma Content-Type: multipart/alternative; boundary=f46d0433a0f2ba441104b1fc6736 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: Fri, 18 Nov 2011 06:25:40 -0000 --f46d0433a0f2ba441104b1fc6736 Content-Type: text/plain; charset=ISO-8859-1 Thanks for looking at the draft and providing feedback Kevin. See inline. On Wed, Nov 16, 2011 at 12:24 PM, Kevin J Ma wrote: > Serge (and Kent), > > Some questions/comments on the requirements in the draft: > > LOG-A1/A2 seem like a good idea. They seem to mimic the existing > LOG-2/3 requirements, respectively, which seems fine, but do we need > to have separate requirements for these or can we just update LOG-2/3 > to include failures? > > That sounds fine. > One question about LOG-2 and LOG-A1: is the text "deliveries to > User Agents" intended to imply that the data should track and be > aggregatable per unique user? We may want to clarify that? > > My interpretation is that a logging record is generated for each content delivered to an end user by the dCDN on behalf of the uCDN. Not sure what you mean about "aggregate." LOG-A3/A4 sound reasonable. Should we include bandwidth or other > usage metrics as well and can they all be included in one usage > metric requirement (similar to META-14)? > > That would be OK. We can probably just keep the requirements general as bandwidth, storage, etc. and determine the parameters in the solutions documents. The example metrics in LOG-A3 seem like they could be exposing > intra-CDN information (e.g., total GB)? Does this go against the > GEN-4 requirement? > > The intention of LOG-A3 is to report usage of aggregate storage used by the dCDN on behalf of the uCDN and not other internal storage resources private to the dCDN. LOG-A5 could be interpreted as either: a) configure the dCDN to do > storage reporting, or b) ask the dCDN to immediately send out logs? > If the latter, it seems to overlap with the existing LOG-9 requirement? > > I think LOG-A5 is the same as LOG-9 except for storage. So this could be folded into LOG-9. > Are LOG-A3/A4 intended to be periodic, or only on-demand? If the > latter, then is it just an issue of raising LOG-9 from LOW to MED? > Note: LOG-9/A5 should probably be included in the 'trigger' discussion? > > The thinking was to have normal periodic with on-demand as an additional capability if the uCDN wanted to do a check of what storage is outstanding at the moment. LOG-A6 seems like two requirements, that could be parts of a more > generic set of LOG-A3/A5 requirements? > > No, I think LOG-6 is talking about the logging interface itself and its ability to be responsive for some near real-time uses. While LOG-A3/A5 is talking about the types of parameters in the logging messages. LOG-A7 sounds ok, but is the confirmation from the delete request not > sufficient? Is a log of individual deleted objects only meaningful > if the object was there to be deleted, i.e. does it need to compare > against everything that was acquired but not yet evicted? > > IMO, the response to the delete is more a control plane acknowledgement while the logging interface is a complete record of transactions between the CDNs. Thus, we need both. LOG-A8/A9 seem reasonable, though they feel more like a MED than a > HIGH to me. Assuming they are HIGH, could we just update the existing > LOG-7 requirement to include extensibility? Is there an existing > log description language that could/should be used here? > > I believe that making the messaging extensible is easy and needs to be done on the first release so that small proprietary fields can be carried over this otherwise standardized interface resulting in wide use of the standard. We should not make the messaging fixed and then later decide to make it extendable. CNTL-A1 seems to overlap with the existing CNTL-2 requirement. > Could we just fix the wording in CNTL-2? > > Yes, we can fold the confirmation into CNTL-2. > CNTL-A2 may need to clarify who created the sub-objects? If the > dCDN created the sub-objects, then that may be intra-CDN information > that falls under the GEN-4 requirement? Otherwise, it feels like a > normal delete failure? Is this requirement to get a more detailed > error in the CNTL-A3 case? > > If the delete is successful, everyone is happy. If the delete fails, you get confirmation of that. If the delete *partially* fails which would mean its an object with sub-objects, then this is asking for a more detailed partial delete report. I think the sub-objects have to be known and understandable by the uCDN for this to be of any value. So I don't think this applies if the dCDN creates the sub-objects. Right now, I don't myself understand how the dCDN would do this sub-object creation on its own. Maybe you could explain. > CNTL-A3 seems to have a couple of aspects. I think bulk delete is > already covered by the existing CNTL-1 requirement. The second part > which lists filters for bulk delete seems to imply that the dCDN needs > to know what the content is and who it belongs to? That seems like it > may need some type of companion metadata requirement? > > I don't see the bulk delete in CNTL-1. I think the two aspects here are linked. Hmm...it seems like it may need some metadata requirement. Let me think about it some more. CNTL-A4 feels out of scope. Reservation seems more like a precondition > to interconnecting? Is the reservation just a suggestion to, or a > requirement for, the dCDN? Is there an existing reservation protocol > that could/should be used here? Maybe a use case would be helpful to > describe the CDNI scope? > > I will look up the ATIS use case and report it back here. Thanks again for your analysis and feedback. > thanx. > > -- Kevin J. Ma > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Serge Manning > Sent: Friday, October 21, 2011 5:47 PM > To: cdni@ietf.org > Subject: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI > > 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 > > -- --Serge --f46d0433a0f2ba441104b1fc6736 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for looking at the draft and providing feedback Kevin. See inline.
      On Wed, Nov 16, 2011 at 12:24 PM, Kevin J = Ma <kevin= .ma@azukisystems.com> wrote:
      Serge (and Kent),

      =A0Some questions/comments on the requirements in the draft:

      =A0LOG-A1/A2 seem like a good idea. =A0They seem to mimic the existing
      =A0LOG-2/3 requirements, respectively, which seems fine, but do we need =A0to have separate requirements for these or can we just update LOG-2/3 =A0to include failures?

      That sounds fine.
      =A0
      =A0One question about LOG-2 and LOG-A1: is the text "deliveries to =A0User Agents" intended to imply that the data should track and be =A0aggregatable per unique user? =A0We may want to clarify that?

      My interpretation is that a logging record is generat= ed for each content delivered to an end user by the dCDN on behalf of the u= CDN. Not sure what you mean about "aggregate."=A0

      =A0LOG-A3/A4 sound reasonable. =A0Should we include bandwidth or other
      =A0usage metrics as well and can they all be included in one usage
      =A0metric requirement (similar to META-14)?

      That would be OK. We can probably just keep the requi= rements general as bandwidth, storage, etc. and determine the parameters in= the solutions documents.

      =A0The example metrics in LOG-A3 seem like they could be exposing
      =A0intra-CDN information (e.g., total GB)? =A0Does this go against the
      =A0GEN-4 requirement?

      The intention of LOG-A3 is to report usage of aggrega= te storage used by the dCDN on behalf of the uCDN and not other internal st= orage resources private to the dCDN.

      =A0LOG-A5 could be interpreted as either: a) configure the dCDN to do
      =A0storage reporting, or b) ask the dCDN to immediately send out logs?
      =A0If the latter, it seems to overlap with the existing LOG-9 requirement?=

      I think LOG-A5 is the same as LOG-9 except for storag= e. So this could be folded into LOG-9.
      =A0
      =A0Are LOG-A3/A4 intended to be periodic, or only on-demand? =A0If the
      =A0latter, then is it just an issue of raising LOG-9 from LOW to MED?
      =A0Note: LOG-9/A5 should probably be included in the 'trigger' dis= cussion?

      The thinking was to have normal periodic with on-dema= nd as an additional capability if the uCDN wanted to do a check of what sto= rage is outstanding at the moment.

      =A0LOG-A6 seems like two requirements, that could be parts of a more
      =A0generic set of LOG-A3/A5 requirements?

      No, I think LOG-6 is talking about the logging interf= ace itself and its ability to be responsive for some near real-time uses. W= hile LOG-A3/A5 is talking about the types of parameters in the logging mess= ages.

      =A0LOG-A7 sounds ok, but is the confirmation from the delete request not =A0sufficient? =A0Is a log of individual deleted objects only meaningful =A0if the object was there to be deleted, i.e. does it need to compare
      =A0against everything that was acquired but not yet evicted?

      IMO, the response to the delete is more a control pla= ne acknowledgement while the logging interface is a complete record of tran= sactions between the CDNs. Thus, we need both.

      =A0LOG-A8/A9 seem reasonable, though they feel more like a MED than a
      =A0HIGH to me. =A0Assuming they are HIGH, could we just update the existin= g
      =A0LOG-7 requirement to include extensibility? =A0Is there an existing
      =A0log description language that could/should be used here?

      I believe that making the messaging extensible is eas= y and needs to be done on the first release so that small proprietary field= s can be carried over this otherwise standardized interface resulting in wi= de use of the standard. We should not make the messaging fixed and then lat= er decide to make it extendable.

      =A0CNTL-A1 seems to overlap with the existing CNTL-2 requirement.
      =A0Could we just fix the wording in CNTL-2?

      Yes, we can fold the confirmation into CNTL-2.
      <= div>=A0
      =A0CNTL-A2 may need to clarify who created the sub-objects? =A0If the
      =A0dCDN created the sub-objects, then that may be intra-CDN information =A0that falls under the GEN-4 requirement? =A0Otherwise, it feels like a =A0normal delete failure? =A0Is this requirement to get a more detailed =A0error in the CNTL-A3 case?

      If the delete is successful, everyone is happy. If th= e delete fails, you get confirmation of that. If the delete *partially* fai= ls which would mean its an object with sub-objects, then this is asking for= a more detailed partial delete report. I think the sub-objects have to be = known and understandable by the uCDN for this to be of any value. So I don&= #39;t think this applies if the dCDN creates the sub-objects. Right now, I = don't myself understand how the dCDN would do this sub-object creation = on its own. Maybe you could explain.
      =A0
      =A0CNTL-A3 seems to have a couple of aspects. =A0I think bulk delete is =A0already covered by the existing CNTL-1 requirement. =A0The second part<= br> =A0which lists filters for bulk delete seems to imply that the dCDN needs<= br> =A0to know what the content is and who it belongs to? =A0That seems like i= t
      =A0may need some type of companion metadata requirement?

      =A0I don't see the bulk delete in CNTL-1. I think= the two aspects here are linked. Hmm...it seems like it may need some meta= data requirement. Let me think about it some more.

      =A0CNTL-A4 feels out of scope. =A0Reservation seems more like a preconditi= on
      =A0to interconnecting? =A0Is the reservation just a suggestion to, or a =A0requirement for, the dCDN? =A0Is there an existing reservation protocol=
      =A0that could/should be used here? =A0Maybe a use case would be helpful to=
      =A0describe the CDNI scope?

      I will look up the ATIS use case and report it back h= ere.

      Thanks again for your analysis and feedback.<= /div>
      =A0
      thanx.

      -- =A0Kevin J. Ma


      From: cdni-bounces@ietf.org [m= ailto:cdni-bounces@ietf.org] O= n Behalf Of Serge Manning
      Sent: Friday, October 21, 2011 5:47 PM
      To: cdni@ietf.org
      Subject: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI

      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 requiremen= ts=A0and determine the additional requirements that are appropriate for CDN= I. 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-reqs
      Revision: =A0 =A0 =A0 =A000
      Title: =A0 =A0 =A0 =A0 =A0 Additional Content Distribution Network Intercon= nection (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




      --
      = --Serge

      --f46d0433a0f2ba441104b1fc6736-- From flefauch@cisco.com Sat Nov 19 09:56: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 6F4A621F86DD for ; Sat, 19 Nov 2011 09:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.863 X-Spam-Level: X-Spam-Status: No, score=-5.863 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 wrRxqhQ3ii6G for ; Sat, 19 Nov 2011 09:56:24 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id ABB3F21F86A6 for ; Sat, 19 Nov 2011 09:56:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=2553; q=dns/txt; s=iport; t=1321725384; x=1322934984; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=n6eAlvUfQHL8D+P0yKgmsldngoxOdO0BmWUxkKGErTk=; b=MpJxJZ1Fpg/WzndXz5pkn2Dm6ol1Dv84fFTzcowa2L40+0NrTICNfwSd sotsmXmqW9BK5ZCJtWzuafNa4cdTARTOVf/ZyVJwwwtiiJ+4shDr/5LZ1 L2J1YuI1Ma1gde/rUZuSAXnqWeqJLkJ0ZUKaFWsA2AIpXyzmwC4ZlfyI1 Q=; X-IronPort-AV: E=Sophos;i="4.69,539,1315180800"; d="scan'208";a="37531281" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 19 Nov 2011 17:56:24 +0000 Received: from rtp-vpn4-1896.cisco.com (rtp-vpn4-1896.cisco.com [10.82.215.104]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pAJHtx6j028005; Sat, 19 Nov 2011 17:56:22 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Nov 2011 15:42:26 +0800 Message-Id: <305077E3-91B4-41FB-8857-116B9EB5906B@cisco.com> To: "Bruce (bdavie) Davie" , Larry Peterson Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: [CDNi] Framework & Synchronous CDNI Metadata Acquisition approaches 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, 19 Nov 2011 17:56:25 -0000 Bruce, Larry, and all, (as an individual) Kent, Ben, David, Grant and I had a chat in Taipei about how to = transport the subset of metadata needed at request routing time and = concluded that it made sense to use the Metadata Interface to convey the = metadata needed at request-routing time, as opposed to attempt to = piggy-back those in the Request-Routing interface/redirection message.=20= I just looked back at the framework and found that this is in line with = the text of section 3.9 that provides a good discussion of the scenario = of Synchronous CDNI Metadata Acquisition. Specifically the text in steps = 3-5 describes: * that metadata can be acquired via a Metadata Interface request * does not mention the conceptual alternative to piggy-back = inside the "Request-Routing Interface/Redirection" request the subset of = metadata needed at request routing time. But while this is clear in our heads, it may be worth recording in the = framework the rationale for that design decision so we don't have to = reopen it later. The key points that came up in our discussion are: * there can be a very high number of RRI redirection message for = the same content, so it is much more efficient to pull the metadata once = for all * the request routing decision can potentially be influenced by = quite a few different metadata object, so you might end retrying to = convey a large subset of the whole metadata * the whole set of metadata is likely needed for subsequent = delivery, so may as well pull it upfront. * if metadata objects are added in the future and some of those = may influence request routing, they would be immediately available to = the dCDN request router if you use the metadata interface, while = (depending on how they are encoded) you may have to rev up the = Request-Routing Interface/Redirection spec. The only counter-argument was an extra inter-CDN RTT at request routing = time, but that does outweigh the benefits. Would you be willing to document the rationale (possibly combining the = above with yours)? The text in step 1 does mention: * that seed metadata can be acquired via a Metadata Interface = request * mentions a potential alternative ways to convey the metadata = seed information via piggy-backing on the "Request-Routing = Interface/Redirection" trigger. Since "seed" metadata may be extremely small (eg identification of = uCDN), it may be worth keeping in step 1 the statement about the = alternative for now. Cheers Francois= From ben@niven-jenkins.co.uk Mon Nov 21 06:13: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 77E7311E80B2 for ; Mon, 21 Nov 2011 06:13:29 -0800 (PST) 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 S1dYdrz5frWI for ; Mon, 21 Nov 2011 06:13:25 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id A6B2411E80B3 for ; Mon, 21 Nov 2011 06:13:24 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=xxx.dhcp.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RSUcc-0004xp-VZ; Mon, 21 Nov 2011 14:13:23 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A38A@EUSAACMS0701.eamcs.ericsson.se> Date: Mon, 21 Nov 2011 14:13:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A359@EUSAACMS0701.eamcs.ericsson.se> <1B6D0317D3AD964FBF3956DEFA3524D51711E6A38A@EUSAACMS0701.eamcs.ericsson.se> To: Alan Kavanagh X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 21 Nov 2011 14:13:29 -0000 On 16 Nov 2011, at 02:15, Alan Kavanagh wrote: > Hi Yiu > =20 > I never said it has to be explicit, then again capturing in the = Requirements document suffices :-) > =20 > Sure here is some text it just needs to be captured. " dCDN Should = inform the uCDN it can not handle any requests at this time", Is the requirement that the "informing" is done via the "capabilities" = request routing interface or the "redirection" request routing = interface? For example, is it sufficient for the dCDN to respond to a CDNI = "redirection" interface request with "I cannot serve to " with a TTL that indicates the period for = which such information can be reused by the uCDN without re-querying the = dCDN? Ben > I dont think it needs to be noted as to why at a given instance of = time the request can not be handled, if others feel different i would = like to hear why. My only further comment is the oposite, i.e. to inform = the uCDN when it can handle requests again.=20 > =20 > BR > Alan >=20 > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 > Sent: November-15-11 9:02 PM > To: Alan Kavanagh; Kent Leung (kleung); gilles.bertrand@orange.com > Cc: cdni@ietf.org > Subject: Re: [CDNi] draft-ietf-cdni-cases-00 >=20 > Hi Alan, >=20 > I struggle how explicit we need to put in the requirement. Do you = think a sub-bullet like: "information to signal overload to uCDN" is = sufficient? Can you suggest some text which you think REQ-2 doesn't = capture? We would like people to discuss the new text in the ML. >=20 > Thanks, > Yiu >=20 > From: Alan Kavanagh > Date: Tue, 15 Nov 2011 19:56:48 -0500 > To: "Kent Leung (kleung)" , = "gilles.bertrand@orange.com" > Cc: "cdni@ietf.org" > Subject: Re: [CDNi] draft-ietf-cdni-cases-00 >=20 > Hi Kent > =20 > What might be useful is to jut capture the requirement somewhere as i = believe their will be numerous ways to address the overload case and i = can see changes required not just on CDN-I metadata i/f as GIlles is = pointing out too, so for now lets capture the requirement. > =20 > Alan >=20 > From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 > Sent: November-15-11 3:52 AM > To: gilles.bertrand@orange.com > Cc: Alan Kavanagh; cdni@ietf.org > Subject: RE: draft-ietf-cdni-cases-00 >=20 > Hi Gilles. I=92m not sure if the requirements should be written = explicitly to map to use cases unless the functions are for that purpose = only. In this case, there could be numerous reasons why dCDN provides = its resource information to the uCDN. > The discussion below indicates a need for RRI requirement, which can = be traced to REQ-2. Is this not sufficient? > Kent > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20= > Sent: Tuesday, November 15, 2011 1:02 PM > To: Kent Leung (kleung) > Cc: alan.kavanagh@ericsson.com; cdni@ietf.org > Subject: RE: draft-ietf-cdni-cases-00 > Hi Kent, > As raised by Alan in his e-mail below, in an offload use case the uCDN = would require information on the dCDNs to be aware of the amount of = traffic it can offload to every dCDN. I think this requirement is = already covered through the request routing interface as REQ-2 includes = the advertising of information about dCDN resources. Maybe we might add = a few words to REQ-2 to mention explicitly that resource information = could be needed for offload situations. > I am not 100% clear today if the offload use case introduces specific = requirements on other interfaces (e.g., control and metadata) in = addition to the request routing interface. I see some specificity in = this use case, for instance, the duration during which the uCDN will use = the dCDN resources can be short in an offload situation (e.g., duration = of a flash crowd) as compared to a footprint extension use case. > Best regards, > Gilles > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20= > Sent: November-07-11 5:19 AM > To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; = trevor.burbridge@bt.com; philip.eardley@bt.com; = kevin.ma@azukisystems.com > Cc: cdni@ietf.org > Subject: RE: draft-ietf-cdni-cases-00 >=20 > (=85) > Section 3.1 Offloading. It should be noted that this use case would = require knowledge about the other CDN to know if the other CDN has the = resources to offload the requests in the first place and also if the = content is available in the CDN being offloaded too. > I agree: the CDN on which requests are offloaded must be able to = handle the offloaded requests. This (may) introduce requirements on the = metadata (and control) interfaces.=20 > A.K.--> Yes, my point exactly, it would be useful to point that out in = your draft to make it complete and also have it noted in the "CDNI = Requirements Draft" . > (=85) > (=85) > _______________________________________________ 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 kleung@cisco.com Mon Nov 21 09:47: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 7CB5A11E80DE for ; Mon, 21 Nov 2011 09:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 7wp17w08vwFo for ; Mon, 21 Nov 2011 09:47:30 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 07C1E11E80DC for ; Mon, 21 Nov 2011 09:47:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=6752; q=dns/txt; s=iport; t=1321897650; x=1323107250; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=5FYaUB17pqnBqV6bxCU9UYa4ST5mbYzypMI7B128IqA=; b=dqxFETiKB45z4lKHLOF6Bi+qOMfhFtcOopUjqzjtve5tZaIlz13JK6KO 2teXtYwpPK5iA+YOK7wmYtmMD5nBStatK1JoCLgVU8AHc2GKIx/N4MKdG nbaX7Knsu8AxhmavUmp297n/4AByve9k+faEQxwiopfLw7yl0c7IpF6Rj I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogAAFyOyk6rRDoG/2dsb2JhbABDmiaQF4EFgXIBAQEDAQEBAQ8BFAkKNAsFBwQCAQgRAwEBAQsGFwEGASYfCQgBAQQBEggah2EIlhoBnj4EiTRjBIgakWiMYA X-IronPort-AV: E=Sophos;i="4.69,548,1315180800"; d="scan'208";a="15495550" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 21 Nov 2011 17:47:29 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pALHlTpK020693; Mon, 21 Nov 2011 17:47:29 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 09:47:29 -0800 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, 21 Nov 2011 09:47:25 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC52104FD387@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] draft-ietf-cdni-cases-00 Thread-Index: AcyoV7vomGzof0ZzTjGneZFDsNeMQgAGkmJw References: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A359@EUSAACMS0701.eamcs.ericsson.se> <1B6D0317D3AD964FBF3956DEFA3524D51711E6A38A@EUSAACMS0701.eamcs.ericsson.se> From: "Kent Leung (kleung)" To: "Ben Niven-Jenkins" , "Alan Kavanagh" X-OriginalArrivalTime: 21 Nov 2011 17:47:29.0477 (UTC) FILETIME=[A3825750:01CCA875] Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 21 Nov 2011 17:47:34 -0000 Good discussions so far. Just like to clarify some points. 1. It looks to me that the topic started off with a requirement for dCDN to inform uCDN on the dCDN's available resources to handle offload use case. This seems to be covered in REQ-2 which generically advertises such information as part of "capabilities" RRI. 2. Then the discussion turned to a need for requirement for dCDN to notify the uCDN when overload condition occurred (i.e. request cannot be handled by dCDN) or no longer the case (i.e. request can be handled again). This seems to be covered in REQ-14 which provides a generic "redirection" RRI function.=20 3. Then it seems a requirement for dCDN to convey more specific context on why it cannot serve the request (e.g. delivery protocol to location for period of time). This seems to be more granular level of control and additional timeliness to REQ-1. Though I suspect that the new requirement is considered [MED] instead of current priority of [HIGH].=20 Have I misinterpreted anything? I'm not sure if the requirements for #1 and #2 need any updates. If so, please provide text that does not functionally overlap with the existing requirements. As for #3, I'm not sure if the intent is to add additional requirements? Kent -----Original Message----- From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 Sent: Monday, November 21, 2011 6:13 AM To: Alan Kavanagh Cc: Lee, Yiu; Kent Leung (kleung); gilles.bertrand@orange.com; cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 On 16 Nov 2011, at 02:15, Alan Kavanagh wrote: > Hi Yiu > =20 > I never said it has to be explicit, then again capturing in the Requirements document suffices :-) > =20 > Sure here is some text it just needs to be captured. " dCDN Should inform the uCDN it can not handle any requests at this time", Is the requirement that the "informing" is done via the "capabilities" request routing interface or the "redirection" request routing interface? For example, is it sufficient for the dCDN to respond to a CDNI "redirection" interface request with "I cannot serve to " with a TTL that indicates the period for which such information can be reused by the uCDN without re-querying the dCDN? Ben > I dont think it needs to be noted as to why at a given instance of time the request can not be handled, if others feel different i would like to hear why. My only further comment is the oposite, i.e. to inform the uCDN when it can handle requests again.=20 > =20 > BR > Alan >=20 > From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 > Sent: November-15-11 9:02 PM > To: Alan Kavanagh; Kent Leung (kleung); gilles.bertrand@orange.com > Cc: cdni@ietf.org > Subject: Re: [CDNi] draft-ietf-cdni-cases-00 >=20 > Hi Alan, >=20 > I struggle how explicit we need to put in the requirement. Do you think a sub-bullet like: "information to signal overload to uCDN" is sufficient? Can you suggest some text which you think REQ-2 doesn't capture? We would like people to discuss the new text in the ML. >=20 > Thanks, > Yiu >=20 > From: Alan Kavanagh > Date: Tue, 15 Nov 2011 19:56:48 -0500 > To: "Kent Leung (kleung)" , "gilles.bertrand@orange.com" > Cc: "cdni@ietf.org" > Subject: Re: [CDNi] draft-ietf-cdni-cases-00 >=20 > Hi Kent > =20 > What might be useful is to jut capture the requirement somewhere as i believe their will be numerous ways to address the overload case and i can see changes required not just on CDN-I metadata i/f as GIlles is pointing out too, so for now lets capture the requirement. > =20 > Alan >=20 > From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 > Sent: November-15-11 3:52 AM > To: gilles.bertrand@orange.com > Cc: Alan Kavanagh; cdni@ietf.org > Subject: RE: draft-ietf-cdni-cases-00 >=20 > Hi Gilles. I'm not sure if the requirements should be written explicitly to map to use cases unless the functions are for that purpose only. In this case, there could be numerous reasons why dCDN provides its resource information to the uCDN. > The discussion below indicates a need for RRI requirement, which can be traced to REQ-2. Is this not sufficient? > Kent > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20 > Sent: Tuesday, November 15, 2011 1:02 PM > To: Kent Leung (kleung) > Cc: alan.kavanagh@ericsson.com; cdni@ietf.org > Subject: RE: draft-ietf-cdni-cases-00 > Hi Kent, > As raised by Alan in his e-mail below, in an offload use case the uCDN would require information on the dCDNs to be aware of the amount of traffic it can offload to every dCDN. I think this requirement is already covered through the request routing interface as REQ-2 includes the advertising of information about dCDN resources. Maybe we might add a few words to REQ-2 to mention explicitly that resource information could be needed for offload situations. > I am not 100% clear today if the offload use case introduces specific requirements on other interfaces (e.g., control and metadata) in addition to the request routing interface. I see some specificity in this use case, for instance, the duration during which the uCDN will use the dCDN resources can be short in an offload situation (e.g., duration of a flash crowd) as compared to a footprint extension use case. > Best regards, > Gilles > From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20 > Sent: November-07-11 5:19 AM > To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; trevor.burbridge@bt.com; philip.eardley@bt.com; kevin.ma@azukisystems.com > Cc: cdni@ietf.org > Subject: RE: draft-ietf-cdni-cases-00 >=20 > (...) > Section 3.1 Offloading. It should be noted that this use case would require knowledge about the other CDN to know if the other CDN has the resources to offload the requests in the first place and also if the content is available in the CDN being offloaded too. > I agree: the CDN on which requests are offloaded must be able to handle the offloaded requests. This (may) introduce requirements on the metadata (and control) interfaces.=20 > A.K.--> Yes, my point exactly, it would be useful to point that out in your draft to make it complete and also have it noted in the "CDNI Requirements Draft" . > (...) > (...) > _______________________________________________ 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 ben@niven-jenkins.co.uk Mon Nov 21 10:32: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 F2B9E1F0C6E for ; Mon, 21 Nov 2011 10:32:22 -0800 (PST) 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 Cfnj50-GR25c for ; Mon, 21 Nov 2011 10:32:18 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 41B8E1F0C67 for ; Mon, 21 Nov 2011 10:32:18 -0800 (PST) Received: from host1.cachelogic.com ([212.44.43.80] helo=dhcp65-239.cachelogic.com) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1RSYfB-0003wn-0j; Mon, 21 Nov 2011 18:32:17 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <2979E38DD6FC6544B789C8DAD7BAFC52104FD387@xmb-sjc-235.amer.cisco.com> Date: Mon, 21 Nov 2011 18:32:13 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A359@EUSAACMS0701.eamcs.ericsson.se> <1B6D0317D3AD964FBF3956DEFA3524D51711E6A38A@EUSAACMS0701.eamcs.ericsson.se> <2979E38DD6FC6544B789C8DAD7BAFC52104FD387@xmb-sjc-235.amer.cisco.com> To: "Kent Leung (kleung)" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 21 Nov 2011 18:32:23 -0000 Kent, On 21 Nov 2011, at 17:47, Kent Leung (kleung) wrote: > Good discussions so far. Just like to clarify some points. >=20 > 1. It looks to me that the topic started off with a requirement for = dCDN > to inform uCDN on the dCDN's available resources to handle offload use > case. This seems to be covered in REQ-2 which generically advertises > such information as part of "capabilities" RRI. >=20 > 2. Then the discussion turned to a need for requirement for dCDN to > notify the uCDN when overload condition occurred (i.e. request cannot = be > handled by dCDN) or no longer the case (i.e. request can be handled > again). This seems to be covered in REQ-14 which provides a generic > "redirection" RRI function.=20 >=20 > 3. Then it seems a requirement for dCDN to convey more specific = context > on why it cannot serve the request (e.g. delivery protocol to location > for period of time). This seems to be more granular level of control > and additional timeliness to REQ-1. Though I suspect that the new > requirement is considered [MED] instead of current priority of [HIGH].=20= >=20 > Have I misinterpreted anything? I'm not sure if the requirements for = #1 > and #2 need any updates. If so, please provide text that does not > functionally overlap with the existing requirements. My intent was not to add additional requirements but probe into the = statement "dCDN Should inform the uCDN it can not handle any requests at = this time" to determine what the actual, specific requirements are. > As for #3, I'm not sure if the intent is to add additional = requirements? I think #3 is not required. E.g. delivery protocol is either explicit or = implicit from the RRI request. Ben >=20 > Kent >=20 > -----Original Message----- > From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 > Sent: Monday, November 21, 2011 6:13 AM > To: Alan Kavanagh > Cc: Lee, Yiu; Kent Leung (kleung); gilles.bertrand@orange.com; > cdni@ietf.org > Subject: Re: [CDNi] draft-ietf-cdni-cases-00 >=20 >=20 > On 16 Nov 2011, at 02:15, Alan Kavanagh wrote: >=20 >> Hi Yiu >>=20 >> I never said it has to be explicit, then again capturing in the > Requirements document suffices :-) >>=20 >> Sure here is some text it just needs to be captured. " dCDN Should > inform the uCDN it can not handle any requests at this time", >=20 > Is the requirement that the "informing" is done via the "capabilities" > request routing interface or the "redirection" request routing > interface? >=20 > For example, is it sufficient for the dCDN to respond to a CDNI > "redirection" interface request with "I cannot serve X> to " with a TTL that indicates the period for > which such information can be reused by the uCDN without re-querying = the > dCDN? >=20 > Ben >=20 >> I dont think it needs to be noted as to why at a given instance of > time the request can not be handled, if others feel different i would > like to hear why. My only further comment is the oposite, i.e. to = inform > the uCDN when it can handle requests again.=20 >>=20 >> BR >> Alan >>=20 >> From: Lee, Yiu [mailto:Yiu_Lee@Cable.Comcast.com]=20 >> Sent: November-15-11 9:02 PM >> To: Alan Kavanagh; Kent Leung (kleung); gilles.bertrand@orange.com >> Cc: cdni@ietf.org >> Subject: Re: [CDNi] draft-ietf-cdni-cases-00 >>=20 >> Hi Alan, >>=20 >> I struggle how explicit we need to put in the requirement. Do you > think a sub-bullet like: "information to signal overload to uCDN" is > sufficient? Can you suggest some text which you think REQ-2 doesn't > capture? We would like people to discuss the new text in the ML. >>=20 >> Thanks, >> Yiu >>=20 >> From: Alan Kavanagh >> Date: Tue, 15 Nov 2011 19:56:48 -0500 >> To: "Kent Leung (kleung)" , > "gilles.bertrand@orange.com" >> Cc: "cdni@ietf.org" >> Subject: Re: [CDNi] draft-ietf-cdni-cases-00 >>=20 >> Hi Kent >>=20 >> What might be useful is to jut capture the requirement somewhere as i > believe their will be numerous ways to address the overload case and i > can see changes required not just on CDN-I metadata i/f as GIlles is > pointing out too, so for now lets capture the requirement. >>=20 >> Alan >>=20 >> From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 >> Sent: November-15-11 3:52 AM >> To: gilles.bertrand@orange.com >> Cc: Alan Kavanagh; cdni@ietf.org >> Subject: RE: draft-ietf-cdni-cases-00 >>=20 >> Hi Gilles. I'm not sure if the requirements should be written > explicitly to map to use cases unless the functions are for that = purpose > only. In this case, there could be numerous reasons why dCDN provides > its resource information to the uCDN. >> The discussion below indicates a need for RRI requirement, which can > be traced to REQ-2. Is this not sufficient? >> Kent >> From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20= >> Sent: Tuesday, November 15, 2011 1:02 PM >> To: Kent Leung (kleung) >> Cc: alan.kavanagh@ericsson.com; cdni@ietf.org >> Subject: RE: draft-ietf-cdni-cases-00 >> Hi Kent, >> As raised by Alan in his e-mail below, in an offload use case the = uCDN > would require information on the dCDNs to be aware of the amount of > traffic it can offload to every dCDN. I think this requirement is > already covered through the request routing interface as REQ-2 = includes > the advertising of information about dCDN resources. Maybe we might = add > a few words to REQ-2 to mention explicitly that resource information > could be needed for offload situations. >> I am not 100% clear today if the offload use case introduces specific > requirements on other interfaces (e.g., control and metadata) in > addition to the request routing interface. I see some specificity in > this use case, for instance, the duration during which the uCDN will = use > the dCDN resources can be short in an offload situation (e.g., = duration > of a flash crowd) as compared to a footprint extension use case. >> Best regards, >> Gilles >> From: gilles.bertrand@orange.com [mailto:gilles.bertrand@orange.com]=20= >> Sent: November-07-11 5:19 AM >> To: Alan Kavanagh; emile.stephan@orange.com; grant.watson@bt.com; > trevor.burbridge@bt.com; philip.eardley@bt.com; > kevin.ma@azukisystems.com >> Cc: cdni@ietf.org >> Subject: RE: draft-ietf-cdni-cases-00 >>=20 >> (...) >> Section 3.1 Offloading. It should be noted that this use case would > require knowledge about the other CDN to know if the other CDN has the > resources to offload the requests in the first place and also if the > content is available in the CDN being offloaded too. >> I agree: the CDN on which requests are offloaded must be able to > handle the offloaded requests. This (may) introduce requirements on = the > metadata (and control) interfaces.=20 >> A.K.--> Yes, my point exactly, it would be useful to point that out = in > your draft to make it complete and also have it noted in the "CDNI > Requirements Draft" . >> (...) >> (...) >> _______________________________________________ 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 From kleung@cisco.com Mon Nov 21 16:21: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 32CE61F0C55 for ; Mon, 21 Nov 2011 16:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 KhFqrZyYmqHv for ; Mon, 21 Nov 2011 16:21:45 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id C19101F0C4C for ; Mon, 21 Nov 2011 16:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=54724; q=dns/txt; s=iport; t=1321921305; x=1323130905; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=mh0/4cKFIkLuGYN48/O/JSxaaZzWTZMCAynLj5aS49w=; b=bA9chsb32Zs7DK98MnxBlLFjIJZccbl37rq1+yyDq93AWx+FIqs/4PCH uZPN/ZS6vZ8yrrMQQbLHbMnpMwEDFjFI9Fv0PWBcU5+e+uTM8oDQf8YJ5 RlZWu95WosonYkdl1bSN9dTzAbdlUEOhO5wGaaQGbjtZZNC8X6NTDIg1F s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMAAEzqyk6rRDoG/2dsb2JhbABDgk2XWpAagQWBcgEBAQQSAQcCEQM3EhACAQgRBAEBCwYQAQYBBgFFCQgBAQQBEggTB51fAZ5fiTRjBIgakWeMYA X-IronPort-AV: E=Sophos;i="4.69,550,1315180800"; d="scan'208,217";a="13852839" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 22 Nov 2011 00:21:44 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id pAM0LjI9006479; Tue, 22 Nov 2011 00:21:45 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 16:21:44 -0800 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_01CCA8AC.B70AE6CF" Date: Mon, 21 Nov 2011 16:21:30 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC521057DE57@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI Thread-Index: Acyluue1VwBoW4bdQzKTHYrfqOLp/wCuspTQ References: <291CC3F9E50E7641901A54E85D0977C651B6CD51F6@MAILR002.mail.lan> From: "Kent Leung (kleung)" To: "Serge Manning" , "Kevin J Ma" X-OriginalArrivalTime: 22 Nov 2011 00:21:44.0888 (UTC) FILETIME=[B73B9B80:01CCA8AC] 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: Tue, 22 Nov 2011 00:21:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCA8AC.B70AE6CF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Serge and Kevin. Comments below. =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Serge Manning Sent: Thursday, November 17, 2011 10:26 PM To: Kevin J Ma Cc: cdni@ietf.org Subject: Re: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI =20 Thanks for looking at the draft and providing feedback Kevin. See inline. On Wed, Nov 16, 2011 at 12:24 PM, Kevin J Ma wrote: Serge (and Kent), Some questions/comments on the requirements in the draft: LOG-A1/A2 seem like a good idea. They seem to mimic the existing LOG-2/3 requirements, respectively, which seems fine, but do we need to have separate requirements for these or can we just update LOG-2/3 to include failures? That sounds fine. =20 KL> Proposed update to LOG-2: =20 LOG-2 [HIGH] The CDNI Logging interface shall provide logging of deliveries and incomplete deliveries to User Agents performed by=20 the Downstream CDN as a result of request redirection by the Upstream CDN. =20 KL> Proposed update to LOG-3: =20 LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging interface shall allow the Downstream CDN to report to the Upstream CDN logging for deliveries and incomplete deliveries performed by the Downstream CDN itself as well as logging for deliveries performed by cascaded CDNs on behalf of the Downstream CDN. =20 =20 One question about LOG-2 and LOG-A1: is the text "deliveries to User Agents" intended to imply that the data should track and be aggregatable per unique user? We may want to clarify that? My interpretation is that a logging record is generated for each content delivered to an end user by the dCDN on behalf of the uCDN. Not sure what you mean about "aggregate."=20 =20 LOG-A3/A4 sound reasonable. Should we include bandwidth or other usage metrics as well and can they all be included in one usage metric requirement (similar to META-14)? That would be OK. We can probably just keep the requirements general as bandwidth, storage, etc. and determine the parameters in the solutions documents. =20 KL> Proposed new requirements: =20 LOG-## [MED] The CDNI Logging interface shall support logging of consumed resources (e.g. storage, bandwidth) to the upstream CDN for deliveries where content is stored by the downstream CDN for delivery to User Agents. The information logged may include the type of storage (e.g., Origin, Intermediate, Edge, Cache) as well as the amount of storage (e.g., total GB, GB used, per time period, per content domain) all of which may impact the cost of the services. =20 LOG-## [MED] In the case of cascaded CDNs, the CDNI Logging interface shall support the Downstream CDN to report consumed resources (e.g. storage, bandwidth) to the Upstream CDN where content is stored by the Downstream CDN itself as well as logging for storage resources when content storage is performed by cascaded CDNs on behalf of the Downstream CDN. =20 =20 =20 The example metrics in LOG-A3 seem like they could be exposing intra-CDN information (e.g., total GB)? Does this go against the GEN-4 requirement? The intention of LOG-A3 is to report usage of aggregate storage used by the dCDN on behalf of the uCDN and not other internal storage resources private to the dCDN. =20 LOG-A5 could be interpreted as either: a) configure the dCDN to do storage reporting, or b) ask the dCDN to immediately send out logs? If the latter, it seems to overlap with the existing LOG-9 requirement? I think LOG-A5 is the same as LOG-9 except for storage. So this could be folded into LOG-9. =20 KL> Note LOG-9 is [LOW] vs. LOG-A5 [MED]. The former is a superset to obtain any logging records including storage. So no need to change LOG-9 other than to raise the priority level. =20 LOG-9 [MED] The CDNI Logging interface may allow a CDN to query another CDN for relevant current logging records (e.g. For on-demand access to real-time logging information). =20 =20 =20 Are LOG-A3/A4 intended to be periodic, or only on-demand? If the latter, then is it just an issue of raising LOG-9 from LOW to MED? Note: LOG-9/A5 should probably be included in the 'trigger' discussion? The thinking was to have normal periodic with on-demand as an additional capability if the uCDN wanted to do a check of what storage is outstanding at the moment. =20 LOG-A6 seems like two requirements, that could be parts of a more generic set of LOG-A3/A5 requirements? No, I think LOG-6 is talking about the logging interface itself and its ability to be responsive for some near real-time uses. While LOG-A3/A5 is talking about the types of parameters in the logging messages. =20 KL> My interpretation of LOG-A6 is that uCDN indicates which performance data should be reported by dCDN in the Logging Interface. This seems to be same though better worded requirement for LOG-11. =20 Propose to update LOG-11. Priority remain as [LOW]? =20 LOG-11 [LOW] The CDNI Logging interface shall support logging of performance data for deliveries to User Agents performed by the Downstream CDN as a result of request redirection by the Upstream CDN. Performance data may include various traffic statistics (the specific parameters are to be determined). The Logging interface shall support the upstream CDN to indicate the nature and contents of the performance data to be reported by the downstream CDN. =20 =20 =20 LOG-A7 sounds ok, but is the confirmation from the delete request not sufficient? Is a log of individual deleted objects only meaningful if the object was there to be deleted, i.e. does it need to compare against everything that was acquired but not yet evicted? IMO, the response to the delete is more a control plane acknowledgement while the logging interface is a complete record of transactions between the CDNs. Thus, we need both. =20 KL> There's value to log a delete event. Should this be [MED] instead? Proposed new requirement: =20 =20 LOG-## [MED] The CDNI Logging interface shall support logging of deleted objects from the downstream CDN to the upstream CDN as a result of explicit delete requests on via the Control interface from the upstream CDN. =20 LOG-A8/A9 seem reasonable, though they feel more like a MED than a HIGH to me. Assuming they are HIGH, could we just update the existing LOG-7 requirement to include extensibility? Is there an existing log description language that could/should be used here? I believe that making the messaging extensible is easy and needs to be done on the first release so that small proprietary fields can be carried over this otherwise standardized interface resulting in wide use of the standard. We should not make the messaging fixed and then later decide to make it extendable. =20 KL> I agree there's value to have extensibility built in the Logging Interface. This includes the ability to support proprietary information. Proposed new requirements. =20 LOG-## [HIGH] The CDNI Logging interface shall support extensibility to allow proprietary information fields to be carried. These information fields must be agreed upon ahead of time between the corresponding CDNs. =20 LOG-## [HIGH] The CDNI Logging interface shall support the exchange of extensible log file formats to support proprietary information fields. These information fields must be agreed upon ahead of time between the corresponding CDNs. =20 =20 =20 CNTL-A1 seems to overlap with the existing CNTL-2 requirement. Could we just fix the wording in CNTL-2? Yes, we can fold the confirmation into CNTL-2. =20 KL> Proposed update to requirement: =20 CNTL-2 [HIGH] The CDNI Control interface shall allow the downstream CDN to report on the completion of these actions (by itself, and if cascaded CDNs are supported by the solution, by potential cascaded Downstream CDNs), in a manner appropriate for the action (e.g. synchronously or asynchronously). =20 The confirmation receipt should include a success or failure indication. The failure indication is used if the dCDN cannot delete the content in its storage. =20 =20 CNTL-A2 may need to clarify who created the sub-objects? If the dCDN created the sub-objects, then that may be intra-CDN information that falls under the GEN-4 requirement? Otherwise, it feels like a normal delete failure? Is this requirement to get a more detailed error in the CNTL-A3 case? If the delete is successful, everyone is happy. If the delete fails, you get confirmation of that. If the delete *partially* fails which would mean its an object with sub-objects, then this is asking for a more detailed partial delete report. I think the sub-objects have to be known and understandable by the uCDN for this to be of any value. So I don't think this applies if the dCDN creates the sub-objects. Right now, I don't myself understand how the dCDN would do this sub-object creation on its own. Maybe you could explain. =20 CNTL-A3 seems to have a couple of aspects. I think bulk delete is already covered by the existing CNTL-1 requirement. The second part which lists filters for bulk delete seems to imply that the dCDN needs to know what the content is and who it belongs to? That seems like it may need some type of companion metadata requirement? I don't see the bulk delete in CNTL-1. I think the two aspects here are linked. Hmm...it seems like it may need some metadata requirement. Let me think about it some more. =20 KL> Proposed update to requirement: =20 CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream CDN to request that the Downstream CDN (and, if cascaded CDNs are supported by the solution, that the potential cascaded Downstream CDNs) perform the following actions on an object or object set: =20 * Mark an object or set of objects and/or related CDNI metadata as "stale" and revalidate them before they are delivered again =20 * Delete an object or set of objects and/or related CDNI metadata from the CDN surrogates and any storage. Only the object(s) and CDNI metadata that pertain to the requesting Upstream CDN are allowed to be purged. =20 =20 CNTL-A4 feels out of scope. Reservation seems more like a precondition to interconnecting? Is the reservation just a suggestion to, or a requirement for, the dCDN? Is there an existing reservation protocol that could/should be used here? Maybe a use case would be helpful to describe the CDNI scope? I will look up the ATIS use case and report it back here. =20 Thanks again for your analysis and feedback. =20 Agree with most points here. =20 Kent =20 thanx. =09 -- Kevin J. Ma =09 =09 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Serge Manning Sent: Friday, October 21, 2011 5:47 PM To: cdni@ietf.org Subject: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI =09 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 Please take a look at the draft and provide your feedback. Thanks. =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 --Serge ------_=_NextPart_001_01CCA8AC.B70AE6CF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Hi Serge and Kevin.  Comments below.

       

      From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = Serge Manning
      Sent: Thursday, November 17, 2011 10:26 = PM
      To: Kevin J Ma
      Cc: = cdni@ietf.org
      Subject: Re: [CDNi] ATIS CDN Interconnect Reqs = into IETF CDNI

       

      Thanks for looking at the draft and = providing feedback Kevin. See inline.

      On Wed, Nov 16, 2011 at 12:24 PM, Kevin J Ma <kevin.ma@azukisystems.com&g= t; wrote:

      Serge (and Kent),

       Some = questions/comments on the requirements in the = draft:

       LOG-A1/A2 seem like a good idea.  They seem to = mimic the existing
       LOG-2/3 requirements, respectively, which = seems fine, but do we need
       to have separate requirements for = these or can we just update LOG-2/3
       to include = failures?

      That sounds = fine.

       

      KL> Proposed update to LOG-2:

       

      LOG-2   [HIGH] The CDNI Logging interface = shall provide logging of

               &= nbsp; deliveries and incomplete deliveries to User Agents performed by =

               &= nbsp; the Downstream CDN as

               &= nbsp; a result of request redirection by the Upstream = CDN.

       

      KL> Proposed update to LOG-3:

       

      LOG-3   [MED] In the =
case of cascaded CDNs, the CDNI Logging
           &nbs=
p;     interface shall allow the Downstream CDN to =
report to the
           &nbs=
p;     Upstream CDN logging for deliveries and =
incomplete deliveries performed by the
           &nbs=
p;     Downstream CDN itself as well as logging for =
deliveries
           &nbs=
p;     performed by cascaded CDNs on behalf of the =
Downstream CDN.

       

       

       One question about LOG-2 and = LOG-A1: is the text "deliveries to
       User Agents" = intended to imply that the data should track and = be
       aggregatable per unique user?  We may want to clarify = that?

      My = interpretation is that a logging record is generated for each content = delivered to an end user by the dCDN on behalf of the uCDN. Not sure = what you mean about = "aggregate." 

       

       LOG-A3/A4 sound reasonable. =  Should we include bandwidth or other
       usage metrics as = well and can they all be included in one usage
       metric = requirement (similar to META-14)?

      That would be OK. We can probably just keep the = requirements general as bandwidth, storage, etc. and determine the = parameters in the solutions documents.

       

      KL> Proposed new requirements:

       

           =
LOG-##  [MED] The CDNI Logging interface shall support logging =
of
           &nbs=
p;       consumed resources (e.g. storage, =
bandwidth) to the upstream CDN for deliveries =
where
           &nbs=
p;       content is stored by the =
downstream CDN for delivery to
           &nbs=
p;       User Agents. The information =
logged may include the type
           &nbs=
p;       of storage (e.g., Origin, =
Intermediate, Edge, Cache) as
           &nbs=
p;       well as the amount of storage =
(e.g., total GB, GB used,
           &nbs=
p;       per time period, per content =
domain) all of which may
           &nbs=
p;       impact the cost of the =
services.
       
           = LOG-##  [MED] In the case of cascaded CDNs, the CDNI = Logging
           &nbs=
p;       interface shall support the =
Downstream CDN to report
           &nbs=
p;       consumed resources (e.g. storage, =
bandwidth) to the Upstream CDN where content =
is
           &nbs=
p;       stored by the Downstream CDN =
itself as well as logging for
           &nbs=
p;       storage resources when content =
storage is performed by
           &nbs=
p;       cascaded CDNs on behalf of the =
Downstream CDN.
       

       

       

       The example metrics in LOG-A3 seem = like they could be exposing
       intra-CDN information (e.g., total = GB)?  Does this go against the
       GEN-4 = requirement?

      The = intention of LOG-A3 is to report usage of aggregate storage used by the = dCDN on behalf of the uCDN and not other internal storage resources = private to the dCDN.

       

       LOG-A5 could be interpreted as = either: a) configure the dCDN to do
       storage reporting, or b) = ask the dCDN to immediately send out logs?
       If the latter, it = seems to overlap with the existing LOG-9 = requirement?

      I = think LOG-A5 is the same as LOG-9 except for storage. So this could be = folded into LOG-9.

       

      KL> Note LOG-9 is [LOW] vs. LOG-A5 [MED].  The former is a = superset to obtain any logging records including storage.  So no = need to change LOG-9 other than to raise the priority = level.

       

         LOG-9   =
[MED] The CDNI Logging interface may allow a CDN to =
query
           &nbs=
p;     another CDN for relevant current logging =
records (e.g.  For
           &nbs=
p;     on-demand access to real-time logging =
information).

       

       

       

       Are LOG-A3/A4 intended to be = periodic, or only on-demand?  If the
       latter, then is it = just an issue of raising LOG-9 from LOW to MED?
       Note: LOG-9/A5 = should probably be included in the 'trigger' = discussion?

      The = thinking was to have normal periodic with on-demand as an additional = capability if the uCDN wanted to do a check of what storage is = outstanding at the moment.

       

       LOG-A6 seems like two requirements, = that could be parts of a more
       generic set of LOG-A3/A5 = requirements?

      No, I = think LOG-6 is talking about the logging interface itself and its = ability to be responsive for some near real-time uses. While LOG-A3/A5 = is talking about the types of parameters in the logging = messages.

       

      KL> My interpretation of LOG-A6 is that uCDN indicates which = performance data should be reported by dCDN in the Logging = Interface.  This seems to be same though better worded requirement = for LOG-11.

       

      Propose to update LOG-11.  Priority remain as = [LOW]?

       

           =
LOG-11  [LOW] The CDNI Logging interface shall support logging =
of
           &nbs=
p;       performance data for deliveries =
to User Agents performed
           &nbs=
p;       by the Downstream CDN as a result =
of request redirection
           &nbs=
p;       by the Upstream CDN. Performance =
data may include various
           &nbs=
p;       traffic statistics (the specific =
parameters are to be
           &nbs=
p;       determined). The Logging =
interface shall support the
           &nbs=
p;       upstream CDN to indicate the =
nature and contents of the
           &nbs=
p;       performance data to be reported =
by the downstream CDN.

       

       

       

       LOG-A7 sounds ok, but is the = confirmation from the delete request not
       sufficient?  Is a = log of individual deleted objects only meaningful
       if the object = was there to be deleted, i.e. does it need to compare
       against = everything that was acquired but not yet = evicted?

      IMO, the = response to the delete is more a control plane acknowledgement while the = logging interface is a complete record of transactions between the CDNs. = Thus, we need both.

       

      KL> There’s value to log a delete event.  Should this = be [MED] instead? Proposed new requirement:

       

       

           =
LOG-##  [MED] The CDNI Logging interface shall support logging =
of
           &nbs=
p;       deleted objects from the =
downstream CDN to the upstream
           &nbs=
p;       CDN as a result of explicit delete =
requests on via the
           &nbs=
p;       Control interface from the =
upstream CDN.

       

       LOG-A8/A9 seem reasonable, though = they feel more like a MED than a
       HIGH to me.  Assuming = they are HIGH, could we just update the existing
       LOG-7 = requirement to include extensibility?  Is there an = existing
       log description language that could/should be used = here?

      I believe = that making the messaging extensible is easy and needs to be done on the = first release so that small proprietary fields can be carried over this = otherwise standardized interface resulting in wide use of the standard. = We should not make the messaging fixed and then later decide to make it = extendable.

       

      KL> I agree there’s value to have extensibility built in the = Logging Interface.  This includes the ability to support = proprietary information.  Proposed new = requirements.

       

           =
LOG-##  [HIGH] The CDNI Logging interface shall =
support
           &nbs=
p;       extensibility to allow =
proprietary information fields to
           &nbs=
p;       be carried. These information =
fields must be agreed upon
           &nbs=
p;       ahead of time between the =
corresponding CDNs.
       
           = LOG-##  [HIGH] The CDNI Logging interface shall support = the
           &nbs=
p;       exchange of extensible log file =
formats to support
           &nbs=
p;       proprietary information fields. =
These information fields
           &nbs=
p;       must be agreed upon ahead of time =
between the
            =
       corresponding =
CDNs.

       

       

       

       CNTL-A1 seems to overlap with the = existing CNTL-2 requirement.
       Could we just fix the wording in = CNTL-2?

      Yes, we can = fold the confirmation into CNTL-2.

       

      KL> Proposed update to = requirement:

       

         CNTL-2   =
[HIGH] The CDNI Control interface shall allow the =
downstream
           &nbs=
p;      CDN to report on the completion of =
these actions (by itself,
           &nbs=
p;      and if cascaded CDNs are supported by =
the solution, by
           &nbs=
p;      potential cascaded Downstream CDNs), in =
a manner appropriate
           &nbs=
p;      for the action (e.g. synchronously or =
asynchronously).  
           &nbs=
p;      The confirmation receipt should =
include a success or
           &nbs=
p;      failure indication. The failure =
indication is used if the
           &nbs=
p;      dCDN cannot delete the content in its =
storage.
       

       

       CNTL-A2 may need to clarify who = created the sub-objects?  If the
       dCDN created the = sub-objects, then that may be intra-CDN information
       that falls = under the GEN-4 requirement?  Otherwise, it feels like = a
       normal delete failure?  Is this requirement to get a = more detailed
       error in the CNTL-A3 = case?

      If the delete = is successful, everyone is happy. If the delete fails, you get = confirmation of that. If the delete *partially* fails which would mean = its an object with sub-objects, then this is asking for a more detailed = partial delete report. I think the sub-objects have to be known and = understandable by the uCDN for this to be of any value. So I don't think = this applies if the dCDN creates the sub-objects. Right now, I don't = myself understand how the dCDN would do this sub-object creation on its = own. Maybe you could explain.

       

       CNTL-A3 seems to have a couple of = aspects.  I think bulk delete is
       already covered by the = existing CNTL-1 requirement.  The second part
       which lists = filters for bulk delete seems to imply that the dCDN needs
       to = know what the content is and who it belongs to?  That seems like = it
       may need some type of companion metadata = requirement?

       I don't see the bulk delete in CNTL-1. I think = the two aspects here are linked. Hmm...it seems like it may need some = metadata requirement. Let me think about it some = more.

       

      KL> Proposed update to requirement:

       

         CNTL-1   =
[HIGH] The CDNI Control interface shall allow the =
Upstream
           &nbs=
p;      CDN to request that the Downstream CDN =
(and, if cascaded
           &nbs=
p;      CDNs are supported by the solution, =
that the potential
           &nbs=
p;      cascaded Downstream CDNs) perform the =
following actions on
           &nbs=
p;      an object or object =
set:
       
           &nbs= p;      *   Mark an object or set of = objects and/or related CDNI metadata as = "stale"
           &nbs=
p;          and revalidate =
them before they are delivered again
       
           &nbs= p;      *   Delete an object or set = of objects and/or related CDNI metadata from = the
           &nbs=
p;          CDN surrogates =
and any storage.  Only the object(s) =
and
           &nbs=
p;          CDNI metadata =
that pertain to the requesting Upstream
           &nbs=
p;          CDN are allowed =
to be purged.

       

       

       CNTL-A4 feels out of scope. =  Reservation seems more like a precondition
       to = interconnecting?  Is the reservation just a suggestion to, or = a
       requirement for, the dCDN?  Is there an existing = reservation protocol
       that could/should be used here? =  Maybe a use case would be helpful to
       describe the CDNI = scope?

      I will look = up the ATIS use case and report it back = here.

       

      Thanks again for your analysis and = feedback.

       

      Agree with most points here.

       

      Kent

       

      thanx.

      --  Kevin J. Ma


      From: cdni-bounces@ietf.org = [mailto:cdni-bounces@ietf.org] On = Behalf Of Serge Manning
      Sent: Friday, October 21, 2011 5:47 PM
      To: = cdni@ietf.org
      Subject: [CDNi] = ATIS CDN Interconnect Reqs into IETF CDNI


      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



       

      -- =
      --Serge

      ------_=_NextPart_001_01CCA8AC.B70AE6CF-- From kleung@cisco.com Mon Nov 21 16:36: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 178F71F0C7E for ; Mon, 21 Nov 2011 16:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 v3td4saCn-uS for ; Mon, 21 Nov 2011 16:36:13 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 354D31F0C55 for ; Mon, 21 Nov 2011 16:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=948; q=dns/txt; s=iport; t=1321922173; x=1323131773; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=u5dCGX88YDvso+MivfOViqAE4vKT4+X3v6sDrHwyz2k=; b=BMaoB68l7e07J3iBVbiA6tfDNYoBwHI82eE8GsYlvHigY9Xq3TVP9x4R y9pm9SiVzq0oJP24gONn+c2qVCZx3UNqaBYxthhQ2we2PG8lqh/lgeqlg 3HxoXmZLz/ajpuHIC4U/DAl4e/jo7a3UfDuRxyK5oMDOXU/PDOMKaYAmU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJrtyk6rRDoI/2dsb2JhbABDqkGBBYFyAQEBAwESAR0KPwULAgEIIgYYBgFWAQEEGxMHh2GWBQGeXok0YwSIGpFnjGA X-IronPort-AV: E=Sophos;i="4.69,550,1315180800"; d="scan'208";a="15546837" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 22 Nov 2011 00:36:10 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAM0aAOd012474; Tue, 22 Nov 2011 00:36:10 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Nov 2011 16:36:10 -0800 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, 21 Nov 2011 16:36:09 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC521057DE60@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] draft-ietf-cdni-cases-00 Thread-Index: Acyoe+dzh5FQyYAoTriWfKDJ3iQemQAMVb5Q References: <1B6D0317D3AD964FBF3956DEFA3524D51711E6A359@EUSAACMS0701.eamcs.ericsson.se> <1B6D0317D3AD964FBF3956DEFA3524D51711E6A38A@EUSAACMS0701.eamcs.ericsson.se> <2979E38DD6FC6544B789C8DAD7BAFC52104FD387@xmb-sjc-235.amer.cisco.com> From: "Kent Leung (kleung)" To: "Ben Niven-Jenkins" X-OriginalArrivalTime: 22 Nov 2011 00:36:10.0312 (UTC) FILETIME=[BB10D480:01CCA8AE] Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-cases-00 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, 22 Nov 2011 00:36:17 -0000 Hi Ben. > My intent was not to add additional requirements but probe into the statement "dCDN Should =20 > inform the uCDN it can not handle any requests at this time" to determine what the actual,=20 > specific requirements are. KL> OK. This should be covered in REQ-14 and REQ-1. I think you were also trying to support the function below (i.e. indicate when dCDN will be ready to handle request again) >=20 >> I dont think it needs to be noted as to why at a given instance of > time the request can not be handled, if others feel different i would > like to hear why. My only further comment is the oposite, i.e. to inform > the uCDN when it can handle requests again.=20 >>=20 >> BR >> Alan KL> This requirement seems to be covered in REQ-1 already? The solution may be based on your proposed TTL method. But that level of detail does not need to be in the requirements draft, IMHO. Kent From flefauch@cisco.com Fri Nov 25 03:04:46 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 EC8CF21F8C30 for ; Fri, 25 Nov 2011 03:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.731 X-Spam-Level: X-Spam-Status: No, score=-8.731 tagged_above=-999 required=5 tests=[AWL=1.868, 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 DTzCI+b1B1RS for ; Fri, 25 Nov 2011 03:04:46 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B483921F8BF0 for ; Fri, 25 Nov 2011 03:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=294; q=dns/txt; s=iport; t=1322219086; x=1323428686; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=wFPyH+YvNc5rsmV+lpWdNqzqferJtrYGVfC8ZI+ZkVU=; b=OBoKB1PPyDOzCL/wjuLUiIwMVWByOID5GiJHPxppIn1KL6D75lTCByac CGK19I6fLDoN3azDIzfnvTWXAQKTb4VXo3MCE0gosL2c1JUSkv1r3sRaV bspNtfrA6mq921duDK3DKSnSIZ7TXQZi7zIeWen5CNAk6dgMvj+hc/kh1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAAh2z06Q/khN/2dsb2JhbABDqnSBBYILASeCGRmHa5Y0gSYBnXWHTYIyYwSUSpIM X-IronPort-AV: E=Sophos;i="4.69,570,1315180800"; d="scan'208";a="60408231" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 25 Nov 2011 11:04:44 +0000 Received: from ams-flefauch-8713.cisco.com (ams-flefauch-8713.cisco.com [10.55.161.196]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAPB4hFU020176 for ; Fri, 25 Nov 2011 11:04:43 GMT From: Francois Le Faucheur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Nov 2011 12:04:39 +0100 Message-Id: <3D4DA48B-0382-460F-B188-63455574C620@cisco.com> To: cdni@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [CDNi] Draft minutes from IETF82 CDNI WG available 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, 25 Nov 2011 11:04:47 -0000 Hi, The draft CDNI Working Group minutes have been uploaded = (http://www.ietf.org/proceedings/82/minutes/cdni.txt). Please review and comment if needed, so we can prepare the final = minutes. Cheers Francois & Rich=20 PS: Thanks to Vinayak for taking notes during the meeting. From gilles.bertrand@orange.com Mon Nov 28 01: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 41ACE21F8CAE for ; Mon, 28 Nov 2011 01:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.228 X-Spam-Level: X-Spam-Status: No, score=-1.228 tagged_above=-999 required=5 tests=[BAYES_50=0.001, EXTRA_MPART_TYPE=1, HELO_EQ_FR=0.35, 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 OaB220tBv0aZ for ; Mon, 28 Nov 2011 01:59:57 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDE421F8CAB for ; Mon, 28 Nov 2011 01:59:57 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E67C8958006; Mon, 28 Nov 2011 11:10:25 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id D9964958005; Mon, 28 Nov 2011 11:10:25 +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, 28 Nov 2011 10:59:54 +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_01CCADB4.7A1209EC" Date: Mon, 28 Nov 2011 10:59:43 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF02E67ECC@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Definitions inside PS and Framework draft Thread-Index: AcyttHPFrVIk3UYESW2duhiaUpRhNA== From: To: , , X-OriginalArrivalTime: 28 Nov 2011 09:59:54.0875 (UTC) FILETIME=[7A8E0CB0:01CCADB4] Cc: cdni@ietf.org Subject: [CDNi] Definitions inside PS and Framework 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: Mon, 28 Nov 2011 09:59:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCADB4.7A1209EC Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CCADB4.7A1209EC" ------_=_NextPart_002_01CCADB4.7A1209EC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Colleagues, =20 As discussed during IETF#82, we are tidying up the terminology section = of the use cases draft. =20 The use cases and the problem statement drafts propose slightly = different definitions of some terms:=20 Problem statement: Authoritative CDN: A CDN which has a direct relationship with a CSP for the distribution & delivery of that CSP's content. =20 CDN Interconnection (CDNI): The set of interfaces over which two or more CDNs communicate with each other in order to achieve the delivery of content to User Agents by Surrogates in one CDN (the downstream CDN) on behalf of another CDN (the upstream CDN). Use cases: Authoritative CDN (aCDN): A CDN provider contracted by the CSP for = delivery of content by its CDN or by its downstream CDNs. =20 CDN Interconnection: Relationship between two CDNs that enables a CDN to provide content delivery services on behalf of another CDN. It relies on a set of interfaces over which two CDNs communicate in order to achieve the delivery of content to end-users by one CDN (the downstream CDN) on behalf of another CDN (the upstream CDN). I find these two definitions from the use cases draft clearer. Do you = agree?=20 =20 =20 Some relevant terms are defined only in the use cases draft. Could you = please include them in the problem statement? Access CDN: A CDN that is directly connected to the end-user's access. An Access CDN may have specific information about the end-user and the network, for instance, end-user's profile and access capabilities. =20 Delivering CDN: The CDN that delivers the requested piece of content to the end-user. In particular, the delivering CDN can be an access CDN. =20 =20 Some terms are not defined yet in the WG's drafts. Could you define them = inside the framework draft? recursive request routing iterative request routing =20 Cordialement, with kind regards, =20 =20 Gilles Bertrand R&D, AudioVisual Delivery (AVD) Content Network Architect t=E9l. +33 (0) 145 29 89 46=20 gilles.bertrand@orange.com =20 =20 ------_=_NextPart_002_01CCADB4.7A1209EC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

      Colleagues,

       

      As discussed during IETF#82, we are tidying up the = terminology section of the use cases draft.

       

      The use cases and the problem = statement drafts propose slightly different definitions of some terms: =

      Problem = statement:

      =A0=A0 = Authoritative CDN: A CDN which has a direct relationship with a = CSP

      =A0=A0 for the = distribution & delivery of that CSP's = content.

       
      =A0=A0 CDN Interconnection (CDNI): The set =
of interfaces over which two or
      =A0=A0 more CDNs communicate with each =
other in order to achieve the
      =A0=A0 delivery of content to User Agents =
by Surrogates in one CDN (the
      =A0=A0 downstream CDN) on behalf of another =
CDN (the upstream CDN).

      Use = cases:

      =A0=A0 = Authoritative CDN (aCDN):=A0=A0 A CDN provider contracted by the CSP for = delivery of content by its

      =A0=A0 CDN or by = its downstream CDNs.

       

      =A0=A0CDN = Interconnection:

      =A0=A0 Relationship = between two CDNs that enables a CDN to provide = content

      =A0=A0 delivery = services on behalf of another CDN.=A0 It relies on a set = of

      =A0=A0 interfaces = over which two CDNs communicate in order to achieve = the

      =A0=A0 delivery of = content to end-users by one CDN (the downstream CDN) = on

      =A0=A0 behalf of = another CDN (the upstream CDN).

      I find = these two definitions from the use cases draft clearer. Do you agree? =

       

       

      Some relevant terms are defined only in the use cases = draft. Could you please include them in the problem = statement?

      =A0=A0 Access = CDN:

      =A0=A0 A CDN that = is directly connected to the end-user's access.=A0 An = Access

      =A0=A0 CDN may have = specific information about the end-user and the = network,

      =A0=A0 for = instance, end-user's profile and access = capabilities.

       

      =A0 =A0=A0Delivering = CDN:

      =A0=A0 The CDN that = delivers the requested piece of content to the = end-user.

      =A0=A0 In = particular, the delivering CDN can be an access = CDN.

       

       

      Some terms are not defined yet in the = WG's drafts. Could you define them inside the framework = draft?

      =A0=A0 recursive = request routing

      =A0=A0 iterative = request routing

       

      Cordialement, with kind = regards,

       

      <= img width=3D40 height=3D40 id=3D"Image_x0020_1" = src=3D"cid:image001.gif@01CCADB9.84120430" = alt=3D"http://www.orange.com/sirius/logos_mail/orange_logo.gif"><= o:p>

      G= illes Bertrand<= br>R&D, AudioVisual Delivery (AVD)
      Content Network = Architect
      t=E9l. +33 (0) 145 29 89 46 =
      gilles.bertrand@orange.com

      <= img width=3D18 height=3D20 id=3D"Image_x0020_2" = src=3D"cid:image002.gif@01CCADB9.84120430" = alt=3D"http://www.orange.com/sirius/logos_mail/ampersand.gif"><= o:p>

       

      ------_=_NextPart_002_01CCADB4.7A1209EC-- ------_=_NextPart_001_01CCADB4.7A1209EC Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.gif Content-Location: image001.gif R0lGODlhKAAoAPcAAP9mAP9lAP////9jAP9kAP9gAP9eAP9dAP9iAP9fAP/x5/9cAP9YAP9ZAP/6 9v+3i/9yGf9lBP+ygv/n1/+IQf/Xvf/fyf+kbP+3if/LrP9jAv9oBv+7kP9oCP91Hf/UuP9xF/+/ lv/awP9mB/+JPf+XV/+EPP+KPf/y6f+HQf+HQv9pC/+PRf/s4f/59f9/Mv9kAv9lAv+cXf/IpP/8 +v/8+P+4jf/Stf9VAP/Ttv/Bmf/Lq/9sDv9vEP9sC/+JPv+2hv9xFv+VUP+ALf9zGv+1h//w5v/u 4v9kBf/JqP/Vuv+3h/+KQv+IQv+2h/9kC/+9k//t4v92G//dyf9bAP9vEv+zhf9aAP91JP/07P/D nf/awf+UT/9pCP/dxv/Nrv+pc//p2v9hAP+GPf9pBv+GP/9iA/9iCv+ocv+QSv/Zwv/AmP+8j/+d Xv/Mqv+lbf/Psf+IOv/7+P/Orv9nCP+SU/96Lv96J//j0f9nA/9eBP/bw//aw//k1P+STf/r3f/n 1v/Ipf+6jf+gZ/+eYv/Lqv/Mrf/gzP9zG/+xgP+ygf/XvP/gzf+JQf/Cm/+VVf+FOP/fzP+QTP/h zv/Xvv+LRv/Gn//s3/+4iv9kAf9rFP+tdv9rCP9lAf9yFv+pcf94KP+xe//Yv/94If9pCv+COf+Z Vf+ue/+7kf9XAP9nCv/q3f9iAf+9lP9uEf9oA//l1P+FN////f+ncv+OR//v5f/y5/+aX/+hY/9+ K/9hAf/59P+hZ/+IPv+fYv90Gv/Qs/+XVf9wE/+VVP9+Lf+YWP/eyf+mbv9+Mf96Jv91HP/HpP+8 kQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAAoACgA AAj/AAEIHEiwoMGDCBMqXMiwocOHECNKnEixosWLGDNq3Mixo8ePIEOKHEmypMmTKFOqXMmypcuQ AQYQCEBAZABOUnqM8FEQwQCBNGkKHPATQICjMoEimBlgaIFfYNAk2lTAKREIBQa86sKqigZdiEAU INBpABIPqmSaUbYiAhkCCUBAeNKIVihTPwnwWFZDjpYBvQBROvSigi0FIRBgEKXExR5XGgI5sIBn yQIMClA4ikAgUwyBB04JuDBLwJsxAiK1IWbFjgQBpZLIenRLQJphAiT5EsDGj4A6JhzIOECwwBY+ DK5MmtNEgAkcHS4AYyQgRYYJDbAIEBKiz4IztaA4zRFwA44DZsQHJqgwpQEVWG4oCIjDYE0WUCUE lMkQpkAyAVxwEIUemuzCARA0QDJKLp40NdABxwjwACoCECLfCal80UIlHwiggiF/FHCHAMEwIcAO OQggCAkSlmABCVUNFAAdRaCggAQFxCLCEAv8YIwXrSyCjCIzIOCBCCw0gIsaNhhhCQO8THCJDsIU NRABBmywgQFINSWGTAYMQNNPMSVwwgfFDCLAJwcYAEMeBtR00EwyytjUnQ7GFEQhR6yCSQc1HeUR XKSMEKdCAQEAOw== ------_=_NextPart_001_01CCADB4.7A1209EC Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhEgAUAPcAAP///+UAAO94AO92APGHG+5vAO5xAOQAAP/8+u5uAO50AO5yAO97AO91AO51 APa2dvFxdPB+Dv3t3esyOO93BvBnaOswOu99APCADfCBDvKZPv/+/Pzo0vGGG/7z9/3x9/7x9vnG k/F/Rf/+/e9hRPrXs/SpW/KPK/alqPGPJO1PUPnPrvjGkv727fSmUO93AP726P769falofzjyvjB ivF1c/B9AP719frasegaHugZF+97B/Fzc+1HRvrTrPOcPv3o6PSjT/GLIvnNnuo0MeszN/e7gP3r 2P3t2+osMfvVwvrMzf3v4fSkXfrSp/apqP748/N+gfetrf/9/frP0uxNQ+onK/zm0egaGe5rCvKX OukXHOkvB/KWN//9+vKLSeUCAOYAAP3u3POaQegUF/OcQ/i9gfvjyvFzdPKQLfCADOgUFPjHkvKN Jv/79/e0tPzp0+5vEOYAA+98APrZtvnRqOYAAexCQPGLJOklGuszK/rbue9ZW/739uoyMv3w4/jH ju1jAPONi+95FP/89/WpW/OJhutKAPCADvrVrfWoW/rKy//8/PKZPO9nZ+5OUf759O9xAPjCi+5R SPzfxO95AO55APa2b+5SVP///vKNKPB8BfWXmPve3fScePnJlvSlVPi4t/KSLvvdv/WsYv/+/ucL C/B/DPrNzvnEu/a2dffBffOEhvaipv738O1RTvBoaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAAAALAAAAAASABQA AAj/AAEIHDgwlYgsTaAQXDhQhqcflhz4YLiQU41MYjokoEFx4BI/iwC46WKgTkcAUzD1YASghSYC R06iMgVLIKUdD7ycZBWAh0BFWv6cBPAoAAQAQ8ZcGXqjyAFHTi5JGArAw4QAVVYQGjiiBBOGSPQc IEJlYSFSpQjSWTUpwBpBBBG0EYJgYAgTMFoFsPOq00A2kTRsECjpxBkAQLYEwGJIYKIIBT4JHEUB VAyBUQLISfIE0KYEjVwJDFIgDRyBHyyA4RJHwIsUHAYiEjBAFIs9OL4EsjHnwiAlBDMIqNRAgQAH DBgoWHAoT4VQfQSqWjBAAO0GBtS4IBEmQAAdd9BIFoFkBs8pDATKGJkBAAQKPlbI5FDxJiAAOw== ------_=_NextPart_001_01CCADB4.7A1209EC-- From flefauch@cisco.com Mon Nov 28 07:29: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 0501021F8B29 for ; Mon, 28 Nov 2011 07:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HuFSEW6C6idS for ; Mon, 28 Nov 2011 07:29:06 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 13D6B21F8B59 for ; Mon, 28 Nov 2011 07:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=10975; q=dns/txt; s=iport; t=1322494145; x=1323703745; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=NUfFK/RiS57qo220hwma9YvT7Y5qCp/4RDP5KzWU834=; b=XXZlAvUXW+v4J9fLvXCCtQsEzQ9aZRG0K77sD2RFALYH2Q1sDeWuPkKt zjFPLWesUdlaXtgV6+IGCaZ6MAAfBYjwh2+BaMLGkE7vbY/9FyNs+KYj4 Gy3GTTzOYnrtwl+hn5QcoAyFXnLAsCjJka7Hd+jNgkSEScUYWrNOALvU9 k=; X-IronPort-AV: E=Sophos;i="4.69,584,1315180800"; d="scan'208,217";a="60488371" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 28 Nov 2011 15:29:03 +0000 Received: from ams-flefauch-8711.cisco.com (ams-flefauch-8711.cisco.com [10.55.161.194]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pASFT2VB016084; Mon, 28 Nov 2011 15:29:02 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-172-589546299 From: Francois Le Faucheur In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF02E67ECC@ftrdmel0.rd.francetelecom.fr> Date: Mon, 28 Nov 2011 16:28:49 +0100 Message-Id: References: <8E09C72DBC577D489F13A71228C0B7BF02E67ECC@ftrdmel0.rd.francetelecom.fr> To: gilles.bertrand@orange.com, Niven-Jenkins Ben , Larry Peterson , Bruce Davie X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] Definitions inside PS and Framework 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: Mon, 28 Nov 2011 15:29:07 -0000 --Apple-Mail-172-589546299 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On 28 Nov 2011, at 10:59, wrote: >=20 > =20 > =20 > Some terms are not defined yet in the WG's drafts. Could you define = them inside the framework draft? >=20 > recursive request routing > iterative request routing Just FYI, Below are the definitions that had been included in early versions of = the "requirements" I-D (they are no longer in the latest versions of the = Requirements I-D).=20 Those may provide a good base for developing the definitions to be = included in the Framework I-D. " o Recursive CDNI request routing: When an Upstream CDN elects to redirect a request towards a Downstream CDN, the Upstream CDN can query the Downstream CDN Request Routing system via the CDNI Request Routing protocol (or use information cached from earlier similar queries) to find out how the Downstream CDN wants the request to be redirected, which allows the Upstream CDN to factor in the Downstream CDN response when redirecting the user agent. This approach is referred to as "recursive" CDNI request routing. Note that the Downstream CDN may elect to have the request redirected directly to a Surrogate inside the Downstream CDN, to the Request-Routing System of the Downstream CDN, to another CDN, or to any other system that the Downstream CDN sees as fit for handling the redirected request. o Iterative CDNI Request Routing: When an Upstream CDN elects to redirect a request towards a Downstream CDN, the Upstream CDN can base its redirection purely on a local decision (and without attempting to take into account how the Downstream CDN may in turn redirect the user agent). In that case, the Upstream CDN redirects the request to the request routing system in the Downstream CDN, which in turn will decide how to redirect that request: this approach is referred to as "iterative" CDNI request routing. " Cheers Francois > =20 >=20 > Cordialement, with kind regards, >=20 > =20 >=20 > >=20 > Gilles Bertrand > R&D, AudioVisual Delivery (AVD) > Content Network Architect > t=E9l. +33 (0) 145 29 89 46=20 > gilles.bertrand@orange.com > >=20 > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail-172-589546299 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi,

      On 28 Nov 2011, at 10:59, = <gilles.bertrand@orange.com&= gt; wrote:

       
       

      Some terms are not defined yet in the WG's = drafts. Could you define them inside the framework = draft?

         recursive request = routing
         iterative request = routing

      Ju= st FYI,

      Below are the definitions that had been = included in early versions of the "requirements" I-D (they are no longer = in the latest versions of the Requirements I-D). 
      Those = may provide a good base for developing the definitions to be included in = the Framework I-D.

      "
         o  Recursive = CDNI request routing: When an Upstream CDN elects to
          =   redirect a request towards a Downstream CDN, the Upstream CDN = can
            query the Downstream CDN Request Routing = system via the CDNI
            Request Routing protocol (or = use information cached from earlier
            similar = queries) to find out how the Downstream CDN wants the
          =   request to be redirected, which allows the Upstream CDN to = factor
            in the Downstream CDN response when = redirecting the user agent.
            This approach is = referred to as "recursive" CDNI request routing.
            = Note that the Downstream CDN may elect to have the request
        =     redirected directly to a Surrogate inside the Downstream = CDN, to
            the Request-Routing System of the = Downstream CDN, to another CDN,
            or to any other = system that the Downstream CDN sees as fit for
            = handling the redirected request.

         o  Iterative = CDNI Request Routing: When an Upstream CDN elects to
          =   redirect a request towards a Downstream CDN, the Upstream CDN = can
            base its redirection purely on a local = decision (and without
            attempting to take into = account how the Downstream CDN may in turn
            = redirect the user agent).  In that case, the Upstream CDN
        =     redirects the request to the request routing system in = the
            Downstream CDN, which in turn will decide = how to redirect that
            request: this approach is = referred to as "iterative" CDNI request
            = routing.
      "

      Cheers

      <= div>Francois


       

      Cordialement, with kind = regards,

       

      <image001.gif>
      R&D, = AudioVisual Delivery (AVD)
      Content Network Architect
      t=E9l. +33 = (0) 145 29 89 46 
       

      _______________________= ________________________
      CDNi mailing list
      CDNi@ietf.org
      Content-Type: multipart/alternative; boundary=f46d0408930da2372004b2e2f346 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: Tue, 29 Nov 2011 17:28:49 -0000 --f46d0408930da2372004b2e2f346 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry for the delayed response (with Thanksgiving holidays in US and all...= ) Thanks Kent for proposing merged text for a bunch of these requirements. I am mostly happy with all of your changes. I just have a couple of comments below. On Mon, Nov 21, 2011 at 6:21 PM, Kent Leung (kleung) wrot= e: > Hi Serge and Kevin. Comments below.**** > > ** ** > > *From:* cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] *On Behalf > Of *Serge Manning > *Sent:* Thursday, November 17, 2011 10:26 PM > *To:* Kevin J Ma > *Cc:* cdni@ietf.org > *Subject:* Re: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI**** > > ** ** > > Thanks for looking at the draft and providing feedback Kevin. See inline.= * > *** > > On Wed, Nov 16, 2011 at 12:24 PM, Kevin J Ma > wrote:**** > > Serge (and Kent), > > Some questions/comments on the requirements in the draft: > > LOG-A1/A2 seem like a good idea. They seem to mimic the existing > LOG-2/3 requirements, respectively, which seems fine, but do we need > to have separate requirements for these or can we just update LOG-2/3 > to include failures?**** > > That sounds fine.**** > > ** ** > > KL> Proposed update to LOG-2:**** > > **** > > LOG-2 [HIGH] The CDNI Logging interface shall provide logging of**** > > deliveries and incomplete deliveries to User Agents performed > by **** > > the Downstream CDN as**** > > a result of request redirection by the Upstream CDN.**** > > ** ** > > KL> Proposed update to LOG-3:**** > > ** ** > > LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging**** > > interface shall allow the Downstream CDN to report to the**** > > Upstream CDN logging for deliveries and incomplete deliveries = performed by the**** > > Downstream CDN itself as well as logging for deliveries**** > > performed by cascaded CDNs on behalf of the Downstream CDN.***= * > > ** > [Serge] I would just want to make it clear that incomplete deliveries should be cascaded up the chain, so a small modification to LOG-3. LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging**** interface shall allow the Downstream CDN to report to the**** Upstream CDN logging for deliveries and incomplete deliveries performed by the**** Downstream CDN itself as well as logging for deliveries *****and incomplete deliveries* performed by cascaded CDNs on behalf of the Downstream CDN. > > [Serge] KL> There=92s value to log a delete event. Should this be [MED] instead? > Proposed new requirement:**** > > ** ** > > ** ** > > LOG-## [MED] The CDNI Logging interface shall support logging of***= * > > deleted objects from the downstream CDN to the upstream**** > > CDN as a result of explicit delete requests on via the**** > > Control interface from the upstream CDN.**** > > ** > [Serge] I feel that its important for the logging interface to hold a complete record of basic transactions from the first version. To me, basic transactions are content add (i.e., delivery) and delete. Also, given that operators in ATIS are sensitive to delete operations, I would suggest to keep this as [HIGH]. Let me know your thoughts. Thanks. --=20 --Serge --f46d0408930da2372004b2e2f346 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry for the delayed response (with Thanksgiving holidays in US and all...= )

      Thanks Kent for proposing merged text for a bunch of t= hese requirements. I am mostly happy with all of your changes. I just have = a couple of comments below.

      On Mon, Nov 21, 2011 at 6:21 PM, Kent Leung = (kleung) <kleung@c= isco.com> wrote:

      Hi Serge and Kevin.=A0 Comments below.

      =A0<= /p>

      From: cdni-bounces@ietf.org [mailto:cdni-= bounces@ietf.org] On Behalf Of Serge Manning
      Sent: Thursday, November 17, 2011 10:26 PM
      To: Kevin J Ma<= br>Cc: cdni@ietf.= org
      Subject: Re: [CDNi] ATIS CDN Interconnect Reqs into IETF = CDNI

      =A0

      Thanks for looking at the dr= aft and providing feedback Kevin. See inline.

      <= div class=3D"im">

      On Wed, Nov 16, 2011 at 12:24 PM, Kevin J Ma <kevin.ma@azukis= ystems.com> wrote:

      Serge (and Kent),

      =A0Some questions/comments on the requirements in = the draft:

      =A0LOG-A1/A2 seem like a good idea. =A0They seem to mimic= the existing
      =A0LOG-2/3 requirements, respectively, which seems fine, b= ut do we need
      =A0to have separate requirements for these or can we just update LOG-2/3=A0to include failures?

      That sounds fine.

      =A0

      KL> Proposed update to= LOG-2:

      =A0

      LOG-2=A0=A0 [HIGH] The CDNI Logging interface shall provide log= ging of

      =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = deliveries and incomplete deliveries to User Agents performed by =

      =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0the Downstream CDN as

      =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 a result of requ= est redirection by the Upstream CDN.

      =A0<= /p>

      KL> Proposed update= to LOG-3:

      =A0<= /p>

      LOG-3=A0=A0 [MED] In t=
he case of cascaded CDNs, the CDNI Logging
      =A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 interface shall allow the Downstream CDN to report to the<=
/u>
      =A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 Upstream CDN logging for deliveries and incomplete de=
liveries performed by the
      =A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 Downstream CDN itself as well as logging for deliveries
      =A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 performed by cascaded CDNs on behalf of the Downstrea=
m CDN.

      <= /div>

      [Serge] I would just want= to make it clear that incomplete deliveries should be cascaded up the chai= n, so a small modification to LOG-3.
      LOG-3=A0=A0 [MED] In the case of cas=
caded CDNs, the CDNI Logging
      =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 interface shall allow the=
 Downstream CDN to report to the
      =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Upstr=
eam CDN logging for deliveries and incomplete deliveries performed by the
      =A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 Downstream CDN itself as well as logging for deliveri=
es and incomplete deliveries
      =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 performed b= y cascaded CDNs on behalf of the Downstream CDN.=A0

      =A0

      <= /div>


      =A0[Serge] <snip>

      KL> There=92s value to log a delete event. =A0Should this be = [MED] instead? Proposed new requirement:

      =A0<= /p>

      =A0

      =A0=A0=A0=A0 L=
OG-##=A0 [MED] The CDNI Logging interface shall support logging of
      =A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 deleted objects from the downstream CDN to t=
he upstream
      =A0=A0=A0=A0=A0=A0=A0=A0 =
=A0=A0=A0 CDN as a result of explicit delete requests on via the<=
/u>
      =A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 Control interface from the upstream CDN.=

      [Serge] I feel that its important for the logging interface to hold a comp= lete record of basic transactions from the first version. To me, basic tran= sactions are content add (i.e., delivery) and delete. Also, given that oper= ators in ATIS are sensitive to delete operations, I would suggest to keep t= his as [HIGH].=A0

      Let me know your thoughts.

      Tha= nks.

      --
      --Serge

      --f46d0408930da2372004b2e2f346-- From kleung@cisco.com Tue Nov 29 10:59: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 36ECB1F0C77 for ; Tue, 29 Nov 2011 10:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 AmlBhIIfo1ie for ; Tue, 29 Nov 2011 10:59:02 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id B49F31F0C67 for ; Tue, 29 Nov 2011 10:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kleung@cisco.com; l=22059; q=dns/txt; s=iport; t=1322593142; x=1323802742; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=g5T9KWNzXs1pulHV/hgNM5YrMN6YdJfnMFQoAK24/T8=; b=f/odVXXY/nnl5GO0uFSXTjfc+FoiRt/rJb1QUNVvPNH6HJsNQw3kYJRl eNV3jfpcZgHz7WrrR2t1fatzY6C8x+st7DONyzBIRByJwxLYpIg4gt5mY vGmqpx5fmlFcd8JSvh3nz1RYwHRJ1dIT+bGaXZ6WJqZifVKW0VRIS00A1 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwAAKcq1U6rRDoJ/2dsb2JhbABDgk2YFpAYgQWBcgEBAQQSAQkRA0kQAgEIEQQBAQsGEAcBBgEgJQkIAQEEEwgaoGgBnj6KO2MEiCeXCYdW X-IronPort-AV: E=Sophos;i="4.69,592,1315180800"; d="scan'208,217";a="16856254" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 29 Nov 2011 18:59:01 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pATIx1BJ026630; Tue, 29 Nov 2011 18:59:01 GMT Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Nov 2011 10:59:01 -0800 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_01CCAEC8.F49E31E7" Date: Tue, 29 Nov 2011 10:58:59 -0800 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5210619F61@xmb-sjc-235.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI Thread-Index: AcyuvF2BwmaxFxjAQJC8QgTkPrdYlAAC8v1g References: <291CC3F9E50E7641901A54E85D0977C651B6CD51F6@MAILR002.mail.lan><2979E38DD6FC6544B789C8DAD7BAFC521057DE57@xmb-sjc-235.amer.cisco.com> From: "Kent Leung (kleung)" To: "Serge Manning" X-OriginalArrivalTime: 29 Nov 2011 18:59:01.0153 (UTC) FILETIME=[F4DA2110:01CCAEC8] 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: Tue, 29 Nov 2011 18:59:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCAEC8.F49E31E7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Serge. No problem. Most of us are in the same situation. My response to your comments are marked as "KL>>" below. BTW, I'll let others have a chance to contribute their inputs for another week. Then I plan to make the changes to the requirements draft according to the WG discussions before publishing the next version. =20 From: Serge Manning [mailto:sergem913@gmail.com]=20 Sent: Tuesday, November 29, 2011 9:29 AM To: Kent Leung (kleung) Cc: Kevin J Ma; cdni@ietf.org Subject: Re: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI =20 Sorry for the delayed response (with Thanksgiving holidays in US and all...) =20 Thanks Kent for proposing merged text for a bunch of these requirements. I am mostly happy with all of your changes. I just have a couple of comments below. On Mon, Nov 21, 2011 at 6:21 PM, Kent Leung (kleung) wrote: Hi Serge and Kevin. Comments below. =20 From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Serge Manning Sent: Thursday, November 17, 2011 10:26 PM To: Kevin J Ma Cc: cdni@ietf.org Subject: Re: [CDNi] ATIS CDN Interconnect Reqs into IETF CDNI =20 Thanks for looking at the draft and providing feedback Kevin. See inline. On Wed, Nov 16, 2011 at 12:24 PM, Kevin J Ma wrote: Serge (and Kent), Some questions/comments on the requirements in the draft: LOG-A1/A2 seem like a good idea. They seem to mimic the existing LOG-2/3 requirements, respectively, which seems fine, but do we need to have separate requirements for these or can we just update LOG-2/3 to include failures? That sounds fine. =20 KL> Proposed update to LOG-2: =20 LOG-2 [HIGH] The CDNI Logging interface shall provide logging of deliveries and incomplete deliveries to User Agents performed by=20 the Downstream CDN as a result of request redirection by the Upstream CDN. =20 KL> Proposed update to LOG-3: =20 LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging interface shall allow the Downstream CDN to report to the Upstream CDN logging for deliveries and incomplete deliveries performed by the Downstream CDN itself as well as logging for deliveries performed by cascaded CDNs on behalf of the Downstream CDN. =20 [Serge] I would just want to make it clear that incomplete deliveries should be cascaded up the chain, so a small modification to LOG-3. LOG-3 [MED] In the case of cascaded CDNs, the CDNI Logging interface shall allow the Downstream CDN to report to the Upstream CDN logging for deliveries and incomplete deliveries performed by the Downstream CDN itself as well as logging for deliveries and incomplete deliveries performed by cascaded CDNs on behalf of the Downstream CDN.=20 =20 KL>> OK =20 =20 [Serge] =20 KL> There's value to log a delete event. Should this be [MED] instead? Proposed new requirement: =20 =20 LOG-## [MED] The CDNI Logging interface shall support logging of deleted objects from the downstream CDN to the upstream CDN as a result of explicit delete requests on via the Control interface from the upstream CDN. [Serge] I feel that its important for the logging interface to hold a complete record of basic transactions from the first version. To me, basic transactions are content add (i.e., delivery) and delete. Also, given that operators in ATIS are sensitive to delete operations, I would suggest to keep this as [HIGH].=20 =20 KL>> I don't have a strong opinion. So requirement will be [HIGH] unless others object. =20 Kent =20 Let me know your thoughts. =20 Thanks. =20 --=20 --Serge ------_=_NextPart_001_01CCAEC8.F49E31E7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

      Hi Serge.  No problem.  Most of us are in the same = situation.  My response to your comments are marked as = “KL>>” below.  BTW, I’ll let others have a = chance to contribute their inputs for another week.  Then I plan to = make the changes to the requirements draft according to the WG = discussions before publishing the next version.

       

      From:= = Serge Manning [mailto:sergem913@gmail.com]
      Sent: Tuesday, = November 29, 2011 9:29 AM
      To: Kent Leung = (kleung)
      Cc: Kevin J Ma; cdni@ietf.org
      Subject: Re: = [CDNi] ATIS CDN Interconnect Reqs into IETF = CDNI

       

      Sorry for = the delayed response (with Thanksgiving holidays in US and = all...)

       

      Thanks Kent for proposing merged text for = a bunch of these requirements. I am mostly happy with all of your = changes. I just have a couple of comments below.

      On Mon, Nov 21, 2011 at 6:21 PM, Kent Leung (kleung) = <kleung@cisco.com> = wrote:

      Hi Serge and Kevin.  Comments below.

       

      From:= = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Serge = Manning
      Sent: Thursday, November 17, 2011 10:26 = PM
      To: Kevin J Ma
      Cc: cdni@ietf.org
      Subject: Re: [CDNi] ATIS = CDN Interconnect Reqs into IETF CDNI

       <= /o:p>

      Thanks for = looking at the draft and providing feedback Kevin. See = inline.

      On Wed, Nov = 16, 2011 at 12:24 PM, Kevin J Ma <kevin.ma@azukisystems.com> = wrote:

      Serge (and = Kent),

       Some questions/comments on the requirements in the = draft:

       LOG-A1/A2 seem like a good idea.  They seem to = mimic the existing
       LOG-2/3 requirements, respectively, which = seems fine, but do we need
       to have separate requirements for = these or can we just update LOG-2/3
       to include = failures?

      That sounds = fine.

       

      KL> Proposed update to LOG-2:

       <= /o:p>

      LOG-2   [HIGH] = The CDNI Logging interface shall provide logging = of

               &= nbsp; deliveries and incomplete deliveries to User Agents performed by =

               &= nbsp; the Downstream CDN as

               &= nbsp; a result of request redirection by the Upstream = CDN.

       

      KL> Proposed update to LOG-3:

       

      LOG-3   [MED] In the =
case of cascaded CDNs, the CDNI =
Logging
           &nbs=
p;     interface shall allow the Downstream CDN to =
report to the
           &nbs=
p;     Upstream CDN logging for deliveries and =
incomplete deliveries performed by the
           &nbs=
p;     Downstream CDN itself as well as logging for =
deliveries
           &nbs=
p;     performed by cascaded CDNs on behalf of the =
Downstream CDN.

       

      [Serge] I would just want to make it clear that = incomplete deliveries should be cascaded up the chain, so a small = modification to LOG-3.

      LOG-3   [MED] In the case of =
cascaded CDNs, the CDNI Logging
             &nbs=
p;   interface shall allow the Downstream CDN to report to =
the
             &nbs=
p;   Upstream CDN logging for deliveries and incomplete =
deliveries performed by the
             &nbs=
p;   Downstream CDN itself as well as logging for deliveries =
and incomplete =
deliveries

                 = performed by cascaded CDNs on behalf of the Downstream = CDN. 

       

      KL>> OK

       

       

       [Serge] <snip>

       

      KL> There’s value to log a delete event.  Should this = be [MED] instead? Proposed new requirement:

       

       

           =
LOG-##  [MED] The CDNI Logging interface shall support logging =
of
           &nbs=
p;       deleted objects from the =
downstream CDN to the upstream
           &nbs=
p;       CDN as a result of explicit delete =
requests on via the
           &nbs=
p;       Control interface from the =
upstream =
CDN.

      [Serge] I feel that its important for the logging = interface to hold a complete record of basic transactions from the first = version. To me, basic transactions are content add (i.e., delivery) and = delete. Also, given that operators in ATIS are sensitive to delete = operations, I would suggest to keep this as = [HIGH]. 

       

      KL>> I don’t have a strong opinion.  So requirement = will be [HIGH] unless others object.

       

      Kent

       

      Let me = know your thoughts.

       

      Thanks.

       

      -- =
      --Serge

      ------_=_NextPart_001_01CCAEC8.F49E31E7-- From bdavie@cisco.com Tue Nov 29 23:58: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 11CE811E8089 for ; Tue, 29 Nov 2011 23:58:39 -0800 (PST) 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=[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 lN9ezzZdC8o5 for ; Tue, 29 Nov 2011 23:58:38 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A9D3D11E8081 for ; Tue, 29 Nov 2011 23:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bdavie@cisco.com; l=3338; q=dns/txt; s=iport; t=1322639918; x=1323849518; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=u82jVEYODiIpUboJvhTMnjjEMQ6x8byrgNJRQbTS8Ps=; b=IoBZWFQm0jiigWpNJKSFwUYAqHNO2hjVoqzy5cHAppnu/NQwRG4fFLm2 ZEtYA5YDhlY1gVmXsXn5moEOqlUogkfB5JeX7C0yD7uDRfBNDg/gYyHse VoN64wDkYOa9ytrvS6E53vYqRoV2K/vtv5ywftOiby7TVrYknmRFkgX3s w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlcJAHLh1U6rRDoI/2dsb2JhbABEJoInqDSBBYFyAQEBAQIBEgFmEAsEQlcGEyKHZZl5AZ48ij1jBIgojC+FQ4xr X-IronPort-AV: E=Sophos;i="4.69,596,1315180800"; d="scan'208,217";a="16971159" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 30 Nov 2011 07:58:37 +0000 Received: from [10.21.52.8] ([10.21.52.8]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAU7wZDf024205; Wed, 30 Nov 2011 07:58:37 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-28-715772049 From: Bruce Davie In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF02E67ECC@ftrdmel0.rd.francetelecom.fr> Date: Tue, 29 Nov 2011 21:32:35 -0500 Message-Id: References: <8E09C72DBC577D489F13A71228C0B7BF02E67ECC@ftrdmel0.rd.francetelecom.fr> To: "" X-Mailer: Apple Mail (2.1084) Cc: cdni@ietf.org Subject: Re: [CDNi] Definitions inside PS and Framework 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, 30 Nov 2011 07:58:39 -0000 --Apple-Mail-28-715772049 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 28, 2011, at 4:59 AM, = wrote: > =20 > Some terms are not defined yet in the WG's drafts. Could you define = them inside the framework draft? >=20 > recursive request routing > iterative request routing > =20 >=20 I think you will find that these are defined in = draft-davie-cdni-framework-01.txt, with text lifted from an earlier = version of the requirements draft. Bruce --Apple-Mail-28-715772049 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii gilles.bertrand@orange.com&= gt; <gilles.bertrand@orange.com&= gt; wrote:

       

      Some terms are not defined yet in the WG's = drafts. Could you define them inside the framework = draft?

         recursive request = routing
         iterative request = routing

       

      I = think you will find that these are defined = in draft-davie-cdni-framework-01.txt, with text lifted from an = earlier version of the requirements = draft.

      Bruce

      = --Apple-Mail-28-715772049-- From gilles.bertrand@orange.com Wed Nov 30 00:40: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 5965321F867F for ; Wed, 30 Nov 2011 00:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 0Ht2+zpt7FDx for ; Wed, 30 Nov 2011 00:40:27 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8C59E21F85DB for ; Wed, 30 Nov 2011 00:40:27 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 74724340003; Wed, 30 Nov 2011 09:40:26 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 65EFF340001; Wed, 30 Nov 2011 09:40:26 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Nov 2011 09:40:26 +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_01CCAF3B.B4B56CC7" Date: Wed, 30 Nov 2011 09:40:14 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF02EB4E22@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Definitions inside PS and Framework draft Thread-Index: AcyvNfEpiU4apnUFQUe23aKj8Ya35QABX2GA References: <8E09C72DBC577D489F13A71228C0B7BF02E67ECC@ftrdmel0.rd.francetelecom.fr> From: To: X-OriginalArrivalTime: 30 Nov 2011 08:40:26.0171 (UTC) FILETIME=[B50310B0:01CCAF3B] Cc: cdni@ietf.org Subject: Re: [CDNi] Definitions inside PS and Framework 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, 30 Nov 2011 08:40:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCAF3B.B4B56CC7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My mistake. They are indeed defined, I must have checked in the former = version instead of version 01. =20 =20 Gilles =20 De : Bruce Davie [mailto:bdavie@cisco.com]=20 Envoy=E9 : mercredi 30 novembre 2011 03:33 =C0 : BERTRAND Gilles RD-CORE-ISS Cc : cdni@ietf.org Objet : Re: Definitions inside PS and Framework draft =20 =20 On Nov 28, 2011, at 4:59 AM, = wrote: =20 Some terms are not defined yet in the WG's drafts. Could you define them = inside the framework draft? recursive request routing iterative request routing =20 I think you will find that these are defined in = draft-davie-cdni-framework-01.txt, with text lifted from an earlier = version of the requirements draft. =20 Bruce =20 ------_=_NextPart_001_01CCAF3B.B4B56CC7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

      My mistake. They are indeed defined, I must have checked in the = former version instead of version 01.

       

       

      Gilles

       

      De : Bruce = Davie [mailto:bdavie@cisco.com]
      Envoy=E9 : mercredi 30 = novembre 2011 03:33
      =C0 : BERTRAND Gilles = RD-CORE-ISS
      Cc : cdni@ietf.org
      Objet : Re: = Definitions inside PS and Framework = draft

       

       

      On = Nov 28, 2011, at 4:59 AM, <gilles.bertrand@orange.com= > <gilles.bertrand@orange.com= > wrote:



       =

      Some terms = are not defined yet in the WG's drafts. Could you define them inside the = framework draft?=

         = recursive request routing=

         = iterative request routing=

       =

      I think you will find that these = are defined in draft-davie-cdni-framework-01.txt, with text lifted = from an earlier version of the requirements draft.

       

      Bruce

       

      ------_=_NextPart_001_01CCAF3B.B4B56CC7--