From nobody Mon Sep 1 19:53:21 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAD81A6FAB for ; Mon, 1 Sep 2014 19:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFfGirD5AQd3 for ; Mon, 1 Sep 2014 19:53:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F182D1A6FAA for ; Mon, 1 Sep 2014 19:53:18 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMA08461; Tue, 02 Sep 2014 02:53:17 +0000 (GMT) Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 2 Sep 2014 03:53:16 +0100 Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml702-chm ([10.193.5.72]) with mapi id 14.03.0158.001; Mon, 1 Sep 2014 19:53:05 -0700 From: Linda Dunbar To: "cdni@ietf.org" Thread-Topic: Is it feasible to extend the CDNi mechanisms to manage virtual network functions in multiple DCs? Thread-Index: Ac/GWQQJbY9gMBwwS/OtpgVnKXCeqQ== Date: Tue, 2 Sep 2014 02:53:04 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645DDF229@dfweml701-chm> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.96.173.234] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F645DDF229dfweml701chm_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Wm62VcdBT61vXPrHorFYNrS4ZRg Subject: [CDNi] Is it feasible to extend the CDNi mechanisms to manage virtual network functions in multiple DCs? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 02 Sep 2014 02:53:20 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F645DDF229dfweml701chm_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Very often resources from one single Data Center can't meet the service req= uirement. So it is desirable for operators to utilize resources from multip= le data centers for those services. The "Media Cloud Federation" shown in draft-aazam-cdni-inter-cloud-architec= ture-00 is one example. Many features specified by CDNi, such as "footprint & Capability advertisem= ent interface", "logging", etc., can be very useful. Is it feasible to exte= nd those CDNi protocols for those services? Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F645DDF229dfweml701chm_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Very often resources from one single Data Center can&#= 8217;t meet the service requirement. So it is desirable for operators to ut= ilize resources from multiple data centers for those services.

The “Media Cloud Federation” shown in draf= t-aazam-cdni-inter-cloud-architecture-00 is one example.

 

Many features specified by CDNi, such as “footpr= int & Capability advertisement interface”, “logging”,= etc., can be very useful. Is it feasible to extend those CDNi protocols fo= r those services?

 

Thanks, Linda Dunbar

 

 

--_000_4A95BA014132FF49AE685FAB4B9F17F645DDF229dfweml701chm_-- From nobody Wed Sep 3 08:50:37 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DBA1A701A; Wed, 3 Sep 2014 08:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sk9KBANE3Rj9; Wed, 3 Sep 2014 08:50:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 042411A876F; Wed, 3 Sep 2014 08:50:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140903155000.18104.5189.idtracker@ietfa.amsl.com> Date: Wed, 03 Sep 2014 08:50:00 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/q8DNdwrl1Wy5sWBC9zVRG3d34UM Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-04.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 15:50:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : CDNI Control Interface / Triggers Authors : Rob Murray Ben Niven-Jenkins Filename : draft-ietf-cdni-control-triggers-04.txt Pages : 41 Date : 2014-09-03 Abstract: This document describes the part of the CDN Interconnection Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it invalidates or purges metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-control-triggers-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Sep 3 09:12:24 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8741A0AE0 for ; Wed, 3 Sep 2014 09:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iNGp1gFSfAM4 for ; Wed, 3 Sep 2014 09:12:11 -0700 (PDT) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FCBA1A87B0 for ; Wed, 3 Sep 2014 09:12:00 -0700 (PDT) Received: from EXB04CAM.corp.velocix.com ([169.254.1.180]) by EXC00CAM.corp.velocix.com ([172.18.4.40]) with mapi id 14.02.0347.000; Wed, 3 Sep 2014 17:11:58 +0100 From: Rob Murray To: "cdni@ietf.org" Thread-Topic: Comments on draft-ietf-cdni-control-triggers-03 Thread-Index: AQHPx5HJgkBO7KNld0WvYJtk+Dvf/g== Date: Wed, 3 Sep 2014 16:11:58 +0000 Message-ID: References: <49C77373835C5A479BC2A84B2A1D66BDDA2D41E3@EXB01-MLT.corp.velocix.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [81.134.152.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Fw95K0XAMBLMcUnP3D1WJAqTwl0 Subject: Re: [CDNi] Comments on draft-ietf-cdni-control-triggers-03 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 03 Sep 2014 16:12:21 -0000 Hi all, We've posted an update to the Triggers draft... URL: http://www.ietf.org/internet-drafts/draft-ietf-cdni-control-tr= iggers-04.txt Status: https://datatracker.ietf.org/doc/draft-ietf-cdni-control-trigg= ers/ Htmlized: http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-04 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-control-tri= ggers-04 It still needs some text on capabilities advertisement, we'll add that when= we have guidance on the format and info needed. Apart from that, we believ= e it's ready for final review / WGLC. Changes in this revision are ... Added a way to cancel a trigger without deleting the Trigger Status Resourc= e, as per Kevin's comments and the discussion in Toronto. To do this, the d= CDN POSTs a cancel command to the all-triggers collection. We also added 'c= ancelling' and 'cancelled' states for the Trigger Status Resources. The JSON encoding section was a bit of a mess, and there was no proper defi= nition of the content of a POST used to create a trigger. So we renamed "Tr= igger Request" to "Trigger Specification" (since it appears in the message = used to create the trigger and in the status resource), and described the b= ody of the POST as a "Trigger Command" - which can now be a "trigger" or a = "cancel". Only the URL of the uCDN's 'all triggers' collection now needs to be config= ured in the uCDN. The other collections, and all of the Trigger Status reso= urces, are linked from there. Addressed comments from Francois, detailed responses are inline below. Added loop detection/avoidance. Updated the IANA section to be in the proper format. Various textual changes to try to improve readability, updated references. Cheers, Rob & Ben. On 4 Jul 2014, at 16:41, Francois Le Faucheur (flefauch) wrote: > Hi Rob, >=20 > I read the new version till end of section 4. Below are some comments. >=20 > Cheers >=20 > Francois >=20 >=20 > *** in section 1:=20 > * remove the reproduction of actual requirements (for consistency with = other documents). > * reader of the present document may not be familiar with meaning of =93= Medium=94 and =93High=94, so I=92d suggest: > OLD: > " > Requirements for CI/T > are the "High" and "Medium" priority requirements for the CI identified i= n section 4 of [I-D.ietf-cdni-requirements],, reproduced here for convenien= ce: >=20 > CI-1 [HIGH] The CDNI Control interface shall allow the Upstream > ... =20 > " > NEW: > " > Section 4 of [I-D.ietf-cdni-requirements] identifies the requirements spe= cific to the CI interface. The subset of these requirements applicable to t= he CI/T interafce are CI-1 to CI-6. > " Done. > *** Section 2: > "Requests to invalidate and purge metadata or content apply to all > variants of that data with a given URI.=94 > What do you mean by =93variants=94 here? I meant a variant as defined in RFC2616 ... variant A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations is termed a `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation. But the httpbis RFCs seem to have dropped that term, the just stick with "r= epresentations". So I've changed the text to ... "Multiple representations of an HTTP resource may share the same URL. Req= uests to invalidate and purge metadata or content apply to all resource rep= resentations with matching URLs." > *** RFC2119 statements: > I think you need to walk through the doc and ensures there are MUST/SHOUL= D/MAY for all necessary element of behaviour. > For example, I see: > * "To trigger activity in the dCDN, the uCDN will POST to the collection= of Trigger Status Resources.=94 and > * "To trigger activity in the dCDN, the uCDN creates a new Trigger Statu= s Resource by posting to the dCDN's collection of uCDN's Trigger Status Res= ources.=94 > but I don=92t see any =93MUST POST=94. > Can you plan a review and make sure you add MUST/SHOULD/MAY wherever it i= s needed? >=20 > As another example, section 2 primarily uses descriptive text (=93dCDN do= es this=94, "it will do that=94) but has a few RFC2119 statements ("uCDN MA= Y GET=94. "uCDN MAY DELETE=94). Sincxe section 2 is an overview, I woudl su= ggest using only descriptive text and makingh sure all RFC2119 statements a= re moved to the more detailed sections. Ben and I went through the doc reviewing normative language. Hopefully it's= in a better state now. > *** section 2.1: > s/Timing of triggered activity is under the dCDN's control/Timing of the = execution of the triggered activity is under the dCDN's control/ Done. > *** section 2.1: > "Invalidate and purge triggers MUST be applied to all data acquired > before the trigger was created in the dCDN. The dCDN may apply the > triggers to data acquired after trigger creation.=94 > why do we have a =93MUST=94 and then a =93may=94 (instead of a =93MAY=94)= ? > This seems like another example of a needed RFC2119 cleanup. Changed to "MAY". > *** section 2.1: > s/Otherwise, the dCDN may pre-position/Otherwise, there is a risk that th= e dCDN pre-positions/ Done > *** section 3: > =93 > o Complete - Trigger Status Resources representing activity that > completed successfully, or for which no further status updates > will be made by the dCDN. > =93 > I think "for which no further status updates will be made by the dCDN=94 = means that is in the =93processed=94 status defined in section 4, right? > If yes, it may be worth mentioning the word =93processed=94 here to help = reconciliate this list of collection with the various status defined in sec= tion 4. e.g.: > =93 > o Complete - Trigger Status Resources representing activity that > completed successfully, or for which no further status updates > will be made by the dCDN (.i.e that is already processed). > " Done. > *** section 4: > "The interface is > intended to be independent of the set of activities defined now, or > that may be defined in future.=94 > I had to re-read this a couple of times to understand what you meant. I t= hink it can be phrased better, perhaps indicating it is independent of the = =93types of triggers=94 (as opposed to "set of activities) and replacing = =93now=94 by =93specified in the present document=94.=20 It wasn't really adding anything, so I just deleted the paragraph. > *** section 4: > the terms =93client=94 and =93server=94 are used out of teh blue and need= to be related to uCDN and dCDN. Perhaps you could do something similar to = what we did in cdni-logging i.e. we specified teh =93Server-side=94 and =93= client-side=94 behavior and stated that a dCDN implementation of the interf= ace MUST support the server-side and an uCDN implementation of the interfa= ce MUST support the client-side and an uCDN.=20 I've changed client/server for uCDN/dCDN. > *** section 4: > =93Since only one CDN > can be authoritative for a given item of metadata or content, this > requirement means there cannot be any "loops" in trigger requests > between CDNs." > This may deserve some more explanations. > When you say =93there cannot be=94 does it mean =93it will not happen bec= ause it is prevented by the law of physics so you don=92t have to worry abo= ut it=94? or does it mean =93you need to make sure it does not happen=94?=20 I meant "prevented by the law of physics", but my physics teachers would be= ashamed of me! If two dCDNs have a shared upstream, and delegate that uCDN content to each= other, and they're not careful about where triggers come from (or maybe in= a more complicated mesh), a loop in triggers might happen. So, added something similar to the 'cdn-path' in the RR draft to make sure = it can't happen. > *** section 4.1: > "if it is malformed > or the uCDN does not have sufficient access rights it MAY reject the > request immediately.=94 > shoudl this be just a =93MAY=94? what else can it do with a malformed req= uest? It can accept the trigger, but create a 'failed' Trigger Status resource wi= th an appropriate error description. I've clarified that in the doc. > *** section 4.1: > s/If the dCDN is not able to track triggered activity/If the dCDN is not = able to track the execution of triggered activity/ Done. > *** section 4.1: > s/If the dCDN is able to track triggered activity/If the dCDN is able to = track the execution of triggered activity/ Done. > *** section 4.2: > s/described in the following sections/described in section 4.2.1 and 4.2.= 2/ Done. > *** section 4.3: > "If an "active" Trigger Status Resource is deleted, the dCDN MAY stop > processing the triggered activity. =93 > MAY or SHOULD? SHOULD, done. > *** section 4.3: > OLD: > =93 > it is recommended that the uCDN's polling interval is half > the time after which records for completed activity will be > considered stale. > =93 > NEW: > =93 > the uCDN SHOULD set its polling interval to a value that is at most half > the time after which records for completed activity will be > considered stale. > =93 Changed to "less than the time...". > *** Section 4.5: > =93 > If a surrogate affected by a trigger is offline in the dCDN, or the > dCDN is unable to pass a trigger request on to any of its cascaded > dCDNs; the dCDN SHOULD report an error if the request is abandoned. > Otherwise, it SHOULD keep the trigger in state "pending" or "active" > until it's acted upon or the uCDN chooses to cancel it. > =93 > It is not obvious if =93Otherwise=94 refers to =93if a surrogate=85=94 or= =93if the request is abandoned=94. I think it is teh latter. In which case= , you may want to structure the text with bullets like: > =93 > If a surrogate affected by a trigger is offline in the dCDN, or the > dCDN is unable to pass a trigger request on to any of its cascaded > dCDNs: > * if the request is abandoned by the dCDN, the dCDN SHOULD report an er= ror > * Otherwise, it SHOULD keep the trigger in state "pending" or "active" > until it's acted upon or the uCDN chooses to cancel it. > " Done. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Editorial Nits: >=20 >=20 > *** Abstract: > s/CDN Interconnect/CDN Interconnection/ > s/re-validate or purge/re-validates or purges/ Done. > *** section 1: > s/Problem scope/problem scope/ Done. > *** section 2: > s/a request for dCDN/a request for the dCDN/ Done. > *** Sometimes you use =93the uCDN=94 and sometimes =93uCDN=94 (e.g. ", uC= DN has access=94). I suggest always using =93the uCDN=94.=20 Done. > *** I thought the aprostrophe for the possessive case only applied to hum= ans and not things, so that one should say =93dCDN control=94 and not =93dC= DN=92s control=94.=20 Hmm, I'm pretty sure things can have apostrophes too. There are probably so= me rules around the difference between "under dCDN control" and "under the = dCDN's control". > *** section 4.1: > s/it MUST indicate that indicate/it MUST indicate/ Done. >=20 >=20 > On 3 Jul 2014, at 20:38, Rob Murray wrote: >=20 >> Hi all, >>=20 >> Kevin, thank you for the review. All very good comments, sorry it took m= e so long to get to them. >>=20 >> Responses inline below, and I've posted an "03" version of the draft... >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers/ >> http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-03 (eventua= lly) >>=20 >> Most comments have been addressed, including a couple of earlier ones fr= om Francois about broken formatting. >>=20 >> What I've not dealt with is the idea to separate trigger deletion and ca= ncellation - in order to make it possible to check the status of a deleted = trigger. It'd make the interface a little more complicated, and I'm not sur= e what status the dCDN could usefully report. (Also, I ran out of time for = making edits!) Let's discuss further in Toronto. >>=20 >> Cheers, >> Rob. >>=20 >> On 6 May 2014, at 23:15, Kevin Ma J wrote: >>=20 >>> Hi All, >>>=20 >>> Per the chairs' request for a detailed review of the triggers draft, >>> I've compiled a list of comments below. >>>=20 >>> thanx. >>>=20 >>> -- Kevin J. Ma >>>=20 >>> comments: >>>=20 >>> - General: imo, an article in front of uCDN/dCDN (i.e., the uCDN/dCDN) >>> makes for easier reading. >>=20 >> Done. >>=20 >>> - General: There are quite a few lower case "must"s (17), "shall"s (14)= , >>> "should"s (7), and "may"s (36) in the document. Are they all >>> intentionally non-normative?=20 >>=20 >> Hopefully sorted now, though I MAY have gone too far! >>=20 >>> - section 2: Should cancelling a trigger and removing a trigger status >>> be separated in some way? Using DELETE for both means >>> that if I wanted to cancel a trigger, I would have no way >>> to get status on the cancelled trigger, since the status >>> resource would be removed at the same time, and delete >>> does not return a status, per the example in section 7.2.5 >>=20 >> See above, it could be a good idea but it'd be good to talk it through a= bit further (sorry I left this update too late to do it on the list before= the deadline). >>=20 >>> - section 2/4.1: In step 2 of figure 1, it mentions authentication as >>> does section 4.1, but section 7 and 9 provide no >>> guidance on either the authentication mechanism or >>> what precisely is being authenticated. Presumably we >>> are authenticating that it is a known uCDN making the >>> request for metadata/content that is known to be owned >>> by that uCDN? Should we state that? >>>=20 >>> Do we have a suggestion (e.g., SSL client auth, HTTP >>> basic/digest auth, etc.) for authentication method? >>=20 >> I've rewritten the Security Considerations section now (based on what's = in the Logging draft, as agreed in London). >>=20 >>> - section 2.1: I found the wording of this sentance a little confusing. >>>=20 >>> "If uCDN wishes to invalidate or purge content, then immediately >>> preposition replacement content at the same URLs, it must ensure the >>> dCDN has completed the invalidate/purge before initiating the >>> prepositioning. If it fails to do that and the requests overlap, and >>> dCDN passes the triggers on to a further dCDN in a cascade, that CDN >>> may preposition content that has not yet been invalidated/purged in >>> its uCDN." >>>=20 >>> Perhaps something like: >>>=20 >>> "If uCDN wishes to invalidate or purge content, then immediately >>> preposition replacement content at the same URLs, it must ensure the >>> dCDN and all cascaded dCDNs have completed the invalidate/purge >>> before initiating the prepositioning, otherwise, a cascaded dCDN may >>> attempt to preposition content that has not yet been invalidated/purg= ed >>> in its uCDN." >>=20 >> Done. >>=20 >>>=20 >>> - section 3: I would break this into two sentances: >>>=20 >>> "The dCDN must present a different set of Trigger Status Resources to >>> each interconnected uCDN, only Trigger Status Resources belonging to >>> a uCDN shall be visible to it." >>>=20 >>> i.e.: >>>=20 >>> "The dCDN must present a different set of Trigger Status Resources to >>> each interconnected uCDN. Only Trigger Status Resources belonging to >>> a uCDN shall be visible to it." >>=20 >> Done (and reworded a bit). >>=20 >>> - section 3: This is the first mention of expiry. Perhaps a reference >>> to Section 4.4? >>>=20 >>> "This collection lists all >>> uCDN triggers that have been accepted by dCDN, and have not yet been >>> deleted by uCDN or expired and removed by dCDN." >>=20 >> Done. >>=20 >>> - section 4.1: These are the first mention of etime and mtime, perhaps >>> there should be a reference to Section 5.2, or some >>> type of explaination on what etime > mtime means. >>>=20 >>> I am not sure about using of etime > mtime as an indicator. >>> If mtime < now and etime < now, but still etime > mtime, >>> it would seem to imply that the activity may be complete, >>> but I don't think that is the intent? >>>=20 >>> Should there be some normative language stating that if >>> etime > mtime, the uCDN must update the status, and the >>> dCDN must update mtime =3D now and etime > mtime? >>>=20 >>> "If dCDN is not able to track triggered activity, it MAY indicate that >>> it has undertaken to complete the activity but will not report >>> completion or any further errors. To do this, it must set the >>> trigger status to "complete", with an estimated completion time in >>> the future ("etime" greater than "mtime")." >>=20 >> I got rid of that and added an extra state, "processed" - it's like "com= plete", but means the dCDN can't provide a success/fail result. (With a rec= ommendation that an estimated completion time should be provided in that ca= se.) >>=20 >>> - section 4.4: Why 24 hours? Seems fast? >>>=20 >>> "It >>> is recommended that Trigger Status Resources are automatically >>> deleted 24 hours after they become completed or failed." >>=20 >> I made it "not less than 24 hours". >>=20 >>> - section 4.4: comma after: >>>=20 >>> "If any part of the trigger request fails, " >>>=20 >>> comma before: >>>=20 >>> ", if the trigger is still running for some URLs >>> or Patterns in the trigger request." >>>=20 >>> perhaps clarify "cascaded" dCDNs: >>>=20 >>> "pass a trigger request on to any of its affected cascaded dCDNs" >>=20 >> Done. >>=20 >>> - section 5.2: AbsoluteTime is a Unix Epoch, so should be UTC. >>> I found the phrase "Time is local to dCDN" confusing as >>> I first assumed "local" was referencing timezone, but I >>> think "local" is just related to unsynchronized clocks? >>> Perhaps: "Time is determined by the dCDN"? >>=20 >> Done. >>=20 >>> - section 5.4: links is a "List of Relationships". Why not just URLs? >>> If the trigger collection can only reference trigger >>> statuses, then why does it need typed relationships? >>> The use of a relationship here seems overly complex? >>>=20 >>> Is relationship standard JSON terminology? Should there >>> be a reference to the acknowledged work of Mike Kelly? >>=20 >> Yes, you're right. It had all got too complicated and bloated. So it's j= ust a list of URLs now, I got rid of all that JSON relationship stuff. >>=20 >>> - section 6: There is a note about MI dependency. >>> Is it just for PatternMatch? >>=20 >> It was, but the dependency wasn't necessary so I've got rid of it. >>=20 >>> - section 6.1.6: "ralationship" -> "relationship" >>=20 >> Fixed. >>=20 >>> - section 6.1.6/6.1.7: I think it would be helpful to define the >>> Relationship and Link objects the same way as >>> all the other JSON objects, e.g.: >>>=20 >>> How are the keys in the _links dictionary >>> determined? And how is their meaning known? >>> The key "self" seems to have a specific meaning? >>> It is essentially a reserved keyword? Are there >>> other reserved keywords (e.g., "Trigger"), and >>> do they have to be registered somewhere? >>>=20 >>> Relationship: >>> Key: _links >>> Description: List of related objects? >>> Type: Array of LinkUnions >>> Mandatory: Yes >>>=20 >>> LinkUnion: >>> Key: ??? >>> Description: List of related objects? >>> Type: Array of LinkUnions >>> Mandatory: No. >>>=20 >>> Key: ??? >>> Description: related objects? >>> Type: Link >>> Mandatory: No. >>>=20 >>> Link: >>> Key: href >>> Description: URI of the addressable object being referenced >>> Type: URL >>> Mandatory: Yes >>>=20 >>> Key: type >>> Description: Type of the referenced object >>> Type: MIME Media Type >>> Mandatory: No >>=20 >> I did that - then decided to get rid of it all, as above. It was only us= ed in the collections, and they're now just lists of links. >>=20 >>> - section 7: There are no examples with "base" or "links". I have an >>> idea of how "base" might be used, but I don't know what >>> the purpoes of "links" is. Can we add an example? >>>=20 >>> "URLs are under control" -> "URLs are under the control" >>=20 >> "links" has gone. >>=20 >>> - section 7.2.1/7.2.2: I don't know where the key "Trigger" came from? >>> Is it derived from some known object, or is it >>> randomly selected (and somehow registered)? >>=20 >> In the "01" draft it was the "relationship type", and I'd not documented= the change properly. But it's gone now, just a list of URLs. >>=20 >>> - section 7.2.5: Would there be value in returning the status on delete= ? >>=20 >> Probably a good idea. Let's wrap it up with discussion on the delete/can= cel question. >>=20 >>> - section 9: In the first sentance below, I interpret "access" as the >>> ability to read (GET) a status object or collection. It >>> does not necessarily imply to me who can issue a new >>> trigger request? In the second sentance, it says it can >>> only "affect" it's own content, which I guess implies >>> that only it can affect it's own content, as another uCDN >>> affecting it's content would violate this rule? Should >>> we make that more explicit? >>>=20 >>> "The dCDN must ensure that each uCDN only has access to its own >>> Trigger Status Resources." >>>=20 >>> "The dCDN must ensure that activity triggered by uCDN only affects >>> metadata or content originating from that uCDN." >>>=20 >>> e.g., update the second sentance to something like: >>>=20 >>> "The dCDN must ensure that activity triggered by uCDN only affects >>> metadata or content originating from that uCDN, and that no other >>> uCDN may trigger activity that affects another uCDN's metadata or >>> content." >>=20 >> Hopefully the re-written section 9 is clearer. >>=20 >>> - random: The mention of only affecting a uCDN's own content made me >>> think of the DNS diamond scenario. Do we believe that the >>> Content URLs described in section 5.1.1 are sufficient to >>> ensure this, or is there a caveat for the diamond case? >>>=20 >>> "The dCDN must ensure that activity triggered by uCDN only affects >>> metadata or content originating from that uCDN." >>=20 >> Done. >>=20 >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From nobody Thu Sep 4 02:29:56 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC12D1A00E9 for ; Thu, 4 Sep 2014 02:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.468 X-Spam-Level: X-Spam-Status: No, score=-3.468 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqHKihY986Ow for ; Thu, 4 Sep 2014 02:29:53 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17EF11A00BB for ; Thu, 4 Sep 2014 02:29:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BJB28479; Thu, 04 Sep 2014 09:29:51 +0000 (GMT) Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 4 Sep 2014 10:29:50 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.231]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Thu, 4 Sep 2014 17:29:41 +0800 From: "Xialiang (Frank)" To: Linda Dunbar Thread-Topic: Re: Is it feasible to extend the CDNi mechanisms to manage virtual network functions in multiple DCs? Thread-Index: Ac/IIsBvfF3VLVcYTCerwF2wwGi8pQ== Date: Thu, 4 Sep 2014 09:29:41 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.200] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F12ACDEBB2SZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/cy6MiVL-jeieQpv7kNETQC4a1BM Cc: "cdni@ietf.org" Subject: Re: [CDNi] Is it feasible to extend the CDNi mechanisms to manage virtual network functions in multiple DCs? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 09:29:55 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F12ACDEBB2SZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Linda, Interesting insight! >From my personal view, with the fast development of cloud technologies and = markets, the cloud federation and cloud interconnection issues are becoming= more and more important and urgent. The corresponding network technologies= involve VPN connections, Data Center interconnection, federation among mul= tiple SPs, etc. One key issue of them is about the information exchange between different D= C or SP to support their federation. The information can be related to loca= tions, capabilities, logging, authentication, etc. And by my understanding, CDNi architecture and its interfaces are very usef= ul for the above information exchange requirements. But these issues seems = to be not in the CDNI WG charter now. B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F12ACDEBB2SZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Linda,

Interesting insight!=

 

From my personal view, with the= fast development of cloud technologies and markets, the cloud federation a= nd cloud interconnection issues are becoming more and more important and ur= gent. The corresponding network technologies involve VPN connections, Data Center interconnection, federation among mul= tiple SPs, etc.

 

One key issue of them is about = the information exchange between different DC or SP to support their federa= tion. The information can be related to locations, capabilities, logging, a= uthentication, etc.

 

And by my understanding, CDNi a= rchitecture and its interfaces are very useful for the above information ex= change requirements. But these issues seems to be not in the CDNI WG charte= r now.

 

B.R.

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F12ACDEBB2SZXEMA502MBSchi_-- From nobody Thu Sep 4 09:12:48 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2F41A8970 for ; Thu, 4 Sep 2014 09:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id us5Oys07C-S9 for ; Thu, 4 Sep 2014 09:12:44 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5C2D1A8A5E for ; Thu, 4 Sep 2014 09:11:18 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id pn19so12154814lab.32 for ; Thu, 04 Sep 2014 09:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=uzm7jQVlNDaK5mYaSVFeCOsP/XI7X404Y5HPtbN6nCE=; b=ThX3Rew00/Sy06DTKDCIuyP6g41CqmNhgVeIpU+wAadrnV1nsOIgPcQAVTrB6tSPW/ ZX8Go4sv+VEIRgKzS/hed/olEUSyT8GCIYjDN5vSrdM1QVPEwU1mnk4ZIEHbp54/ruv5 75o7a7LAUudIopkOQD1R9YBhuJEIY2OoWGrcMYIHfmWel6AK3gIhzJNBIkhTZhXCyJaR DTLKHvTBlqwlhd5Z3g5jCEhzF47IsAcashsE0sPCdkImvxL1wWHKrYLwaSXyN+ofMGJb FiqURP3QaAPxiuBl+QbdeuFiVYHgPlnmSInv2bPjW0cTlZxH2wCXzViGJhERXcwocTKP cHNw== X-Received: by 10.152.205.5 with SMTP id lc5mr5644919lac.45.1409847076566; Thu, 04 Sep 2014 09:11:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.33.50 with HTTP; Thu, 4 Sep 2014 09:10:36 -0700 (PDT) In-Reply-To: References: From: Mohammad Aazam Date: Thu, 4 Sep 2014 21:10:36 +0500 Message-ID: To: cdni@ietf.org Content-Type: multipart/alternative; boundary=001a1133a6ae2fbe7405023f9af3 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/pQJANiwpMmsFDE81VZNugK8lrkQ Subject: Re: [CDNi] CDNi Digest, Vol 46, Issue 1 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 04 Sep 2014 16:12:46 -0000 --001a1133a6ae2fbe7405023f9af3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes indeed. Specially in the case of storage space and similar facilities. But as you know, cloud computing can provide further services, which data-centers may not, so the scope would become limited. On Wed, Sep 3, 2014 at 12:00 AM, wrote: > Send CDNi mailing list submissions to > cdni@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/cdni > or, via email, send a message with subject or body 'help' to > cdni-request@ietf.org > > You can reach the person managing the list at > cdni-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of CDNi digest..." > > Today's Topics: > > 1. Is it feasible to extend the CDNi mechanisms to manage > virtual network functions in multiple DCs? (Linda Dunbar) > > > ---------- Forwarded message ---------- > From: Linda Dunbar > To: "cdni@ietf.org" > Cc: > Date: Tue, 2 Sep 2014 02:53:04 +0000 > Subject: [CDNi] Is it feasible to extend the CDNi mechanisms to manage > virtual network functions in multiple DCs? > > Very often resources from one single Data Center can=E2=80=99t meet the s= ervice > requirement. So it is desirable for operators to utilize resources from > multiple data centers for those services. > > The =E2=80=9CMedia Cloud Federation=E2=80=9D shown in > draft-aazam-cdni-inter-cloud-architecture-00 is one example. > > > > Many features specified by CDNi, such as =E2=80=9Cfootprint & Capability > advertisement interface=E2=80=9D, =E2=80=9Clogging=E2=80=9D, etc., can be= very useful. Is it > feasible to extend those CDNi protocols for those services? > > > > Thanks, Linda Dunbar > > > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > > --=20 "Nothing is permanent in this wicked world - not even our troubles." - Charlie Chaplin. Regards, Mohammad Aazam --001a1133a6ae2fbe7405023f9af3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes indeed. Specially in the case of storage space and similar=20 facilities. But as you know, cloud computing can provide further=20 services, which data-centers may not, so the scope would become limited.


On W= ed, Sep 3, 2014 at 12:00 AM, <cdni-request@ietf.org> wr= ote:
Send CDNi mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cdni@ietf.org<= /a>

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/cdni or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cdni-r= equest@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cdni-own= er@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of CDNi digest..."

Today's Topics:

=C2=A0 =C2=A01. Is it feasible to extend the CDNi mechanisms to manage
=C2=A0 =C2=A0 =C2=A0 virtual network functions in multiple DCs? (Linda Dunb= ar)


---------- Forwarded message ----------
From:=C2=A0Linda Dunbar = <linda.dunbar@huawei.com&= gt;
To:=C2=A0"cdni@ietf.org&qu= ot; <cdni@ietf.org>
Cc:=C2=A0
Date:=C2=A0Tue, 2 Sep 2014 02:53:04 +0000
Subject:=C2=A0[CD= Ni] Is it feasible to extend the CDNi mechanisms to manage virtual network = functions in multiple DCs?

Very often resources from one single Data Center can=E2=80=99t meet the = service requirement. So it is desirable for operators to utilize resources = from multiple data centers for those services.

The =E2=80=9CMedia Cloud Federation=E2=80=9D shown in draft-aazam-cdni-i= nter-cloud-architecture-00 is one example.

=C2=A0

Many features specified by CDNi, such as =E2=80=9Cfootprint & Capabi= lity advertisement interface=E2=80=9D, =E2=80=9Clogging=E2=80=9D, etc., can= be very useful. Is it feasible to extend those CDNi protocols for those se= rvices?

=C2=A0

Thanks, Linda Dunbar

=C2=A0

=C2=A0


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




--
"Nothing is permanent in this wicked world - not even our troubles.&q= uot; - Charlie Chaplin.
Regards,
Mohammad Aazam
--001a1133a6ae2fbe7405023f9af3-- From nobody Fri Sep 5 07:41:27 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB6E1A06FB for ; Fri, 5 Sep 2014 07:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itOIoUvXHZuD for ; Fri, 5 Sep 2014 07:41:24 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 52BD11A06F6 for ; Fri, 5 Sep 2014 07:41:23 -0700 (PDT) Received: from aputeaux-554-1-122-217.w92-154.abo.wanadoo.fr ([92.154.81.217] helo=[192.168.1.132]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1XPuhW-0006Q0-9P; Fri, 05 Sep 2014 15:41:22 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Niven-Jenkins In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645DDF229@dfweml701-chm> Date: Fri, 5 Sep 2014 15:41:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2ECEBE84-F23D-42A5-9ADD-C37B208CC269@niven-jenkins.co.uk> References: <4A95BA014132FF49AE685FAB4B9F17F645DDF229@dfweml701-chm> To: Linda Dunbar X-Mailer: Apple Mail (2.1878.6) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/eRITs67HmPSVieROmGEVQwaKMmc Cc: "cdni@ietf.org" Subject: Re: [CDNi] Is it feasible to extend the CDNi mechanisms to manage virtual network functions in multiple DCs? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 05 Sep 2014 14:41:26 -0000 Hi Linda, I haven't read the draft you mention below. The CDNI interfaces defined = to date are basically HTTP APIs carrying CDNI specific data. There may be some reuse possible, e.g. footprint/capability but it = probably depends on how much overlap there is between the Media Cloud = Federation's view of footprint/capability and CDNI's definition/use of = that data. Likewise with logging, the logging format defined is similar to a web = server access log so it depends how well that maps to the sorts of logs = you'll be generating. The logging "API" is just an Atom feed. Without reading the draft you mention my gut says you'll probably end up = defining so much of your own cloud-specific data to exchange that even = if you start with the CDNI specifications, you'll end up with something = that looks completely different so you may be better defining your own = cloud-specific APIs but YMMV. Ben On 2 Sep 2014, at 03:53, Linda Dunbar wrote: > Very often resources from one single Data Center can=92t meet the = service requirement. So it is desirable for operators to utilize = resources from multiple data centers for those services. > The =93Media Cloud Federation=94 shown in = draft-aazam-cdni-inter-cloud-architecture-00 is one example. > =20 > Many features specified by CDNi, such as =93footprint & Capability = advertisement interface=94, =93logging=94, etc., can be very useful. Is = it feasible to extend those CDNi protocols for those services? > =20 > Thanks, Linda Dunbar > =20 > =20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Tue Sep 16 16:24:18 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCB61A6F49; Tue, 16 Sep 2014 16:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GL60lK9fUxHc; Tue, 16 Sep 2014 16:24:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 417111A03C3; Tue, 16 Sep 2014 16:24:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140916232415.16287.43585.idtracker@ietfa.amsl.com> Date: Tue, 16 Sep 2014 16:24:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/O6NiI6o3mUAUZEvRjmFrvRZnEoc Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 16 Sep 2014 23:24:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : URI Signing for CDN Interconnection (CDNI) Authors : Kent Leung Francois Le Faucheur Ray van Brandenburg Bill Downey Michel Fisher Filename : draft-ietf-cdni-uri-signing-01.txt Pages : 39 Date : 2014-09-16 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-uri-signing-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-uri-signing-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/