From RMurray@velocix.com Thu Aug 1 09:56:11 2013 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 76EA821E80D7 for ; Thu, 1 Aug 2013 09:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.605 X-Spam-Level: * X-Spam-Status: No, score=1.605 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 VsXbO4vPxgeM for ; Thu, 1 Aug 2013 09:56:06 -0700 (PDT) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) by ietfa.amsl.com (Postfix) with ESMTP id D29D721E8117 for ; Thu, 1 Aug 2013 09:56:01 -0700 (PDT) Received: from EXC01-MLT.corp.velocix.com (172.18.4.41) by EXC00CAM.corp.velocix.com (172.18.4.40) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 1 Aug 2013 17:55:59 +0100 Received: from EXB01-MLT.corp.velocix.com ([169.254.2.197]) by exc01-mlt.corp.velocix.com ([172.18.4.41]) with mapi id 14.02.0318.001; Thu, 1 Aug 2013 17:55:59 +0100 From: Rob Murray To: "cdni@ietf.org" Thread-Topic: Comments on draft-choi-cdni-control-init-bootstrapping-01 Thread-Index: AQHOjtf/q1LT4O1/REuZ61JgTjsDsg== Date: Thu, 1 Aug 2013 16:55:59 +0000 Message-ID: <684B9758-CCB6-4E33-BDB6-6FC8B5CDE889@velocix.com> References: , <49C77373835C5A479BC2A84B2A1D66BD8E4A9838@EXB01-MLT.corp.velocix.com> In-Reply-To: <49C77373835C5A479BC2A84B2A1D66BD8E4A9838@EXB01-MLT.corp.velocix.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_684B9758CCB64E33BDB66FC8B5CDE889velocixcom_" MIME-Version: 1.0 Subject: [CDNi] Comments on draft-choi-cdni-control-init-bootstrapping-01 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, 01 Aug 2013 16:56:11 -0000 --_000_684B9758CCB64E33BDB66FC8B5CDE889velocixcom_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgYWxsLCB0aGUgY29tbWVudHMgSSBwcm9taXNlZCB0byBjb3B5IHRvIHRoZSBsaXN0Li4uDQoN CihUYWVzYW5nLCBhcG9sb2dpZXMgZm9yIHNlbmRpbmcgdGhlbSBzbyBsYXRlLikNCg0KDQpSb2Iu DQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBSb2IgTXVycmF5IDxybXVycmF5 QHZlbG9jaXguY29tPG1haWx0bzpybXVycmF5QHZlbG9jaXguY29tPj4NCkRhdGU6IDMxIEp1bHkg MjAxMyAxODoyMTowNSBDRVNUDQpUbzogw9bFwrvzIDxjaG9pdHNAZXRyaS5yZS5rcjxtYWlsdG86 Y2hvaXRzQGV0cmkucmUua3I+Pg0KQ2M6ICJlYXN0c2t5QHNvbGJveC5jb208bWFpbHRvOmVhc3Rz a3lAc29sYm94LmNvbT4iIDxlYXN0c2t5QHNvbGJveC5jb208bWFpbHRvOmVhc3Rza3lAc29sYm94 LmNvbT4+LCBCZW4gTml2ZW4tSmVua2lucyA8YmVuQHZlbG9jaXguY29tPG1haWx0bzpiZW5AdmVs b2NpeC5jb20+Pg0KU3ViamVjdDogUmU6IFJlcXVlc3QgZm9yIHlvdXIgZmVlZGJhY2sgb24gQm9v dHN0cmFwcGluZyBkcmFmdA0KDQpIaSBUYWVzYW5nLA0KDQpJJ3ZlIGp1c3QgaGFkIGEgbG9vayAt IEknbSBub3Qgc3VyZSB0aGUgdHJpZ2dlcnMgaW50ZXJmYWNlIGlzIGFwcHJvcHJpYXRlIGZvciB0 aGlzLg0KDQpUaGUgYWltIG9mIHRoaXMgcGFydCBvZiB0aGUgQ29udHJvbCBpbnRlcmZhY2UgaXMg Zm9yIG9uZSBDRE4gdG8gZmluZCBvdXQgaG93IHRvIHRhbGsgdG8gYW5vdGhlciBvbmUsIGluY2x1 ZGluZyB3aGljaCBVUkxzIGl0IHNob3VsZCB1c2UgdG8gZmluZCBSSS9NSS9GQ0ksIHdoaWNoIGFj cXVpc2l0aW9uIHByb3RvY29scyBpdCBzdXBwb3J0IGV0YyBldGMuLi4gaXQncyBhYm91dCAiZ2V0 dGluZyIgaW5mbyBmcm9tIHRoZSBvdGhlciBDRE4uDQoNClRoZSB0cmlnZ2VycyBpbnRlcmZhY2Ug aXMgZGVzaWduZWQgZm9yIG9uZSBDRE4gdG8gYXNrIHRoZSBvdGhlciB0byBkbyBzb21ldGhpbmcu Li4gaXQncyBhYm91dCAicHV0dGluZyIgYSByZXF1ZXN0IGludG8gdGhlIG90aGVyIENETi4NCg0K SSB0aGluayAgeW91ciBkcmFmdCBjYW4ganVzdCBkZWZpbmUgYSBzZXQgb2YgcHJvcGVydGllcyBh bmQgYSBjb250YWluZXIgZm9yIHRoZW0gdGhhdCBjYW4gYmUgZmV0Y2hlZCBmcm9tIGEgIndlbGwg a25vd24iIFVSTCBvbiB0aGUgb3RoZXIgQ0ROLCB0aGVyZSdzIG5vIG5lZWQgZm9yIHR3byB3YXkg Y29tbXVuaWNhdGlvbi4NCg0KWW91IHByb2JhYmx5IG5lZWQgdHdvIHNldHMgb2YgcHJvcGVydGll cywgdGhlIHRoaW5ncyB1Q0ROIG5lZWRzIHRvIGtub3cgYWJvdXQgZENETiwgYW5kIHRoZSB0aGlu Z3MgZENETiBuZWVkcyB0byBrbm93IGFib3V0IHVDRE4gLSBhbmQgdGhlc2UgY2FuIGxpdmUgYXQg ZGlmZmVyZW50IHdlbGwta25vd24gVVJMcyAobWVldGluZyBDTlRMLTYpLg0KDQpUaGUgZENETiBv cGVyYXRvciB3b3VsZCB0ZWxsIGRDRE4gdGhlIHNpbmdsZSB3ZWxsLWtub3duIFVSTCBkZXNjcmli aW5nIHVDRE4ncyBpbnRlcmZhY2VzLCBhbGxvd2luZyBkQ0ROIHRvIGZpbmQgb3V0IGFsbCBhYm91 dCB1Q0ROLiBUaGUgc2FtZSB3b3VsZCBoYXBwZW4gb24gdUNETiBmb3IgaXQgdG8gZmluZCBvdXQg YWJvdXQgZENETi4gVGhlbiB0aGUgdHdvIGNhbiB0YWxrLg0KDQpUbyB0ZXJtaW5hdGUgYW4gaW50 ZXJjb25uZWN0LCB0aGUgQ0ROIGNhbiBqdXN0IHJlbW92ZSBpdHMgYm9vdHN0cmFwcGluZyBkb2N1 bWVudCAoQ05UTC01KS4NCg0KVG8gYmUgYWxpZ25lZCB3aXRoIHRoZSBvdGhlciBpbnRlcmZhY2Vz LCB0aGUgcHJvcGVydGllcyBzaG91bGQgcHJvYmFibHkgbGl2ZSBpbiBKU09OIGZvcm1hdCBiZSBm ZXRjaGVkIG92ZXIgaHR0cChzKSwgIGFuZCBzaG91bGQgaGF2ZSBjYWNoZS1jb250cm9sIHNldHRp bmdzIHRoYXQgbWFrZSBzdXJlIHRoZSBvdGhlciBDRE4gcmVndWxhcmx5IHJlZnJlc2hlcyBpdCBp biBjYXNlIHRoaW5ncyBjaGFuZ2UuDQoNCkkgY2FuJ3Qgc3BvdCBhbnkgcmVxJ3MgdGhhdCB3b3Vs ZG4ndCBiZSBtZXQgYnkgdGhpcyBtdWNoIHNpbXBsZXIgaW50ZXJmYWNlLg0KDQpDaGVlcnMsDQpS b2IuDQoNCkZyb206IMPWxcK78yA8Y2hvaXRzQGV0cmkucmUua3I8bWFpbHRvOmNob2l0c0BldHJp LnJlLmtyPj4NCkRhdGU6IFdlZG5lc2RheSwgMzEgSnVseSAyMDEzIDEwOjM4DQpUbzogUm9iIE11 cnJheSA8cm11cnJheUB2ZWxvY2l4LmNvbTxtYWlsdG86cm11cnJheUB2ZWxvY2l4LmNvbT4+DQpD YzogImVhc3Rza3lAc29sYm94LmNvbTxtYWlsdG86ZWFzdHNreUBzb2xib3guY29tPiIgPGVhc3Rz a3lAc29sYm94LmNvbTxtYWlsdG86ZWFzdHNreUBzb2xib3guY29tPj4NClN1YmplY3Q6IFJlcXVl c3QgZm9yIHlvdXIgZmVlZGJhY2sgb24gQm9vdHN0cmFwcGluZyBkcmFmdA0KDQpEZWFyIFJvYiwN Cg0KSGF2ZSB5b3UgaGFkIHRpbWUgdG8gdGFrZSBsb29rIGF0IHRoZSBib290c3RyYXBwaW5nIGRy YWZ0IDAxIHZlcnNpb24/DQpXaGVuIEkgcHJlc2VudCB0aGUgc3RhdHVzIG9mIHRoaXMgZHJhZnQg dG9tb3Jyb3csIEkgd291bGQgbGlrZSB0byBtZW50aW9uIHNvbWV0aGluZyBhYm91dCB0aGUgZGly ZWN0aW9uIHRvIHRoZSBmdXR1cmUgcHJvZ3Jlc3MuDQpJZiB5b3UgaGF2ZSBhbnkgb3BpbmlvbiBv biB0aGUgZGlyZWN0aW9uLCBJIHdvdWxkIGJlIGhhcHB5IHRvIGhlYXIgYWJvdXQgaXQuICBCZXNp ZGVzIHRoZSBkaXJlY3Rpb24sIEkgd2lsbCBhbHNvIGFwcHJlY2lhdGUgaWYgeW91IHByb3ZpZGUg bWUgYW55IHRlY2huaWNhbCBjb21tZW50cy4gIE1hbnkgdGhhbmtzIGluIGFkdmFuY2UuDQoNCkJl c3QgcmVnYXJkcywNClRhZXNhbmcNCg== --_000_684B9758CCB64E33BDB66FC8B5CDE889velocixcom_ Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable
Hi all, the comments I promised to copy to the list...

(Taesang, apologies for sending them so late.)


Rob.

Begin forwarded message:

From: Rob Murray <rmu= rray@velocix.com>
Date: 31 July 2013 18:21:05 CEST
To: =C3=D6=C5=C2=BB=F3 <choi= ts@etri.re.kr>
Cc: "eastsky@solbox.com" <eastsky@solbox.com&g= t;, Ben Niven-Jenkins <ben@velocix.co= m>
Subject: Re: Request for your feedback on Bootstrapping draft=

Hi Taesang,

I've just had a look - I'm not sure the triggers interface is appropri= ate for this.

The aim of this part of the Control interface is for one CDN to find o= ut how to talk to another one, including which URLs it should use to find R= I/MI/FCI, which acquisition protocols it support etc etc... it's about &quo= t;getting" info from the other CDN.

The triggers interface is designed for one CDN to ask the other to do = something... it's about "putting" a request into the other CDN.

I think  your draft can just define a set of properties and a con= tainer for them that can be fetched from a "well known" URL on th= e other CDN, there's no need for two way communication.

You probably need two sets of properties, the things uCDN needs to kno= w about dCDN, and the things dCDN needs to know about uCDN - and these can = live at different well-known URLs (meeting CNTL-6).

The dCDN operator would tell dCDN the single well-known URL describing= uCDN's interfaces, allowing dCDN to find out all about uCDN. The same woul= d happen on uCDN for it to find out about dCDN. Then the two can talk.

To terminate an interconnect, the CDN can just remove its bootstrappin= g document (CNTL-5).

To be aligned with the other interfaces, the properties should probabl= y live in JSON format be fetched over http(s),  and should have cache-= control settings that make sure the other CDN regularly refreshes it in cas= e things change.

I can't spot any req's that wouldn't be met by this much simpler inter= face.

Cheers,
Rob.

From: =C3=D6=C5=C2=BB=F3 <choits@etri.re.kr>
Date: Wednesday, 31 July 2013 10:38=
To: Rob Murray <rmurray@velocix.com>
Cc: "eastsky@solbox.com" <eastsky@solbox.com>
Subject: Request for your feedback = on Bootstrapping draft

Dear Rob,

 

Have you had time to take look = at the bootstrapping draft 01 version?

When I present the status of th= is draft tomorrow, I would like to mention something about the direction to= the future progress.  

If you have any opinion on the = direction, I would be happy to hear about it.  Besides the direction, = I will also appreciate if you provide me any technical comments.  Many= thanks in advance.

 

Best regards,=

Taesang

--_000_684B9758CCB64E33BDB66FC8B5CDE889velocixcom_-- From flefauch@cisco.com Thu Aug 1 10:12:52 2013 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 9D16621E8219 for ; Thu, 1 Aug 2013 10:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Kj7Y+vbI1o1 for ; Thu, 1 Aug 2013 10:12:47 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 1F0BB11E8127 for ; Thu, 1 Aug 2013 10:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=241; q=dns/txt; s=iport; t=1375377162; x=1376586762; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=4eHA3Wf3aNTswYamWVe92gNKIyZuRe3E056fiJ9g7/4=; b=AQKPtAHNG6V4AlDyLb4qcTZvs/iQ2V+DNVh4InKDip2D9yi4R+zaWRLJ HyOAV21dCiwZl0XrIPyPL9yPr/XaFYVwwvjAUMXsomh7TCG2ssDVEmsS3 1SsF1XyqbFtri8hDD8sqGKKOwrjKKAVLaE+EWUNyIC3uOIc4OhQRJFknN g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMOV+lGtJXG//2dsb2JhbABbgwaBBb5HgR0WdIImAQQ6UQEqFEInBBuICJlQoEKPVoNRcwOpLYMUgio X-IronPort-AV: E=Sophos;i="4.89,795,1367971200"; d="scan'208";a="242350379" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 01 Aug 2013 17:12:40 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r71HCeR7026095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Aug 2013 17:12:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 12:12:40 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Tentative agreement to add a "URI Signing" deliverable to the CDNI charter Thread-Index: AQHOjtpTMHbI5puLwE+jMqXjZ8uA5Q== Date: Thu, 1 Aug 2013 17:12:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.110.191] Content-Type: text/plain; charset="us-ascii" Content-ID: <3C91BFF2DC9054469CE17A8DE7006428@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Tentative agreement to add a "URI Signing" deliverable to the CDNI charter 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, 01 Aug 2013 17:12:52 -0000 Hi everyone, We've reached a tentative agreement during today's session to add a "URI Si= gning" deliverable to the CDNI charter. If you have comments or concerns about that, please express those on the li= st. Cheers Francois= From mcaulfie@cisco.com Thu Aug 1 13:41:20 2013 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 A8A2D11E815E for ; Thu, 1 Aug 2013 13:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 X1Mcp2WhSU2k for ; Thu, 1 Aug 2013 13:41:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0721911E810E for ; Thu, 1 Aug 2013 13:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2403; q=dns/txt; s=iport; t=1375389675; x=1376599275; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=n5acPZb+/kj6IL2nJt9Tmkuvroj2Zz6SwZ7zerHfhEA=; b=QxxnI0j0c6fsEwUuGofdMaN4QG3WaQd85CFmatbu4XTwwjAfV3fIF9cR 6mzn+anPdYnJbmPMEl5BDFYR4xi2JknWBhtjiORhsPcm+nx9TcxoWYVxZ MIotsHbDlbPRqE8OtpDItzvEaMnwfNcev8BY+09YjJEFJQzeIzIHaU6TV M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAKzH+lGtJXG8/2dsb2JhbABbgwY1UL5MgR0WdIImAQQ6UQEqFEImAQQbiAiZZ6Azj1aDUXMDqS2DFIIq X-IronPort-AV: E=Sophos;i="4.89,796,1367971200"; d="scan'208";a="242546665" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2013 20:41:05 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r71Kf50R009593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Aug 2013 20:41:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.140]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 15:41:05 -0500 From: "Matt Caulfield (mcaulfie)" To: "cdni@ietf.org" Thread-Topic: New Text for Framework on URI Rewriting Thread-Index: Ac6O92zds42pB4QjSEezI1Jqeu28Ag== Date: Thu, 1 Aug 2013 20:41:05 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] New Text for Framework on URI Rewriting 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, 01 Aug 2013 20:41:20 -0000 Hi everyone, Based on comments this week regarding the URI Rewriting section of the CDNI= Framework document I have put together a revised section which aims to tou= ch on the key points more clearly. Please share your feedback on the text b= elow. If it is suitable, we can incorporate into the next revision of draft= -ietf-cdni-framework. Thanks, Matt Metadata & URI Rewriting When using HTTP redirection, content URIs will be rewritten between uCDNs a= nd dCDNs. In the case of cascaded CDNs, content URIs may be rewritten multi= ple times between uCDN and dCDN. URI rewriting poses a special challenge fo= r the implementation of some CDNI interfaces. Consider the simple case: a single uCDN and dCDN. This section refers to th= e URI requested of the uCDN as the "uCDN URI" and the URI requested of the = dCDN as the "dCDN URI".=20 Any CDNI interface which relies on content URIs must state explicitly which= URI is to be used - the dCDN URI or the uCDN URI. For example, in the case= of the Logging Interface, each log message may reference a content URI. In= the case of the Metadata Interface, the dCDN must query for the uCDN for m= etadata based on a content URI. For all CDNI interfaces, the dCDN should translate any dCDN URIs to uCDN UR= Is before interacting with the uCDN. For logging, this approach requires th= e dCDN to translate any dCDN URIs in its log messages into uCDN URIs. For m= etadata, this approach requires the dCDN to translate any dCDN URIs into uC= DN URIs before querying the uCDN for metadata.=20 In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and there= fore is capable of translating from uCDN URI to dCDN URI and vice versa. In= iterative mode, an out-of-band agreement instructs the uCDN and dCDN how t= o translate from uCDN URI to dCDN URI and vice versa. In either mode, the d= CDN is capable of translating dCDN URIs into uCDN URIs before interacting w= ith the uCDN. Note that even in the DNS redirection case, some URI rewriting is still nec= essary. For example, any metadata which references the immediately upstream= CDN (such as content acquisition metadata) should be rewritten as the meta= data is passed between CDNs. However, given that DNS redirection does not c= hange the content URI, many of the concerns addressed above with HTTP redir= ection do not apply. =20 From mcaulfie@cisco.com Thu Aug 1 14:07:33 2013 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 E1F9F11E8165 for ; Thu, 1 Aug 2013 14:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02Voli5qA7wC for ; Thu, 1 Aug 2013 14:06:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 96DE721F9F85 for ; Thu, 1 Aug 2013 14:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3211; q=dns/txt; s=iport; t=1375391081; x=1376600681; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=M5ZcDgcQP+oriD+jU2ASRTeB8L5BH5cTPAD0mw724Bs=; b=VRozZFByEHHdpxCsYfdFGG4Yc2gGupVFtCgqF8fs2cCwz3uxQ7GUI3io 6n6uDNWI89LMr/4PV6Z/4G+KkvHSjHQKZTFrfaiDTEkbMjakqMGkCvb+n 6xhj3d2WckoPh1oU8PtmIZQNq5ZF9lo5OuYjofxbLvepv/kJYi+8tyHNn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAF7M+lGtJXHA/2dsb2JhbABRCoMGNVC+TIEdFnSCJgEEJxM/EgEqDgZCJgEECgQNiAi6II4/BoERMR+DAXMDqS2DFIFxOQ X-IronPort-AV: E=Sophos;i="4.89,796,1367971200"; d="scan'208";a="242446375" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 01 Aug 2013 21:01:24 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r71L1NC5028758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 1 Aug 2013 21:01:24 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.140]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 16:01:23 -0500 From: "Matt Caulfield (mcaulfie)" To: "cdni@ietf.org" Thread-Topic: Notes from today's Informal Metadata Meeting Thread-Index: Ac6O+kJH9tPwbFxNTdSsD84MCa171w== Date: Thu, 1 Aug 2013 21:01:23 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C92104BB464@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Notes from today's Informal Metadata Meeting 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, 01 Aug 2013 21:07:37 -0000 Attendees: Matt Caulfield, Kent Leung, Kevin Ma, Ray van Brandenburg, Rob M= urray "Mandatory-to-enforce" The metadata draft defines a property in the GenericMetadata object for ind= icating that a particular piece of metadata is mandatory to enforce. We dis= cussed whether or not there is ever a case where this flag would be set to = false and came up with a few examples related to optional optimizations tha= t a CSP may desire but are not strictly required. We also questioned whethe= r or not the value of this property should be static (i.e. defined by the R= FC or standard which also defines the metadata it corresponds to). For exam= ple, the URI signing draft defines a new metadata object for URI signing. S= hould the CSP/uCDN be allowed to make URI signing mandatory to enforce for = some content but not other content? Or should mandatory to enforce be defin= ed by the URI signing draft as always "true" for URI signing metadata? We f= elt that mandatory-to-enforce SHOULD be static and its value SHOULD be take= n from the same standard which defines the corresponding metadata. --> Matt to clarify this point in the Metadata draft IANA Registries The IANA Considerations section in the Metadata draft is not yet filled in.= We discussed the required registries for Metadata - such as a registry for= GenericMetadata types, Protocol types, Location types, etc.=20 --> Kevin to identify and fill in IANA Considerations Authentication for Acquisition The current Source object contains a placeholder for authentication. We dis= cussed a simple username/password based authentication method in this conte= xt and agreed to name the auth object "CredentialsAuth". This object could = be used for HTTP Basic, FTP, or other transfer methods that require a usern= ame and password. The Source object could point to a CredentialsAuth object= or to any other type of Auth object yet to be defined. As such, an IANA re= gistry is planned for tracking Auth methods. --> Matt to add CredentialsAuth object to Metadata Authentication for Delivery We were unsure what sort of authentication, if any, should be supported by = the base metadata draft. We agreed to send a separate email to the list inq= uiring on this topic. --> Matt to send email on expect authentication techniques Query Parameters Modification In the working group meeting on Tuesday, it was noted that the current abil= ity to remove query parameters when caching a resource is not sufficient fo= r base interoperability. Instead a more flexible scheme is needed which ins= tructs a dCDN to remove certain query parameters before caching, acquiring,= or looking up metadata for a piece of a content. --> Matt to update query parameter modification text Acquisition Source object We discussed some ambiguity in the Source object section. It is not current= ly clear how a dCDN should really use a Source object to acquire content fr= om the uCDN, especially for the HTTP redirection case. --> Matt to clarify Source section Editors notes A number of editors notes identify missing areas of the draft. --> Above items either address or obviate all current editors notes From mcaulfie@cisco.com Thu Aug 1 14:08:36 2013 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 8B96A21F8A50 for ; Thu, 1 Aug 2013 14:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NEUrlpcWJH9 for ; Thu, 1 Aug 2013 14:08:15 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 0119B11E8171 for ; Thu, 1 Aug 2013 14:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=529; q=dns/txt; s=iport; t=1375391290; x=1376600890; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=039QksOXI7DcKmvN1pKXUjpLsKicedEkork3XWRlk9I=; b=MDLTWVuReYKsHud9WJo5RIjw6G7TyIbXnLYPgou8a2QUvCZWA4zYvE+l OVk6Hrv036ZT85R6/wdNtTzgtxHrafvd9rsZuJr1anm0rMQGeklOtxHt2 r5KaIKmKln1niy4nP28c9B4oyvxvsf+wPcxcLHU9a/LV+OiP6Avs5AIVP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI7N+lGtJXHB/2dsb2JhbABbgwaBBb5MgR0WdIImAQQ6UQEqDgZCJgEEG4gImXmgMI9WUIMBcwOUAgyVH4MUgio X-IronPort-AV: E=Sophos;i="4.89,796,1367971200"; d="scan'208";a="242473909" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 01 Aug 2013 21:07:30 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r71L7Tpu008584 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Aug 2013 21:07:29 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.140]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 16:07:29 -0500 From: "Matt Caulfield (mcaulfie)" To: "cdni@ietf.org" Thread-Topic: Authentication for Acquisition and Delivery Thread-Index: Ac6O+xvM51WBNEJrSti/Ylq0DRhKgA== Date: Thu, 1 Aug 2013 21:07:28 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C92104BB47A@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.13] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Authentication for Acquisition and Delivery 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, 01 Aug 2013 21:08:36 -0000 Hi everyone, During today's informal metadata meeting, we decided to pose the following = question to the list: What sort of authentication is needed for content acquisition? For content = delivery? We'd like to understand both what is expected for basic interoperability as= well as for more advanced use cases. The current assumptions in the metadata draft for basic interop are: 1) No authentication is needed for delivery 2) Basic username/password are needed for acquisition Thoughts? Thanks, Matt From kevin.ma@azukisystems.com Thu Aug 1 14:47:48 2013 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 3BB2F21F9D3E for ; Thu, 1 Aug 2013 14:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 gOCumlAdwQJi for ; Thu, 1 Aug 2013 14:47:32 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 929F111E81DA for ; Thu, 1 Aug 2013 14:28:59 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E7ABC8BF88E; Thu, 1 Aug 2013 17:24:39 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB027.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id EE20D8BF332; Thu, 1 Aug 2013 17:24:35 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB027.mail.lan ([10.110.17.27]) with mapi; Thu, 1 Aug 2013 17:26:28 -0400 From: Kevin J Ma To: "Matt Caulfield (mcaulfie)" , "cdni@ietf.org" Date: Thu, 1 Aug 2013 17:28:51 -0400 Thread-Topic: Notes from today's Informal Metadata Meeting Thread-Index: Ac6O+kJH9tPwbFxNTdSsD84MCa171wAAlvNA Message-ID: <291CC3F9E50E7641901A54E85D0977C66651433151@MAILR002.mail.lan> References: <166EBB70C264A9479E459B01B1BA6C92104BB464@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C92104BB464@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Notes from today's Informal Metadata Meeting 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, 01 Aug 2013 21:47:49 -0000 wrt:=20 > Authentication for Acquisition > The current Source object contains a placeholder for authentication. We > discussed a simple username/password based authentication method in this > context and agreed to name the auth object "CredentialsAuth". This object > could be used for HTTP Basic, FTP, or other transfer methods that require > a username and password. Note: there was also discussion of other possible authentication methods (e.g., scp identity file, or ssl mutual auth client cert), but the basic username/password seemed like the bare minimum in lieu of any firm requirements. There is an obvious security concern with passing credentials through the metadata interface, especially if the uCDN is going to point the dCDN at not its own caches/origin, but at a further upstream cache/origin, and is thus propogating credentials that it received from a CDN further upstream which has no relationship with that dCDN. If this is a concern for the operators or anyone in the WG at large, it would be good to have input? An alternative would be to have an AuthID pointer that identifies some type of authentication credentials that were delivered out-of-band? -- Kevin J. Ma > -----Original Message----- > From: Matt Caulfield (mcaulfie) [mailto:mcaulfie@cisco.com] > Sent: Thursday, August 01, 2013 5:01 PM > To: cdni@ietf.org > Cc: Kent Leung (kleung); Kevin J Ma; Brandenburg, R. (Ray) van > (ray.vanbrandenburg@tno.nl); Rob Murray (RMurray@velocix.com) > Subject: Notes from today's Informal Metadata Meeting >=20 > Attendees: Matt Caulfield, Kent Leung, Kevin Ma, Ray van Brandenburg, Rob > Murray >=20 > "Mandatory-to-enforce" > The metadata draft defines a property in the GenericMetadata object for > indicating that a particular piece of metadata is mandatory to enforce. W= e > discussed whether or not there is ever a case where this flag would be se= t > to false and came up with a few examples related to optional optimization= s > that a CSP may desire but are not strictly required. We also questioned > whether or not the value of this property should be static (i.e. defined > by the RFC or standard which also defines the metadata it corresponds to)= . > For example, the URI signing draft defines a new metadata object for URI > signing. Should the CSP/uCDN be allowed to make URI signing mandatory to > enforce for some content but not other content? Or should mandatory to > enforce be defined by the URI signing draft as always "true" for URI > signing metadata? We felt that mandatory-to-enforce SHOULD be static and > its value SHOULD be taken from the same standard which defines the > corresponding metadata. > --> Matt to clarify this point in the Metadata draft >=20 > IANA Registries > The IANA Considerations section in the Metadata draft is not yet filled > in. We discussed the required registries for Metadata - such as a registr= y > for GenericMetadata types, Protocol types, Location types, etc. > --> Kevin to identify and fill in IANA Considerations >=20 > Authentication for Acquisition > The current Source object contains a placeholder for authentication. We > discussed a simple username/password based authentication method in this > context and agreed to name the auth object "CredentialsAuth". This object > could be used for HTTP Basic, FTP, or other transfer methods that require > a username and password. The Source object could point to a > CredentialsAuth object or to any other type of Auth object yet to be > defined. As such, an IANA registry is planned for tracking Auth methods. > --> Matt to add CredentialsAuth object to Metadata >=20 > Authentication for Delivery > We were unsure what sort of authentication, if any, should be supported b= y > the base metadata draft. We agreed to send a separate email to the list > inquiring on this topic. > --> Matt to send email on expect authentication techniques >=20 > Query Parameters Modification > In the working group meeting on Tuesday, it was noted that the current > ability to remove query parameters when caching a resource is not > sufficient for base interoperability. Instead a more flexible scheme is > needed which instructs a dCDN to remove certain query parameters before > caching, acquiring, or looking up metadata for a piece of a content. > --> Matt to update query parameter modification text >=20 > Acquisition Source object > We discussed some ambiguity in the Source object section. It is not > currently clear how a dCDN should really use a Source object to acquire > content from the uCDN, especially for the HTTP redirection case. > --> Matt to clarify Source section >=20 > Editors notes > A number of editors notes identify missing areas of the draft. > --> Above items either address or obviate all current editors notes From flefauch@cisco.com Fri Aug 2 06:27:33 2013 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 3E1F011E80D3 for ; Fri, 2 Aug 2013 06:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 SYRyqzuwTAYJ for ; Fri, 2 Aug 2013 06:27:28 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 03C7721E804D for ; Fri, 2 Aug 2013 06:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10059; q=dns/txt; s=iport; t=1375450047; x=1376659647; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TQ8J7cU3GfVPFrFnenFUWAVcp5Qb2gZaoMNtaKJIgIg=; b=APfOHIEJDcz3+LP6CvXaOr6YSBtXhE9akkIVPhUR7Oo29OVgs/JXZRCm nlG4LSTdPI5MIqc7jlbnnHzVqiLyK6IlF/CriKtGma87o6pXlIHxcehky Wk6ktDolXjTgOfKJWSQkpcNdHn07OMTz/rI933bAbVj20Scphlc6Dn3EB I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFADmz+1GtJV2c/2dsb2JhbABagwY1UL5SgRwWdIIkAQEBAwEBAQE3NBALAgEIIgsJECcLJQEBBAoJCIgCBgy5Ko9lAjgKgw90A5kJkCSDF4Iq X-IronPort-AV: E=Sophos;i="4.89,801,1367971200"; d="scan'208";a="242827196" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 02 Aug 2013 13:27:06 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r72DR5Dd011443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 2 Aug 2013 13:27:05 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Fri, 2 Aug 2013 08:27:05 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] New Text for Framework on URI Rewriting Thread-Index: Ac6O92zds42pB4QjSEezI1Jqeu28AgAtnYUA Date: Fri, 2 Aug 2013 13:27:05 +0000 Message-ID: References: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] New Text for Framework on URI Rewriting 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, 02 Aug 2013 13:27:33 -0000 Matt and all, I am not comfortable with a few of the statements in the draft text below. = I think some ambiguity lingered in there because we need to be more precise= in the modelling of the "URI plans" and recognise that there are actually = 3 URI plans, and not just 2. Specifically I think there is: * a "u-URI" used between user-agent and uCDN. A u-URI is understood by uCD= N * a "ud-URI" understood by both uCDN and dCDN * a "d-URI" used between user-agent and dCDN Surrogate. A d-URI is unders= tood by dCDN. Once we define the three schemes the whole discussion becomes quite simple = and very un-ambiguous I think: all CDNI interfaces have to operate using ud= -URIs (for this particular pair of uCDN and dCDN) in all situations. I beli= eve this statement holds for any request routing method (HTTP and DNS) and = for any redirection method (iterative and recursive) and for handling of tr= ansitive situation. Obviously, the 3 URI schemes are not always different, but they may be diff= erent. Here are a few examples scenarios: 1) say we use DNS redirection. u-URI=3Dud-URI=3Dd-URI (eg =3Dcsp1.ucdn.com) 2) say we use HTTP redirection in iterative mode, and dCDN sticks to the ud= -URI scheme u-URI!=3Dud-URI=3Dd-URI (eg u-URI=3Dcsp1.ucdn.com) (eg ud-URI=3Dd-URI=3Ducdn.dcdn.com/csp1) 3) say we use HTTP redirection in recursive mode, and dCDN wants to use his= own scheme u-URI!=3Dud-URI!=3Dd-URI (eg u-URI=3Dcsp1.ucdn.com used between user-agent and uCDN) (eg ud-URI=3Ducdn.dcdn.com/csp1 used in Redirection request message) (eg d-URI=3Ddcdn.com/ucdn1/csp1 used in Redirection response message, betw= een user-agent and dCDN, and in the raw logs generated by the dCDN Surrogat= e) Note that I used different combinations of URI plans between recursive and = iterative in the examples above, but there is no correlation between URI sc= heme combination and redirection mode. Any URI scheme combination is possib= le with any redirection mode. In any situation, the CDNI interfaces always need to use the ud-URI scheme = (for that particular pair of uCDN and dCDN).=20 Does this sound right? Assuming this is right, the framework text could look something like this (= feel free to improve): " Metadata & URI Rewriting When using HTTP redirection, content URIs will be rewritten between uCDNs a= nd dCDNs. In the case of cascaded CDNs, content URIs may be rewritten at ev= ery CDN hop between uCDN and dCDN. URI rewriting needs to be taken into acc= ount for the implementation of some CDNI interfaces. Consider the simple case: a single uCDN and dCDN. This section refers: * to a URI requested of the uCDN as a "u-URI" * to a URI used in CDNI interactions between the uCDN and dCDN as a "ud-UR= I" * to a URI requested of the dCDN as a "dCDN URI" In a given deployment situation, the ud-URI plan may be different or the sa= me as the u-URI plan, and the d-URI plan may be different or the same as th= e ud-URI plan. Any combination is possible. For example, where DNS redirect= ion is used the u-URI, ud-URI and d-URI plans will all be the same. As anot= her example, where HTTP request routing in iterative mode is used, the uCDN= will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.co= m/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp.ucd= n.com/xyz), and in turn the dCDN request routing system may redirect the us= er-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz) in = a plan that is different to the ud-URI plan. Most CDNI interfaces involve content URIs. For example, in the case of the = CDNI Logging interface, each log record may reference a content URI. In the= case of the CDNI Metadata interface, the dCDN must query the uCDN for meta= data based on a content URI.=20 Any CDNI interface between an uCDN and a dCDN which relies on content URIs = needs to convey URIs in that interface in the ud-URI plan for the given pai= r of CDNs.=20 When the dCDN is transfering CDNI information to the uCDN including a conte= nt URI, it is the responsibility of the dCDN to use the ud-URI plan and, if= required, to map back a d-URI into a ud-URI. For example, if the dCDN uses= a d-URI plan that is different to the ud-URI plan, the dCDN needs to map b= ack the d-URIs into ud-URIs for inclusion in the CDNI Logging interface. When the uCDN is transfering CDNI information to the dCDN including a conte= nt URI, it is the responsibility of the dCDN to use the ud-URI plan when co= nveying content URIs. For example, if the uCDN uses a d-URI plan that is di= fferent from the ud-URI plan, it is the responsibility of the uCDN to ensur= e content URIs used in the CDNI Metadata interface are expressed in the ud-= URI plan. Also, if the dCDN uses a d-URI plan that is different from the ud= -URI plan, it is the responsibility of the dCDN to correlate d-URIs in cont= ent requests with metadata obtained from the uCDN expressed in the ud-URI p= lan.=20 Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 actin= g as the transit CDN and CDN3 acting as the dCDN. This section refers: * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as a ud-= URI-ut * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 as a ud-= URI-td In a given deployment situation the ud-URI-td plan may be different or the = same as the ud-URI-ut plan. For example, when DNS request routing is used a= t every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the same. Wh= en HTTP request routing is used at every CDN hop, the ud-URI-td plan and ud= -URI-ut plan will be different. When, in his role of transit CDN, CDN2 turns information obtained on a CDNI= interface from the dCDN (respectively uCDN) into information transmitted t= o the uCDN (respectively dCDN) on the corresponding CDNI interface, it is t= he responsibility of the transit CDN to convert content URIs from the ud-UR= I-td plan to the ud-URI-ut plan (respectively from the ud-URI-ut plan to th= e ud-URI-td plan). For example, when the transit CDN receives CDNI logging records from the dC= DN with content URIs expressed in the ud-URI-td plan, and when the transit = CDN includes the corresponding CDNI logging records for transmission to the= uCDN over the CDNI Logging interface, the transit CDN needs to map the con= tent URIs expressed in the ud-URI-td plan into URIs expressed into the ud-U= RI-ut plan. Similarly, when the transit CDN receives CDNI metadata informat= ion from the uCDN with content URIs expressed in the ud-URI-ut plan, and wh= en the transit CDN includes the corresponfing CDNI metadata information for= transmission to the dCDN over the CDNI Metadata interface, the transit CDN= needs to map the content URIs expressed in the ud-URI-ut plan into content= URIs expressed in the ud-URI-td plan. Regarding metadata information, note= that (even when the ud-URI-ut plan and ud-URI-td plan are the same) the tr= ansit CDN is also likely to have to perform rewriting on some other metadat= a information. For example, any metadata which references the immediately u= pstream CDN (such as content acquisition metadata) should be rewritten as t= he metadata is passed between CDNs. " Francois On 1 Aug 2013, at 22:41, Matt Caulfield (mcaulfie) wro= te: > Hi everyone, >=20 > Based on comments this week regarding the URI Rewriting section of the CD= NI Framework document I have put together a revised section which aims to t= ouch on the key points more clearly. Please share your feedback on the text= below. If it is suitable, we can incorporate into the next revision of dra= ft-ietf-cdni-framework. >=20 > Thanks, > Matt >=20 > Metadata & URI Rewriting >=20 > When using HTTP redirection, content URIs will be rewritten between uCDNs= and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten mul= tiple times between uCDN and dCDN. URI rewriting poses a special challenge = for the implementation of some CDNI interfaces. > Consider the simple case: a single uCDN and dCDN. This section refers to = the URI requested of the uCDN as the "uCDN URI" and the URI requested of th= e dCDN as the "dCDN URI".=20 >=20 > Any CDNI interface which relies on content URIs must state explicitly whi= ch URI is to be used - the dCDN URI or the uCDN URI. For example, in the ca= se of the Logging Interface, each log message may reference a content URI. = In the case of the Metadata Interface, the dCDN must query for the uCDN for= metadata based on a content URI. >=20 > For all CDNI interfaces, the dCDN should translate any dCDN URIs to uCDN = URIs before interacting with the uCDN. For logging, this approach requires = the dCDN to translate any dCDN URIs in its log messages into uCDN URIs. For= metadata, this approach requires the dCDN to translate any dCDN URIs into = uCDN URIs before querying the uCDN for metadata.=20 >=20 > In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and the= refore is capable of translating from uCDN URI to dCDN URI and vice versa. = In iterative mode, an out-of-band agreement instructs the uCDN and dCDN how= to translate from uCDN URI to dCDN URI and vice versa. In either mode, the= dCDN is capable of translating dCDN URIs into uCDN URIs before interacting= with the uCDN. >=20 > Note that even in the DNS redirection case, some URI rewriting is still n= ecessary. For example, any metadata which references the immediately upstre= am CDN (such as content acquisition metadata) should be rewritten as the me= tadata is passed between CDNs. However, given that DNS redirection does not= change the content URI, many of the concerns addressed above with HTTP red= irection do not apply. >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From swainner@cisco.com Fri Aug 2 14:35:37 2013 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 E627611E80E7 for ; Fri, 2 Aug 2013 14:35:37 -0700 (PDT) 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 YSY6-mYPKr6I for ; Fri, 2 Aug 2013 14:35:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EDEAA11E80F9 for ; Fri, 2 Aug 2013 14:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18651; q=dns/txt; s=iport; t=1375479330; x=1376688930; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=nH5xeaHcWWyWkEzsTNzYSanbrFkPg6sVef4crsJUzH4=; b=aB7GYafKoL52fn+eXmQo2RgS5UNJbVkaUsdesCxZUu06m1ggrfohJd9W HjbqW9wofpQsg6NZtvRez/vN/BnF3OeqagoVE+gD9AQr/xi81D5kBd85z JZWlr2QnPKU5FBMxlS/BZEe6lrOHwCxuHEOwxmxL8Uu979PoqjR3o+OKf k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkFACIl/FGtJV2Y/2dsb2JhbABagwY1SohztiCBHhZ0giQBAQEBAwEBASRABwoRCxgJFg8JAwIBAgEVMBMGAgEBBYgHBwW5EJAfhA0DlAiDV4EqkCSDMyCBLiQ X-IronPort-AV: E=Sophos;i="4.89,803,1367971200"; d="scan'208,217";a="242935741" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 02 Aug 2013 21:35:28 +0000 Received: from rtp-swainner-8919.cisco.com (rtp-swainner-8919.cisco.com [10.116.109.202]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r72LZRk1016950 for ; Fri, 2 Aug 2013 21:35:28 GMT Message-ID: <51FC261F.7040002@cisco.com> Date: Fri, 02 Aug 2013 17:35:27 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cdni@ietf.org References: <20130715211254.20113.85966.idtracker@ietfa.amsl.com> In-Reply-To: <20130715211254.20113.85966.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070801000906080905090902" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-metadata-02.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, 02 Aug 2013 21:35:38 -0000 This is a multi-part message in MIME format. --------------070801000906080905090902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Comments on the metadata-02 draft ... Scott Wainner * 4.2.6. Auth** ** ** An Auth object defines authentication and authorization methods to be** ** used during content delivery and content acquisition, e.g. methods** ** such as tokenization and URL Signing.** ** ** [Ed. Need to synchronize authentication configuration with CDNI URL** ** signing draft definitions.]** * sw> There is no need for a uCDN to direct the User Agent to a dCDN if that dCDN doesn't support the authentication method invoked. URL signing draft defines at least two methods: 1) URL Signing 2) Tokenization and the attributes associated with the method defined. I consider two models: a. dCDN advertises its AUTH methods in capabilities (FCI); the uCDN finds at least one of these methods acceptable or not b. uCDN announces the method(s) it requires (MI) ; the dCDN either accepts a method or rejects them all In the case of DNS redirect, the method is defined by the CSP and may be inherently understood by the uCDN. That method needs to be conveyed to the dCDN and where the dCDN is validated by the uCDN; otherwise, the dCDN won't be able to authenticate the URL created by the CSP. This seems like a good candidate for the MI as a mandatory attribute. For a given Host in the HostIndex, the authentication method and attributes can be defined: REFERENCE leung-cdni-url-signing-2.txt Method: Signature or SignedToken Enforcement Attributes: ET and CIP Signature Attributes: MD or DS Computation Attributes: VER, KID, HF *4.2.8. Grouping** ** ** A Grouping object identifies a large group of content to which this** ** content belongs.** ** ** Property: ccid** ** ** Description: Content Collection identifier for an application-** ** specific purpose such as logging.** ** ** Type: String** ** ** Mandatory-to-Specify: No. Default is an empty string.** ** ** Property: sid** ** ** Description: Session identifier for an application-specific** ** purpose such as logging.** ** ** Type: String** ** ** Mandatory-to-Specify: No. Default is an empty string.** * sw> According to the cdni-logging-05.txt, the dCDN creates and assigns a Session-ID. It seems to me that the CSP may create a Session-ID. Likewise, a uCDN would also create a Session-ID for any delegation to a dCDN. Ideally, the CSP Session-ID, the uCDN Session-ID, and the dCDN Session-ID would be correlated such that the operators can track the hand-off of the referrals: CSP -> uCDN -> dCDN -> dCDN -> deliveryNode. Perhaps the Session-ID has some defined hierarchy that explicitly traces the referrals: Session-ID:= [dcdn-id.ucdn-id.csp-id.] If that is the case, the MI could convey the uCDN's part of the Session-ID: sid = ucdn-id.csp-id where the dCDN can prepend its assigned Session-ID. In a similar manner, a dCDN that delegates to another dCDN would prepend its assigned Session-ID: sid = dcdn-1-id.ucdn-id.csp-id Now we need to define the format of the Session-ID. Refer to I-D. brandenburg-cdni-has which describes the session-ID, but it remains undefine. *6.2. Retrieval of CDNI Metadata resources** ** ** ....** ** ** Where a downstream CDN is interconnected with multiple upstream CDNs,** ** the downstream CDN must decide which upstream CDN's CDNI metadata** ** should be used to handle a particular User Agent request.** * sw> I would think the dCDN MUST request the metadata from the uCDN that provided the User Agent the request. * When application level redirection (e.g. HTTP 302 redirects) is being** ** used between CDNs, it is expected that the downstream CDN will be** ** able to determine the upstream CDN that redirected a particular** ** request from information contained in the received request (e.g. via** ** the URI). With knowledge of which upstream CDN routed the request,** ** the downstream CDN can choose the correct metadata server from which** ** to obtain the HostIndex. Note that the HostIndex served by each uCDN** ** may be unique.** * sw> Now that we may incorporate the Request Interface in the WG, the URI prepared by the uCDN for the dCDN and passed via the User Agent client (Interative Mode) may contain a reference such that the dCDN will know the originator of the User Agent's request. * In the case of DNS redirection there is not always sufficient** ** information carried in the DNS request from User Agents to determine** ** the upstream CDN that redirected a particular request (e.g. when** ** content from a given host is redirected to a given downstream CDN by** ** more than one upstream CDN) and therefore downstream CDNs may have to** ** apply local policy when deciding which upstream CDN's metadata to** ** apply.** * sw> I would think that the dCDN would have a unique CNAME for each uCDN that it services, thus the dCDN can associate the incoming request to a particular uCDN by association of the CNAME to the uCDN. Example: uCDN-1 CNAME for dCDN-X: ucdn-1.dcdn-x.com uCDN-2 CNAME for dCDN-X: ucdn-2.dcdn-x.com Now dCDN-X knows the originator of the DNS referral; hence, the dCDN can make metadata calls to the appropriate uCDN. On 7/15/13 5:12 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. > > Title : CDN Interconnect Metadata > Author(s) : Ben Niven-Jenkins > Rob Murray > Grant Watson > Matt Caulfield > Kent Leung > Kevin J. Ma > Filename : draft-ietf-cdni-metadata-02.txt > Pages : 43 > Date : 2013-07-15 > > Abstract: > The CDNI Metadata Interface enables interconnected CDNs to exchange > content distribution metadata in order to enable content acquisition > and delivery. The CDNI metadata associated with a piece of content > provides a downstream CDN with sufficient information for the > downstream CDN to service content requests on behalf of an upstream > CDN. This document describes both the core set of CDNI metadata and > the protocol for exchanging that metadata. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-metadata-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-02 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > . > --------------070801000906080905090902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Comments on the metadata-02 draft ...

Scott Wainner



4.2.6.  Auth

   An Auth object defines authentication and authorization methods to be
   used during content delivery and content acquisition, e.g. methods
   such as tokenization and URL Signing.

   [Ed.  Need to synchronize authentication configuration with CDNI URL
   signing draft definitions.]

sw> There is no need for a uCDN to direct the User Agent to a dCDN if that dCDN doesn't support the authentication method invoked.  URL signing draft defines at least two methods:

1) URL Signing
2) Tokenization

and the attributes associated with the method defined.

I consider two models:

a. dCDN advertises its AUTH methods in capabilities (FCI); the uCDN finds at least one of these methods acceptable or not
b. uCDN announces the method(s) it requires (MI) ; the dCDN either accepts a method or rejects them all

In the case of DNS redirect, the method is defined by the CSP and may be inherently understood by the uCDN.  That method needs to be conveyed to the dCDN and where the dCDN is validated by the uCDN; otherwise, the dCDN won't be able to authenticate the URL created by the CSP.  This seems like a good candidate for the MI as a mandatory attribute.  For a given Host in the HostIndex, the authentication method and attributes can be defined:
   
    REFERENCE leung-cdni-url-signing-2.txt

    Method: Signature or SignedToken
    Enforcement Attributes: ET and CIP
    Signature Attributes: MD or DS
    Computation Attributes: VER, KID, HF

4.2.8.  Grouping

   A Grouping object identifies a large group of content to which this
   content belongs.

      Property: ccid

         Description: Content Collection identifier for an application-
         specific purpose such as logging.

         Type: String

         Mandatory-to-Specify: No.  Default is an empty string.

      Property: sid

         Description: Session identifier for an application-specific
         purpose such as logging.

         Type: String

         Mandatory-to-Specify: No.  Default is an empty string.

sw>  According to the cdni-logging-05.txt, the dCDN creates and assigns a Session-ID.  It seems to me that the CSP may create a Session-ID.  Likewise, a uCDN would also create a Session-ID for any delegation to a dCDN.  Ideally, the CSP Session-ID, the uCDN Session-ID, and the dCDN Session-ID would be correlated such that the operators can track the hand-off of the referrals: CSP -> uCDN -> dCDN -> dCDN -> deliveryNode.

Perhaps the Session-ID has some defined hierarchy that explicitly traces the referrals:

    Session-ID:= [dcdn-id.ucdn-id.csp-id.]

If that is the case, the MI could convey the uCDN's part of the Session-ID:

    sid = ucdn-id.csp-id

where the dCDN can prepend its assigned Session-ID.

In a similar manner, a dCDN that delegates to another dCDN would prepend its assigned Session-ID:

    sid = dcdn-1-id.ucdn-id.csp-id

Now we need to define the format of the Session-ID.  Refer to I-D. brandenburg-cdni-has which describes the session-ID, but it remains undefine.


6.2.  Retrieval of CDNI Metadata resources

   ....

   Where a downstream CDN is interconnected with multiple upstream CDNs,
   the downstream CDN must decide which upstream CDN's CDNI metadata
   should be used to handle a particular User Agent request.

sw> I would think the dCDN MUST request the metadata from the uCDN that provided the User Agent the request.

   When application level redirection (e.g. HTTP 302 redirects) is being
   used between CDNs, it is expected that the downstream CDN will be
   able to determine the upstream CDN that redirected a particular
   request from information contained in the received request (e.g. via
   the URI).  With knowledge of which upstream CDN routed the request,
   the downstream CDN can choose the correct metadata server from which
   to obtain the HostIndex.  Note that the HostIndex served by each uCDN
   may be unique.

sw> Now that we may incorporate the Request Interface in the WG, the URI prepared by the uCDN for the dCDN and passed via the User Agent client (Interative Mode) may contain a reference such that the dCDN will know the originator of the User Agent's request.

   In the case of DNS redirection there is not always sufficient
   information carried in the DNS request from User Agents to determine
   the upstream CDN that redirected a particular request (e.g. when
   content from a given host is redirected to a given downstream CDN by
   more than one upstream CDN) and therefore downstream CDNs may have to
   apply local policy when deciding which upstream CDN's metadata to
   apply.

sw> I would think that the dCDN would have a unique CNAME for each uCDN that it services, thus the dCDN can associate the incoming request to a particular uCDN by association of the CNAME to the uCDN.

    Example:
        uCDN-1 CNAME for dCDN-X: ucdn-1.dcdn-x.com
        uCDN-2 CNAME for dCDN-X: ucdn-2.dcdn-x.com
    Now dCDN-X knows the originator of the DNS referral; hence, the dCDN can make metadata calls to the appropriate uCDN.



On 7/15/13 5:12 PM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.

	Title           : CDN Interconnect Metadata
	Author(s)       : Ben Niven-Jenkins
                          Rob Murray
                          Grant Watson
                          Matt Caulfield
                          Kent Leung
                          Kevin J. Ma
	Filename        : draft-ietf-cdni-metadata-02.txt
	Pages           : 43
	Date            : 2013-07-15

Abstract:
   The CDNI Metadata Interface enables interconnected CDNs to exchange
   content distribution metadata in order to enable content acquisition
   and delivery.  The CDNI metadata associated with a piece of content
   provides a downstream CDN with sufficient information for the
   downstream CDN to service content requests on behalf of an upstream
   CDN.  This document describes both the core set of CDNI metadata and
   the protocol for exchanging that metadata.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-cdni-metadata-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-metadata-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--------------070801000906080905090902-- From ben@niven-jenkins.co.uk Sat Aug 3 08:12:54 2013 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 A585321F9FC8 for ; Sat, 3 Aug 2013 08:12:54 -0700 (PDT) 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 2M4MUWfdDV+a for ; Sat, 3 Aug 2013 08:12:50 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id EDA6E21F9EF5 for ; Sat, 3 Aug 2013 08:12:49 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginmedia.com ([86.14.227.47] helo=[192.168.0.4]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1V5dVf-00035j-1I; Sat, 03 Aug 2013 16:12:47 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Sat, 3 Aug 2013 16:12:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3838550E-781D-4245-AD46-AF5473835F2F@niven-jenkins.co.uk> References: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> To: Francois Le Faucheur (flefauch) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Text for Framework on URI Rewriting 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, 03 Aug 2013 15:12:54 -0000 Francois, Matt, Colleagues, I think there is an important distinction between a CDN being told a = particular transformation to apply and applying it and a CDN actually = 'understanding' a particular URI. For example, in the case of iterative request routing a dCDN may 'say' = to a uCDN "here is the transformation I want you to apply to URIs in = order to redirect them to me". There is no requirement for the uCDN to = actually understand what it is doing and without other knowledge it is = not safe IMO for the uCDN to attempt to infer meaning from the = transformation, it should just blindly apply it. I think this is an important distinction/point because looseness here = will lead IMO to people making incorrect assumptions about what a uCDN = or dCDN may "know" and incorrect design decision that couple uCDNs and = dCDNs more than is necessary. Ben On 2 Aug 2013, at 14:27, Francois Le Faucheur (flefauch) wrote: > Matt and all, >=20 > I am not comfortable with a few of the statements in the draft text = below. I think some ambiguity lingered in there because we need to be = more precise in the modelling of the "URI plans" and recognise that = there are actually 3 URI plans, and not just 2. Specifically I think = there is: > * a "u-URI" used between user-agent and uCDN. A u-URI is = understood by uCDN > * a "ud-URI" understood by both uCDN and dCDN > * a "d-URI" used between user-agent and dCDN Surrogate. A d-URI = is understood by dCDN. > Once we define the three schemes the whole discussion becomes quite = simple and very un-ambiguous I think: all CDNI interfaces have to = operate using ud-URIs (for this particular pair of uCDN and dCDN) in all = situations. I believe this statement holds for any request routing = method (HTTP and DNS) and for any redirection method (iterative and = recursive) and for handling of transitive situation. >=20 > Obviously, the 3 URI schemes are not always different, but they may be = different. > Here are a few examples scenarios: >=20 > 1) say we use DNS redirection. > u-URI=3Dud-URI=3Dd-URI (eg =3Dcsp1.ucdn.com) >=20 > 2) say we use HTTP redirection in iterative mode, and dCDN sticks to = the ud-URI scheme > u-URI!=3Dud-URI=3Dd-URI > (eg u-URI=3Dcsp1.ucdn.com) > (eg ud-URI=3Dd-URI=3Ducdn.dcdn.com/csp1) >=20 > 3) say we use HTTP redirection in recursive mode, and dCDN wants to = use his own scheme > u-URI!=3Dud-URI!=3Dd-URI > (eg u-URI=3Dcsp1.ucdn.com used between user-agent and uCDN) > (eg ud-URI=3Ducdn.dcdn.com/csp1 used in Redirection request message) > (eg d-URI=3Ddcdn.com/ucdn1/csp1 used in Redirection response message, = between user-agent and dCDN, and in the raw logs generated by the dCDN = Surrogate) >=20 > Note that I used different combinations of URI plans between recursive = and iterative in the examples above, but there is no correlation between = URI scheme combination and redirection mode. Any URI scheme combination = is possible with any redirection mode. >=20 > In any situation, the CDNI interfaces always need to use the ud-URI = scheme (for that particular pair of uCDN and dCDN).=20 >=20 > Does this sound right? >=20 > Assuming this is right, the framework text could look something like = this (feel free to improve): >=20 > " > Metadata & URI Rewriting >=20 > When using HTTP redirection, content URIs will be rewritten between = uCDNs and dCDNs. In the case of cascaded CDNs, content URIs may be = rewritten at every CDN hop between uCDN and dCDN. URI rewriting needs to = be taken into account for the implementation of some CDNI interfaces. >=20 > Consider the simple case: a single uCDN and dCDN. This section refers: > * to a URI requested of the uCDN as a "u-URI" > * to a URI used in CDNI interactions between the uCDN and dCDN = as a "ud-URI" > * to a URI requested of the dCDN as a "dCDN URI" >=20 > In a given deployment situation, the ud-URI plan may be different or = the same as the u-URI plan, and the d-URI plan may be different or the = same as the ud-URI plan. Any combination is possible. For example, where = DNS redirection is used the u-URI, ud-URI and d-URI plans will all be = the same. As another example, where HTTP request routing in iterative = mode is used, the uCDN will redirect the user-agent to the dCDN using a = ud-URI (e.g. ucdn.dcdn.com/csp/xyz) in a plan that will be different to = the u-URI plan (e.g. csp.ucdn.com/xyz), and in turn the dCDN request = routing system may redirect the user-agent to a dCDN Surrogate using a = d-URI (e.g. dcdn.com/ucdn/csp/xyz) in a plan that is different to the = ud-URI plan. >=20 > Most CDNI interfaces involve content URIs. For example, in the case of = the CDNI Logging interface, each log record may reference a content URI. = In the case of the CDNI Metadata interface, the dCDN must query the uCDN = for metadata based on a content URI.=20 >=20 > Any CDNI interface between an uCDN and a dCDN which relies on content = URIs needs to convey URIs in that interface in the ud-URI plan for the = given pair of CDNs.=20 >=20 > When the dCDN is transfering CDNI information to the uCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan = and, if required, to map back a d-URI into a ud-URI. For example, if the = dCDN uses a d-URI plan that is different to the ud-URI plan, the dCDN = needs to map back the d-URIs into ud-URIs for inclusion in the CDNI = Logging interface. >=20 > When the uCDN is transfering CDNI information to the dCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan = when conveying content URIs. For example, if the uCDN uses a d-URI plan = that is different from the ud-URI plan, it is the responsibility of the = uCDN to ensure content URIs used in the CDNI Metadata interface are = expressed in the ud-URI plan. Also, if the dCDN uses a d-URI plan that = is different from the ud-URI plan, it is the responsibility of the dCDN = to correlate d-URIs in content requests with metadata obtained from the = uCDN expressed in the ud-URI plan.=20 >=20 > Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 = acting as the transit CDN and CDN3 acting as the dCDN. This section = refers: > * to a ud-URI involved in CDNI interactions between CDN1 and = CDN2 as a ud-URI-ut > * to a ud-URI involved in CDNI interactions between CDN2 and = CDN3 as a ud-URI-td >=20 > In a given deployment situation the ud-URI-td plan may be different or = the same as the ud-URI-ut plan. For example, when DNS request routing is = used at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the = same. When HTTP request routing is used at every CDN hop, the ud-URI-td = plan and ud-URI-ut plan will be different. >=20 > When, in his role of transit CDN, CDN2 turns information obtained on a = CDNI interface from the dCDN (respectively uCDN) into information = transmitted to the uCDN (respectively dCDN) on the corresponding CDNI = interface, it is the responsibility of the transit CDN to convert = content URIs from the ud-URI-td plan to the ud-URI-ut plan (respectively = from the ud-URI-ut plan to the ud-URI-td plan). >=20 > For example, when the transit CDN receives CDNI logging records from = the dCDN with content URIs expressed in the ud-URI-td plan, and when the = transit CDN includes the corresponding CDNI logging records for = transmission to the uCDN over the CDNI Logging interface, the transit = CDN needs to map the content URIs expressed in the ud-URI-td plan into = URIs expressed into the ud-URI-ut plan. Similarly, when the transit CDN = receives CDNI metadata information from the uCDN with content URIs = expressed in the ud-URI-ut plan, and when the transit CDN includes the = corresponfing CDNI metadata information for transmission to the dCDN = over the CDNI Metadata interface, the transit CDN needs to map the = content URIs expressed in the ud-URI-ut plan into content URIs expressed = in the ud-URI-td plan. Regarding metadata information, note that (even = when the ud-URI-ut plan and ud-URI-td plan are the same) the transit CDN = is also likely to have to perform rewriting on some other metadata = information.=20 > For example, any metadata which references the immediately upstream = CDN (such as content acquisition metadata) should be rewritten as the = metadata is passed between CDNs. > " >=20 > Francois >=20 > On 1 Aug 2013, at 22:41, Matt Caulfield (mcaulfie) = wrote: >=20 >> Hi everyone, >>=20 >> Based on comments this week regarding the URI Rewriting section of = the CDNI Framework document I have put together a revised section which = aims to touch on the key points more clearly. Please share your feedback = on the text below. If it is suitable, we can incorporate into the next = revision of draft-ietf-cdni-framework. >>=20 >> Thanks, >> Matt >>=20 >> Metadata & URI Rewriting >>=20 >> When using HTTP redirection, content URIs will be rewritten between = uCDNs and dCDNs. In the case of cascaded CDNs, content URIs may be = rewritten multiple times between uCDN and dCDN. URI rewriting poses a = special challenge for the implementation of some CDNI interfaces. >=20 >=20 >=20 >> Consider the simple case: a single uCDN and dCDN. This section refers = to the URI requested of the uCDN as the "uCDN URI" and the URI requested = of the dCDN as the "dCDN URI".=20 >>=20 >> Any CDNI interface which relies on content URIs must state explicitly = which URI is to be used - the dCDN URI or the uCDN URI. For example, in = the case of the Logging Interface, each log message may reference a = content URI. In the case of the Metadata Interface, the dCDN must query = for the uCDN for metadata based on a content URI. >>=20 >> For all CDNI interfaces, the dCDN should translate any dCDN URIs to = uCDN URIs before interacting with the uCDN. For logging, this approach = requires the dCDN to translate any dCDN URIs in its log messages into = uCDN URIs. For metadata, this approach requires the dCDN to translate = any dCDN URIs into uCDN URIs before querying the uCDN for metadata.=20 >>=20 >> In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and = therefore is capable of translating from uCDN URI to dCDN URI and vice = versa. In iterative mode, an out-of-band agreement instructs the uCDN = and dCDN how to translate from uCDN URI to dCDN URI and vice versa. In = either mode, the dCDN is capable of translating dCDN URIs into uCDN URIs = before interacting with the uCDN. >>=20 >> Note that even in the DNS redirection case, some URI rewriting is = still necessary. For example, any metadata which references the = immediately upstream CDN (such as content acquisition metadata) should = be rewritten as the metadata is passed between CDNs. However, given that = DNS redirection does not change the content URI, many of the concerns = addressed above with HTTP redirection do not apply. >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Sun Aug 4 12:04:42 2013 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 EEE5321F9D5E for ; Sun, 4 Aug 2013 12:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 rQ1izZxpbZlt for ; Sun, 4 Aug 2013 12:04:38 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9572021F9D39 for ; Sun, 4 Aug 2013 12:04:38 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8E8628BE5A3 for ; Sun, 4 Aug 2013 15:04:39 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 18BE58BE51C for ; Sun, 4 Aug 2013 15:04:39 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Sun, 4 Aug 2013 15:03:39 -0400 From: Kevin J Ma To: "cdni@ietf.org" Date: Sun, 4 Aug 2013 15:04:34 -0400 Thread-Topic: New Version Notification for draft-ma-cdni-capabilities-03.txt Thread-Index: Ac6RRBi9V/GygaeMRcym0u+G4W0alwAACHdA Message-ID: <291CC3F9E50E7641901A54E85D0977C66651433622@MAILR002.mail.lan> References: <20130804185451.13411.73451.idtracker@ietfa.amsl.com> In-Reply-To: <20130804185451.13411.73451.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-ma-cdni-capabilities-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Aug 2013 19:04:43 -0000 SGkgYWxsLA0KDQogIEkgbWFkZSBzb21lIHVwZGF0ZXMgdG8gbXkgRkNJIGRyYWZ0IHRvIGJyaW5n IGl0IGludG8gbGluZSB3aXRoIHRoZSBjdXJyZW50DQogIGZyYW1ld29yayBhbmQgcmVxdWlyZW1l bnRzIGRyYWZ0cyAoaS5lLiwgY29uY2Vuc3VzIGludGVyZmFjZSBuYW1lcyBhbmQgbmV3DQogIHJl cXVpcmVtZW50cyBudW1iZXJpbmcpLCBhcyB3ZWxsIGFzIHRvIGFkZHJlc3Mgc29tZSBvZiB0aGUg ZGVjaXNpb25zIHRoYXQNCiAgd2VyZSBtYWRlIGluIE9ybGFuZG8gdGhhdCBJIHdhcyBub3QgYWJs ZSB0byBhZGRyZXNzIGluIHRpbWUgZm9yIEJlcmxpbg0KICAoZS5nLiwgcGFydGlhbCB1cGRhdGUg c3VwcG9ydCwganNvbiBmb3JtYXR0aW5nLCBhbmQgbG9nZ2luZy9tZXRhZGF0YQ0KICBjYXBhYmls aXRpZXMgaGFuZGxpbmcpLiAgSSBpbnRlbmQgdG8gZG8gYW5vdGhlciB1cGRhdGUgb25jZSB3ZSBo YXZlDQogIGZpbmFsaXplZCB0aGUgc2VtYW50aWNzIGRyYWZ0LCBob3BlZnVsbHkgaW4gdGltZSBm b3IgVmFuY291dmVyLg0KDQp0aGFueC4NCg0KLS0gIEtldmluIEouIE1hDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBBdWd1c3QgMDQsIDIwMTMg Mjo1NSBQTQ0KVG86IEtldmluIEogTWE7IEtldmluIEogTWENClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbWEtY2RuaS1jYXBhYmlsaXRpZXMtMDMudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1hLWNkbmktY2FwYWJpbGl0aWVzLTAzLnR4dA0K aGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXZpbiBKLiBNYSBhbmQgcG9zdGVk IHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LW1hLWNkbmktY2Fw YWJpbGl0aWVzDQpSZXZpc2lvbjoJIDAzDQpUaXRsZToJCSBDRE5JIEZvb3RwcmludCAmIENhcGFi aWxpdGllcyBBZHZlcnRpc2VtZW50IEludGVyZmFjZQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDgt MDQNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNw0K VVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1tYS1jZG5pLWNhcGFiaWxpdGllcy0wMy50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tYS1jZG5pLWNhcGFiaWxpdGllcw0KSHRtbGl6 ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1tYS1jZG5pLWNhcGFi aWxpdGllcy0wMw0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1tYS1jZG5pLWNhcGFiaWxpdGllcy0wMw0KDQpBYnN0cmFjdDoNCiAgIENvbnRl bnQgRGlzdHJpYnV0aW9uIE5ldHdvcmsgSW50ZXJjb25uZWN0aW9uIChDRE5JKSBpcyBwcmVkaWNh dGVkIG9uDQogICB0aGUgYWJpbGl0eSBvZiBkb3duc3RyZWFtIENETnMgKGRDRE5zKSB0byBoYW5k bGUgZW5kLXVzZXIgcmVxdWVzdHMgaW4NCiAgIGEgZnVuY3Rpb25hbGx5IGVxdWl2YWxlbnQgbWFu bmVyIHRvIHRoZSB1cHN0cmVhbSBDRE4gKHVDRE4pLiAgVGhlDQogICB1Q0ROIG11c3QgYmUgYWJs ZSB0byBhc3Nlc3MgdGhlIGFiaWxpdHkgb2YgdGhlIGRDRE4gdG8gaGFuZGxlDQogICBpbmRpdmlk dWFsIHJlcXVlc3RzLiAgVGhlIENETkkgRm9vdHByaW50ICYgQ2FwYWJpbGl0aWVzIEFkdmVydGlz ZW1lbnQNCiAgIGludGVyZmFjZSAoRkNJKSBpcyBwcm92aWRlZCBmb3IgdGhlIGFkdmVydGlzZW1l bnQgb2YgY2FwYWJpbGl0aWVzIGFuZA0KICAgdGhlIGZvb3RwcmludHMgdG8gd2hpY2ggdGhleSBh cHBseSBieSB0aGUgZENETiB0byB0aGUgdUNETi4gIFRoaXMNCiAgIGRvY3VtZW50IGRlc2NyaWJl cyBhbiBhcHByb2FjaCB0byBpbXBsZW1lbnRpbmcgdGhlIENETkkgRkNJLg0KDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From swainner@cisco.com Sun Aug 4 20:31:48 2013 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 9CB3D21E80D3 for ; Sun, 4 Aug 2013 20:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 XGH1A-y+X0S8 for ; Sun, 4 Aug 2013 20:31:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA6121E80CD for ; Sun, 4 Aug 2013 20:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12796; q=dns/txt; s=iport; t=1375673504; x=1376883104; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=hv9ZD8yXoWwDl1gJahQzm9XU6KOlvhDaZcnHursh+dc=; b=V/yNjgBbWKgy1C8Xt/wa4rUoRfvmyfd+tZ+h/cpk98lD6uRGRv92svPM HSjicWtLdL7XBXggMi7BE+rQLXQi5lr9gtOaD23lX/E+7PPL8anOaRGPo QFAcQ4R4RkkHf85i76kw1phUHw3z48WefYjF7QneEpeMq97cF82ErfcWJ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANAb/1GtJXG//2dsb2JhbABagwY1v0iBHRZ0giAEAQEBBAEBATU2ChELGAkMCg8JAwIBAgEVMAcJAwYCAQGFRQeCIR8MtSGPZjoKhAMDlAmDV4EqkCWDMyA X-IronPort-AV: E=Sophos;i="4.89,815,1367971200"; d="scan'208";a="243370139" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 05 Aug 2013 03:31:42 +0000 Received: from rtp-swainner-8919.cisco.com (rtp-swainner-8919.cisco.com [10.116.109.202]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r753VgJh001410; Mon, 5 Aug 2013 03:31:42 GMT Message-ID: <51FF1C9D.9060703@cisco.com> Date: Sun, 04 Aug 2013 23:31:41 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cdni@ietf.org, ben@niven-jenkins.co.uk References: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> <3838550E-781D-4245-AD46-AF5473835F2F@niven-jenkins.co.uk> In-Reply-To: <3838550E-781D-4245-AD46-AF5473835F2F@niven-jenkins.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [CDNi] New Text for Framework on URI Rewriting 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, 05 Aug 2013 03:31:48 -0000 Ben I think I agree with you, but using a different logical point of=20 view. I suspect the uCDN is the entity that 'knows' the URL that is=20 created by the CSP. There are likely to be proprietary attributes that=20 only the uCDN and CSP understand. With that said, the uCDN will need to = re-write the URL attributes into a CDNI form that any dCDN could=20 understand provided it supports the attributes. For example, the CSP might use a query parameter "algorithm=3Dsha256= "=20 which is understood by the uCDN. Of course, there are likely no dCDNs=20 that would understand this query parameter. It is incumbent upon the=20 uCDN to map the "algorithm=3D" parameter to the CDNI "HF=3D" parameter. = It=20 is the uCDN that knows this mapping. All we need from the dCDN is to=20 know that it supports "HF=3Dsha256" which is a option from the URL Signin= g=20 capabilities. The same can be said for any other query parameters. It would be=20 the uCDN that knows if the CSP's "algorithm" parameter is mandatory or=20 optional. The uCDN just needs to know if there is a dCDN that supports=20 the mandatory attributes using the CDNI methods for conveying the=20 parameters. Scott On 8/3/13 11:12 AM, Ben Niven-Jenkins wrote: > Francois, Matt, Colleagues, > > I think there is an important distinction between a CDN being told a pa= rticular transformation to apply and applying it and a CDN actually 'unde= rstanding' a particular URI. > > For example, in the case of iterative request routing a dCDN may 'say' = to a uCDN "here is the transformation I want you to apply to URIs in orde= r to redirect them to me". There is no requirement for the uCDN to actual= ly understand what it is doing and without other knowledge it is not safe= IMO for the uCDN to attempt to infer meaning from the transformation, it= should just blindly apply it. > > I think this is an important distinction/point because looseness here w= ill lead IMO to people making incorrect assumptions about what a uCDN or = dCDN may "know" and incorrect design decision that couple uCDNs and dCDN= s more than is necessary. > > Ben > > On 2 Aug 2013, at 14:27, Francois Le Faucheur (flefauch) wrote: > >> Matt and all, >> >> I am not comfortable with a few of the statements in the draft text be= low. I think some ambiguity lingered in there because we need to be more = precise in the modelling of the "URI plans" and recognise that there are = actually 3 URI plans, and not just 2. Specifically I think there is: >> * a "u-URI" used between user-agent and uCDN. A u-URI is understood b= y uCDN >> * a "ud-URI" understood by both uCDN and dCDN >> * a "d-URI" used between user-agent and dCDN Surrogate. A d-URI is u= nderstood by dCDN. >> Once we define the three schemes the whole discussion becomes quite si= mple and very un-ambiguous I think: all CDNI interfaces have to operate u= sing ud-URIs (for this particular pair of uCDN and dCDN) in all situation= s. I believe this statement holds for any request routing method (HTTP an= d DNS) and for any redirection method (iterative and recursive) and for h= andling of transitive situation. >> >> Obviously, the 3 URI schemes are not always different, but they may be= different. >> Here are a few examples scenarios: >> >> 1) say we use DNS redirection. >> u-URI=3Dud-URI=3Dd-URI (eg =3Dcsp1.ucdn.com) >> >> 2) say we use HTTP redirection in iterative mode, and dCDN sticks to t= he ud-URI scheme >> u-URI!=3Dud-URI=3Dd-URI >> (eg u-URI=3Dcsp1.ucdn.com) >> (eg ud-URI=3Dd-URI=3Ducdn.dcdn.com/csp1) >> >> 3) say we use HTTP redirection in recursive mode, and dCDN wants to us= e his own scheme >> u-URI!=3Dud-URI!=3Dd-URI >> (eg u-URI=3Dcsp1.ucdn.com used between user-agent and uCDN) >> (eg ud-URI=3Ducdn.dcdn.com/csp1 used in Redirection request message) >> (eg d-URI=3Ddcdn.com/ucdn1/csp1 used in Redirection response message, = between user-agent and dCDN, and in the raw logs generated by the dCDN S= urrogate) >> >> Note that I used different combinations of URI plans between recursive= and iterative in the examples above, but there is no correlation between= URI scheme combination and redirection mode. Any URI scheme combination = is possible with any redirection mode. >> >> In any situation, the CDNI interfaces always need to use the ud-URI sc= heme (for that particular pair of uCDN and dCDN). >> >> Does this sound right? >> >> Assuming this is right, the framework text could look something like t= his (feel free to improve): >> >> " >> Metadata & URI Rewriting >> >> When using HTTP redirection, content URIs will be rewritten between uC= DNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritte= n at every CDN hop between uCDN and dCDN. URI rewriting needs to be taken= into account for the implementation of some CDNI interfaces. >> >> Consider the simple case: a single uCDN and dCDN. This section refers:= >> * to a URI requested of the uCDN as a "u-URI" >> * to a URI used in CDNI interactions between the uCDN and dCDN as a "= ud-URI" >> * to a URI requested of the dCDN as a "dCDN URI" >> >> In a given deployment situation, the ud-URI plan may be different or t= he same as the u-URI plan, and the d-URI plan may be different or the sam= e as the ud-URI plan. Any combination is possible. For example, where DNS= redirection is used the u-URI, ud-URI and d-URI plans will all be the sa= me. As another example, where HTTP request routing in iterative mode is u= sed, the uCDN will redirect the user-agent to the dCDN using a ud-URI (e.= g. ucdn.dcdn.com/csp/xyz) in a plan that will be different to the u-URI p= lan (e.g. csp.ucdn.com/xyz), and in turn the dCDN request routing system = may redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.= com/ucdn/csp/xyz) in a plan that is different to the ud-URI plan. >> >> Most CDNI interfaces involve content URIs. For example, in the case of= the CDNI Logging interface, each log record may reference a content URI.= In the case of the CDNI Metadata interface, the dCDN must query the uCDN= for metadata based on a content URI. >> >> Any CDNI interface between an uCDN and a dCDN which relies on content = URIs needs to convey URIs in that interface in the ud-URI plan for the gi= ven pair of CDNs. >> >> When the dCDN is transfering CDNI information to the uCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan = and, if required, to map back a d-URI into a ud-URI. For example, if the = dCDN uses a d-URI plan that is different to the ud-URI plan, the dCDN nee= ds to map back the d-URIs into ud-URIs for inclusion in the CDNI Logging = interface. >> >> When the uCDN is transfering CDNI information to the dCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan = when conveying content URIs. For example, if the uCDN uses a d-URI plan t= hat is different from the ud-URI plan, it is the responsibility of the uC= DN to ensure content URIs used in the CDNI Metadata interface are express= ed in the ud-URI plan. Also, if the dCDN uses a d-URI plan that is differ= ent from the ud-URI plan, it is the responsibility of the dCDN to correla= te d-URIs in content requests with metadata obtained from the uCDN expres= sed in the ud-URI plan. >> >> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 = acting as the transit CDN and CDN3 acting as the dCDN. This section refer= s: >> * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as = a ud-URI-ut >> * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 as = a ud-URI-td >> >> In a given deployment situation the ud-URI-td plan may be different or= the same as the ud-URI-ut plan. For example, when DNS request routing is= used at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the= same. When HTTP request routing is used at every CDN hop, the ud-URI-td = plan and ud-URI-ut plan will be different. >> >> When, in his role of transit CDN, CDN2 turns information obtained on a= CDNI interface from the dCDN (respectively uCDN) into information transm= itted to the uCDN (respectively dCDN) on the corresponding CDNI interface= , it is the responsibility of the transit CDN to convert content URIs fro= m the ud-URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-= ut plan to the ud-URI-td plan). >> >> For example, when the transit CDN receives CDNI logging records from t= he dCDN with content URIs expressed in the ud-URI-td plan, and when the t= ransit CDN includes the corresponding CDNI logging records for transmissi= on to the uCDN over the CDNI Logging interface, the transit CDN needs to = map the content URIs expressed in the ud-URI-td plan into URIs expressed = into the ud-URI-ut plan. Similarly, when the transit CDN receives CDNI me= tadata information from the uCDN with content URIs expressed in the ud-UR= I-ut plan, and when the transit CDN includes the corresponfing CDNI metad= ata information for transmission to the dCDN over the CDNI Metadata inter= face, the transit CDN needs to map the content URIs expressed in the ud-U= RI-ut plan into content URIs expressed in the ud-URI-td plan. Regarding m= etadata information, note that (even when the ud-URI-ut plan and ud-URI-t= d plan are the same) the transit CDN is also likely to have to perform re= writing on some other metadata information > . >> For example, any metadata which references the immediately upstream CD= N (such as content acquisition metadata) should be rewritten as the metad= ata is passed between CDNs. >> " >> >> Francois >> >> On 1 Aug 2013, at 22:41, Matt Caulfield (mcaulfie) wrote: >> >>> Hi everyone, >>> >>> Based on comments this week regarding the URI Rewriting section of th= e CDNI Framework document I have put together a revised section which aim= s to touch on the key points more clearly. Please share your feedback on = the text below. If it is suitable, we can incorporate into the next revis= ion of draft-ietf-cdni-framework. >>> >>> Thanks, >>> Matt >>> >>> Metadata & URI Rewriting >>> >>> When using HTTP redirection, content URIs will be rewritten between u= CDNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritt= en multiple times between uCDN and dCDN. URI rewriting poses a special ch= allenge for the implementation of some CDNI interfaces. >> >> >>> Consider the simple case: a single uCDN and dCDN. This section refers= to the URI requested of the uCDN as the "uCDN URI" and the URI requested= of the dCDN as the "dCDN URI". >>> >>> Any CDNI interface which relies on content URIs must state explicitly= which URI is to be used - the dCDN URI or the uCDN URI. For example, in = the case of the Logging Interface, each log message may reference a conte= nt URI. In the case of the Metadata Interface, the dCDN must query for th= e uCDN for metadata based on a content URI. >>> >>> For all CDNI interfaces, the dCDN should translate any dCDN URIs to u= CDN URIs before interacting with the uCDN. For logging, this approach req= uires the dCDN to translate any dCDN URIs in its log messages into uCDN U= RIs. For metadata, this approach requires the dCDN to translate any dCDN = URIs into uCDN URIs before querying the uCDN for metadata. >>> >>> In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and= therefore is capable of translating from uCDN URI to dCDN URI and vice v= ersa. In iterative mode, an out-of-band agreement instructs the uCDN and = dCDN how to translate from uCDN URI to dCDN URI and vice versa. In either= mode, the dCDN is capable of translating dCDN URIs into uCDN URIs before= interacting with the uCDN. >>> >>> Note that even in the DNS redirection case, some URI rewriting is sti= ll necessary. For example, any metadata which references the immediately = upstream CDN (such as content acquisition metadata) should be rewritten a= s the metadata is passed between CDNs. However, given that DNS redirectio= n does not change the content URI, many of the concerns addressed above w= ith HTTP redirection do not apply. >>> >>> _______________________________________________ >>> 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 Mon Aug 5 01:15:38 2013 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 48ECE21F9C2E for ; Mon, 5 Aug 2013 01:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx+FDz94oAjk for ; Mon, 5 Aug 2013 01:15:12 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 09AFB21F9C16 for ; Mon, 5 Aug 2013 01:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12399; q=dns/txt; s=iport; t=1375690510; x=1376900110; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4Jfr248OrgnGlxBrqOBUsAi0BbukqDdku9gjsRACJgc=; b=WlpMBbBCCaZZd5gKulG8fWRXW/ptsJrR6Uap3N33eMh3FUpk4C8fysJ3 fDctJCtbqp1msqhK/Xc6PT1ek2FESKhIn29qH1RU17SaYVrHTcj+o9i/e KVr5WZiRUinTuQNKaLOx9M/wqYp6tGk8p7nFolfaYNJmMGMX4z41wQ2iB 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAM1e/1GtJV2a/2dsb2JhbABagwY1UL55gR4WdIIkAQEBAwEBAQFrCwULAgEIGAoLGScLJQEBBAoEBQiIAgYMtGiPZgIxBwqDD3QDlAmFAZAlgxeCKg X-IronPort-AV: E=Sophos;i="4.89,817,1367971200"; d="scan'208";a="240449199" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 05 Aug 2013 08:15:00 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r758F0ZK001535 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 5 Aug 2013 08:15:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 03:14:59 -0500 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] New Text for Framework on URI Rewriting Thread-Index: Ac6O92zds42pB4QjSEezI1Jqeu28AgAtnYUAADX7fIAAVf6ugA== Date: Mon, 5 Aug 2013 08:14:58 +0000 Message-ID: References: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> <3838550E-781D-4245-AD46-AF5473835F2F@niven-jenkins.co.uk> In-Reply-To: <3838550E-781D-4245-AD46-AF5473835F2F@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Text for Framework on URI Rewriting 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, 05 Aug 2013 08:15:38 -0000 Ben, On 3 Aug 2013, at 17:12, Ben Niven-Jenkins wrote: > Francois, Matt, Colleagues, >=20 > I think there is an important distinction between a CDN being told a part= icular transformation to apply and applying it and a CDN actually 'understa= nding' a particular URI. Agreed. > For example, in the case of iterative request routing a dCDN may 'say' to= a uCDN "here is the transformation I want you to apply to URIs in order to= redirect them to me". There is no requirement for the uCDN to actually und= erstand what it is doing and without other knowledge it is not safe IMO for= the uCDN to attempt to infer meaning from the transformation, it should ju= st blindly apply it. Right. I chose the wrong words in the informal descriptive text I used at t= he top of the message (i.e when I said " a ud-URI understood by both uCDN a= nd dCDN").=20 But I think the proposed draft text was more carefully chosen and addresses= your point. It says: " This section refers: ... * to a URI used in CDNI interactions between the uCDN and dCDN as a "ud-UR= I" =85 " So in your example, the "ud-URI" is the one applied by the uCDN in accordan= ce with "the transformation I want you to apply to URIs in order to redirec= t them to me" and this does not have to be "understood" by the uCDN. If you ignore the casual informal descriptive text at the beginning of my e= arlier message, are you comfortable with the draft text? Thanks Francois >=20 > I think this is an important distinction/point because looseness here wil= l lead IMO to people making incorrect assumptions about what a uCDN or dCDN= may "know" and incorrect design decision that couple uCDNs and dCDNs more= than is necessary. >=20 > Ben >=20 > On 2 Aug 2013, at 14:27, Francois Le Faucheur (flefauch) wrote: >=20 >> Matt and all, >>=20 >> I am not comfortable with a few of the statements in the draft text belo= w. I think some ambiguity lingered in there because we need to be more prec= ise in the modelling of the "URI plans" and recognise that there are actual= ly 3 URI plans, and not just 2. Specifically I think there is: >> * a "u-URI" used between user-agent and uCDN. A u-URI is understood by = uCDN >> * a "ud-URI" understood by both uCDN and dCDN >> * a "d-URI" used between user-agent and dCDN Surrogate. A d-URI is und= erstood by dCDN. >> Once we define the three schemes the whole discussion becomes quite simp= le and very un-ambiguous I think: all CDNI interfaces have to operate using= ud-URIs (for this particular pair of uCDN and dCDN) in all situations. I b= elieve this statement holds for any request routing method (HTTP and DNS) a= nd for any redirection method (iterative and recursive) and for handling of= transitive situation. >>=20 >> Obviously, the 3 URI schemes are not always different, but they may be d= ifferent. >> Here are a few examples scenarios: >>=20 >> 1) say we use DNS redirection. >> u-URI=3Dud-URI=3Dd-URI (eg =3Dcsp1.ucdn.com) >>=20 >> 2) say we use HTTP redirection in iterative mode, and dCDN sticks to the= ud-URI scheme >> u-URI!=3Dud-URI=3Dd-URI >> (eg u-URI=3Dcsp1.ucdn.com) >> (eg ud-URI=3Dd-URI=3Ducdn.dcdn.com/csp1) >>=20 >> 3) say we use HTTP redirection in recursive mode, and dCDN wants to use = his own scheme >> u-URI!=3Dud-URI!=3Dd-URI >> (eg u-URI=3Dcsp1.ucdn.com used between user-agent and uCDN) >> (eg ud-URI=3Ducdn.dcdn.com/csp1 used in Redirection request message) >> (eg d-URI=3Ddcdn.com/ucdn1/csp1 used in Redirection response message, b= etween user-agent and dCDN, and in the raw logs generated by the dCDN Surro= gate) >>=20 >> Note that I used different combinations of URI plans between recursive a= nd iterative in the examples above, but there is no correlation between URI= scheme combination and redirection mode. Any URI scheme combination is pos= sible with any redirection mode. >>=20 >> In any situation, the CDNI interfaces always need to use the ud-URI sche= me (for that particular pair of uCDN and dCDN).=20 >>=20 >> Does this sound right? >>=20 >> Assuming this is right, the framework text could look something like thi= s (feel free to improve): >>=20 >> " >> Metadata & URI Rewriting >>=20 >> When using HTTP redirection, content URIs will be rewritten between uCDN= s and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten at= every CDN hop between uCDN and dCDN. URI rewriting needs to be taken into = account for the implementation of some CDNI interfaces. >>=20 >> Consider the simple case: a single uCDN and dCDN. This section refers: >> * to a URI requested of the uCDN as a "u-URI" >> * to a URI used in CDNI interactions between the uCDN and dCDN as a "ud= -URI" >> * to a URI requested of the dCDN as a "dCDN URI" >>=20 >> In a given deployment situation, the ud-URI plan may be different or the= same as the u-URI plan, and the d-URI plan may be different or the same as= the ud-URI plan. Any combination is possible. For example, where DNS redir= ection is used the u-URI, ud-URI and d-URI plans will all be the same. As a= nother example, where HTTP request routing in iterative mode is used, the u= CDN will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn= .com/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp.= ucdn.com/xyz), and in turn the dCDN request routing system may redirect the= user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz) = in a plan that is different to the ud-URI plan. >>=20 >> Most CDNI interfaces involve content URIs. For example, in the case of t= he CDNI Logging interface, each log record may reference a content URI. In = the case of the CDNI Metadata interface, the dCDN must query the uCDN for m= etadata based on a content URI.=20 >>=20 >> Any CDNI interface between an uCDN and a dCDN which relies on content UR= Is needs to convey URIs in that interface in the ud-URI plan for the given = pair of CDNs.=20 >>=20 >> When the dCDN is transfering CDNI information to the uCDN including a co= ntent URI, it is the responsibility of the dCDN to use the ud-URI plan and,= if required, to map back a d-URI into a ud-URI. For example, if the dCDN u= ses a d-URI plan that is different to the ud-URI plan, the dCDN needs to ma= p back the d-URIs into ud-URIs for inclusion in the CDNI Logging interface. >>=20 >> When the uCDN is transfering CDNI information to the dCDN including a co= ntent URI, it is the responsibility of the dCDN to use the ud-URI plan when= conveying content URIs. For example, if the uCDN uses a d-URI plan that is= different from the ud-URI plan, it is the responsibility of the uCDN to en= sure content URIs used in the CDNI Metadata interface are expressed in the = ud-URI plan. Also, if the dCDN uses a d-URI plan that is different from the= ud-URI plan, it is the responsibility of the dCDN to correlate d-URIs in c= ontent requests with metadata obtained from the uCDN expressed in the ud-UR= I plan.=20 >>=20 >> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 ac= ting as the transit CDN and CDN3 acting as the dCDN. This section refers: >> * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as a = ud-URI-ut >> * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 as a = ud-URI-td >>=20 >> In a given deployment situation the ud-URI-td plan may be different or t= he same as the ud-URI-ut plan. For example, when DNS request routing is use= d at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the same.= When HTTP request routing is used at every CDN hop, the ud-URI-td plan and= ud-URI-ut plan will be different. >>=20 >> When, in his role of transit CDN, CDN2 turns information obtained on a C= DNI interface from the dCDN (respectively uCDN) into information transmitte= d to the uCDN (respectively dCDN) on the corresponding CDNI interface, it i= s the responsibility of the transit CDN to convert content URIs from the ud= -URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-ut plan to= the ud-URI-td plan). >>=20 >> For example, when the transit CDN receives CDNI logging records from the= dCDN with content URIs expressed in the ud-URI-td plan, and when the trans= it CDN includes the corresponding CDNI logging records for transmission to = the uCDN over the CDNI Logging interface, the transit CDN needs to map the = content URIs expressed in the ud-URI-td plan into URIs expressed into the u= d-URI-ut plan. Similarly, when the transit CDN receives CDNI metadata infor= mation from the uCDN with content URIs expressed in the ud-URI-ut plan, and= when the transit CDN includes the corresponfing CDNI metadata information = for transmission to the dCDN over the CDNI Metadata interface, the transit = CDN needs to map the content URIs expressed in the ud-URI-ut plan into cont= ent URIs expressed in the ud-URI-td plan. Regarding metadata information, n= ote that (even when the ud-URI-ut plan and ud-URI-td plan are the same) the= transit CDN is also likely to have to perform rewriting on some other meta= data information.=20 >> For example, any metadata which references the immediately upstream CDN = (such as content acquisition metadata) should be rewritten as the metadata = is passed between CDNs. >> " >>=20 >> Francois >>=20 >> On 1 Aug 2013, at 22:41, Matt Caulfield (mcaulfie) = wrote: >>=20 >>> Hi everyone, >>>=20 >>> Based on comments this week regarding the URI Rewriting section of the = CDNI Framework document I have put together a revised section which aims to= touch on the key points more clearly. Please share your feedback on the te= xt below. If it is suitable, we can incorporate into the next revision of d= raft-ietf-cdni-framework. >>>=20 >>> Thanks, >>> Matt >>>=20 >>> Metadata & URI Rewriting >>>=20 >>> When using HTTP redirection, content URIs will be rewritten between uCD= Ns and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten m= ultiple times between uCDN and dCDN. URI rewriting poses a special challeng= e for the implementation of some CDNI interfaces. >>=20 >>=20 >>=20 >>> Consider the simple case: a single uCDN and dCDN. This section refers t= o the URI requested of the uCDN as the "uCDN URI" and the URI requested of = the dCDN as the "dCDN URI".=20 >>>=20 >>> Any CDNI interface which relies on content URIs must state explicitly w= hich URI is to be used - the dCDN URI or the uCDN URI. For example, in the = case of the Logging Interface, each log message may reference a content URI= . In the case of the Metadata Interface, the dCDN must query for the uCDN f= or metadata based on a content URI. >>>=20 >>> For all CDNI interfaces, the dCDN should translate any dCDN URIs to uCD= N URIs before interacting with the uCDN. For logging, this approach require= s the dCDN to translate any dCDN URIs in its log messages into uCDN URIs. F= or metadata, this approach requires the dCDN to translate any dCDN URIs int= o uCDN URIs before querying the uCDN for metadata.=20 >>>=20 >>> In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and t= herefore is capable of translating from uCDN URI to dCDN URI and vice versa= . In iterative mode, an out-of-band agreement instructs the uCDN and dCDN h= ow to translate from uCDN URI to dCDN URI and vice versa. In either mode, t= he dCDN is capable of translating dCDN URIs into uCDN URIs before interacti= ng with the uCDN. >>>=20 >>> Note that even in the DNS redirection case, some URI rewriting is still= necessary. For example, any metadata which references the immediately upst= ream CDN (such as content acquisition metadata) should be rewritten as the = metadata is passed between CDNs. However, given that DNS redirection does n= ot change the content URI, many of the concerns addressed above with HTTP r= edirection do not apply. >>>=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 flefauch@cisco.com Mon Aug 5 01:40:05 2013 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 7F45021F9D17 for ; Mon, 5 Aug 2013 01:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 0CkXqcLtSH4R for ; Mon, 5 Aug 2013 01:39:50 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E0EBC21F940D for ; Mon, 5 Aug 2013 01:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16204; q=dns/txt; s=iport; t=1375691976; x=1376901576; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6w386jL24nhCUZI/nK7z8M4oNkSSe9fFFJlh1fGwCNo=; b=HE7YJk6pZvIok0nozIuqz1Xt5UEu/UTCPmHyodq8iX3yZlI3MCAhCWhF w29WUEXrdLp++hKkqorZExcxHFvnGCRTg5XdCxLKZ0/E/Aaktgk55Ezl0 2LWyjpI7OHHDtrK+Iowr95hXe6X7DG6b4MprGYIuolIuJttJFkxAyS0YV 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADdk/1GtJV2c/2dsb2JhbABagwY1UL55gR4WdIIkAQEBBAEBATc0GwIBCBgKCwkQJwslAQEECgkIiAgMtGuPZgI4CoMPdAOZCpAlgxeCKg X-IronPort-AV: E=Sophos;i="4.89,817,1367971200"; d="scan'208";a="243455973" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 05 Aug 2013 08:39:35 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r758dYBF027000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 5 Aug 2013 08:39:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 5 Aug 2013 03:39:34 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] New Text for Framework on URI Rewriting Thread-Index: Ac6O92zds42pB4QjSEezI1Jqeu28AgAtnYUAAIzUnYA= Date: Mon, 5 Aug 2013 08:39:33 +0000 Message-ID: References: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] Content-Type: text/plain; charset="us-ascii" Content-ID: <32843B2F07FA58419297BC8C613370DE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] New Text for Framework on URI Rewriting 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, 05 Aug 2013 08:40:23 -0000 Folks, Someone suggested privately that perhaps we are trying to provide too much = details here, and that we may be finally blurring the point that is not tha= t complicated. So I'd like to offer an alternative text that aims at captur= ing the point accurately but succinctly. So you'll find below: * a Concise Option (new) * a Verbose Option (same as in my earlier message with minor editorial enh= ancements) Let us know which you favor (or if you have alternative proposals to offer)= . Francois Concise Option =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " Metadata & URI Rewriting When using HTTP redirection, content URIs will be rewritten when redirectio= n takes place within an uCDN, when redirection takes place from an uCDN to = a dCDN and when redirection takes place within a dCDN. In the case of casca= ded CDNs, content URIs may be rewritten at every CDN hop between the uCDN a= nd the dCDN serving the request. URI rewriting needs to be taken into accou= nt for the implementation of some CDNI interfaces. Consider the simple case: a single uCDN and dCDN. This section refers: * to a URI requested of the uCDN as a "u-URI" * to a URI used in CDNI interactions between the uCDN and dCDN as a "ud-UR= I" * to a URI requested of the dCDN as a "d-URI" In a given deployment situation, the ud-URI plan may be different or the sa= me as the u-URI plan, and the d-URI plan may be different or the same as th= e ud-URI plan. Any combination is possible. For example, where DNS redirect= ion is used the u-URI, ud-URI and d-URI plans will all be the same. As anot= her example, where HTTP request routing in iterative mode is used, the uCDN= will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.co= m/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp.ucd= n.com/xyz), and in turn the dCDN request routing system may redirect the us= er-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz) in = a plan that is different to the ud-URI plan. Most CDNI interfaces involve content URIs. For example, in the case of the = CDNI Logging interface, each log record may reference a content URI. In the= case of the CDNI Metadata interface, the dCDN must query the uCDN for meta= data based on a content URI.=20 It is the responsibility of the uCDN (respectively dCDN) to ensure that a c= ontent URI communicated to the dCDN (respectively uCDN) are always expresse= d in the ud-URI plan for the particular dCDN (respectively uCDN). When the = content URI has been derived from information expressing content URIs in a = different plan, the uCDN (respectively dCDN) needs to map the content URI i= nto the ud-URI plan (for the given pair of uCDN and dCDN) for conveying it = as a content URI in a CDNI interface. " Verbose Option: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " Metadata & URI Rewriting When using HTTP redirection, content URIs will be rewritten when redirectio= n takes place within an uCDN, when redirection takes place from an uCDN to = a dCDN and when redirection takes place within a dCDN. In the case of casca= ded CDNs, content URIs may be rewritten at every CDN hop between the uCDN a= nd the dCDN serving the request. URI rewriting needs to be taken into accou= nt for the implementation of some CDNI interfaces. Consider the simple case: a single uCDN and dCDN. This section refers: * to a URI requested of the uCDN as a "u-URI" * to a URI used in CDNI interactions between the uCDN and dCDN as a "ud-UR= I" * to a URI requested of the dCDN as a "d-URI" In a given deployment situation, the ud-URI plan may be different or the sa= me as the u-URI plan, and the d-URI plan may be different or the same as th= e ud-URI plan. Any combination is possible. For example, where DNS redirect= ion is used the u-URI, ud-URI and d-URI plans will all be the same. As anot= her example, where HTTP request routing in iterative mode is used, the uCDN= will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.co= m/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp.ucd= n.com/xyz), and in turn the dCDN request routing system may redirect the us= er-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz) in = a plan that is different to the ud-URI plan. Most CDNI interfaces involve content URIs. For example, in the case of the = CDNI Logging interface, each log record may reference a content URI. In the= case of the CDNI Metadata interface, the dCDN must query the uCDN for meta= data based on a content URI.=20 Any CDNI interface between an uCDN and a dCDN which relies on content URIs = needs to convey URIs in that interface in the ud-URI plan for the given pai= r of CDNs.=20 When the dCDN is transfering CDNI information to the uCDN including a conte= nt URI, it is the responsibility of the dCDN to use the ud-URI plan and, if= required, to map back a d-URI into a ud-URI. For example, if the dCDN uses= a d-URI plan that is different to the ud-URI plan, the dCDN needs to map b= ack the d-URIs into ud-URIs for inclusion in the CDNI Logging interface. When the uCDN is transfering CDNI information to the dCDN including a conte= nt URI, it is the responsibility of the dCDN to use the ud-URI plan when co= nveying content URIs. For example, if the uCDN uses a d-URI plan that is di= fferent from the ud-URI plan, it is the responsibility of the uCDN to ensur= e content URIs used in the CDNI Metadata interface are expressed in the ud-= URI plan. Also, if the dCDN uses a d-URI plan that is different from the ud= -URI plan, it is the responsibility of the dCDN to correlate d-URIs in cont= ent requests with metadata obtained from the uCDN expressed in the ud-URI p= lan.=20 Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 actin= g as the transit CDN and CDN3 acting as the dCDN. This section refers: * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as a ud-= URI-ut * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 as a ud-= URI-td In a given deployment situation the ud-URI-td plan may be different or the = same as the ud-URI-ut plan. For example, when DNS request routing is used a= t every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the same. Wh= en HTTP request routing is used at every CDN hop, the ud-URI-td plan and ud= -URI-ut plan will be different. When, in his role of transit CDN, CDN2 turns information obtained on a CDNI= interface from the dCDN (respectively uCDN) into information transmitted t= o the uCDN (respectively dCDN) on the corresponding CDNI interface, it is t= he responsibility of the transit CDN to convert content URIs from the ud-UR= I-td plan to the ud-URI-ut plan (respectively from the ud-URI-ut plan to th= e ud-URI-td plan). For example, when the transit CDN receives CDNI logging records from the dC= DN with content URIs expressed in the ud-URI-td plan, and when the transit = CDN includes the corresponding CDNI logging records for transmission to the= uCDN over the CDNI Logging interface, the transit CDN needs to map the con= tent URIs expressed in the ud-URI-td plan into URIs expressed into the ud-U= RI-ut plan. Similarly, when the transit CDN receives CDNI metadata informat= ion from the uCDN with content URIs expressed in the ud-URI-ut plan, and wh= en the transit CDN includes the corresponfing CDNI metadata information for= transmission to the dCDN over the CDNI Metadata interface, the transit CDN= needs to map the content URIs expressed in the ud-URI-ut plan into content= URIs expressed in the ud-URI-td plan. Regarding metadata information, note= that (even when the ud-URI-ut plan and ud-URI-td plan are the same) the tr= ansit CDN is also likely to have to perform rewriting on some other metadat= a information.=20 For example, any metadata which references the immediately upstream CDN (su= ch as content acquisition metadata) should be rewritten as the metadata is = passed between CDNs. " >=20 > " > Metadata & URI Rewriting >=20 > When using HTTP redirection, content URIs will be rewritten between uCDNs= and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten at = every CDN hop between uCDN and dCDN. URI rewriting needs to be taken into a= ccount for the implementation of some CDNI interfaces. >=20 > Consider the simple case: a single uCDN and dCDN. This section refers: > * to a URI requested of the uCDN as a "u-URI" > * to a URI used in CDNI interactions between the uCDN and dCDN as a "ud-= URI" > * to a URI requested of the dCDN as a "dCDN URI" >=20 > In a given deployment situation, the ud-URI plan may be different or the = same as the u-URI plan, and the d-URI plan may be different or the same as = the ud-URI plan. Any combination is possible. For example, where DNS redire= ction is used the u-URI, ud-URI and d-URI plans will all be the same. As an= other example, where HTTP request routing in iterative mode is used, the uC= DN will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.= com/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp.u= cdn.com/xyz), and in turn the dCDN request routing system may redirect the = user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz) i= n a plan that is different to the ud-URI plan. >=20 > Most CDNI interfaces involve content URIs. For example, in the case of th= e CDNI Logging interface, each log record may reference a content URI. In t= he case of the CDNI Metadata interface, the dCDN must query the uCDN for me= tadata based on a content URI.=20 >=20 > Any CDNI interface between an uCDN and a dCDN which relies on content URI= s needs to convey URIs in that interface in the ud-URI plan for the given p= air of CDNs.=20 >=20 > When the dCDN is transfering CDNI information to the uCDN including a con= tent URI, it is the responsibility of the dCDN to use the ud-URI plan and, = if required, to map back a d-URI into a ud-URI. For example, if the dCDN us= es a d-URI plan that is different to the ud-URI plan, the dCDN needs to map= back the d-URIs into ud-URIs for inclusion in the CDNI Logging interface. >=20 > When the uCDN is transfering CDNI information to the dCDN including a con= tent URI, it is the responsibility of the dCDN to use the ud-URI plan when = conveying content URIs. For example, if the uCDN uses a d-URI plan that is = different from the ud-URI plan, it is the responsibility of the uCDN to ens= ure content URIs used in the CDNI Metadata interface are expressed in the u= d-URI plan. Also, if the dCDN uses a d-URI plan that is different from the = ud-URI plan, it is the responsibility of the dCDN to correlate d-URIs in co= ntent requests with metadata obtained from the uCDN expressed in the ud-URI= plan.=20 >=20 > Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 act= ing as the transit CDN and CDN3 acting as the dCDN. This section refers: > * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as a u= d-URI-ut > * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 as a u= d-URI-td >=20 > In a given deployment situation the ud-URI-td plan may be different or th= e same as the ud-URI-ut plan. For example, when DNS request routing is used= at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the same. = When HTTP request routing is used at every CDN hop, the ud-URI-td plan and = ud-URI-ut plan will be different. >=20 > When, in his role of transit CDN, CDN2 turns information obtained on a CD= NI interface from the dCDN (respectively uCDN) into information transmitted= to the uCDN (respectively dCDN) on the corresponding CDNI interface, it is= the responsibility of the transit CDN to convert content URIs from the ud-= URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-ut plan to = the ud-URI-td plan). >=20 > For example, when the transit CDN receives CDNI logging records from the = dCDN with content URIs expressed in the ud-URI-td plan, and when the transi= t CDN includes the corresponding CDNI logging records for transmission to t= he uCDN over the CDNI Logging interface, the transit CDN needs to map the c= ontent URIs expressed in the ud-URI-td plan into URIs expressed into the ud= -URI-ut plan. Similarly, when the transit CDN receives CDNI metadata inform= ation from the uCDN with content URIs expressed in the ud-URI-ut plan, and = when the transit CDN includes the corresponfing CDNI metadata information f= or transmission to the dCDN over the CDNI Metadata interface, the transit C= DN needs to map the content URIs expressed in the ud-URI-ut plan into conte= nt URIs expressed in the ud-URI-td plan. Regarding metadata information, no= te that (even when the ud-URI-ut plan and ud-URI-td plan are the same) the = transit CDN is also likely to have to perform rewriting on some other metad= ata information.=20 > For example, any metadata which references the immediately upstream CDN (= such as content acquisition metadata) should be rewritten as the metadata i= s passed between CDNs. > " >=20 > Francois >=20 > On 1 Aug 2013, at 22:41, Matt Caulfield (mcaulfie) w= rote: >=20 >> Hi everyone, >>=20 >> Based on comments this week regarding the URI Rewriting section of the C= DNI Framework document I have put together a revised section which aims to = touch on the key points more clearly. Please share your feedback on the tex= t below. If it is suitable, we can incorporate into the next revision of dr= aft-ietf-cdni-framework. >>=20 >> Thanks, >> Matt >>=20 >> Metadata & URI Rewriting >>=20 >> When using HTTP redirection, content URIs will be rewritten between uCDN= s and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten mu= ltiple times between uCDN and dCDN. URI rewriting poses a special challenge= for the implementation of some CDNI interfaces. >=20 >=20 >=20 >> Consider the simple case: a single uCDN and dCDN. This section refers to= the URI requested of the uCDN as the "uCDN URI" and the URI requested of t= he dCDN as the "dCDN URI".=20 >>=20 >> Any CDNI interface which relies on content URIs must state explicitly wh= ich URI is to be used - the dCDN URI or the uCDN URI. For example, in the c= ase of the Logging Interface, each log message may reference a content URI.= In the case of the Metadata Interface, the dCDN must query for the uCDN fo= r metadata based on a content URI. >>=20 >> For all CDNI interfaces, the dCDN should translate any dCDN URIs to uCDN= URIs before interacting with the uCDN. For logging, this approach requires= the dCDN to translate any dCDN URIs in its log messages into uCDN URIs. Fo= r metadata, this approach requires the dCDN to translate any dCDN URIs into= uCDN URIs before querying the uCDN for metadata.=20 >>=20 >> In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and th= erefore is capable of translating from uCDN URI to dCDN URI and vice versa.= In iterative mode, an out-of-band agreement instructs the uCDN and dCDN ho= w to translate from uCDN URI to dCDN URI and vice versa. In either mode, th= e dCDN is capable of translating dCDN URIs into uCDN URIs before interactin= g with the uCDN. >>=20 >> Note that even in the DNS redirection case, some URI rewriting is still = necessary. For example, any metadata which references the immediately upstr= eam CDN (such as content acquisition metadata) should be rewritten as the m= etadata is passed between CDNs. However, given that DNS redirection does no= t change the content URI, many of the concerns addressed above with HTTP re= direction do not apply. >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From swainner@cisco.com Mon Aug 5 03:43:41 2013 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 9EAF521F9E6C for ; Mon, 5 Aug 2013 03:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 c33NnG8k175z for ; Mon, 5 Aug 2013 03:43:36 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E307621F9E3C for ; Mon, 5 Aug 2013 03:43:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17080; q=dns/txt; s=iport; t=1375699416; x=1376909016; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=1oY8l5vS9EvIb9Qnq0WYcJdW9fE3fSIy0wrwKce6nu0=; b=mTi9W0abyg6az3fDKx5cT4h4HTeEzRY58Z9fZGxJTMtK6kh7wGJ3rggU Ax1HJbQ6jmIewHFI1rsDBYb/w2MwcYH0rW8gEgIOk3+hfLllhbBgk/4uv vdgLsOZBTx5+1Hix8Kfpvj7t28AiGLnDNjGniCE3cZVLFFjIqd67PEcwl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAA+B/1GtJXHA/2dsb2JhbABagwY1v0mBHxZ0giQBAQEEAQEBNTYbCxgJDBkPAhYwEAMGAgEBiAwMtF+PZjoKhAMDl2CBKpAlgzMg X-IronPort-AV: E=Sophos;i="4.89,817,1367971200"; d="scan'208";a="243492027" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 05 Aug 2013 10:43:35 +0000 Received: from rtp-swainner-8919.cisco.com (rtp-swainner-8919.cisco.com [10.116.109.202]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r75AhYq2015905 for ; Mon, 5 Aug 2013 10:43:34 GMT Message-ID: <51FF81D6.204@cisco.com> Date: Mon, 05 Aug 2013 06:43:34 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cdni@ietf.org References: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [CDNi] New Text for Framework on URI Rewriting 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, 05 Aug 2013 10:43:42 -0000 I was following along the "Concise Option" until the last paragraph. Alternative suggested in line ... On 8/5/13 4:39 AM, Francois Le Faucheur (flefauch) wrote: > Folks, > > Someone suggested privately that perhaps we are trying to provide too m= uch details here, and that we may be finally blurring the point that is n= ot that complicated. So I'd like to offer an alternative text that aims a= t capturing the point accurately but succinctly. So you'll find below: > * a Concise Option (new) > * a Verbose Option (same as in my earlier message with minor editorial= enhancements) > Let us know which you favor (or if you have alternative proposals to of= fer). > > Francois > > > Concise Option > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > " > Metadata & URI Rewriting > > When using HTTP redirection, content URIs will be rewritten when redire= ction takes place within an uCDN, when redirection takes place from an uC= DN to a dCDN and when redirection takes place within a dCDN. In the case = of cascaded CDNs, content URIs may be rewritten at every CDN hop between = the uCDN and the dCDN serving the request. URI rewriting needs to be take= n into account for the implementation of some CDNI interfaces. > > Consider the simple case: a single uCDN and dCDN. This section refers: > * to a URI requested of the uCDN as a "u-URI" > * to a URI used in CDNI interactions between the uCDN and dCDN as a "u= d-URI" > * to a URI requested of the dCDN as a "d-URI" > > In a given deployment situation, the ud-URI plan may be different or th= e same as the u-URI plan, and the d-URI plan may be different or the same= as the ud-URI plan. Any combination is possible. For example, where DNS = redirection is used the u-URI, ud-URI and d-URI plans will all be the sam= e. As another example, where HTTP request routing in iterative mode is us= ed, the uCDN will redirect the user-agent to the dCDN using a ud-URI (e.g= =2E ucdn.dcdn.com/csp/xyz) in a plan that will be different to the u-URI = plan (e.g. csp.ucdn.com/xyz), and in turn the dCDN request routing system= may redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn= =2Ecom/ucdn/csp/xyz) in a plan that is different to the ud-URI plan. > > Most CDNI interfaces involve content URIs. For example, in the case of = the CDNI Logging interface, each log record may reference a content URI. = In the case of the CDNI Metadata interface, the dCDN must query the uCDN = for metadata based on a content URI. > > It is the responsibility of the uCDN (respectively dCDN) to ensure that= a content URI communicated to the dCDN (respectively uCDN) are always ex= pressed in the ud-URI plan for the particular dCDN (respectively uCDN). W= hen the content URI has been derived from information expressing content = URIs in a different plan, the uCDN (respectively dCDN) needs to map the c= ontent URI into the ud-URI plan (for the given pair of uCDN and dCDN) for= conveying it as a content URI in a CDNI interface. > " It is the responsibility of the uCDN to ensure that a content URI=20 communicated to the dCDN is always expressed in the ud-URI plan. When a=20 uCDN receives a content URI request conveying information that uses a=20 different plan, the uCDN must map the content URI into the ud-URI plan=20 in accordance with the capabilities of a chosen dCDN. The CDNI=20 interfaces RI, MI, and LI must reference the ud-URI for purposes of=20 request routing, metadata, and logging, respectively. > > > Verbose Option: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > " > Metadata & URI Rewriting > > When using HTTP redirection, content URIs will be rewritten when redire= ction takes place within an uCDN, when redirection takes place from an uC= DN to a dCDN and when redirection takes place within a dCDN. In the case = of cascaded CDNs, content URIs may be rewritten at every CDN hop between = the uCDN and the dCDN serving the request. URI rewriting needs to be take= n into account for the implementation of some CDNI interfaces. > > Consider the simple case: a single uCDN and dCDN. This section refers: > * to a URI requested of the uCDN as a "u-URI" > * to a URI used in CDNI interactions between the uCDN and dCDN as a "u= d-URI" > * to a URI requested of the dCDN as a "d-URI" > > In a given deployment situation, the ud-URI plan may be different or th= e same as the u-URI plan, and the d-URI plan may be different or the same= as the ud-URI plan. Any combination is possible. For example, where DNS = redirection is used the u-URI, ud-URI and d-URI plans will all be the sam= e. As another example, where HTTP request routing in iterative mode is us= ed, the uCDN will redirect the user-agent to the dCDN using a ud-URI (e.g= =2E ucdn.dcdn.com/csp/xyz) in a plan that will be different to the u-URI = plan (e.g. csp.ucdn.com/xyz), and in turn the dCDN request routing system= may redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn= =2Ecom/ucdn/csp/xyz) in a plan that is different to the ud-URI plan. > > Most CDNI interfaces involve content URIs. For example, in the case of = the CDNI Logging interface, each log record may reference a content URI. = In the case of the CDNI Metadata interface, the dCDN must query the uCDN = for metadata based on a content URI. > > Any CDNI interface between an uCDN and a dCDN which relies on content U= RIs needs to convey URIs in that interface in the ud-URI plan for the giv= en pair of CDNs. > > When the dCDN is transfering CDNI information to the uCDN including a c= ontent URI, it is the responsibility of the dCDN to use the ud-URI plan a= nd, if required, to map back a d-URI into a ud-URI. For example, if the d= CDN uses a d-URI plan that is different to the ud-URI plan, the dCDN need= s to map back the d-URIs into ud-URIs for inclusion in the CDNI Logging i= nterface. > > When the uCDN is transfering CDNI information to the dCDN including a c= ontent URI, it is the responsibility of the dCDN to use the ud-URI plan w= hen conveying content URIs. For example, if the uCDN uses a d-URI plan th= at is different from the ud-URI plan, it is the responsibility of the uCD= N to ensure content URIs used in the CDNI Metadata interface are expresse= d in the ud-URI plan. Also, if the dCDN uses a d-URI plan that is differe= nt from the ud-URI plan, it is the responsibility of the dCDN to correlat= e d-URIs in content requests with metadata obtained from the uCDN express= ed in the ud-URI plan. > > Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 a= cting as the transit CDN and CDN3 acting as the dCDN. This section refers= : > * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as a= ud-URI-ut > * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 as a= ud-URI-td > > In a given deployment situation the ud-URI-td plan may be different or = the same as the ud-URI-ut plan. For example, when DNS request routing is = used at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the = same. When HTTP request routing is used at every CDN hop, the ud-URI-td p= lan and ud-URI-ut plan will be different. > > When, in his role of transit CDN, CDN2 turns information obtained on a = CDNI interface from the dCDN (respectively uCDN) into information transmi= tted to the uCDN (respectively dCDN) on the corresponding CDNI interface,= it is the responsibility of the transit CDN to convert content URIs from= the ud-URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-u= t plan to the ud-URI-td plan). > > For example, when the transit CDN receives CDNI logging records from th= e dCDN with content URIs expressed in the ud-URI-td plan, and when the tr= ansit CDN includes the corresponding CDNI logging records for transmissio= n to the uCDN over the CDNI Logging interface, the transit CDN needs to m= ap the content URIs expressed in the ud-URI-td plan into URIs expressed i= nto the ud-URI-ut plan. Similarly, when the transit CDN receives CDNI met= adata information from the uCDN with content URIs expressed in the ud-URI= -ut plan, and when the transit CDN includes the corresponfing CDNI metada= ta information for transmission to the dCDN over the CDNI Metadata interf= ace, the transit CDN needs to map the content URIs expressed in the ud-UR= I-ut plan into content URIs expressed in the ud-URI-td plan. Regarding me= tadata information, note that (even when the ud-URI-ut plan and ud-URI-td= plan are the same) the transit CDN is also likely to have to perform rew= riting on some other metadata information. > For example, any metadata which references the immediately upstream CDN= (such as content acquisition metadata) should be rewritten as the metada= ta is passed between CDNs. > " > > > >> " >> Metadata & URI Rewriting >> >> When using HTTP redirection, content URIs will be rewritten between uC= DNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritte= n at every CDN hop between uCDN and dCDN. URI rewriting needs to be taken= into account for the implementation of some CDNI interfaces. >> >> Consider the simple case: a single uCDN and dCDN. This section refers:= >> * to a URI requested of the uCDN as a "u-URI" >> * to a URI used in CDNI interactions between the uCDN and dCDN as a "= ud-URI" >> * to a URI requested of the dCDN as a "dCDN URI" >> >> In a given deployment situation, the ud-URI plan may be different or t= he same as the u-URI plan, and the d-URI plan may be different or the sam= e as the ud-URI plan. Any combination is possible. For example, where DNS= redirection is used the u-URI, ud-URI and d-URI plans will all be the sa= me. As another example, where HTTP request routing in iterative mode is u= sed, the uCDN will redirect the user-agent to the dCDN using a ud-URI (e.= g. ucdn.dcdn.com/csp/xyz) in a plan that will be different to the u-URI p= lan (e.g. csp.ucdn.com/xyz), and in turn the dCDN request routing system = may redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.= com/ucdn/csp/xyz) in a plan that is different to the ud-URI plan. >> >> Most CDNI interfaces involve content URIs. For example, in the case of= the CDNI Logging interface, each log record may reference a content URI.= In the case of the CDNI Metadata interface, the dCDN must query the uCDN= for metadata based on a content URI. >> >> Any CDNI interface between an uCDN and a dCDN which relies on content = URIs needs to convey URIs in that interface in the ud-URI plan for the gi= ven pair of CDNs. >> >> When the dCDN is transfering CDNI information to the uCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan = and, if required, to map back a d-URI into a ud-URI. For example, if the = dCDN uses a d-URI plan that is different to the ud-URI plan, the dCDN nee= ds to map back the d-URIs into ud-URIs for inclusion in the CDNI Logging = interface. >> >> When the uCDN is transfering CDNI information to the dCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan = when conveying content URIs. For example, if the uCDN uses a d-URI plan t= hat is different from the ud-URI plan, it is the responsibility of the uC= DN to ensure content URIs used in the CDNI Metadata interface are express= ed in the ud-URI plan. Also, if the dCDN uses a d-URI plan that is differ= ent from the ud-URI plan, it is the responsibility of the dCDN to correla= te d-URIs in content requests with metadata obtained from the uCDN expres= sed in the ud-URI plan. >> >> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 = acting as the transit CDN and CDN3 acting as the dCDN. This section refer= s: >> * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as = a ud-URI-ut >> * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 as = a ud-URI-td >> >> In a given deployment situation the ud-URI-td plan may be different or= the same as the ud-URI-ut plan. For example, when DNS request routing is= used at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the= same. When HTTP request routing is used at every CDN hop, the ud-URI-td = plan and ud-URI-ut plan will be different. >> >> When, in his role of transit CDN, CDN2 turns information obtained on a= CDNI interface from the dCDN (respectively uCDN) into information transm= itted to the uCDN (respectively dCDN) on the corresponding CDNI interface= , it is the responsibility of the transit CDN to convert content URIs fro= m the ud-URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-= ut plan to the ud-URI-td plan). >> >> For example, when the transit CDN receives CDNI logging records from t= he dCDN with content URIs expressed in the ud-URI-td plan, and when the t= ransit CDN includes the corresponding CDNI logging records for transmissi= on to the uCDN over the CDNI Logging interface, the transit CDN needs to = map the content URIs expressed in the ud-URI-td plan into URIs expressed = into the ud-URI-ut plan. Similarly, when the transit CDN receives CDNI me= tadata information from the uCDN with content URIs expressed in the ud-UR= I-ut plan, and when the transit CDN includes the corresponfing CDNI metad= ata information for transmission to the dCDN over the CDNI Metadata inter= face, the transit CDN needs to map the content URIs expressed in the ud-U= RI-ut plan into content URIs expressed in the ud-URI-td plan. Regarding m= etadata information, note that (even when the ud-URI-ut plan and ud-URI-t= d plan are the same) the transit CDN is also likely to have to perform re= writing on some other metadata information > . >> For example, any metadata which references the immediately upstream CD= N (such as content acquisition metadata) should be rewritten as the metad= ata is passed between CDNs. >> " >> >> Francois >> >> On 1 Aug 2013, at 22:41, Matt Caulfield (mcaulfie) wrote: >> >>> Hi everyone, >>> >>> Based on comments this week regarding the URI Rewriting section of th= e CDNI Framework document I have put together a revised section which aim= s to touch on the key points more clearly. Please share your feedback on = the text below. If it is suitable, we can incorporate into the next revis= ion of draft-ietf-cdni-framework. >>> >>> Thanks, >>> Matt >>> >>> Metadata & URI Rewriting >>> >>> When using HTTP redirection, content URIs will be rewritten between u= CDNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritt= en multiple times between uCDN and dCDN. URI rewriting poses a special ch= allenge for the implementation of some CDNI interfaces. >> >> >>> Consider the simple case: a single uCDN and dCDN. This section refers= to the URI requested of the uCDN as the "uCDN URI" and the URI requested= of the dCDN as the "dCDN URI". >>> >>> Any CDNI interface which relies on content URIs must state explicitly= which URI is to be used - the dCDN URI or the uCDN URI. For example, in = the case of the Logging Interface, each log message may reference a conte= nt URI. In the case of the Metadata Interface, the dCDN must query for th= e uCDN for metadata based on a content URI. >>> >>> For all CDNI interfaces, the dCDN should translate any dCDN URIs to u= CDN URIs before interacting with the uCDN. For logging, this approach req= uires the dCDN to translate any dCDN URIs in its log messages into uCDN U= RIs. For metadata, this approach requires the dCDN to translate any dCDN = URIs into uCDN URIs before querying the uCDN for metadata. >>> >>> In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and= therefore is capable of translating from uCDN URI to dCDN URI and vice v= ersa. In iterative mode, an out-of-band agreement instructs the uCDN and = dCDN how to translate from uCDN URI to dCDN URI and vice versa. In either= mode, the dCDN is capable of translating dCDN URIs into uCDN URIs before= interacting with the uCDN. >>> >>> Note that even in the DNS redirection case, some URI rewriting is sti= ll necessary. For example, any metadata which references the immediately = upstream CDN (such as content acquisition metadata) should be rewritten a= s the metadata is passed between CDNs. However, given that DNS redirectio= n does not change the content URI, many of the concerns addressed above w= ith HTTP redirection do not apply. >>> >>> _______________________________________________ >>> 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 swainner@cisco.com Mon Aug 5 13:55:54 2013 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 A96E121F9E45 for ; Mon, 5 Aug 2013 13:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 iI21ZOEFnUYo for ; Mon, 5 Aug 2013 13:55:50 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2F321F9E3B for ; Mon, 5 Aug 2013 13:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20244; q=dns/txt; s=iport; t=1375736150; x=1376945750; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Zh9oCjIrIq1AtTk02/nOI98SNxU6ygP3e687CbWFntY=; b=QQNPgO96LyGnmHD7H2VIXHMFCRkh8UQfXRlWNkDqtzHa+lYnG++pXVUR WQThU94UKMoIqYO+iy/SnnwG+hCTUUbzCORUBSy0IYnl6Z+4NSB+V0KQt U8DbiDwrM0v0UWnhNu4nOUD9ThfZjTf1bYnQwA+1Fd/aDO9sBgxWhtfIF w=; X-IronPort-AV: E=Sophos;i="4.89,821,1367971200"; d="scan'208";a="243759785" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 05 Aug 2013 20:55:47 +0000 Received: from rtp-swainner-8919.cisco.com (rtp-swainner-8919.cisco.com [10.116.109.202]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r75KtkHr025315; Mon, 5 Aug 2013 20:55:46 GMT Message-ID: <52001152.5070200@cisco.com> Date: Mon, 05 Aug 2013 16:55:46 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cdni@ietf.org, Francois Le Faucheur References: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> <51FF81D6.204@cisco.com> In-Reply-To: <51FF81D6.204@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CDNi] New Text for Framework on URI Rewriting 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, 05 Aug 2013 20:55:54 -0000 Francois, May I suggest we re-write the paragraphs as follows: Metadata & URI Rewriting ------------------------ When using HTTP redirection, content URIs may be rewritten when redirection takes place within an uCDN, from an uCDN to a dCDN, and within the dCDN. In the case of cascaded CDNs, content URIs may be rewritten at every CDN hop e.g between the uCDN and the dCDN acting as the transit CDN, and between the transit CDN and the dCDN serving the request. The content URI used between a specific pair of uCDN and dCDN becomes a common handle that can be referred to without ambiguity by both CDNs of the specific pair of uCDN and dCDN in all their inter-CDN communications. The handle allows the uCDN and dCDN to correlate information exchanged in CDNI interfaces in both the downstream direction (e.g. when using the MI) and the upstream direction (e.g. when using the LI). Consider the simple case: a single uCDN and dCDN pair using HTTP redirection. This section defines the content URIs as follows: "u-URI" represents a content URI in a request presented to the uCDN "ud-URI" is a content URI acting as the common handle across uCDN and dCDN for requests redirected by the uCDN to a specific dCDN "d-URI" represents a content URI in a request made within the delegate dCDN The "ud-URI" effectively becomes the handle which the uCDN and dCDN pair correlate all CDNI information. In particular, for a given pair of CDNs executing the HTTP redirection, the uCDN needs to map the u-URI to the ud-URI handle for all MI message exchanges, while the dCDN needs to map the d-URI to the ud-URI handle for all LI message exchanges. In the case of a cascaded CDNs, the transit CDN will re-write the content URI when redirecting to the dCDN, thereby establishing a new handle between the transit CDN and the dCDN, that is different from the handle between the uCDN and transit CDN. It is the responsibility of the transit CDN to manage its mapping across handles so the right handle for the specific pair of CDNs is always used in its CDNI communication. In summary, all CDNI interfaces between a given pair of CDNs need to always use the "ud-URI" handle for that specific CDN pair, as their content URI reference. Scott Wainner On 8/5/13 6:43 AM, Scott Wainner wrote: > I was following along the "Concise Option" until the last paragraph. > > Alternative suggested in line ... > > On 8/5/13 4:39 AM, Francois Le Faucheur (flefauch) wrote: >> Folks, >> >> Someone suggested privately that perhaps we are trying to provide too >> much details here, and that we may be finally blurring the point that >> is not that complicated. So I'd like to offer an alternative text >> that aims at capturing the point accurately but succinctly. So you'll >> find below: >> * a Concise Option (new) >> * a Verbose Option (same as in my earlier message with minor >> editorial enhancements) >> Let us know which you favor (or if you have alternative proposals to >> offer). >> >> Francois >> >> >> Concise Option >> =========== >> " >> Metadata & URI Rewriting >> >> When using HTTP redirection, content URIs will be rewritten when >> redirection takes place within an uCDN, when redirection takes place >> from an uCDN to a dCDN and when redirection takes place within a >> dCDN. In the case of cascaded CDNs, content URIs may be rewritten at >> every CDN hop between the uCDN and the dCDN serving the request. URI >> rewriting needs to be taken into account for the implementation of >> some CDNI interfaces. >> >> Consider the simple case: a single uCDN and dCDN. This section refers: >> * to a URI requested of the uCDN as a "u-URI" >> * to a URI used in CDNI interactions between the uCDN and dCDN as >> a "ud-URI" >> * to a URI requested of the dCDN as a "d-URI" >> >> In a given deployment situation, the ud-URI plan may be different or >> the same as the u-URI plan, and the d-URI plan may be different or >> the same as the ud-URI plan. Any combination is possible. For >> example, where DNS redirection is used the u-URI, ud-URI and d-URI >> plans will all be the same. As another example, where HTTP request >> routing in iterative mode is used, the uCDN will redirect the >> user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.com/csp/xyz) in >> a plan that will be different to the u-URI plan (e.g. >> csp.ucdn.com/xyz), and in turn the dCDN request routing system may >> redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. >> dcdn.com/ucdn/csp/xyz) in a plan that is different to the ud-URI plan. >> >> Most CDNI interfaces involve content URIs. For example, in the case >> of the CDNI Logging interface, each log record may reference a >> content URI. In the case of the CDNI Metadata interface, the dCDN >> must query the uCDN for metadata based on a content URI. >> >> It is the responsibility of the uCDN (respectively dCDN) to ensure >> that a content URI communicated to the dCDN (respectively uCDN) are >> always expressed in the ud-URI plan for the particular dCDN >> (respectively uCDN). When the content URI has been derived from >> information expressing content URIs in a different plan, the uCDN >> (respectively dCDN) needs to map the content URI into the ud-URI plan >> (for the given pair of uCDN and dCDN) for conveying it as a content >> URI in a CDNI interface. >> " > It is the responsibility of the uCDN to ensure that a content URI > communicated to the dCDN is always expressed in the ud-URI plan. When > a uCDN receives a content URI request conveying information that uses > a different plan, the uCDN must map the content URI into the ud-URI > plan in accordance with the capabilities of a chosen dCDN. The CDNI > interfaces RI, MI, and LI must reference the ud-URI for purposes of > request routing, metadata, and logging, respectively. >> >> >> Verbose Option: >> ============ >> >> " >> Metadata & URI Rewriting >> >> When using HTTP redirection, content URIs will be rewritten when >> redirection takes place within an uCDN, when redirection takes place >> from an uCDN to a dCDN and when redirection takes place within a >> dCDN. In the case of cascaded CDNs, content URIs may be rewritten at >> every CDN hop between the uCDN and the dCDN serving the request. URI >> rewriting needs to be taken into account for the implementation of >> some CDNI interfaces. >> >> Consider the simple case: a single uCDN and dCDN. This section refers: >> * to a URI requested of the uCDN as a "u-URI" >> * to a URI used in CDNI interactions between the uCDN and dCDN as >> a "ud-URI" >> * to a URI requested of the dCDN as a "d-URI" >> >> In a given deployment situation, the ud-URI plan may be different or >> the same as the u-URI plan, and the d-URI plan may be different or >> the same as the ud-URI plan. Any combination is possible. For >> example, where DNS redirection is used the u-URI, ud-URI and d-URI >> plans will all be the same. As another example, where HTTP request >> routing in iterative mode is used, the uCDN will redirect the >> user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.com/csp/xyz) in >> a plan that will be different to the u-URI plan (e.g. >> csp.ucdn.com/xyz), and in turn the dCDN request routing system may >> redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. >> dcdn.com/ucdn/csp/xyz) in a plan that is different to the ud-URI plan. >> >> Most CDNI interfaces involve content URIs. For example, in the case >> of the CDNI Logging interface, each log record may reference a >> content URI. In the case of the CDNI Metadata interface, the dCDN >> must query the uCDN for metadata based on a content URI. >> >> Any CDNI interface between an uCDN and a dCDN which relies on content >> URIs needs to convey URIs in that interface in the ud-URI plan for >> the given pair of CDNs. >> >> When the dCDN is transfering CDNI information to the uCDN including a >> content URI, it is the responsibility of the dCDN to use the ud-URI >> plan and, if required, to map back a d-URI into a ud-URI. For >> example, if the dCDN uses a d-URI plan that is different to the >> ud-URI plan, the dCDN needs to map back the d-URIs into ud-URIs for >> inclusion in the CDNI Logging interface. >> >> When the uCDN is transfering CDNI information to the dCDN including a >> content URI, it is the responsibility of the dCDN to use the ud-URI >> plan when conveying content URIs. For example, if the uCDN uses a >> d-URI plan that is different from the ud-URI plan, it is the >> responsibility of the uCDN to ensure content URIs used in the CDNI >> Metadata interface are expressed in the ud-URI plan. Also, if the >> dCDN uses a d-URI plan that is different from the ud-URI plan, it is >> the responsibility of the dCDN to correlate d-URIs in content >> requests with metadata obtained from the uCDN expressed in the ud-URI >> plan. >> >> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 >> acting as the transit CDN and CDN3 acting as the dCDN. This section >> refers: >> * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 >> as a ud-URI-ut >> * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 >> as a ud-URI-td >> >> In a given deployment situation the ud-URI-td plan may be different >> or the same as the ud-URI-ut plan. For example, when DNS request >> routing is used at every CDN hop, the ud-URI-td plan and ud-URI-ut >> plan will be the same. When HTTP request routing is used at every CDN >> hop, the ud-URI-td plan and ud-URI-ut plan will be different. >> >> When, in his role of transit CDN, CDN2 turns information obtained on >> a CDNI interface from the dCDN (respectively uCDN) into information >> transmitted to the uCDN (respectively dCDN) on the corresponding CDNI >> interface, it is the responsibility of the transit CDN to convert >> content URIs from the ud-URI-td plan to the ud-URI-ut plan >> (respectively from the ud-URI-ut plan to the ud-URI-td plan). >> >> For example, when the transit CDN receives CDNI logging records from >> the dCDN with content URIs expressed in the ud-URI-td plan, and when >> the transit CDN includes the corresponding CDNI logging records for >> transmission to the uCDN over the CDNI Logging interface, the transit >> CDN needs to map the content URIs expressed in the ud-URI-td plan >> into URIs expressed into the ud-URI-ut plan. Similarly, when the >> transit CDN receives CDNI metadata information from the uCDN with >> content URIs expressed in the ud-URI-ut plan, and when the transit >> CDN includes the corresponfing CDNI metadata information for >> transmission to the dCDN over the CDNI Metadata interface, the >> transit CDN needs to map the content URIs expressed in the ud-URI-ut >> plan into content URIs expressed in the ud-URI-td plan. Regarding >> metadata information, note that (even when the ud-URI-ut plan and >> ud-URI-td plan are the same) the transit CDN is also likely to have >> to perform rewriting on some other metadata information > . >> For example, any metadata which references the immediately upstream >> CDN (such as content acquisition metadata) should be rewritten as the >> metadata is passed between CDNs. >> " >> >> >> >>> " >>> Metadata & URI Rewriting >>> >>> When using HTTP redirection, content URIs will be rewritten between >>> uCDNs and dCDNs. In the case of cascaded CDNs, content URIs may be >>> rewritten at every CDN hop between uCDN and dCDN. URI rewriting >>> needs to be taken into account for the implementation of some CDNI >>> interfaces. >>> >>> Consider the simple case: a single uCDN and dCDN. This section refers: >>> * to a URI requested of the uCDN as a "u-URI" >>> * to a URI used in CDNI interactions between the uCDN and dCDN >>> as a "ud-URI" >>> * to a URI requested of the dCDN as a "dCDN URI" >>> >>> In a given deployment situation, the ud-URI plan may be different or >>> the same as the u-URI plan, and the d-URI plan may be different or >>> the same as the ud-URI plan. Any combination is possible. For >>> example, where DNS redirection is used the u-URI, ud-URI and d-URI >>> plans will all be the same. As another example, where HTTP request >>> routing in iterative mode is used, the uCDN will redirect the >>> user-agent to the dCDN using a ud-URI (e.g. ucdn.dcdn.com/csp/xyz) >>> in a plan that will be different to the u-URI plan (e.g. >>> csp.ucdn.com/xyz), and in turn the dCDN request routing system may >>> redirect the user-agent to a dCDN Surrogate using a d-URI (e.g. >>> dcdn.com/ucdn/csp/xyz) in a plan that is different to the ud-URI plan. >>> >>> Most CDNI interfaces involve content URIs. For example, in the case >>> of the CDNI Logging interface, each log record may reference a >>> content URI. In the case of the CDNI Metadata interface, the dCDN >>> must query the uCDN for metadata based on a content URI. >>> >>> Any CDNI interface between an uCDN and a dCDN which relies on >>> content URIs needs to convey URIs in that interface in the ud-URI >>> plan for the given pair of CDNs. >>> >>> When the dCDN is transfering CDNI information to the uCDN including >>> a content URI, it is the responsibility of the dCDN to use the >>> ud-URI plan and, if required, to map back a d-URI into a ud-URI. For >>> example, if the dCDN uses a d-URI plan that is different to the >>> ud-URI plan, the dCDN needs to map back the d-URIs into ud-URIs for >>> inclusion in the CDNI Logging interface. >>> >>> When the uCDN is transfering CDNI information to the dCDN including >>> a content URI, it is the responsibility of the dCDN to use the >>> ud-URI plan when conveying content URIs. For example, if the uCDN >>> uses a d-URI plan that is different from the ud-URI plan, it is the >>> responsibility of the uCDN to ensure content URIs used in the CDNI >>> Metadata interface are expressed in the ud-URI plan. Also, if the >>> dCDN uses a d-URI plan that is different from the ud-URI plan, it is >>> the responsibility of the dCDN to correlate d-URIs in content >>> requests with metadata obtained from the uCDN expressed in the >>> ud-URI plan. >>> >>> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, >>> CDN2 acting as the transit CDN and CDN3 acting as the dCDN. This >>> section refers: >>> * to a ud-URI involved in CDNI interactions between CDN1 and >>> CDN2 as a ud-URI-ut >>> * to a ud-URI involved in CDNI interactions between CDN2 and >>> CDN3 as a ud-URI-td >>> >>> In a given deployment situation the ud-URI-td plan may be different >>> or the same as the ud-URI-ut plan. For example, when DNS request >>> routing is used at every CDN hop, the ud-URI-td plan and ud-URI-ut >>> plan will be the same. When HTTP request routing is used at every >>> CDN hop, the ud-URI-td plan and ud-URI-ut plan will be different. >>> >>> When, in his role of transit CDN, CDN2 turns information obtained on >>> a CDNI interface from the dCDN (respectively uCDN) into information >>> transmitted to the uCDN (respectively dCDN) on the corresponding >>> CDNI interface, it is the responsibility of the transit CDN to >>> convert content URIs from the ud-URI-td plan to the ud-URI-ut plan >>> (respectively from the ud-URI-ut plan to the ud-URI-td plan). >>> >>> For example, when the transit CDN receives CDNI logging records from >>> the dCDN with content URIs expressed in the ud-URI-td plan, and when >>> the transit CDN includes the corresponding CDNI logging records for >>> transmission to the uCDN over the CDNI Logging interface, the >>> transit CDN needs to map the content URIs expressed in the ud-URI-td >>> plan into URIs expressed into the ud-URI-ut plan. Similarly, when >>> the transit CDN receives CDNI metadata information from the uCDN >>> with content URIs expressed in the ud-URI-ut plan, and when the >>> transit CDN includes the corresponfing CDNI metadata information for >>> transmission to the dCDN over the CDNI Metadata interface, the >>> transit CDN needs to map the content URIs expressed in the ud-URI-ut >>> plan into content URIs expressed in the ud-URI-td plan. Regarding >>> metadata information, note that (even when the ud-URI-ut plan and >>> ud-URI-td plan are the same) the transit CDN is also likely to have >>> to perform rewriting on some other metadata informatio > n >> . >>> For example, any metadata which references the immediately upstream >>> CDN (such as content acquisition metadata) should be rewritten as >>> the metadata is passed between CDNs. >>> " >>> >>> Francois >>> >>> On 1 Aug 2013, at 22:41, Matt Caulfield (mcaulfie) >>> wrote: >>> >>>> Hi everyone, >>>> >>>> Based on comments this week regarding the URI Rewriting section of >>>> the CDNI Framework document I have put together a revised section >>>> which aims to touch on the key points more clearly. Please share >>>> your feedback on the text below. If it is suitable, we can >>>> incorporate into the next revision of draft-ietf-cdni-framework. >>>> >>>> Thanks, >>>> Matt >>>> >>>> Metadata & URI Rewriting >>>> >>>> When using HTTP redirection, content URIs will be rewritten between >>>> uCDNs and dCDNs. In the case of cascaded CDNs, content URIs may be >>>> rewritten multiple times between uCDN and dCDN. URI rewriting poses >>>> a special challenge for the implementation of some CDNI interfaces. >>> >>> >>>> Consider the simple case: a single uCDN and dCDN. This section >>>> refers to the URI requested of the uCDN as the "uCDN URI" and the >>>> URI requested of the dCDN as the "dCDN URI". >>>> >>>> Any CDNI interface which relies on content URIs must state >>>> explicitly which URI is to be used - the dCDN URI or the uCDN URI. >>>> For example, in the case of the Logging Interface, each log message >>>> may reference a content URI. In the case of the Metadata Interface, >>>> the dCDN must query for the uCDN for metadata based on a content URI. >>>> >>>> For all CDNI interfaces, the dCDN should translate any dCDN URIs to >>>> uCDN URIs before interacting with the uCDN. For logging, this >>>> approach requires the dCDN to translate any dCDN URIs in its log >>>> messages into uCDN URIs. For metadata, this approach requires the >>>> dCDN to translate any dCDN URIs into uCDN URIs before querying the >>>> uCDN for metadata. >>>> >>>> In recursive mode, the dCDN is queried by the uCDN for a dCDN URI >>>> and therefore is capable of translating from uCDN URI to dCDN URI >>>> and vice versa. In iterative mode, an out-of-band agreement >>>> instructs the uCDN and dCDN how to translate from uCDN URI to dCDN >>>> URI and vice versa. In either mode, the dCDN is capable of >>>> translating dCDN URIs into uCDN URIs before interacting with the uCDN. >>>> >>>> Note that even in the DNS redirection case, some URI rewriting is >>>> still necessary. For example, any metadata which references the >>>> immediately upstream CDN (such as content acquisition metadata) >>>> should be rewritten as the metadata is passed between CDNs. >>>> However, given that DNS redirection does not change the content >>>> URI, many of the concerns addressed above with HTTP redirection do >>>> not apply. >>>> >>>> _______________________________________________ >>>> 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 Tue Aug 6 05:20:36 2013 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 5D67F21F9C2E for ; Tue, 6 Aug 2013 05:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 Ir15wqSlZV9d for ; Tue, 6 Aug 2013 05:20:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1916321F9C16 for ; Tue, 6 Aug 2013 05:20:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20321; q=dns/txt; s=iport; t=1375791629; x=1377001229; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=L2z9vPlzAxpWJq+GLG3SuYjctw9MsGwPPn7uLFaK/ng=; b=GOgfXIOtG4rsUdA1WeLhkQgusNfqP/2SJrJv0I6tlp9K1hECAipvbnqO 0fb3ZiyAAOkLMHVhQHW+SOa3ZlE3SCmvrJSUWDj2k7/B7AfB7cyvXNyiI nKqGTTAYzp0cdH3wzSt6uLsSg+agl/hLgQJNYt/C6k/+k3yGn8Rpy9Fmv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAMzoAFKtJXHA/2dsb2JhbABbgwY1RAy+fYEfFnSCJAEBAQMBAQEBawsFCwIBCBgKCxknCyUBAQQKBAUIiAIGDLZJj2cCMQcKgxB0A4hzkBiQJIMXgio X-IronPort-AV: E=Sophos;i="4.89,826,1367971200"; d="scan'208";a="244054699" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 06 Aug 2013 12:20:27 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r76CKREn032210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 Aug 2013 12:20:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 07:20:26 -0500 From: "Francois Le Faucheur (flefauch)" To: "Scott Wainner (swainner)" Thread-Topic: [CDNi] New Text for Framework on URI Rewriting Thread-Index: Ac6O92zds42pB4QjSEezI1Jqeu28AgAtnYUAAIzUnYAADzzzPQAqw+kA Date: Tue, 6 Aug 2013 12:20:26 +0000 Message-ID: References: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> <51FF81D6.204@cisco.com> <52001152.5070200@cisco.com> In-Reply-To: <52001152.5070200@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <26C8DA8C0556444897B628962E540D68@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Text for Framework on URI Rewriting 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, 06 Aug 2013 12:20:38 -0000 Hi Scott, That can work for me. Opnion anyone? Francois On 5 Aug 2013, at 22:55, Scott Wainner wrote: > Francois, >=20 > May I suggest we re-write the paragraphs as follows: >=20 > Metadata & URI Rewriting > ------------------------ >=20 > When using HTTP redirection, content URIs may be rewritten when redirecti= on takes place within an uCDN, from an uCDN to a dCDN, and within the dCDN.= In the case of cascaded CDNs, content URIs may be rewritten at every CDN h= op e.g between the uCDN and the dCDN acting as the transit CDN, and between= the transit CDN and the dCDN serving the request. The content URI used bet= ween a specific pair of uCDN and dCDN becomes a common handle that can be r= eferred to without ambiguity by both CDNs of the specific pair of uCDN and = dCDN in all their inter-CDN communications. The handle allows the uCDN and = dCDN to correlate information exchanged in CDNI interfaces in both the down= stream direction (e.g. when using the MI) and the upstream direction (e.g. = when using the LI). >=20 > Consider the simple case: a single uCDN and dCDN pair using HTTP redirect= ion. This section defines the content URIs as follows: >=20 > "u-URI" represents a content URI in a request presented to the uCDN > "ud-URI" is a content URI acting as the common handle across uCDN and d= CDN for requests redirected by the uCDN to a specific dCDN > "d-URI" represents a content URI in a request made within the delegate = dCDN >=20 > The "ud-URI" effectively becomes the handle which the uCDN and dCDN pair = correlate all CDNI information. In particular, for a given pair of CDNs exe= cuting the HTTP redirection, the uCDN needs to map the u-URI to the ud-URI = handle for all MI message exchanges, while the dCDN needs to map the d-URI = to the ud-URI handle for all LI message exchanges. >=20 > In the case of a cascaded CDNs, the transit CDN will re-write the content= URI when redirecting to the dCDN, thereby establishing a new handle betwee= n the transit CDN and the dCDN, that is different from the handle between t= he uCDN and transit CDN. It is the responsibility of the transit CDN to man= age its mapping across handles so the right handle for the specific pair of= CDNs is always used in its CDNI communication. >=20 > In summary, all CDNI interfaces between a given pair of CDNs need to alwa= ys use the "ud-URI" handle for that specific CDN pair, as their content URI= reference. >=20 > Scott Wainner >=20 >=20 >=20 > On 8/5/13 6:43 AM, Scott Wainner wrote: >> I was following along the "Concise Option" until the last paragraph. >>=20 >> Alternative suggested in line ... >>=20 >> On 8/5/13 4:39 AM, Francois Le Faucheur (flefauch) wrote: >>> Folks, >>>=20 >>> Someone suggested privately that perhaps we are trying to provide too m= uch details here, and that we may be finally blurring the point that is not= that complicated. So I'd like to offer an alternative text that aims at ca= pturing the point accurately but succinctly. So you'll find below: >>> * a Concise Option (new) >>> * a Verbose Option (same as in my earlier message with minor editori= al enhancements) >>> Let us know which you favor (or if you have alternative proposals to of= fer). >>>=20 >>> Francois >>>=20 >>>=20 >>> Concise Option >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> " >>> Metadata & URI Rewriting >>>=20 >>> When using HTTP redirection, content URIs will be rewritten when redire= ction takes place within an uCDN, when redirection takes place from an uCDN= to a dCDN and when redirection takes place within a dCDN. In the case of c= ascaded CDNs, content URIs may be rewritten at every CDN hop between the uC= DN and the dCDN serving the request. URI rewriting needs to be taken into a= ccount for the implementation of some CDNI interfaces. >>>=20 >>> Consider the simple case: a single uCDN and dCDN. This section refers: >>> * to a URI requested of the uCDN as a "u-URI" >>> * to a URI used in CDNI interactions between the uCDN and dCDN as a = "ud-URI" >>> * to a URI requested of the dCDN as a "d-URI" >>>=20 >>> In a given deployment situation, the ud-URI plan may be different or th= e same as the u-URI plan, and the d-URI plan may be different or the same a= s the ud-URI plan. Any combination is possible. For example, where DNS redi= rection is used the u-URI, ud-URI and d-URI plans will all be the same. As = another example, where HTTP request routing in iterative mode is used, the = uCDN will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcd= n.com/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp= .ucdn.com/xyz), and in turn the dCDN request routing system may redirect th= e user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz)= in a plan that is different to the ud-URI plan. >>>=20 >>> Most CDNI interfaces involve content URIs. For example, in the case of = the CDNI Logging interface, each log record may reference a content URI. In= the case of the CDNI Metadata interface, the dCDN must query the uCDN for = metadata based on a content URI. >>>=20 >>> It is the responsibility of the uCDN (respectively dCDN) to ensure that= a content URI communicated to the dCDN (respectively uCDN) are always expr= essed in the ud-URI plan for the particular dCDN (respectively uCDN). When = the content URI has been derived from information expressing content URIs i= n a different plan, the uCDN (respectively dCDN) needs to map the content U= RI into the ud-URI plan (for the given pair of uCDN and dCDN) for conveying= it as a content URI in a CDNI interface. >>> " >> It is the responsibility of the uCDN to ensure that a content URI commun= icated to the dCDN is always expressed in the ud-URI plan. When a uCDN rece= ives a content URI request conveying information that uses a different plan= , the uCDN must map the content URI into the ud-URI plan in accordance with= the capabilities of a chosen dCDN. The CDNI interfaces RI, MI, and LI mus= t reference the ud-URI for purposes of request routing, metadata, and loggi= ng, respectively. >>>=20 >>>=20 >>> Verbose Option: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> " >>> Metadata & URI Rewriting >>>=20 >>> When using HTTP redirection, content URIs will be rewritten when redire= ction takes place within an uCDN, when redirection takes place from an uCDN= to a dCDN and when redirection takes place within a dCDN. In the case of c= ascaded CDNs, content URIs may be rewritten at every CDN hop between the uC= DN and the dCDN serving the request. URI rewriting needs to be taken into a= ccount for the implementation of some CDNI interfaces. >>>=20 >>> Consider the simple case: a single uCDN and dCDN. This section refers: >>> * to a URI requested of the uCDN as a "u-URI" >>> * to a URI used in CDNI interactions between the uCDN and dCDN as a = "ud-URI" >>> * to a URI requested of the dCDN as a "d-URI" >>>=20 >>> In a given deployment situation, the ud-URI plan may be different or th= e same as the u-URI plan, and the d-URI plan may be different or the same a= s the ud-URI plan. Any combination is possible. For example, where DNS redi= rection is used the u-URI, ud-URI and d-URI plans will all be the same. As = another example, where HTTP request routing in iterative mode is used, the = uCDN will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcd= n.com/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp= .ucdn.com/xyz), and in turn the dCDN request routing system may redirect th= e user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz)= in a plan that is different to the ud-URI plan. >>>=20 >>> Most CDNI interfaces involve content URIs. For example, in the case of = the CDNI Logging interface, each log record may reference a content URI. In= the case of the CDNI Metadata interface, the dCDN must query the uCDN for = metadata based on a content URI. >>>=20 >>> Any CDNI interface between an uCDN and a dCDN which relies on content U= RIs needs to convey URIs in that interface in the ud-URI plan for the given= pair of CDNs. >>>=20 >>> When the dCDN is transfering CDNI information to the uCDN including a c= ontent URI, it is the responsibility of the dCDN to use the ud-URI plan and= , if required, to map back a d-URI into a ud-URI. For example, if the dCDN = uses a d-URI plan that is different to the ud-URI plan, the dCDN needs to m= ap back the d-URIs into ud-URIs for inclusion in the CDNI Logging interface= . >>>=20 >>> When the uCDN is transfering CDNI information to the dCDN including a c= ontent URI, it is the responsibility of the dCDN to use the ud-URI plan whe= n conveying content URIs. For example, if the uCDN uses a d-URI plan that i= s different from the ud-URI plan, it is the responsibility of the uCDN to e= nsure content URIs used in the CDNI Metadata interface are expressed in the= ud-URI plan. Also, if the dCDN uses a d-URI plan that is different from th= e ud-URI plan, it is the responsibility of the dCDN to correlate d-URIs in = content requests with metadata obtained from the uCDN expressed in the ud-U= RI plan. >>>=20 >>> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 a= cting as the transit CDN and CDN3 acting as the dCDN. This section refers: >>> * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as= a ud-URI-ut >>> * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 as= a ud-URI-td >>>=20 >>> In a given deployment situation the ud-URI-td plan may be different or = the same as the ud-URI-ut plan. For example, when DNS request routing is us= ed at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the same= . When HTTP request routing is used at every CDN hop, the ud-URI-td plan an= d ud-URI-ut plan will be different. >>>=20 >>> When, in his role of transit CDN, CDN2 turns information obtained on a = CDNI interface from the dCDN (respectively uCDN) into information transmitt= ed to the uCDN (respectively dCDN) on the corresponding CDNI interface, it = is the responsibility of the transit CDN to convert content URIs from the u= d-URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-ut plan t= o the ud-URI-td plan). >>>=20 >>> For example, when the transit CDN receives CDNI logging records from th= e dCDN with content URIs expressed in the ud-URI-td plan, and when the tran= sit CDN includes the corresponding CDNI logging records for transmission to= the uCDN over the CDNI Logging interface, the transit CDN needs to map the= content URIs expressed in the ud-URI-td plan into URIs expressed into the = ud-URI-ut plan. Similarly, when the transit CDN receives CDNI metadata info= rmation from the uCDN with content URIs expressed in the ud-URI-ut plan, an= d when the transit CDN includes the corresponfing CDNI metadata information= for transmission to the dCDN over the CDNI Metadata interface, the transit= CDN needs to map the content URIs expressed in the ud-URI-ut plan into con= tent URIs expressed in the ud-URI-td plan. Regarding metadata information, = note that (even when the ud-URI-ut plan and ud-URI-td plan are the same) th= e transit CDN is also likely to have to perform rewriting on some other met= adata information >> . >>> For example, any metadata which references the immediately upstream CDN= (such as content acquisition metadata) should be rewritten as the metadata= is passed between CDNs. >>> " >>>=20 >>>=20 >>>=20 >>>> " >>>> Metadata & URI Rewriting >>>>=20 >>>> When using HTTP redirection, content URIs will be rewritten between uC= DNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten = at every CDN hop between uCDN and dCDN. URI rewriting needs to be taken int= o account for the implementation of some CDNI interfaces. >>>>=20 >>>> Consider the simple case: a single uCDN and dCDN. This section refers: >>>> * to a URI requested of the uCDN as a "u-URI" >>>> * to a URI used in CDNI interactions between the uCDN and dCDN as a= "ud-URI" >>>> * to a URI requested of the dCDN as a "dCDN URI" >>>>=20 >>>> In a given deployment situation, the ud-URI plan may be different or t= he same as the u-URI plan, and the d-URI plan may be different or the same = as the ud-URI plan. Any combination is possible. For example, where DNS red= irection is used the u-URI, ud-URI and d-URI plans will all be the same. As= another example, where HTTP request routing in iterative mode is used, the= uCDN will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dc= dn.com/csp/xyz) in a plan that will be different to the u-URI plan (e.g. cs= p.ucdn.com/xyz), and in turn the dCDN request routing system may redirect t= he user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz= ) in a plan that is different to the ud-URI plan. >>>>=20 >>>> Most CDNI interfaces involve content URIs. For example, in the case of= the CDNI Logging interface, each log record may reference a content URI. I= n the case of the CDNI Metadata interface, the dCDN must query the uCDN for= metadata based on a content URI. >>>>=20 >>>> Any CDNI interface between an uCDN and a dCDN which relies on content = URIs needs to convey URIs in that interface in the ud-URI plan for the give= n pair of CDNs. >>>>=20 >>>> When the dCDN is transfering CDNI information to the uCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan an= d, if required, to map back a d-URI into a ud-URI. For example, if the dCDN= uses a d-URI plan that is different to the ud-URI plan, the dCDN needs to = map back the d-URIs into ud-URIs for inclusion in the CDNI Logging interfac= e. >>>>=20 >>>> When the uCDN is transfering CDNI information to the dCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan wh= en conveying content URIs. For example, if the uCDN uses a d-URI plan that = is different from the ud-URI plan, it is the responsibility of the uCDN to = ensure content URIs used in the CDNI Metadata interface are expressed in th= e ud-URI plan. Also, if the dCDN uses a d-URI plan that is different from t= he ud-URI plan, it is the responsibility of the dCDN to correlate d-URIs in= content requests with metadata obtained from the uCDN expressed in the ud-= URI plan. >>>>=20 >>>> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 = acting as the transit CDN and CDN3 acting as the dCDN. This section refers: >>>> * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 a= s a ud-URI-ut >>>> * to a ud-URI involved in CDNI interactions between CDN2 and CDN3 a= s a ud-URI-td >>>>=20 >>>> In a given deployment situation the ud-URI-td plan may be different or= the same as the ud-URI-ut plan. For example, when DNS request routing is u= sed at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the sam= e. When HTTP request routing is used at every CDN hop, the ud-URI-td plan a= nd ud-URI-ut plan will be different. >>>>=20 >>>> When, in his role of transit CDN, CDN2 turns information obtained on a= CDNI interface from the dCDN (respectively uCDN) into information transmit= ted to the uCDN (respectively dCDN) on the corresponding CDNI interface, it= is the responsibility of the transit CDN to convert content URIs from the = ud-URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-ut plan = to the ud-URI-td plan). >>>>=20 >>>> For example, when the transit CDN receives CDNI logging records from t= he dCDN with content URIs expressed in the ud-URI-td plan, and when the tra= nsit CDN includes the corresponding CDNI logging records for transmission t= o the uCDN over the CDNI Logging interface, the transit CDN needs to map th= e content URIs expressed in the ud-URI-td plan into URIs expressed into the= ud-URI-ut plan. Similarly, when the transit CDN receives CDNI metadata inf= ormation from the uCDN with content URIs expressed in the ud-URI-ut plan, a= nd when the transit CDN includes the corresponfing CDNI metadata informatio= n for transmission to the dCDN over the CDNI Metadata interface, the transi= t CDN needs to map the content URIs expressed in the ud-URI-ut plan into co= ntent URIs expressed in the ud-URI-td plan. Regarding metadata information,= note that (even when the ud-URI-ut plan and ud-URI-td plan are the same) t= he transit CDN is also likely to have to perform rewriting on some other me= tadata informatio >> n >>> . >>>> For example, any metadata which references the immediately upstream CD= N (such as content acquisition metadata) should be rewritten as the metadat= a is passed between CDNs. >>>> " >>>>=20 >>>> Francois >>>>=20 >>>> On 1 Aug 2013, at 22:41, Matt Caulfield (mcaulfie) wrote: >>>>=20 >>>>> Hi everyone, >>>>>=20 >>>>> Based on comments this week regarding the URI Rewriting section of th= e CDNI Framework document I have put together a revised section which aims = to touch on the key points more clearly. Please share your feedback on the = text below. If it is suitable, we can incorporate into the next revision of= draft-ietf-cdni-framework. >>>>>=20 >>>>> Thanks, >>>>> Matt >>>>>=20 >>>>> Metadata & URI Rewriting >>>>>=20 >>>>> When using HTTP redirection, content URIs will be rewritten between u= CDNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten= multiple times between uCDN and dCDN. URI rewriting poses a special challe= nge for the implementation of some CDNI interfaces. >>>>=20 >>>>=20 >>>>> Consider the simple case: a single uCDN and dCDN. This section refers= to the URI requested of the uCDN as the "uCDN URI" and the URI requested o= f the dCDN as the "dCDN URI". >>>>>=20 >>>>> Any CDNI interface which relies on content URIs must state explicitly= which URI is to be used - the dCDN URI or the uCDN URI. For example, in th= e case of the Logging Interface, each log message may reference a content U= RI. In the case of the Metadata Interface, the dCDN must query for the uCDN= for metadata based on a content URI. >>>>>=20 >>>>> For all CDNI interfaces, the dCDN should translate any dCDN URIs to u= CDN URIs before interacting with the uCDN. For logging, this approach requi= res the dCDN to translate any dCDN URIs in its log messages into uCDN URIs.= For metadata, this approach requires the dCDN to translate any dCDN URIs i= nto uCDN URIs before querying the uCDN for metadata. >>>>>=20 >>>>> In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and= therefore is capable of translating from uCDN URI to dCDN URI and vice ver= sa. In iterative mode, an out-of-band agreement instructs the uCDN and dCDN= how to translate from uCDN URI to dCDN URI and vice versa. In either mode,= the dCDN is capable of translating dCDN URIs into uCDN URIs before interac= ting with the uCDN. >>>>>=20 >>>>> Note that even in the DNS redirection case, some URI rewriting is sti= ll necessary. For example, any metadata which references the immediately up= stream CDN (such as content acquisition metadata) should be rewritten as th= e metadata is passed between CDNs. However, given that DNS redirection does= not change the content URI, many of the concerns addressed above with HTTP= redirection do not apply. >>>>>=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 >>> _______________________________________________ >>> 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 >> . >>=20 >=20 From mcaulfie@cisco.com Tue Aug 6 10:12:25 2013 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 435A921F8756 for ; Tue, 6 Aug 2013 10:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL9g4UWgkcrC for ; Tue, 6 Aug 2013 10:12:20 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2E12E21F9E5B for ; Tue, 6 Aug 2013 10:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21801; q=dns/txt; s=iport; t=1375809140; x=1377018740; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=pn+w/0MQyLYu/UqRUQveRQ2Vl7/EvYo3jEavgRDPmJU=; b=aT//YAhxF+IVK9BcAMVO1w/aL0ovDQUFtLW6lOIwobGghfVUjPf/WfSC +99sR9TpUwBA8dmV1krbPsJAHWJGDNx+Ew3shuaZu00pzhatsfA/6ZB0F aeLsP7ZRW6MWFk0LCBXGjbA1+BH+VdOAbtFiUSwZbwRcdX0LZpKS4KUUb I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAIktAVKtJV2b/2dsb2JhbABagwY1RAy+fYEfFnSCJAEBAQMBAQEBFyA0CwUHBAIBCBEEAQEBCgsJCQcnCxQJCAIEAQkEBQgTh28GDLcCj2kxBwYEgxB0A5kLkCSDF4Iq X-IronPort-AV: E=Sophos;i="4.89,827,1367971200"; d="scan'208";a="244155788" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 06 Aug 2013 17:12:18 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r76HCIqi021650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 6 Aug 2013 17:12:18 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 6 Aug 2013 12:12:18 -0500 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" , "Scott Wainner (swainner)" Thread-Topic: [CDNi] New Text for Framework on URI Rewriting Thread-Index: Ac6O92zds42pB4QjSEezI1Jqeu28AgAtnYUAAIzUnYAABFVkAAAVYX8AACBLKgAAAKN+EA== Date: Tue, 6 Aug 2013 17:12:17 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C921050B195@xmb-aln-x03.cisco.com> References: <166EBB70C264A9479E459B01B1BA6C92104BB38D@xmb-aln-x03.cisco.com> <51FF81D6.204@cisco.com> <52001152.5070200@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.69.110] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Text for Framework on URI Rewriting 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, 06 Aug 2013 17:12:25 -0000 I think the text below captures the idea nicely. However, is there general consensus that using the ud-URI as a handle is a = good idea? In practice, this solution complicates the metadata interface im= plementation by requiring the uCDN to expose different metadata to each dCD= N (tailored for the specific ud-URI shared between them). It also creates c= oupling between request routing and metadata. Is that something we can live= with? An alternate solution is to use a common handle for content throughout all = cascaded CDNs. This happens automatically in the DNS case - all CDNs use th= e original URI. Logging and metadata both reference the original URI. We co= uld try to bringing HTTP case in line with the DNS case by guaranteeing tha= t any URI (u-URI, ud-URI, or d-URI) can always be translated back to the or= iginal URI. Thanks, Matt -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: Tuesday, August 06, 2013 8:20 AM To: Scott Wainner (swainner) Cc: cdni@ietf.org Subject: Re: [CDNi] New Text for Framework on URI Rewriting Hi Scott, That can work for me. Opnion anyone? Francois On 5 Aug 2013, at 22:55, Scott Wainner wrote: > Francois, >=20 > May I suggest we re-write the paragraphs as follows: >=20 > Metadata & URI Rewriting > ------------------------ >=20 > When using HTTP redirection, content URIs may be rewritten when redirecti= on takes place within an uCDN, from an uCDN to a dCDN, and within the dCDN.= In the case of cascaded CDNs, content URIs may be rewritten at every CDN h= op e.g between the uCDN and the dCDN acting as the transit CDN, and between= the transit CDN and the dCDN serving the request. The content URI used bet= ween a specific pair of uCDN and dCDN becomes a common handle that can be r= eferred to without ambiguity by both CDNs of the specific pair of uCDN and = dCDN in all their inter-CDN communications. The handle allows the uCDN and = dCDN to correlate information exchanged in CDNI interfaces in both the down= stream direction (e.g. when using the MI) and the upstream direction (e.g. = when using the LI). >=20 > Consider the simple case: a single uCDN and dCDN pair using HTTP redirect= ion. This section defines the content URIs as follows: >=20 > "u-URI" represents a content URI in a request presented to the uCDN > "ud-URI" is a content URI acting as the common handle across uCDN and d= CDN for requests redirected by the uCDN to a specific dCDN > "d-URI" represents a content URI in a request made within the=20 > delegate dCDN >=20 > The "ud-URI" effectively becomes the handle which the uCDN and dCDN pair = correlate all CDNI information. In particular, for a given pair of CDNs exe= cuting the HTTP redirection, the uCDN needs to map the u-URI to the ud-URI = handle for all MI message exchanges, while the dCDN needs to map the d-URI = to the ud-URI handle for all LI message exchanges. >=20 > In the case of a cascaded CDNs, the transit CDN will re-write the content= URI when redirecting to the dCDN, thereby establishing a new handle betwee= n the transit CDN and the dCDN, that is different from the handle between t= he uCDN and transit CDN. It is the responsibility of the transit CDN to man= age its mapping across handles so the right handle for the specific pair of= CDNs is always used in its CDNI communication. >=20 > In summary, all CDNI interfaces between a given pair of CDNs need to alwa= ys use the "ud-URI" handle for that specific CDN pair, as their content URI= reference. >=20 > Scott Wainner >=20 >=20 >=20 > On 8/5/13 6:43 AM, Scott Wainner wrote: >> I was following along the "Concise Option" until the last paragraph. >>=20 >> Alternative suggested in line ... >>=20 >> On 8/5/13 4:39 AM, Francois Le Faucheur (flefauch) wrote: >>> Folks, >>>=20 >>> Someone suggested privately that perhaps we are trying to provide too m= uch details here, and that we may be finally blurring the point that is not= that complicated. So I'd like to offer an alternative text that aims at ca= pturing the point accurately but succinctly. So you'll find below: >>> * a Concise Option (new) >>> * a Verbose Option (same as in my earlier message with minor=20 >>> editorial enhancements) Let us know which you favor (or if you have alt= ernative proposals to offer). >>>=20 >>> Francois >>>=20 >>>=20 >>> Concise Option >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> " >>> Metadata & URI Rewriting >>>=20 >>> When using HTTP redirection, content URIs will be rewritten when redire= ction takes place within an uCDN, when redirection takes place from an uCDN= to a dCDN and when redirection takes place within a dCDN. In the case of c= ascaded CDNs, content URIs may be rewritten at every CDN hop between the uC= DN and the dCDN serving the request. URI rewriting needs to be taken into a= ccount for the implementation of some CDNI interfaces. >>>=20 >>> Consider the simple case: a single uCDN and dCDN. This section refers: >>> * to a URI requested of the uCDN as a "u-URI" >>> * to a URI used in CDNI interactions between the uCDN and dCDN as a = "ud-URI" >>> * to a URI requested of the dCDN as a "d-URI" >>>=20 >>> In a given deployment situation, the ud-URI plan may be different or th= e same as the u-URI plan, and the d-URI plan may be different or the same a= s the ud-URI plan. Any combination is possible. For example, where DNS redi= rection is used the u-URI, ud-URI and d-URI plans will all be the same. As = another example, where HTTP request routing in iterative mode is used, the = uCDN will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcd= n.com/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp= .ucdn.com/xyz), and in turn the dCDN request routing system may redirect th= e user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz)= in a plan that is different to the ud-URI plan. >>>=20 >>> Most CDNI interfaces involve content URIs. For example, in the case of = the CDNI Logging interface, each log record may reference a content URI. In= the case of the CDNI Metadata interface, the dCDN must query the uCDN for = metadata based on a content URI. >>>=20 >>> It is the responsibility of the uCDN (respectively dCDN) to ensure that= a content URI communicated to the dCDN (respectively uCDN) are always expr= essed in the ud-URI plan for the particular dCDN (respectively uCDN). When = the content URI has been derived from information expressing content URIs i= n a different plan, the uCDN (respectively dCDN) needs to map the content U= RI into the ud-URI plan (for the given pair of uCDN and dCDN) for conveying= it as a content URI in a CDNI interface. >>> " >> It is the responsibility of the uCDN to ensure that a content URI commun= icated to the dCDN is always expressed in the ud-URI plan. When a uCDN rece= ives a content URI request conveying information that uses a different plan= , the uCDN must map the content URI into the ud-URI plan in accordance with= the capabilities of a chosen dCDN. The CDNI interfaces RI, MI, and LI mus= t reference the ud-URI for purposes of request routing, metadata, and loggi= ng, respectively. >>>=20 >>>=20 >>> Verbose Option: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>=20 >>> " >>> Metadata & URI Rewriting >>>=20 >>> When using HTTP redirection, content URIs will be rewritten when redire= ction takes place within an uCDN, when redirection takes place from an uCDN= to a dCDN and when redirection takes place within a dCDN. In the case of c= ascaded CDNs, content URIs may be rewritten at every CDN hop between the uC= DN and the dCDN serving the request. URI rewriting needs to be taken into a= ccount for the implementation of some CDNI interfaces. >>>=20 >>> Consider the simple case: a single uCDN and dCDN. This section refers: >>> * to a URI requested of the uCDN as a "u-URI" >>> * to a URI used in CDNI interactions between the uCDN and dCDN as a = "ud-URI" >>> * to a URI requested of the dCDN as a "d-URI" >>>=20 >>> In a given deployment situation, the ud-URI plan may be different or th= e same as the u-URI plan, and the d-URI plan may be different or the same a= s the ud-URI plan. Any combination is possible. For example, where DNS redi= rection is used the u-URI, ud-URI and d-URI plans will all be the same. As = another example, where HTTP request routing in iterative mode is used, the = uCDN will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dcd= n.com/csp/xyz) in a plan that will be different to the u-URI plan (e.g. csp= .ucdn.com/xyz), and in turn the dCDN request routing system may redirect th= e user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz)= in a plan that is different to the ud-URI plan. >>>=20 >>> Most CDNI interfaces involve content URIs. For example, in the case of = the CDNI Logging interface, each log record may reference a content URI. In= the case of the CDNI Metadata interface, the dCDN must query the uCDN for = metadata based on a content URI. >>>=20 >>> Any CDNI interface between an uCDN and a dCDN which relies on content U= RIs needs to convey URIs in that interface in the ud-URI plan for the given= pair of CDNs. >>>=20 >>> When the dCDN is transfering CDNI information to the uCDN including a c= ontent URI, it is the responsibility of the dCDN to use the ud-URI plan and= , if required, to map back a d-URI into a ud-URI. For example, if the dCDN = uses a d-URI plan that is different to the ud-URI plan, the dCDN needs to m= ap back the d-URIs into ud-URIs for inclusion in the CDNI Logging interface= . >>>=20 >>> When the uCDN is transfering CDNI information to the dCDN including a c= ontent URI, it is the responsibility of the dCDN to use the ud-URI plan whe= n conveying content URIs. For example, if the uCDN uses a d-URI plan that i= s different from the ud-URI plan, it is the responsibility of the uCDN to e= nsure content URIs used in the CDNI Metadata interface are expressed in the= ud-URI plan. Also, if the dCDN uses a d-URI plan that is different from th= e ud-URI plan, it is the responsibility of the dCDN to correlate d-URIs in = content requests with metadata obtained from the uCDN expressed in the ud-U= RI plan. >>>=20 >>> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 a= cting as the transit CDN and CDN3 acting as the dCDN. This section refers: >>> * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 as= a ud-URI-ut >>> * to a ud-URI involved in CDNI interactions between CDN2 and CDN3=20 >>> as a ud-URI-td >>>=20 >>> In a given deployment situation the ud-URI-td plan may be different or = the same as the ud-URI-ut plan. For example, when DNS request routing is us= ed at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the same= . When HTTP request routing is used at every CDN hop, the ud-URI-td plan an= d ud-URI-ut plan will be different. >>>=20 >>> When, in his role of transit CDN, CDN2 turns information obtained on a = CDNI interface from the dCDN (respectively uCDN) into information transmitt= ed to the uCDN (respectively dCDN) on the corresponding CDNI interface, it = is the responsibility of the transit CDN to convert content URIs from the u= d-URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-ut plan t= o the ud-URI-td plan). >>>=20 >>> For example, when the transit CDN receives CDNI logging records from=20 >>> the dCDN with content URIs expressed in the ud-URI-td plan, and when=20 >>> the transit CDN includes the corresponding CDNI logging records for=20 >>> transmission to the uCDN over the CDNI Logging interface, the=20 >>> transit CDN needs to map the content URIs expressed in the ud-URI-td=20 >>> plan into URIs expressed into the ud-URI-ut plan. Similarly, when=20 >>> the transit CDN receives CDNI metadata information from the uCDN=20 >>> with content URIs expressed in the ud-URI-ut plan, and when the=20 >>> transit CDN includes the corresponfing CDNI metadata information for=20 >>> transmission to the dCDN over the CDNI Metadata interface, the=20 >>> transit CDN needs to map the content URIs expressed in the ud-URI-ut=20 >>> plan into content URIs expressed in the ud-URI-td plan. Regarding=20 >>> metadata information, note that (even when the ud-URI-ut plan and=20 >>> ud-URI-td plan are the same) the transit CDN is also likely to have=20 >>> to perform rewriting on some other metadata informati on >> . >>> For example, any metadata which references the immediately upstream CDN= (such as content acquisition metadata) should be rewritten as the metadata= is passed between CDNs. >>> " >>>=20 >>>=20 >>>=20 >>>> " >>>> Metadata & URI Rewriting >>>>=20 >>>> When using HTTP redirection, content URIs will be rewritten between uC= DNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten = at every CDN hop between uCDN and dCDN. URI rewriting needs to be taken int= o account for the implementation of some CDNI interfaces. >>>>=20 >>>> Consider the simple case: a single uCDN and dCDN. This section refers: >>>> * to a URI requested of the uCDN as a "u-URI" >>>> * to a URI used in CDNI interactions between the uCDN and dCDN as a= "ud-URI" >>>> * to a URI requested of the dCDN as a "dCDN URI" >>>>=20 >>>> In a given deployment situation, the ud-URI plan may be different or t= he same as the u-URI plan, and the d-URI plan may be different or the same = as the ud-URI plan. Any combination is possible. For example, where DNS red= irection is used the u-URI, ud-URI and d-URI plans will all be the same. As= another example, where HTTP request routing in iterative mode is used, the= uCDN will redirect the user-agent to the dCDN using a ud-URI (e.g. ucdn.dc= dn.com/csp/xyz) in a plan that will be different to the u-URI plan (e.g. cs= p.ucdn.com/xyz), and in turn the dCDN request routing system may redirect t= he user-agent to a dCDN Surrogate using a d-URI (e.g. dcdn.com/ucdn/csp/xyz= ) in a plan that is different to the ud-URI plan. >>>>=20 >>>> Most CDNI interfaces involve content URIs. For example, in the case of= the CDNI Logging interface, each log record may reference a content URI. I= n the case of the CDNI Metadata interface, the dCDN must query the uCDN for= metadata based on a content URI. >>>>=20 >>>> Any CDNI interface between an uCDN and a dCDN which relies on content = URIs needs to convey URIs in that interface in the ud-URI plan for the give= n pair of CDNs. >>>>=20 >>>> When the dCDN is transfering CDNI information to the uCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan an= d, if required, to map back a d-URI into a ud-URI. For example, if the dCDN= uses a d-URI plan that is different to the ud-URI plan, the dCDN needs to = map back the d-URIs into ud-URIs for inclusion in the CDNI Logging interfac= e. >>>>=20 >>>> When the uCDN is transfering CDNI information to the dCDN including a = content URI, it is the responsibility of the dCDN to use the ud-URI plan wh= en conveying content URIs. For example, if the uCDN uses a d-URI plan that = is different from the ud-URI plan, it is the responsibility of the uCDN to = ensure content URIs used in the CDNI Metadata interface are expressed in th= e ud-URI plan. Also, if the dCDN uses a d-URI plan that is different from t= he ud-URI plan, it is the responsibility of the dCDN to correlate d-URIs in= content requests with metadata obtained from the uCDN expressed in the ud-= URI plan. >>>>=20 >>>> Now consider a cascaded CDNs case, with CDN1 acting as the uCDN, CDN2 = acting as the transit CDN and CDN3 acting as the dCDN. This section refers: >>>> * to a ud-URI involved in CDNI interactions between CDN1 and CDN2 a= s a ud-URI-ut >>>> * to a ud-URI involved in CDNI interactions between CDN2 and=20 >>>> CDN3 as a ud-URI-td >>>>=20 >>>> In a given deployment situation the ud-URI-td plan may be different or= the same as the ud-URI-ut plan. For example, when DNS request routing is u= sed at every CDN hop, the ud-URI-td plan and ud-URI-ut plan will be the sam= e. When HTTP request routing is used at every CDN hop, the ud-URI-td plan a= nd ud-URI-ut plan will be different. >>>>=20 >>>> When, in his role of transit CDN, CDN2 turns information obtained on a= CDNI interface from the dCDN (respectively uCDN) into information transmit= ted to the uCDN (respectively dCDN) on the corresponding CDNI interface, it= is the responsibility of the transit CDN to convert content URIs from the = ud-URI-td plan to the ud-URI-ut plan (respectively from the ud-URI-ut plan = to the ud-URI-td plan). >>>>=20 >>>> For example, when the transit CDN receives CDNI logging records=20 >>>> from the dCDN with content URIs expressed in the ud-URI-td plan,=20 >>>> and when the transit CDN includes the corresponding CDNI logging=20 >>>> records for transmission to the uCDN over the CDNI Logging=20 >>>> interface, the transit CDN needs to map the content URIs expressed=20 >>>> in the ud-URI-td plan into URIs expressed into the ud-URI-ut plan.=20 >>>> Similarly, when the transit CDN receives CDNI metadata information=20 >>>> from the uCDN with content URIs expressed in the ud-URI-ut plan,=20 >>>> and when the transit CDN includes the corresponfing CDNI metadata=20 >>>> information for transmission to the dCDN over the CDNI Metadata=20 >>>> interface, the transit CDN needs to map the content URIs expressed=20 >>>> in the ud-URI-ut plan into content URIs expressed in the ud-URI-td=20 >>>> plan. Regarding metadata information, note that (even when the=20 >>>> ud-URI-ut plan and ud-URI-td plan are the same) the transit CDN is=20 >>>> also likely to have to perform rewriting on some other metadata=20 >>>> informat io >> n >>> . >>>> For example, any metadata which references the immediately upstream CD= N (such as content acquisition metadata) should be rewritten as the metadat= a is passed between CDNs. >>>> " >>>>=20 >>>> Francois >>>>=20 >>>> On 1 Aug 2013, at 22:41, Matt Caulfield (mcaulfie) wrote: >>>>=20 >>>>> Hi everyone, >>>>>=20 >>>>> Based on comments this week regarding the URI Rewriting section of th= e CDNI Framework document I have put together a revised section which aims = to touch on the key points more clearly. Please share your feedback on the = text below. If it is suitable, we can incorporate into the next revision of= draft-ietf-cdni-framework. >>>>>=20 >>>>> Thanks, >>>>> Matt >>>>>=20 >>>>> Metadata & URI Rewriting >>>>>=20 >>>>> When using HTTP redirection, content URIs will be rewritten between u= CDNs and dCDNs. In the case of cascaded CDNs, content URIs may be rewritten= multiple times between uCDN and dCDN. URI rewriting poses a special challe= nge for the implementation of some CDNI interfaces. >>>>=20 >>>>=20 >>>>> Consider the simple case: a single uCDN and dCDN. This section refers= to the URI requested of the uCDN as the "uCDN URI" and the URI requested o= f the dCDN as the "dCDN URI". >>>>>=20 >>>>> Any CDNI interface which relies on content URIs must state explicitly= which URI is to be used - the dCDN URI or the uCDN URI. For example, in th= e case of the Logging Interface, each log message may reference a content U= RI. In the case of the Metadata Interface, the dCDN must query for the uCDN= for metadata based on a content URI. >>>>>=20 >>>>> For all CDNI interfaces, the dCDN should translate any dCDN URIs to u= CDN URIs before interacting with the uCDN. For logging, this approach requi= res the dCDN to translate any dCDN URIs in its log messages into uCDN URIs.= For metadata, this approach requires the dCDN to translate any dCDN URIs i= nto uCDN URIs before querying the uCDN for metadata. >>>>>=20 >>>>> In recursive mode, the dCDN is queried by the uCDN for a dCDN URI and= therefore is capable of translating from uCDN URI to dCDN URI and vice ver= sa. In iterative mode, an out-of-band agreement instructs the uCDN and dCDN= how to translate from uCDN URI to dCDN URI and vice versa. In either mode,= the dCDN is capable of translating dCDN URIs into uCDN URIs before interac= ting with the uCDN. >>>>>=20 >>>>> Note that even in the DNS redirection case, some URI rewriting is sti= ll necessary. For example, any metadata which references the immediately up= stream CDN (such as content acquisition metadata) should be rewritten as th= e metadata is passed between CDNs. However, given that DNS redirection does= not change the content URI, many of the concerns addressed above with HTTP= redirection do not apply. >>>>>=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 >>> _______________________________________________ >>> 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 >> . >>=20 >=20 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Wed Aug 7 01:39:50 2013 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 0777521F9929 for ; Wed, 7 Aug 2013 01:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 uHZZ6MWxxwoG for ; Wed, 7 Aug 2013 01:39:45 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC7121E810D for ; Wed, 7 Aug 2013 01:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=242; q=dns/txt; s=iport; t=1375864785; x=1377074385; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=PKg7h3Qo2/Q3yVnpGGVXoYGmQyi0ejF70PWjSMewz8E=; b=lHSX0vI1AdyAI/3+L3+yTFWzDdDK3GmMNKgkZdq5h59V0rqRXaS4Eq/H 6VqZy0gpqeImizmuonWbM/Hb0xEtZjKgIssgYUmimOlxrMAMzVFR8Tgri klBC4FIijm7xZzTuwfYpFHwJk2vZDgoJD9v0Gnx+slBpF9S/EbzkaryUP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoAKALgGAlKtJV2c/2dsb2JhbABagwY1UIJKu3UEAYEcFnSCJgEEOlEBKhRCJwQbAYgHDJdVoFKOe26DUnQDqTCDF4Iq X-IronPort-AV: E=Sophos;i="4.89,831,1367971200"; d="scan'208";a="244541513" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 07 Aug 2013 08:39:44 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r778dhRV004815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 7 Aug 2013 08:39:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 03:39:43 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Draft minutes of IETF-87 CDN sessions available for review Thread-Index: AQHOk0mpvw2TJh5n8Uy8g62jrkIGCw== Date: Wed, 7 Aug 2013 08:39:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] Content-Type: text/plain; charset="us-ascii" Content-ID: <50FE8AA4E873E44598D0BB10C4887DD6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Draft minutes of IETF-87 CDN sessions available for review 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, 07 Aug 2013 08:39:50 -0000 Folks, Draft minutes for our Berlin meetings have been uploaded: http://www.ietf.org/proceedings/87/minutes/minutes-87-cdni Please send Daryl and I any potential comments/corrections so we can finali= se them. Cheers Francois= From flefauch@cisco.com Wed Aug 7 01:41:47 2013 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 4AB5021F9929 for ; Wed, 7 Aug 2013 01:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFZTXx18LACZ for ; Wed, 7 Aug 2013 01:41:42 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1845F21E810C for ; Wed, 7 Aug 2013 01:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=605; q=dns/txt; s=iport; t=1375864902; x=1377074502; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=TI0Q3Is4QYruB4R+CHD3RyhwWFfPj9UlUBwoHTlltkw=; b=U8WiUaS3T2MG0dFw2oEHFTkbqFRwVLn18DKK65KlCdjVBm1fhx11rNDw QyUd9VZBmPwueaxfYStxOh0KKjYPzwWK5am+xkZ6SsaGtb59zZZpktlXh BJ4XBgBMGOYUc3Fm6xXckFU+uqFH73V/vIzEbruLupZQ7ppiVxV5TJOhz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFADEHAlKtJXG//2dsb2JhbABagwY1UIJKu3qBHBZ0giQBAQEDAQEBATc0EAsCAQgiFBAnCyUCBBMIAYgBBgy4J49nAjiDGnQDqTCDF4Iq X-IronPort-AV: E=Sophos;i="4.89,831,1367971200"; d="scan'208";a="241455371" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 07 Aug 2013 08:41:41 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r778ffaN023674 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 7 Aug 2013 08:41:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 03:41:41 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Draft minutes of IETF-87 CDN sessions available for review Thread-Index: AQHOk0mpvw2TJh5n8Uy8g62jrkIGC5mJwR0A Date: Wed, 7 Aug 2013 08:41:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Draft minutes of IETF-87 CDN sessions available for review 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, 07 Aug 2013 08:41:47 -0000 and thank you to Rob Murray and Iuniana Oprescu for taking the notes during= the meetings. Francois On 7 Aug 2013, at 10:39, "Francois Le Faucheur (flefauch)" wrote: > Folks, >=20 > Draft minutes for our Berlin meetings have been uploaded: > http://www.ietf.org/proceedings/87/minutes/minutes-87-cdni >=20 > Please send Daryl and I any potential comments/corrections so we can fina= lise them. >=20 > Cheers >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Wed Aug 7 10:31:03 2013 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 8FCAF11E812C for ; Wed, 7 Aug 2013 10:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 OMwjwBxUBSIs for ; Wed, 7 Aug 2013 10:30:51 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 79AA721F9DA3 for ; Wed, 7 Aug 2013 10:30:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5612; q=dns/txt; s=iport; t=1375896648; x=1377106248; h=from:to:subject:date:message-id:mime-version; bh=ZeFGrMs51rw07biY6k7VKbyIELZBsQ+tbnlBHITNZoM=; b=UfS5vpSP1ySn+tzIv6RLyFidTmWI8Gmpd0s67YBhh1cCtNpHPpxY0VYA KqjM/+FrNuZdIKI6oFUYym3jAn3LMfHDgS2rkwjGsewg4mdfFmRx4OkUM tvFOWl+cM7oJEyA/i8osmsrpyrePbvlvYZzNEjqWXm2dT7twnQwkP1dz/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAK+DAlKtJXG8/2dsb2JhbABbgkJENVC+RYEdFnSCJgEELV4BKlYmAQQbiAiYGKBDj2mDUnQDqTCDF4FqJBw X-IronPort-AV: E=Sophos;i="4.89,834,1367971200"; d="scan'208,217";a="241672529" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 07 Aug 2013 17:30:47 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r77HUkV5010513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 7 Aug 2013 17:30:47 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.31]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Wed, 7 Aug 2013 12:30:46 -0500 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: URI Signing related record for logging to be moved Thread-Index: Ac6Tk9bzI2gH5QtTRgmsvvGkbhegCA== Date: Wed, 7 Aug 2013 17:30:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.156.16.12] Content-Type: multipart/alternative; boundary="_000_CD85F32117029D4F9AEF48BDEF5536AB1034B580xmbalnx03ciscoc_" MIME-Version: 1.0 Subject: [CDNi] URI Signing related record for logging to be moved 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, 07 Aug 2013 17:31:03 -0000 --_000_CD85F32117029D4F9AEF48BDEF5536AB1034B580xmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks. Just want to make a note that the following CDNI logging field wi= ll be moved from draft-ietf-cdni-logging to draft-leung-cdni-uri-signing ba= sed on the last WG's agreement. o s-uri-signing: * format: 1DIGIT * field value: this characterises the uri signing validation performed by the Surrogate on the request. The allowed values are: * + "0" : no uri signature validation performed + "1" : uri signature validation performed and validated + "2" : uri signature validation performed and rejected * occurrence: there MUST be zero or exactly one instance of this field. Kent --_000_CD85F32117029D4F9AEF48BDEF5536AB1034B580xmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks. Just want to make a note that the followin= g CDNI logging field will be moved from draft-ietf-cdni-logging to draft-le= ung-cdni-uri-signing based on the last WG’s agreement.

 

   o  s-uri-signing:
      *  format: 1DIGIT<=
/span>
      *  field value: this characte=
rises the uri signing validation
         performed by the=
 Surrogate on the request.  The allowed values
         are:<=
/span>
      *
         +  &quo=
t;0" : no uri signature validation performed
         +  &quo=
t;1" : uri signature validation performed and validated
         +  &quo=
t;2" : uri signature validation performed and rejected
      *  occurrence: there MUST be =
zero or exactly one instance of this
         field.

 

Kent

--_000_CD85F32117029D4F9AEF48BDEF5536AB1034B580xmbalnx03ciscoc_-- From internet-drafts@ietf.org Wed Aug 21 11:26:18 2013 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 A92A91F0ED7; Wed, 21 Aug 2013 11:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 7-IirPFI6kDm; Wed, 21 Aug 2013 11:26:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 067361F0ECF; Wed, 21 Aug 2013 11:26:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130821182607.19330.38545.idtracker@ietfa.amsl.com> Date: Wed, 21 Aug 2013 11:26:07 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-04.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, 21 Aug 2013 18:26:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Framework for CDN Interconnection Author(s) : Larry Peterson Bruce Davie Filename : draft-ietf-cdni-framework-04.txt Pages : 53 Date : 2013-08-21 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, distribution metadata exchange, and logging information exchange across CDNs. 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. It obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-framework-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 flefauch@cisco.com Mon Aug 26 08:56:09 2013 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 C735821E804C for ; Mon, 26 Aug 2013 08:56:09 -0700 (PDT) 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 kZbOAMnV61PT for ; Mon, 26 Aug 2013 08:55:58 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1780B11E81B9 for ; Mon, 26 Aug 2013 08:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21884; q=dns/txt; s=iport; t=1377532558; x=1378742158; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hXnPWqfSdO/DMUFWUKwn0w3fq876aqfuhCJonkWTnNc=; b=PMJ8fPF9+HtRxNDlpH0L0KctPfrkBVS55LunALjrPDfUXHSdUkYKcCjp +c8VclLU82WVZVw+IOcs4933ezzXKup0FAi/WPSCtA5a226Sw1T68/P8D FanGdKes8TNpvzSqKsa+cTZyrwI2uisfPOhtWNKpU+4kuXwe50EPXvCZb w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArEGAOp5G1KtJXG//2dsb2JhbABRCoMHNVHAFYEiFm0HgiUBAQQBAQFrCxACARoQHQcnCxQDDgIEDgUIE4dmDLdkBI81BIEOMQeDHH0DlBSVO4MegWhC X-IronPort-AV: E=Sophos;i="4.89,959,1367971200"; d="scan'208,217";a="251532098" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 26 Aug 2013 15:55:57 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r7QFtvSo010947 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Aug 2013 15:55:57 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 10:55:56 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Draft CDNI charter update Thread-Index: AQHOonTADCRiL5mwJkGqoIFfG0jz5g== Date: Mon, 26 Aug 2013 15:55:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04B5CA9Dxmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: [CDNi] Draft CDNI charter update 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, 26 Aug 2013 15:56:09 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04B5CA9Dxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefauch) > wrote: Hi everyone, We've reached a tentative agreement during today's session to add a "URI Si= gning" deliverable to the CDNI charter. If you have comments or concerns about that, please express those on the li= st. There has been no concerns expressed on the Berlin tentative agreement to a= dd a "URI Signing" deliverable to the CDNI charter; so we will consider thi= s as a WG decision. Also, we need to update the target dates for existing Deliverables. Below is a proposal to update the Charter accordingly, with addition over t= he current charter showing up in red and changes showing up in blue. Please= review carefully and let us know if you have any comments on this proposal= . Francois & Daryl PROPOSED NEW CHARTER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness o= f delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure an= d many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (vi= a their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent an= d important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the "CDNI request-routing interface". This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the "CDNI metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification of "URI Signing for CDNI" allowing support of content= access control across interconnected CDNs through signing of content URIs.= In particular, this specification will identify how URI signing impacts (o= r does not impact) each of the CDNI Interfaces. The WG will discuss and address the security, management and operationa= l issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and = a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet. Goals and Milestones: Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Dec 2013 - Submit CDNI framework to IESG as Informational Sep 2013 - Submit CDNI requirements to IESG as Informational April 2014 - Submit specification of the CDNI Request Routing/Redirection= interface to IESG as Proposed Standard Dec 2013 - Submit specification of the CDNI Logging interface to IESG as = Proposed Standard April 2014 - Submit specification of the CDNI Control interface to IESG a= s proposed Standard Dec 2013 - Submit specification of the CDNI Metadata Distribution interfa= ce to IESG as Proposed Standard Sep 2014 - Submit specification of the CDNI Request Routing/Footprint & C= apabilities Advertisement interface to IESG as Proposed Standard Dec 2014 - Submit specification of URI Signing for CDNI to IESG as Propos= ed Standard Dec 2014 - Recharter or dissolve Cheers Francois _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D04B5CA9Dxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <66270C0B422720428E433D81B9A50891@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hello,

On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Hi everyone,

We've reached a tentative agreement during today's session to add a "U= RI Signing" deliverable to the CDNI charter.
If you have comments or concerns about that, please express those on the li= st.

There has been no concerns expressed on the Berlin tentative agreement= to add a "URI Signing" deliverable to the CDNI charter; so = we will consider this as a WG decision.

Also, we need to update the target dates for existing Deliverables.
 
Below is a proposal to update the Charter accordingly, with addition o= ver the current charter showing up in red and changes showing up in blue. P= lease review carefully and let us know if you have any comments on this pro= posal. 


Francois & Daryl


PROPOSED NEW CHARTER
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /div>
"
Description of Working Group:


    A Content Delivery Network (CDN) is an infrastructure of= network
    elements operating at layer 4 through layer 7, arranged = for the
    efficient distribution and delivery of digital content. = Such content
    includes, but is not limited to, web pages and images de= livered via
    HTTP, and streaming of continuous media delivered via HT= TP, RTSP, RTMP,
    etc. CDNs typically provide services to multiple Content= Service
    Providers (CSPs).

    CDNs provide numerous benefits: a shared platform for mu= lti-service
    content delivery, reduced transmission costs for cacheab= le content,
    improved quality of experience for end users and increas= ed robustness of
    delivery. For these reasons they are frequently used for= large-scale
    content delivery.

    As a result of the significant growth in content deliver= ed over IP
    networks, existing CDN providers are scaling up their in= frastructure and
    many Network Service Providers and Enterprise Service Pr= oviders are
    deploying their own CDNs. Subject to the policy of the C= SP, it is
    generally desirable that a given item of content can be = delivered to an
    end user regardless of that end user's location or attac= hment network.
    This creates a need for interconnecting (previously) sta= ndalone CDNs so
    they can interoperate and collectively behave as a singl= e delivery
    infrastructure.

    The goal of the CDNI Working Group is to allow the inter= connection of
    separately administered CDNs in support of the end-to-en= d delivery of
    content from CSPs through multiple CDNs and ultimately t= o end users (via
    their respective User Agents). The CDNI WG aims at deliv= ering a
    targeted, deployable solution in a short timeframe (18-2= 4 months) as
    needed by the industry. It is expected that the CDNI int= erfaces will be
    realized using existing IETF protocols for transport and= message
    exchange, and using existing object notation grammars/la= nguages for the
    definition of CDNI objects and semantics. In the event t= hat protocol
    extensions or new protocols are deemed necessary by the = WG, the WG will
    recharter.

    The working group will focus on the following items:

    - A "problem statement" document providing a d= escription of the problem
      and a common terminology.

    - A "use case" document describing scenarios f= or usage and applications
      of the CDNI solution and protocols.

    - A "framework" document providing a descripti= on of the different
      components of the CDNI architecture and how they = interact with one
      another. This document will also include a "= threat analysis"
      discussing the security concerns and threats, the= trust model and
      privacy issues specific to CDNI.

    - A "requirements" document. This document lis= ts the requirements for
      the CDNI architecture and the CDNI interfaces. In= particular, this
      document will focus on identifying a reasonable s= et of more urgent and
      important requirements that will be addressed in = the initial set of
      CDNI protocols and solutions produced by the work= ing group. This
      document will list the requirements stemming from= the threat analysis
      and to be met by each of the CDNI interfaces.

    - A specification of the "CDNI request-routing inte= rface". This
      interface will allow an upstream CDN request rout= ing system to obtain
      from the downstream CDN the information necessary= to perform request
      redirection.

    - A specification of the "CDNI metadata interface&q= uot;. This interface will
      allow the CDNs to exchange content distribution m= etadata of inter-CDN
      scope. Content distribution metadata refers to th= e subset of content
      metadata that is relevant to the distribution of = the content and
      therefore is to be processed by CDNs (for example= , this may include
      information enabling: content acquisition, geo-bl= ocking, enforcement
      of availability windows or access control).

    - A specification of the "CDNI logging interface&qu= ot;. This interface will
      allow CDN logging systems to exchange logging inf= ormation associated
      with actions that are relevant across CDNs (such = as content
      distribution, content delivery and content routin= g actions) for
      purposes of accounting, analytics, monitoring, et= c.

    - A specification of the "CDNI control interface&qu= ot;. In particular, this
      interface will allow an upstream CDN to remove or= invalidate content
      in a downstream CDN.

    - A specification of "URI S= igning for CDNI" allowing support of content access control across int= erconnected CDNs through signing of content URIs. In particular, this speci= fication will identify how URI signing impacts (or does not impact) each of the CDNI Interfaces.

    The WG will discuss and address the security, management= and operational
    issues specific to CDNI, inside the above documents and = specifications.

    The working group will only define solutions for aspects= of the CDN
    Interconnection problem space that require direct commun= ication or
    interoperation between CDNs.

    In particular, the WG will not define:

    - New session, transport or network protocols.

    - New protocols for delivering content from a CDN to an = End User/User
      Agent.

    - New protocols for ingestion of content or metadata bet= ween a CSP and a
      CDN.

    - New protocols for acquiring content across CDNs.

    - Protocols and algorithms for intra-CDN operations.

    - Support for Transparent Caching across CDNs.

    - New applications consuming CDNI logs.

    - Digital Right Management (DRM) mechanisms.

    The CDNI WG will work with other IETF WGs to assess, and= where
    appropriate, leverage protocols developed by those WGs, = in order to
    realize the CDNI requirements and CDNI interfaces. For e= xample, the WG
    may assess the suitability of the ALTO protocol as a pro= tocol to enable
    downstream CDNs to exchange information which may aid an= upstream CDN
    with making CDNI request routing decisions. The CDNI WG = will also
    coordinate with relevant groups outside the IETF such as= UltraViolet.


Goals and Milestones:
  Done     - Submit CDNI problem statement to IESG as I= nformational
  Done     - Submit CDNI use cases to IESG as Informati= onal
  Dec 2013 - Submit CDNI framework= to IESG as Informational
  Sep 2013 = - Submit CDNI requirements to IESG as Informational
  April 2014 - Submit specification of the CDNI Re= quest Routing/Redirection interface to IESG as Proposed Standard
  Dec 2013&= nbsp;- Submit specification of the CDNI Logging interface to IESG as Propos= ed Standard
  April 2014 - Submit specification of the CD= NI Control interface to IESG as proposed Standard
  Dec 2013&= nbsp;- Submit specification of the CDNI Metadata Distribution interface to = IESG as Proposed Standard
  Sep 2014 - Submit specification of the CDNI Requ= est Routing/Footprint & Capabilities Advertisement interface to IESG as= Proposed Standard
  Dec 2014 - Submit specification of URI = Signing for CDNI to IESG as Proposed Standard
  Dec 2014 - Recharter o= r dissolve





Cheers

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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D04B5CA9Dxmbrcdx10ciscoc_-- From flefauch@cisco.com Mon Aug 26 10:13:38 2013 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 663CD11E81D4 for ; Mon, 26 Aug 2013 10:13:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwQHT8RUHb7n for ; Mon, 26 Aug 2013 10:13:33 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8516011E81C8 for ; Mon, 26 Aug 2013 10:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4522; q=dns/txt; s=iport; t=1377537213; x=1378746813; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=jfwBB/MrsXPQMYsbHX2gu1G73kBSQEr1f8ZEg/6rKJo=; b=GWtv1J8jspRn9Geip5EV126SqS6LX/xN4lzMIv0jMJvVCxIyOIqNISv7 gLYTQURBq+3Be070PRMmFSdlUDCbbLBPU8AK8Escl0MVf2Z7qWqRsK7WL P40dqDsD/FYQLLuRF+z+7uFlhuqFCGVs8k5FgCvCemieZvk4cGYeaNu7A k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsUGALWLG1KtJXHA/2dsb2JhbABagwc1SwbAGYEiFm0HgiQBAQEDAQEBATc0BAcQAgEIIhQQJwslAgQOBQgBh3IGBwW3N5BFAjECBYMcfQOZG4sLhSmDHoIq X-IronPort-AV: E=Sophos;i="4.89,960,1367971200"; d="scan'208";a="251761982" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 26 Aug 2013 17:13:33 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r7QHDW8D026056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 26 Aug 2013 17:13:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 26 Aug 2013 12:13:32 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-framework@tools.ietf.org" Thread-Topic: I-D Action: draft-ietf-cdni-framework-04.txt Thread-Index: AQHOon+Xtf3UNJPzXUuQjyr85GIlJQ== Date: Mon, 26 Aug 2013 17:13:32 +0000 Message-ID: References: <20130821182607.19330.38545.idtracker@ietfa.amsl.com> In-Reply-To: <20130821182607.19330.38545.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <69AF0E4B6F889E489C576029A762E679@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-framework-04.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, 26 Aug 2013 17:13:38 -0000 CDNI Framework authors, Thanks for publishing an updated version as per the Berlin agreement, Below are a few comments/suggestions on -04. *** the interface names are not strictly aligned to the final naming we hav= e agreed top use across all documents. For memory, the exact names are: * CDNI Control interface (CI) * CDNI Metadata interface (MI) * CDNI Logging interface (LI) * CDNI Request Routing Redirection interface (RI) * CDNI Footprint & Capabilities Advertisement interface (FCI) (Note the capitalized/non-capitalized words). For example, the current version uses "Footprint & Capability Interface" in= stead of "CDNI Footprint & Capabilities Advertisement interface". *** I would recommend that we refer to the reference model as the "expanded= reference model" instead of the "extended reference model". This is becaus= e we do not want to suggest that we have changed teh referemce model in any= way. We are only showing a different representation of it that expands one= interface into its two components.=20 Specifically: OLD: " This document uses the reference model in Figure 1, which extends the reference model originally defined in RFC 6707. (The difference is that the extended model splits the Request Routing Interface into two distinct parts: the Request Routing Redirection Interface and the Footprint and Capability Interface, as described below.) " NEW: " This document uses the reference model in Figure 1, which expands the reference model originally defined in RFC 6707. (The difference is that the expanded model shows separately the two distinct components of the Request Routing interface : the Request Routi= ng Redirection interface and the Footprint and Capability Advertisement interface, as described below.) " OLD: " Figure 1: CDNI Model and CDNI Interfaces " NEW: " Figure 1: CDNI Expanded Model and CDNI Interfaces " *** inside Figure 1, I suggest replacing the CDNI interface names by their = "official" abbreviations (CI, MI, etc) since it is getting quite crammed an= d we end up with some abbreviation anyways (eg "Foot & Cap Int"). *** there are many occurences of unintended "\u002D"=20 Cheers Francois On 21 Aug 2013, at 20:26, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Content Delivery Networks Interconnectio= n Working Group of the IETF. >=20 > Title : Framework for CDN Interconnection > Author(s) : Larry Peterson > Bruce Davie > Filename : draft-ietf-cdni-framework-04.txt > Pages : 53 > Date : 2013-08-21 >=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, > distribution metadata exchange, and logging information exchange > across CDNs. 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. It obsoletes RFC 3466. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-framework >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-framework-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-framework-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From ray.vanbrandenburg@tno.nl Thu Aug 29 00:09:46 2013 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 A2ECD11E80EA for ; Thu, 29 Aug 2013 00:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 iINEMIYukHfa for ; Thu, 29 Aug 2013 00:09:41 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id B21B811E80F7 for ; Thu, 29 Aug 2013 00:09:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,981,1367964000"; d="scan'208,217";a="2172916" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 29 Aug 2013 09:09:37 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.176]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.03.0123.003; Thu, 29 Aug 2013 09:09:36 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" , "cdni@ietf.org" Thread-Topic: Draft CDNI charter update Thread-Index: AQHOonTNiFq0oneSn0aPMWN+YJpML5mrw9gw Date: Thu, 29 Aug 2013 07:09:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581F464BFFEXCMBX03tsntnon_" MIME-Version: 1.0 Subject: Re: [CDNi] Draft CDNI charter update 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, 29 Aug 2013 07:09:46 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F464BFFEXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Francois, all, Some comments from my side: - A specification of "URI Signing for CDNI" allowing support of co= ntent access control across interconnected CDNs through signing of content = URIs. In particular, this specification will identify how URI signing impac= ts (or does not impact) each of the CDNI Interfaces. To me, the first sente= nce captures the subject quite well, I'm not so sure about the second one. = While URI signing definitely has an impact on some of the other CDNI interf= aces, the sentence seems to imply the URI Signing doc will be some sort of = analysis document, instead of a specification. Maybe something like: "A spe= cification for 'CDNI URI Signing'. This document will specify a mechanism t= hat allows interconnected CDNs to support control access control by signing= content URIs." - The current milestone for URI Signing is Dec 2014. Looking at th= e maturity of the only candidate draft for URI Signing that is currently ou= t there, Sept 2014 (or maybe even July) seems realistic to me, especially s= ince the current candidate draft is a lot more mature than for example the = current FCI proposals, which are also listed for Sept 2014. - You might want to re-order the other milestones to line them up = chronologically. - Now that we're discussing the charter anyway, I noticed the fina= l sentence "The CDNI WG will also coordinate with relevant groups outside t= he IETF such as UltraViolet" Is this still relevant? Or should we take it o= ut? - The same is true for "The CDNI WG aims at delivering a targeted,= deployable solution in a short timeframe (18-24 months) as needed by the i= ndustry". Now that we're updating the dates, should we remove the '(18-24 m= onths)' from this line? Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: maandag 26 augustus 2013 17:56 To: cdni@ietf.org Subject: [CDNi] Draft CDNI charter update Hello, On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefauch) > wrote: Hi everyone, We've reached a tentative agreement during today's session to add a "URI Si= gning" deliverable to the CDNI charter. If you have comments or concerns about that, please express those on the li= st. There has been no concerns expressed on the Berlin tentative agreement to a= dd a "URI Signing" deliverable to the CDNI charter; so we will consider thi= s as a WG decision. Also, we need to update the target dates for existing Deliverables. Below is a proposal to update the Charter accordingly, with addition over t= he current charter showing up in red and changes showing up in blue. Please= review carefully and let us know if you have any comments on this proposal. Francois & Daryl PROPOSED NEW CHARTER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the "CDNI request-routing interface". This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the "CDNI metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification of "URI Signing for CDNI" allowing support of content= access control across interconnected CDNs through signing of content URIs.= In particular, this specification will identify how URI signing impacts (o= r does not impact) each of the CDNI Interfaces. The WG will discuss and address the security, management and operational issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet. Goals and Milestones: Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Dec 2013 - Submit CDNI framework to IESG as Informational Sep 2013 - Submit CDNI requirements to IESG as Informational April 2014 - Submit specification of the CDNI Request Routing/Redirection= interface to IESG as Proposed Standard Dec 2013 - Submit specification of the CDNI Logging interface to IESG as = Proposed Standard April 2014 - Submit specification of the CDNI Control interface to IESG a= s proposed Standard Dec 2013 - Submit specification of the CDNI Metadata Distribution interfa= ce to IESG as Proposed Standard Sep 2014 - Submit specification of the CDNI Request Routing/Footprint & C= apabilities Advertisement interface to IESG as Proposed Standard Dec 2014 - Submit specification of URI Signing for CDNI to IESG as Propos= ed Standard Dec 2014 - Recharter or dissolve Cheers Francois _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581F464BFFEXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Francoi= s, all,

 = ;

Some comme= nts from my side:

 = ;

-          A specification of = "URI Signing for CDNI" allowing support of content access control= across interconnected CDNs through signing of content URIs. In particular, this specification will identify how URI signing impacts (or does not impa= ct) each of the CDNI Interfaces. To me, the first sentence captures the subj= ect quite well, I’m not so sure about the second one. While URI signi= ng definitely has an impact on some of the other CDNI interfaces, the sentence seems to imply the URI Signing doc will be some sort of analy= sis document, instead of a specification. Maybe something like: “A specification for ‘CDNI URI Sign= ing’. This document will specify a mechanism that allows interconnect= ed CDNs to support control access control by signing content URIs.”

-          The current milesto= ne for URI Signing is Dec 2014. Looking at the maturity of the only candida= te draft for URI Signing that is currently out there, Sept 2014 (or maybe even July) seems realistic to me, especially since the curr= ent candidate draft is a lot more mature than for example the current FCI p= roposals, which are also listed for Sept 2014.

-          You might want to r= e-order the other milestones to line them up chronologically.

-          No= w that we’re discussing the charter anyway, I noticed the final sente= nce “The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet” Is this still relevant? Or should we t= ake it out?

-          Th= e same is true for “The CDNI WG aims at delivering a targeted, deploy= able solution in a short timeframe (18-24 months) as needed by the industry”. Now that we’re updating the dates, should we re= move the ‘(18-24 months)’ from this line?

 = ;

Best regar= ds,

 = ;

Ray

 = ;

 = ;

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: maandag 26 augustus 2013 17:56
To: cdni@ietf.org
Subject: [CDNi] Draft CDNI charter update

 

Hello,

 

On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefa= uch) <flefauch@cisco.com> w= rote:



Hi everyone,

We've reached a tentative agreement during today's session to add a "U= RI Signing" deliverable to the CDNI charter.
If you have comments or concerns about that, please express those on the li= st.

 

There has been no concerns expressed on the Berlin t= entative agreement to add a "URI Signing" deliverable to the= CDNI charter; so we will consider this as a WG decision.

 

Also, we need to update the target dates for existin= g Deliverables.

 

Below is a proposal to update the Charter accordingl= y, with addition over the current charter showing up in red and changes sho= wing up in blue. Please review carefully and let us know if you have any co= mments on this proposal. 

 

 

Francois & Daryl

 

 

PROPOSED NEW CHARTER

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

"

Description of Working Group:

 

 

    A Content Delivery Network (CDN) is an= infrastructure of network

    elements operating at layer 4 through = layer 7, arranged for the

    efficient distribution and delivery of= digital content. Such content

    includes, but is not limited to, web p= ages and images delivered via

    HTTP, and streaming of continuous medi= a delivered via HTTP, RTSP, RTMP,

    etc. CDNs typically provide services t= o multiple Content Service

    Providers (CSPs).

 

    CDNs provide numerous benefits: a shar= ed platform for multi-service

    content delivery, reduced transmission= costs for cacheable content,

    improved quality of experience for end= users and increased robustness of

    delivery. For these reasons they are f= requently used for large-scale

    content delivery.

 

    As a result of the significant growth = in content delivered over IP

    networks, existing CDN providers are s= caling up their infrastructure and

    many Network Service Providers and Ent= erprise Service Providers are

    deploying their own CDNs. Subject to t= he policy of the CSP, it is

    generally desirable that a given item = of content can be delivered to an

    end user regardless of that end user's= location or attachment network.

    This creates a need for interconnectin= g (previously) standalone CDNs so

    they can interoperate and collectively= behave as a single delivery

    infrastructure.

 

    The goal of the CDNI Working Group is = to allow the interconnection of

    separately administered CDNs in suppor= t of the end-to-end delivery of

    content from CSPs through multiple CDN= s and ultimately to end users (via

    their respective User Agents). The CDN= I WG aims at delivering a

    targeted, deployable solution in a sho= rt timeframe (18-24 months) as

    needed by the industry. It is expected= that the CDNI interfaces will be

    realized using existing IETF protocols= for transport and message

    exchange, and using existing object no= tation grammars/languages for the

    definition of CDNI objects and semanti= cs. In the event that protocol

    extensions or new protocols are deemed= necessary by the WG, the WG will

    recharter.

 

    The working group will focus on the fo= llowing items:

 

    - A "problem statement" docu= ment providing a description of the problem

      and a common terminology.<= /o:p>

 

    - A "use case" document desc= ribing scenarios for usage and applications

      of the CDNI solution and protoc= ols.

 

    - A "framework" document pro= viding a description of the different

      components of the CDNI architec= ture and how they interact with one

      another. This document will als= o include a "threat analysis"

      discussing the security concern= s and threats, the trust model and

      privacy issues specific to CDNI= .

 

    - A "requirements" document.= This document lists the requirements for

      the CDNI architecture and the C= DNI interfaces. In particular, this

      document will focus on identify= ing a reasonable set of more urgent and

      important requirements that wil= l be addressed in the initial set of

      CDNI protocols and solutions pr= oduced by the working group. This

      document will list the requirem= ents stemming from the threat analysis

      and to be met by each of the CD= NI interfaces.

 

    - A specification of the "CDNI re= quest-routing interface". This

      interface will allow an upstrea= m CDN request routing system to obtain

      from the downstream CDN the inf= ormation necessary to perform request

      redirection.

 

    - A specification of the "CDNI me= tadata interface". This interface will

      allow the CDNs to exchange cont= ent distribution metadata of inter-CDN

      scope. Content distribution met= adata refers to the subset of content

      metadata that is relevant to th= e distribution of the content and

      therefore is to be processed by= CDNs (for example, this may include

      information enabling: content a= cquisition, geo-blocking, enforcement

      of availability windows or acce= ss control).

 

    - A specification of the "CDNI lo= gging interface". This interface will

      allow CDN logging systems to ex= change logging information associated

      with actions that are relevant = across CDNs (such as content

      distribution, content delivery = and content routing actions) for

      purposes of accounting, analyti= cs, monitoring, etc.

 

    - A specification of the "CDNI co= ntrol interface". In particular, this

      interface will allow an upstrea= m CDN to remove or invalidate content

      in a downstream CDN.=

 

    - A spec= ification of "URI Signing for CDNI" allowing support of content a= ccess control across interconnected CDNs through signing of content URIs. I= n particular, this specification will identify how URI signing impacts (or does not impact) each of the CDNI Interfaces.

 

    The WG will discuss and address the se= curity, management and operational

    issues specific to CDNI, inside the ab= ove documents and specifications.

 

    The working group will only define sol= utions for aspects of the CDN

    Interconnection problem space that req= uire direct communication or

    interoperation between CDNs.

 

    In particular, the WG will not define:=

 

    - New session, transport or network pr= otocols.

 

    - New protocols for delivering content= from a CDN to an End User/User

      Agent.

 

    - New protocols for ingestion of conte= nt or metadata between a CSP and a

      CDN.

 

    - New protocols for acquiring content = across CDNs.

 

    - Protocols and algorithms for intra-C= DN operations.

 

    - Support for Transparent Caching acro= ss CDNs.

 

    - New applications consuming CDNI logs= .

 

    - Digital Right Management (DRM) mecha= nisms.

 

    The CDNI WG will work with other IETF = WGs to assess, and where

    appropriate, leverage protocols develo= ped by those WGs, in order to

    realize the CDNI requirements and CDNI= interfaces. For example, the WG

    may assess the suitability of the ALTO= protocol as a protocol to enable

    downstream CDNs to exchange informatio= n which may aid an upstream CDN

    with making CDNI request routing decis= ions. The CDNI WG will also

    coordinate with relevant groups outsid= e the IETF such as UltraViolet.

 

 

Goals and Milestones:

  Done     - Submit CDNI problem stat= ement to IESG as Informational

  Done     - Submit CDNI use cases to= IESG as Informational

  Dec 2013= - Submit CDNI framework to IESG as Informational

  Sep 2013=  - Submit CDNI requirements to IESG as Informational

  April 2014=  - Submit specification of the CDNI Request Routing/Redirection= interface to IESG as Proposed Standard

  Dec 2013 - Submit specification of the CDNI Logging interface to IESG as = Proposed Standard

  April = ;2014 - Submit specification of the CDNI Control interface to I= ESG as proposed Standard

  Dec 2013 - Submit specification of the CDNI Metadata Distribution interfa= ce to IESG as Proposed Standard

  Sep 2014 - Submit specification of the CDNI Request Routing/Footprint &am= p; Capabilities Advertisement interface to IESG as Proposed Standard

  Dec 2014 - Subm= it specification of URI Signing for CDNI to IESG as Proposed Standard

  Dec 2014 - Recharter or dissolve

 

 

 

 


Cheers

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

 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581F464BFFEXCMBX03tsntnon_-- From flefauch@cisco.com Thu Aug 29 01:06:55 2013 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 0009D21F9A70 for ; Thu, 29 Aug 2013 01:06:54 -0700 (PDT) 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=[AWL=-0.000, 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 Tf02Trs2+wJp for ; Thu, 29 Aug 2013 01:06:48 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0144421F9A38 for ; Thu, 29 Aug 2013 01:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63060; q=dns/txt; s=iport; t=1377763608; x=1378973208; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cb27/GaOD8R1hE5Q7yEUbZn8AcNibTIAj4r2RuZuQHg=; b=QWAqLpBrrRNFmP2qnLO/RGKZeNa+EdDxTyMBqG//VTq6r/pp7N8h5sIM GBX/+m8QslZTNM//ToFhuEPs1I4CxNVFw2vhVji7IAzo2kXhFTheo84CQ XRKx4hHO3GJX/EdMoXpByoYIt89h8lU353GYW2OOkNGfbmT8pXeVr4gLm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAMz/HlKtJXG9/2dsb2JhbABQCoJDRDVRwCiBJhZ0giQBAQEEAQEBF1QEBxACAQgRAQMBAQsWAQYHJwsUAwYIAgQOBQgTh2YMuH6OMQQGgQEHLQQGAQaDFoEAA5QZkQ6EMoE7gWWBaAkXIg X-IronPort-AV: E=Sophos;i="4.89,981,1367971200"; d="scan'208,217";a="253048858" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 29 Aug 2013 08:06:46 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r7T86jeP016116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 29 Aug 2013 08:06:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 03:06:45 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: Draft CDNI charter update Thread-Index: AQHOonTADCRiL5mwJkGqoIFfG0jz5pmsHFgAgAAP9AA= Date: Thu, 29 Aug 2013 08:06:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04B63AB3xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Draft CDNI charter update 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, 29 Aug 2013 08:06:55 -0000 X-List-Received-Date: Thu, 29 Aug 2013 08:06:55 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04B63AB3xmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ray and all, Thanks for these good comments. See below for detailed response: On 29 Aug 2013, at 09:09, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, Some comments from my side: - A specification of "URI Signing for CDNI" allowing support of co= ntent access control across interconnected CDNs through signing of content = URIs. In particular, this specification will identify how URI signing impac= ts (or does not impact) each of the CDNI Interfaces. To me, the first sente= nce captures the subject quite well, I=92m not so sure about the second one= . While URI signing definitely has an impact on some of the other CDNI inte= rfaces, the sentence seems to imply the URI Signing doc will be some sort o= f analysis document, instead of a specification. Maybe something like: =93A= specification for =91CDNI URI Signing=92. This document will specify a mec= hanism that allows interconnected CDNs to support control access control by= signing content URIs.=94 I see your concern. At the same time, I think it woudl be useful to clarify= the relationship of that specification with other CDNI interfaces ie it is= not about defining an additional interface, but instead may involve extens= ions to the other CDNI interfaces (eg potentially additonal CDNI metadata, = additional logging field). How about: =93 A specification for =91CDNI URI Signing=92. This document will specify a me= chanism that allows interconnected CDNs to support control access control b= y signing content URIs. This may involve extensions to the CDNI interfaces = (e.g. CDNI metadata interface, CDNI logging interface). =94 - The current milestone for URI Signing is Dec 2014. Looking at th= e maturity of the only candidate draft for URI Signing that is currently ou= t there, Sept 2014 (or maybe even July) seems realistic to me, especially s= ince the current candidate draft is a lot more mature than for example the = current FCI proposals, which are also listed for Sept 2014. Let's go for Sept 2014. Remember this target assumes the document has been = through a number of steps beyond "being ready" (eg WG Last Call, Chair/AD r= eview=85). But by all means, feel free to beat the target ^). - You might want to re-order the other milestones to line them up = chronologically. Agreed. - Now that we=92re discussing the charter anyway, I noticed the fi= nal sentence =93The CDNI WG will also coordinate with relevant groups outsi= de the IETF such as UltraViolet=94 Is this still relevant? Or should we tak= e it out? I'd agree to remove the explicit mention about Ultra-Violet. It may be wort= h keeping a placeholder to remember we may have to interact with some exter= nal groups (for example we have received a liaison from the NGMN about thei= r "Mobile Content Delivery Optimization" work). So we could rephrase into: " The CDNI WG will also coordinate with relevant groups outside the IETF, if = and where appropriate. " - The same is true for =93The CDNI WG aims at delivering a targete= d, deployable solution in a short timeframe (18-24 months) as needed by the= industry=94. Now that we=92re updating the dates, should we remove the =91= (18-24 months)=92 from this line? I'd agree to remove the =91(18-24 months)=92 from this line. The other clean-up we may want to do is to update the interface names to th= eir final agreed names and add a few words to clarify that the "request rou= ting interface" actually comprises two component interfaces, to make it eas= ier to understand why there are two corresponding deliverables. If folks ag= ree to that idea, we'll propose updated text for that too. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: maandag 26 augustus 2013 17:56 To: cdni@ietf.org Subject: [CDNi] Draft CDNI charter update Hello, On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefauch) > wrote: Hi everyone, We've reached a tentative agreement during today's session to add a "URI Si= gning" deliverable to the CDNI charter. If you have comments or concerns about that, please express those on the li= st. There has been no concerns expressed on the Berlin tentative agreement to a= dd a "URI Signing" deliverable to the CDNI charter; so we will consider thi= s as a WG decision. Also, we need to update the target dates for existing Deliverables. Below is a proposal to update the Charter accordingly, with addition over t= he current charter showing up in red and changes showing up in blue. Please= review carefully and let us know if you have any comments on this proposal= . Francois & Daryl PROPOSED NEW CHARTER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness o= f delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure an= d many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (vi= a their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent an= d important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the "CDNI request-routing interface". This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the "CDNI metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification of "URI Signing for CDNI" allowing support of content= access control across interconnected CDNs through signing of content URIs.= In particular, this specification will identify how URI signing impacts (o= r does not impact) each of the CDNI Interfaces. The WG will discuss and address the security, management and operationa= l issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and = a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet. Goals and Milestones: Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Dec 2013 - Submit CDNI framework to IESG as Informational Sep 2013 - Submit CDNI requirements to IESG as Informational April 2014 - Submit specification of the CDNI Request Routing/Redirection= interface to IESG as Proposed Standard Dec 2013 - Submit specification of the CDNI Logging interface to IESG as = Proposed Standard April 2014 - Submit specification of the CDNI Control interface to IESG a= s proposed Standard Dec 2013 - Submit specification of the CDNI Metadata Distribution interfa= ce to IESG as Proposed Standard Sep 2014 - Submit specification of the CDNI Request Routing/Footprint & C= apabilities Advertisement interface to IESG as Proposed Standard Dec 2014 - Submit specification of URI Signing for CDNI to IESG as Propos= ed Standard Dec 2014 - Recharter or dissolve Cheers Francois _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FC236DA6F2DA77449EF2D02DF4471A8D04B63AB3xmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <65A66D8BF072F24EA9502CC76E821401@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Ray and all,

Thanks for these good comments. See below for detailed response:

On 29 Aug 2013, at 09:09, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ;
 wrote:

Hi Francois, all,
 
Some comments from my side:
 
-      =     A specification of "URI Signing for CDNI" allowing support of cont= ent access control across interconnected CDNs through signing of content UR= Is. In particular, this specification will identify how URI signing impacts= (or does not impact) each of the CDNI Interfaces. To me, the first sentence captures the subject quite well, I=92m not so sure = about the second one. While URI signing definitely has an impact on some of= the other CDNI interfaces, the sentence seems to imply the URI Signing doc= will be some sort of analysis document, instead of a specification. Maybe something like: =93A specification for =91CDNI URI Sign= ing=92. This document will specify a mechanism that allows interconnected CDNs to support control access control by signing co= ntent URIs.=94

I see your concern. At the same time, I think it woudl be useful to cl= arify the relationship of that specification with other CDNI interfaces ie = it is not about defining an additional interface, but instead may involve e= xtensions to the other CDNI interfaces (eg potentially additonal CDNI metadata, additional logging field).

How about:
=93
A specification for =91CDNI URI Signing=92. This document will specify= a mechanism that allows interconnected CDNs to support control access cont= rol by signing content URIs. This may involve extensions to the CDNI interf= aces (e.g. CDNI metadata interface, CDNI logging interface).
=94 

-      =     The current milestone for URI Signing is Dec 2014. Looking at the maturity of = the only candidate draft for URI Signing that is currently out there, Sept = 2014 (or maybe even July) seems realistic to me, especially since the curre= nt candidate draft is a lot more mature than for example the current FCI proposals, which are also listed f= or Sept 2014.

Let's go for Sept 2014. Remember this target assumes the document has = been through a number of steps beyond "being ready" (eg WG Last C= all, Chair/AD review=85).
But by all means, feel free to beat the target ^). 

-      =     You might want to re-order the other milestones to line them up chronologicall= y.

Agreed.

-      =     Now that we=92re discussing the charter anyway, I noticed the final sentence = =93The CDNI WG will also coordinate with relevant groups outside the IETF s= uch as UltraViolet=94 Is this still relevant? Or should we take it out?

I'd agree to remove the explicit mention about Ultra-Violet. It may be= worth keeping a placeholder to remember we may have to interact with some = external groups (for example we have received a liaison from the NGMN about= their "Mobile Content Delivery Optimization" work). So we could rephrase into:
"
The CDNI WG will also coordinate with relevant groups outside the IETF= , if and where appropriate.
"

-      =     The same is true for =93The CDNI WG aims at delivering a targeted, deployable = solution in a short timeframe (18-24 months) as needed by the industry=94. = Now that we=92re updating the dates, should we remove the =91(18-24 months)= =92 from this line?

I'd agree to remove the =91(18-24 months)=92 from this line.

The other clean-up we may want to do is to update the interface names = to their final agreed names and add a few words to clarify that the "r= equest routing interface" actually comprises two component interfaces,= to make it easier to understand why there are two corresponding deliverables. If folks agree to that idea, we'll pro= pose updated text for that too.

Thanks

Francois

 
Best regards,
 
Ray
 
 
From:&nbs= p;cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)=
Sent: maandag 26 a= ugustus 2013 17:56
To: cdni@ietf.org
Subject: [CDNi] Dr= aft CDNI charter update
 
Hello,
 
 
There has been no concerns expressed on the Berlin tentative agreement to&n= bsp;add a "URI Signing" deliverable to the CDNI charter; so we wi= ll consider this as a WG decision.
 
Also, we need to update the target dates for existing Deliverables.
 
Below is a proposal to update the Charter accordingly, with addition over t= he current charter showing up in red and changes showing up in blue. Please= review carefully and let us know if you have any comments on this proposal= . 
 
 
Francois & Daryl
 
 
PROPOSED NEW CHARTER
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>
"
Description of Working Group:
 
 
    A Content Delivery Network (CDN) is an infrastructure of netw= ork
    elements operating at layer 4 through layer 7, arranged for t= he
    efficient distribution and delivery of digital content. Such = content
    includes, but is not limited to, web pages and images deliver= ed via
    HTTP, and streaming of continuous media delivered via HTTP, R= TSP, RTMP,
    etc. CDNs typically provide services to multiple Content Serv= ice
    Providers (CSPs).
 
    CDNs provide numerous benefits: a shared platform for multi-s= ervice
    content delivery, reduced transmission costs for cacheable co= ntent,
    improved quality of experience for end users and increased ro= bustness of
    delivery. For these reasons they are frequently used for larg= e-scale
    content delivery.
 
    As a result of the significant growth in content delivered ov= er IP
    networks, existing CDN providers are scaling up their infrast= ructure and
    many Network Service Providers and Enterprise Service Provide= rs are
    deploying their own CDNs. Subject to the policy of the CSP, i= t is
    generally desirable that a given item of content can be deliv= ered to an
    end user regardless of that end user's location or attachment= network.
    This creates a need for interconnecting (previously) standalo= ne CDNs so
    they can interoperate and collectively behave as a single del= ivery
    infrastructure.
 
    The goal of the CDNI Working Group is to allow the interconne= ction of
    separately administered CDNs in support of the end-to-end del= ivery of
    content from CSPs through multiple CDNs and ultimately to end= users (via
    their respective User Agents). The CDNI WG aims at delivering= a
    targeted, deployable solution in a short timeframe (18-24 mon= ths) as
    needed by the industry. It is expected that the CDNI interfac= es will be
    realized using existing IETF protocols for transport and mess= age
    exchange, and using existing object notation grammars/languag= es for the
    definition of CDNI objects and semantics. In the event that p= rotocol
    extensions or new protocols are deemed necessary by the WG, t= he WG will
    recharter.
 
    The working group will focus on the following items:
 
    - A "problem statement" document providing a descri= ption of the problem
      and a common terminology.
 
    - A "use case" document describing scenarios for us= age and applications
      of the CDNI solution and protocols.
 
    - A "framework" document providing a description of= the different
      components of the CDNI architecture and how they inter= act with one
      another. This document will also include a "threa= t analysis"
      discussing the security concerns and threats, the trus= t model and
      privacy issues specific to CDNI.
 
    - A "requirements" document. This document lists th= e requirements for
      the CDNI architecture and the CDNI interfaces. In part= icular, this
      document will focus on identifying a reasonable set of= more urgent and
      important requirements that will be addressed in the i= nitial set of
      CDNI protocols and solutions produced by the working g= roup. This
      document will list the requirements stemming from the = threat analysis
      and to be met by each of the CDNI interfaces.
 
    - A specification of the "CDNI request-routing interface= ". This
      interface will allow an upstream CDN request routing s= ystem to obtain
      from the downstream CDN the information necessary to p= erform request
      redirection.
 
    - A specification of the "CDNI metadata interface".= This interface will
      allow the CDNs to exchange content distribution metada= ta of inter-CDN
      scope. Content distribution metadata refers to the sub= set of content
      metadata that is relevant to the distribution of the c= ontent and
      therefore is to be processed by CDNs (for example, thi= s may include
      information enabling: content acquisition, geo-blockin= g, enforcement
      of availability windows or access control).=
 
    - A specification of the "CDNI logging interface". = This interface will
      allow CDN logging systems to exchange logging informat= ion associated
      with actions that are relevant across CDNs (such as co= ntent
      distribution, content delivery and content routing act= ions) for
      purposes of accounting, analytics, monitoring, etc.
 
    - A specification of the "CDNI control interface". = In particular, this
      interface will allow an upstream CDN to remove or inva= lidate content
      in a downstream CDN.
 
    - A specification o= f "URI Signing for CDNI" allowing support of content access contr= ol across interconnected CDNs through signing of content URIs. In particula= r, this specification will identify how URI signing impacts (or does not impact) each of the CDNI Interfaces.
 
    The WG will discuss and address the security, management and = operational
    issues specific to CDNI, inside the above documents and speci= fications.
 
    The working group will only define solutions for aspects of t= he CDN
    Interconnection problem space that require direct communicati= on or
    interoperation between CDNs.
 
    In particular, the WG will not define:
 
    - New session, transport or network protocols.
 
    - New protocols for delivering content from a CDN to an End U= ser/User
      Agent.
 
    - New protocols for ingestion of content or metadata between = a CSP and a
      CDN.
 
    - New protocols for acquiring content across CDNs.=
 
    - Protocols and algorithms for intra-CDN operations.
 
    - Support for Transparent Caching across CDNs.
 
    - New applications consuming CDNI logs.
 
    - Digital Right Management (DRM) mechanisms.
 
    The CDNI WG will work with other IETF WGs to assess, and wher= e
    appropriate, leverage protocols developed by those WGs, in or= der to
    realize the CDNI requirements and CDNI interfaces. For exampl= e, the WG
    may assess the suitability of the ALTO protocol as a protocol= to enable
    downstream CDNs to exchange information which may aid an upst= ream CDN
    with making CDNI request routing decisions. The CDNI WG will = also
    coordinate with relevant groups outside the IETF such as Ultr= aViolet.
 
 
Goals and Milestones:
  Done     - Submit CDNI problem statement to IESG as Inform= ational
  Done     - Submit CDNI use cases to IESG as Informational<= o:p>
  Dec 2013 - Submit CDNI framework to IESG as Informational<= /div>
  Sep 2013 - Submit CDNI requirements to = IESG as Informational
  April 2014 - Submit specification = of the CDNI Request Routing/Redirection interface to IESG as Proposed Stand= ard
  Dec 2013 = - Submit specification of the CDNI Logging interface to IESG as Proposed St= andard
  April 2014 - Submit specification of the CDNI Control interface to IESG as prop= osed Standard
  Dec 2013 = - Submit specification of the CDNI Metadata Distribution interface to IESG = as Proposed Standard
  Sep 2014 - Submit specification of= the CDNI Request Routing/Footprint & Capabilities Advertisement interf= ace to IESG as Proposed Standard
  Dec 2014 - Submit specific= ation of URI Signing for CDNI to IESG as Proposed Standard
  Dec 2014 = - Recharter or dissolve
 
 
 
 
 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer


--_000_FC236DA6F2DA77449EF2D02DF4471A8D04B63AB3xmbrcdx10ciscoc_-- From ray.vanbrandenburg@tno.nl Thu Aug 29 01:31:55 2013 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 1932621F9E51 for ; Thu, 29 Aug 2013 01:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.254 X-Spam-Level: X-Spam-Status: No, score=-0.254 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, 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 V2szyTjUM-WW for ; Thu, 29 Aug 2013 01:31:48 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 52ED021F9E3C for ; Thu, 29 Aug 2013 01:31:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,981,1367964000"; d="scan'208,217";a="2173980" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 29 Aug 2013 10:31:45 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.176]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Thu, 29 Aug 2013 10:31:45 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" Thread-Topic: Draft CDNI charter update Thread-Index: AQHOonTNiFq0oneSn0aPMWN+YJpML5mrw9gw///zHQCAACfuIA== Date: Thu, 29 Aug 2013 08:31:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581F464FCAEXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Draft CDNI charter update 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, 29 Aug 2013 08:31:55 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F464FCAEXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, Please see inline. Thanks, Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 29 augustus 2013 10:07 To: Brandenburg, R. (Ray) van Cc: Francois Le Faucheur (flefauch); cdni@ietf.org Subject: Re: Draft CDNI charter update Hi Ray and all, Thanks for these good comments. See below for detailed response: On 29 Aug 2013, at 09:09, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, Some comments from my side: - A specification of "URI Signing for CDNI" allowing support of co= ntent access control across interconnected CDNs through signing of content = URIs. In particular, this specification will identify how URI signing impac= ts (or does not impact) each of the CDNI Interfaces. To me, the first sente= nce captures the subject quite well, I'm not so sure about the second one. = While URI signing definitely has an impact on some of the other CDNI interf= aces, the sentence seems to imply the URI Signing doc will be some sort of = analysis document, instead of a specification. Maybe something like: "A spe= cification for 'CDNI URI Signing'. This document will specify a mechanism t= hat allows interconnected CDNs to support control access control by signing= content URIs." I see your concern. At the same time, I think it woudl be useful to clarify= the relationship of that specification with other CDNI interfaces ie it is= not about defining an additional interface, but instead may involve extens= ions to the other CDNI interfaces (eg potentially additonal CDNI metadata, = additional logging field). How about: " A specification for 'CDNI URI Signing'. This document will specify a mechan= ism that allows interconnected CDNs to support control access control by si= gning content URIs. This may involve extensions to the CDNI interfaces (e.g= . CDNI metadata interface, CDNI logging interface). Works for me. " - The current milestone for URI Signing is Dec 2014. Looking at th= e maturity of the only candidate draft for URI Signing that is currently ou= t there, Sept 2014 (or maybe even July) seems realistic to me, especially s= ince the current candidate draft is a lot more mature than for example the = current FCI proposals, which are also listed for Sept 2014. Let's go for Sept 2014. Remember this target assumes the document has been = through a number of steps beyond "being ready" (eg WG Last Call, Chair/AD r= eview...). But by all means, feel free to beat the target ^). I'll give it a shot ;) - You might want to re-order the other milestones to line them up = chronologically. Agreed. - Now that we're discussing the charter anyway, I noticed the fina= l sentence "The CDNI WG will also coordinate with relevant groups outside t= he IETF such as UltraViolet" Is this still relevant? Or should we take it o= ut? I'd agree to remove the explicit mention about Ultra-Violet. It may be wort= h keeping a placeholder to remember we may have to interact with some exter= nal groups (for example we have received a liaison from the NGMN about thei= r "Mobile Content Delivery Optimization" work). So we could rephrase into: " The CDNI WG will also coordinate with relevant groups outside the IETF, if = and where appropriate. " Ok. - The same is true for "The CDNI WG aims at delivering a targeted,= deployable solution in a short timeframe (18-24 months) as needed by the i= ndustry". Now that we're updating the dates, should we remove the '(18-24 m= onths)' from this line? I'd agree to remove the '(18-24 months)' from this line. The other clean-up we may want to do is to update the interface names to th= eir final agreed names and add a few words to clarify that the "request rou= ting interface" actually comprises two component interfaces, to make it eas= ier to understand why there are two corresponding deliverables. If folks ag= ree to that idea, we'll propose updated text for that too. That sounds like something we should definitely do. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: maandag 26 augustus 2013 17:56 To: cdni@ietf.org Subject: [CDNi] Draft CDNI charter update Hello, On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefauch) > wrote: Hi everyone, We've reached a tentative agreement during today's session to add a "URI Si= gning" deliverable to the CDNI charter. If you have comments or concerns about that, please express those on the li= st. There has been no concerns expressed on the Berlin tentative agreement to a= dd a "URI Signing" deliverable to the CDNI charter; so we will consider thi= s as a WG decision. Also, we need to update the target dates for existing Deliverables. Below is a proposal to update the Charter accordingly, with addition over t= he current charter showing up in red and changes showing up in blue. Please= review carefully and let us know if you have any comments on this proposal= . Francois & Daryl PROPOSED NEW CHARTER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness o= f delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure an= d many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (vi= a their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent an= d important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the "CDNI request-routing interface". This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the "CDNI metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification of "URI Signing for CDNI" allowing support of content= access control across interconnected CDNs through signing of content URIs.= In particular, this specification will identify how URI signing impacts (o= r does not impact) each of the CDNI Interfaces. The WG will discuss and address the security, management and operationa= l issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and = a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet. Goals and Milestones: Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Dec 2013 - Submit CDNI framework to IESG as Informational Sep 2013 - Submit CDNI requirements to IESG as Informational April 2014 - Submit specification of the CDNI Request Routing/Redirection= interface to IESG as Proposed Standard Dec 2013 - Submit specification of the CDNI Logging interface to IESG as = Proposed Standard April 2014 - Submit specification of the CDNI Control interface to IESG a= s proposed Standard Dec 2013 - Submit specification of the CDNI Metadata Distribution interfa= ce to IESG as Proposed Standard Sep 2014 - Submit specification of the CDNI Request Routing/Footprint & C= apabilities Advertisement interface to IESG as Proposed Standard Dec 2014 - Submit specification of URI Signing for CDNI to IESG as Propos= ed Standard Dec 2014 - Recharter or dissolve Cheers Francois _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581F464FCAEXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,
 
Please see inline.
 
Thanks,
 
Ray
 
Fr= om: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
Sent: donderdag 29 augustus 2013 10:07
To: Brandenburg, R. (Ray) van
Cc: Francois Le Faucheur (flefauch); cdni@ietf.org
Subject: Re: Draft CDNI charter update
 
Hi Ray and all,
 
Thanks for these good comments. See below for detailed response:=
 
On 29 Aug 2013, at 09:09, "Brandenburg, R. (Ray) van" <ray.vanbr= andenburg@tno.nl>
 wrote:

Hi Francois, all,
 
Some comments from my side:
 
-   =        A specification of "URI Signing for CDNI" allowing support of conte= nt access control across interconnected CDNs through signing of content URI= s. In particular, this specification will identify how URI signing impacts = (or does not impact) each of the CDNI Interfaces. To me, the first sentence captures the subject quite well, I’m not so su= re about the second one. While URI signing definitely has an impact on some= of the other CDNI interfaces, the sentence seems to imply the URI Signing = doc will be some sort of analysis document, instead of a specification. Maybe something like: “A specification for &= #8216;CDNI URI Signing’. This document will specify a mechanism that allows interconnected CDNs to support control access control by signin= g content URIs.”
 
I see your concern. At the same time, I think it woudl be useful to cla= rify the relationship of that specification with other CDNI interfaces ie i= t is not about defining an additional interface, but instead may involve extensions to the other CDNI interfaces = (eg potentially additonal CDNI metadata, additional logging field).<= /font>
 
How about:
“
A specification for ‘CDNI URI Signing’. This document will = specify a mechanism that allows interconnected CDNs to support control acce= ss control by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI metadata interface, CDNI loggi= ng interface).
 
 
Works for me.
 
 
 
” 

-   =        The current milestone for URI Signing is Dec 2014. Looking at the maturity of t= he only candidate draft for URI Signing that is currently out there, Sept 2= 014 (or maybe even July) seems realistic to me, especially since the curren= t candidate draft is a lot more mature than for example the current FCI proposals, which are also listed fo= r Sept 2014.
 
Let's go for Sept 2014. Remember this target assumes the document has b= een through a number of steps beyond "being ready" (eg WG Last Ca= ll, Chair/AD review…).
But by all means, feel free to beat the target ^). <= /div>
 
 
I’ll give it a shot ;)
 

-   =        You might want to re-order the other milestones to line them up chronologically= .
 
Agreed.

-   =        Now tha= t we’re discussing the charter anyway, I noticed the final sentence “The CDNI WG will also c= oordinate with relevant groups outside the IETF such as UltraViolet” = Is this still relevant? Or should we take it out?
 
I'd agree to remove the explicit mention about Ultra-Violet. It may be = worth keeping a placeholder to remember we may have to interact with some e= xternal groups (for example we have received a liaison from the NGMN about their "Mobile Content Delivery Optimizat= ion" work). So we could rephrase into:
"
The CDNI WG will also coordinate with relevant groups outside the IETF,= if and where appropriate.
"
 
Ok.
 

-   =        The sam= e is true for “The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe = (18-24 months) as needed by the industry”. Now that we’re updat= ing the dates, should we remove the ‘(18-24 months)’ from this = line?
 
I'd agree to remove the ‘(18-24 months)’ from this lin= e.
 
The other clean-up we may want to do is to update the interface names t= o their final agreed names and add a few words to clarify that the "re= quest routing interface" actually comprises two component interfaces, to make it easier to understand why there are two= corresponding deliverables. If folks agree to that idea, we'll propose upd= ated text for that too.
 
That sounds like something we should definitel= y do.
 
Thanks
 
Francois

 
Best regards,
 
Ray
 
 
Fr= om: = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Francois Le Faucheur (flefauch)
Sent: maandag 26 augustus 2013 17:56
To: cd= ni@ietf.org
Subject: [CDNi] Draft CDNI charter update
 
Hello,
 
On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:


Hi everyone,

We've reached a tentative agreement during today's session to add a "U= RI Signing" deliverable to the CDNI charter.
If you have comments or concerns about that, please express those on the li= st.
 
There has been no concerns expressed on the Berlin tentative agreement = to add a "URI Signing" deliverable to the CDNI charter; so w= e will consider this as a WG decision.
 
Also, we need to update the target dates for existing Deliverables.
 
Below is a proposal to update the Charter accordingly, with addition ov= er the current charter showing up in red and changes showing up in blue. Pl= ease review carefully and let us know if you have any comments on this proposal. 
 
 
Francois & Daryl
 
 
PROPOSED NEW CHARTER
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
"
Description of Working Group:
 
 
    A Content Delivery Network (CDN) is an infrastructure of = network
    elements operating at layer 4 through layer 7, arranged f= or the
    efficient distribution and delivery of digital content. S= uch content
    includes, but is not limited to, web pages and images del= ivered via
    HTTP, and streaming of continuous media delivered via HTT= P, RTSP, RTMP,
    etc. CDNs typically provide services to multiple Content = Service
    Providers (CSPs).
 
    CDNs provide numerous benefits: a shared platform for mul= ti-service
    content delivery, reduced transmission costs for cacheabl= e content,
    improved quality of experience for end users and increase= d robustness of
    delivery. For these reasons they are frequently used for = large-scale
    content delivery.
 
    As a result of the significant growth in content delivere= d over IP
    networks, existing CDN providers are scaling up their inf= rastructure and
    many Network Service Providers and Enterprise Service Pro= viders are
    deploying their own CDNs. Subject to the policy of the CS= P, it is
    generally desirable that a given item of content can be d= elivered to an
    end user regardless of that end user's location or attach= ment network.
    This creates a need for interconnecting (previously) stan= dalone CDNs so
    they can interoperate and collectively behave as a single= delivery
    infrastructure.
 
    The goal of the CDNI Working Group is to allow the interc= onnection of
    separately administered CDNs in support of the end-to-end= delivery of
    content from CSPs through multiple CDNs and ultimately to= end users (via
    their respective User Agents). The CDNI WG aims at delive= ring a
    targeted, deployable solution in a short timeframe (18-24= months) as
    needed by the industry. It is expected that the CDNI inte= rfaces will be
    realized using existing IETF protocols for transport and = message
    exchange, and using existing object notation grammars/lan= guages for the
    definition of CDNI objects and semantics. In the event th= at protocol
    extensions or new protocols are deemed necessary by the W= G, the WG will
    recharter.
 
    The working group will focus on the following items:
 
    - A "problem statement" document providing a de= scription of the problem
      and a common terminology.
 
    - A "use case" document describing scenarios fo= r usage and applications
      of the CDNI solution and protocols.<= /div>
 
    - A "framework" document providing a descriptio= n of the different
      components of the CDNI architecture and how they i= nteract with one
      another. This document will also include a "t= hreat analysis"
      discussing the security concerns and threats, the = trust model and
      privacy issues specific to CDNI.
 
    - A "requirements" document. This document list= s the requirements for
      the CDNI architecture and the CDNI interfaces. In = particular, this
      document will focus on identifying a reasonable se= t of more urgent and
      important requirements that will be addressed in t= he initial set of
      CDNI protocols and solutions produced by the worki= ng group. This
      document will list the requirements stemming from = the threat analysis
      and to be met by each of the CDNI interfaces.
 
    - A specification of the "CDNI request-routing inter= face". This
      interface will allow an upstream CDN request routi= ng system to obtain
      from the downstream CDN the information necessary = to perform request
      redirection.
 
    - A specification of the "CDNI metadata interface&qu= ot;. This interface will
      allow the CDNs to exchange content distribution me= tadata of inter-CDN
      scope. Content distribution metadata refers to the= subset of content
      metadata that is relevant to the distribution of t= he content and
      therefore is to be processed by CDNs (for example,= this may include
      information enabling: content acquisition, geo-blo= cking, enforcement
      of availability windows or access control).=
 
    - A specification of the "CDNI logging interface&quo= t;. This interface will
      allow CDN logging systems to exchange logging info= rmation associated
      with actions that are relevant across CDNs (such a= s content
      distribution, content delivery and content routing= actions) for
      purposes of accounting, analytics, monitoring, etc= .
 
    - A specification of the "CDNI control interface&quo= t;. In particular, this
      interface will allow an upstream CDN to remove or = invalidate content
      in a downstream CDN.
 
    - A specification of "URI Signing = for CDNI" allowing support of content access control across interconne= cted CDNs through signing of content URIs. In particular, this specification will identify how URI signing impacts (or does not impact) ea= ch of the CDNI Interfaces.
 
    The WG will discuss and address the security, management = and operational
    issues specific to CDNI, inside the above documents and s= pecifications.
 
    The working group will only define solutions for aspects = of the CDN
    Interconnection problem space that require direct communi= cation or
    interoperation between CDNs.
 
    In particular, the WG will not define:
 
    - New session, transport or network protocols.
 
    - New protocols for delivering content from a CDN to an E= nd User/User
      Agent.
 
    - New protocols for ingestion of content or metadata betw= een a CSP and a
      CDN.
 
    - New protocols for acquiring content across CDNs.=
 
    - Protocols and algorithms for intra-CDN operations.
 
    - Support for Transparent Caching across CDNs.
 
    - New applications consuming CDNI logs.
 
    - Digital Right Management (DRM) mechanisms.
 
    The CDNI WG will work with other IETF WGs to assess, and = where
    appropriate, leverage protocols developed by those WGs, i= n order to
    realize the CDNI requirements and CDNI interfaces. For ex= ample, the WG
    may assess the suitability of the ALTO protocol as a prot= ocol to enable
    downstream CDNs to exchange information which may aid an = upstream CDN
    with making CDNI request routing decisions. The CDNI WG w= ill also
    coordinate with relevant groups outside the IETF such as = UltraViolet.
 
 
Goals and Milestones:
  Done     - Submit CDNI problem statement to IESG as In= formational
  Done     - Submit CDNI use cases to IESG as Informatio= nal
  Dec 2013 - Submit CDNI = framework to IESG as Informational
  Sep 2013 - Submit CDNI = requirements to IESG as Informational
  April 2014 - Submi= t specification of the CDNI Request Routing/Redirection interface to IESG a= s Proposed Standard
  Dec 2013 - Submit speci= fication of the CDNI Logging interface to IESG as Proposed Standard<= /font>
  April 2014 - Submi= t specification of the CDNI Control interface to IESG as proposed Standard<= /span>
  Dec 2013 - Submit speci= fication of the CDNI Metadata Distribution interface to IESG as Proposed St= andard
  Sep 2014 - Submit = specification of the CDNI Request Routing/Footprint & Capabilities Adve= rtisement interface to IESG as Proposed Standard
  Dec 2014 - Submit specification of URI Signing= for CDNI to IESG as Proposed Standard
  Dec 2014 - Recharter or= dissolve
 
 
 
 

Cheers

Francois
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
 
This e-mail and its contents ar= e subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer
 
 
 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F464FCAEXCMBX03tsntnon_-- From flefauch@cisco.com Thu Aug 29 01:53:05 2013 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 E36F621E8084 for ; Thu, 29 Aug 2013 01:53:05 -0700 (PDT) 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=[AWL=-0.000, 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 zUi9OfWCQ8yL for ; Thu, 29 Aug 2013 01:53:01 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 57F2421E8082 for ; Thu, 29 Aug 2013 01:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=78101; q=dns/txt; s=iport; t=1377766380; x=1378975980; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=oyzQLvaxSJpvKLoGi/I71s1vLFQ10K7CnOnzHwxKyPo=; b=RmxR4WYi7JS0bfweBa6ViQvaCoiNngITx0lg1N+gvRgvvclg3tRXSeDM sJDEXnY+KLicm4+E3vZ8wiKXJogoQo3zTCkN9aKag+g5mAVv1H4Xyl+6c ve8UhOfx/CWrssRW52xj2BG7TcRCFGb/eDKNvBYVbhFX2Hoef4dOGAxwe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQGABYLH1KtJXG8/2dsb2JhbABQCoJDRDVRwCiBKBZtB4IkAQEBBAEBARcBUwQXAgEIEQEDAQELFgEGBycLFAMGCAIEEwgTh2YMuQCOMQQGgQEHLQoBBoMWgQADhUqOT5EOhDKDIIFoCRci X-IronPort-AV: E=Sophos;i="4.89,981,1367971200"; d="scan'208,217";a="253040008" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 29 Aug 2013 08:52:59 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r7T8qxtQ024307 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 29 Aug 2013 08:52:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.8]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 29 Aug 2013 03:52:58 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Draft CDNI charter update Thread-Index: AQHOonTADCRiL5mwJkGqoIFfG0jz5pmsHFgAgAAP9ACAAAb+AIAABeuA Date: Thu, 29 Aug 2013 08:52:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04B63DB2xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [CDNi] Draft CDNI charter update 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, 29 Aug 2013 08:53:06 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04B63DB2xmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Everyone, Below is an updated draft proposed charter reflecting the discussion with R= ay. Changes in blue, Additions in red. Please review. Cheers Francois PROPOSED NEW CHARTER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness o= f delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure an= d many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (vi= a their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent an= d important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the CDNI request-routing interface. This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. It is actually a logical bundling of two separate but related interfaces: * Footprint & Capability Advertisement interface: Asynchronous opera= tions to exchange routing information (e.g., the network footprint and capabilities served by a given CDN) that enables CDN selection for subsequent user requests; and * Request Routing Redirection interface: Synchronous operations to select a delivery CDN (surrogate) for a given user request. - A specification of the "CDNI Metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI Logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI Control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification for =91CDNI URI Signing=92. This document will specif= y a mechanism that allows interconnected CDNs to support access control by = signing content URIs. This may involve extensions to the CDNI interfaces (e= .g. CDNI metadata interface, CDNI logging interface). The WG will discuss and address the security, management and operationa= l issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and = a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF, if and where appropri= ate. Goals and Milestones: Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Sep 2013 - Submit CDNI requirements to IESG as Informational Dec 2013 - Submit CDNI framework to IESG as Informational Dec 2013 - Submit specification of the CDNI Logging interface to IESG as = Proposed Standard Dec 2013 - Submit specification of the CDNI Metadata interface to IESG as= Proposed Standard April 2014 - Submit specification of the CDNI Request Routing Redirection= interface to IESG as Proposed Standard April 2014 - Submit specification of the CDNI Control interface to IESG a= s proposed Standard Sep 2014 - Submit specification of the CDNI Footprint & Capabilities Adve= rtisement interface to IESG as Proposed Standard Sep 2014 - Submit specification of URI Signing for CDNI to IESG as Propos= ed Standard Sep 2014 - Recharter or dissolve On 29 Aug 2013, at 10:31, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, Please see inline. Thanks, Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 29 augustus 2013 10:07 To: Brandenburg, R. (Ray) van Cc: Francois Le Faucheur (flefauch); cdni@ietf.org Subject: Re: Draft CDNI charter update Hi Ray and all, Thanks for these good comments. See below for detailed response: On 29 Aug 2013, at 09:09, "Brandenburg, R. (Ray) van" > wrote: Hi Francois, all, Some comments from my side: - A specification of "URI Signing for CDNI" allowing support of co= ntent access control across interconnected CDNs through signing of content = URIs. In particular, this specification will identify how URI signing impac= ts (or does not impact) each of the CDNI Interfaces. To me, the first sente= nce captures the subject quite well, I=92m not so sure about the second one= . While URI signing definitely has an impact on some of the other CDNI inte= rfaces, the sentence seems to imply the URI Signing doc will be some sort o= f analysis document, instead of a specification. Maybe something like: =93A= specification for =91CDNI URI Signing=92. This document will specify a mec= hanism that allows interconnected CDNs to support control access control by= signing content URIs.=94 I see your concern. At the same time, I think it woudl be useful to clarify= the relationship of that specification with other CDNI interfaces ie it is= not about defining an additional interface, but instead may involve extens= ions to the other CDNI interfaces (eg potentially additonal CDNI metadata, = additional logging field). How about: =93 A specification for =91CDNI URI Signing=92. This document will specify a me= chanism that allows interconnected CDNs to support control access control b= y signing content URIs. This may involve extensions to the CDNI interfaces = (e.g. CDNI metadata interface, CDNI logging interface). Works for me. =94 - The current milestone for URI Signing is Dec 2014. Looking at th= e maturity of the only candidate draft for URI Signing that is currently ou= t there, Sept 2014 (or maybe even July) seems realistic to me, especially s= ince the current candidate draft is a lot more mature than for example the = current FCI proposals, which are also listed for Sept 2014. Let's go for Sept 2014. Remember this target assumes the document has been = through a number of steps beyond "being ready" (eg WG Last Call, Chair/AD r= eview=85). But by all means, feel free to beat the target ^). I=92ll give it a shot ;) - You might want to re-order the other milestones to line them up = chronologically. Agreed. - Now that we=92re discussing the charter anyway, I noticed the fi= nal sentence =93The CDNI WG will also coordinate with relevant groups outsi= de the IETF such as UltraViolet=94 Is this still relevant? Or should we tak= e it out? I'd agree to remove the explicit mention about Ultra-Violet. It may be wort= h keeping a placeholder to remember we may have to interact with some exter= nal groups (for example we have received a liaison from the NGMN about thei= r "Mobile Content Delivery Optimization" work). So we could rephrase into: " The CDNI WG will also coordinate with relevant groups outside the IETF, if = and where appropriate. " Ok. - The same is true for =93The CDNI WG aims at delivering a targete= d, deployable solution in a short timeframe (18-24 months) as needed by the= industry=94. Now that we=92re updating the dates, should we remove the =91= (18-24 months)=92 from this line? I'd agree to remove the =91(18-24 months)=92 from this line. The other clean-up we may want to do is to update the interface names to th= eir final agreed names and add a few words to clarify that the "request rou= ting interface" actually comprises two component interfaces, to make it eas= ier to understand why there are two corresponding deliverables. If folks ag= ree to that idea, we'll propose updated text for that too. That sounds like something we should definitely do. Thanks Francois Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: maandag 26 augustus 2013 17:56 To: cdni@ietf.org Subject: [CDNi] Draft CDNI charter update Hello, On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefauch) > wrote: Hi everyone, We've reached a tentative agreement during today's session to add a "URI Si= gning" deliverable to the CDNI charter. If you have comments or concerns about that, please express those on the li= st. There has been no concerns expressed on the Berlin tentative agreement to a= dd a "URI Signing" deliverable to the CDNI charter; so we will consider thi= s as a WG decision. Also, we need to update the target dates for existing Deliverables. Below is a proposal to update the Charter accordingly, with addition over t= he current charter showing up in red and changes showing up in blue. Please= review carefully and let us know if you have any comments on this proposal= . Francois & Daryl PROPOSED NEW CHARTER =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D " Description of Working Group: A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs). CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness o= f delivery. For these reasons they are frequently used for large-scale content delivery. As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure an= d many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a need for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure. The goal of the CDNI Working Group is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (vi= a their respective User Agents). The CDNI WG aims at delivering a targeted, deployable solution in a short timeframe (18-24 months) as needed by the industry. It is expected that the CDNI interfaces will be realized using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics. In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter. The working group will focus on the following items: - A "problem statement" document providing a description of the problem and a common terminology. - A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols. - A "framework" document providing a description of the different components of the CDNI architecture and how they interact with one another. This document will also include a "threat analysis" discussing the security concerns and threats, the trust model and privacy issues specific to CDNI. - A "requirements" document. This document lists the requirements for the CDNI architecture and the CDNI interfaces. In particular, this document will focus on identifying a reasonable set of more urgent an= d important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group. This document will list the requirements stemming from the threat analysis and to be met by each of the CDNI interfaces. - A specification of the "CDNI request-routing interface". This interface will allow an upstream CDN request routing system to obtain from the downstream CDN the information necessary to perform request redirection. - A specification of the "CDNI metadata interface". This interface will allow the CDNs to exchange content distribution metadata of inter-CDN scope. Content distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore is to be processed by CDNs (for example, this may include information enabling: content acquisition, geo-blocking, enforcement of availability windows or access control). - A specification of the "CDNI logging interface". This interface will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc. - A specification of the "CDNI control interface". In particular, this interface will allow an upstream CDN to remove or invalidate content in a downstream CDN. - A specification of "URI Signing for CDNI" allowing support of content= access control across interconnected CDNs through signing of content URIs.= In particular, this specification will identify how URI signing impacts (o= r does not impact) each of the CDNI Interfaces. The WG will discuss and address the security, management and operationa= l issues specific to CDNI, inside the above documents and specifications. The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs. In particular, the WG will not define: - New session, transport or network protocols. - New protocols for delivering content from a CDN to an End User/User Agent. - New protocols for ingestion of content or metadata between a CSP and = a CDN. - New protocols for acquiring content across CDNs. - Protocols and algorithms for intra-CDN operations. - Support for Transparent Caching across CDNs. - New applications consuming CDNI logs. - Digital Right Management (DRM) mechanisms. The CDNI WG will work with other IETF WGs to assess, and where appropriate, leverage protocols developed by those WGs, in order to realize the CDNI requirements and CDNI interfaces. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions. The CDNI WG will also coordinate with relevant groups outside the IETF such as UltraViolet. Goals and Milestones: Done - Submit CDNI problem statement to IESG as Informational Done - Submit CDNI use cases to IESG as Informational Dec 2013 - Submit CDNI framework to IESG as Informational Sep 2013 - Submit CDNI requirements to IESG as Informational April 2014 - Submit specification of the CDNI Request Routing/Redirection= interface to IESG as Proposed Standard Dec 2013 - Submit specification of the CDNI Logging interface to IESG as = Proposed Standard April 2014 - Submit specification of the CDNI Control interface to IESG a= s proposed Standard Dec 2013 - Submit specification of the CDNI Metadata Distribution interfa= ce to IESG as Proposed Standard Sep 2014 - Submit specification of the CDNI Request Routing/Footprint & C= apabilities Advertisement interface to IESG as Proposed Standard Dec 2014 - Submit specification of URI Signing for CDNI to IESG as Propos= ed Standard Dec 2014 - Recharter or dissolve Cheers Francois _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FC236DA6F2DA77449EF2D02DF4471A8D04B63DB2xmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <9E21C5E1E10CD747A81CC384F3D625B5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Everyone,

Below is an updated draft proposed charter reflecting the discussion w= ith Ray.
Changes in blue, Additions in red.

Please review.

Cheers

Francois



PROPOSED NEW CHARTER
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /div>
"
Description of Working Group:


    A Content Delivery Network (CDN) is an infrastructure of= network
    elements operating at layer 4 through layer 7, arranged = for the
    efficient distribution and delivery of digital content. = Such content
    includes, but is not limited to, web pages and images de= livered via
    HTTP, and streaming of continuous media delivered via HT= TP, RTSP, RTMP,
    etc. CDNs typically provide services to multiple Content= Service
    Providers (CSPs).

    CDNs provide numerous benefits: a shared platform for mu= lti-service
    content delivery, reduced transmission costs for cacheab= le content,
    improved quality of experience for end users and increas= ed robustness of
    delivery. For these reasons they are frequently used for= large-scale
    content delivery.

    As a result of the significant growth in content deliver= ed over IP
    networks, existing CDN providers are scaling up their in= frastructure and
    many Network Service Providers and Enterprise Service Pr= oviders are
    deploying their own CDNs. Subject to the policy of the C= SP, it is
    generally desirable that a given item of content can be = delivered to an
    end user regardless of that end user's location or attac= hment network.
    This creates a need for interconnecting (previously) sta= ndalone CDNs so
    they can interoperate and collectively behave as a singl= e delivery
    infrastructure.

    The goal of the CDNI Working Group is to allow the inter= connection of
    separately administered CDNs in support of the end-to-en= d delivery of
    content from CSPs through multiple CDNs and ultimately t= o end users (via
    their respective User Agents). The CDNI WG aims at deliv= ering a
    targeted, deployable solution in a short timeframe as
    needed by the industry. It is expected that the CDNI int= erfaces will be
    realized using existing IETF protocols for transport and= message
    exchange, and using existing object notation grammars/la= nguages for the
    definition of CDNI objects and semantics. In the event t= hat protocol
    extensions or new protocols are deemed necessary by the = WG, the WG will
    recharter.

    The working group will focus on the following items:

    - A "problem statement" document providing a d= escription of the problem
      and a common terminology.

    - A "use case" document describing scenarios f= or usage and applications
      of the CDNI solution and protocols.

    - A "framework" document providing a descripti= on of the different
      components of the CDNI architecture and how they = interact with one
      another. This document will also include a "= threat analysis"
      discussing the security concerns and threats, the= trust model and
      privacy issues specific to CDNI.

    - A "requirements" document. This document lis= ts the requirements for
      the CDNI architecture and the CDNI interfaces. In= particular, this
      document will focus on identifying a reasonable s= et of more urgent and
      important requirements that will be addressed in = the initial set of
      CDNI protocols and solutions produced by the work= ing group. This
      document will list the requirements stemming from= the threat analysis
      and to be met by each of the CDNI interfaces.

    - A specification of the CD= NI request-routing interface. This
      interface will allow an upstream CDN request rout= ing system to obtain
      from the downstream CDN the information necessary= to perform request
      redirection.  It is actually a logical = bundling of two separate
      but related interfaces:

      *  Footprint & C= apability Advertisement interface: Asynchronous operations
         to exchange = routing information (e.g., the network footprint
         and capabili= ties served by a given CDN) that enables CDN
         selection fo= r subsequent user requests; and

      *  Request Routing R= edirection interface: Synchronous operations to
         select a del= ivery CDN (surrogate) for a given user request.

    - A specification of the "C= DNI Metadata interface". This interface will
      allow the CDNs to exchange content distribution m= etadata of inter-CDN
      scope. Content distribution metadata refers to th= e subset of content
      metadata that is relevant to the distribution of = the content and
      therefore is to be processed by CDNs (for example= , this may include
      information enabling: content acquisition, geo-bl= ocking, enforcement
      of availability windows or access control).

    - A specification of the "C= DNI Logging interface". This interface will
      allow CDN logging systems to exchange logging inf= ormation associated
      with actions that are relevant across CDNs (such = as content
      distribution, content delivery and content routin= g actions) for
      purposes of accounting, analytics, monitoring, et= c.

    - A specification of the "C= DNI Control interface". In particular, this
      interface will allow an upstream CDN to remove or= invalidate content
      in a downstream CDN.

    - A specification for =91CD= NI URI Signing=92. This document will specify a mechanism that allows inter= connected CDNs to support access control by signing content URIs. This= may involve extensions to the CDNI interfaces (e.g. CDNI metadata interface, CDNI logging interface).

    The WG will discuss and address the security, management= and operational
    issues specific to CDNI, inside the above documents and = specifications.

    The working group will only define solutions for aspects= of the CDN
    Interconnection problem space that require direct commun= ication or
    interoperation between CDNs.

    In particular, the WG will not define:

    - New session, transport or network protocols.

    - New protocols for delivering content from a CDN to an = End User/User
      Agent.

    - New protocols for ingestion of content or metadata bet= ween a CSP and a
      CDN.

    - New protocols for acquiring content across CDNs.

    - Protocols and algorithms for intra-CDN operations.

    - Support for Transparent Caching across CDNs.

    - New applications consuming CDNI logs.

    - Digital Right Management (DRM) mechanisms.

    The CDNI WG will work with other IETF WGs to assess, and= where
    appropriate, leverage protocols developed by those WGs, = in order to
    realize the CDNI requirements and CDNI interfaces. For e= xample, the WG
    may assess the suitability of the ALTO protocol as a pro= tocol to enable
    downstream CDNs to exchange information which may aid an= upstream CDN
    with making CDNI request routing decisions. The CDNI WG = will also
    coordinate with relevant groups outside the IETF, if and= where appropriate.


Goals and Milestones:
  Done     - Submit CDNI problem statement to IESG as I= nformational
  Done     - Submit CDNI use cases to IESG as Informati= onal
  Sep 2013&= nbsp;- Submit CDNI requirements to IESG as Informational
  Dec 2013 - Submit CDNI= framework to IESG as Informational
  Dec 2013&= nbsp;- Submit specification of the CDNI Logging interface to IESG as Propos= ed Standard
  Dec 2013&= nbsp;- Submit specification of the CDNI Metada= ta interface to IESG as Proposed Standard
  April 2014 - Submit specification of the&nb= sp;CDNI Request Routing Redirection interface to IESG as Proposed Standard
  April 2014 - Submit specification of the CD= NI Control interface to IESG as proposed Standard
  Sep 2014 - Submit specification of the = ;CDNI Footprint & Capabilities Advertisement in= terface to IESG as Proposed Standard
  Sep 2014 - Submit specification of URI = Signing for CDNI to IESG as Proposed Standard
  Sep 2014 - Recharter o= r dissolve




On 29 Aug 2013, at 10:31, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ;
 wrote:

Hi Francois,
 
Please see inline.
 
Thanks,
 
Ray
 
= From: Francois Le Fau= cheur (flefauch) [mailto:flefauch@cis= co.com] 
Sent: donderdag 29= augustus 2013 10:07
To: Brandenburg, R= . (Ray) van
Cc: Francois Le Fa= ucheur (flefauch); cdni@ietf.org
Subject: Re: Draft= CDNI charter update
 
Hi Ray and all,
 
Thanks for these good comments. See below for detailed response:
 
On 29 Aug 2013, at 09:09, "Brandenburg, R. (Ray) van" <<= a href=3D"mailto:ray.vanbrandenburg@tno.nl">ray.van= brandenburg@tno.nl>
 wrote:

Hi Francois, all,
 
Some comments from my side:
 
-  &n= bsp;       <= font size=3D"3" color=3D"#FF280A">A specification of "URI Signing for CDNI" allowing support of cont= ent access control across interconnected CDNs through signing of content UR= Is. In particular, this specification will identify how URI signing impacts= (or does not impact) each of the CDNI Interfaces. To me, the first sentence captures the subject quite well, I=92m not so sure = about the second one. While URI signing definitely has an impact on some of= the other CDNI interfaces, the sentence seems to imply the URI Signing doc= will be some sort of analysis document, instead of a specification. Maybe something like: =93A specification for = =91CDNI URI Signing=92. This document will specify a mechanism that allows interconnected CDNs to support control access control by signi= ng content URIs.=94
 
I see your concern. At the same time, I think it woudl be useful to c= larify the relationship of that specification with other CDNI interfaces ie= it is not about defining an additional interface, but instead may involve extensions to the other CDNI interfaces= (eg potentially additonal CDNI metadata, additional logging field).=
 
How about:
=93
A specification for =91CDNI URI Signing=92. This document will specif= y a mechanism that allows interconnected CDNs to support control access con= trol by signing content URIs. This may involve extensions to the CDNI interfaces (e.g. CDNI metadata interface, CDNI logg= ing interface).
 
 
Works for me.
 
 
 
=94 

-  &n= bsp;       <= font size=3D"3">The current milestone for URI Signing is Dec 2014. Looking at the maturity of = the only candidate draft for URI Signing that is currently out there, Sept = 2014 (or maybe even July) seems realistic to me, especially since the curre= nt candidate draft is a lot more mature than for example the current FCI proposals, which are also listed f= or Sept 2014.
 
Let's go for Sept 2014. Remember this target assumes the document has= been through a number of steps beyond "being ready" (eg WG Last = Call, Chair/AD review=85).
But by all means, feel free to beat the target ^). 
 
 
I=92ll give it a shot ;)
 

-  &n= bsp;       <= font size=3D"3">You might want to re-order the other milestones to line them up chronologicall= y.
 
Agreed.

-  &n= bsp;       N= ow that we=92re discussing the charter anyway, I noticed the final sentence =93The CDNI WG will also = coordinate with relevant groups outside the IETF such as UltraViolet=94 Is = this still relevant? Or should we take it out?
 
I'd agree to remove the explicit mention about Ultra-Violet. It may b= e worth keeping a placeholder to remember we may have to interact with some= external groups (for example we have received a liaison from the NGMN about their "Mobile Content Delivery= Optimization" work). So we could rephrase into:
"
The CDNI WG will also coordinate with relevant groups outside the IET= F, if and where appropriate.
"
 
Ok.
 

-  &n= bsp;       T= he same is true for =93The CDNI WG aims at delivering a targeted, deployable solution in a short time= frame (18-24 months) as needed by the industry=94. Now that we=92re updatin= g the dates, should we remove the =91(18-24 months)=92 from this line?
 
I'd agree to remove the =91(18-24 months)=92 from this line.
 
The other clean-up we may want to do is to update the interface names= to their final agreed names and add a few words to clarify that the "= request routing interface" actually comprises two component interfaces, to make it easier to understand why there are tw= o corresponding deliverables. If folks agree to that idea, we'll propose up= dated text for that too.
 
That sounds like something we should definitel= y do.
 
Thanks
 
Francois

 
Best regards,
 
Ray
 
 
= From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: maandag 26 augustus 2013 17:56
To: cd= ni@ietf.org
Subject: [CDNi] Draft CDNI charter update
 
Hello,
 
On 1 Aug 2013, at 19:12, Francois Le Faucheur (flefauch) <flefauch@cisco.com= > wrote:


Hi everyone,

We've reached a tentative agreement during today's session to add a "U= RI Signing" deliverable to the CDNI charter.
If you have comments or concerns about that, please express those on the li= st.
 
There has been no concerns expressed on the Berlin tentative agreemen= t to add a "URI Signing" deliverable to the CDNI charter; so= we will consider this as a WG decision.
 
Also, we need to update the target dates for existing Deliverables.
 
Below is a proposal to update the Charter accordingly, with addition = over the current charter showing up in red and changes showing up in blue. = Please review carefully and let us know if you have any comments on this proposal. 
 
 
Francois & Daryl
 
 
PROPOSED NEW CHARTER
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
"
Description of Working Group:
 
 
    A Content Delivery Network (CDN) is an infrastructure o= f network
    elements operating at layer 4 through layer 7, arranged= for the
    efficient distribution and delivery of digital content.= Such content
    includes, but is not limited to, web pages and images d= elivered via
    HTTP, and streaming of continuous media delivered via H= TTP, RTSP, RTMP,
    etc. CDNs typically provide services to multiple Conten= t Service
    Providers (CSPs).
 
    CDNs provide numerous benefits: a shared platform for m= ulti-service
    content delivery, reduced transmission costs for cachea= ble content,
    improved quality of experience for end users and increa= sed robustness of
    delivery. For these reasons they are frequently used fo= r large-scale
    content delivery.
 
    As a result of the significant growth in content delive= red over IP
    networks, existing CDN providers are scaling up their i= nfrastructure and
    many Network Service Providers and Enterprise Service P= roviders are
    deploying their own CDNs. Subject to the policy of the = CSP, it is
    generally desirable that a given item of content can be= delivered to an
    end user regardless of that end user's location or atta= chment network.
    This creates a need for interconnecting (previously) st= andalone CDNs so
    they can interoperate and collectively behave as a sing= le delivery
    infrastructure.
 
    The goal of the CDNI Working Group is to allow the inte= rconnection of
    separately administered CDNs in support of the end-to-e= nd delivery of
    content from CSPs through multiple CDNs and ultimately = to end users (via
    their respective User Agents). The CDNI WG aims at deli= vering a
    targeted, deployable solution in a short timeframe (18-= 24 months) as
    needed by the industry. It is expected that the CDNI in= terfaces will be
    realized using existing IETF protocols for transport an= d message
    exchange, and using existing object notation grammars/l= anguages for the
    definition of CDNI objects and semantics. In the event = that protocol
    extensions or new protocols are deemed necessary by the= WG, the WG will
    recharter.
 
    The working group will focus on the following items:
 
    - A "problem statement" document providing a = description of the problem
      and a common terminology.
 
    - A "use case" document describing scenarios = for usage and applications
      of the CDNI solution and protocols.
 
    - A "framework" document providing a descript= ion of the different
      components of the CDNI architecture and how they= interact with one
      another. This document will also include a "= ;threat analysis"
      discussing the security concerns and threats, th= e trust model and
      privacy issues specific to CDNI.
 
    - A "requirements" document. This document li= sts the requirements for
      the CDNI architecture and the CDNI interfaces. I= n particular, this
      document will focus on identifying a reasonable = set of more urgent and
      important requirements that will be addressed in= the initial set of
      CDNI protocols and solutions produced by the wor= king group. This
      document will list the requirements stemming fro= m the threat analysis
      and to be met by each of the CDNI interfaces.
 
    - A specification of the "CDNI request-routing int= erface". This
      interface will allow an upstream CDN request rou= ting system to obtain
      from the downstream CDN the information necessar= y to perform request
      redirection.
 
    - A specification of the "CDNI metadata interface&= quot;. This interface will
      allow the CDNs to exchange content distribution = metadata of inter-CDN
      scope. Content distribution metadata refers to t= he subset of content
      metadata that is relevant to the distribution of= the content and
      therefore is to be processed by CDNs (for exampl= e, this may include
      information enabling: content acquisition, geo-b= locking, enforcement
      of availability windows or access control).
 
    - A specification of the "CDNI logging interface&q= uot;. This interface will
      allow CDN logging systems to exchange logging in= formation associated
      with actions that are relevant across CDNs (such= as content
      distribution, content delivery and content routi= ng actions) for
      purposes of accounting, analytics, monitoring, e= tc.
 
    - A specification of the "CDNI control interface&q= uot;. In particular, this
      interface will allow an upstream CDN to remove o= r invalidate content
      in a downstream CDN.
 
    - A specification of "URI Signin= g for CDNI" allowing support of content access control across intercon= nected CDNs through signing of content URIs. In particular, this specification will identify how URI signing impacts (or does not impa= ct) each of the CDNI Interfaces.
 
    The WG will discuss and address the security, managemen= t and operational
    issues specific to CDNI, inside the above documents and= specifications.
 
    The working group will only define solutions for aspect= s of the CDN
    Interconnection problem space that require direct commu= nication or
    interoperation between CDNs.
 
    In particular, the WG will not define:
 
    - New session, transport or network protocols.
 
    - New protocols for delivering content from a CDN to an= End User/User
      Agent.
 
    - New protocols for ingestion of content or metadata be= tween a CSP and a
      CDN.
 
    - New protocols for acquiring content across CDNs.
 
    - Protocols and algorithms for intra-CDN operations.
 
    - Support for Transparent Caching across CDNs.
 
    - New applications consuming CDNI logs.
 
    - Digital Right Management (DRM) mechanisms.
 
    The CDNI WG will work with other IETF WGs to assess, an= d where
    appropriate, leverage protocols developed by those WGs,= in order to
    realize the CDNI requirements and CDNI interfaces. For = example, the WG
    may assess the suitability of the ALTO protocol as a pr= otocol to enable
    downstream CDNs to exchange information which may aid a= n upstream CDN
    with making CDNI request routing decisions. The CDNI WG= will also
    coordinate with relevant groups outside the IETF such a= s UltraViolet.
 
 
Goals and Milestones:
  Done     - Submit CDNI problem statement to IESG as = Informational
  Done     - Submit CDNI use cases to IESG as Informat= ional
  Dec 2013 - Submit CDN= I framework to IESG as Informational
  Sep 2013 - Submit CDN= I requirements to IESG as Informational
  April 2014 - Sub= mit specification of the CDNI Request Routing/Redirection interface to IESG= as Proposed Standard
  Dec 2013 - Submit spe= cification of the CDNI Logging interface to IESG as Proposed Standard
  April 2014 - Sub= mit specification of the CDNI Control interface to IESG as proposed Standar= d
  Dec 2013 - Submit spe= cification of the CDNI Metadata Distribution interface to IESG as Proposed = Standard
  Sep 2014 - Submi= t specification of the CDNI Request Routing/Footprint & Capabilities Ad= vertisement interface to IESG as Proposed Standard
  Dec 2014 - Submit specification of URI Signi= ng for CDNI to IESG as Proposed Standard
  Dec 2014 - Recharter = or dissolve
 
 
 
 

Cheers

Francois
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
 
This e-mail and its conte= nts are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

--_000_FC236DA6F2DA77449EF2D02DF4471A8D04B63DB2xmbrcdx10ciscoc_--