From Jan.Seedorf@neclab.eu Mon Mar 4 02:15:40 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 2052A21F8984; Mon, 4 Mar 2013 02:15:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.999 X-Spam-Level: X-Spam-Status: No, score=-100.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1g+xKLrYwuRX; Mon, 4 Mar 2013 02:15:39 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2FE2621F8976; Mon, 4 Mar 2013 02:15:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 97E72103516; Mon, 4 Mar 2013 11:15:20 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPqkB0kYpF-T; Mon, 4 Mar 2013 11:15:20 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7FC5C1034FE; Mon, 4 Mar 2013 11:15:10 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 4 Mar 2013 11:14:32 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: CDNI Footprint/Capabilities Side Meeting @IETF-86 Thread-Index: Ac4YwPQe14aF90GjQs+loeBh6aCtnA== Date: Mon, 4 Mar 2013 10:14:31 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55455F3A@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni-footprint@ietf.org" Subject: [CDNi] CDNI Footprint/Capabilities Side Meeting @IETF-86 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, 04 Mar 2013 10:15:40 -0000 I have set up a doodle, please try to fill in by Thursday this week, so tha= t we can decide the best slot and circulate the date/time on Friday. http://www.doodle.com/adfa9unigs9gxmr8 - Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Senior Researcher NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 jan.seedorf@neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End = Road, London, HA4 6QE, GB, Registered in England 2832014 From flefauch@cisco.com Mon Mar 4 02:37:30 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 26FA321F8939 for ; Mon, 4 Mar 2013 02:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 eXa33oe-rKaU for ; Mon, 4 Mar 2013 02:37:29 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 845FE21F8933 for ; Mon, 4 Mar 2013 02:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=251; q=dns/txt; s=iport; t=1362393449; x=1363603049; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=I9fQ8ajEDo0JqVoDC8rNxKwt6dhmLhNWOzbDpL9bwII=; b=D0qjRDGfAkryEuqTwcm+tp9LMKwK7yvSeZzFnmPUlTiSihWAPu1QIzJF oiEnqniU6YJNQJnek8CjKUMoQflHjaGF0z6zwfculnN2OwefBeZ9tX59T b2Txt4sQTzLhNVeJ0rjOGOMIEZubUosL1VU4nJ87pJjuGwXFiKCDpDo5U I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugJAMV3NFGtJXG+/2dsb2JhbABFhgm8PgQBfxZzgiEBBDpRASoUQicEGwGICgymW6AsjXhkgxdhA6cygwiCJw X-IronPort-AV: E=Sophos;i="4.84,778,1355097600"; d="scan'208";a="180367419" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 04 Mar 2013 10:37:29 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r24AbTv9032609 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Mar 2013 10:37:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 04:37:28 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI Draft Agenda available Thread-Index: AQHOGMRElQCg8ia5JEOSmCUv4SDrww== Date: Mon, 4 Mar 2013 10:37:28 +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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI Draft Agenda available X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 10:37:30 -0000 Folks, Draft agenda for the two CDNI WG sessions in Orlando has been uploaded at: http://www.ietf.org/proceedings/86/agenda/agenda-86-cdni Please let us know asap if you have comments or if we have omitted a slot. Cheers Francois & Rich From flefauch@cisco.com Mon Mar 4 02:38: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 39A1E21F8639 for ; Mon, 4 Mar 2013 02:38:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 3b9sPJ1an6lT for ; Mon, 4 Mar 2013 02:38:53 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B677721F858A for ; Mon, 4 Mar 2013 02:38:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=156; q=dns/txt; s=iport; t=1362393533; x=1363603133; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=UwdfokTx9dJZZ3840PWT07vZyPTdUHBhlOEVxGYJMc0=; b=bvmOHEj/7numvg9Tg5ZpDK29kujyI1GtGwAKTxgUY/ZENoxOxUgFiD8Y K2J0d943cdmJubQk5Nd+L7bweJ4j5N8klNlFyVNIjk76W2iMtA3U/hXWK DLOA32Fy2jLiUPUolmMQ1N1sylbbdZFUB8iJ+d+yVTdvC77L4IkhO2hhj 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EALF4NFGtJV2d/2dsb2JhbABFwkx/FnOCIQEEOlEBKhRCJwQbiAumZ6AsjlyDF2EDpzKDCIIn X-IronPort-AV: E=Sophos;i="4.84,778,1355097600"; d="scan'208";a="183358687" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 04 Mar 2013 10:38:53 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r24AcrUt024632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Mar 2013 10:38:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 04:38:53 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI slides for your presentations Thread-Index: AQHOGMR2AdcKYlHBSEaODv6/Sc/Obw== Date: Mon, 4 Mar 2013 10:38:52 +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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI slides for your presentations X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 10:38:54 -0000 To all CDNI presenters in Orlando, Please send Rich and I your draft slidedeck asap and no later than Sunday 1= 0 March. Cheers Francois & Rich= From ben@niven-jenkins.co.uk Tue Mar 5 00:21:14 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 9C75221F8896 for ; Tue, 5 Mar 2013 00:21:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 h5f3t5OyHEnO for ; Tue, 5 Mar 2013 00:21:14 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id CC0BF21F88A2 for ; Tue, 5 Mar 2013 00:21:11 -0800 (PST) Received: from dab-ell2-h-65-3.dab.02.net ([82.132.245.119] helo=[10.47.142.82]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UCn7W-0000aY-MJ for cdni@ietf.org; Tue, 05 Mar 2013 08:21:11 +0000 From: Ben Niven-Jenkins Content-Type: multipart/alternative; boundary=Apple-Mail-09B89F46-5001-4F7E-9F5A-5D9545C73EB7 X-Mailer: iPhone Mail (10B146) Message-Id: <7CDC3544-B21D-45A3-BB9A-CC7EDBA62E32@niven-jenkins.co.uk> Date: Tue, 5 Mar 2013 08:21:02 +0000 To: "cdni@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Subject: [CDNi] draft-choi-cdni-control-bootstrapping 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, 05 Mar 2013 08:21:14 -0000 --Apple-Mail-09B89F46-5001-4F7E-9F5A-5D9545C73EB7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is draft-choi-cdni-control-bootstrapping available somewhere as http://datatracker.ietf.org/doc/draft-choi-cdni-control-bootstrapping/ Returns a 404? Thanks Ben --Apple-Mail-09B89F46-5001-4F7E-9F5A-5D9545C73EB7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is draft-choi-cdni-c= ontrol-bootstrapping available somewhere as

=
=
Returns a 404?

Thanks
Ben= --Apple-Mail-09B89F46-5001-4F7E-9F5A-5D9545C73EB7-- From flefauch@cisco.com Tue Mar 5 00:44: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 9A9BD21F86CA for ; Tue, 5 Mar 2013 00:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.606 X-Spam-Level: X-Spam-Status: No, score=-9.606 tagged_above=-999 required=5 tests=[AWL=-0.761, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 8lq6-f6iap27 for ; Tue, 5 Mar 2013 00:44:37 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 85B5821F86C2 for ; Tue, 5 Mar 2013 00:44:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5364; q=dns/txt; s=iport; t=1362473077; x=1363682677; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4NexN8MeZvFp4BeIPfKJG1Xok7t+IAsiN29eN/mEhGM=; b=LXSZgpjslRAEqP1EgcCRA03vEiMdQ3cwnVGEXUP04SYIwPKKWmgAMRSA Kzx/SNNUN3/C3jFHAJSO4uLncEFwI/wYs4WvZDutc3ZiRl0HK7K4F+n1p NksaWHXmcMQXl5rRkju4dzDPts23jqRvhQbZtUCzBp6c0Mc0bi9vVh5UJ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmkFADWwNVGtJV2d/2dsb2JhbABEgkOuQokmAYgoDXYWc4IgAQEEAQEBawsQAgEIIh0HAiULFBECBA4FCIgLDK4skDaOWzEHgl9hA5doj1CDCIIn X-IronPort-AV: E=Sophos;i="4.84,786,1355097600"; d="scan'208,217";a="183820317" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 05 Mar 2013 08:44:24 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r258iN1i031719 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 08:44:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 5 Mar 2013 02:44:23 -0600 From: "Francois Le Faucheur (flefauch)" To: Ben Niven-Jenkins Thread-Topic: [CDNi] draft-choi-cdni-control-bootstrapping Thread-Index: AQHOGXpqaZ73M+/vuUiuYZt97BdMOpiXLOWA Date: Tue, 5 Mar 2013 08:44:23 +0000 Message-ID: References: <7CDC3544-B21D-45A3-BB9A-CC7EDBA62E32@niven-jenkins.co.uk> In-Reply-To: <7CDC3544-B21D-45A3-BB9A-CC7EDBA62E32@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.195] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D38E4D6xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-choi-cdni-control-bootstrapping 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, 05 Mar 2013 08:44:38 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D38E4D6xmbrcdx10ciscocom_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkgQmVuLA0KVGFlc2FuZyBpcyBhYm91dCB0byBtYWtlIGl0IGF2YWlsYWJsZSBmcm9tIGEgbm9u LUlFVEYgc2l0ZSAod2hpY2ggd2lsbCBiZSBhZHZlcnRpc2VkIG9uIHRoaXMgbGlzdCkgYW5kIHdp bGwgcG9zdCBpdCBvbiB0aGUgSUVURiBzaXRlIGFzIHNvb24gYXMgdXBsb2FkIHJlb3BlbnMuDQpD aGVlcnMNCkZyYW5jb2lzDQoNCk9uIDUgTWFyIDIwMTMsIGF0IDA5OjIxLCBCZW4gTml2ZW4tSmVu a2lucyA8YmVuQG5pdmVuLWplbmtpbnMuY28udWs8bWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNv LnVrPj4NCiB3cm90ZToNCg0KSXMgZHJhZnQtY2hvaS1jZG5pLWNvbnRyb2wtYm9vdHN0cmFwcGlu ZyBhdmFpbGFibGUgc29tZXdoZXJlIGFzDQoNCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtY2hvaS1jZG5pLWNvbnRyb2wtYm9vdHN0cmFwcGluZy8NCg0KUmV0dXJucyBhIDQw ND8NCg0KVGhhbmtzDQpCZW4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpDRE5pIG1haWxpbmcgbGlzdA0KQ0ROaUBpZXRmLm9yZzxtYWlsdG86Q0ROaUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0KDQo= --_000_FC236DA6F2DA77449EF2D02DF4471A8D38E4D6xmbrcdx10ciscocom_ Content-Type: text/html; charset="ks_c_5601-1987" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Ben,
Taesang is about to make it available from a non-IETF site (which will= be advertised on this list) and will post it on the IETF site as soon as u= pload reopens.
Cheers
Francois

On 5 Mar 2013, at 09:21, Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
 wrote:

Is draft-choi-cdni-control-boo= tstrapping available somewhere as


Returns a 404?

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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D38E4D6xmbrcdx10ciscocom_-- From flefauch@cisco.com Wed Mar 6 00:48: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 A2EF621F869A for ; Wed, 6 Mar 2013 00:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.127 X-Spam-Level: X-Spam-Status: No, score=-8.127 tagged_above=-999 required=5 tests=[AWL=-1.732, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 hkFDf2LC40lD for ; Wed, 6 Mar 2013 00:48:24 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id CA41121F866F for ; Wed, 6 Mar 2013 00:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15261; q=dns/txt; s=iport; t=1362559703; x=1363769303; h=from:to:subject:date:message-id:references:mime-version; bh=kHozBmrdBR1ZEmkmoiyRGiLE7Zts8O6f9AFlfJJZD40=; b=VTz+2ge7hFNk6yEjz7BxO7HtuIcFelp6E6O9uFrMg/V6dtWunQOfjgpt g7e99niHQaEUuLEm7i8rvSKQ6L6Qcz04lzZL+byLwur6CKqpr/jCR6fcg lyYScbic4IqtViUsEQ9vYvLNc4kCa/cxtUMT8MZSBTY7TYPk/CBcX9tXl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAOYBN1GtJV2Y/2dsb2JhbABEFoQ8rmaJJgGIJXR3FnOCKgEBAQQBAQFrGwIBBhMDAQEBCx0HAiULFAcCCAIEEwiICwyOBK1fjlwWCgYHCgeCWWEDl2iKOoUWgwiCJw X-IronPort-AV: E=Sophos;i="4.84,793,1355097600"; d="scan'208,217";a="181297923" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 06 Mar 2013 08:48:23 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r268mNvr021670 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Mar 2013 08:48:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 02:48:22 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] draft-choi-cdni-control-bootstrapping Thread-Index: AQHOGXpqaZ73M+/vuUiuYZt97BdMOg== Date: Wed, 6 Mar 2013 08:48:22 +0000 Message-ID: References: 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: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D390D68xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] Fwd: draft-choi-cdni-control-bootstrapping 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, 06 Mar 2013 08:48:25 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D390D68xmbrcdx10ciscocom_ Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SnVzdCBmb3J3YXJkaW5nIFRhZXNhbmcncyBtZXNzYWdlIHRvIHRoZSBsaXN0IG9uIGhpcyBiZWhh bGYuDQpGcmFuY29pcw0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogw9bFwrvz IDxjaG9pdHNAZXRyaS5yZS5rcjxtYWlsdG86Y2hvaXRzQGV0cmkucmUua3I+Pg0KU3ViamVjdDog UkU6IFtDRE5pXSBkcmFmdC1jaG9pLWNkbmktY29udHJvbC1ib290c3RyYXBwaW5nDQpEYXRlOiA1 IE1hcmNoIDIwMTMgMTU6MTk6NTAgQ0VUDQpUbzogIkZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVm YXVjaCkiIDxmbGVmYXVjaEBjaXNjby5jb208bWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbT4+LCBC ZW4gTml2ZW4tSmVua2lucyA8YmVuQG5pdmVuLWplbmtpbnMuY28udWs8bWFpbHRvOmJlbkBuaXZl bi1qZW5raW5zLmNvLnVrPj4NCkNjOiAiY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9y Zz4iIDxjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPj4sICJjZG5pLmthaXN0QGth aXN0LmFjLmtyPG1haWx0bzpjZG5pLmthaXN0QGthaXN0LmFjLmtyPiIgPGNkbmkua2Fpc3RAa2Fp c3QuYWMua3I8bWFpbHRvOmNkbmkua2Fpc3RAa2Fpc3QuYWMua3I+Pg0KDQpIaSBCZW4sIEZyYW5j b2lzLCBhbmQgQ0ROaSBXRyBjb2xsZWFndWVzLA0KDQpIZXJlIGlzIGEgcHJpdmF0ZSBsaW5rIHRv IG91ciBpbml0aWFsIGRyYWZ0LCChsGRyYWZ0LWNob2ktY2RuaS1jb250cm9sLWluaXQtYm9vdHN0 cmFwcGluZy0wMKGxLg0KaHR0cDovL2NhbmUua2Fpc3QuYWMua3IvfnBlaGEvZHJhZnQtY2hvaS1j ZG5pLWNvbnRyb2wtaW5pdC1ib290c3RyYXBwaW5nLTAwLnR4dA0KSSB3aWxsIGFsc28gdXBsb2Fk IGl0IGluIHRoZSBvZmZpY2lhbCBJRVRGIHNpdGUgYXMgc29vbiBhcyBpdCByZW9wZW5zLiAgQW55 IGNvbW1lbnRzIG9yIHN1Z2dlc3Rpb25zIGFyZSBhcHByZWNpYXRlZC4NCg0KQmVzdCByZWdhcmRz LA0KVGFlc2FuZw0KRVRSSQ0KDQoNCkZyb206IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVj aCkgW21haWx0bzpmbGVmYXVjaEBjaXNjby5jb208aHR0cDovL2Npc2NvLmNvbT5dDQpTZW50OiBU dWVzZGF5LCBNYXJjaCAwNSwgMjAxMyA1OjQ0IFBNDQpUbzogQmVuIE5pdmVuLUplbmtpbnMNCkNj OiBjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPjsgw9bFwrvzDQpTdWJqZWN0OiBS ZTogW0NETmldIGRyYWZ0LWNob2ktY2RuaS1jb250cm9sLWJvb3RzdHJhcHBpbmcNCg0KSGkgQmVu LA0KVGFlc2FuZyBpcyBhYm91dCB0byBtYWtlIGl0IGF2YWlsYWJsZSBmcm9tIGEgbm9uLUlFVEYg c2l0ZSAod2hpY2ggd2lsbCBiZSBhZHZlcnRpc2VkIG9uIHRoaXMgbGlzdCkgYW5kIHdpbGwgcG9z dCBpdCBvbiB0aGUgSUVURiBzaXRlIGFzIHNvb24gYXMgdXBsb2FkIHJlb3BlbnMuDQpDaGVlcnMN CkZyYW5jb2lzDQoNCk9uIDUgTWFyIDIwMTMsIGF0IDA5OjIxLCBCZW4gTml2ZW4tSmVua2lucyA8 YmVuQG5pdmVuLWplbmtpbnMuY28udWs8bWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPj4N CiB3cm90ZToNCg0KDQpJcyBkcmFmdC1jaG9pLWNkbmktY29udHJvbC1ib290c3RyYXBwaW5nIGF2 YWlsYWJsZSBzb21ld2hlcmUgYXMNCg0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWNob2ktY2RuaS1jb250cm9sLWJvb3RzdHJhcHBpbmcvDQoNCg0KUmV0dXJucyBhIDQw ND8NCg0KDQpUaGFua3MNCkJlbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYub3JnPG1haWx0bzpDRE5p QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQoN Cg== --_000_FC236DA6F2DA77449EF2D02DF4471A8D390D68xmbrcdx10ciscocom_ Content-Type: text/html; charset="ks_c_5601-1987" Content-ID: <6EE61F039EE3DD4882DA425F2AF04F96@cisco.com> Content-Transfer-Encoding: quoted-printable Just forwarding Taesang's message to the list on his behalf.
Francois

Begin forwarded message:

From: =C3= =D6=C5=C2=BB=F3 <choits@etri.re.kr<= /a>>
Subject: RE= : [CDNi] draft-choi-cdni-control-bootstrapping
Date: 5 Mar= ch 2013 15:19:50 CET
Hi Ben, Francois, an= d CDNi WG colleagues,
 
Here is a private link to our initial draft, =A1=B0= draft-choi-cdni-control-init-bootstrapping-00=A1=B1.
http://cane.kaist.ac.kr/~peha/draft-choi-cdni-control-init= -bootstrapping-00.txt<= /div>
I will also upload it in the official IETF site as = soon as it reopens.  Any comments or suggestions are appreciated. &nbs= p;
 
Best regards,
Taesang
ETRI<= /div>
 
 
From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco= .com] 
Sent: Tuesday, Mar= ch 05, 2013 5:44 PM
To: Ben Niven-Jenk= ins
Cc: cdni@ietf.org;=  =C3=D6=C5=C2=BB=F3
Subject: Re: [CDNi= ] draft-choi-cdni-control-bootstrapping
 
Hi Ben,
Taesang is about to make it available fro= m a non-IETF site (which will be advertised on this list) and will post it = on the IETF site as soon as upload reopens.
Cheers
Francois
 
On 5 Mar 2013, at 09:21, Ben Niven-Jenkin= s <ben@niven-jenkins.co.uk>
 wrote:


Is draft-choi= -cdni-control-bootstrapping available somewhere as




Returns a 404?


Thanks<= /span>
Ben
_________________________________________= ______
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdn= i


--_000_FC236DA6F2DA77449EF2D02DF4471A8D390D68xmbrcdx10ciscocom_-- From richard_woundy@cable.comcast.com Wed Mar 6 10:28:45 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 0AA8E21F8A85 for ; Wed, 6 Mar 2013 10:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.129 X-Spam-Level: X-Spam-Status: No, score=-103.129 tagged_above=-999 required=5 tests=[AWL=-2.102, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, 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 MI-8Rx2Cq7ok for ; Wed, 6 Mar 2013 10:28:40 -0800 (PST) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 5968121F8ABC for ; Wed, 6 Mar 2013 10:28:37 -0800 (PST) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.59545790; Wed, 06 Mar 2013 10:57:25 -0700 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.218]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Wed, 6 Mar 2013 13:28:26 -0500 From: "Woundy, Richard" To: "cdni@ietf.org" Thread-Topic: [CDNi] Fwd: draft-choi-cdni-control-bootstrapping Thread-Index: AQHOGXpqaZ73M+/vuUiuYZt97BdMOpiY/dEA Date: Wed, 6 Mar 2013 18:28:26 +0000 Message-ID: <1CA25301D2219F40B3AA37201F0EACD1480130C7@PACDCEXMB01.cable.comcast.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [24.40.56.165] Content-Type: multipart/alternative; boundary="_000_1CA25301D2219F40B3AA37201F0EACD1480130C7PACDCEXMB01cabl_" MIME-Version: 1.0 Subject: Re: [CDNi] Fwd: draft-choi-cdni-control-bootstrapping 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, 06 Mar 2013 18:28:45 -0000 --_000_1CA25301D2219F40B3AA37201F0EACD1480130C7PACDCEXMB01cabl_ Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 SSB1cGRhdGVkIHRoZSBhZ2VuZGEgd2l0aCBhIHBvaW50ZXIgdG8gdGhpcyB0ZW1wb3JhcnkgY29w eSBvZiB0aGUgZHJhZnQsIGFzIHdlbGwgYXMgd2l0aCB0aGUgY29ycmVjdGVkIFdlYkV4IHNlc3Np b24gZm9yIFRodXJzZGF5Lg0KDQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzg2L2Fn ZW5kYS9hZ2VuZGEtODYtY2RuaQ0KDQpGcm9tOiBGcmFuY29pcyBMZSBGYXVjaGV1ciA8ZmxlZmF1 Y2hAY2lzY28uY29tPG1haWx0bzpmbGVmYXVjaEBjaXNjby5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5 LCBNYXJjaCA2LCAyMDEzIDM6NDggQU0NClRvOiAiY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBp ZXRmLm9yZz4iIDxjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPj4NClN1YmplY3Q6 IFtDRE5pXSBGd2Q6IGRyYWZ0LWNob2ktY2RuaS1jb250cm9sLWJvb3RzdHJhcHBpbmcNCg0KSnVz dCBmb3J3YXJkaW5nIFRhZXNhbmcncyBtZXNzYWdlIHRvIHRoZSBsaXN0IG9uIGhpcyBiZWhhbGYu DQpGcmFuY29pcw0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogw9bFwrvzIDxj aG9pdHNAZXRyaS5yZS5rcjxtYWlsdG86Y2hvaXRzQGV0cmkucmUua3I+Pg0KU3ViamVjdDogUkU6 IFtDRE5pXSBkcmFmdC1jaG9pLWNkbmktY29udHJvbC1ib290c3RyYXBwaW5nDQpEYXRlOiA1IE1h cmNoIDIwMTMgMTU6MTk6NTAgQ0VUDQpUbzogIkZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVj aCkiIDxmbGVmYXVjaEBjaXNjby5jb208bWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbT4+LCBCZW4g Tml2ZW4tSmVua2lucyA8YmVuQG5pdmVuLWplbmtpbnMuY28udWs8bWFpbHRvOmJlbkBuaXZlbi1q ZW5raW5zLmNvLnVrPj4NCkNjOiAiY2RuaUBpZXRmLm9yZzxtYWlsdG86Y2RuaUBpZXRmLm9yZz4i IDxjZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPj4sICJjZG5pLmthaXN0QGthaXN0 LmFjLmtyPG1haWx0bzpjZG5pLmthaXN0QGthaXN0LmFjLmtyPiIgPGNkbmkua2Fpc3RAa2Fpc3Qu YWMua3I8bWFpbHRvOmNkbmkua2Fpc3RAa2Fpc3QuYWMua3I+Pg0KDQpIaSBCZW4sIEZyYW5jb2lz LCBhbmQgQ0ROaSBXRyBjb2xsZWFndWVzLA0KDQpIZXJlIGlzIGEgcHJpdmF0ZSBsaW5rIHRvIG91 ciBpbml0aWFsIGRyYWZ0LCChsGRyYWZ0LWNob2ktY2RuaS1jb250cm9sLWluaXQtYm9vdHN0cmFw cGluZy0wMKGxLg0KaHR0cDovL2NhbmUua2Fpc3QuYWMua3IvfnBlaGEvZHJhZnQtY2hvaS1jZG5p LWNvbnRyb2wtaW5pdC1ib290c3RyYXBwaW5nLTAwLnR4dA0KSSB3aWxsIGFsc28gdXBsb2FkIGl0 IGluIHRoZSBvZmZpY2lhbCBJRVRGIHNpdGUgYXMgc29vbiBhcyBpdCByZW9wZW5zLiAgQW55IGNv bW1lbnRzIG9yIHN1Z2dlc3Rpb25zIGFyZSBhcHByZWNpYXRlZC4NCg0KQmVzdCByZWdhcmRzLA0K VGFlc2FuZw0KRVRSSQ0KDQoNCkZyb206IEZyYW5jb2lzIExlIEZhdWNoZXVyIChmbGVmYXVjaCkg W21haWx0bzpmbGVmYXVjaEBjaXNjby5jb208aHR0cDovL2Npc2NvLmNvbT5dDQpTZW50OiBUdWVz ZGF5LCBNYXJjaCAwNSwgMjAxMyA1OjQ0IFBNDQpUbzogQmVuIE5pdmVuLUplbmtpbnMNCkNjOiBj ZG5pQGlldGYub3JnPG1haWx0bzpjZG5pQGlldGYub3JnPjsgw9bFwrvzDQpTdWJqZWN0OiBSZTog W0NETmldIGRyYWZ0LWNob2ktY2RuaS1jb250cm9sLWJvb3RzdHJhcHBpbmcNCg0KSGkgQmVuLA0K VGFlc2FuZyBpcyBhYm91dCB0byBtYWtlIGl0IGF2YWlsYWJsZSBmcm9tIGEgbm9uLUlFVEYgc2l0 ZSAod2hpY2ggd2lsbCBiZSBhZHZlcnRpc2VkIG9uIHRoaXMgbGlzdCkgYW5kIHdpbGwgcG9zdCBp dCBvbiB0aGUgSUVURiBzaXRlIGFzIHNvb24gYXMgdXBsb2FkIHJlb3BlbnMuDQpDaGVlcnMNCkZy YW5jb2lzDQoNCk9uIDUgTWFyIDIwMTMsIGF0IDA5OjIxLCBCZW4gTml2ZW4tSmVua2lucyA8YmVu QG5pdmVuLWplbmtpbnMuY28udWs8bWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPj4NCiB3 cm90ZToNCg0KDQpJcyBkcmFmdC1jaG9pLWNkbmktY29udHJvbC1ib290c3RyYXBwaW5nIGF2YWls YWJsZSBzb21ld2hlcmUgYXMNCg0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWNob2ktY2RuaS1jb250cm9sLWJvb3RzdHJhcHBpbmcvDQoNCg0KUmV0dXJucyBhIDQwND8N Cg0KDQpUaGFua3MNCkJlbg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCkNETmkgbWFpbGluZyBsaXN0DQpDRE5pQGlldGYub3JnPG1haWx0bzpDRE5pQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQoNCg== --_000_1CA25301D2219F40B3AA37201F0EACD1480130C7PACDCEXMB01cabl_ Content-Type: text/html; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PWV1Yy1rciI+DQo8L2hlYWQ+DQo8Ym9keSBzdHlsZT0id29yZC13 cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1i cmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTog MTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+DQo8ZGl2PkkgdXBkYXRl ZCB0aGUgYWdlbmRhIHdpdGggYSBwb2ludGVyIHRvIHRoaXMgdGVtcG9yYXJ5IGNvcHkgb2YgdGhl IGRyYWZ0LCBhcyB3ZWxsIGFzIHdpdGggdGhlIGNvcnJlY3RlZCBXZWJFeCBzZXNzaW9uIGZvciBU aHVyc2RheS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pmh0dHA6Ly93d3cuaWV0Zi5v cmcvcHJvY2VlZGluZ3MvODYvYWdlbmRhL2FnZW5kYS04Ni1jZG5pPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9y OmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdI VDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRp dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s ZCI+RnJvbTogPC9zcGFuPkZyYW5jb2lzIExlIEZhdWNoZXVyICZsdDs8YSBocmVmPSJtYWlsdG86 ZmxlZmF1Y2hAY2lzY28uY29tIj5mbGVmYXVjaEBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBNYXJjaCA2 LCAyMDEzIDM6NDggQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwv c3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwv YT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3Jn PC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9z cGFuPltDRE5pXSBGd2Q6IGRyYWZ0LWNob2ktY2RuaS1jb250cm9sLWJvb3RzdHJhcHBpbmc8YnI+ DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PjxiYXNlIGhyZWY9IngtbXNnOi8vNzY3 LyI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgIj4NCkp1c3Qg Zm9yd2FyZGluZyBUYWVzYW5nJ3MgbWVzc2FnZSB0byB0aGUgbGlzdCBvbiBoaXMgYmVoYWxmLg0K PGRpdj5GcmFuY29pczxicj4NCjxkaXY+PGJyPg0KPGRpdj5CZWdpbiBmb3J3YXJkZWQgbWVzc2Fn ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJp Z2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OidIZWx2ZXRpY2EnOyBmb250LXNpemU6bWVkaXVtOyBjb2xvcjpy Z2JhKDAsIDAsIDAsIDEuMCk7Ij48Yj5Gcm9tOg0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6J0hlbHZldGljYSc7IGZvbnQtc2l6ZTptZWRpdW07Ij7D1sXCu/MgJmx0OzxhIGhy ZWY9Im1haWx0bzpjaG9pdHNAZXRyaS5yZS5rciI+Y2hvaXRzQGV0cmkucmUua3I8L2E+Jmd0Ozxi cj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLXJp Z2h0OiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLWxlZnQ6IDBweDsiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OidIZWx2ZXRpY2EnOyBmb250LXNpemU6bWVkaXVtOyBjb2xvcjpy Z2JhKDAsIDAsIDAsIDEuMCk7Ij48Yj5TdWJqZWN0Og0KPC9iPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6J0hlbHZldGljYSc7IGZvbnQtc2l6ZTptZWRpdW07Ij48Yj5SRTogW0NETmld IGRyYWZ0LWNob2ktY2RuaS1jb250cm9sLWJvb3RzdHJhcHBpbmc8L2I+PGJyPg0KPC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFy Z2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMHB4OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6J0hlbHZldGljYSc7IGZvbnQtc2l6ZTptZWRpdW07IGNvbG9yOnJnYmEoMCwgMCwgMCwg MS4wKTsiPjxiPkRhdGU6DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTonSGVs dmV0aWNhJzsgZm9udC1zaXplOm1lZGl1bTsiPjUgTWFyY2ggMjAxMyAxNToxOTo1MCBDRVQ8YnI+ DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1yaWdo dDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IG1hcmdpbi1sZWZ0OiAwcHg7Ij4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTonSGVsdmV0aWNhJzsgZm9udC1zaXplOm1lZGl1bTsgY29sb3I6cmdi YSgwLCAwLCAwLCAxLjApOyI+PGI+VG86DQo8L2I+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTonSGVsdmV0aWNhJzsgZm9udC1zaXplOm1lZGl1bTsiPiZxdW90O0ZyYW5jb2lzIExlIEZh dWNoZXVyIChmbGVmYXVjaCkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpmbGVmYXVjaEBjaXNj by5jb20iPmZsZWZhdWNoQGNpc2NvLmNvbTwvYT4mZ3Q7LCBCZW4gTml2ZW4tSmVua2lucyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrIj5iZW5Abml2ZW4tamVua2lu cy5jby51azwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLXRv cDogMHB4OyBtYXJnaW4tcmlnaHQ6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBtYXJnaW4tbGVm dDogMHB4OyI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J0hlbHZldGljYSc7IGZvbnQtc2l6 ZTptZWRpdW07IGNvbG9yOnJnYmEoMCwgMCwgMCwgMS4wKTsiPjxiPkNjOg0KPC9iPjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6J0hlbHZldGljYSc7IGZvbnQtc2l6ZTptZWRpdW07Ij4m cXVvdDs8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT4mcXVv dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpjZG5pQGlldGYub3JnIj5jZG5pQGlldGYub3JnPC9hPiZn dDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpjZG5pLmthaXN0QGthaXN0LmFjLmtyIj5jZG5pLmth aXN0QGthaXN0LmFjLmtyPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNkbmkua2Fpc3RA a2Fpc3QuYWMua3IiPmNkbmkua2Fpc3RAa2Fpc3QuYWMua3I8L2E+Jmd0Ozxicj4NCjwvc3Bhbj48 L2Rpdj4NCjxicj4NCjxkaXYgbGFuZz0iS08iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IG1lZGl1bTsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogMjsgdGV4 dC1hbGlnbjogLXdlYmtpdC1hdXRvOyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiAyOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7ICI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2Vj dGlvbjE7ICI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ILG8uLI7ICI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJ7i8 wLogsO218Sc7ICI+SGkgQmVuLCBGcmFuY29pcywgYW5kIENETmkgV0cgY29sbGVhZ3Vlcyw8bzpw PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogsby4sjsgIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQt ZmFtaWx5OiAnuLzAuiCw7bXxJzsgIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdD b3VyaWVyIE5ldyc7ICI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyBmb250LWZhbWlseTogJ7i8wLogsO218Sc7ICI+SGVyZSBpcyBhIHByaXZhdGUg bGluayB0byBvdXIgaW5pdGlhbCBkcmFmdCwgobBkcmFmdC1jaG9pLWNkbmktY29udHJvbC1pbml0 LWJvb3RzdHJhcHBpbmctMDChsS48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog J0NvdXJpZXIgTmV3JzsgIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwOi8vY2Fu ZS5rYWlzdC5hYy5rci9+cGVoYS9kcmFmdC1jaG9pLWNkbmktY29udHJvbC1pbml0LWJvb3RzdHJh cHBpbmctMDAudHh0IiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7ICI+aHR0cDovL2NhbmUua2Fpc3QuYWMua3IvfnBlaGEvZHJhZnQtY2hvaS1jZG5pLWNv bnRyb2wtaW5pdC1ib290c3RyYXBwaW5nLTAwLnR4dDwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICe4vMC6ILDt tfEnOyAiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcn OyAiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Zm9udC1mYW1pbHk6ICe4vMC6ILDttfEnOyAiPkkgd2lsbCBhbHNvIHVwbG9hZCBpdCBpbiB0aGUg b2ZmaWNpYWwgSUVURiBzaXRlIGFzIHNvb24gYXMgaXQgcmVvcGVucy4mbmJzcDsgQW55IGNvbW1l bnRzIG9yIHN1Z2dlc3Rpb25zIGFyZSBhcHByZWNpYXRlZC4gJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJ7i8wLogsO21 8Sc7ICI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyAiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1m YW1pbHk6ICe4vMC6ILDttfEnOyAiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0 OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsgIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAnuLzAuiCw7bXxJzsgIj5U YWVzYW5nPG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7 ICI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBm b250LWZhbWlseTogJ7i8wLogsO218Sc7ICI+RVRSSTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ILG8uLI7ICI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBm b250LWZhbWlseTogJ7i8wLogsO218Sc7ICI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiCxvLiyOyAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICe4vMC6ILDttfEnOyAiPiZuYnNwOzwv c3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUg bm9uZTsgYm9yZGVyLXRvcC13aWR0aDogMXB0OyBib3JkZXItdG9wLWNvbG9yOiByZ2IoMTgxLCAx OTYsIDIyMyk7IHBhZGRpbmc6IDNwdCAwY20gMGNtOyAiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiCxvLiyOyAiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTog VGFob21hLCBzYW5zLXNlcmlmOyAiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsg Ij48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJhbmNv aXMNCiBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpIFs8YSBocmVmPSJtYWlsdG86ZmxlZmF1Y2hAIj5t YWlsdG86ZmxlZmF1Y2hAPC9hPjxhIGhyZWY9Imh0dHA6Ly9jaXNjby5jb20iPmNpc2NvLmNvbTwv YT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N CjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5UdWVzZGF5LCBNYXJjaCAwNSwgMjAxMyA1OjQ0IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5CZW4gTml2ZW4tSmVu a2luczxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5vcmciPmNkbmlAaWV0Zi5vcmc8 L2E+OzxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgIj7D1sXCu/M8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNh bnMtc2VyaWY7ICI+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbQ0ROaV0gZHJhZnQtY2hvaS1jZG5pLWNvbnRy b2wtYm9vdHN0cmFwcGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogsby4sjsgIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiCxvLiyOyAiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBCZW4sPG86cD48L286 cD48L3NwYW4+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiCxvLiyOyAiPjxzcGFuIGxhbmc9IkVO LVVTIj5UYWVzYW5nIGlzIGFib3V0IHRvIG1ha2UgaXQgYXZhaWxhYmxlIGZyb20gYSBub24tSUVU RiBzaXRlICh3aGljaCB3aWxsIGJlIGFkdmVydGlzZWQgb24gdGhpcyBsaXN0KSBhbmQgd2lsbCBw b3N0IGl0IG9uIHRoZSBJRVRGIHNpdGUgYXMgc29vbiBhcyB1cGxvYWQgcmVvcGVucy48bzpwPjwv bzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogsby4sjsgIj48c3Bh biBsYW5nPSJFTi1VUyI+Q2hlZXJzPG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ILG8uLI7ICI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyYW5jb2lzPG86cD48 L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ILG8uLI7ICI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiCxvLiyOyAiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiA1IE1hciAyMDEzLCBhdCAwOToyMSwg QmVuIE5pdmVuLUplbmtpbnMgJmx0OzxhIGhyZWY9Im1haWx0bzpiZW5Abml2ZW4tamVua2lucy5j by51ayIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyAi PmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrPC9hPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogsby4sjsgIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogsby4 sjsgIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9k aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiCxvLiyOyAiPjxzcGFuIGxhbmc9IkVOLVVTIj5JcyZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTEuNXB0OyBmb250 LWZhbWlseTogJy5IZWx2ZXRpY2FOZXVlVUknLCBzZXJpZjsgIj5kcmFmdC1jaG9pLWNkbmktY29u dHJvbC1ib290c3RyYXBwaW5nIGF2YWlsYWJsZSBzb21ld2hlcmUgYXM8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogsby4 sjsgIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTEuNXB0OyBmb250LWZh bWlseTogJy5IZWx2ZXRpY2FOZXVlVUknLCBzZXJpZjsgIj48YnI+DQo8YnI+DQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiCxvLiyOyAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAx MS41cHQ7IGZvbnQtZmFtaWx5OiAnLkhlbHZldGljYU5ldWVVSScsIHNlcmlmOyAiPjxhIGhyZWY9 Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY2hvaS1jZG5pLWNvbnRyb2wt Ym9vdHN0cmFwcGluZy8iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVu ZGVybGluZTsgIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNob2ktY2Ru aS1jb250cm9sLWJvb3RzdHJhcHBpbmcvPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ILG8uLI7ICI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDExLjVwdDsgZm9udC1mYW1pbHk6 ICcuSGVsdmV0aWNhTmV1ZVVJJywgc2VyaWY7ICI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogsby4sjsgIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTEuNXB0 OyBmb250LWZhbWlseTogJy5IZWx2ZXRpY2FOZXVlVUknLCBzZXJpZjsgIj5SZXR1cm5zIGEgNDA0 Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ILG8uLI7ICI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6IDExLjVwdDsgZm9udC1mYW1pbHk6ICcuSGVsdmV0aWNhTmV1ZVVJJywgc2VyaWY7 ICI+PGJyPg0KPGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogsby4sjsgIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTEuNXB0OyBmb250LWZhbWlseTogJy5IZWx2ZXRpY2FO ZXVlVUknLCBzZXJpZjsgIj5UaGFua3M8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiCxvLiyOyAiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMS41cHQ7IGZvbnQtZmFtaWx5OiAnLkhl bHZldGljYU5ldWVVSScsIHNlcmlmOyAiPkJlbjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiCxvLiyOyAi PjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4NCkNETmkgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkNE TmlAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsgIj5DRE5pQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2RuaSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lOyAiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vY2RuaTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogsby4sjsgIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1CA25301D2219F40B3AA37201F0EACD1480130C7PACDCEXMB01cabl_-- From kleung@cisco.com Wed Mar 6 15:08:35 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 221D511E80ED for ; Wed, 6 Mar 2013 15:08:35 -0800 (PST) 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 g6LGivLNcM7a for ; Wed, 6 Mar 2013 15:08:33 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 51E5921F8AD1 for ; Wed, 6 Mar 2013 15:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12883; q=dns/txt; s=iport; t=1362611313; x=1363820913; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=F3tctVh/ottyyE+KHGyIodOb1iTBSokZTVPrX23q02Y=; b=lvAtGHXAJQQ7fWVBZEhlxaWY+s202rCcpoTergbx2zHLtBCGl5g0Fj3/ zlbrHNo10BbC5UeGkRtauVbN7eZ6ISQpnR1Jgx84+nqtHZpYKE1Mexolc Y4TwyPmHOqQVaFEVizR76kEHbgQlI0pqpErv0Hb97KUO9xiK3YJxuuQ9h k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFvLN1GtJXG9/2dsb2JhbABDhU++boFfFnOCKwEBAQQBAQE3NAIEEQYBGQQBAQsUCS4LFAkJAQQKCQgBEod4BwWaI6FPjUwVeg8XGIJZYQOXaY9SgwmBaj0 X-IronPort-AV: E=Sophos;i="4.84,798,1355097600"; d="scan'208";a="181615717" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-9.cisco.com with ESMTP; 06 Mar 2013 23:08:32 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r26N8Wuv003364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Mar 2013 23:08:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 17:08:32 -0600 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: draft-ietf-cdni-requirements-05.txt Thread-Index: Ac4avxMK/pRAinoqR3mcJn/pp4LLVQ== Date: Wed, 6 Mar 2013 23:08:31 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.149.104] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] draft-ietf-cdni-requirements-05.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, 06 Mar 2013 23:08:35 -0000 Hi folks. The requirements draft was updated based on the feedback from the= authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), draf= t-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-logging. In preparation for the next WG session, the edits were published in the dra= ft for review. Please provide your comments to the list of requirement chan= ges below. Thanks. 1. New CDNI Control Interface requirement a. Based on recommendations in ID-HAS, CCID is introduced for HAS = content without the need for HAS-aware CDN. CNTL-12 [MED] The CDNI Control interface should allow for multipl= e=09 content items identified by a Content Collection ID to be=09 purged using a single Content Purge action. 2. New CDNI Request Routing Interface requirements a. This is an explicit requirement for RRI to support per-chunk r= equest routing. Since the chunk is same as any content, it's not clear if t= he requirement is needed? REQ-15 [HIGH] The CDNI Request-Routing interface shall allow for= =09 per-chunk request routing of HTTP Adaptive Streaming content.= =09 [Ed: chunk is treated as any content, is this needed?]=09 =09 b. Manifest rewrite by uCDN is considered as optional feature in = the ID-HAS, should the priority be LOW instead of MED? REQ-16 [MED] The CDNI Request-Routing interface should allow the= =09 Upstream CDN to use the information conveyed by the=09 Downstream CDN during the Recursive Request Routing process=09 to rewrite an HTTP Adaptive Streaming manifest file. [Ed:=09 should this be LOW?]=09 =20 c. Manifest rewrite by uCDN for URI Signing is considered as opt= ional feature in the ID-HAS, should the priority be LOW instead of MED? =09 REQ-17 [MED] The CDNI Request-Routing interface should allow th= e=09 Upstream CDN to re-sign the invariant portion of the chunk=09 URIs embedded in the HTTP Adaptive Streaming manifest file.=09 [Ed: should this be LOW?]=09 =09 d. Use of cookie for URI Signing is is considered as optional fea= ture in the ID-HAS, should the priority be LOW instead of MED? REQ-18 [MED] The CDNI Request-routing interface should allow the= use=09 of HTTP cookie to associate the chunks with the HTTP Adaptive= =09 Stream manifest file (which is verified by the URI signature)= =09 basedon the Authorization Group ID (which is an identifier=09 used to correlate the manifest file to the related chunks).=09 [Ed: should this be LOW?]=09 =20 e. LOW instead of MED priority?=09 REQ-19 [MED] The CDNI Request-Routing interface may allow for an= =09 efficient method of transferring request routing information=09 for multiple chunks from the Downstream CDN to the Upstream=09 CDN as part of the recursive request routing process. [Ed:=09 should this be LOW?]=09 =09 f. Based on ID-HAS and logging drafts, the following requirement = was introduced to log HAS content and customization of the logging. =09 REQ-20 [MED] The CDNI Request-Routing/Footprint and Advertising= =09 interface shall support advertisement of the following=09 capabilities:=09 =09 * support for customized CDNI Logging=09 =09 * support of Content Collection ID logging=09 =09 * support for Session ID logging 3. Removed CDNI Metadata Distribution Interface requirement. a. Based on the metadata draft, there is no need for dCDN to indi= cate to the uCDN the result of delivering the metadata since the "pull" or = "triggered pull" model is used (i.e. dCDN request for metadata from uCDN). META-13 [HIGH] The CDNI Metadata Distribution interface shall =09 provide indication by the Downstream CDN to the Upstream CDN = =09 of whether the CDNI metadata (and corresponding future =09 request redirections) is accepted or rejected. When =09 rejected, the CDNI Metadata Distribution protocol Must allow = =09 the Downstream CDN to provide information about the cause of = =09 the rejection. =09 4. New CDNI Metadata Distribution Interface requirements a. Based on ID-HAS's recommendations, this is introduced. META-19 [HIGH] The CDNI Metadata interface shall provide indicatio= n=09 of related content (e.g. HTTP Adaptive Bit Rate chunks) by=09 the Content Collection ID (CCID) metadata. This could be=09 used by the Downstream CDN for operations on the group of=09 content. For example, this could potentially include:=09 =09 * content acquisition for the entire set of files when one= =09 piece of content is requested=09 =09 * local file management and storage bundles all the files=09 for the content=09 =09 * purging the entire set of files associated with the=09 content=09 =09 * logging of the delivery of the content for the session=09 when at least one file in the set was delivered=09 =09 b. Based on the logging draft, this is introduced. META-20 [HIGH] The CDNI Metadata Distribution interface shall=09 support an OPTIONAL mechanism allowing the Upstream CDN to=09 indicate to the Downstream CDN which CDNI Log fields are to=09 be provided for all, for specific sets of, or for specific=09 content items delivered using HTTP. A CDNI implementation=09 that does not support this optional CDNI Metadata=09 Distribution Interface mechanism MUST ignore this log format= =09 indication and generate CDNI logging format for HTTP=09 Adaptive Streaming using the default set of CDNI Logging=09 fields.=09 =09 c. Based on the ID-HAS's recommendations, this is introduced. META-21 [MED] The CDNI Metadata Distribution interface shall allow= =09 the Upstream CDN to signal to the Downstream CDN the Content= =09 Collection ID value for all, for specific sets of, or for=09 specific content items delivered using HTTP. Whenever the=09 Downstream CDN is instructed by the Upstream CDN to report=09 the Content Collection ID field in the log records, the=09 Downstream CDN is to use the value provided through the CDNI= =09 Metadata interface for the corresponding content. Note the=09 Session ID field along with Content Collection ID may be=09 used for HTTP Adaptive Streaming content.=09 =09 d. Based on ID-HAS's recommendations, this is introduced. META-22 [MED] The CDNI Metadata Distribution interface shall allow= =09 the Upstream CDN to signal to the Downstream CDN the=09 Authorization Group ID value for all the related HTTP=09 Adaptive Streamin content (i.e. manifest file and chunks).=09 The authorization result of a content (e.g. manifest file)=09 is transferred over to related content (e.g. chunks). [Ed:=09 need to improve wording?] 5. Remove CDNI Logging Interface requirement a. It is deemed unnecessary for dCDN to obtain logs from uCDN, whic= h has access to all the logs for trouble-shooting and auditing. LOG-4 [HIGH] The CDNI Logging interface shall provide logging of =09 distribution performed by the Upstream CDN as a result of =09 acquisition request by the Downstream CDN. 6. Add CDNI Logging Interface requirements a. Based on the logging draft, this is introduced. LOG-17 [HIGH] The CDNI Logging interface shall support the=09 notification from Downstream CDN to Upstream CDN for the=09 event that the logging retention duration or maximum size of=09 logging data has exceeded.=09 =09 b. Based on the ID-HAS, CCID is a field to report in the log. Als= o, based on the logging draft, Session ID is another field needed in the lo= g. LOG-18 [MED] The CDNI Logging interface should support the abili= ty=09 for the Downstream CDN to include the Content Collection ID=09 and Session ID fields in CDNI log entries generated for HTTP=09 Adaptive Streaming content. This fields can be supported by=09 the "customizable" log format which is expected to be defined= =09 independently of HTTP Adaptive Streaming. Kent -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Saturday, February 23, 2013 1:16 PM To: i-d-announce@ietf.org Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt 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 : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-05.txt Pages : 23 Date : 2013-02-23 Abstract: Content Delivery Networks (CDNs) are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. There is a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. This draft is a work in progress and requirements may be added, modified, or removed by the working group. Requirements Language The key words "High Priority", "Medium Priority" and "Low Priority" in this document are to be interpreted in the following way: o "High Priority" indicates requirements that are to be supported by the CDNI interfaces. A requirement is stated as "High Priority" when it is established by the working group that it can be met without compromising the targeted schedule for WG deliverables, or when it is established that specifying a solution without meeting this requirement would not make sense and would justify re- adjusting the WG schedule, or both. This is tagged as "[HIGH]". o "Medium Priority" indicates requirements that are to be supported by the CDNI interfaces unless the WG realizes at a later stage that attempting to meet this requirement would compromise the overall WG schedule (for example it would involve complexities that would result in significantly delaying the deliverables). This is tagged as "[MED]". o "Low Priority" indicates requirements that are to be supported by the CDNI interfaces provided that dedicating WG resources to this work does not prevent addressing "High Priority" and "Medium Priority" requirements and that attempting to meet this requirement would not compromise the overall WG schedule. This is tagged as "[LOW]". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-requirements-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-05 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 From Jan.Seedorf@neclab.eu Thu Mar 7 03:03:59 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 6B74B21F8D2E; Thu, 7 Mar 2013 03:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMLloRn+2NZu; Thu, 7 Mar 2013 03:03:58 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6D57A21F8D13; Thu, 7 Mar 2013 03:03:55 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id BBFE81035F7; Thu, 7 Mar 2013 12:03:54 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKMN1JKOo7hK; Thu, 7 Mar 2013 12:03:54 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 9611D1035F5; Thu, 7 Mar 2013 12:03:44 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 7 Mar 2013 12:03:44 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: CDNI Footprint/Capabilities Side Meeting @IETF-86 Thread-Index: Ac4YwPQe14aF90GjQs+loeBh6aCtnACX9odw Date: Thu, 7 Mar 2013 11:03:29 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55457C48@PALLENE.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE55455F3A@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE55455F3A@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni-footprint@ietf.org" Subject: [CDNi] CDNI Footprint/Capabilities Side Meeting @IETF-86 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, 07 Mar 2013 11:03:59 -0000 Dear all, The winner of the doodle is: ** WED, March 13th, 13:00-15:00 ** I suggest we meet at the registration desk and then go find a room. - Jan > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Jan Seedorf > Sent: Monday, March 04, 2013 11:15 AM > To: cdni@ietf.org > Cc: cdni-footprint@ietf.org > Subject: [cdni-footprint] CDNI Footprint/Capabilities Side Meeting @IETF-= 86 >=20 > I have set up a doodle, please try to fill in by Thursday this week, so t= hat we > can decide the best slot and circulate the date/time on Friday. >=20 > http://www.doodle.com/adfa9unigs9gxmr8 >=20 > - Jan >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > Jan Seedorf > Senior Researcher > NEC Europe Ltd., NEC Laboratories Europe, Network Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 > Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 > e-mail:=A0 jan.seedorf@neclab.eu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West En= d > Road, London, HA4 6QE, GB, Registered in England 2832014 >=20 >=20 > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint From flefauch@cisco.com Thu Mar 7 06:32:14 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 9888521F8D3A for ; Thu, 7 Mar 2013 06:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.796 X-Spam-Level: X-Spam-Status: No, score=-9.796 tagged_above=-999 required=5 tests=[AWL=0.803, 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 B3Tg61GnwdWz for ; Thu, 7 Mar 2013 06:32:14 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E707121F8D37 for ; Thu, 7 Mar 2013 06:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1039; q=dns/txt; s=iport; t=1362666734; x=1363876334; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=SJqPvQXTi6NzXhpvtt5GpmhlJ3Nhk+xCj0fdiu8BX6w=; b=KKUgfKFguReXs14eh4xkCVBasuaEjehvYgdtetMonat6jqM6aidahX0k mo7ySdGftyY73mztY8p0lDxh5MGPSXZIMfl1qxCmG1DftoWWHYo0ju9F7 q3q7F2W/ILMRrTx4nhKGPuJ3pFIcr6iRYb6u9Ubd0e5huq1x1llki98k6 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANyjOFGtJXHA/2dsb2JhbABDxESBXBZzgi0BBDpRASoUQicEGxOHeJlooHuOW4MXYQOnPIMJgic X-IronPort-AV: E=Sophos;i="4.84,803,1355097600"; d="scan'208";a="184643992" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 07 Mar 2013 14:32:12 +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 r27EWCkq019510 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Mar 2013 14:32:12 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 08:32:12 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Informal meeting on cdni-logging Thread-Index: AQHOG0COA/bKsKF91E+WEwNxJ8B4eQ== Date: Thu, 7 Mar 2013 14:32:11 +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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Informal meeting on cdni-logging 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, 07 Mar 2013 14:32:14 -0000 Folks, (as an individual and cdni-logging co-author) We'd like to run an informal open meeting around cdni-logging while in Orla= ndo. We've (tentatively) selected: * Tuesday 1:00 pm local time,=20 * get together at the IETF Registration desk.=20 So please put that in your calendar if you're interested in the cdni-loggin= g work. Pretty flexible agenda but should include: * review of candidate logging fields + which is mandatory/optional/mot-nee= ded for delivery records * how hard should we try to make the non-real-time logging solution compat= ible/extensible to real-time logging? in other words, should we first just = specify a very simple file based exchange of log records for non-real-time,= and then accept that we may not be able to leverage much of that when tryi= ng to move to real-time logging? * log records formats/syntax * whatever you'd like to discuss Obviously the cdni-logging draft will still be discussed formally in the CD= NI WG session. Cheers Francois & Iuniana From flefauch@cisco.com Thu Mar 7 07:03:53 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 EED6421F8C8D for ; Thu, 7 Mar 2013 07:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.657 X-Spam-Level: X-Spam-Status: No, score=-9.657 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foL4HwKJG41h for ; Thu, 7 Mar 2013 07:03:52 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 485C621F8C2B for ; Thu, 7 Mar 2013 07:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17940; q=dns/txt; s=iport; t=1362668632; x=1363878232; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aTiuMcDKGvlJNY7iE76XQkcGl3A0i+1D5uPm8cMavnY=; b=RAfUxtHeUAWGASILQgmEhF2Y6uzfjf8LPtCvsJzEe4YHF3fPgfp5UjS/ J6oj+OIrPvzhO1W8ji0jpd0bNEUEAeG+EjlUggAhsYdC95lRcE8dQuZvF G97PGF35GYd5rzL4JMQ+uKHCbmN/kfVChyokcvzTcpOg9uVJyvpcr9Mn3 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAFKrOFGtJV2b/2dsb2JhbABDhUy+eIFcFnOCKwEBAQMBAQEBGgpHCwULAgEIGAokJwslAgQBDQUIAYgEBgcFumCNQIEZAjECBYJfYQOTB4Riij6FFYMJgic X-IronPort-AV: E=Sophos;i="4.84,803,1355097600"; d="scan'208";a="184869355" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 07 Mar 2013 15:03:51 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r27F3pQ7008371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Mar 2013 15:03:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 7 Mar 2013 09:03:50 -0600 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben , Wangdanhua Thread-Topic: [CDNi] Comments on draft-he-cdni-routing-request-redirection-03.txt Thread-Index: AQHOG0T5J2AOtdumkUiruFfPchAQmQ== Date: Thu, 7 Mar 2013 15:03:49 +0000 Message-ID: References: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> <3F5BB382-1292-4EE4-8621-52C7C5097ACC@niven-jenkins.co.uk> 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="Windows-1252" Content-ID: <9EDF90C7F10CA349A13E7BC86A4799C0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-he-cdni-routing-request-redirection-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: Thu, 07 Mar 2013 15:03:54 -0000 Hello Ben and co-authors, Thanks for addressing my comments. This is definitely going in the right direction. Below are a bunch of comments on the latest version (some editorial, some m= ore significant). Francois Title:=20 "Routing Request Redirection" ---> "Request Routing Redirection Interface= " too many authors * section 1: I would suggest: * compressing/removing the 1st two paragraphs and simply refer to RFC6707 * incorporate here the text that you currently have in the abstract which = re-explains the break-down of the request routing interface into FCI and RI= . This is the right place to remind the reader of how the Redirection Inter= face fits in the overall picture. It is also the right place to introduce t= he RI acronym. * section 2: "Examples of an application level redirection are HTTP and RTMP 302 redirec= tions." --> "Examples of an application level redirection are HTTP 302 Redirection = and RTMP 302 Redirection." * section 2: at the end of the HTTP Redirection definition add: "HTTP Redirection is a particular case of Application Level Redirection". *section 3: 1st "Editors' note:. This discusses an interesting point. I suggest in next= rev you replace this with a paragraph that basically says: * how upstream CDN decides which dCDN to talk to via RI is a local policy = of uCDN and outside the scope of this doc * a typical example would be where the uCDN selects the dCDN for the reque= st, and then queries that dCDN via RI and then redirects to the Redirection= Target. * a more complex example would be where the uCDN selects the dCDN for the= request, and then queries that dCDN via RI and got a reject from dCDN. The= n uCDN selects an alternative dCDN and then queries that dCDN via RI and th= en redirects to the Redirection Target. * yet an even more complex example would be where the uCDN selects two can= didate dCDNs and queries both via RI before selecting one and using the Red= irection Target provided by that dCDN. * section 3: "The Redirection Interface operates between a pair of interconnected CDNs." --> " The Redirection Interface operates between the Request Routing system= s of a pair of interconnected CDNs." * everywhere: "Iterative Request Routing" --> "Iterative Request Redirection"=20 "Recursive Request Routing" --> "Recursive Request Redirection" "CDNi" --> "CDNI" * section 3: OLD: " In the case of Recursive Request Routing, an Upstream CDN forwards a CDNI request routing redirection request from a user agent to a Downstream CDN for the Downstream CDN to select a Redirection Target. " NEW: " In the case of Recursive Request Redirection, in order to perform redirecti= on of a request received from a User Agent , the Upstream CDN queries the D= ownstream CDN so that the Downstream CDN can select and provide a Redirecti= on Target. " * section 3: "The initial Upstream CDN->User Agent redirection protocols" --> "The Upstr= eam CDN->User Agent redirection protocols" * "3.1. Discussion on protocol type for CDNI RRRI" there is no "RRRI" acronym defined. * section 3.1: I still have a problem with the content of that section and with Table1. In= particular: * In the 3rd column ("dCDN response"). first the column heading should say= "dCDN RI response". Then , it is misleading to say that the dCDN response = is "DNS with=85" or "HTTP 302": The dCDN response is actually an RI Respons= e that allows the uCDN to build a DNS response or a HTTP 302 response. * in the 4th column ("Notes"). It is incorrect to say that "dCDN uses DNS"= or "dCDN uses HTTP redirection" because all you know is that the uCDN will= use DNS or HTTP, but the dCDN could actually decide to use whatever it wan= ts. For example, the dCDN can provide a CNAME in the RI response that point= s to the dCDN request Router. as a result the USer-Agent the uCDN may perfo= rm DNS redirection but the dCDN will perform HTTP redirection. This section needs to be cleaned up. The kyy points that have to be conveye= d are: * one protocol (DNS or HTTP) is used between User-Agent and uCDN RR * RI is used between uCDN and dCDN, and dCDN uses that to provide a Redire= ction Target in the format that is compatible with the protocol used betwee= n User-Agent and uCDN RR * the dCDN has freedom in the Redirection Target it provides. Depending on= the returned Redirection Target, we may see the following scenario: - the request is redirected to the final Surrogate (i.e. no more redirect= ion) - the request is redirected to a request router that will be using a redi= rection protocol (DNS or HTTP) which may be the same as first redirection o= r may be different. This is controlled by the dCDN =20 * Section 4: "where the attributes of User Agent's requests" --> "where the attributes o= f a User Agent's request" * section 4: "The general call flow between Request Routers" --> "The general Recursive = Request Redirection message flow between Request Routing systems" * section 4: Figure with message flow - add a Figure Number + Figure Title - the numbers of the steps on the right doe snot match the step descriptio= n under the figure * section 4.1: "e.g. URI of the requested content, the client's location information." --> "e.g. URI of the requested content and the client's location informati= on, when those are known by the uCDN Request Routing system." * section 4.1: re Cacheability of the response. I wonder if conveying the cache ability of the response _only_ in standards= HTTP cache-Control mechanism is really the best way to do it, or should we= not also encode it inside the body, just like the scope. I think that has to do with expected implementations of the uCDN Request Ro= uter. If the uCDN RR makes direct use of the cached RI response to process = subsequent requests, then it makes sense to have the cache ability encoded = only in the HTTP headers. If the uCDN RR actually builds a separate table/d= atabase of information derived from the RI responses, then it makes more se= nse to have both cache ability and scope encoded inside the RI response bod= y. Since the RI responses are not easily indexed via a URI (since they are = all posted on the same Redirection Interface URI e.g. rr1.dcdn.example.net/= dcdn/ri ) then I'd expect more the latter type of implementation. No? *4.2 : re JSON encoding Although the trade-offs may not be exactly the same across all Web Services= based CDNI interfaces (RI, MI, Triggers), it would make sense to use the s= ame type of encoding (e.g. JSON or XML) across all the interfaces ; unless = there is really a good reason to not do so. For now, can you add an "Editor's Note" saying that actual choice of encodi= ng is still TBD and all JSON encoding is provided "as an example"? =20 *4.2: "[Maybe a use case is responses is if the dCDN wants to indicate it is prepared to have a DNS redirection directly to it or a HTTP redirection from the uCDN RR to the dCDN and wants to indicate both options in a single response?]] " I would think that the uCDN is the one to choose whether it wants to redire= ct to dCDN via DNS or HTTP. So I don't think the dCDN needs to be able to s= ay it can handle both. However, this makes me think of a potential other requirements: perhaps it = makes sense for the uCDN to influence/control whether the dCDN shoudl be us= ing DNS/HTTP for further redirection. Whether DNS or HTTP redirection is us= ed has visible impact to the enduser and (indirect) impact on the Content P= rovider. So the Content provider may want to impose one mode of redirection= and then the uCDN needs to be able to tell the dCDN whether some mode are = required/forbidden. For example, a Content Provider may want to have only D= NS redirection used so Interconnected CDNs are transparent to endusers (fro= m URI viewpoint). Then the uCDN may need to tell the dCDN that the dCDN oug= ht to pick a Redirection Target that will achieve full DNS redirection (i.e= . the dCDN cannot return as a RT a CNAME who get's resolved as the dCDN RR = IP address). This would call for an additional optional parameter in the RI request indi= cating required (or excluded) downstream redirection protocols. *4.3.1: " o The IP address of the User Agent" --> " o The IP address or prefi= x of the User Agent"=20 On 16 Feb 2013, at 15:57, Ben Niven-Jenkins wrote= : > Francois, >=20 > Closing the loop on this. I've tried to address all your comments in my w= orking copy of draft-he-cdni-routing-request-redirection-04. >=20 > I will be posting it in the next week once I've got feedback from my co-a= uthors. >=20 > When it gets published let me know if you feel your comments below haven;= t been addressed. In particular I re-wrote a lot of the document to incorpo= rate the concept of Redirection targets and I'd be interested in your views= on the new text. >=20 > Ben >=20 > On 7 Nov 2012, at 14:32, Francois Le Faucheur (flefauch) wrote: >=20 >> Thanks for your responses. Looks like we're synch. Please keep track of = those points so they get addressed in the next rev. >> You may want to bring up some of those today (e.g. need for link to meta= data in Redirection request) , specifically during the "discussion slot" fo= r Redirection, so we get input from others. >>=20 >> On 6 Nov 2012, at 10:25, Ben Niven-Jenkins wrote: >>=20 >>> Francois, >>>=20 >>> Please see below for my views. >>>=20 >>> On 5 Nov 2012, at 23:33, Francois Le Faucheur (flefauch) wrote: >>>=20 >>>> Hello, >>>>=20 >>>> (As an Individual). >>>>=20 >>>> In general, I feel this new version is going in the right direction. >>>>=20 >>>> Some high level comments: >>>>=20 >>>> * I think the spec should be less prescriptive as to how a dCDN build= s its redirection response. For example in section 6.1.1, the text says: >>>> "If the dCDN decides to use DNS Redirection, where the Downstream CDN >>>> is redirecting directly to a surrogate in the Downstream CDN: the >>>> Downstream CDN selects one or more surrogates and returns a CDNI RRRI >>>> response containing the IP addresses of the selected surrogate(s), ... >>>> If the dCDN decides to use DNS Redirection, where the Downstream CDN >>>> is redirecting to a Request Router in the dCDN: : the Downstream CDN >>>> returns a CDNI RRRI response containing a CNAME of the Downstream >>>> CDN's Request Router(s), =85 >>>> " >>>> In this example, I think the dCDN should be free to return an IP addre= ss or a CNAME of the "redirection target" as it sees fit. The redirection t= arget may be a Surrogate, a Request Router, a set of Surrogates, a 3rd part= y CDN Req Router, a 3rd party CDN Surrogate in case of cascaded CDNs,... wh= atever the dCDN sees fit. >>>> You could possibly mention one of the behavior above as an example of = what might happen, but it should just be an example and I recommend the spe= c be open as to the logic to populate the Redirection response. >>>=20 >>> Fair comment. Describing the different redirection possibilities & thei= r applicability while at the same time talking about CDNI Redirection in a = more generic way (so we don't keep repeating all the different nuances) was= something we struggled a little with and is certainly an area of the draft= (IMO) that needs more work to make the text clearer etc. >>>=20 >>> I like your idea of a 'redirection target' and maybe the right approach= is to have a section defining/discussing the possibilities for redirection= (A/AAAA/CNAME/Application level 302/etc) to a 'redirection target' in a dC= DN and in the rest of the document just talk generically about redirection = targets? >>>=20 >>>> * the document keeps talking about "encapsulating the enduser request"= inside the Redirection Request. I find this misleading, because this is no= t about encapsulating the enduser request per-say, but rather to convey the= key attributes of the enduser request. >>>=20 >>> Fair comment. We used 'encapsulating end user request' to distinguish b= etween previous versions of the draft where the end user request was proxie= d to a dCDN via the same protocol that the end user request was made over. >>>=20 >>> Going forward that history doesn't matter and we should use better lang= uage to describe what we are actually doing. >>>=20 >>>> * for HTTP, the Redirection Request should allow passing other attribu= tes in addition to client IP address and URI. >>>=20 >>> The draft currently just tries to define the minimum necessary informat= ion for a dCDN to be able to perform a redirection. There are probably othe= r attributes that the dCDN would find useful and although it is not explici= tly described in the current draft I think the CDNI Redirection 'protocol f= ramework' in draft-he easily allows passing additional optional attributes.= Describing how to extend the 'base protocol' with additional attributes is= certainly something we should add in a future revision of the draft. >>>=20 >>> Personally, I am reluctant to define lots of theoretical attributes (th= at no one ends up using) to be included in a CDN Redirection request but I = would like to hear views from implementors on the attributes they actually = use (or plan to use as part of CDNI) to influence surrogate selection/redir= ection across a CDN interconnect. >>>=20 >>>> * the document requires that a pointer to Metadata be included in the = Redirection request: >>>> "For DNS redirection, the uCDN also needs to provide in the CDNI RRRI >>>> request the a link to the associated CDNI Metadata for the host/ >>>> domain being requested." >>>> Considering that the latest Metadata interface allows the dCDN to walk= down the metadata tree for any content without seeding any initial info/po= inters, I am not sure there is a benefit in passing a link to metadata insi= de the Redirection request. If would potentially save the dCDN Request Rout= er to do the lookup on Content-->Metadata , but would require the uCDN Requ= est Router to do the same on its behalf. Besides the dCDN has to do that lo= oup anyways to get the Metadata for serving the content. >>>=20 >>> This is in my slides for Thursday. When I was thinking about CDN Redire= ction a while ago I convinced myself a link to CDNI Metadata was useful so = when I started working on draft-he I included it, but since then I've been = struggling to remind myself why I originally thought it was required so I'm= certainly open to removing it. >>>=20 >>>> * the redirection interface will need to discuss handling of URI Signi= ng=20 >>>=20 >>> Sure. Personally I'd like the uri signing/token authorisation work in t= he WG to mature a bit more first just to avoid having to keep draft-he alig= ned with a still moving target. >>>=20 >>> At a minimum we should include in the next revision a comment that we s= till need to factor token authorisation into the document. >>>=20 >>>> * we need to agree on a set of acronyms to refer to the "CDNI Request = Routing/Redirection Interface". I will bring that up during the meeting thi= s week. >>>=20 >>> OK >>>=20 >>> Ben >>>=20 >>>>=20 >>>> HTH >>>>=20 >>>> Francois >>>>=20 >>>>=20 >>>> On 21 Oct 2012, at 23:02, >>>> wrote: >>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>>>>=20 >>>>>=20 >>>>> Title : Routing Request Redirection for CDN Interconnectio= n >>>>> Author(s) : Wang Danhua (editor) >>>>> He Xiaoyan >>>>> Spencer Dawkins >>>>> Ge Chen >>>>> Ni Wei >>>>> Zhang Yunfei >>>>> Ben Niven-Jenkins >>>>> Filename : draft-he-cdni-routing-request-redirection-03.txt >>>>> Pages : 19 >>>>> Date : 2012-10-21 >>>>>=20 >>>>> Abstract: >>>>> The Request Routing Interface comprises of (1) the asynchronous >>>>> advertisement of footprint and capabilities by a downstream CDN that >>>>> allows a upstream CDN to decide whether to redirect particular user >>>>> requests to that downstream CDN; and (2) the synchronous operation of >>>>> an upstream CDN requesting whether a downstream CDN is prepared to >>>>> accept a user request and of a downstream CDN responding with how to >>>>> actually redirect the user request. This document describes an >>>>> interface for the latter part, i.e. the CDNI Request Routing >>>>> Redirection interface. >>>>>=20 >>>>>=20 >>>>> The IETF datatracker status page for this draft is: >>>>> https://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redire= ction >>>>>=20 >>>>> There's also a htmlized version available at: >>>>> http://tools.ietf.org/html/draft-he-cdni-routing-request-redirection-= 03 >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> http://www.ietf.org/rfcdiff?url2=3Ddraft-he-cdni-routing-request-redi= rection-03 >>>>>=20 >>>>>=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 >>>>=20 >>>> _______________________________________________ >>>> CDNi mailing list >>>> CDNi@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni >>>=20 >>=20 >=20 From flefauch@cisco.com Fri Mar 8 00:27:19 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 BDE8721F8630 for ; Fri, 8 Mar 2013 00:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.483 X-Spam-Level: X-Spam-Status: No, score=-10.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 wksgM2p9PSfk for ; Fri, 8 Mar 2013 00:27:14 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 51B3421F84BE for ; Fri, 8 Mar 2013 00:27:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=430; q=dns/txt; s=iport; t=1362731234; x=1363940834; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SEv3p5wzZZp9d4RISRK34C0Ox1EOqO2kkcPu1p3Uqss=; b=PDBdK1i1+kEWvWroP4t6FNzrqdkmL9vz19kh0vvJ85HzXY1KcCwfqbo5 nKSjz5gktXiftTeUBZkn5wMvVGy+q7Maos/x+FYAet2ZHElpu/r6D4UH6 0KLW74oUI2NkE48WWhX9iou9805H6HML7Y/NoUAok1HWYxsx4dybwQ7gK A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAEugOVGtJXG+/2dsb2JhbABDh1u8coFYFm0HgisBAQEDAQEBATc0EAsCAQgiFBAnCyUCBBMIiAUGDLscBI5ZAjiCX2EDpzyDCYIn X-IronPort-AV: E=Sophos;i="4.84,806,1355097600"; d="scan'208";a="185001875" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 08 Mar 2013 08:27:13 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r288RDWi021967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 8 Mar 2013 08:27:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 02:27:13 -0600 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] CDNI slides for your presentations Thread-Index: AQHOGMR2AdcKYlHBSEaODv6/Sc/Ob5ib4IIA Date: Fri, 8 Mar 2013 08:27:12 +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: <70FEF22E929F33429633CF0DEDA3A362@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] CDNI slides for your presentations X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 08:27:19 -0000 Just a friendly reminder. On 4 Mar 2013, at 11:38, Francois Le Faucheur (flefauch) wrote: > To all CDNI presenters in Orlando, >=20 > Please send Rich and I your draft slidedeck asap and no later than Sunday= 10 March. >=20 > Cheers >=20 > Francois & Rich > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Fri Mar 8 10:05: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 1062121F87AF for ; Fri, 8 Mar 2013 10:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.097 X-Spam-Level: X-Spam-Status: No, score=-10.097 tagged_above=-999 required=5 tests=[AWL=0.502, 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 4eKBdqhNc2Sz for ; Fri, 8 Mar 2013 10:05:37 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id D2F2821F8783 for ; Fri, 8 Mar 2013 10:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28909; q=dns/txt; s=iport; t=1362765937; x=1363975537; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=vF5Wug6Ntkw+hHXNNw4CZKitHsIOeaLtxu3VwF8ZV7I=; b=axnJG0wjhbRqALq/H8omXPolJkGIPfisSIGkVknekURJGwjVgmAkUOcL R61wNb/5QJwlgLCyK9EBH+uc5v3xwwYyRHtBRf258CPg8GMmkcmG/wpGA oRs3Vkq3Tkuxih3mwHV3lUz4kHQv6eXf8Akw/TEyzP0guzM6UcmePTnUo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPMnOlGtJXG9/2dsb2JhbABDxE6BWxZ0giwBAQEDARoNQAsHBQsCAQgRAwECAQoLGTIdCAIEDgUIE4dyBrskiXWDSxaBAwImCwcGBIJVYQOXcY9UgwqBaj0 X-IronPort-AV: E=Sophos;i="4.84,809,1355097600"; d="scan'208";a="185456766" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 08 Mar 2013 18:05:35 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r28I5ZLt013470 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Mar 2013 18:05:35 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Fri, 8 Mar 2013 12:05:35 -0600 From: "Francois Le Faucheur (flefauch)" To: "Peterson, Larry" Thread-Topic: 2nd batch of comments on cdni-framework Thread-Index: AQHOHCeI+byF7dh4PEG1QkK8WqWDEA== Date: Fri, 8 Mar 2013 18:05:35 +0000 Message-ID: References: <8E46261D-5CD6-46CC-AD81-7F5CF8E7F595@verivue.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.195] Content-Type: text/plain; charset="Windows-1252" Content-ID: <759566351B95C4429F5EEB512DE8B2A3@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [CDNi] 2nd batch of comments on cdni-framework X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 18:05:42 -0000 Hi Larry, I just had a quick look at cdni-framework-03 and can confirm this version a= ddresses my last comment. Thanks Francois On 21 Dec 2012, at 22:40, "Peterson, Larry" wrote: > You aren't missing anything. I was probably trying to sweep too much > under the rug. I've added the additional message to figures 3 and 4. >=20 > Larry >=20 > On Dec 21, 2012, at 9:57 AM, Francois Le Faucheur (flefauch) wrote: >=20 >> Hi Larry, >>=20 >> On 21 Dec 2012, at 15:14, Peterson, Larry wrote: >>=20 >>> Francois, >>>=20 >>> You're right. I should have warned you. My reading is that the explanat= ion >>> in the text covers (explains) that case, which we don't need to trace e= xplicitly. >>=20 >> There seems to be a disconnect. Let me try clarify (and please let me kn= ow if I am missing something) >> I am not talking about some special case. In the message flow that is sh= own, I believe there is simply one single mandatory message that is missing= . >>=20 >> The figure currently shows: >> " >> | |HTTP op-b-acq.op-a.net | >> | |------------------------>| >> | | |(8) >> | |302 node2.op-b.acq.op-A.net >> | |<------------------------| >> | |DNS node2.op-b-acq.op-a.net >> | |------------------------>| >> | | |(9) >> | |IPaddr of A's Delivery Node >> | |<------------------------| >> | | |(10) >> | |Data | >> | |<------------------------| >> " >>=20 >> I believe it should show: >> " >> | |HTTP op-b-acq.op-a.net | >> | |------------------------>| >> | | |(8) >> | |302 node2.op-b.acq.op-A.net >> | |<------------------------| >> | |DNS node2.op-b-acq.op-a.net >> | |------------------------>| >> | | |(9) >> | |IPaddr of A's Delivery Node >> | |<------------------------| >>=20 >> | |HTTP node2.op-b-acq.op-a.net >> | |------------------------>| >>=20 >> | | |(10) >> | |Data | >> | |<------------------------| >> " >>=20 >> The message flows always show every DNS message and every HTTP message, = it does not make sense to me to omit one single HTTP request message when a= ll the ones are shown. >> In step 2, 3 and 4 above, you have the exact same sequence of HTTP redir= ect, DNS , HTTP request and the HTTP request is shown. Why would you not sh= ow in step (9). >>=20 >> BTW, the text that follows the figure also makes the same omission i.e. = it describe the HTTP redirect, the corresponding DNS, and then just says th= at the content is served. But the content won't be served until operator B = issues a HTTP request following the 302 redirect. >> If Operator A was to use DNS for intra-CDN request routing, then you don= 't need to show this HTTP request, but you example does not assume DNS redi= rection since it shows a 302 node2.op-b.acq.op-A.net. >> As shown the message flow is a cross-breed between the DNS message flow = and the HTTP message flow and does not seem correct to me. >>=20 >> Same applies to Figure 4. >>=20 >> What am I missing? >>=20 >> Thanks >>=20 >>=20 >>>=20 >>> Larry >>>=20 >>> On Dec 20, 2012, at 10:48 AM, Francois Le Faucheur (flefauch) wrote: >>>=20 >>>> To the WG, >>>> I just realized that I had inadvertently omitted to copy the cdni alia= s when I sent my 2nd batch of comments on cdni-framework last October. So h= ere it is below, just for the records. >>>>=20 >>>> To Larry, Bruce, >>>> Thanks very much for incorporating my two batches of comments. >>>> I noticed that you did not reflect the comments about a missing messag= e in the message flows of Figure 3 and Figure 4. Is this an omission on you= r end, or am I missing something and these messages are actually not needed= ? >>>>=20 >>>> " >>>>> section 3.2, Figure 3: >>>>> I believe a HTTP request is missing in the acquisition phase (i.e. af= ter step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the d= CDN will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" whi= ch is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should h= appen just before the "Data" message. >>>> " >>>> " >>>>> Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.= net" request missing from the figure. >>>> " >>>>=20 >>>> Thanks >>>>=20 >>>> Francois >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>>=20 >>>>> From: Francois Le Faucheur >>>>> Subject: 2nd batch of comments on cdni-framework >>>>> Date: 31 October 2012 18:44:51 CET >>>>> To: >>>>>=20 >>>>> Larry, Bruce, >>>>>=20 >>>>> Below is the second batch of my detailed comments on cdni-framework-0= 1 (as an Individual). >>>>> I don't think there is anything major missing from the document. >>>>>=20 >>>>> I hope these comments are useful and can be addressed in a new versio= n soon. >>>>>=20 >>>>> Cheers >>>>>=20 >>>>> Francois >>>>>=20 >>>>>=20 >>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>=20 >>>>>=20 >>>>> As discussed off-line, one general change needed is to reflect the IE= TF-84 decisions with respect to HAS. >>>>>=20 >>>>>=20 >>>>> section 1.1: >>>>> OLD: >>>>> " >>>>> Recursive CDNI request routing: When an Upstream CDN elects to >>>>> redirect a request towards a Downstream CDN, the Upstream CDN can >>>>> query the Downstream CDN Request Routing system via the CDNI Request >>>>> Routing interface (or use information cached from earlier similar >>>>> queries) to find out how the Downstream CDN wants the request to be >>>>> redirected, which allows the Upstream CDN to factor in the Downstream >>>>> CDN response when redirecting the user agent. This approach is >>>>> referred to as "recursive" CDNI request routing. Note that the >>>>> Downstream CDN may elect to have the request redirected directly to a >>>>> Surrogate inside the Downstream CDN, to the Request-Routing System of >>>>> the Downstream CDN, to another CDN, or to any other system that the >>>>> Downstream CDN sees as fit for handling the redirected request. >>>>> " >>>>> NEW: >>>>> " >>>>> Recursive CDNI Request Redirection: When an Upstream CDN elects to >>>>> redirect a request towards a Downstream CDN, the Upstream CDN can >>>>> query the Downstream CDN Request Routing system via the CDNI Request >>>>> Routing Redirection interface (or use information cached from earlier= similar >>>>> queries) to find out how the Downstream CDN wants the request to be >>>>> redirected, which allows the Upstream CDN to factor in the Downstream >>>>> CDN response when redirecting the user agent. This approach is >>>>> referred to as "Recursive" CDNI Request Redirection. Note that the >>>>> Downstream CDN may elect to have the request redirected directly to a >>>>> Surrogate inside the Downstream CDN, to the Request-Routing System of >>>>> the Downstream CDN, to another CDN, or to any other system that the >>>>> Downstream CDN sees as fit for handling the redirected request. >>>>> " >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> " >>>>> Iterative CDNI Request Routing: When an Upstream CDN elects to >>>>> redirect a request towards a Downstream CDN, the Upstream CDN can >>>>> base its redirection purely on a local decision (and without >>>>> attempting to take into account how the Downstream CDN may in turn >>>>> redirect the user agent). In that case, the Upstream CDN redirects >>>>> the request to the request routing system in the Downstream CDN, >>>>> which in turn will decide how to redirect that request: this approach >>>>> is referred to as "iterative" CDNI request routing. >>>>> " >>>>> NEW: >>>>> " >>>>> Iterative CDNI Request Redirection: When an Upstream CDN elects to >>>>> redirect a request towards a Downstream CDN, the Upstream CDN can >>>>> base its redirection purely on a local decision (and without >>>>> attempting to take into account how the Downstream CDN may in turn >>>>> redirect the user agent). In that case, the Upstream CDN redirects >>>>> the request to the request routing system in the Downstream CDN, >>>>> which in turn will decide how to redirect that request: this approach >>>>> is referred to as "Iterative" CDNI Request Redirection. >>>>> " >>>>>=20 >>>>>=20 >>>>>=20 >>>>> section 3: >>>>> I suggest tweaking titles of the example sections to make them more c= onsistent and explicit: >>>>> * section 3.2: "HTTP Redirect Example" --> "Iterative HTTP Redirecti= on Example" >>>>> * section 3.3: "Recursive Redirection Example" --> "Recursive HTTP R= edirection Example" >>>>> * section 3.4: "DNS-based redirection example" --> "Iterative DNS-ba= sed Redirection Example" >>>>> * section 3.5: "Dynamic Footprint Discovery" --> "Dynamic Footprint = Discovery example" >>>>> * section 3.6: "Content Removal" --> "Content Removal Example" >>>>>=20 >>>>>=20 >>>>> section 3: >>>>> All figures are titled as "Request Trace for =85" >>>>> I'd suggest titling them with something like "Message Flow for=85". T= his is not really a "trace" and I am not sure what "request" is, because th= e message flows contain both "requests" and "responses", and there are mess= age flows that don't relate to any "content request". >>>>>=20 >>>>>=20 >>>>> section 3.2, Figure 3: >>>>> I believe a HTTP request is missing in the acquisition phase (i.e. af= ter step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the d= CDN will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" whi= ch is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should h= appen just before the "Data" message. >>>>>=20 >>>>>=20 >>>>> section 3.2: >>>>> OLD: >>>>> " >>>>> it is at this point that Operator A processes the rest of the URL: >>>>> " >>>>> NEW: >>>>> " >>>>> Operator A processes the rest of the URL: >>>>> " >>>>> (rationale: Operator A may have looked at the rest of the URL in earl= ier steps e.g. to look at metadata to decide if/how to redirect etc, so bet= ter leave it open). >>>>>=20 >>>>>=20 >>>>> section 3.2.1: >>>>> OLD >>>>> " >>>>> For example, obtaining information from dCDN regarding the set of cli= ent >>>>> IP addresses or geographic regions it might be able to serve is an >>>>> aspect of the request routing interface. >>>>> " >>>>> NEW: >>>>> " >>>>> For example, obtaining information from dCDN regarding the set of cli= ent >>>>> IP addresses or geographic regions it might be able to serve is an >>>>> aspect of the CDNI request routing interface (specifically of the CDN= I Footprint & Capabilities advertisement interface). >>>>> " >>>>>=20 >>>>>=20 >>>>> section 3.2.1: >>>>> OLD >>>>> " >>>>> Hence, there is no explicit metadata interface invoked in this exampl= e. >>>>> " >>>>> NEW: >>>>> " >>>>> The example also assumes that the CSP does not require any distributi= on policy (e.g. time window, geo-blocking) or delivery processing to be app= lied by the interconnected CDNs. Hence, there is no explicit metadata inter= face invoked in this example. >>>>> " >>>>>=20 >>>>>=20 >>>>> section 3.3: >>>>> OLD: >>>>> " >>>>> The following example builds on the previous one to illustrate the >>>>> use of the Request Routing interface to enable "recursive" CDNI >>>>> request routing. >>>>> " >>>>> NEW: >>>>> " >>>>> The following example builds on the previous one to illustrate the >>>>> use of the Request Routing interface (specifically the CDNI Request R= outing Redirection interface) to enable "recursive" CDNI request routing. >>>>> " >>>>>=20 >>>>> section 3.3: >>>>> OLD: >>>>> " >>>>> The operators still must agree on some distinguished >>>>> CDN-domain that will be used for inter-CDN acquisition of CSP's >>>>> content by dCDN. >>>>> " >>>>> NEW: >>>>> " >>>>> We assume that the operators agree on some distinguished >>>>> CDN-domain that will be used for inter-CDN acquisition of CSP's >>>>> content by dCDN. >>>>> " >>>>> (Rationale: I made the same comment about section 3.2. While it is co= nvenient to do it that way, it is not an absolute requirement.) >>>>>=20 >>>>>=20 >>>>> section 3.3: >>>>> " >>>>> DNS must be configured in the following way: >>>>> " >>>>> Again, I suggest the text is tweaked in multiple places so that the "= must" is replaced by something like "we assume that". Because a lot of thos= e are just how the example works, but is not a "must" in itself. >>>>> This carries into all other examples (e.g. section 3.4 and so on). >>>>> I believe this needs to be fixed because an issue that has been broug= ht up multiple times wrt current framework is a need to clarify what is exa= mple from what is prescription. >>>>>=20 >>>>>=20 >>>>> Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.= net" request missing from the figure. >>>>>=20 >>>>> section 3.3, step 2: >>>>> OLD: >>>>> " >>>>> so it queries the CDNI Request Routing interface of Operator B >>>>> " >>>>> NEW: >>>>> " >>>>> so it queries the CDNI Request Routing Redirection interface of Opera= tor B >>>>> " >>>>> (more generally, you need to check all occurrences of "Request Routin= g Interface" or "RRI" throughout the document and align to our finalized no= menclature of "CDNI Request Routing Redirection interface" and "CDNI Footpr= int & Capabilities advertisement interface". >>>>> In Figure 4, "RRI REQ" needs to be changed to something like "RR-RI R= EQ") >>>>>=20 >>>>>=20 >>>>> section 3.4.1: >>>>> OLD: >>>>> " >>>>> The advantages of this approach are that it is more transparent to >>>>> the end-user and requires fewer round trips than HTTP-based >>>>> redirection. >>>>> " >>>>> NEW: >>>>> " >>>>> The advantages of this approach are that it is more transparent to >>>>> the end-user and requires fewer round trips than HTTP-based >>>>> redirection (in its worst case i.e. when none of the needed DNS infor= mation is cached). >>>>> " >>>>> (Rationale: in the HTTP redirection case, the extra RTTs have to do w= ith DNS request for very stable information such as the IP address of the C= DN domains or delivery nodes. Those can be appropriately handled with long = TTLs - certainly compared to the TTL that needs to be applied in case of DN= S redirection. So in practice, for many requests the nb of real RTTs would = be similar. In fact, I'd suggest you bring up this point). >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> " >>>>> In this case, one option is for the upstream CDN to treat the end-use= r >>>>> as it would any user not connected to a peer CDN. >>>>> " >>>>> NEW: >>>>> " >>>>> In this case, and assuming the uCDN is capable of detecting that situ= ation, one option is for the upstream CDN to treat the end-user >>>>> as it would any user not connected to a peer CDN. >>>>> " >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> " >>>>> Note that this >>>>> problem affects existing CDNs that rely on DNS to determine where to >>>>> redirect client requests, but the consequences are arguably less >>>>> serious since the LDNS is likely in the same network as the dCDN >>>>> serves. >>>>> " >>>>> I don't quite get that sentence. >>>>> First, I suggest you make it explicit as to whether you mean "the co= nsequences are arguably less serious in existing CDNs" or "the consequence= s are arguably less serious CDNI". >>>>> Second, I don't quite see the difference between the two: if an endus= er uses a global DNS, then a single CDN just cannot make any reasonable dec= ision, nor can an uCDN in CDNI. >>>>>=20 >>>>>=20 >>>>> section 3.5, Figure 6: >>>>> OLD: >>>>> " >>>>> RRI REQ >>>>> " >>>>> NEW: >>>>> " >>>>> RR-F&CAI REQ >>>>> " >>>>> (in line with earlier comment: for "Request Routing - Footprint and C= apabilities Advertisement interface) >>>>>=20 >>>>>=20 >>>>> section 3.5: >>>>> The notion of Footprint discovery could be illustrated with either DN= S or HTTP. The document currently illustrates it with DNS. However, it gets= a little confusing because (i) the example interaction mentioned is "Can y= ou >>>>> serve clients from this IP Prefix?" and (ii) the text just before sec= tion 3.5 just discussed the issue of identifying the client IP address in c= ase of HTTP redirection (which is why a note was added : "(Note that the is= sues of determining the client's subnet from DNS requests, as described abo= ve, are exactly the same here as >>>>> in Section 3.4.) ". >>>>> I would suggest simply using HTTP redirection (instead of DNS) in the= example of section 3.5. I think it would make the concept of footprint dis= covery easier to get for the reader. >>>>>=20 >>>>>=20 >>>>> Figure 7: >>>>> you included step numbers (e.g "(1)") in the Figure but did not refer= to those in the description text. >>>>>=20 >>>>>=20 >>>>> section 3.7: >>>>> OLD: >>>>> " >>>>> The following example illustrates how the Control interface may be >>>>> used to pre-position an item of content in the dCDN. >>>>> " >>>>> NEW: >>>>> " >>>>> The following example illustrates how the Control interface may be >>>>> used to achieve pre-positioning of an item of content in the dCDN. >>>>> " >>>>>=20 >>>>>=20 >>>>> section 3.7, Figure 8: >>>>> Figure 8 actually shows a scenario where dCDN performs DNS redirectio= n for intra-CDN request routing (i.e. in step 6). This is in contradiction = with the statement "Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3,= 4 of >>>>> Figure 3," since Figure 3 actually showed HTTP redirection in dCDN an= d involved an additional step 5. Also it is the first time where an example= mixes HTTP redirection across CDNs with DNS redirection inside a CDN, and = while I don't have a problem in showing such a combination, I don't think i= t should be introduced in the middle of the example illustrating prepositio= ning. >>>>> My recommendation is to tweak the current example in Figure 8 to show= HTTP redirection in dCDN (as is done in the referenced Figure 3). >>>>>=20 >>>>>=20 >>>>> section 3.8: >>>>> We have progressed on the topic of "metadata push" and this is now se= en as "triggered pull" initiated by the Control interface. >>>>> While it is logically close to a metadata push, I recommend that: >>>>> * the terminology be updated to current one e.g. as per RFC6707 : "Pr= e-positioned CDNI Metadata acquisition: " >>>>> * the "MI push" in the figure be replaced with a "CI pre-position" + = "CI OK" + "MI pull" (the "CI" messages would be analogous to those of Figu= re 7). >>>>> If you feel it is useful you could put a note that this could have be= en realized via a push mechanism, but that CDNI solution has selected a tri= ggered Pull solution at least initially. But I suggest the description be m= ade using triggered Pull. >>>>>=20 >>>>>=20 >>>>> section 3.9: >>>>> " 1. Operator A initially uses the Metadata Interface to >>>>> asynchronously push seed metadata to Operator B. For example, >>>>> this seed information may include a URI indicating where CDNI >>>>> Metadata can later be pulled from for some content set. >>>>> " >>>>> We have progressed on the topic of "metadata seed". As discussed in i= etf-cdni-metadata, there is only one single bit of info that needs to be kn= own ahead of time which is the URI of the Metadata server, from which every= thing can be learnt. And this info is expected to be known via config, or l= earnt via some future CDNI auto discovery protocol. This basically removes = the need for any seed info related to a content or content range. >>>>> So I recommend removing step 1 from the Figure and from the text. >>>>>=20 >>>>>=20 >>>>> section 3.10: >>>>> OLD: >>>>> " >>>>> 3.10. Content Acquisition with Multiple Upstream CDNs >>>>> " >>>>> NEW: >>>>> " >>>>> 3.10. Content Acquisition and Metadata Acquisition with Multiple Ups= tream CDNs >>>>> " >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> " >>>>> Given that the dCDN has established a business relationship with each= of its uCDNs, assume >>>>> that the dCDN can trust any uCDN to acquire the content. The dCDN >>>>> may narrow the set of viable uCDNs by examining the CDNI metadata >>>>> from each to determine which uCDNs are hosting metadata for the >>>>> requested content." >>>>> NEW: >>>>> " >>>>> The dCDN may narrow the set of viable uCDNs by examining the CDNI met= adata >>>>> from each to determine which uCDNs are hosting metadata for the >>>>> requested content. If there is a single uCDN hosting metadata for the= requested content, the dCDN can assume that the request redirection is com= ing from this uCDN and can acquire content from that uCDN. If there are mul= tiple uCDNs hosting metadata for the requested content, the dCDN may be rea= dy to trust any of these uCDNs to acquire the content (provided the uCDN is= in a position to serve it). If the dCDN is not ready to trust any of these= uCDNs, it needs to ensure via out of band arrangements that, for a given c= ontent, only a single uCDN will ever redirect requests to the dCDN. " >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> " >>>>> tightly c coupled >>>>> " >>>>> NEW: >>>>> " >>>>> tightly coupled >>>>> " >>>>>=20 >>>>>=20 >>>>> section 4: >>>>> OLD: >>>>> " >>>>> Figure 1 illustrates the four main interfaces that are in scope for >>>>> the CDNI WG, along with several others. >>>>> " >>>>> NEW: >>>>> " >>>>> Figure 1 illustrates the four CDNI interfaces, along with several oth= er relevant interfaces. >>>>> " >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> " >>>>> The detailed specifications >>>>> of these interfaces are left to other documents (mostly still to be >>>>> written, but see [I-D.ietf-cdni-problem-statement] and >>>>> [I-D.ietf-cdni-requirements] for some discussion of the interfaces). >>>>> " >>>>> NEW: >>>>> " >>>>> The detailed specifications >>>>> of these interfaces are left to other documents, but see [I-D.ietf-cd= ni-problem-statement] and >>>>> [I-D.ietf-cdni-requirements] for some discussion of the interfaces. >>>>> " >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> " >>>>> There is also an important interface between the user and the Request >>>>> Routing function of both uCDN and dCDN. As we saw in some of the >>>>> preceding examples, that interface can be used as a way of passing >>>>> information such as the metadata that is required to obtain the >>>>> content in dCDN from uCDN. >>>>> " >>>>> NEW: >>>>> " >>>>> There is also an important interface between the user and the Request >>>>> Routing function of both uCDN and dCDN (shown as the "Request" interf= ace in Figure 1). As we saw in some of the >>>>> preceding examples, that interface can be used as a way of passing >>>>> information a subset of metadata such as the minimum information that= is required for dCDN to obtain the >>>>> content from uCDN. >>>>> " >>>>>=20 >>>>> section 4.2: >>>>> OLD: >>>>> " >>>>> While in the the limit >>>>> " >>>>> NEW: >>>>> " >>>>> While in the limit >>>>> " >>>>>=20 >>>>>=20 >>>>> section 4.2: >>>>> I recommend the text in this section: >>>>> * be aligned to our finalized nomenclature of "CDNI Request Routing R= edirection interface" and "CDNI Footprint & Capabilities advertisement inte= rface". >>>>> * be structured to separate discussion on these two interfaces >>>>> * refers to draft-spp-cdni-rr-foot-cap-semantics ( CDNI Request Routi= ng: Footprint and Capabilities Semantics) when discussing the information = to advertise as footprint >>>>>=20 >>>>>=20 >>>>> section 4.4: >>>>> OLD: >>>>> " >>>>> It is necessary for the upstream CDN to have visibility into the >>>>> delivery of content it originates to end-users connected to the >>>>> downstream CDN. >>>>> " >>>>> NEW: >>>>> " >>>>> It is necessary for the upstream CDN to have visibility into the >>>>> delivery of content that it redirected to a downstream CDN. >>>>> " >>>>>=20 >>>>> section 4.4: >>>>> [I-D.lefaucheur-cdni-logging-delivery] has been incorporated into [I-= D.bertrand-cdni-logging], so you only need to refer to the latter. >>>>>=20 >>>>> section 4.6: >>>>> [I-D.ma-cdni-metadata] and [I-D.cjlmw-cdni-metadata] are now merged i= nto ietf-cdni-metadata, so you only need to refer to that document. >>>>>=20 >>>>> section 4.6: >>>>> OLD: >>>>> " >>>>> Such metadata includes geo-blocking >>>>> restrictions, availability windows, access control policies, and so >>>>> on. It may also include policy information such as the desire to >>>>> pre-position content rather than fetch it on demand. >>>>> " >>>>> NEW: >>>>> " >>>>> Such metadata includes geo-blocking >>>>> restrictions, availability windows, access control policies, and so >>>>> on. It may also include information to facilitate acquisition of con= tent by dCDN (e.g. alternate sources for the content, authorization informa= tion needed to acquire the content from the source). >>>>> " >>>>> (Rationale: just aligning metadata examples to what is likely support= ed by the metadata interface, to avoid confusion). >>>>>=20 >>>>>=20 >>>>> section 4.6: >>>>> OLD: >>>>> " >>>>> Some metadata may be able to be conveyed using in-band mechanisms. >>>>> For example, to inform the downstream CDN of any geo-blocking >>>>> restrictions or availability windows, the upstream can elect to >>>>> redirect a request to the downstream CDN only if that CDN's >>>>> advertised delivery footprint is acceptable for the requested URL. >>>>> Similarly, the request could be forwarded only if the current time is >>>>> within the availability window. >>>>> " >>>>> NEW: >>>>> " >>>>> Some distribution metadata may be partially emulated using in-band me= chanisms. >>>>> For example, in case of any geo-blocking >>>>> restrictions or availability windows, the upstream CDN can elect to >>>>> redirect a request to the downstream CDN only if that CDN's >>>>> advertised delivery footprint is acceptable for the requested URL. >>>>> Similarly, the request could be forwarded only if the current time is >>>>> within the availability window. However, such approaches typically co= me with shortcomings such as inability to prevent from replay outside the t= ime window or inability to make use of a downstream CDN that covers a broad= er footprint than the geo-blocking restrictions. >>>>> " >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> " >>>>> All of these in-band techniques serve to illustrate that uCDNs have >>>>> the option of enforcing their access control policies themselves, >>>>> rather than delegating enforcement to dCDNs using the Metadata >>>>> interface. >>>>> " >>>>> NEW: >>>>> " >>>>> All of these in-band techniques serve to illustrate that uCDNs have >>>>> the option of enforcing some of their access control policies themsel= ves (at the expense of increased inter-CDN signaling load), >>>>> rather than delegating enforcement to dCDNs using the Metadata >>>>> interface. >>>>> " >>>>> (Rationale: the text is toned down a little bit because I think there= are shortcomings with that approach, such as difficulty in preventing repl= ays that bypass the access control policies) >>>>>=20 >>>>>=20 >>>>> OLD: >>>>> " >>>>> to express this its desire >>>>> " >>>>> NEW: >>>>> " >>>>> to express its desire >>>>> " >>>>>=20 >>>>> section 5: >>>>> OLD: >>>>> " >>>>> and that may other models >>>>> " >>>>> NEW: >>>>> " >>>>> and that many other models >>>>> " >>>>=20 >>>=20 >>=20 >=20 From Martin.Stiemerling@neclab.eu Mon Mar 11 13:38:17 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 E0C7D21F90B5 for ; Mon, 11 Mar 2013 13:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.608 X-Spam-Level: X-Spam-Status: No, score=-103.608 tagged_above=-999 required=5 tests=[AWL=-0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oh+w8EeAvJhM for ; Mon, 11 Mar 2013 13:38:17 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 484AF21F90B3 for ; Mon, 11 Mar 2013 13:38:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A93FA1036A2 for ; Mon, 11 Mar 2013 21:38:16 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVhsxYc0ivqd for ; Mon, 11 Mar 2013 21:38:16 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 8B1291036A0 for ; Mon, 11 Mar 2013 21:38:11 +0100 (CET) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 11 Mar 2013 21:37:28 +0100 Message-ID: <513E40AF.2080804@neclab.eu> Date: Mon, 11 Mar 2013 16:38:07 -0400 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: [CDNi] Looking for a new co-chair for the CDNI Working Group X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Martin Stiemerling 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, 11 Mar 2013 20:38:18 -0000 Hi all, The CDNI working group [1] is looking for a new working group co-chair. Rich Woundy is stepping down as co-chair by the end of the IETF-86 meeting. A big thank you to Rich for being co-chair since the establishment of the CDNI working group! If any of you is interested in co-chairing the CDNI WG, please send an email back to me in private. Thanks, Martin [1] http://datatracker.ietf.org/wg/cdni -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From ietf@meetecho.com Mon Mar 11 16:30: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 5834411E80D9 for ; Mon, 11 Mar 2013 16:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.497 X-Spam-Level: X-Spam-Status: No, score=-0.497 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IT=0.635, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYa8OhRGsOqO for ; Mon, 11 Mar 2013 16:30:36 -0700 (PDT) Received: from smtpdg8.aruba.it (unknown [62.149.158.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4297A11E80CC for ; Mon, 11 Mar 2013 16:30:35 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd03.ad.aruba.it with bizsmtp id APWX1l00D2w8SR601PWZs4; Tue, 12 Mar 2013 00:30:34 +0100 Date: Mon, 11 Mar 2013 19:30:30 -0400 (EDT) From: Meetecho Team To: cdni@ietf.org Message-ID: <860069.1.1363044630199.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_5143025.1363044630154" Subject: [CDNi] Meetecho support for CDNI WG session 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, 11 Mar 2013 23:30:37 -0000 ------=_Part_0_5143025.1363044630154 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the CDNI WG meeting session. Access to the on-line session (including audio and video streams) will be made available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/cdni The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_5143025.1363044630154-- From flefauch@cisco.com Tue Mar 12 06:35:14 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 479BD21F89D7 for ; Tue, 12 Mar 2013 06:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 tLHS3UzH3mhe for ; Tue, 12 Mar 2013 06:35:13 -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 A346F21F89CB for ; Tue, 12 Mar 2013 06:35:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1144; q=dns/txt; s=iport; t=1363095313; x=1364304913; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=sBb70Mrtq0il7+gGj3/xPSRPz3ThCD9WetuBG9UsP6k=; b=L3VDFwdpEMTzFrGjojE9Zzgy+43TT+lFRoPsB6tGL3x6OmhfMH3zKSi3 9k8lGfbKY8PB4e4mXtH8GMNhoi7ETJcrmAxGlMZAf/a0hhC6ZDJxvp+tK lR3wvCRluRnpXpES99YBmhqmpRvWIsq7ICiugmxNuL3BVIMriIa+MvtoJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAM0uP1GtJV2c/2dsb2JhbABDxGWBShZtB4IoAQEBBDpPAgEIGAoUEDIlAgQTCBOHebA0kAYXjloCOIJfYQOnTIMKgig X-IronPort-AV: E=Sophos;i="4.84,830,1355097600"; d="scan'208";a="186503098" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 12 Mar 2013 13:35:13 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2CDZDAQ012541 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Mar 2013 13:35:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 08:35:13 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Informal meeting on cdni-logging : Today at 1:00pm Thread-Index: AQHOHyZsL72D60WVgU+1o6FrEfLhXQ== Date: Tue, 12 Mar 2013 13:35:12 +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.61.103.20] Content-Type: text/plain; charset="us-ascii" Content-ID: <09B14A8807191C40B85DB19E59A6A1DF@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Informal meeting on cdni-logging : Today at 1:00pm 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, 12 Mar 2013 13:35:14 -0000 Folks, Just a friendly reminder: On 7 Mar 2013, at 09:32, Francois Le Faucheur (flefauch) wrote: >=20 > We'd like to run an informal open meeting around cdni-logging while in Or= lando. >=20 > We've selected: > * Tuesday 1:00 pm local time,=20 > * get together at the IETF Registration desk.=20 > So please put that in your calendar if you're interested in the cdni-logg= ing work. >=20 > Pretty flexible agenda but should include: > * review of candidate logging fields + which is mandatory/optional/mot-n= eeded for delivery records > * how hard should we try to make the non-real-time logging solution comp= atible/extensible to real-time logging? in other words, should we first jus= t specify a very simple file based exchange of log records for non-real-tim= e, and then accept that we may not be able to leverage much of that when tr= ying to move to real-time logging? > * log records formats/syntax > * whatever you'd like to discuss >=20 > Obviously the cdni-logging draft will still be discussed formally in the = CDNI WG session. >=20 > Cheers >=20 > Francois & Iuniana From flefauch@cisco.com Tue Mar 12 07:07:49 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 799A321F8AD4 for ; Tue, 12 Mar 2013 07:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.16 X-Spam-Level: X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=0.439, 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 aAYWtoIlPza2 for ; Tue, 12 Mar 2013 07:07:48 -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 1E6B521F8A5F for ; Tue, 12 Mar 2013 07:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14837; q=dns/txt; s=iport; t=1363097268; x=1364306868; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=F2x+MevEAnsmqMLob7AS/zDQlYlA/9Yl4khYB3zm8nU=; b=j0GJRI7WY4LLOPdINUz3+232cVr+tXuvDZ6PnZ3yvxI4Sm1EykPPk+IQ pNZnZXc4TZAj1d6wro95pr34S56btahtdAp5YrBw5+VdR5rahcZHE5nLU xCNtjvwPMTCXoljr4Nm3+y83WNyLqdQHpHLPgrOZzE5JzorkOZcIVO7vF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFADM2P1GtJV2Z/2dsb2JhbABDhTm/KoFHFnSCKAEBAQMBAQEBNzQCBAUFBwQCAQgRBAEBCxQJBycLFAkIAgQKBAUIARKHcwYHBbBGkAMXjU0VeAImCwcGgllhA5d1j1eDCoFrAR4BHQ X-IronPort-AV: E=Sophos;i="4.84,830,1355097600"; d="scan'208";a="186539213" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 12 Mar 2013 14:07:47 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2CE7lR4007606 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Mar 2013 14:07:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 09:07:47 -0500 From: "Francois Le Faucheur (flefauch)" To: "Kent Leung (kleung)" Thread-Topic: [CDNi] draft-ietf-cdni-requirements-05.txt Thread-Index: AQHOHyr49FDfcqspjU2CJ/jyOXsSbw== Date: Tue, 12 Mar 2013 14:07:46 +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.61.103.20] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:07:49 -0000 Kent and all, I have received consistent feed-back from two CDN operators and a Content P= rovider that the CDNI solution ought to support: *A* enforcement of caching directives by dCDN that are different to the on= es signalled in the HTTP headers *B* choice of ignoring/factoring query string in dCDN caching *C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive Downloa= d)=20 *A* and *B* are already mostly covered in META-18 but it is listed as [LOW]= . I would recommend we raise META-18 to [MED]. I don't think *C* is covered. I would recommend we add rate-pacing as a 3rd= example of "surrogate cache behaviour" in META-18.=20 I will bring this up in the CDNI session today, but wanted to give folks so= me heads-up. I also have other comments on -05 which I will either pass on to Kent direc= tly or post on the list. Cheers Francois " META-18 [LOW] The CDNI Metadata Distribution interface may allow signaling of CDNI-relevant surrogate cache behavior parameters. For example, this could potentially include: * control of whether the query string of HTTP URI is to be ignored by surrogate cache * content revalidation parameters (e.g. TTL) " On 6 Mar 2013, at 18:08, Kent Leung (kleung) wrote: > Hi folks. The requirements draft was updated based on the feedback from t= he authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), dr= aft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-loggin= g. >=20 > In preparation for the next WG session, the edits were published in the d= raft for review. Please provide your comments to the list of requirement ch= anges below. Thanks. >=20 > 1. New CDNI Control Interface requirement >=20 > a. Based on recommendations in ID-HAS, CCID is introduced for HAS= content without the need for HAS-aware CDN. >=20 > CNTL-12 [MED] The CDNI Control interface should allow for multip= le=09 > content items identified by a Content Collection ID to be=09 > purged using a single Content Purge action. >=20 > 2. New CDNI Request Routing Interface requirements >=20 > a. This is an explicit requirement for RRI to support per-chunk = request routing. Since the chunk is same as any content, it's not clear if = the requirement is needed? >=20 > REQ-15 [HIGH] The CDNI Request-Routing interface shall allow fo= r=09 > per-chunk request routing of HTTP Adaptive Streaming content.= =09 > [Ed: chunk is treated as any content, is this needed?]=09 > =09 > b. Manifest rewrite by uCDN is considered as optional feature in= the ID-HAS, should the priority be LOW instead of MED? >=20 > REQ-16 [MED] The CDNI Request-Routing interface should allow th= e=09 > Upstream CDN to use the information conveyed by the=09 > Downstream CDN during the Recursive Request Routing process=09 > to rewrite an HTTP Adaptive Streaming manifest file. [Ed:=09 > should this be LOW?]=09 >=20 > c. Manifest rewrite by uCDN for URI Signing is considered as op= tional feature in the ID-HAS, should the priority be LOW instead of MED? > =09 > REQ-17 [MED] The CDNI Request-Routing interface should allow t= he=09 > Upstream CDN to re-sign the invariant portion of the chunk=09 > URIs embedded in the HTTP Adaptive Streaming manifest file.=09 > [Ed: should this be LOW?]=09 > =09 > d. Use of cookie for URI Signing is is considered as optional fe= ature in the ID-HAS, should the priority be LOW instead of MED? >=20 > REQ-18 [MED] The CDNI Request-routing interface should allow th= e use=09 > of HTTP cookie to associate the chunks with the HTTP Adaptive= =09 > Stream manifest file (which is verified by the URI signature)= =09 > basedon the Authorization Group ID (which is an identifier=09 > used to correlate the manifest file to the related chunks).=09 > [Ed: should this be LOW?]=09 >=20 > e. LOW instead of MED priority?=09 >=20 > REQ-19 [MED] The CDNI Request-Routing interface may allow for a= n=09 > efficient method of transferring request routing information= =09 > for multiple chunks from the Downstream CDN to the Upstream=09 > CDN as part of the recursive request routing process. [Ed:=09 > should this be LOW?]=09 > =09 > f. Based on ID-HAS and logging drafts, the following requirement= was introduced to log HAS content and customization of the logging. > =09 > REQ-20 [MED] The CDNI Request-Routing/Footprint and Advertising= =09 > interface shall support advertisement of the following=09 > capabilities:=09 > =09 > * support for customized CDNI Logging=09 > =09 > * support of Content Collection ID logging=09 > =09 > * support for Session ID logging >=20 > 3. Removed CDNI Metadata Distribution Interface requirement. >=20 > a. Based on the metadata draft, there is no need for dCDN to ind= icate to the uCDN the result of delivering the metadata since the "pull" or= "triggered pull" model is used (i.e. dCDN request for metadata from uCDN). >=20 > META-13 [HIGH] The CDNI Metadata Distribution interface shall =09 > provide indication by the Downstream CDN to the Upstream CDN = =09 > of whether the CDNI metadata (and corresponding future =09 > request redirections) is accepted or rejected. When =09 > rejected, the CDNI Metadata Distribution protocol Must allow = =09 > the Downstream CDN to provide information about the cause of = =09 > the rejection. =09 >=20 > 4. New CDNI Metadata Distribution Interface requirements >=20 > a. Based on ID-HAS's recommendations, this is introduced. >=20 > META-19 [HIGH] The CDNI Metadata interface shall provide indicati= on=09 > of related content (e.g. HTTP Adaptive Bit Rate chunks) by= =09 > the Content Collection ID (CCID) metadata. This could be=09 > used by the Downstream CDN for operations on the group of=09 > content. For example, this could potentially include:=09 > =09 > * content acquisition for the entire set of files when one= =09 > piece of content is requested=09 > =09 > * local file management and storage bundles all the files= =09 > for the content=09 > =09 > * purging the entire set of files associated with the=09 > content=09 > =09 > * logging of the delivery of the content for the session=09 > when at least one file in the set was delivered=09 > =09 > b. Based on the logging draft, this is introduced. >=20 > META-20 [HIGH] The CDNI Metadata Distribution interface shall=09 > support an OPTIONAL mechanism allowing the Upstream CDN to=09 > indicate to the Downstream CDN which CDNI Log fields are to= =09 > be provided for all, for specific sets of, or for specific=09 > content items delivered using HTTP. A CDNI implementation=09 > that does not support this optional CDNI Metadata=09 > Distribution Interface mechanism MUST ignore this log format= =09 > indication and generate CDNI logging format for HTTP=09 > Adaptive Streaming using the default set of CDNI Logging=09 > fields.=09 > =09 > c. Based on the ID-HAS's recommendations, this is introduced. >=20 > META-21 [MED] The CDNI Metadata Distribution interface shall allo= w=09 > the Upstream CDN to signal to the Downstream CDN the Content= =09 > Collection ID value for all, for specific sets of, or for=09 > specific content items delivered using HTTP. Whenever the=09 > Downstream CDN is instructed by the Upstream CDN to report=09 > the Content Collection ID field in the log records, the=09 > Downstream CDN is to use the value provided through the CDNI= =09 > Metadata interface for the corresponding content. Note the= =09 > Session ID field along with Content Collection ID may be=09 > used for HTTP Adaptive Streaming content.=09 > =09 > d. Based on ID-HAS's recommendations, this is introduced. >=20 > META-22 [MED] The CDNI Metadata Distribution interface shall allo= w=09 > the Upstream CDN to signal to the Downstream CDN the=09 > Authorization Group ID value for all the related HTTP=09 > Adaptive Streamin content (i.e. manifest file and chunks).=09 > The authorization result of a content (e.g. manifest file)=09 > is transferred over to related content (e.g. chunks). [Ed:= =09 > need to improve wording?] >=20 > 5. Remove CDNI Logging Interface requirement >=20 > a. It is deemed unnecessary for dCDN to obtain logs from uCDN, whi= ch has access to all the logs for trouble-shooting and auditing. >=20 > LOG-4 [HIGH] The CDNI Logging interface shall provide logging of =09 > distribution performed by the Upstream CDN as a result of =09 > acquisition request by the Downstream CDN. >=20 > 6. Add CDNI Logging Interface requirements >=20 > a. Based on the logging draft, this is introduced. >=20 > LOG-17 [HIGH] The CDNI Logging interface shall support the=09 > notification from Downstream CDN to Upstream CDN for the=09 > event that the logging retention duration or maximum size of= =09 > logging data has exceeded.=09 > =09 > b. Based on the ID-HAS, CCID is a field to report in the log. Al= so, based on the logging draft, Session ID is another field needed in the l= og. >=20 > LOG-18 [MED] The CDNI Logging interface should support the abil= ity=09 > for the Downstream CDN to include the Content Collection ID=09 > and Session ID fields in CDNI log entries generated for HTTP= =09 > Adaptive Streaming content. This fields can be supported by= =09 > the "customizable" log format which is expected to be defined= =09 > independently of HTTP Adaptive Streaming. >=20 > Kent >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Saturday, February 23, 2013 1:16 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt >=20 >=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 : Content Distribution Network Interconnection (CDNI) Re= quirements > Author(s) : Kent Leung > Yiu Lee > Filename : draft-ietf-cdni-requirements-05.txt > Pages : 23 > Date : 2013-02-23 >=20 > Abstract: > Content Delivery Networks (CDNs) are frequently used for large-scale > content delivery. As a result, existing CDN providers are scaling up > their infrastructure and many Network Service Providers (NSPs) are > deploying their own CDNs. There is a requirement for interconnecting > standalone CDNs so that their collective CDN footprint can be > leveraged for the end-to-end delivery of content from Content Service > Providers (CSPs) to end users. The Content Distribution Network > Interconnection (CDNI) working group has been chartered to develop an > interoperable and scalable solution for such CDN interconnection. >=20 > The goal of the present document is to outline the requirements for > the solution and interfaces to be specified by the CDNI working > group. This draft is a work in progress and requirements may be > added, modified, or removed by the working group. >=20 > Requirements Language >=20 > The key words "High Priority", "Medium Priority" and "Low Priority" > in this document are to be interpreted in the following way: >=20 > o "High Priority" indicates requirements that are to be supported by > the CDNI interfaces. A requirement is stated as "High Priority" > when it is established by the working group that it can be met > without compromising the targeted schedule for WG deliverables, or > when it is established that specifying a solution without meeting > this requirement would not make sense and would justify re- > adjusting the WG schedule, or both. This is tagged as "[HIGH]". >=20 > o "Medium Priority" indicates requirements that are to be supported > by the CDNI interfaces unless the WG realizes at a later stage > that attempting to meet this requirement would compromise the > overall WG schedule (for example it would involve complexities > that would result in significantly delaying the deliverables). > This is tagged as "[MED]". >=20 > o "Low Priority" indicates requirements that are to be supported by > the CDNI interfaces provided that dedicating WG resources to this > work does not prevent addressing "High Priority" and "Medium > Priority" requirements and that attempting to meet this > requirement would not compromise the overall WG schedule. This is > tagged as "[LOW]". >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-requirements-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From oran@cisco.com Tue Mar 12 07:19:13 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 81C0F21F8B4C for ; Tue, 12 Mar 2013 07:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUU+o1quymke for ; Tue, 12 Mar 2013 07:19:12 -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 DD09321F8B4A for ; Tue, 12 Mar 2013 07:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15944; q=dns/txt; s=iport; t=1363097952; x=1364307552; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=qcFk2z0HrWORjBOCmskg/Jt3dy6XDRPMA2HPQFoI/1c=; b=TZbQJfU9VDhAeeqksUat/cuAsJW1MYIclZpPVPMdheFdSslITveWQoVW sxvNtvVysY+30l7tzAjoSoB9RRmXDGnRVqnk44FsCcJPCXTUXfaI1E6jg RHRAW9Ecti6y0iEhgd+esuquwvT88T1vc/LucnRhNgfnneUP1wkTcHaW6 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAA45P1GtJXG9/2dsb2JhbABDhTm/KoFHFnSCKAEBAQMBAQEBawIEBQUHBAIBCBEEAQEBCh0HJwsUCQgCBAoEBQgBEodzBgcFsESPexeNTQoLeAImCwcGgllhA4g9jziPV4MKgWsBHgEd X-IronPort-AV: E=Sophos;i="4.84,830,1355097600"; d="scan'208";a="186522598" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 12 Mar 2013 14:19:00 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2CEJ0Oo013756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Mar 2013 14:19:00 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.152]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 09:18:59 -0500 From: "Dave Oran (oran)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] draft-ietf-cdni-requirements-05.txt Thread-Index: AQHOHyr49FDfcqspjU2CJ/jyOXsSb5iibo0A Date: Tue, 12 Mar 2013 14:18:59 +0000 Message-ID: <61A34E1FA77BE74E886859A389603E7F3E364BFB@xmb-rcd-x01.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.104.186] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <85FA834DAF5175468DAAFDAC980D2CF9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:19:13 -0000 On Mar 12, 2013, at 10:07 AM, "Francois Le Faucheur (flefauch)" wrote: > Kent and all, >=20 > I have received consistent feed-back from two CDN operators and a Content= Provider that the CDNI solution ought to support: > *A* enforcement of caching directives by dCDN that are different to the = ones signalled in the HTTP headers > *B* choice of ignoring/factoring query string in dCDN caching > *C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive Downl= oad)=20 >=20 Stupid na=EFve question. Why should an uCDN care if a dCDN decides to provi= de better/faster service by allowing higher download rates if it wants? The= uCDN can always himself rate limit how fast it primes the dCDN caches if i= t want to protect its own peak-rate service resources. I can see the converse - that the uCDN may want via service contract to hav= e the dCDN support certain minimum rates and *not* arbitrarily rate limit t= he customers of the uCDN. Is that was was intended by *C*? Enlightenment greatly appreciated. =20 > *A* and *B* are already mostly covered in META-18 but it is listed as [LO= W]. I would recommend we raise META-18 to [MED]. >=20 > I don't think *C* is covered. I would recommend we add rate-pacing as a 3= rd example of "surrogate cache behaviour" in META-18.=20 >=20 > I will bring this up in the CDNI session today, but wanted to give folks = some heads-up. >=20 > I also have other comments on -05 which I will either pass on to Kent dir= ectly or post on the list. >=20 > Cheers >=20 > Francois >=20 >=20 >=20 > " > META-18 [LOW] The CDNI Metadata Distribution interface may allow > signaling of CDNI-relevant surrogate cache behavior > parameters. For example, this could potentially include: >=20 > * control of whether the query string of HTTP URI is to be > ignored by surrogate cache >=20 > * content revalidation parameters (e.g. TTL) > " >=20 >=20 > On 6 Mar 2013, at 18:08, Kent Leung (kleung) wrote: >=20 >> Hi folks. The requirements draft was updated based on the feedback from = the authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), d= raft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-loggi= ng. >>=20 >> In preparation for the next WG session, the edits were published in the = draft for review. Please provide your comments to the list of requirement c= hanges below. Thanks. >>=20 >> 1. New CDNI Control Interface requirement >>=20 >> a. Based on recommendations in ID-HAS, CCID is introduced for HAS= content without the need for HAS-aware CDN. >>=20 >> CNTL-12 [MED] The CDNI Control interface should allow for multip= le=09 >> content items identified by a Content Collection ID to be=09 >> purged using a single Content Purge action. >>=20 >> 2. New CDNI Request Routing Interface requirements >>=20 >> a. This is an explicit requirement for RRI to support per-chunk = request routing. Since the chunk is same as any content, it's not clear if = the requirement is needed? >>=20 >> REQ-15 [HIGH] The CDNI Request-Routing interface shall allow fo= r=09 >> per-chunk request routing of HTTP Adaptive Streaming content= .=09 >> [Ed: chunk is treated as any content, is this needed?]=09 >> =09 >> b. Manifest rewrite by uCDN is considered as optional feature in= the ID-HAS, should the priority be LOW instead of MED? >>=20 >> REQ-16 [MED] The CDNI Request-Routing interface should allow th= e=09 >> Upstream CDN to use the information conveyed by the=09 >> Downstream CDN during the Recursive Request Routing process= =09 >> to rewrite an HTTP Adaptive Streaming manifest file. [Ed:=09 >> should this be LOW?]=09 >>=20 >> c. Manifest rewrite by uCDN for URI Signing is considered as op= tional feature in the ID-HAS, should the priority be LOW instead of MED? >> =09 >> REQ-17 [MED] The CDNI Request-Routing interface should allow t= he=09 >> Upstream CDN to re-sign the invariant portion of the chunk=09 >> URIs embedded in the HTTP Adaptive Streaming manifest file.= =09 >> [Ed: should this be LOW?]=09 >> =09 >> d. Use of cookie for URI Signing is is considered as optional fe= ature in the ID-HAS, should the priority be LOW instead of MED? >>=20 >> REQ-18 [MED] The CDNI Request-routing interface should allow th= e use=09 >> of HTTP cookie to associate the chunks with the HTTP Adaptiv= e=09 >> Stream manifest file (which is verified by the URI signature= )=09 >> basedon the Authorization Group ID (which is an identifier=09 >> used to correlate the manifest file to the related chunks).= =09 >> [Ed: should this be LOW?]=09 >>=20 >> e. LOW instead of MED priority?=09 >>=20 >> REQ-19 [MED] The CDNI Request-Routing interface may allow for a= n=09 >> efficient method of transferring request routing information= =09 >> for multiple chunks from the Downstream CDN to the Upstream= =09 >> CDN as part of the recursive request routing process. [Ed:= =09 >> should this be LOW?]=09 >> =09 >> f. Based on ID-HAS and logging drafts, the following requirement= was introduced to log HAS content and customization of the logging. >> =09 >> REQ-20 [MED] The CDNI Request-Routing/Footprint and Advertising= =09 >> interface shall support advertisement of the following=09 >> capabilities:=09 >> =09 >> * support for customized CDNI Logging=09 >> =09 >> * support of Content Collection ID logging=09 >> =09 >> * support for Session ID logging >>=20 >> 3. Removed CDNI Metadata Distribution Interface requirement. >>=20 >> a. Based on the metadata draft, there is no need for dCDN to ind= icate to the uCDN the result of delivering the metadata since the "pull" or= "triggered pull" model is used (i.e. dCDN request for metadata from uCDN). >>=20 >> META-13 [HIGH] The CDNI Metadata Distribution interface shall =09 >> provide indication by the Downstream CDN to the Upstream CDN = =09 >> of whether the CDNI metadata (and corresponding future =09 >> request redirections) is accepted or rejected. When =09 >> rejected, the CDNI Metadata Distribution protocol Must allow = =09 >> the Downstream CDN to provide information about the cause of = =09 >> the rejection. =09 >>=20 >> 4. New CDNI Metadata Distribution Interface requirements >>=20 >> a. Based on ID-HAS's recommendations, this is introduced. >>=20 >> META-19 [HIGH] The CDNI Metadata interface shall provide indicati= on=09 >> of related content (e.g. HTTP Adaptive Bit Rate chunks) by= =09 >> the Content Collection ID (CCID) metadata. This could be=09 >> used by the Downstream CDN for operations on the group of=09 >> content. For example, this could potentially include:=09 >> =09 >> * content acquisition for the entire set of files when on= e=09 >> piece of content is requested=09 >> =09 >> * local file management and storage bundles all the files= =09 >> for the content=09 >> =09 >> * purging the entire set of files associated with the=09 >> content=09 >> =09 >> * logging of the delivery of the content for the session= =09 >> when at least one file in the set was delivered=09 >> =09 >> b. Based on the logging draft, this is introduced. >>=20 >> META-20 [HIGH] The CDNI Metadata Distribution interface shall=09 >> support an OPTIONAL mechanism allowing the Upstream CDN to= =09 >> indicate to the Downstream CDN which CDNI Log fields are to= =09 >> be provided for all, for specific sets of, or for specific= =09 >> content items delivered using HTTP. A CDNI implementation= =09 >> that does not support this optional CDNI Metadata=09 >> Distribution Interface mechanism MUST ignore this log forma= t=09 >> indication and generate CDNI logging format for HTTP=09 >> Adaptive Streaming using the default set of CDNI Logging=09 >> fields.=09 >> =09 >> c. Based on the ID-HAS's recommendations, this is introduced. >>=20 >> META-21 [MED] The CDNI Metadata Distribution interface shall allo= w=09 >> the Upstream CDN to signal to the Downstream CDN the Conten= t=09 >> Collection ID value for all, for specific sets of, or for=09 >> specific content items delivered using HTTP. Whenever the= =09 >> Downstream CDN is instructed by the Upstream CDN to report= =09 >> the Content Collection ID field in the log records, the=09 >> Downstream CDN is to use the value provided through the CDN= I=09 >> Metadata interface for the corresponding content. Note the= =09 >> Session ID field along with Content Collection ID may be=09 >> used for HTTP Adaptive Streaming content.=09 >> =09 >> d. Based on ID-HAS's recommendations, this is introduced. >>=20 >> META-22 [MED] The CDNI Metadata Distribution interface shall allo= w=09 >> the Upstream CDN to signal to the Downstream CDN the=09 >> Authorization Group ID value for all the related HTTP=09 >> Adaptive Streamin content (i.e. manifest file and chunks).= =09 >> The authorization result of a content (e.g. manifest file)= =09 >> is transferred over to related content (e.g. chunks). [Ed:= =09 >> need to improve wording?] >>=20 >> 5. Remove CDNI Logging Interface requirement >>=20 >> a. It is deemed unnecessary for dCDN to obtain logs from uCDN, whi= ch has access to all the logs for trouble-shooting and auditing. >>=20 >> LOG-4 [HIGH] The CDNI Logging interface shall provide logging of =09 >> distribution performed by the Upstream CDN as a result of =09 >> acquisition request by the Downstream CDN. >>=20 >> 6. Add CDNI Logging Interface requirements >>=20 >> a. Based on the logging draft, this is introduced. >>=20 >> LOG-17 [HIGH] The CDNI Logging interface shall support the=09 >> notification from Downstream CDN to Upstream CDN for the=09 >> event that the logging retention duration or maximum size of= =09 >> logging data has exceeded.=09 >> =09 >> b. Based on the ID-HAS, CCID is a field to report in the log. Al= so, based on the logging draft, Session ID is another field needed in the l= og. >>=20 >> LOG-18 [MED] The CDNI Logging interface should support the abil= ity=09 >> for the Downstream CDN to include the Content Collection ID= =09 >> and Session ID fields in CDNI log entries generated for HTTP= =09 >> Adaptive Streaming content. This fields can be supported by= =09 >> the "customizable" log format which is expected to be define= d=09 >> independently of HTTP Adaptive Streaming. >>=20 >> Kent >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org >> Sent: Saturday, February 23, 2013 1:16 PM >> To: i-d-announce@ietf.org >> Cc: cdni@ietf.org >> Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Content Delivery Networks Interconnecti= on Working Group of the IETF. >>=20 >> Title : Content Distribution Network Interconnection (CDNI) R= equirements >> Author(s) : Kent Leung >> Yiu Lee >> Filename : draft-ietf-cdni-requirements-05.txt >> Pages : 23 >> Date : 2013-02-23 >>=20 >> Abstract: >> Content Delivery Networks (CDNs) are frequently used for large-scale >> content delivery. As a result, existing CDN providers are scaling up >> their infrastructure and many Network Service Providers (NSPs) are >> deploying their own CDNs. There is a requirement for interconnecting >> standalone CDNs so that their collective CDN footprint can be >> leveraged for the end-to-end delivery of content from Content Service >> Providers (CSPs) to end users. The Content Distribution Network >> Interconnection (CDNI) working group has been chartered to develop an >> interoperable and scalable solution for such CDN interconnection. >>=20 >> The goal of the present document is to outline the requirements for >> the solution and interfaces to be specified by the CDNI working >> group. This draft is a work in progress and requirements may be >> added, modified, or removed by the working group. >>=20 >> Requirements Language >>=20 >> The key words "High Priority", "Medium Priority" and "Low Priority" >> in this document are to be interpreted in the following way: >>=20 >> o "High Priority" indicates requirements that are to be supported by >> the CDNI interfaces. A requirement is stated as "High Priority" >> when it is established by the working group that it can be met >> without compromising the targeted schedule for WG deliverables, or >> when it is established that specifying a solution without meeting >> this requirement would not make sense and would justify re- >> adjusting the WG schedule, or both. This is tagged as "[HIGH]". >>=20 >> o "Medium Priority" indicates requirements that are to be supported >> by the CDNI interfaces unless the WG realizes at a later stage >> that attempting to meet this requirement would compromise the >> overall WG schedule (for example it would involve complexities >> that would result in significantly delaying the deliverables). >> This is tagged as "[MED]". >>=20 >> o "Low Priority" indicates requirements that are to be supported by >> the CDNI interfaces provided that dedicating WG resources to this >> work does not prevent addressing "High Priority" and "Medium >> Priority" requirements and that attempting to meet this >> requirement would not compromise the overall WG schedule. This is >> tagged as "[LOW]". >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-cdni-requirements-05 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-05 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Tue Mar 12 07:28: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 603C521F8B14 for ; Tue, 12 Mar 2013 07:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.522 X-Spam-Level: X-Spam-Status: No, score=-10.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 JNsVyypQ9DMN for ; Tue, 12 Mar 2013 07:28:44 -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 9F6F421F87CE for ; Tue, 12 Mar 2013 07:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17318; q=dns/txt; s=iport; t=1363098524; x=1364308124; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RLaSEUWdRRdfAP+XRofzQ/WOaoxO5/4b+Sdj/S7D6zU=; b=WQPyTBpezJC+/vED5RU91tALwJCciP0H4SsgyYxL80s31vnQCYYmkaKK R0QjUoFfRCmIYiWOJqgMM7g6HcASl2doJPFioHnb1K5LkyPmvDsMUQC85 POVPLNYZiSCbt9cRLBIBVBym/Q2l/cm6b6CZlafHrjzh/bhBx178ERnq+ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAGI6P1GtJV2a/2dsb2JhbABDhTm/KoFHFnSCKAEBAQMBAQEBJEcCBAUFBwQCAQgRBAEBAQodBycLFAkIAgQKBAUIARKHcwYHBbBKj3gXjU0KC3gCJgsHBoJZYQOIPY84j1eDCoFrAR4BHQ X-IronPort-AV: E=Sophos;i="4.84,830,1355097600"; d="scan'208";a="186338007" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 12 Mar 2013 14:28:43 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2CEShYL029025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Mar 2013 14:28:43 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 09:28:43 -0500 From: "Francois Le Faucheur (flefauch)" To: "Dave Oran (oran)" Thread-Topic: [CDNi] draft-ietf-cdni-requirements-05.txt Thread-Index: AQHOHyr49FDfcqspjU2CJ/jyOXsSb5iibo0AgAACt4A= Date: Tue, 12 Mar 2013 14:28:43 +0000 Message-ID: References: <61A34E1FA77BE74E886859A389603E7F3E364BFB@xmb-rcd-x01.cisco.com> In-Reply-To: <61A34E1FA77BE74E886859A389603E7F3E364BFB@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.103.20] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2D212ACD4D09834E9DFA09EF5E602A10@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 14:28:46 -0000 Hello Dave, On 12 Mar 2013, at 10:18, "Dave Oran (oran)" wrote: >=20 > On Mar 12, 2013, at 10:07 AM, "Francois Le Faucheur (flefauch)" > wrote: >=20 >> Kent and all, >>=20 >> I have received consistent feed-back from two CDN operators and a Conten= t Provider that the CDNI solution ought to support: >> *A* enforcement of caching directives by dCDN that are different to the= ones signalled in the HTTP headers >> *B* choice of ignoring/factoring query string in dCDN caching >> *C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive Down= load)=20 >>=20 > Stupid na=EFve question. Why should an uCDN care if a dCDN decides to pro= vide better/faster service by allowing higher download rates if it wants? T= he uCDN can always himself rate limit how fast it primes the dCDN caches if= it want to protect its own peak-rate service resources. The motivation is that some Content Providers want to minimise their delive= ry costs (and hence minimise the volume and/or peak streaming rate, dependi= ng on what metric they are charged on) when the users are only watching the= first parts of a piece of content, which, as we know is common behaviour. = So the Content Provider is asking the authoritative CDN (who then needs to = ask its dCDNs) to only start to stream the content at the "necessary" rate = (i.e. something marginally higher than playrate). If the user switches to s= ome other content, the Content Provider only gets charged for marginally mo= re than what was viewed. >=20 > I can see the converse - that the uCDN may want via service contract to h= ave the dCDN support certain minimum rates and *not* arbitrarily rate limit= the customers of the uCDN. I can see that too. But I'd expect that to happen mostly at the Business la= yer initially. I can see a few cases where you might want to signal some in= formation uCDN-->dCDN and have dCDN take actions about it, but that seems m= ore sophisticated than what we are focusing on in initial scope. > Is that was was intended by *C*? >=20 > Enlightenment greatly appreciated. Are you feeling enlightened or darkened? Francois >=20 >=20 >> *A* and *B* are already mostly covered in META-18 but it is listed as [L= OW]. I would recommend we raise META-18 to [MED]. >>=20 >> I don't think *C* is covered. I would recommend we add rate-pacing as a = 3rd example of "surrogate cache behaviour" in META-18.=20 >>=20 >> I will bring this up in the CDNI session today, but wanted to give folks= some heads-up. >>=20 >> I also have other comments on -05 which I will either pass on to Kent di= rectly or post on the list. >>=20 >> Cheers >>=20 >> Francois >>=20 >>=20 >>=20 >> " >> META-18 [LOW] The CDNI Metadata Distribution interface may allow >> signaling of CDNI-relevant surrogate cache behavior >> parameters. For example, this could potentially include: >>=20 >> * control of whether the query string of HTTP URI is to be >> ignored by surrogate cache >>=20 >> * content revalidation parameters (e.g. TTL) >> " >>=20 >>=20 >> On 6 Mar 2013, at 18:08, Kent Leung (kleung) wrote: >>=20 >>> Hi folks. The requirements draft was updated based on the feedback from= the authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), = draft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-logg= ing. >>>=20 >>> In preparation for the next WG session, the edits were published in the= draft for review. Please provide your comments to the list of requirement = changes below. Thanks. >>>=20 >>> 1. New CDNI Control Interface requirement >>>=20 >>> a. Based on recommendations in ID-HAS, CCID is introduced for HAS= content without the need for HAS-aware CDN. >>>=20 >>> CNTL-12 [MED] The CDNI Control interface should allow for multip= le=09 >>> content items identified by a Content Collection ID to be= =09 >>> purged using a single Content Purge action. >>>=20 >>> 2. New CDNI Request Routing Interface requirements >>>=20 >>> a. This is an explicit requirement for RRI to support per-chunk = request routing. Since the chunk is same as any content, it's not clear if = the requirement is needed? >>>=20 >>> REQ-15 [HIGH] The CDNI Request-Routing interface shall allow fo= r=09 >>> per-chunk request routing of HTTP Adaptive Streaming conten= t.=09 >>> [Ed: chunk is treated as any content, is this needed?]=09 >>> =09 >>> b. Manifest rewrite by uCDN is considered as optional feature in= the ID-HAS, should the priority be LOW instead of MED? >>>=20 >>> REQ-16 [MED] The CDNI Request-Routing interface should allow th= e=09 >>> Upstream CDN to use the information conveyed by the=09 >>> Downstream CDN during the Recursive Request Routing process= =09 >>> to rewrite an HTTP Adaptive Streaming manifest file. [Ed:= =09 >>> should this be LOW?]=09 >>>=20 >>> c. Manifest rewrite by uCDN for URI Signing is considered as op= tional feature in the ID-HAS, should the priority be LOW instead of MED? >>> =09 >>> REQ-17 [MED] The CDNI Request-Routing interface should allow t= he=09 >>> Upstream CDN to re-sign the invariant portion of the chunk= =09 >>> URIs embedded in the HTTP Adaptive Streaming manifest file.= =09 >>> [Ed: should this be LOW?]=09 >>> =09 >>> d. Use of cookie for URI Signing is is considered as optional fe= ature in the ID-HAS, should the priority be LOW instead of MED? >>>=20 >>> REQ-18 [MED] The CDNI Request-routing interface should allow th= e use=09 >>> of HTTP cookie to associate the chunks with the HTTP Adapti= ve=09 >>> Stream manifest file (which is verified by the URI signatur= e)=09 >>> basedon the Authorization Group ID (which is an identifier= =09 >>> used to correlate the manifest file to the related chunks).= =09 >>> [Ed: should this be LOW?]=09 >>>=20 >>> e. LOW instead of MED priority?=09 >>>=20 >>> REQ-19 [MED] The CDNI Request-Routing interface may allow for a= n=09 >>> efficient method of transferring request routing informatio= n=09 >>> for multiple chunks from the Downstream CDN to the Upstream= =09 >>> CDN as part of the recursive request routing process. [Ed:= =09 >>> should this be LOW?]=09 >>> =09 >>> f. Based on ID-HAS and logging drafts, the following requirement= was introduced to log HAS content and customization of the logging. >>> =09 >>> REQ-20 [MED] The CDNI Request-Routing/Footprint and Advertising= =09 >>> interface shall support advertisement of the following=09 >>> capabilities:=09 >>> =09 >>> * support for customized CDNI Logging=09 >>> =09 >>> * support of Content Collection ID logging=09 >>> =09 >>> * support for Session ID logging >>>=20 >>> 3. Removed CDNI Metadata Distribution Interface requirement. >>>=20 >>> a. Based on the metadata draft, there is no need for dCDN to ind= icate to the uCDN the result of delivering the metadata since the "pull" or= "triggered pull" model is used (i.e. dCDN request for metadata from uCDN). >>>=20 >>> META-13 [HIGH] The CDNI Metadata Distribution interface shall =09 >>> provide indication by the Downstream CDN to the Upstream CDN = =09 >>> of whether the CDNI metadata (and corresponding future =09 >>> request redirections) is accepted or rejected. When =09 >>> rejected, the CDNI Metadata Distribution protocol Must allow = =09 >>> the Downstream CDN to provide information about the cause of = =09 >>> the rejection. =09 >>>=20 >>> 4. New CDNI Metadata Distribution Interface requirements >>>=20 >>> a. Based on ID-HAS's recommendations, this is introduced. >>>=20 >>> META-19 [HIGH] The CDNI Metadata interface shall provide indicati= on=09 >>> of related content (e.g. HTTP Adaptive Bit Rate chunks) b= y=09 >>> the Content Collection ID (CCID) metadata. This could be= =09 >>> used by the Downstream CDN for operations on the group of= =09 >>> content. For example, this could potentially include:=09 >>> =09 >>> * content acquisition for the entire set of files when o= ne=09 >>> piece of content is requested=09 >>> =09 >>> * local file management and storage bundles all the file= s=09 >>> for the content=09 >>> =09 >>> * purging the entire set of files associated with the=09 >>> content=09 >>> =09 >>> * logging of the delivery of the content for the session= =09 >>> when at least one file in the set was delivered=09 >>> =09 >>> b. Based on the logging draft, this is introduced. >>>=20 >>> META-20 [HIGH] The CDNI Metadata Distribution interface shall=09 >>> support an OPTIONAL mechanism allowing the Upstream CDN to= =09 >>> indicate to the Downstream CDN which CDNI Log fields are t= o=09 >>> be provided for all, for specific sets of, or for specific= =09 >>> content items delivered using HTTP. A CDNI implementation= =09 >>> that does not support this optional CDNI Metadata=09 >>> Distribution Interface mechanism MUST ignore this log form= at=09 >>> indication and generate CDNI logging format for HTTP=09 >>> Adaptive Streaming using the default set of CDNI Logging=09 >>> fields.=09 >>> =09 >>> c. Based on the ID-HAS's recommendations, this is introduced. >>>=20 >>> META-21 [MED] The CDNI Metadata Distribution interface shall allo= w=09 >>> the Upstream CDN to signal to the Downstream CDN the Conte= nt=09 >>> Collection ID value for all, for specific sets of, or for= =09 >>> specific content items delivered using HTTP. Whenever the= =09 >>> Downstream CDN is instructed by the Upstream CDN to report= =09 >>> the Content Collection ID field in the log records, the=09 >>> Downstream CDN is to use the value provided through the CD= NI=09 >>> Metadata interface for the corresponding content. Note th= e=09 >>> Session ID field along with Content Collection ID may be=09 >>> used for HTTP Adaptive Streaming content.=09 >>> =09 >>> d. Based on ID-HAS's recommendations, this is introduced. >>>=20 >>> META-22 [MED] The CDNI Metadata Distribution interface shall allo= w=09 >>> the Upstream CDN to signal to the Downstream CDN the=09 >>> Authorization Group ID value for all the related HTTP=09 >>> Adaptive Streamin content (i.e. manifest file and chunks).= =09 >>> The authorization result of a content (e.g. manifest file)= =09 >>> is transferred over to related content (e.g. chunks). [Ed= :=09 >>> need to improve wording?] >>>=20 >>> 5. Remove CDNI Logging Interface requirement >>>=20 >>> a. It is deemed unnecessary for dCDN to obtain logs from uCDN, whi= ch has access to all the logs for trouble-shooting and auditing. >>>=20 >>> LOG-4 [HIGH] The CDNI Logging interface shall provide logging of =09 >>> distribution performed by the Upstream CDN as a result of =09 >>> acquisition request by the Downstream CDN. >>>=20 >>> 6. Add CDNI Logging Interface requirements >>>=20 >>> a. Based on the logging draft, this is introduced. >>>=20 >>> LOG-17 [HIGH] The CDNI Logging interface shall support the=09 >>> notification from Downstream CDN to Upstream CDN for the=09 >>> event that the logging retention duration or maximum size o= f=09 >>> logging data has exceeded.=09 >>> =09 >>> b. Based on the ID-HAS, CCID is a field to report in the log. Al= so, based on the logging draft, Session ID is another field needed in the l= og. >>>=20 >>> LOG-18 [MED] The CDNI Logging interface should support the abil= ity=09 >>> for the Downstream CDN to include the Content Collection ID= =09 >>> and Session ID fields in CDNI log entries generated for HTT= P=09 >>> Adaptive Streaming content. This fields can be supported b= y=09 >>> the "customizable" log format which is expected to be defin= ed=09 >>> independently of HTTP Adaptive Streaming. >>>=20 >>> Kent >>>=20 >>> -----Original Message----- >>> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of= internet-drafts@ietf.org >>> Sent: Saturday, February 23, 2013 1:16 PM >>> To: i-d-announce@ietf.org >>> Cc: cdni@ietf.org >>> Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. >>> This draft is a work item of the Content Delivery Networks Interconnect= ion Working Group of the IETF. >>>=20 >>> Title : Content Distribution Network Interconnection (CDNI) = Requirements >>> Author(s) : Kent Leung >>> Yiu Lee >>> Filename : draft-ietf-cdni-requirements-05.txt >>> Pages : 23 >>> Date : 2013-02-23 >>>=20 >>> Abstract: >>> Content Delivery Networks (CDNs) are frequently used for large-scale >>> content delivery. As a result, existing CDN providers are scaling up >>> their infrastructure and many Network Service Providers (NSPs) are >>> deploying their own CDNs. There is a requirement for interconnecting >>> standalone CDNs so that their collective CDN footprint can be >>> leveraged for the end-to-end delivery of content from Content Service >>> Providers (CSPs) to end users. The Content Distribution Network >>> Interconnection (CDNI) working group has been chartered to develop an >>> interoperable and scalable solution for such CDN interconnection. >>>=20 >>> The goal of the present document is to outline the requirements for >>> the solution and interfaces to be specified by the CDNI working >>> group. This draft is a work in progress and requirements may be >>> added, modified, or removed by the working group. >>>=20 >>> Requirements Language >>>=20 >>> The key words "High Priority", "Medium Priority" and "Low Priority" >>> in this document are to be interpreted in the following way: >>>=20 >>> o "High Priority" indicates requirements that are to be supported by >>> the CDNI interfaces. A requirement is stated as "High Priority" >>> when it is established by the working group that it can be met >>> without compromising the targeted schedule for WG deliverables, or >>> when it is established that specifying a solution without meeting >>> this requirement would not make sense and would justify re- >>> adjusting the WG schedule, or both. This is tagged as "[HIGH]". >>>=20 >>> o "Medium Priority" indicates requirements that are to be supported >>> by the CDNI interfaces unless the WG realizes at a later stage >>> that attempting to meet this requirement would compromise the >>> overall WG schedule (for example it would involve complexities >>> that would result in significantly delaying the deliverables). >>> This is tagged as "[MED]". >>>=20 >>> o "Low Priority" indicates requirements that are to be supported by >>> the CDNI interfaces provided that dedicating WG resources to this >>> work does not prevent addressing "High Priority" and "Medium >>> Priority" requirements and that attempting to meet this >>> requirement would not compromise the overall WG schedule. This is >>> tagged as "[LOW]". >>>=20 >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements >>>=20 >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-cdni-requirements-05 >>>=20 >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-05 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From kleung@cisco.com Tue Mar 12 09:54: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 977BF21F8B13 for ; Tue, 12 Mar 2013 09:54:10 -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 71qVdf4eQGAZ for ; Tue, 12 Mar 2013 09:54:02 -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 90E9221F8B7E for ; Tue, 12 Mar 2013 09:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15382; q=dns/txt; s=iport; t=1363107241; x=1364316841; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ce3cYxoTJQLoNlQZAByH84VQJBs3m7blo7ACrlLE3CM=; b=fmWAOD+U6L8gvq7xsx+3RmPfHOjLMXdBJZMFcIEvjwAmb2+uu08ngbGy HfzwHOr9IRC7NxSMJ57hdR6udYJCWZEu2H8Ec9rDYvzX3S5KWttii3bYm 4IEG9q4HMrCnx45EP3tvTA+IBSPv1mBF3Ap6nhNDr4fRQ2VHnurngbrFC A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAB5dP1GtJV2d/2dsb2JhbABDhT2/KoFLFnSCKQEBAQMBAQEBNzQCBAUFBwQCAQgRBAEBCxQJBycLFAkIAQEECgQFCAESh3MGBwWxTo9pF41NFXomCwcGgllhA5d1j1eDCoFrAR4BHQ X-IronPort-AV: E=Sophos;i="4.84,831,1355097600"; d="scan'208";a="186657536" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 12 Mar 2013 16:54:00 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2CGrxmI009945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Mar 2013 16:53:59 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.8]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 11:53:59 -0500 From: "Kent Leung (kleung)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] draft-ietf-cdni-requirements-05.txt Thread-Index: Ac4avxMK/pRAinoqR3mcJn/pp4LLVQElc5gAAATlWmA= Date: Tue, 12 Mar 2013 16:53: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.21.95.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 16:54:11 -0000 Hi Francois. Comments below in "KL>". -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Tuesday, March 12, 2013 7:08 AM To: Kent Leung (kleung) Cc: cdni@ietf.org Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt Kent and all, I have received consistent feed-back from two CDN operators and a Content P= rovider that the CDNI solution ought to support: *A* enforcement of caching directives by dCDN that are different to the on= es signalled in the HTTP headers *B* choice of ignoring/factoring query string in dCDN caching *C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive Downloa= d)=20 *A* and *B* are already mostly covered in META-18 but it is listed as [LOW]= . I would recommend we raise META-18 to [MED]. KL> That sounds reasonable to me. Unless others object, this requirement wi= ll be set to MED priority in the next version. I don't think *C* is covered. I would recommend we add rate-pacing as a 3rd= example of "surrogate cache behaviour" in META-18.=20 KL> I can see some value of this feature. I'll see how the debate settles b= efore updating the draft. I will bring this up in the CDNI session today, but wanted to give folks so= me heads-up. KL> Thanks for the heads up. I also have other comments on -05 which I will either pass on to Kent direc= tly or post on the list. KL> Thanks. Kent Cheers Francois " META-18 [LOW] The CDNI Metadata Distribution interface may allow signaling of CDNI-relevant surrogate cache behavior parameters. For example, this could potentially include: * control of whether the query string of HTTP URI is to be ignored by surrogate cache * content revalidation parameters (e.g. TTL) " On 6 Mar 2013, at 18:08, Kent Leung (kleung) wrote: > Hi folks. The requirements draft was updated based on the feedback from t= he authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), dr= aft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-loggin= g. >=20 > In preparation for the next WG session, the edits were published in the d= raft for review. Please provide your comments to the list of requirement ch= anges below. Thanks. >=20 > 1. New CDNI Control Interface requirement >=20 > a. Based on recommendations in ID-HAS, CCID is introduced for HAS= content without the need for HAS-aware CDN. >=20 > CNTL-12 [MED] The CDNI Control interface should allow for multip= le=09 > content items identified by a Content Collection ID to be=09 > purged using a single Content Purge action. >=20 > 2. New CDNI Request Routing Interface requirements >=20 > a. This is an explicit requirement for RRI to support per-chunk = request routing. Since the chunk is same as any content, it's not clear if = the requirement is needed? >=20 > REQ-15 [HIGH] The CDNI Request-Routing interface shall allow fo= r=09 > per-chunk request routing of HTTP Adaptive Streaming content.= =09 > [Ed: chunk is treated as any content, is this needed?]=09 > =09 > b. Manifest rewrite by uCDN is considered as optional feature in= the ID-HAS, should the priority be LOW instead of MED? >=20 > REQ-16 [MED] The CDNI Request-Routing interface should allow th= e=09 > Upstream CDN to use the information conveyed by the=09 > Downstream CDN during the Recursive Request Routing process=09 > to rewrite an HTTP Adaptive Streaming manifest file. [Ed:=09 > should this be LOW?]=09 >=20 > c. Manifest rewrite by uCDN for URI Signing is considered as op= tional feature in the ID-HAS, should the priority be LOW instead of MED? > =09 > REQ-17 [MED] The CDNI Request-Routing interface should allow t= he=09 > Upstream CDN to re-sign the invariant portion of the chunk=09 > URIs embedded in the HTTP Adaptive Streaming manifest file.=09 > [Ed: should this be LOW?]=09 > =09 > d. Use of cookie for URI Signing is is considered as optional fe= ature in the ID-HAS, should the priority be LOW instead of MED? >=20 > REQ-18 [MED] The CDNI Request-routing interface should allow th= e use=09 > of HTTP cookie to associate the chunks with the HTTP Adaptive= =09 > Stream manifest file (which is verified by the URI signature)= =09 > basedon the Authorization Group ID (which is an identifier=09 > used to correlate the manifest file to the related chunks).=09 > [Ed: should this be LOW?]=09 >=20 > e. LOW instead of MED priority?=09 >=20 > REQ-19 [MED] The CDNI Request-Routing interface may allow for a= n=09 > efficient method of transferring request routing information= =09 > for multiple chunks from the Downstream CDN to the Upstream=09 > CDN as part of the recursive request routing process. [Ed:=09 > should this be LOW?]=09 > =09 > f. Based on ID-HAS and logging drafts, the following requirement= was introduced to log HAS content and customization of the logging. > =09 > REQ-20 [MED] The CDNI Request-Routing/Footprint and Advertising= =09 > interface shall support advertisement of the following=09 > capabilities:=09 > =09 > * support for customized CDNI Logging=09 > =09 > * support of Content Collection ID logging=09 > =09 > * support for Session ID logging >=20 > 3. Removed CDNI Metadata Distribution Interface requirement. >=20 > a. Based on the metadata draft, there is no need for dCDN to ind= icate to the uCDN the result of delivering the metadata since the "pull" or= "triggered pull" model is used (i.e. dCDN request for metadata from uCDN). >=20 > META-13 [HIGH] The CDNI Metadata Distribution interface shall =09 > provide indication by the Downstream CDN to the Upstream CDN = =09 > of whether the CDNI metadata (and corresponding future =09 > request redirections) is accepted or rejected. When =09 > rejected, the CDNI Metadata Distribution protocol Must allow = =09 > the Downstream CDN to provide information about the cause of = =09 > the rejection. =09 >=20 > 4. New CDNI Metadata Distribution Interface requirements >=20 > a. Based on ID-HAS's recommendations, this is introduced. >=20 > META-19 [HIGH] The CDNI Metadata interface shall provide indicati= on=09 > of related content (e.g. HTTP Adaptive Bit Rate chunks) by= =09 > the Content Collection ID (CCID) metadata. This could be=09 > used by the Downstream CDN for operations on the group of=09 > content. For example, this could potentially include:=09 > =09 > * content acquisition for the entire set of files when one= =09 > piece of content is requested=09 > =09 > * local file management and storage bundles all the files= =09 > for the content=09 > =09 > * purging the entire set of files associated with the=09 > content=09 > =09 > * logging of the delivery of the content for the session=09 > when at least one file in the set was delivered=09 > =09 > b. Based on the logging draft, this is introduced. >=20 > META-20 [HIGH] The CDNI Metadata Distribution interface shall=09 > support an OPTIONAL mechanism allowing the Upstream CDN to=09 > indicate to the Downstream CDN which CDNI Log fields are to= =09 > be provided for all, for specific sets of, or for specific=09 > content items delivered using HTTP. A CDNI implementation=09 > that does not support this optional CDNI Metadata=09 > Distribution Interface mechanism MUST ignore this log format= =09 > indication and generate CDNI logging format for HTTP=09 > Adaptive Streaming using the default set of CDNI Logging=09 > fields.=09 > =09 > c. Based on the ID-HAS's recommendations, this is introduced. >=20 > META-21 [MED] The CDNI Metadata Distribution interface shall allo= w=09 > the Upstream CDN to signal to the Downstream CDN the Content= =09 > Collection ID value for all, for specific sets of, or for=09 > specific content items delivered using HTTP. Whenever the=09 > Downstream CDN is instructed by the Upstream CDN to report=09 > the Content Collection ID field in the log records, the=09 > Downstream CDN is to use the value provided through the CDNI= =09 > Metadata interface for the corresponding content. Note the= =09 > Session ID field along with Content Collection ID may be=09 > used for HTTP Adaptive Streaming content.=09 > =09 > d. Based on ID-HAS's recommendations, this is introduced. >=20 > META-22 [MED] The CDNI Metadata Distribution interface shall allo= w=09 > the Upstream CDN to signal to the Downstream CDN the=09 > Authorization Group ID value for all the related HTTP=09 > Adaptive Streamin content (i.e. manifest file and chunks).=09 > The authorization result of a content (e.g. manifest file)=09 > is transferred over to related content (e.g. chunks). [Ed:= =09 > need to improve wording?] >=20 > 5. Remove CDNI Logging Interface requirement >=20 > a. It is deemed unnecessary for dCDN to obtain logs from uCDN, whi= ch has access to all the logs for trouble-shooting and auditing. >=20 > LOG-4 [HIGH] The CDNI Logging interface shall provide logging of =09 > distribution performed by the Upstream CDN as a result of =09 > acquisition request by the Downstream CDN. >=20 > 6. Add CDNI Logging Interface requirements >=20 > a. Based on the logging draft, this is introduced. >=20 > LOG-17 [HIGH] The CDNI Logging interface shall support the=09 > notification from Downstream CDN to Upstream CDN for the=09 > event that the logging retention duration or maximum size of= =09 > logging data has exceeded.=09 > =09 > b. Based on the ID-HAS, CCID is a field to report in the log. Al= so, based on the logging draft, Session ID is another field needed in the l= og. >=20 > LOG-18 [MED] The CDNI Logging interface should support the abil= ity=09 > for the Downstream CDN to include the Content Collection ID=09 > and Session ID fields in CDNI log entries generated for HTTP= =09 > Adaptive Streaming content. This fields can be supported by= =09 > the "customizable" log format which is expected to be defined= =09 > independently of HTTP Adaptive Streaming. >=20 > Kent >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org > Sent: Saturday, February 23, 2013 1:16 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt >=20 >=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 : Content Distribution Network Interconnection (CDNI) Re= quirements > Author(s) : Kent Leung > Yiu Lee > Filename : draft-ietf-cdni-requirements-05.txt > Pages : 23 > Date : 2013-02-23 >=20 > Abstract: > Content Delivery Networks (CDNs) are frequently used for large-scale > content delivery. As a result, existing CDN providers are scaling up > their infrastructure and many Network Service Providers (NSPs) are > deploying their own CDNs. There is a requirement for interconnecting > standalone CDNs so that their collective CDN footprint can be > leveraged for the end-to-end delivery of content from Content Service > Providers (CSPs) to end users. The Content Distribution Network > Interconnection (CDNI) working group has been chartered to develop an > interoperable and scalable solution for such CDN interconnection. >=20 > The goal of the present document is to outline the requirements for > the solution and interfaces to be specified by the CDNI working > group. This draft is a work in progress and requirements may be > added, modified, or removed by the working group. >=20 > Requirements Language >=20 > The key words "High Priority", "Medium Priority" and "Low Priority" > in this document are to be interpreted in the following way: >=20 > o "High Priority" indicates requirements that are to be supported by > the CDNI interfaces. A requirement is stated as "High Priority" > when it is established by the working group that it can be met > without compromising the targeted schedule for WG deliverables, or > when it is established that specifying a solution without meeting > this requirement would not make sense and would justify re- > adjusting the WG schedule, or both. This is tagged as "[HIGH]". >=20 > o "Medium Priority" indicates requirements that are to be supported > by the CDNI interfaces unless the WG realizes at a later stage > that attempting to meet this requirement would compromise the > overall WG schedule (for example it would involve complexities > that would result in significantly delaying the deliverables). > This is tagged as "[MED]". >=20 > o "Low Priority" indicates requirements that are to be supported by > the CDNI interfaces provided that dedicating WG resources to this > work does not prevent addressing "High Priority" and "Medium > Priority" requirements and that attempting to meet this > requirement would not compromise the overall WG schedule. This is > tagged as "[LOW]". >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-requirements-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Tue Mar 12 13:29: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 496E421F87F9 for ; Tue, 12 Mar 2013 13:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.533 X-Spam-Level: X-Spam-Status: No, score=-10.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 kMu2PH0pYGOI for ; Tue, 12 Mar 2013 13:29:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id AE13221F8712 for ; Tue, 12 Mar 2013 13:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=289; q=dns/txt; s=iport; t=1363120156; x=1364329756; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=veo745BstyshX3fMRVVTQ0i6YZFzKUEnAPl8emOxD+k=; b=VA9LrXQAXf3ReKizF1DU5wt36PuatXb3sYr/v0FTnLZbiKVFzFlnsPiL m3t2Z/mTUiLKELFbMAAnfyhIMKumqg1y7lGKGeJDKIVoVF48hLBM5DinI DAxluNJ+0Cj6AW8/RPHYlCh/rM/jtAJC7XKjMy6UPdTdd7ZZ6FGAfYObt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAF6PP1GtJXHB/2dsb2JhbABDh1C9GoFLFm0HgisBBDpRASoUQicEGwGICwygQ5EVj1oXjlyDF2EDp0yDCoIo X-IronPort-AV: E=Sophos;i="4.84,833,1355097600"; d="scan'208";a="186707637" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 12 Mar 2013 20:29:16 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2CKTGFP030761 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Mar 2013 20:29:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 15:29:16 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Using JSON in IETF Protocols Thread-Index: AQHOH2BDecRHTZyzm0uqczRyks60kA== Date: Tue, 12 Mar 2013 20:29:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.150.244] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Using JSON in IETF Protocols 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, 12 Mar 2013 20:29:18 -0000 Rich shared this link to an IETF Journal article discussing the use of JSON= in IETF protocols: Here is a http://www.internetsociety.org/articles/using-json-ietf-protocols This may be useful for the encoding discussion around CDNI Metadata and CDN= I Request Routing. Francois= From Jan.Seedorf@neclab.eu Tue Mar 12 14:28:27 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 CCCC611E80F7 for ; Tue, 12 Mar 2013 14:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.166 X-Spam-Level: X-Spam-Status: No, score=-103.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ab+6okcvGnjq for ; Tue, 12 Mar 2013 14:28:26 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C3DFD11E80F5 for ; Tue, 12 Mar 2013 14:28:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 395D3103709 for ; Tue, 12 Mar 2013 22:28:26 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGHtDahDIyCc for ; Tue, 12 Mar 2013 22:28:26 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 213E5103707 for ; Tue, 12 Mar 2013 22:28:21 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 12 Mar 2013 22:27:45 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: Reminder: CDNI Footprint/Capabilities Side Meeting @IETF-86 Thread-Index: Ac4fZj8DUGRWES+ATM6e/NlNED9h+Q== Date: Tue, 12 Mar 2013 21:27:45 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5545A775@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.207] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Reminder: CDNI Footprint/Capabilities Side Meeting @IETF-86 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, 12 Mar 2013 21:28:27 -0000 Dear all, Just a reminder: the footprint/capabilities side meeting at this IETF-86 me= eting will be tomorrow, ** WED, March 13th, 13:00-15:00 ** - Jan -----Original Message----- From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.o= rg] On Behalf Of Jan Seedorf Sent: Thursday, March 07, 2013 6:03 AM To: cdni@ietf.org Cc: cdni-footprint@ietf.org Subject: [cdni-footprint] CDNI Footprint/Capabilities Side Meeting @IETF-86 Dear all, The winner of the doodle is: ** WED, March 13th, 13:00-15:00 ** I suggest we meet at the registration desk and then go find a room. - Jan > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Jan Seedorf > Sent: Monday, March 04, 2013 11:15 AM > To: cdni@ietf.org > Cc: cdni-footprint@ietf.org > Subject: [cdni-footprint] CDNI Footprint/Capabilities Side Meeting @IETF-= 86 >=20 > I have set up a doodle, please try to fill in by Thursday this week, so t= hat we > can decide the best slot and circulate the date/time on Friday. >=20 > http://www.doodle.com/adfa9unigs9gxmr8 >=20 > - Jan >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > Jan Seedorf > Senior Researcher > NEC Europe Ltd., NEC Laboratories Europe, Network Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 > Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 > e-mail:=A0 jan.seedorf@neclab.eu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West En= d > Road, London, HA4 6QE, GB, Registered in England 2832014 >=20 >=20 > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint _______________________________________________ cdni-footprint mailing list cdni-footprint@ietf.org https://www.ietf.org/mailman/listinfo/cdni-footprint From flefauch@cisco.com Tue Mar 12 15:27:34 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 A27DD11E812B for ; Tue, 12 Mar 2013 15:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.209 X-Spam-Level: X-Spam-Status: No, score=-10.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 73MGXBqVggWe for ; Tue, 12 Mar 2013 15:27:33 -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 503E811E80FF for ; Tue, 12 Mar 2013 15:27:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1493; q=dns/txt; s=iport; t=1363127253; x=1364336853; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cVYp2ev9ob9T7AePODonhY90gDdG6CGKRBzWKpvJ8gs=; b=I9/vJ60L54braxWtgaPZi+BAcH+FmKtW83XjJ490wucEUrWpbHQFEWI5 EwnF1ItM/TI3iSd0alyM30TOfCzyIsD2EH0bchmyJumAfj6AniKEBo3LS cG0RIOxjS03F8XxJ72q5D3WqJM/VB/Qoz7Hmlg/xmkE3zm6XFtcmdHKjz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPGqP1GtJXG//2dsb2JhbABDxHeBSxZtB4IpAQEBAwEBAQE3NBALAgEqFBAnCyUCBBMIE4dzBgyxX49cEwSOXDiCX2EDp0yDCoIo X-IronPort-AV: E=Sophos;i="4.84,833,1355097600"; d="scan'208";a="186533410" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 12 Mar 2013 22:27:32 +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 r2CMRWUx011656 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 12 Mar 2013 22:27:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 17:27:32 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] 2nd Informal meeting on cdni-logging in Orlando Thread-Index: AQHOH3DJthMz9JA1xUa9yHP+qRJLzw== Date: Tue, 12 Mar 2013 22:27:32 +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.21.80.217] Content-Type: text/plain; charset="us-ascii" Content-ID: <3B8CC892B4988642BCA1327F32225D5D@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] 2nd Informal meeting on cdni-logging in Orlando 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, 12 Mar 2013 22:27:34 -0000 We will have another informal meeting around cdni-logging: * Thursday 9:00am=20 * get together at the IETF Registration desk Cheers Francois & Iuniana On 7 Mar 2013, at 09:32, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > (as an individual and cdni-logging co-author) >=20 > We'd like to run an informal open meeting around cdni-logging while in Or= lando. >=20 > We've (tentatively) selected: > * Tuesday 1:00 pm local time,=20 > * get together at the IETF Registration desk.=20 > So please put that in your calendar if you're interested in the cdni-logg= ing work. >=20 > Pretty flexible agenda but should include: > * review of candidate logging fields + which is mandatory/optional/mot-n= eeded for delivery records > * how hard should we try to make the non-real-time logging solution comp= atible/extensible to real-time logging? in other words, should we first jus= t specify a very simple file based exchange of log records for non-real-tim= e, and then accept that we may not be able to leverage much of that when tr= ying to move to real-time logging? > * log records formats/syntax > * whatever you'd like to discuss >=20 > Obviously the cdni-logging draft will still be discussed formally in the = CDNI WG session. >=20 > Cheers >=20 > Francois & Iuniana >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From ben@niven-jenkins.co.uk Tue Mar 12 15:33:17 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 2A83211E810D for ; Tue, 12 Mar 2013 15:33:17 -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 DQYf+YH4sp2j for ; Tue, 12 Mar 2013 15:33:16 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 48A6711E80F0 for ; Tue, 12 Mar 2013 15:33:16 -0700 (PDT) Received: from dhcp-1627.meeting.ietf.org ([130.129.22.39]) by mail10.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1UFXks-0000PJ-Dp; Tue, 12 Mar 2013 22:33:10 +0000 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <166EBB70C264A9479E459B01B1BA6C92103212C7@xmb-aln-x03.cisco.com> Date: Tue, 12 Mar 2013 22:33:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <42BAF0A5-02CF-4F62-A700-2B6114CAC0F7@niven-jenkins.co.uk> References: <166EBB70C264A9479E459B01B1BA6C92103212C7@xmb-aln-x03.cisco.com> To: Matt Caulfield (mcaulfie) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni@ietf.org" Subject: Re: [CDNi] XML vs JSON 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, 12 Mar 2013 22:33:17 -0000 Matt, Colleagues, As I've said in the past my preference would be for JSON. Reading the "Using JSON in IETF Protocols" page Francois forwarded to = the list, there are a number of things called out in the section titled = "The Devil Is in the Details", namely: 1) Support for non-Unicode character sets 2) Mixed Content & Markup 3) Namespaces 4) Normative Reference for JSON 5) Schemas 6) Performance I would argue that CDNI has no requirement for (1), (2) & (3) and (4) is = being fixed by the recently formed JSON WG in Apps Area. I'm not convinced the Schema argument is a showstopper, there are = proposals for JSON schemas and if folks felt strongly about having a = formal schema in the CDNI specification RFCs we can pick one of those = schema proposals and use it. Performance weighs in JSON's favour (according to the link, I do not = have my own experimental data to draw from as I've never tested JSON vs = XML performance). So IMO there is no compelling reason to select XML over JSON. Equally = one could argue there is no compelling reason to select JSON over XML = but I would argue the simplicity (& apparent performance) of JSON tips = the scales in JSON's favour. Ben On 22 Feb 2013, at 21:12, Matt Caulfield (mcaulfie) wrote: > Hi everyone, >=20 > While writing the CDNI metadata draft, we have been struggling with = the choice between XML and JSON for encoding metadata.=20 >=20 > We are turning to the list for inspiration and hopefully a decision. = Below is an extremely high level synopsis of the options.=20 >=20 > XML > Verbose. > Flexible. > Allows for both elements and attributes. > Standardized schema definition language. > Includes concept of namespaces. >=20 > JSON > Terse.=20 > Fast to parse. > Allows for ordered lists. >=20 > If you feel strongly one way or the other, please chime in.=20 >=20 > See the metadata draft for an example of both: = http://tools.ietf.org/html/draft-ietf-cdni-metadata-00#section-5.4 >=20 > Thanks, > Matt > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Wed Mar 13 07:27: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 BBEB921F8E3A for ; Wed, 13 Mar 2013 07:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.541 X-Spam-Level: X-Spam-Status: No, score=-10.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 tCWg23s5l9Mx for ; Wed, 13 Mar 2013 07:27: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 456F321F8B20 for ; Wed, 13 Mar 2013 07:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=692; q=dns/txt; s=iport; t=1363184867; x=1364394467; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=GT++WFffLWh4oGlFxGJHW80V7DZyAc99DlWfi3sN5J4=; b=jZnG8JZEBNsQBt3r4SXokQKFWLGXHglT/41rGMnD2pqXn8zMDAU8f51N WwMHLSCumBlglwxuHf9vz3/eC9iySeaj3/gZbkIGsDw2y7ziqvl4wfr+0 LUZwbeXR6KGzHXn3DJmZDu+hZpf4f7Wp2+nS0vI/brk6GUBSrcuw20bD2 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEOLQFGtJXG9/2dsb2JhbABDxHuBVhZtB4IrAQQ6PxIBKhRCJwQODYgMwisXjlwxgmZhA6dMgwqCKA X-IronPort-AV: E=Sophos;i="4.84,837,1355097600"; d="scan'208";a="187005249" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 13 Mar 2013 14:27:46 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2DERkan024680 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 14:27:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 09:27:36 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-framework@tools.ietf.org" Thread-Topic: Next steps for draft-ietf-cdni-framework Thread-Index: AQHOH/bo7fNkXZuhzUiNBQFDGSRkhg== Date: Wed, 13 Mar 2013 14:27:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.119.95] Content-Type: text/plain; charset="us-ascii" Content-ID: <4500F037BBA23F49B9C232BD6BD23CDA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Next steps for draft-ietf-cdni-framework X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:27:47 -0000 Hi Larry and co-authors, At the end of the cdni-framework presentation, we agreed that: * cdni-framework would be revved up within 3 weeks to tweak text on "Check= -with-Me" * we will issue a WG Last Call on that next rev. However, during the cdni-metadata presentation, we agreed that the text abo= ut "URI rewriting" (currently in the cdmi-metadata document) should be gene= ralised since it applies to multiple CDNI interfaces and moved to the cdni-= framework document. Can you confirm you can work with the cdni-metadata authors to generalise a= nd move the text on "URI Rewriting" into the next rev of cdni-framework (to= be WG Last Called)? thanks Francois= From lapeters@akamai.com Wed Mar 13 11:08: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 78FB321F8E0B for ; Wed, 13 Mar 2013 11:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 QiKbgfX7GE9E for ; Wed, 13 Mar 2013 11:08:50 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id A187521F8E67 for ; Wed, 13 Mar 2013 11:08:47 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 150091655F7; Wed, 13 Mar 2013 18:08:47 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 09EA2165557; Wed, 13 Mar 2013 18:08:47 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub5.dfw01.corp.akamai.com [172.27.25.71]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id EE95147BD5; Wed, 13 Mar 2013 18:08:45 +0000 (GMT) Received: from USMBX2.msg.corp.akamai.com ([169.254.1.74]) by ustx2ex-cashub5.dfw01.corp.akamai.com ([172.27.25.71]) with mapi; Wed, 13 Mar 2013 13:08:45 -0500 From: "Peterson, Larry" To: "Francois Le Faucheur (flefauch)" Date: Wed, 13 Mar 2013 13:08:43 -0500 Thread-Topic: [CDNi] Next steps for draft-ietf-cdni-framework Thread-Index: Ac4gFc0Igl7u7nV5Q4SXvfowdTWH6g== Message-ID: <3396984E-3304-4035-A18B-91E9D8978421@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_C2BDCC0F-AD81-42C5-A087-9812FB8BA947"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "draft-ietf-cdni-framework@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Next steps for draft-ietf-cdni-framework X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:08:50 -0000 --Apple-Mail=_C2BDCC0F-AD81-42C5-A087-9812FB8BA947 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I can do that. --Larry On Mar 13, 2013, at 10:27 AM, Francois Le Faucheur (flefauch) wrote: > Hi Larry and co-authors, >=20 > At the end of the cdni-framework presentation, we agreed that: > * cdni-framework would be revved up within 3 weeks to tweak text = on "Check-with-Me" > * we will issue a WG Last Call on that next rev. >=20 > However, during the cdni-metadata presentation, we agreed that the = text about "URI rewriting" (currently in the cdmi-metadata document) = should be generalised since it applies to multiple CDNI interfaces and = moved to the cdni-framework document. >=20 > Can you confirm you can work with the cdni-metadata authors to = generalise and move the text on "URI Rewriting" into the next rev of = cdni-framework (to be WG Last Called)? >=20 > thanks >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail=_C2BDCC0F-AD81-42C5-A087-9812FB8BA947 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOPjCCBjYw ggUeoAMCAQICChsbaFcAAAAAAAQwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJ Um9vdDAeFw0wOTA2MDMxMzE2MjFaFw0xOTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNj b20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQD ExBBa2FtYWlQS0lJc3N1aW5nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5 Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cLkVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg 8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq +A9zFcxABosmmYDCSJ1+B6noMarjHG62AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN /ianrjc/AKi2vzRETb98qvv3h2GWdif7nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Np i7+GsYLcmB0b63L02cs9QCXA4oOeawIDAQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV HQ4EFgQUB+y0jq9nhlSI772zFFdJz4JMvxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgEC MCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMA dQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz/hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEj MIIBH6CCARugggEXhiJodHRwOi8vYWthbWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8v YWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6 Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtl eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlv blBvaW50MIIBTgYIKwYBBQUHAQEEggFAMIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBr aS91c21hMWNhLXBraTBfQWthbWFpUEtJUm9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2Ft YWlwa2kuZGZ3MDEuY29ycC5ha2FtYWkuY29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNy dDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8vL0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9 YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBADkqmsMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfW aAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDv NQSSApRMHQ0VYRuMC1HruQexFvqDBoqjJ1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjE ri+aO0XVBdRaNiZyB50kmhNelgWRPT5OsDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0I MP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggAMIIG 6KADAgECAgodVbdHAAIAAOWFMA0GCSqGSIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20x FjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBB a2FtYWlQS0lJc3N1aW5nMB4XDTEyMTIwNDE5MzYxN1oXDTEzMTIwNDE5MzYxN1owgZwxCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJNQTESMBAGA1UEBxMJQ2FtYnJpZGdlMRwwGgYDVQQKExNBa2FtYWkg VGVjaG5vbG9naWVzMRcwFQYDVQQLEw5BVVRPLWJvcy1tcGFnYjERMA8GA1UEAxMIbGFwZXRlcnMx IjAgBgkqhkiG9w0BCQEWE2xhcGV0ZXJzQGFrYW1haS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCbmb+XJz2L/fxTvAIagVUCs7TkIOaqRAwQxpOn9wxVL6rtNHCjLSUoblRzOkb3 baEGF1kVXiGDGI/2b1M8za3SHJc/pmbTbhhLGyBNO6k4+cdzjzZF+oK7h0iO58kIGU8YWrrD3JVF GBiPu7dw3KLW5q5SxKcyV3BXIWQ6lhHBZ1vTpgkc9hG3RDZV9YBccj8HZqUrKb6qsVSDkdyELyvs BKVYkRQ0Imu8IMckbflYew+52pTGchuSRKldFYmdhCJ1yrZohjVId+h2n3GYPAWlz0+jDuyY1CLV lZoZFwfAYs+NU+04A/FLWp7Vy48j6MzdfxIlSPot0/9xjkNCIxFNAgMBAAGjggR/MIIEezALBgNV HQ8EBAMCBaAwMwYDVR0lBCwwKgYIKwYBBQUHAwcGCCsGAQUFBwMCBgorBgEEAYI3CgMEBggrBgEF BQcDBDAzBgNVHREELDAqoCgGCisGAQQBgjcUAgOgGgwYbGFwZXRlcnNAY29ycC5ha2FtYWkuY29t MB0GA1UdDgQWBBQbw+hP1X8ejh4BkPijwLbJXNFMfDAfBgNVHSMEGDAWgBQH7LSOr2eGVIjvvbMU V0nPgky/FDCCATkGA1UdHwSCATAwggEsMIIBKKCCASSgggEghiVodHRwOi8vYWthbWFpcGtpL0Fr YW1haVBLSUlzc3VpbmcuY3JshjtodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNv bS9Ba2FtYWlQS0lJc3N1aW5nLmNybIaBuWxkYXA6Ly8vQ049QWthbWFpUEtJSXNzdWluZyxDTj11 c21hMWNhLXBraTEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBvAYIKwYBBQUHAQEEggGu MIIBqjBZBggrBgEFBQcwAoZNaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTEua2VuZGFsbC5j b3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwbwYIKwYBBQUHMAKGY2h0dHA6 Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWkuY29tL3VzbWExY2EtcGtpMS5rZW5kYWxsLmNv cnAuYWthbWFpLmNvbV9Ba2FtYWlQS0lJc3N1aW5nKDIpLmNydDCBrAYIKwYBBQUHMAKGgZ9sZGFw Oi8vL0NOPUFrYW1haVBLSUlzc3VpbmcsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0 ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9ha2FtYWlvY3NwLmFrYW1haS5jb20vb2NzcDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiCzuU6h7jULYGFiwei4yGG0g+BSYTk3wWBkPoUAgFkAgEWMEEGCSsGAQQBgjcVCgQ0MDIwCgYI KwYBBQUHAwcwCgYIKwYBBQUHAwIwDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDBEBgkqhkiG9w0B CQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcN AwcwDQYJKoZIhvcNAQEFBQADggEBAGJ0DGpvXHPRk+t1KHfshPIJLXaaOh3irSMk2BpTVkXnvzmR K+X7ZJueCKhK7e6UVyyi1QrGx3U+XkRmCCLLAYbKyyqSIBRibWbzIovfkWp8BFOHhajrMimuWERD nJJuteZAhpUexBDCEatkTbPQ+Y8EGLAKxI4HpaWWmagUDaAAKpqrkxMXHP93pYRCWfzoSqrk3zGR Cq4d4g66vDaTvjp5FykQLHNTplCIgp6Yy1pCgkSXZT+2ZSQyACbXPrt917QwvxHIB7w8256R9804 DPIKF1j3ryjtiVePBBHokfiRAQlJjrEV3KDVrXAM7riy+XpePAYojrDcR8+cXgFZtzYxggLwMIIC 7AIBATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDAS BgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgodVbdHAAIAAOWF MAkGBSsOAwIaBQCgggFZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxMzE4MDg0NFowIwYJKoZIhvcNAQkEMRYEFCXoux1BfN7XgLxzb66b8EJkW9lIMHsGCSsG AQQBgjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1h aTEUMBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCCh1Vt0cA AgAA5YUwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJ c3N1aW5nAgodVbdHAAIAAOWFMA0GCSqGSIb3DQEBAQUABIIBACk74Dk5LYB30Gnej27G1/ONovta qtzS+wHgkWyplgjLlRs7r6xnjToyF86Wai7uLOfG9+tcmKypK4g7pJfUFZJqI/KhqLp55zxXu3ho 9aZiNOSHyODaDmnvtCIslwkwzZc+0Xc/C/eArArJzEYOQw+r8sanLcycw0SbCOyht/CqnNyX4suz FCrzgq0XMi6zArF43mPeQwkuefIB0tBuuFWebhnXddbB0hJmVYzWRxDIkO7EqPnRBpLP512ucy3P oW1MrmO0qvkOPjDY4DYpC6KfYywb0fNnRX4JPOZWw+VVJyQ1tcRFsQmX3wXnOHoQe9xmhwKEl5o5 +uEx45/z2SIAAAAAAAA= --Apple-Mail=_C2BDCC0F-AD81-42C5-A087-9812FB8BA947-- From Martin.Stiemerling@neclab.eu Wed Mar 13 11:50:49 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 8481621F8D76 for ; Wed, 13 Mar 2013 11:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.605 X-Spam-Level: X-Spam-Status: No, score=-103.605 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkWbzBQDg0qf for ; Wed, 13 Mar 2013 11:50:49 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id ECB1121F8D2F for ; Wed, 13 Mar 2013 11:50:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 5B3A410370D for ; Wed, 13 Mar 2013 19:50:48 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r4XuJDv4cfTf for ; Wed, 13 Mar 2013 19:50:48 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 3EBA810364B for ; Wed, 13 Mar 2013 19:50:43 +0100 (CET) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 13 Mar 2013 19:50:14 +0100 Message-ID: <5140CA7F.1010208@neclab.eu> Date: Wed, 13 Mar 2013 14:50:39 -0400 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: References: <513E40AF.2080804@neclab.eu> In-Reply-To: <513E40AF.2080804@neclab.eu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: Re: [CDNi] Looking for a new co-chair for the CDNI Working Group 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, 13 Mar 2013 18:50:49 -0000 To add a deadline for speaking up as a candidate: ***Please send your email to the call below to me until 3/20 5pm PT***** Thanks, Martin On 03/11/2013 04:38 PM, Martin Stiemerling wrote: > Hi all, > > The CDNI working group [1] is looking for a new working group co-chair. > > Rich Woundy is stepping down as co-chair by the end of the IETF-86 meeting. > > A big thank you to Rich for being co-chair since the establishment of > the CDNI working group! > > > If any of you is interested in co-chairing the CDNI WG, please send an > email back to me in private. > > > Thanks, > > Martin > > > [1] http://datatracker.ietf.org/wg/cdni > -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From Jan.Seedorf@neclab.eu Wed Mar 13 17:39:00 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 864F911E80D3 for ; Wed, 13 Mar 2013 17:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.274 X-Spam-Level: X-Spam-Status: No, score=-103.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k17UVaBEozsm for ; Wed, 13 Mar 2013 17:38:59 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 88EC711E80C5 for ; Wed, 13 Mar 2013 17:38:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id EB34310377A for ; Thu, 14 Mar 2013 01:38:58 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGCK2CyCUYg1 for ; Thu, 14 Mar 2013 01:38:58 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id CE701103777 for ; Thu, 14 Mar 2013 01:38:53 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.80]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 14 Mar 2013 01:38:53 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: notes from footprint / capabilities side meeting today Thread-Index: Ac4gS6O1YwXy++E3QgaPre4z63Iuzw== Date: Thu, 14 Mar 2013 00:38:26 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5545B135@PALLENE.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.209] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] notes from footprint / capabilities side meeting today 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, 14 Mar 2013 00:39:01 -0000 Dear all, Below are my rough notes from today's side meeting. A summary will follow i= n the slides being presented in the session tomorrow. - Jan ********** -- Discussion whether to have only high-level location identifiers (e.g. br= oad geographic regions) as mandatory; Jon: that is what business agreements= currently use; Rich: what about DVD-region codes; discussion what should b= e these mandatory location identifiers: DVD-region, Blue-Ray, ISO country c= ode, IP-prefixes, AS-number?=20 -- agreement that for footprint there will be a small set of mandatory iden= tifier types, and protocol will be open for future optional types of footpr= ints (similar as with capabilities) -- Long discussion what needs to be mandatory and what optional -- Francois: should new types of footprint be optional, or experimental? Do= they need to undergo working group approval? -- Discussion whether we need working group consensus or just expert review= for new optional capabilities/footprints -- Spec will define a process on how optional capabilities/footprints will = be added -- Clear agreement on country code -- DVD-Region: cons -> could be mapped to ISO codes; pro -> is relevant fro= m a content-DRM perspective;=20 -- Clear agreement on IP-prefixes and AS number -- Mapping of IP-address to AS number or country can be problematic ********** =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Senior Researcher NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 jan.seedorf@neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End = Road, London, HA4 6QE, GB, Registered in England 2832014 From swainner@cisco.com Mon Mar 18 09:28:44 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 C656E21F868B for ; Mon, 18 Mar 2013 09:28:44 -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 EHzYZPliBGa0 for ; Mon, 18 Mar 2013 09:28:35 -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 A4C1B21F8C7D for ; Mon, 18 Mar 2013 09:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12151; q=dns/txt; s=iport; t=1363623982; x=1364833582; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=eDPmEEp1I79T9jRSCXAv/0tw+BRyG41d7ZziE4yPfNM=; b=W1QfBw7owFyktJmnA3otfx/Sz0IypeWeWSdtitv2jVkNlwmcRCt3BtP3 rufIO/xBklXcbdbSWUSLB3b0A+V0wVDEGrnYK2HgO0j5CeSwrrnFN3zB7 ufdh8Z/2z+O12jsh/iueNbzIZPwonY4OPLczaTY1aCeG0sGEm4/JIx8IV s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIg/R1GtJV2b/2dsb2JhbABDjXy3JoFWFnSCJQEBBCdRARAsFg8JAwIBAgFFEwEHAQGIEMIojxUHg0ADgUiVFpECgyYg X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208,217";a="188696261" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 18 Mar 2013 16:26:21 +0000 Received: from rtp-swainner-89113.cisco.com (rtp-swainner-89113.cisco.com [10.116.109.206]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2IGQLLm010871; Mon, 18 Mar 2013 16:26:21 GMT Message-ID: <5147402C.7050906@cisco.com> Date: Mon, 18 Mar 2013 12:26:20 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: cdni@ietf.org References: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> <3F5BB382-1292-4EE4-8621-52C7C5097ACC@niven-jenkins.co.uk> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030807060108000609020905" Subject: [CDNi] Comments on draft-he-cdni-routing-request-redirection-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, 18 Mar 2013 16:28:44 -0000 This is a multi-part message in MIME format. --------------030807060108000609020905 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit |4.2 |A single request or response MUST contain only one of the dns or http keys. A DNS query to the uCDN can't result in an HTTP response to the client. The client or DNS forwarder needs a DNS response. Therefore, I see no need for the HTTP key if the RI request type is DNS. An HTTP query to the uCDN requires an HTTP response to the client. Certainly, an HTTP response on the RI request is appropriate. However, a DNS response on the uCDN's RI request using an HTTP key would presumably mean the target of the RI wasn't satisfactorily and the uCDN RR would have to resolve the targets DNS response. Not sure how valuable that would be. |[Editor's note: Is the cdn-path useful on responses as well?] Yes, a uCDN RR that is assessing alternate CDN's in parallel would presumably need to know if the responses of candidate transit dCDN's 'converged' at some point. Consider the case where uCDN is assessing multiple options: a. uCDN -> dCDN-1 -> dCDN-2 b. uCDN -> dCDN-2 Most likely, the uCDN would want to choose dCDN-2 directly as opposed to using dCDN-1 as a transit. |[Editor's note: Need some text/section specifying the Media Types for RI requests/responses] Are you thinking classes of content such as video, audio, images or explicit MIME types? Are we assuming that the dCDN will only serve a subset of the content classes (e.g. images only, images and audio, but no video)? |4.3.1 | c-subnet : String : No : The IP address of the UA in CIDR format. What relevance does this have? Are we trying to assert some assumed scope (i.e. other clients in the same c-subnet)? I suspect that this may be RFC1918 space; therefore, its usefulness is suspect. |4.4.1 HTTP Redirection requests transaction_id integer mandatory : identifier created by uCDN for correlating request/responses session_id string optional? | mandatory? : session identifier reflected from proprietary client HTTP request method: string {http | rtsp | rtmp} mandatory : describes method of request/response client_ip: format {v4 | v6} string mandatory : extracted from HTTP HEADER x-forwarded-for or client request IP forwarder: format {v4 | v6} string mandatory : extracted from HTTP HEADER via or client request IP start_avail: format {epoch | gmt} string optional : extracted from URL of client request expiration: format {epoch | gmt} string optional : extracted from URL of client request |4.4.2 HTTP Redirection responses add transaction_id integer mandatory : identifier created by uCDN for correlating request/responses session_id string optional : reflection of uCDN session_id or generated by dCDN method string {http | rtsp | rtmp} mandatory : describes method of request/response start_avail: format {epoch | gmt} string optional : reflection of uCDN start_avail or generated by dCDN expiration: format {epoch | gmt} string optional : reflection of uCDN expiration or generated by dCDN | 4.5 Indicating the cache-ability and scope of responses I think this would only be applicable to URL's that are not signed when using the Recursive mode. I believe most dCDN will want to authenticate each client request. If we expand the scope of a dCDN response to include a wider range of subnets, that means the uCDN will have to sign URL requests using the chosen dCDN's method and algorithms. The advantage of the RI interface is that the uCDN does not need to know the methods of each dCDN; the dCDN can sign the URL according to its own rules and simply provide the signed URL PATH back to the uCDN as an opaque string. [NOTE] In contrast, the Iterative mode requires the uCDN to sign the URL according to the method of the dCDN (or know that a particular URL can remain unsigned when delegating). Since the client request interface is not in scope of CDNI, we can't specify the parameters in the URL given back to the client (we have to consider the PATH as an opaque string). | 4.6 Error responses method: unsupported client_ip: unsupported type forwarder: unsupported type start_avail: premature expiration: too late | 8. Outstanding considerations We discussed in the FCI design team the ability for the dCDN to advertise an abstract 'footprint' definition associated with a capability. For example, a region might be defined that represents an aggregate geographic footprint as follows: uCDN defines: north_america = CA and US and MX dCDN receives definition in MI: footprint 'north_america' = CA and US and MX Are there any merits in having the uCDN pass via the RI any client location attributes? Certainly, the dCDN could respond with an error if the client location fell outside the boundaries of the contract. Scott --------------030807060108000609020905 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit |4.2

|A single request or response MUST contain only one of the dns or http keys.

A DNS query to the uCDN can't result in an HTTP response to the client.  The client or DNS forwarder needs a DNS response.  Therefore, I see no need for the HTTP key if the RI request type is DNS.

An HTTP query to the uCDN requires an HTTP response to the client.  Certainly, an HTTP response on the RI request is appropriate.  However, a DNS response on the uCDN's RI request using an HTTP key would presumably mean the target of the RI wasn't satisfactorily and the uCDN RR would have to resolve the targets DNS response.  Not sure how valuable that would be.

|[Editor's note: Is the cdn-path useful on responses as well?]

Yes, a uCDN RR that is assessing alternate CDN's in parallel would presumably need to know if the responses of candidate transit dCDN's 'converged' at some point.  Consider the case where uCDN is assessing multiple options:

    a. uCDN -> dCDN-1 -> dCDN-2
    b. uCDN -> dCDN-2

Most likely, the uCDN would want to choose dCDN-2 directly as opposed to using dCDN-1 as a transit.

|[Editor's note: Need some text/section specifying the Media Types for RI requests/responses]

Are you thinking classes of content such as video, audio, images or explicit MIME types?

Are we assuming that the dCDN will only serve a subset of the content classes (e.g. images only, images and audio, but no video)?

|4.3.1

| c-subnet : String : No : The IP address of the UA in CIDR format.

What relevance does this have?  Are we trying to assert some assumed scope (i.e. other clients in the same c-subnet)?  I suspect that this may be RFC1918 space; therefore, its usefulness is suspect.

|4.4.1 HTTP Redirection requests

transaction_id
    integer
    mandatory
    : identifier created by uCDN for correlating request/responses

session_id
    string
    optional? | mandatory?
    : session identifier reflected from proprietary client HTTP request

method:
    string {http | rtsp | rtmp}
    mandatory
    : describes method of request/response

client_ip:
    format {v4 | v6}
    string
    mandatory
    : extracted from HTTP HEADER x-forwarded-for or client request IP

forwarder:
    format {v4 | v6}
    string
    mandatory
    : extracted from HTTP HEADER via or client request IP

start_avail:
    format {epoch | gmt}
    string
    optional
    : extracted from URL of client request

expiration:
    format {epoch | gmt}
    string
    optional
    : extracted from URL of client request

|4.4.2 HTTP Redirection responses

add

transaction_id
    integer
    mandatory
    : identifier created by uCDN for correlating request/responses

session_id
    string
    optional
    : reflection of uCDN session_id or generated by dCDN

method
    string {http | rtsp | rtmp}
    mandatory
    : describes method of request/response

start_avail:
    format {epoch | gmt}
    string
    optional
    : reflection of uCDN start_avail or generated by dCDN

expiration:
    format {epoch | gmt}
    string
    optional
    : reflection of uCDN expiration or generated by dCDN

| 4.5 Indicating the cache-ability and scope of responses

I think this would only be applicable to URL's that are not signed when using the Recursive mode.

I believe most dCDN will want to authenticate each client request.  If we expand the scope of a dCDN response to include a wider range of subnets, that means the uCDN will have to sign URL requests using the chosen dCDN's method and algorithms.  The advantage of the RI interface is that the uCDN does not need to know the methods of each dCDN; the dCDN can sign the URL according to its own rules and simply provide the signed URL PATH back to the uCDN as an opaque string.

[NOTE] In contrast, the Iterative mode requires the uCDN to sign the URL according to the method of the dCDN (or know that a particular URL can remain unsigned when delegating).  Since the client request interface is not in scope of CDNI, we can't specify the parameters in the URL given back to the client (we have to consider the PATH as an opaque string).

| 4.6 Error responses

method:
    unsupported

client_ip:
    unsupported type

forwarder:
    unsupported type

start_avail:
    premature

expiration:
    too late

| 8. Outstanding considerations

We discussed in the FCI design team the ability for the dCDN to advertise an abstract 'footprint' definition associated with a capability.  For example, a region might be defined that represents an aggregate geographic footprint as follows:

uCDN defines:
    north_america = CA and US and MX
dCDN receives definition in MI:
    footprint 'north_america' = CA and US and MX

Are there any merits in having the uCDN pass via the RI any client location attributes? Certainly, the dCDN could respond with an error if the client location fell outside the boundaries of the contract.

Scott





--------------030807060108000609020905-- From flefauch@cisco.com Mon Mar 18 17:46: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 782B321F8A85 for ; Mon, 18 Mar 2013 17:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.301, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swbzLifsKgzG for ; Mon, 18 Mar 2013 17:46:47 -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 603AF21F8AA8 for ; Mon, 18 Mar 2013 17:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42735; q=dns/txt; s=iport; t=1363654007; x=1364863607; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZDGR6HQWD6o9LwLWgKnPwfAZydIFnvU/xh/cKccEN8s=; b=dc6JCi3zVqM/6Lxhh51xgUewrDd/CYE5HikFmx/onNCVdAVQk+oLe/aJ 3GbMKyekBLzUBX7otqeibMpsnfGbN1VgVDQ2h5pbZBumH69FSEcCGhFvQ A1+8ff4/NU+6NSD66izZi7NOHTOalLX9cul6SpCoUQ//I1RXmZ2c6aztk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFADG0R1GtJXG9/2dsb2JhbABDhB2BNrcwiDuBXhZ0giUBAQQBAQEXAQIKRwsQAgEIIhYBBgcnCxQRAgQOBQgBiAsHBbIekBeNRYEaDx4EBwmCVmEDkxiEZYpMhReDCoIo X-IronPort-AV: E=Sophos;i="4.84,868,1355097600"; d="scan'208,217";a="188644170" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 19 Mar 2013 00:46:46 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2J0kknR005638 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 00:46:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 19:46:46 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben Thread-Topic: [CDNi] Comments on draft-he-cdni-routing-request-redirection-03.txt Thread-Index: AQHOG0T5J2AOtdumkUiruFfPchAQmZisk72A Date: Tue, 19 Mar 2013 00:46:45 +0000 Message-ID: References: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> <3F5BB382-1292-4EE4-8621-52C7C5097ACC@niven-jenkins.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.155.152.21] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D3AE1E9xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-he-cdni-routing-request-redirection-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: Tue, 19 Mar 2013 00:46:50 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D3AE1E9xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, (as an Individual) And another comment regarding: " [[Editor's note: What other attributes of the request should we include? METHOD? Version? other headers?]] " I recommend including the ability to pass on any HTTP-header. Example use c= ases include: * select final CDN based on user-agent (e.g. some CDNs maybe know to perfor= m better for some type of streaming) * select final CDN based on X-forwarded-for These parameters are easy to include by uCDN request router and can always = be trivially ignored by dCDN request router. So the impact of adding that i= n the base spec should be minimal. Cheers Francois On 7 Mar 2013, at 07:03, Francois Le Faucheur (flefauch) > wrote: Hello Ben and co-authors, Thanks for addressing my comments. This is definitely going in the right direction. Below are a bunch of comments on the latest version (some editorial, some m= ore significant). Francois Title: "Routing Request Redirection" ---> "Request Routing Redirection Interface= " too many authors * section 1: I would suggest: * compressing/removing the 1st two paragraphs and simply refer to RFC6707 * incorporate here the text that you currently have in the abstract which r= e-explains the break-down of the request routing interface into FCI and RI.= This is the right place to remind the reader of how the Redirection Interf= ace fits in the overall picture. It is also the right place to introduce th= e RI acronym. * section 2: "Examples of an application level redirection are HTTP and RTMP 302 redirec= tions." --> "Examples of an application level redirection are HTTP 302 Redirection = and RTMP 302 Redirection." * section 2: at the end of the HTTP Redirection definition add: "HTTP Redirection is a particular case of Application Level Redirection". *section 3: 1st "Editors' note:. This discusses an interesting point. I suggest in next= rev you replace this with a paragraph that basically says: * how upstream CDN decides which dCDN to talk to via RI is a local policy o= f uCDN and outside the scope of this doc * a typical example would be where the uCDN selects the dCDN for the reques= t, and then queries that dCDN via RI and then redirects to the Redirection = Target. * a more complex example would be where the uCDN selects the dCDN for the = request, and then queries that dCDN via RI and got a reject from dCDN. Then= uCDN selects an alternative dCDN and then queries that dCDN via RI and the= n redirects to the Redirection Target. * yet an even more complex example would be where the uCDN selects two cand= idate dCDNs and queries both via RI before selecting one and using the Redi= rection Target provided by that dCDN. * section 3: "The Redirection Interface operates between a pair of interconnected CDNs." --> " The Redirection Interface operates between the Request Routing system= s of a pair of interconnected CDNs." * everywhere: "Iterative Request Routing" --> "Iterative Request Redirection" "Recursive Request Routing" --> "Recursive Request Redirection" "CDNi" --> "CDNI" * section 3: OLD: " In the case of Recursive Request Routing, an Upstream CDN forwards a CDNI request routing redirection request from a user agent to a Downstream CDN for the Downstream CDN to select a Redirection Target. " NEW: " In the case of Recursive Request Redirection, in order to perform redirecti= on of a request received from a User Agent , the Upstream CDN queries the D= ownstream CDN so that the Downstream CDN can select and provide a Redirecti= on Target. " * section 3: "The initial Upstream CDN->User Agent redirection protocols" --> "The Upstr= eam CDN->User Agent redirection protocols" * "3.1. Discussion on protocol type for CDNI RRRI" there is no "RRRI" acronym defined. * section 3.1: I still have a problem with the content of that section and with Table1. In= particular: * In the 3rd column ("dCDN response"). first the column heading should say = "dCDN RI response". Then , it is misleading to say that the dCDN response i= s "DNS with=85" or "HTTP 302": The dCDN response is actually an RI Response= that allows the uCDN to build a DNS response or a HTTP 302 response. * in the 4th column ("Notes"). It is incorrect to say that "dCDN uses DNS" = or "dCDN uses HTTP redirection" because all you know is that the uCDN will = use DNS or HTTP, but the dCDN could actually decide to use whatever it want= s. For example, the dCDN can provide a CNAME in the RI response that points= to the dCDN request Router. as a result the USer-Agent the uCDN may perfor= m DNS redirection but the dCDN will perform HTTP redirection. This section needs to be cleaned up. The kyy points that have to be conveye= d are: * one protocol (DNS or HTTP) is used between User-Agent and uCDN RR * RI is used between uCDN and dCDN, and dCDN uses that to provide a Redirec= tion Target in the format that is compatible with the protocol used between= User-Agent and uCDN RR * the dCDN has freedom in the Redirection Target it provides. Depending on = the returned Redirection Target, we may see the following scenario: - the request is redirected to the final Surrogate (i.e. no more redirectio= n) - the request is redirected to a request router that will be using a redire= ction protocol (DNS or HTTP) which may be the same as first redirection or = may be different. This is controlled by the dCDN * Section 4: "where the attributes of User Agent's requests" --> "where the attributes o= f a User Agent's request" * section 4: "The general call flow between Request Routers" --> "The general Recursive = Request Redirection message flow between Request Routing systems" * section 4: Figure with message flow - add a Figure Number + Figure Title - the numbers of the steps on the right doe snot match the step description= under the figure * section 4.1: "e.g. URI of the requested content, the client's location information." --> "e.g. URI of the requested content and the client's location informati= on, when those are known by the uCDN Request Routing system." * section 4.1: re Cacheability of the response. I wonder if conveying the cache ability of the response _only_ in standards= HTTP cache-Control mechanism is really the best way to do it, or should we= not also encode it inside the body, just like the scope. I think that has to do with expected implementations of the uCDN Request Ro= uter. If the uCDN RR makes direct use of the cached RI response to process = subsequent requests, then it makes sense to have the cache ability encoded = only in the HTTP headers. If the uCDN RR actually builds a separate table/d= atabase of information derived from the RI responses, then it makes more se= nse to have both cache ability and scope encoded inside the RI response bod= y. Since the RI responses are not easily indexed via a URI (since they are = all posted on the same Redirection Interface URI e.g. rr1.dcdn.example.net/= dcdn/ri ) then I'd expect more the lat= ter type of implementation. No? *4.2 : re JSON encoding Although the trade-offs may not be exactly the same across all Web Services= based CDNI interfaces (RI, MI, Triggers), it would make sense to use the s= ame type of encoding (e.g. JSON or XML) across all the interfaces ; unless = there is really a good reason to not do so. For now, can you add an "Editor's Note" saying that actual choice of encodi= ng is still TBD and all JSON encoding is provided "as an example"? *4.2: "[Maybe a use case is responses is if the dCDN wants to indicate it is prepared to have a DNS redirection directly to it or a HTTP redirection from the uCDN RR to the dCDN and wants to indicate both options in a single response?]] " I would think that the uCDN is the one to choose whether it wants to redire= ct to dCDN via DNS or HTTP. So I don't think the dCDN needs to be able to s= ay it can handle both. However, this makes me think of a potential other requirements: perhaps it = makes sense for the uCDN to influence/control whether the dCDN shoudl be us= ing DNS/HTTP for further redirection. Whether DNS or HTTP redirection is us= ed has visible impact to the enduser and (indirect) impact on the Content P= rovider. So the Content provider may want to impose one mode of redirection= and then the uCDN needs to be able to tell the dCDN whether some mode are = required/forbidden. For example, a Content Provider may want to have only D= NS redirection used so Interconnected CDNs are transparent to endusers (fro= m URI viewpoint). Then the uCDN may need to tell the dCDN that the dCDN oug= ht to pick a Redirection Target that will achieve full DNS redirection (i.e= . the dCDN cannot return as a RT a CNAME who get's resolved as the dCDN RR = IP address). This would call for an additional optional parameter in the RI request indi= cating required (or excluded) downstream redirection protocols. *4.3.1: " o The IP address of the User Agent" --> " o The IP address or prefi= x of the User Agent" On 16 Feb 2013, at 15:57, Ben Niven-Jenkins > wrote: Francois, Closing the loop on this. I've tried to address all your comments in my wor= king copy of draft-he-cdni-routing-request-redirection-04. I will be posting it in the next week once I've got feedback from my co-aut= hors. When it gets published let me know if you feel your comments below haven;t = been addressed. In particular I re-wrote a lot of the document to incorpora= te the concept of Redirection targets and I'd be interested in your views o= n the new text. Ben On 7 Nov 2012, at 14:32, Francois Le Faucheur (flefauch) wrote: Thanks for your responses. Looks like we're synch. Please keep track of tho= se points so they get addressed in the next rev. You may want to bring up some of those today (e.g. need for link to metadat= a in Redirection request) , specifically during the "discussion slot" for R= edirection, so we get input from others. On 6 Nov 2012, at 10:25, Ben Niven-Jenkins wrote: Francois, Please see below for my views. On 5 Nov 2012, at 23:33, Francois Le Faucheur (flefauch) wrote: Hello, (As an Individual). In general, I feel this new version is going in the right direction. Some high level comments: * I think the spec should be less prescriptive as to how a dCDN builds its = redirection response. For example in section 6.1.1, the text says: "If the dCDN decides to use DNS Redirection, where the Downstream CDN is redirecting directly to a surrogate in the Downstream CDN: the Downstream CDN selects one or more surrogates and returns a CDNI RRRI response containing the IP addresses of the selected surrogate(s), ... If the dCDN decides to use DNS Redirection, where the Downstream CDN is redirecting to a Request Router in the dCDN: : the Downstream CDN returns a CDNI RRRI response containing a CNAME of the Downstream CDN's Request Router(s), =85 " In this example, I think the dCDN should be free to return an IP address or= a CNAME of the "redirection target" as it sees fit. The redirection target= may be a Surrogate, a Request Router, a set of Surrogates, a 3rd party CDN= Req Router, a 3rd party CDN Surrogate in case of cascaded CDNs,... whateve= r the dCDN sees fit. You could possibly mention one of the behavior above as an example of what = might happen, but it should just be an example and I recommend the spec be = open as to the logic to populate the Redirection response. Fair comment. Describing the different redirection possibilities & their ap= plicability while at the same time talking about CDNI Redirection in a more= generic way (so we don't keep repeating all the different nuances) was som= ething we struggled a little with and is certainly an area of the draft (IM= O) that needs more work to make the text clearer etc. I like your idea of a 'redirection target' and maybe the right approach is = to have a section defining/discussing the possibilities for redirection (A/= AAAA/CNAME/Application level 302/etc) to a 'redirection target' in a dCDN a= nd in the rest of the document just talk generically about redirection targ= ets? * the document keeps talking about "encapsulating the enduser request" insi= de the Redirection Request. I find this misleading, because this is not abo= ut encapsulating the enduser request per-say, but rather to convey the key = attributes of the enduser request. Fair comment. We used 'encapsulating end user request' to distinguish betwe= en previous versions of the draft where the end user request was proxied to= a dCDN via the same protocol that the end user request was made over. Going forward that history doesn't matter and we should use better language= to describe what we are actually doing. * for HTTP, the Redirection Request should allow passing other attributes i= n addition to client IP address and URI. The draft currently just tries to define the minimum necessary information = for a dCDN to be able to perform a redirection. There are probably other at= tributes that the dCDN would find useful and although it is not explicitly = described in the current draft I think the CDNI Redirection 'protocol frame= work' in draft-he easily allows passing additional optional attributes. Des= cribing how to extend the 'base protocol' with additional attributes is cer= tainly something we should add in a future revision of the draft. Personally, I am reluctant to define lots of theoretical attributes (that n= o one ends up using) to be included in a CDN Redirection request but I woul= d like to hear views from implementors on the attributes they actually use = (or plan to use as part of CDNI) to influence surrogate selection/redirecti= on across a CDN interconnect. * the document requires that a pointer to Metadata be included in the Redir= ection request: "For DNS redirection, the uCDN also needs to provide in the CDNI RRRI request the a link to the associated CDNI Metadata for the host/ domain being requested." Considering that the latest Metadata interface allows the dCDN to walk down= the metadata tree for any content without seeding any initial info/pointer= s, I am not sure there is a benefit in passing a link to metadata inside th= e Redirection request. If would potentially save the dCDN Request Router to= do the lookup on Content-->Metadata , but would require the uCDN Request R= outer to do the same on its behalf. Besides the dCDN has to do that looup a= nyways to get the Metadata for serving the content. This is in my slides for Thursday. When I was thinking about CDN Redirectio= n a while ago I convinced myself a link to CDNI Metadata was useful so when= I started working on draft-he I included it, but since then I've been stru= ggling to remind myself why I originally thought it was required so I'm cer= tainly open to removing it. * the redirection interface will need to discuss handling of URI Signing Sure. Personally I'd like the uri signing/token authorisation work in the W= G to mature a bit more first just to avoid having to keep draft-he aligned = with a still moving target. At a minimum we should include in the next revision a comment that we still= need to factor token authorisation into the document. * we need to agree on a set of acronyms to refer to the "CDNI Request Routi= ng/Redirection Interface". I will bring that up during the meeting this wee= k. OK Ben HTH Francois On 21 Oct 2012, at 23:02, > > wrote: A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : Routing Request Redirection for CDN Interconnection Author(s) : Wang Danhua (editor) He Xiaoyan Spencer Dawkins Ge Chen Ni Wei Zhang Yunfei Ben Niven-Jenkins Filename : draft-he-cdni-routing-request-redirection-03.txt Pages : 19 Date : 2012-10-21 Abstract: The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows a upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI Request Routing Redirection interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redirection There's also a htmlized version available at: http://tools.ietf.org/html/draft-he-cdni-routing-request-redirection-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-he-cdni-routing-request-redirectio= n-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D3AE1E9xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

(as an Individual)

And another comment regarding:
"
 [[Editor's note: What other attributes of the request shoul=
d we
   include?  METHOD?  Version? other headers?]]
"
I recommend including the ability to pass on any HTTP-header. Example = use cases include:
* sele= ct final CDN based on user-agent (e.g. some CDNs maybe know to perform bett= er for some type of streaming)
* = ;select final CDN based on X-forwarded-for 

These parameters are easy to include by uCDN request router and can al= ways be trivially ignored by dCDN request router. So the impact of adding t= hat in the base spec should be minimal.

Cheers

Francois


On 7 Mar 2013, at 07:03, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Hello Ben and co-authors,

Thanks for addressing my comments.

This is definitely going in the right direction.

Below are a bunch of comments on the latest version (some editorial, some m= ore significant).

Francois


Title:
"Routing Request Redirection"  --->  "Request R= outing Redirection Interface"

too many authors

* section 1:
I would suggest:
* compressi= ng/removing the 1st two paragraphs and simply refer to RFC6707
* incorpora= te here the text that you currently have in the abstract which re-explains = the break-down of the request routing interface into FCI and RI. This is th= e right place to remind the reader of how the Redirection Interface fits in the overall picture. It is also the = right place to introduce the RI acronym.

* section 2:
"Examples of an application level redirection are HTTP and RTMP 302 re= directions."
--> "Examples of an application level redirection are HTTP 302 Redi= rection and RTMP 302 Redirection."

* section 2:
at the end of the HTTP Redirection definition add:
"HTTP Redirection is a particular case of Application Level Redirectio= n".

*section 3:
1st "Editors' note:. This discusses an interesting point. I suggest in= next rev you replace this with a paragraph that basically says:
* how upstr= eam CDN decides which dCDN to talk to via RI is a local policy of uCDN and = outside the scope of this doc
* a typical= example would be where the uCDN selects the dCDN for the request, and then= queries that dCDN via RI and then redirects to the Redirection Target.
* a more co= mplex example would be where the  uCDN selects the dCDN for the reques= t, and then queries that dCDN via RI and got a reject from dCDN. Then uCDN = selects an alternative dCDN and then queries that dCDN via RI and then redirects to the Redirection Target.
* yet an ev= en more complex example would be where the uCDN selects two candidate dCDNs= and queries both via RI before selecting one and using the Redirection Tar= get provided by that dCDN.


* section 3:
"The Redirection Interface operates between a pair of interconnected C= DNs."
--> " The Redirection Interface operates between the Request Routin= g systems of a pair of interconnected
  CDNs."


* everywhere:
"Itera= tive Request Routing"  --> "Iterative Request Redirection= "
"Recur= sive Request Routing"   --> "Recursive Request Redir= ection"
"CDNi&= quot; --> "CDNI"

* section 3:
OLD:
"
In the case of Recursive Request Routing, an Upstream CDN forwards a
  CDNI request routing redirection request from a user agent to a=
  Downstream CDN for the Downstream CDN to select a Redirection T= arget.
"
NEW:
"
In the case of Recursive Request Redirection, in order to perform redirecti= on of a request received from a User Agent , the Upstream CDN queries the D= ownstream CDN so that the Downstream CDN can select and provide a Redirecti= on Target.
"


* section 3:
"The initial Upstream CDN->User Agent redirection protocols" -= -> "The Upstream CDN->User Agent redirection protocols"


* "3.1.  Discussion on protocol type for CDNI RRRI"
there is no "RRRI" acronym defined.


* section 3.1:
I still have a problem with the content of that section and with Table1. In= particular:
* In the 3r= d column ("dCDN response"). first the column heading should say &= quot;dCDN RI response". Then , it is misleading to say that the dCDN r= esponse is "DNS with=85" or "HTTP 302": The dCDN respon= se is actually an RI Response that allows the uCDN to build a DNS response or= a HTTP 302 response.
* in the 4t= h column ("Notes"). It is incorrect to say that "dCDN uses D= NS" or "dCDN uses HTTP redirection" because all you know is = that the uCDN will use DNS or HTTP, but the dCDN could actually decide to use whatever it wants. For example, the dCDN can provide a CNAME in the= RI response that points to the dCDN request Router. as a result the USer-A= gent the uCDN may perform DNS redirection but the dCDN will perform HTTP re= direction.
This section needs to be cleaned up. The kyy points that have to be conveye= d are:
* one proto= col (DNS or HTTP) is used between User-Agent and uCDN RR
* RI is use= d between uCDN and dCDN, and dCDN uses that to provide a Redirection Target= in the format that is compatible with the protocol used between User-Agent= and uCDN RR
* the dCDN = has freedom in the Redirection Target it provides. Depending on the returne= d Redirection Target, we may see the following scenario:
- the request is redir= ected to the final Surrogate (i.e. no more redirection)
- the request is redir= ected to a request router that will be using a redirection protocol (DNS or= HTTP) which may be the same as first redirection or may be different. This is controlled by the dCDN   


* Section 4:
"where the attributes of User Agent's requests" --> "wher= e the attributes of a User Agent's request"

* section 4:
"The general call flow between Request Routers" --> "The = general Recursive Request Redirection message flow between Request Routing = systems"

* section 4: Figure with message flow
- add a Fig= ure Number + Figure Title
- the numbe= rs of the steps on the right doe snot match the step description under the = figure

* section 4.1:
"e.g.  URI of the requested content, the client's location inform= ation."
--> "e.g.  URI of the requested content and the client's locat= ion information, when those are known by the uCDN Request Routing system.&q= uot;


* section 4.1: re Cacheability of the response.
I wonder if conveying the cache ability of the response _only_ in standards= HTTP cache-Control mechanism is really the best way to do it, or should we= not also encode it inside the body, just like the scope.
I think that has to do with expected implementations of the uCDN Request Ro= uter. If the uCDN RR makes direct use of the cached RI response to process = subsequent requests, then it makes sense to have the cache ability encoded = only in the HTTP headers. If the uCDN RR actually builds a separate table/database of information derived f= rom the RI responses, then it makes more sense to have both cache ability a= nd scope encoded inside the RI response body. Since the RI responses are no= t easily indexed via a URI (since they are all posted on the same Redirection Interface URI e.g. rr1.dcdn.example.net/dcdn/ri ) then I'd expect more the latter type of = implementation. No?

*4.2 : re JSON encoding
Although the trade-offs may not be exactly the same across all Web Services= based CDNI interfaces (RI, MI, Triggers), it would make sense to use the s= ame type of encoding (e.g. JSON or XML) across all the interfaces ; unless = there is really a good reason to not do so.
For now, can you add an "Editor's Note" saying that actual choice= of encoding is still TBD and all JSON encoding is provided "as an exa= mple"?


*4.2:
"[Maybe a use case is
  responses is if the dCDN wants to indicate it is prepared to ha= ve a
  DNS redirection directly to it or a HTTP redirection from the u= CDN RR
  to the dCDN and wants to indicate both options in a single
  response?]]
"
I would think that the uCDN is the one to choose whether it wants to redire= ct to dCDN via DNS or HTTP. So I don't think the dCDN needs to be able to s= ay it can handle both.
However, this makes me think of a potential other requirements: perhaps it = makes sense for the uCDN to influence/control whether the dCDN shoudl be us= ing DNS/HTTP for further redirection. Whether DNS or HTTP redirection is us= ed has visible impact to the enduser and (indirect) impact on the Content Provider. So the Content provider may= want to impose one mode of redirection and then the uCDN needs to be able = to tell the dCDN whether some mode are required/forbidden. For example, a C= ontent Provider may want to have only DNS redirection used so Interconnected CDNs are transparent to enduse= rs (from URI viewpoint). Then the uCDN may need to tell the dCDN that the d= CDN ought to pick a Redirection Target that will achieve full DNS redirecti= on (i.e. the dCDN cannot return as a RT a CNAME who get's resolved as the dCDN RR IP address).
This would call for an additional optional parameter in the RI request indi= cating required (or excluded) downstream redirection protocols.


*4.3.1:
"   o  The IP address of the User Agent" --> &q= uot;   o  The IP address or prefix of the User Agent"




On 16 Feb 2013, at 15:57, Ben Niven-Jenkins <ben@niven-jenkins.co.uk> wrote:

Francois,

Closing the loop on this. I've tried to address all your comments in my wor= king copy of draft-he-cdni-routing-request-redirection-04.

I will be posting it in the next week once I've got feedback from my co-aut= hors.

When it gets published let me know if you feel your comments below haven;t = been addressed. In particular I re-wrote a lot of the document to incorpora= te the concept of Redirection targets and I'd be interested in your views o= n the new text.

Ben

On 7 Nov 2012, at 14:32, Francois Le Faucheur (flefauch) wrote:

Thanks for your responses. Looks like we're synch= . Please keep track of those points so they get addressed in the next rev.<= br> You may want to bring up some of those today (e.g. need for link to metadat= a in Redirection request) , specifically during the "discussion slot&q= uot; for Redirection, so we get input from others.

On 6 Nov 2012, at 10:25, Ben Niven-Jenkins wrote:

Francois,

Please see below for my views.

On 5 Nov 2012, at 23:33, Francois Le Faucheur (flefauch) wrote:

Hello,

(As an Individual).

In general, I feel this new version is going in the right direction.

Some high level comments:

* I think t= he spec should be less prescriptive as to how a dCDN builds its redirection= response. For example in section 6.1.1, the text says:
"If the dCDN decides to use DNS Redirection, where the Downstream CDN<= br> is redirecting directly to a surrogate in the Downstream CDN: the
Downstream CDN selects one or more surrogates and returns a CDNI RRRI
response containing the IP addresses of the selected surrogate(s), ...
If the dCDN decides to use DNS Redirection, where the Downstream CDN
is redirecting to a Request Router in the dCDN: : the Downstream CDN
returns a CDNI RRRI response containing a CNAME of the Downstream
CDN's Request Router(s), =85
"
In this example, I think the dCDN should be free to return an IP address or= a CNAME of the "redirection target" as it sees fit. The redirect= ion target may be a Surrogate, a Request Router, a set of Surrogates, a 3rd= party CDN Req Router, a 3rd party CDN Surrogate in case of cascaded CDNs,... whatever the dCDN sees fit.
You could possibly mention one of the behavior above as an example of what = might happen, but it should just be an example and I recommend the spec be = open as to the logic to populate the Redirection response.

Fair comment. Describing the different redirection possibilities & thei= r applicability while at the same time talking about CDNI Redirection in a = more generic way (so we don't keep repeating all the different nuances) was= something we struggled a little with and is certainly an area of the draft (IMO) that needs more work to make t= he text clearer etc.

I like your idea of a 'redirection target' and maybe the right approach is = to have a section defining/discussing the possibilities for redirection (A/= AAAA/CNAME/Application level 302/etc) to a 'redirection target' in a dCDN a= nd in the rest of the document just talk generically about redirection targets?

* the document keeps talking about "encapsul= ating the enduser request" inside the Redirection Request. I find this= misleading, because this is not about encapsulating the enduser request pe= r-say, but rather to convey the key attributes of the enduser request.

Fair comment. We used 'encapsulating end user request' to distinguish betwe= en previous versions of the draft where the end user request was proxied to= a dCDN via the same protocol that the end user request was made over.

Going forward that history doesn't matter and we should use better language= to describe what we are actually doing.

* for HTTP, the Redirection Request should allow = passing other attributes in addition to client IP address and URI.

The draft currently just tries to define the minimum necessary information = for a dCDN to be able to perform a redirection. There are probably other at= tributes that the dCDN would find useful and although it is not explicitly = described in the current draft I think the CDNI Redirection 'protocol framework' in draft-he easily allows = passing additional optional attributes. Describing how to extend the 'base = protocol' with additional attributes is certainly something we should add i= n a future revision of the draft.

Personally, I am reluctant to define lots of theoretical attributes (that n= o one ends up using) to be included in a CDN Redirection request but I woul= d like to hear views from implementors on the attributes they actually use = (or plan to use as part of CDNI) to influence surrogate selection/redirection across a CDN interconnect.
* the document requires that a pointer to Metadat= a be included in the Redirection request:
"For DNS redirection, the uCDN also needs to provide in the CDNI RRRI<= br> request the a link to the associated CDNI Metadata for the host/
domain being requested."
Considering that the latest Metadata interface allows the dCDN to walk down= the metadata tree for any content without seeding any initial info/pointer= s, I am not sure there is a benefit in passing a link to metadata inside th= e Redirection request. If would potentially save the dCDN Request Router to do the lookup on Content-->= Metadata , but would require the uCDN Request Router to do the same on its = behalf. Besides the dCDN has to do that looup anyways to get the Metadata f= or serving the content.

This is in my slides for Thursday. When I was thinking about CDN Redirectio= n a while ago I convinced myself a link to CDNI Metadata was useful so when= I started working on draft-he I included it, but since then I've been stru= ggling to remind myself why I originally thought it was required so I'm certainly open to removing it.

* the redirection interface will need to discuss = handling of URI Signing

Sure. Personally I'd like the uri signing/token authorisation work in the W= G to mature a bit more first just to avoid having to keep draft-he aligned = with a still moving target.

At a minimum we should include in the next revision a comment that we still= need to factor token authorisation into the document.

* we need to agree on a set of acronyms to refer = to the "CDNI Request Routing/Redirection Interface". I will bring= that up during the meeting this week.

OK

Ben


HTH

Francois


On 21 Oct 2012, at 23:02, <i= nternet-drafts@ietf.org>
<internet-drafts@ietf.org> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


Title  = ;         : Routing Request Re= direction for CDN Interconnection
Author(s) &= nbsp;     : Wang Danhua (editor)
            &nb= sp;       He Xiaoyan
            &nb= sp;       Spencer Dawkins
            &nb= sp;       Ge Chen
            &nb= sp;       Ni Wei
            &nb= sp;       Zhang Yunfei
            &nb= sp;       Ben Niven-Jenkins
Filename &n= bsp;      : draft-he-cdni-routing-request-red= irection-03.txt
Pages  = ;         : 19
Date  =           : 2012-10-21
Abstract:
The Request Routing Interface comprises of (1) the asynchronous
advertisement of footprint and capabilities by a downstream CDN that
allows a upstream CDN to decide whether to redirect particular user
requests to that downstream CDN; and (2) the synchronous operation of
an upstream CDN requesting whether a downstream CDN is prepared to
accept a user request and of a downstream CDN responding with how to
actually redirect the user request.  This document describes an
interface for the latter part, i.e. the CDNI Request Routing
Redirection interface.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-he-cdni-routing-request-= redirection

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-he-cdni-routing-request-redirection-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-he-cdni-routing-request-redirectio= n-03


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

_______________________________________________
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

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




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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D3AE1E9xmbrcdx10ciscocom_-- From flefauch@cisco.com Fri Mar 22 04:48: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 6208921F849C for ; Fri, 22 Mar 2013 04:48: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=[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 Tvn3qDri6JKK for ; Fri, 22 Mar 2013 04:48:49 -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 914E621F8461 for ; Fri, 22 Mar 2013 04:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=278; q=dns/txt; s=iport; t=1363952929; x=1365162529; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0SohG/p7Oh52/tEcNPFMUtvIpPKr277FFjGXSp/v488=; b=Of7loFBoROs7KSrSUZrqPkZ13XJZGPjd3BqhC82Agm/yazUAjsSUa+15 VpetEBp3R53U/JLdhqbsfzePeMVFzbZ3HRpB/fXYUXBK7S2O0r/8000zH U3/evaST51LErpCHzjj6kwjzK/Lbi2hvIhfubI99lywuWsIFtT+3R0dpB o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8LAFZDTFGtJXG//2dsb2JhbABDh2O+FAIBgWIWbQeCJgEEOlEBKhRCJwQbAYgLDKEEoHIXjk0UgxdhA6dngwqCKA X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="190385285" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 22 Mar 2013 11:48:47 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2MBmk0Q023155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Mar 2013 11:48:46 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 06:48:46 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Draft Minutes for IETF-86 CDNI WG available for review Thread-Index: AQHOJvM1kzPZAE0eoEuyxoG1vLCkkA== Date: Fri, 22 Mar 2013 11:48:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.67] Content-Type: text/plain; charset="us-ascii" Content-ID: <05CB34C4D61F8B49B581B2C656E02632@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Draft Minutes for IETF-86 CDNI WG 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: Fri, 22 Mar 2013 11:48:50 -0000 Folks, Draft Minutes for IETF-86 CDNI WG available at: http://www.ietf.org/proceedings/86/minutes/minutes-86-cdni Please review and provide comments/corrections as needed. Francois PS: Thanks to Kevin Ma and Matt Caulfield for taking notes during the meeti= ngs= From flefauch@cisco.com Fri Mar 22 05:31:57 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 C5B6821F853A for ; Fri, 22 Mar 2013 05:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 LNdsKUXVY1H7 for ; Fri, 22 Mar 2013 05:31:57 -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 2349321F8A41 for ; Fri, 22 Mar 2013 05:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=212; q=dns/txt; s=iport; t=1363955517; x=1365165117; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=aDI6qxWHNfdIA+F3qlMeTLXUTa8TMR46X2vTPhyiFE8=; b=KT7BUPHA6/g8F4FxlifVkGzTnTCOYCVWE80TW2msP8R/HS+9iEhoBmqN 6LaPs7YsqqbH+52oUe7WbZ4ow756nRJZjFhjmh6iTrmI6ojWiC3fj583r orXa1yf5441MEqTt7BlBYEJNrtGiGFrptqxGfRPo2F+dsAghXUXqnvG21 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO1NTFGtJV2d/2dsb2JhbABDxXuBYhZtB4ImAQQ6UQEqFEInBBuIDKEYoGsXjmGDF2EDp2eDCoIo X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="187372456" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 22 Mar 2013 12:31:56 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2MCVu6j025040 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Mar 2013 12:31:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 07:31:56 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Agreement to move cdni-framework to WG Last Call Thread-Index: AQHOJvk9trSesmQyq0y10MIMdXDk0Q== Date: Fri, 22 Mar 2013 12:31:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.67] Content-Type: text/plain; charset="us-ascii" Content-ID: <1213BF443831B949A6DCC0A84F0A0AA7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Agreement to move cdni-framework to WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 12:31:57 -0000 Folks, During IETF-86, the WG tentatively agreed to go to WG Last Call once the ne= xt rev of cdni-framework is posted. If you have concerns/issues with that, = let us know by 5 April 2013.=20 Francois= From flefauch@cisco.com Fri Mar 22 05:33:56 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 BA83021F8A22 for ; Fri, 22 Mar 2013 05:33: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=[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 SEH1JAVxfTR2 for ; Fri, 22 Mar 2013 05:33:56 -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 3E0A821F8A08 for ; Fri, 22 Mar 2013 05:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=215; q=dns/txt; s=iport; t=1363955636; x=1365165236; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=JKbTYkdalNZMEwqdP++EKVAs9svSSMqaQLK367ixCEI=; b=S4CJUPQyR8Or00p4JbQO0Ktjs/BuA04XNir9ho7cgmGn+h7Sw4NkycE1 6JUSSBlMcMH0iDyuyrXjOIDxW7qKaLIfXO+JjLjjdZJzG3MmWpaHY2+R9 /z1Ozwz4K4y3p0ga0wbIfcKExtpQQRmfFFSMbWvl1LKDWQTkoCAmu19QR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGZPTFGtJXG9/2dsb2JhbABDxXuBYhZtB4ImAQQ6UQEqFEInBBuIDKEioGsXjmGDF2EDp2eDCoIo X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="190151339" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 22 Mar 2013 12:33:53 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2MCXrsf019709 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Mar 2013 12:33:53 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 07:33:43 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Agreement to move cdni-requirements to WG Last Call Thread-Index: AQHOJvl88LezkhGhm0mTgLgP/jocBw== Date: Fri, 22 Mar 2013 12:33:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.67] Content-Type: text/plain; charset="us-ascii" Content-ID: <03194E83DBA3294396EB9505C3B8A80E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Agreement to move cdni-requirements to WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 12:33:56 -0000 Folks, During IETF-86, the WG tentatively agreed to go to WG Last Call once the ne= xt rev of cdni-requirements is posted. If you have concerns/issues with tha= t, let us know by 5 April 2013.=20 Francois= From flefauch@cisco.com Fri Mar 22 05:35:49 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 8030821F8AD5 for ; Fri, 22 Mar 2013 05:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 RucdialtUUGy for ; Fri, 22 Mar 2013 05:35:49 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F3D2B21F8A41 for ; Fri, 22 Mar 2013 05:35:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=211; q=dns/txt; s=iport; t=1363955749; x=1365165349; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ycwCU+jR/M+2khoJz0UBLoas0pkt38XhVFdUQ7YZz2U=; b=BVwSmAibT1hElili0s9YWQxIwCOK2z0avE2gTXJvAwypprE2T78cVEU0 G5tskfhKt4TxcKd4303ZoLUkJhSQV4dR3uateNlFg60MPtzmSVwXLIVC1 8s017kXKZGKchKIroe06WzsYVy5jvvnR7O1VhepZ6gA1OlSB0pDSNobbl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKNOTFGtJXG9/2dsb2JhbABDxXuBYhZtB4ImAQQ6UQEqFEInBBuIDKEZoGsXjmGDF2EDp2eDCoIo X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="190365803" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 22 Mar 2013 12:35:29 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2MCZTuo020692 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Mar 2013 12:35:29 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 07:35:29 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Agreement to adopt cdni-triggers as WG document Thread-Index: AQHOJvm8TDoS+BXd8EKrBVo0KZSJoA== Date: Fri, 22 Mar 2013 12:35:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.67] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Agreement to adopt cdni-triggers as WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 12:35:49 -0000 Folks, During IETF-86, the WG tentatively agreed to adopt draft-murray-cdni-trigge= rs-02 as a Working Group document. If you have concerns/issues with that, l= et us know by 5 April 2013.=20 Francois= From flefauch@cisco.com Fri Mar 22 05:37:34 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 105AE21F846C for ; Fri, 22 Mar 2013 05:37:34 -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 nkZc1rl-pJOv for ; Fri, 22 Mar 2013 05:37:32 -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 CC31621F8464 for ; Fri, 22 Mar 2013 05:37:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=226; q=dns/txt; s=iport; t=1363955853; x=1365165453; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wxw+538iQ1TKanVHewXwQTtor4SymPvrNryx9dV2v+s=; b=NSAP/JJtQ07QE6Vubbc0doJybdna13esoomPZDTRKFyxCLm4YCX4xkxA +/SwfDsyt+XJxRbuWXwTLiUkzBxb9LUKMIizOGnf6rjfJxAwD2e+Bb7TW /t3ZJ8TXPD3EbpNm7xYkfmUTxFduKAJpHSkA0sa6PI/8YOAAUwDsxPg6c A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGZPTFGtJV2b/2dsb2JhbABDxXuBYhZtB4ImAQQ6UQEqFEInBBuIDKEioGsXjmGDF2EDp2eDCoIo X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="190364788" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 22 Mar 2013 12:37:32 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2MCbWxw008842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Mar 2013 12:37:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 07:37:32 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Agreement to adopt cdni-routing-request-redirection as WG document Thread-Index: AQHOJvoFYBEfu+PF7UeqmdJ4W+52MQ== Date: Fri, 22 Mar 2013 12:37:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.67] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Agreement to adopt cdni-routing-request-redirection as WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 12:37:34 -0000 Folks, During IETF-86, the WG tentatively agreed to adopt draft-he-cdni-routing-re= quest-redirection-04 as a Working Group document. If you have concerns/issu= es with that, let us know by 5 April 2013.=20 Francois= From flefauch@cisco.com Fri Mar 22 05:39:08 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 F0A7121F8A6F for ; Fri, 22 Mar 2013 05:39:08 -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 aRuFgGREtbK2 for ; Fri, 22 Mar 2013 05:39:06 -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 8963021F8496 for ; Fri, 22 Mar 2013 05:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=221; q=dns/txt; s=iport; t=1363955946; x=1365165546; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=hyierxanixEsW8HN3loZC5q6zLW0/0V6P0osj6J2CEc=; b=Z7+EyO2kw3mB+J859g4uCxnUXoZxuEmhI7aiXkWh/eWxsgKwekq2BSjf 1lpjnTaYqQspixJZZMooJSoNtybrDMmOpmwHI2JuX6SZcojuSu/6sI1FP fl4lmb0Y24JD2z3eQKQg+hQ6+xnSDaXk2NdsjARr+g/DIuFt4OKc8Ipda Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAC9PTFGtJV2Z/2dsb2JhbABDxXuBYhZtB4ImAQQ6UQEqFEInBBuIDKEfoGsXjmGDF2EDp2eDCoIo X-IronPort-AV: E=Sophos;i="4.84,891,1355097600"; d="scan'208";a="187374750" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 22 Mar 2013 12:38:58 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r2MCcwHA004561 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 22 Mar 2013 12:38:58 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Fri, 22 Mar 2013 07:38:58 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Agreement to adopt cdni-rr-foot-cap-semantics-04 as WG document Thread-Index: AQHOJvo4j53/BloLiEqLsNC3F78Ghg== Date: Fri, 22 Mar 2013 12:38:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.105.67] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Agreement to adopt cdni-rr-foot-cap-semantics-04 as WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 12:39:09 -0000 Folks, During IETF-86, the WG tentatively agreed to adopt draft-spp-cdni-rr-foot-c= ap-semantics-04 as a Working Group document. If you have concerns/issues wi= th that, let us know by 5 April 2013.=20 Francois= From flefauch@cisco.com Sat Mar 30 02:50:24 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 3159E21F884F for ; Sat, 30 Mar 2013 02:50:24 -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 EPIcY-Z0H6F9 for ; Sat, 30 Mar 2013 02:50:22 -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 1D30021F874B for ; Sat, 30 Mar 2013 02:50:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26123; q=dns/txt; s=iport; t=1364637022; x=1365846622; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sH/cWwzM4kZ10UUmFfX+ger+C9kQAEphdZoFVd4hHaY=; b=fE5tO4GakCIzVMBHGWSLURePFT9ztN2fTZFr5UeFOm2XUWp0r4tjT61e FYq0JVf0XvyFyKVvfxBXxZ6MZnqVgtfAVvp8CsLMd758W77CUpbXM24e/ nOT5ImVN4ZPUoulq3i7k/95fXKybJvfZTVrBOuHYDGelSMpChtB+07kmX I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAKm0VlGtJXHA/2dsb2JhbABDgzpBvyiBDxZ0gh8BAQEBAgEBAQEXIDQCBAUFBwQCARkBAwEBAQoUCQcnCxQDBggCBAoEBQgBEodzBgcFv0GNZg8GeyYLAgUGgllhA5gKj2yDC4FrAQcXAQUY X-IronPort-AV: E=Sophos;i="4.87,378,1363132800"; d="scan'208";a="192944704" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 30 Mar 2013 09:50:21 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2U9oLqp016661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 30 Mar 2013 09:50:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.195]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Sat, 30 Mar 2013 04:50:20 -0500 From: "Francois Le Faucheur (flefauch)" To: "Kent Leung (kleung)" Thread-Topic: Comments on draft-ietf-cdni-requirements-05.txt Thread-Index: AQHOLSv9aBLjbrhBMEqVd2LAvpipbQ== Date: Sat, 30 Mar 2013 09:50:19 +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.199] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Comments on draft-ietf-cdni-requirements-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 09:50:24 -0000 Hi Kent and all, In addition to the comment already discussed below, here are my remaining c= omments (as an Individual): OLD: " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information ... " NEW: " GEN-4 [HIGH] The CDNI solution shall not depend on intra-CDN information ... " OLD: " GEN-5 [HIGH] The CDNI solution shall support delivery to the user agent based on HTTP [RFC2616]. (Note that while delivery and acquisition "data plane" protocols are out of the CDNI solution scope, the CDNI solution "control plane" protocols are expected to participate in enabling, selecting or facilitating operations of such acquisition and delivery protocols. Hence it is useful to state requirements on the CDNI solution in terms of which acquisition and delivery protocols). GEN-6 [HIGH] The CDNI solution shall support acquisition across CDNs based on HTTP [RFC2616]. " NEW: " GEN-5 [HIGH] The CDNI solution shall support delivery to the user agent based on HTTP [RFC2616]. =20 GEN-6 [HIGH] The CDNI solution shall support acquisition across CDNs based on HTTP [RFC2616]. (Note that while delivery and acquisition "data plane" protocols are out of= the CDNI solution scope, the CDNI solution "control plane" protocols are e= xpected to participate in enabling, selecting or facilitating operations of= such acquisition and delivery protocols. Hence it is useful to state requ= irements on the CDNI solution in terms of which acquisition and delivery pr= otocols). " (Rationale: the note applies to both GEN-5 and GEN-6) Regarding: " GEN-13 Removed. " I suggest you just remove altogether the requirements that were dropped and= renumber the following ones to avoid gaps. Regarding: " CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream CDN to request that the Downstream CDN (and, if cascaded CDNs are supported by the solution, that the potential cascaded Downstream CDNs) perform the following actions on an object or object set: * Mark an object or set of objects and/or its CDNI metadata as "stale" and revalidate them before they are delivered again * Delete an object or set of objects and/or its CDNI metadata from the CDN surrogates and any storage. Only the object(s) and CDNI metadata that pertain to the requesting Upstream CDN are allowed to be purged. " It is clear to me that the 2nd bullet is a [HIGH].=20 But it is not clear to me that the first bullet is really a [HIGH]. I see i= t as an optimisation, not a must-have. I'd rate it as a [MID] or [LOW]. In = fact, does the "triggers" interface actually cope for that ? Perhaps you can split the two bullets so they can have a different priority= level. Regarding: " CNTL-3 [HIGH] The CDNI Control interface shall support initiation and control by the Upstream CDN of pre-positioned CDNI metadata acquisition by the Downstream CDN. " I thought we have agreed that pre-positioning would be a [MED] whether cont= ent or metadata. CNTL-4 is already a [MED]. I suggest making CNTL-3 a [MED]= also. Regarding: " CNTL-10 [LOW] The CDNI Control interface may allow exchange and negotiation of delivery authorization mechanisms to be supported across the CDNs (e.g. URI signature based validation). " This functionality has moved to the FCI. How about, you move this functiona= lity with the rest of the text discussing the FCI requirements? Regarding: " CNTL-12 [MED] The CDNI Control interface should allow for multiple content items identified by a Content Collection ID to be purged using a single Content Purge action. " I suggest moving this requirement up so it follows the first purge-related = requirements i.e. place it right after CNTL-1. Regarding Section 5: I strongly recommend that: * you split this into separate sections for RI and FCI.=20 * in each requirement, you mention the actual interface (i.e. RI or FCI) i= nstead of "the Request Routing Interface". It will make it much easier to read, and much more useful so we know which = requirements applies to which interface. Regarding REQ-15 and "[Ed: chunk is treated as any content, is this needed?= ]" I vote for keeping it in. Explicit is better.=20 Regarding REQ-16 and REQ-17: I vote for [LOW]. I see Manifest-file-Manipula= tion approaches as nice-to-allow but not [MED]. Regarding REQ-19: it is a [MED] but you use "may". I think it shoudl say "s= hould" for a [MED]. BTW: at the very end of editing , you should probably do a pass and check t= he shall/should/may correspond to HIGH/MED/LOW in each and every requiremen= t. e.g. there is also a mismatch in REQ-20. Regarding REQ-20: The list of capabilities here is a little out of date (e.g. "support for cu= stomised CDNI logging" - which is dropped) and only covers the ones related= to logging while it shoudl bring up the other ones (e.g. delivery protocol= ). Since the actual capabilities are discussed in the FCI semantics draft, = I would suggest not trying to list specific capabilities in that requiremen= t, and instead keep it high level and probably just list the types of capab= ilities (e.g. mention it needs to cover capabilities associated with loggin= g, with distribution protocols, with acquisition protocols, etc..) OLD: " META-7 [HIGH] The CDNI Metadata Distribution interface shall allow the Upstream CDN to request addition and modification of CDNI Metadata into the Downstream CDN. " NEW: " META-7 [HIGH] The CDNI Metadata Distribution interface (possibly in conju= nction with the CDNI Control interface) shall allow the Upstream CDN to request addition and modification of CDNI Metadata into the Downstream CDN. " OLD: " META-8 [HIGH] The CDNI Metadata Distribution interface shall allow removal of obsolete CDNI Metadata from the Downstream CDN (this could, for example, be achieved via an explicit removal request from the Upstream CDN or via expiration of a Time-To-Live associated to the Metadata). " NEW: " META-8 [HIGH] The CDNI Metadata Distribution interface (possibly in conju= nction with the CDNI Control interface) shall allow removal of obsolete CDNI Metadata from the Downstream CDN (this could, for example, be achieved via an explicit removal request from the Upstream CDN or via expiration of a Time-To-Live associated to the Metadata). " OLD: " META-15 [HIGH] The CDNI Metadata interface shall be able to exchange a set of well-accepted metadata elements with specified semantics (e.g. start of time window, end of time window). " NEW: " META-15 [HIGH] The CDNI Metadata interface shall be able to exchange a set of metadata elements with specified semantics (e.g. start of time window, end of time window). " Regarding META-18: see thread below. Regarding META-20: As documented in http://www.ietf.org/mail-archive/web/cd= ni/current/msg01375.html, it is felt that this requirement shoudl not be pu= rsued for initial deliverables. Besides, there was no hard conclusion as to= whether this would belong to MI or CI. This requirement should be a [MED] = (instead of a [HIGH]) and I suggest you add a note indicating that there is= still some thinking to be done to conclude whether this should really be M= I or CI. OLD: " LOG-1 [HIGH] The CDNI logging architecture and interface shall ensure reliable logging of CDNI events. " NEW: " LOG-1 [HIGH] The CDNI logging architecture and interface shall ensure reliable transfer of CDNI logging information across CDNs= . " OLD: " LOG-7 [HIGH] The CDNI Logging interface shall define a log file format and a set of fields to be exported through the Logging protocol, with some granularity (e.g. On a per content type basis). " NEW: " LOG-7 [HIGH] The CDNI Logging interface shall define a log file format and a set of fields to be exported for various CDNI loggi= ng events. " re LOG-8: s/mechanisms/mechanism/ re LOG-14: This requirement should be removed since it is already covered by another r= equirement on the CI. OLD: " LOG-17 [HIGH] The CDNI Logging interface shall support the notification from Downstream CDN to Upstream CDN for the event that the logging retention duration or maximum size of logging data has exceeded. " NEW: " LOG-17 [HIGH] The CDNI Logging interface shall allow a CDN to notify anoth= er CDN about which CDNI logging information is available for transfer (and/= or no longer available, say because it exceeded some logging retention peri= od or some logging retention volume). " Rationale: The current wording was overly prescriptive. I think the key poi= nt is that the CDNs should inform each other about which info can be obtain= ed.=20 OLD: " LOG-18 [MED] The CDNI Logging interface should support the ability for the Downstream CDN to include the Content Collection ID and Session ID fields in CDNI log entries generated for HTTP Adaptive Streaming content. This fields can be supported by the "customizable" log format which is expected to be defined independently of HTTP Adaptive Streaming. " NEW: " LOG-18 [MED] The CDNI Logging interface should support the ability for the Downstream CDN to include the Content Collection ID and Session ID fields in CDNI log entries generated for HTTP Adaptive Streaming content. " Rationale: again custom log likely not supported initially. Francois On 12 Mar 2013, at 17:53, Kent Leung (kleung) wrote: > Hi Francois. Comments below in "KL>". >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch)=20 > Sent: Tuesday, March 12, 2013 7:08 AM > To: Kent Leung (kleung) > Cc: cdni@ietf.org > Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt >=20 > Kent and all, >=20 > I have received consistent feed-back from two CDN operators and a Content= Provider that the CDNI solution ought to support: > *A* enforcement of caching directives by dCDN that are different to the = ones signalled in the HTTP headers > *B* choice of ignoring/factoring query string in dCDN caching > *C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive Downl= oad)=20 >=20 > *A* and *B* are already mostly covered in META-18 but it is listed as [LO= W]. I would recommend we raise META-18 to [MED]. >=20 > KL> That sounds reasonable to me. Unless others object, this requirement = will be set to MED priority in the next version. >=20 > I don't think *C* is covered. I would recommend we add rate-pacing as a 3= rd example of "surrogate cache behaviour" in META-18.=20 >=20 > KL> I can see some value of this feature. I'll see how the debate settles= before updating the draft. >=20 > I will bring this up in the CDNI session today, but wanted to give folks = some heads-up. >=20 > KL> Thanks for the heads up. >=20 > I also have other comments on -05 which I will either pass on to Kent dir= ectly or post on the list. >=20 > KL> Thanks. >=20 > Kent >=20 >=20 > Cheers >=20 > Francois >=20 >=20 >=20 > " > META-18 [LOW] The CDNI Metadata Distribution interface may allow > signaling of CDNI-relevant surrogate cache behavior > parameters. For example, this could potentially include: >=20 > * control of whether the query string of HTTP URI is to be > ignored by surrogate cache >=20 > * content revalidation parameters (e.g. TTL) > " >=20 >=20 > On 6 Mar 2013, at 18:08, Kent Leung (kleung) wrote: >=20 >> Hi folks. The requirements draft was updated based on the feedback from = the authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), d= raft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-loggi= ng. >>=20 >> In preparation for the next WG session, the edits were published in the = draft for review. Please provide your comments to the list of requirement c= hanges below. Thanks. >>=20 >> 1. New CDNI Control Interface requirement >>=20 >> a. Based on recommendations in ID-HAS, CCID is introduced for HAS= content without the need for HAS-aware CDN. >>=20 >> CNTL-12 [MED] The CDNI Control interface should allow for multip= le=09 >> content items identified by a Content Collection ID to be=09 >> purged using a single Content Purge action. >>=20 >> 2. New CDNI Request Routing Interface requirements >>=20 >> a. This is an explicit requirement for RRI to support per-chunk = request routing. Since the chunk is same as any content, it's not clear if = the requirement is needed? >>=20 >> REQ-15 [HIGH] The CDNI Request-Routing interface shall allow fo= r=09 >> per-chunk request routing of HTTP Adaptive Streaming content= .=09 >> [Ed: chunk is treated as any content, is this needed?]=09 >> =09 >> b. Manifest rewrite by uCDN is considered as optional feature in= the ID-HAS, should the priority be LOW instead of MED? >>=20 >> REQ-16 [MED] The CDNI Request-Routing interface should allow th= e=09 >> Upstream CDN to use the information conveyed by the=09 >> Downstream CDN during the Recursive Request Routing process= =09 >> to rewrite an HTTP Adaptive Streaming manifest file. [Ed:=09 >> should this be LOW?]=09 >>=20 >> c. Manifest rewrite by uCDN for URI Signing is considered as op= tional feature in the ID-HAS, should the priority be LOW instead of MED? >> =09 >> REQ-17 [MED] The CDNI Request-Routing interface should allow t= he=09 >> Upstream CDN to re-sign the invariant portion of the chunk=09 >> URIs embedded in the HTTP Adaptive Streaming manifest file.= =09 >> [Ed: should this be LOW?]=09 >> =09 >> d. Use of cookie for URI Signing is is considered as optional fe= ature in the ID-HAS, should the priority be LOW instead of MED? >>=20 >> REQ-18 [MED] The CDNI Request-routing interface should allow th= e use=09 >> of HTTP cookie to associate the chunks with the HTTP Adaptiv= e=09 >> Stream manifest file (which is verified by the URI signature= )=09 >> basedon the Authorization Group ID (which is an identifier=09 >> used to correlate the manifest file to the related chunks).= =09 >> [Ed: should this be LOW?]=09 >>=20 >> e. LOW instead of MED priority?=09 >>=20 >> REQ-19 [MED] The CDNI Request-Routing interface may allow for a= n=09 >> efficient method of transferring request routing information= =09 >> for multiple chunks from the Downstream CDN to the Upstream= =09 >> CDN as part of the recursive request routing process. [Ed:= =09 >> should this be LOW?]=09 >> =09 >> f. Based on ID-HAS and logging drafts, the following requirement= was introduced to log HAS content and customization of the logging. >> =09 >> REQ-20 [MED] The CDNI Request-Routing/Footprint and Advertising= =09 >> interface shall support advertisement of the following=09 >> capabilities:=09 >> =09 >> * support for customized CDNI Logging=09 >> =09 >> * support of Content Collection ID logging=09 >> =09 >> * support for Session ID logging >>=20 >> 3. Removed CDNI Metadata Distribution Interface requirement. >>=20 >> a. Based on the metadata draft, there is no need for dCDN to ind= icate to the uCDN the result of delivering the metadata since the "pull" or= "triggered pull" model is used (i.e. dCDN request for metadata from uCDN). >>=20 >> META-13 [HIGH] The CDNI Metadata Distribution interface shall =09 >> provide indication by the Downstream CDN to the Upstream CDN = =09 >> of whether the CDNI metadata (and corresponding future =09 >> request redirections) is accepted or rejected. When =09 >> rejected, the CDNI Metadata Distribution protocol Must allow = =09 >> the Downstream CDN to provide information about the cause of = =09 >> the rejection. =09 >>=20 >> 4. New CDNI Metadata Distribution Interface requirements >>=20 >> a. Based on ID-HAS's recommendations, this is introduced. >>=20 >> META-19 [HIGH] The CDNI Metadata interface shall provide indicati= on=09 >> of related content (e.g. HTTP Adaptive Bit Rate chunks) by= =09 >> the Content Collection ID (CCID) metadata. This could be=09 >> used by the Downstream CDN for operations on the group of=09 >> content. For example, this could potentially include:=09 >> =09 >> * content acquisition for the entire set of files when on= e=09 >> piece of content is requested=09 >> =09 >> * local file management and storage bundles all the files= =09 >> for the content=09 >> =09 >> * purging the entire set of files associated with the=09 >> content=09 >> =09 >> * logging of the delivery of the content for the session= =09 >> when at least one file in the set was delivered=09 >> =09 >> b. Based on the logging draft, this is introduced. >>=20 >> META-20 [HIGH] The CDNI Metadata Distribution interface shall=09 >> support an OPTIONAL mechanism allowing the Upstream CDN to= =09 >> indicate to the Downstream CDN which CDNI Log fields are to= =09 >> be provided for all, for specific sets of, or for specific= =09 >> content items delivered using HTTP. A CDNI implementation= =09 >> that does not support this optional CDNI Metadata=09 >> Distribution Interface mechanism MUST ignore this log forma= t=09 >> indication and generate CDNI logging format for HTTP=09 >> Adaptive Streaming using the default set of CDNI Logging=09 >> fields.=09 >> =09 >> c. Based on the ID-HAS's recommendations, this is introduced. >>=20 >> META-21 [MED] The CDNI Metadata Distribution interface shall allo= w=09 >> the Upstream CDN to signal to the Downstream CDN the Conten= t=09 >> Collection ID value for all, for specific sets of, or for=09 >> specific content items delivered using HTTP. Whenever the= =09 >> Downstream CDN is instructed by the Upstream CDN to report= =09 >> the Content Collection ID field in the log records, the=09 >> Downstream CDN is to use the value provided through the CDN= I=09 >> Metadata interface for the corresponding content. Note the= =09 >> Session ID field along with Content Collection ID may be=09 >> used for HTTP Adaptive Streaming content.=09 >> =09 >> d. Based on ID-HAS's recommendations, this is introduced. >>=20 >> META-22 [MED] The CDNI Metadata Distribution interface shall allo= w=09 >> the Upstream CDN to signal to the Downstream CDN the=09 >> Authorization Group ID value for all the related HTTP=09 >> Adaptive Streamin content (i.e. manifest file and chunks).= =09 >> The authorization result of a content (e.g. manifest file)= =09 >> is transferred over to related content (e.g. chunks). [Ed:= =09 >> need to improve wording?] >>=20 >> 5. Remove CDNI Logging Interface requirement >>=20 >> a. It is deemed unnecessary for dCDN to obtain logs from uCDN, whi= ch has access to all the logs for trouble-shooting and auditing. >>=20 >> LOG-4 [HIGH] The CDNI Logging interface shall provide logging of =09 >> distribution performed by the Upstream CDN as a result of =09 >> acquisition request by the Downstream CDN. >>=20 >> 6. Add CDNI Logging Interface requirements >>=20 >> a. Based on the logging draft, this is introduced. >>=20 >> LOG-17 [HIGH] The CDNI Logging interface shall support the=09 >> notification from Downstream CDN to Upstream CDN for the=09 >> event that the logging retention duration or maximum size of= =09 >> logging data has exceeded.=09 >> =09 >> b. Based on the ID-HAS, CCID is a field to report in the log. Al= so, based on the logging draft, Session ID is another field needed in the l= og. >>=20 >> LOG-18 [MED] The CDNI Logging interface should support the abil= ity=09 >> for the Downstream CDN to include the Content Collection ID= =09 >> and Session ID fields in CDNI log entries generated for HTTP= =09 >> Adaptive Streaming content. This fields can be supported by= =09 >> the "customizable" log format which is expected to be define= d=09 >> independently of HTTP Adaptive Streaming. >>=20 >> Kent >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of = internet-drafts@ietf.org >> Sent: Saturday, February 23, 2013 1:16 PM >> To: i-d-announce@ietf.org >> Cc: cdni@ietf.org >> Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Content Delivery Networks Interconnecti= on Working Group of the IETF. >>=20 >> Title : Content Distribution Network Interconnection (CDNI) R= equirements >> Author(s) : Kent Leung >> Yiu Lee >> Filename : draft-ietf-cdni-requirements-05.txt >> Pages : 23 >> Date : 2013-02-23 >>=20 >> Abstract: >> Content Delivery Networks (CDNs) are frequently used for large-scale >> content delivery. As a result, existing CDN providers are scaling up >> their infrastructure and many Network Service Providers (NSPs) are >> deploying their own CDNs. There is a requirement for interconnecting >> standalone CDNs so that their collective CDN footprint can be >> leveraged for the end-to-end delivery of content from Content Service >> Providers (CSPs) to end users. The Content Distribution Network >> Interconnection (CDNI) working group has been chartered to develop an >> interoperable and scalable solution for such CDN interconnection. >>=20 >> The goal of the present document is to outline the requirements for >> the solution and interfaces to be specified by the CDNI working >> group. This draft is a work in progress and requirements may be >> added, modified, or removed by the working group. >>=20 >> Requirements Language >>=20 >> The key words "High Priority", "Medium Priority" and "Low Priority" >> in this document are to be interpreted in the following way: >>=20 >> o "High Priority" indicates requirements that are to be supported by >> the CDNI interfaces. A requirement is stated as "High Priority" >> when it is established by the working group that it can be met >> without compromising the targeted schedule for WG deliverables, or >> when it is established that specifying a solution without meeting >> this requirement would not make sense and would justify re- >> adjusting the WG schedule, or both. This is tagged as "[HIGH]". >>=20 >> o "Medium Priority" indicates requirements that are to be supported >> by the CDNI interfaces unless the WG realizes at a later stage >> that attempting to meet this requirement would compromise the >> overall WG schedule (for example it would involve complexities >> that would result in significantly delaying the deliverables). >> This is tagged as "[MED]". >>=20 >> o "Low Priority" indicates requirements that are to be supported by >> the CDNI interfaces provided that dedicating WG resources to this >> work does not prevent addressing "High Priority" and "Medium >> Priority" requirements and that attempting to meet this >> requirement would not compromise the overall WG schedule. This is >> tagged as "[LOW]". >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-cdni-requirements-05 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-05 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From ben@niven-jenkins.co.uk Sun Mar 31 09:42:07 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 A478221F85EB for ; Sun, 31 Mar 2013 09:42:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.149 X-Spam-Level: X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK9p1xwhC2bW for ; Sun, 31 Mar 2013 09:42:05 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4287021F85DC for ; Sun, 31 Mar 2013 09:42:04 -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 1UMLKU-0006mc-Uj; Sun, 31 Mar 2013 17:42:04 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Sun, 31 Mar 2013 17:41:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <532216A5-90EA-43FA-813A-64AB7F70F4A7@niven-jenkins.co.uk> References: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> <3F5BB382-1292-4EE4-8621-52C7C5097ACC@niven-jenkins.co.uk> 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] Comments on draft-he-cdni-routing-request-redirection-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, 31 Mar 2013 16:42:07 -0000 Francois, On 19 Mar 2013, at 00:46, Francois Le Faucheur (flefauch) wrote: > Hi, >=20 > (as an Individual) >=20 > And another comment regarding: > " > [[Editor's note: What other attributes of the request should we > include? METHOD? Version? other headers?]] >=20 > " > I recommend including the ability to pass on any HTTP-header. Example = use cases include: > * select final CDN based on user-agent (e.g. some CDNs maybe know to = perform better for some type of streaming) > * select final CDN based on X-forwarded-for=20 >=20 > These parameters are easy to include by uCDN request router and can = always be trivially ignored by dCDN request router. So the impact of = adding that in the base spec should be minimal. As per discussion/agreement in Orlando, I've added a generic mechanism = for uCDN to signal User Agent headers to dCDN in my working copy of = draft-he-cdni-routing-request-redirection-05. Ben >=20 > Cheers >=20 > Francois >=20 >=20 > On 7 Mar 2013, at 07:03, Francois Le Faucheur (flefauch) = wrote: >=20 >> Hello Ben and co-authors, >>=20 >> Thanks for addressing my comments. >>=20 >> This is definitely going in the right direction. >>=20 >> Below are a bunch of comments on the latest version (some editorial, = some more significant). >>=20 >> Francois >>=20 >>=20 >> Title:=20 >> "Routing Request Redirection" ---> "Request Routing Redirection = Interface" >>=20 >> too many authors >>=20 >> * section 1: >> I would suggest: >> * compressing/removing the 1st two paragraphs and simply refer to = RFC6707 >> * incorporate here the text that you currently have in the abstract = which re-explains the break-down of the request routing interface into = FCI and RI. This is the right place to remind the reader of how the = Redirection Interface fits in the overall picture. It is also the right = place to introduce the RI acronym. >>=20 >> * section 2: >> "Examples of an application level redirection are HTTP and RTMP 302 = redirections." >> --> "Examples of an application level redirection are HTTP 302 = Redirection and RTMP 302 Redirection." >>=20 >> * section 2: >> at the end of the HTTP Redirection definition add: >> "HTTP Redirection is a particular case of Application Level = Redirection". >>=20 >> *section 3: >> 1st "Editors' note:. This discusses an interesting point. I suggest = in next rev you replace this with a paragraph that basically says: >> * how upstream CDN decides which dCDN to talk to via RI is a local = policy of uCDN and outside the scope of this doc >> * a typical example would be where the uCDN selects the dCDN for the = request, and then queries that dCDN via RI and then redirects to the = Redirection Target. >> * a more complex example would be where the uCDN selects the dCDN = for the request, and then queries that dCDN via RI and got a reject from = dCDN. Then uCDN selects an alternative dCDN and then queries that dCDN = via RI and then redirects to the Redirection Target. >> * yet an even more complex example would be where the uCDN selects = two candidate dCDNs and queries both via RI before selecting one and = using the Redirection Target provided by that dCDN. >>=20 >>=20 >> * section 3: >> "The Redirection Interface operates between a pair of interconnected = CDNs." >> --> " The Redirection Interface operates between the Request Routing = systems of a pair of interconnected >> CDNs." >>=20 >>=20 >> * everywhere: >> "Iterative Request Routing" --> "Iterative Request Redirection"=20 >> "Recursive Request Routing" --> "Recursive Request Redirection" >> "CDNi" --> "CDNI" >>=20 >> * section 3: >> OLD: >> " >> In the case of Recursive Request Routing, an Upstream CDN forwards a >> CDNI request routing redirection request from a user agent to a >> Downstream CDN for the Downstream CDN to select a Redirection = Target. >> " >> NEW: >> " >> In the case of Recursive Request Redirection, in order to perform = redirection of a request received from a User Agent , the Upstream CDN = queries the Downstream CDN so that the Downstream CDN can select and = provide a Redirection Target. >> " >>=20 >>=20 >> * section 3: >> "The initial Upstream CDN->User Agent redirection protocols" --> "The = Upstream CDN->User Agent redirection protocols" >>=20 >>=20 >> * "3.1. Discussion on protocol type for CDNI RRRI" >> there is no "RRRI" acronym defined. >>=20 >>=20 >> * section 3.1: >> I still have a problem with the content of that section and with = Table1. In particular: >> * In the 3rd column ("dCDN response"). first the column heading = should say "dCDN RI response". Then , it is misleading to say that the = dCDN response is "DNS with=85" or "HTTP 302": The dCDN response is = actually an RI Response that allows the uCDN to build a DNS response or = a HTTP 302 response. >> * in the 4th column ("Notes"). It is incorrect to say that "dCDN uses = DNS" or "dCDN uses HTTP redirection" because all you know is that the = uCDN will use DNS or HTTP, but the dCDN could actually decide to use = whatever it wants. For example, the dCDN can provide a CNAME in the RI = response that points to the dCDN request Router. as a result the = USer-Agent the uCDN may perform DNS redirection but the dCDN will = perform HTTP redirection. >> This section needs to be cleaned up. The kyy points that have to be = conveyed are: >> * one protocol (DNS or HTTP) is used between User-Agent and uCDN RR >> * RI is used between uCDN and dCDN, and dCDN uses that to provide a = Redirection Target in the format that is compatible with the protocol = used between User-Agent and uCDN RR >> * the dCDN has freedom in the Redirection Target it provides. = Depending on the returned Redirection Target, we may see the following = scenario: >> - the request is redirected to the final Surrogate (i.e. no more = redirection) >> - the request is redirected to a request router that will be using a = redirection protocol (DNS or HTTP) which may be the same as first = redirection or may be different. This is controlled by the dCDN =20 >>=20 >>=20 >> * Section 4: >> "where the attributes of User Agent's requests" --> "where the = attributes of a User Agent's request" >>=20 >> * section 4: >> "The general call flow between Request Routers" --> "The general = Recursive Request Redirection message flow between Request Routing = systems" >>=20 >> * section 4: Figure with message flow >> - add a Figure Number + Figure Title >> - the numbers of the steps on the right doe snot match the step = description under the figure >>=20 >> * section 4.1: >> "e.g. URI of the requested content, the client's location = information." >> --> "e.g. URI of the requested content and the client's location = information, when those are known by the uCDN Request Routing system." >>=20 >>=20 >> * section 4.1: re Cacheability of the response. >> I wonder if conveying the cache ability of the response _only_ in = standards HTTP cache-Control mechanism is really the best way to do it, = or should we not also encode it inside the body, just like the scope. >> I think that has to do with expected implementations of the uCDN = Request Router. If the uCDN RR makes direct use of the cached RI = response to process subsequent requests, then it makes sense to have the = cache ability encoded only in the HTTP headers. If the uCDN RR actually = builds a separate table/database of information derived from the RI = responses, then it makes more sense to have both cache ability and scope = encoded inside the RI response body. Since the RI responses are not = easily indexed via a URI (since they are all posted on the same = Redirection Interface URI e.g. rr1.dcdn.example.net/dcdn/ri ) then I'd = expect more the latter type of implementation. No? >>=20 >> *4.2 : re JSON encoding >> Although the trade-offs may not be exactly the same across all Web = Services based CDNI interfaces (RI, MI, Triggers), it would make sense = to use the same type of encoding (e.g. JSON or XML) across all the = interfaces ; unless there is really a good reason to not do so. >> For now, can you add an "Editor's Note" saying that actual choice of = encoding is still TBD and all JSON encoding is provided "as an example"? >>=20 >>=20 >> *4.2: >> "[Maybe a use case is >> responses is if the dCDN wants to indicate it is prepared to have a >> DNS redirection directly to it or a HTTP redirection from the uCDN = RR >> to the dCDN and wants to indicate both options in a single >> response?]] >> " >> I would think that the uCDN is the one to choose whether it wants to = redirect to dCDN via DNS or HTTP. So I don't think the dCDN needs to be = able to say it can handle both. >> However, this makes me think of a potential other requirements: = perhaps it makes sense for the uCDN to influence/control whether the = dCDN shoudl be using DNS/HTTP for further redirection. Whether DNS or = HTTP redirection is used has visible impact to the enduser and = (indirect) impact on the Content Provider. So the Content provider may = want to impose one mode of redirection and then the uCDN needs to be = able to tell the dCDN whether some mode are required/forbidden. For = example, a Content Provider may want to have only DNS redirection used = so Interconnected CDNs are transparent to endusers (from URI viewpoint). = Then the uCDN may need to tell the dCDN that the dCDN ought to pick a = Redirection Target that will achieve full DNS redirection (i.e. the dCDN = cannot return as a RT a CNAME who get's resolved as the dCDN RR IP = address). >> This would call for an additional optional parameter in the RI = request indicating required (or excluded) downstream redirection = protocols. >>=20 >>=20 >> *4.3.1: >> " o The IP address of the User Agent" --> " o The IP address or = prefix of the User Agent"=20 >>=20 >>=20 >>=20 >>=20 >> On 16 Feb 2013, at 15:57, Ben Niven-Jenkins = wrote: >>=20 >>> Francois, >>>=20 >>> Closing the loop on this. I've tried to address all your comments in = my working copy of draft-he-cdni-routing-request-redirection-04. >>>=20 >>> I will be posting it in the next week once I've got feedback from my = co-authors. >>>=20 >>> When it gets published let me know if you feel your comments below = haven;t been addressed. In particular I re-wrote a lot of the document = to incorporate the concept of Redirection targets and I'd be interested = in your views on the new text. >>>=20 >>> Ben >>>=20 >>> On 7 Nov 2012, at 14:32, Francois Le Faucheur (flefauch) wrote: >>>=20 >>>> Thanks for your responses. Looks like we're synch. Please keep = track of those points so they get addressed in the next rev. >>>> You may want to bring up some of those today (e.g. need for link to = metadata in Redirection request) , specifically during the "discussion = slot" for Redirection, so we get input from others. >>>>=20 >>>> On 6 Nov 2012, at 10:25, Ben Niven-Jenkins wrote: >>>>=20 >>>>> Francois, >>>>>=20 >>>>> Please see below for my views. >>>>>=20 >>>>> On 5 Nov 2012, at 23:33, Francois Le Faucheur (flefauch) wrote: >>>>>=20 >>>>>> Hello, >>>>>>=20 >>>>>> (As an Individual). >>>>>>=20 >>>>>> In general, I feel this new version is going in the right = direction. >>>>>>=20 >>>>>> Some high level comments: >>>>>>=20 >>>>>> * I think the spec should be less prescriptive as to how a dCDN = builds its redirection response. For example in section 6.1.1, the text = says: >>>>>> "If the dCDN decides to use DNS Redirection, where the Downstream = CDN >>>>>> is redirecting directly to a surrogate in the Downstream CDN: the >>>>>> Downstream CDN selects one or more surrogates and returns a CDNI = RRRI >>>>>> response containing the IP addresses of the selected = surrogate(s), ... >>>>>> If the dCDN decides to use DNS Redirection, where the Downstream = CDN >>>>>> is redirecting to a Request Router in the dCDN: : the Downstream = CDN >>>>>> returns a CDNI RRRI response containing a CNAME of the Downstream >>>>>> CDN's Request Router(s), =85 >>>>>> " >>>>>> In this example, I think the dCDN should be free to return an IP = address or a CNAME of the "redirection target" as it sees fit. The = redirection target may be a Surrogate, a Request Router, a set of = Surrogates, a 3rd party CDN Req Router, a 3rd party CDN Surrogate in = case of cascaded CDNs,... whatever the dCDN sees fit. >>>>>> You could possibly mention one of the behavior above as an = example of what might happen, but it should just be an example and I = recommend the spec be open as to the logic to populate the Redirection = response. >>>>>=20 >>>>> Fair comment. Describing the different redirection possibilities & = their applicability while at the same time talking about CDNI = Redirection in a more generic way (so we don't keep repeating all the = different nuances) was something we struggled a little with and is = certainly an area of the draft (IMO) that needs more work to make the = text clearer etc. >>>>>=20 >>>>> I like your idea of a 'redirection target' and maybe the right = approach is to have a section defining/discussing the possibilities for = redirection (A/AAAA/CNAME/Application level 302/etc) to a 'redirection = target' in a dCDN and in the rest of the document just talk generically = about redirection targets? >>>>>=20 >>>>>> * the document keeps talking about "encapsulating the enduser = request" inside the Redirection Request. I find this misleading, because = this is not about encapsulating the enduser request per-say, but rather = to convey the key attributes of the enduser request. >>>>>=20 >>>>> Fair comment. We used 'encapsulating end user request' to = distinguish between previous versions of the draft where the end user = request was proxied to a dCDN via the same protocol that the end user = request was made over. >>>>>=20 >>>>> Going forward that history doesn't matter and we should use better = language to describe what we are actually doing. >>>>>=20 >>>>>> * for HTTP, the Redirection Request should allow passing other = attributes in addition to client IP address and URI. >>>>>=20 >>>>> The draft currently just tries to define the minimum necessary = information for a dCDN to be able to perform a redirection. There are = probably other attributes that the dCDN would find useful and although = it is not explicitly described in the current draft I think the CDNI = Redirection 'protocol framework' in draft-he easily allows passing = additional optional attributes. Describing how to extend the 'base = protocol' with additional attributes is certainly something we should = add in a future revision of the draft. >>>>>=20 >>>>> Personally, I am reluctant to define lots of theoretical = attributes (that no one ends up using) to be included in a CDN = Redirection request but I would like to hear views from implementors on = the attributes they actually use (or plan to use as part of CDNI) to = influence surrogate selection/redirection across a CDN interconnect. >>>>>=20 >>>>>> * the document requires that a pointer to Metadata be included in = the Redirection request: >>>>>> "For DNS redirection, the uCDN also needs to provide in the CDNI = RRRI >>>>>> request the a link to the associated CDNI Metadata for the host/ >>>>>> domain being requested." >>>>>> Considering that the latest Metadata interface allows the dCDN to = walk down the metadata tree for any content without seeding any initial = info/pointers, I am not sure there is a benefit in passing a link to = metadata inside the Redirection request. If would potentially save the = dCDN Request Router to do the lookup on Content-->Metadata , but would = require the uCDN Request Router to do the same on its behalf. Besides = the dCDN has to do that looup anyways to get the Metadata for serving = the content. >>>>>=20 >>>>> This is in my slides for Thursday. When I was thinking about CDN = Redirection a while ago I convinced myself a link to CDNI Metadata was = useful so when I started working on draft-he I included it, but since = then I've been struggling to remind myself why I originally thought it = was required so I'm certainly open to removing it. >>>>>=20 >>>>>> * the redirection interface will need to discuss handling of URI = Signing=20 >>>>>=20 >>>>> Sure. Personally I'd like the uri signing/token authorisation work = in the WG to mature a bit more first just to avoid having to keep = draft-he aligned with a still moving target. >>>>>=20 >>>>> At a minimum we should include in the next revision a comment that = we still need to factor token authorisation into the document. >>>>>=20 >>>>>> * we need to agree on a set of acronyms to refer to the "CDNI = Request Routing/Redirection Interface". I will bring that up during the = meeting this week. >>>>>=20 >>>>> OK >>>>>=20 >>>>> Ben >>>>>=20 >>>>>>=20 >>>>>> HTH >>>>>>=20 >>>>>> Francois >>>>>>=20 >>>>>>=20 >>>>>> On 21 Oct 2012, at 23:02, >>>>>> wrote: >>>>>>=20 >>>>>>>=20 >>>>>>> A New Internet-Draft is available from the on-line = Internet-Drafts directories. >>>>>>>=20 >>>>>>>=20 >>>>>>> Title : Routing Request Redirection for CDN = Interconnection >>>>>>> Author(s) : Wang Danhua (editor) >>>>>>> He Xiaoyan >>>>>>> Spencer Dawkins >>>>>>> Ge Chen >>>>>>> Ni Wei >>>>>>> Zhang Yunfei >>>>>>> Ben Niven-Jenkins >>>>>>> Filename : = draft-he-cdni-routing-request-redirection-03.txt >>>>>>> Pages : 19 >>>>>>> Date : 2012-10-21 >>>>>>>=20 >>>>>>> Abstract: >>>>>>> The Request Routing Interface comprises of (1) the asynchronous >>>>>>> advertisement of footprint and capabilities by a downstream CDN = that >>>>>>> allows a upstream CDN to decide whether to redirect particular = user >>>>>>> requests to that downstream CDN; and (2) the synchronous = operation of >>>>>>> an upstream CDN requesting whether a downstream CDN is prepared = to >>>>>>> accept a user request and of a downstream CDN responding with = how to >>>>>>> actually redirect the user request. This document describes an >>>>>>> interface for the latter part, i.e. the CDNI Request Routing >>>>>>> Redirection interface. >>>>>>>=20 >>>>>>>=20 >>>>>>> The IETF datatracker status page for this draft is: >>>>>>> = https://datatracker.ietf.org/doc/draft-he-cdni-routing-request-redirection= >>>>>>>=20 >>>>>>> There's also a htmlized version available at: >>>>>>> = http://tools.ietf.org/html/draft-he-cdni-routing-request-redirection-03 >>>>>>>=20 >>>>>>> A diff from the previous version is available at: >>>>>>> = http://www.ietf.org/rfcdiff?url2=3Ddraft-he-cdni-routing-request-redirecti= on-03 >>>>>>>=20 >>>>>>>=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 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> CDNi mailing list >>>>>> CDNi@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/cdni >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From ben@niven-jenkins.co.uk Sun Mar 31 10:58:13 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 0AD0B21F866E for ; Sun, 31 Mar 2013 10:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 ZFSkwRT9sB4p for ; Sun, 31 Mar 2013 10:58:12 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCD421F86D2 for ; Sun, 31 Mar 2013 10:58:11 -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 1UMMWA-0007wR-Ar; Sun, 31 Mar 2013 18:58:11 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Ben Niven-Jenkins In-Reply-To: Date: Sun, 31 Mar 2013 18:58:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> <3F5BB382-1292-4EE4-8621-52C7C5097ACC@niven-jenkins.co.uk> 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] Comments on draft-he-cdni-routing-request-redirection-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, 31 Mar 2013 17:58:13 -0000 Francois, On 7 Mar 2013, at 15:03, Francois Le Faucheur (flefauch) wrote: > Hello Ben and co-authors, >=20 > Thanks for addressing my comments. >=20 > This is definitely going in the right direction. >=20 > Below are a bunch of comments on the latest version (some editorial, = some more significant). >=20 > Francois >=20 >=20 > Title:=20 > "Routing Request Redirection" ---> "Request Routing Redirection = Interface" Done. > too many authors Done. > * section 1: > I would suggest: > * compressing/removing the 1st two paragraphs and simply refer = to RFC6707 > * incorporate here the text that you currently have in the = abstract which re-explains the break-down of the request routing = interface into FCI and RI. This is the right place to remind the reader = of how the Redirection Interface fits in the overall picture. It is also = the right place to introduce the RI acronym. Done. > * section 2: > "Examples of an application level redirection are HTTP and RTMP 302 = redirections." > --> "Examples of an application level redirection are HTTP 302 = Redirection and RTMP 302 Redirection." Done. > * section 2: > at the end of the HTTP Redirection definition add: > "HTTP Redirection is a particular case of Application Level = Redirection". Done. > *section 3: > 1st "Editors' note:. This discusses an interesting point. I suggest in = next rev you replace this with a paragraph that basically says: > * how upstream CDN decides which dCDN to talk to via RI is a = local policy of uCDN and outside the scope of this doc > * a typical example would be where the uCDN selects the dCDN for = the request, and then queries that dCDN via RI and then redirects to the = Redirection Target. > * a more complex example would be where the uCDN selects the = dCDN for the request, and then queries that dCDN via RI and got a reject = from dCDN. Then uCDN selects an alternative dCDN and then queries that = dCDN via RI and then redirects to the Redirection Target. > * yet an even more complex example would be where the uCDN = selects two candidate dCDNs and queries both via RI before selecting one = and using the Redirection Target provided by that dCDN. Done. > * section 3: > "The Redirection Interface operates between a pair of interconnected = CDNs." > --> " The Redirection Interface operates between the Request Routing = systems of a pair of interconnected > CDNs." Done. > * everywhere: > "Iterative Request Routing" --> "Iterative Request Redirection"=20= > "Recursive Request Routing" --> "Recursive Request = Redirection" > "CDNi" --> "CDNI" Done. > * section 3: > OLD: > " > In the case of Recursive Request Routing, an Upstream CDN forwards a > CDNI request routing redirection request from a user agent to a > Downstream CDN for the Downstream CDN to select a Redirection = Target. > " > NEW: > " > In the case of Recursive Request Redirection, in order to perform = redirection of a request received from a User Agent , the Upstream CDN = queries the Downstream CDN so that the Downstream CDN can select and = provide a Redirection Target. > " Done. > * section 3: > "The initial Upstream CDN->User Agent redirection protocols" --> "The = Upstream CDN->User Agent redirection protocols" Done. > * "3.1. Discussion on protocol type for CDNI RRRI" > there is no "RRRI" acronym defined. >=20 > * section 3.1: > I still have a problem with the content of that section and with = Table1. In particular: > * In the 3rd column ("dCDN response"). first the column heading = should say "dCDN RI response". Then , it is misleading to say that the = dCDN response is "DNS with=85" or "HTTP 302": The dCDN response is = actually an RI Response that allows the uCDN to build a DNS response or = a HTTP 302 response. > * in the 4th column ("Notes"). It is incorrect to say that "dCDN = uses DNS" or "dCDN uses HTTP redirection" because all you know is that = the uCDN will use DNS or HTTP, but the dCDN could actually decide to use = whatever it wants. For example, the dCDN can provide a CNAME in the RI = response that points to the dCDN request Router. as a result the = USer-Agent the uCDN may perform DNS redirection but the dCDN will = perform HTTP redirection. > This section needs to be cleaned up. The kyy points that have to be = conveyed are: > * one protocol (DNS or HTTP) is used between User-Agent and uCDN = RR > * RI is used between uCDN and dCDN, and dCDN uses that to = provide a Redirection Target in the format that is compatible with the = protocol used between User-Agent and uCDN RR > * the dCDN has freedom in the Redirection Target it provides. = Depending on the returned Redirection Target, we may see the following = scenario: > - the request is redirected to the final Surrogate (i.e. = no more redirection) > - the request is redirected to a request router that = will be using a redirection protocol (DNS or HTTP) which may be the same = as first redirection or may be different. This is controlled by the dCDN = =20 I've added a paragraph to section 3 using your text above as a base and = deleted section 3.1. > * Section 4: > "where the attributes of User Agent's requests" --> "where the = attributes of a User Agent's request" Done. > * section 4: > "The general call flow between Request Routers" --> "The general = Recursive Request Redirection message flow between Request Routing = systems" Done. > * section 4: Figure with message flow > - add a Figure Number + Figure Title > - the numbers of the steps on the right doe snot match the step = description under the figure Done. > * section 4.1: > "e.g. URI of the requested content, the client's location = information." > --> "e.g. URI of the requested content and the client's location = information, when those are known by the uCDN Request Routing system." Done. > * section 4.1: re Cacheability of the response. > I wonder if conveying the cache ability of the response _only_ in = standards HTTP cache-Control mechanism is really the best way to do it, = or should we not also encode it inside the body, just like the scope. > I think that has to do with expected implementations of the uCDN = Request Router. If the uCDN RR makes direct use of the cached RI = response to process subsequent requests, then it makes sense to have the = cache ability encoded only in the HTTP headers. If the uCDN RR actually = builds a separate table/database of information derived from the RI = responses, then it makes more sense to have both cache ability and scope = encoded inside the RI response body. Since the RI responses are not = easily indexed via a URI (since they are all posted on the same = Redirection Interface URI e.g. rr1.dcdn.example.net/dcdn/ri ) then I'd = expect more the latter type of implementation. No? There is nothing to stop an implementation extracting the cacheability = from the Cache-Control header and storing it in its table/database. The advantage of having the cacheability in the HTTP Cache-Control = header is that RI request/responses can be cached by HTTP intermediaries = which may be useful in some scenarios. I fear if we put the cacheability = in the response body folks will forget to reflect it in the HTTP headers = too. It also means we need to specify what to do if the Cache-Control & = Response Body values don't match. > *4.2 : re JSON encoding > Although the trade-offs may not be exactly the same across all Web = Services based CDNI interfaces (RI, MI, Triggers), it would make sense = to use the same type of encoding (e.g. JSON or XML) across all the = interfaces ; unless there is really a good reason to not do so. > For now, can you add an "Editor's Note" saying that actual choice of = encoding is still TBD and all JSON encoding is provided "as an example"? I think between you writing this and me getting around to replying, = we're pretty much agreed to converge on JSON, so I think this editor's = note is no longer required. > *4.2: > "[Maybe a use case is > responses is if the dCDN wants to indicate it is prepared to have a > DNS redirection directly to it or a HTTP redirection from the uCDN = RR > to the dCDN and wants to indicate both options in a single > response?]] > " > I would think that the uCDN is the one to choose whether it wants to = redirect to dCDN via DNS or HTTP. So I don't think the dCDN needs to be = able to say it can handle both. > However, this makes me think of a potential other requirements: = perhaps it makes sense for the uCDN to influence/control whether the = dCDN shoudl be using DNS/HTTP for further redirection. Whether DNS or = HTTP redirection is used has visible impact to the enduser and = (indirect) impact on the Content Provider. So the Content provider may = want to impose one mode of redirection and then the uCDN needs to be = able to tell the dCDN whether some mode are required/forbidden. For = example, a Content Provider may want to have only DNS redirection used = so Interconnected CDNs are transparent to endusers (from URI viewpoint). = Then the uCDN may need to tell the dCDN that the dCDN ought to pick a = Redirection Target that will achieve full DNS redirection (i.e. the dCDN = cannot return as a RT a CNAME who get's resolved as the dCDN RR IP = address). > This would call for an additional optional parameter in the RI request = indicating required (or excluded) downstream redirection protocols. Does it really require that or just an additional property in the dns = key of RI requests as you can't convert a HTTP 302 back into DNS = redirection as such. In my working copy I've added a dns-only property to the dns key with = the following description: If True then dCDN MUST only use DNS redirection to a surrogate and MUST = include the dns-only property set to True on any cascaded RI requests. = Defaults to False. > *4.3.1: > " o The IP address of the User Agent" --> " o The IP address or = prefix of the User Agent"=20 Done. Ben From ben@niven-jenkins.co.uk Sun Mar 31 11:22:43 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 7560C21F862B for ; Sun, 31 Mar 2013 11:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 RhN82pLCuMoG for ; Sun, 31 Mar 2013 11:22:38 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 70CF721F85CE for ; Sun, 31 Mar 2013 11:22:31 -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 1UMMti-0002sM-9B; Sun, 31 Mar 2013 19:22:30 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <5147402C.7050906@cisco.com> Date: Sun, 31 Mar 2013 19:22:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <50FD43A2-B649-4E03-875D-665FB5E0C20C@niven-jenkins.co.uk> References: <20121022030240.24155.12810.idtracker@ietfa.amsl.com> <3F5BB382-1292-4EE4-8621-52C7C5097ACC@niven-jenkins.co.uk> <5147402C.7050906@cisco.com> To: Scott Wainner X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] Comments on draft-he-cdni-routing-request-redirection-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: Sun, 31 Mar 2013 18:22:48 -0000 Scott, On 18 Mar 2013, at 16:26, Scott Wainner wrote: > |4.2 >=20 > |A single request or response MUST contain only one of the dns or http = keys. >=20 > A DNS query to the uCDN can't result in an HTTP response to the = client. The client or DNS forwarder needs a DNS response. Therefore, I = see no need for the HTTP key if the RI request type is DNS. >=20 > An HTTP query to the uCDN requires an HTTP response to the client. = Certainly, an HTTP response on the RI request is appropriate. However, = a DNS response on the uCDN's RI request using an HTTP key would = presumably mean the target of the RI wasn't satisfactorily and the uCDN = RR would have to resolve the targets DNS response. Not sure how = valuable that would be. This was also discussed during the WG session in Orlando and consensus = was to restrict the response to only one of the dns or http keys. I have = updated my working copy of -05 accordingly. > |[Editor's note: Is the cdn-path useful on responses as well?] >=20 > Yes, a uCDN RR that is assessing alternate CDN's in parallel would = presumably need to know if the responses of candidate transit dCDN's = 'converged' at some point. Consider the case where uCDN is assessing = multiple options: >=20 > a. uCDN -> dCDN-1 -> dCDN-2 > b. uCDN -> dCDN-2 >=20 > Most likely, the uCDN would want to choose dCDN-2 directly as opposed = to using dCDN-1 as a transit. OK I have added this to my working copy of -05. > |[Editor's note: Need some text/section specifying the Media Types for = RI requests/responses] >=20 > Are you thinking classes of content such as video, audio, images or = explicit MIME types? No, what I mean is we need to specify the media types to use for the RI = requests/responses themselves e.g. application/cdni.rirequest+json > Are we assuming that the dCDN will only serve a subset of the content = classes (e.g. images only, images and audio, but no video)? >=20 > |4.3.1 >=20 > | c-subnet : String : No : The IP address of the UA in CIDR format. >=20 > What relevance does this have? Are we trying to assert some assumed = scope (i.e. other clients in the same c-subnet)? I suspect that this = may be RFC1918 space; therefore, its usefulness is suspect. It is for cases such as when the User Agent's DNS resolver supports = draft-vandergaast-edns-client-subnet and the uCDN request router is able = to pass on more specific IP address details than just the DNS resolver. > |4.4.1 HTTP Redirection requests In my working copy of -05 I've added the ability for the uCDN to pass = any HTTP headers to the dCDN in a generic way which I think addresses = what you asked for here. > |4.4.2 HTTP Redirection responses I have put an Editor's note in -05 asking whether the generic header = mechanism used for RI requests should be used for RI responses too. If = the mechanism addresses your requirements I'll add it in? > | 4.5 Indicating the cache-ability and scope of responses >=20 > I think this would only be applicable to URL's that are not signed = when using the Recursive mode. >=20 > I believe most dCDN will want to authenticate each client request. If = we expand the scope of a dCDN response to include a wider range of = subnets, that means the uCDN will have to sign URL requests using the = chosen dCDN's method and algorithms. The advantage of the RI interface = is that the uCDN does not need to know the methods of each dCDN; the = dCDN can sign the URL according to its own rules and simply provide the = signed URL PATH back to the uCDN as an opaque string. >=20 > [NOTE] In contrast, the Iterative mode requires the uCDN to sign the = URL according to the method of the dCDN (or know that a particular URL = can remain unsigned when delegating). Since the client request = interface is not in scope of CDNI, we can't specify the parameters in = the URL given back to the client (we have to consider the PATH as an = opaque string). Sure but control is completely in the hands of the dCDN. If it wants to = authorise every single request and do any resigning itself then it can = return uncacheable responses. For other use cases the dCDN has the = option of returning cacheable responses if it wants to. > | 4.6 Error responses >=20 > method: > unsupported >=20 > client_ip: > unsupported type >=20 > forwarder: > unsupported type >=20 > start_avail: > premature >=20 > expiration: > too late I'm sorry but I don't understand what you are asking for here? > | 8. Outstanding considerations >=20 > We discussed in the FCI design team the ability for the dCDN to = advertise an abstract 'footprint' definition associated with a = capability. For example, a region might be defined that represents an = aggregate geographic footprint as follows: >=20 > uCDN defines: > north_america =3D CA and US and MX > dCDN receives definition in MI: > footprint 'north_america' =3D CA and US and MX >=20 > Are there any merits in having the uCDN pass via the RI any client = location attributes? Certainly, the dCDN could respond with an error if = the client location fell outside the boundaries of the contract. I'm not exactly sure what you're suggesting? If it's passing = footprint/location information inband with the RI request I don't think = we should do that. Or are you thinking more along the lines of the uCDN expressing the = semantic "I [uCDN] geo-located the User-Agent as north_america"? Thanks Ben