From Jan.Seedorf@neclab.eu Mon Dec 3 05:43:37 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EEB621F8744; Mon, 3 Dec 2012 05:43:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEWkTWjXBpMr; Mon, 3 Dec 2012 05:43:36 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA5221F8714; Mon, 3 Dec 2012 05:43:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 67C43102811; Mon, 3 Dec 2012 14:43:32 +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 yT50Xg7IljLC; Mon, 3 Dec 2012 14:43:32 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 50624102810; Mon, 3 Dec 2012 14:43:22 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 3 Dec 2012 14:41:18 +0100 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Doodle for next Footprint/Capabilities phone call ... Thread-Index: Ac3RW95y8Ex+/D0NS6ua278666054w== Date: Mon, 3 Dec 2012 13:41:02 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553BD553@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Doodle for next Footprint/Capabilities phone call ... X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 13:43:37 -0000 http://www.doodle.com/azcc8dtes5vvegqy Please try to fill out by the end of this week. 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 Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014=20 From internet-drafts@ietf.org Mon Dec 3 10:14:22 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FDC21F892F; Mon, 3 Dec 2012 10:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2N84ZBYs6BAA; Mon, 3 Dec 2012 10:14:22 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1920A21F8920; Mon, 3 Dec 2012 10:14:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121203181422.28401.23391.idtracker@ietfa.amsl.com> Date: Mon, 03 Dec 2012 10:14:22 -0800 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-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, 03 Dec 2012 18:14:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-04.txt Pages : 21 Date : 2012-12-03 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Jan.Seedorf@neclab.eu Fri Dec 7 07:20:01 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7E921F8AB4; Fri, 7 Dec 2012 07:20:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wmXhSJy-oRs; Fri, 7 Dec 2012 07:20:00 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 225CF21F8AA3; Fri, 7 Dec 2012 07:20:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F2E631028F3; Fri, 7 Dec 2012 16:19: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 fpEYoycnFJrB; Fri, 7 Dec 2012 16:19:58 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D66FB1028F1; Fri, 7 Dec 2012 16:19:48 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 7 Dec 2012 16:19:27 +0100 From: Jan Seedorf To: Jan Seedorf , "cdni-footprint@ietf.org" Thread-Topic: [cdni-footprint] Doodle for next Footprint/Capabilities phone call ... Thread-Index: Ac3RW95y8Ex+/D0NS6ua278666054wDMiXVQ Date: Fri, 7 Dec 2012 15:18:41 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553C4373@DAPHNIS.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE553BD553@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE553BD553@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.99.154] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for next Footprint/Capabilities phone 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, 07 Dec 2012 15:20:01 -0000 Dear all, The most popular date is WED, DEC. 19th. Stefano, can you please arrange We= bEx for Dec. 19th, 16:00-18:00 CET? Thanks, Jan > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Jan Seedorf > Sent: Monday, December 03, 2012 2:41 PM > To: cdni-footprint@ietf.org > Cc: cdni@ietf.org > Subject: [cdni-footprint] Doodle for next Footprint/Capabilities phone ca= ll ... >=20 > http://www.doodle.com/azcc8dtes5vvegqy >=20 > Please try to fill out by the end of this week. >=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 Limited Registered Office: NEC House, > 1 Victoria Road, London W3 6BL Registered in England 2832014 >=20 >=20 > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint From ray.vanbrandenburg@tno.nl Fri Dec 7 08:07:49 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF90C21F87E9; Fri, 7 Dec 2012 08:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BW9fLUIK1m6L; Fri, 7 Dec 2012 08:07:49 -0800 (PST) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id A136E21F88CD; Fri, 7 Dec 2012 08:07:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,239,1355094000"; d="scan'208";a="213444" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 07 Dec 2012 17:07:39 +0100 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.244]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0318.004; Fri, 7 Dec 2012 17:07:39 +0100 From: "Brandenburg, R. (Ray) van" To: Jan Seedorf , "flefauch@cisco.com" Thread-Topic: [cdni-footprint] Doodle for next Footprint/Capabilities phone call ... Thread-Index: Ac3RW95y8Ex+/D0NS6ua278666054wDMiXVQAAGnjgA= Date: Fri, 7 Dec 2012 16:07:38 +0000 Message-ID: References: <2779C9F0771F974CAD742BAE6D9904FE553BD553@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE553C4373@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE553C4373@DAPHNIS.office.hd> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "cdni@ietf.org" , "cdni-footprint@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for next Footprint/Capabilities phone 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, 07 Dec 2012 16:07:50 -0000 Hi Jan, Francois, The proposed date and time (Dec. 19 16:00-18:00) has now been scheduled for= both the Footprint Design Team call as well as for the call to discuss Log= ging. = As someone who would like to participate in both calls, I would prefer if w= e could re-schedule one of them. = Best regards, Ray -----Original Message----- From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.o= rg] On Behalf Of Jan Seedorf Sent: vrijdag 7 december 2012 16:19 To: Jan Seedorf; cdni-footprint@ietf.org Cc: cdni@ietf.org Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities phone = call ... Dear all, The most popular date is WED, DEC. 19th. Stefano, can you please arrange We= bEx for Dec. 19th, 16:00-18:00 CET? Thanks, Jan > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- = > bounces@ietf.org] On Behalf Of Jan Seedorf > Sent: Monday, December 03, 2012 2:41 PM > To: cdni-footprint@ietf.org > Cc: cdni@ietf.org > Subject: [cdni-footprint] Doodle for next Footprint/Capabilities phone ca= ll ... > = > http://www.doodle.com/azcc8dtes5vvegqy > = > Please try to fill out by the end of this week. > = > 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 = > Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 434= 2-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 Limited Registered Office: NEC House, > 1 Victoria Road, London W3 6BL Registered in England 2832014 > = > = > _______________________________________________ > 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 This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From kevin.ma@azukisystems.com Fri Dec 7 09:37:49 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7571521F8797; Fri, 7 Dec 2012 09:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OCpFBqVlwIdg; Fri, 7 Dec 2012 09:37:48 -0800 (PST) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 75CC121F8781; Fri, 7 Dec 2012 09:37:48 -0800 (PST) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 80D948BFE11; Fri, 7 Dec 2012 12:37:47 -0500 (EST) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id 0966D8BFE23; Fri, 7 Dec 2012 12:37:47 -0500 (EST) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Fri, 7 Dec 2012 12:37:28 -0500 From: Kevin J Ma To: "Brandenburg, R. (Ray) van" , Jan Seedorf , "flefauch@cisco.com" Date: Fri, 7 Dec 2012 12:37:44 -0500 Thread-Topic: [cdni-footprint] Doodle for next Footprint/Capabilities phone call ... Thread-Index: Ac3RW95y8Ex+/D0NS6ua278666054wDMiXVQAAGnjgAAAx1fIA== Message-ID: <291CC3F9E50E7641901A54E85D0977C653612EE311@MAILR002.mail.lan> References: <2779C9F0771F974CAD742BAE6D9904FE553BD553@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE553C4373@DAPHNIS.office.hd> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , "cdni-footprint@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for next Footprint/Capabilities phone 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, 07 Dec 2012 17:37:49 -0000 +1 > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van > Sent: Friday, December 07, 2012 11:08 AM > To: Jan Seedorf; flefauch@cisco.com > Cc: cdni@ietf.org; cdni-footprint@ietf.org > Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities phon= e > call ... >=20 > Hi Jan, Francois, >=20 > The proposed date and time (Dec. 19 16:00-18:00) has now been scheduled > for both the Footprint Design Team call as well as for the call to discus= s > Logging. >=20 > As someone who would like to participate in both calls, I would prefer if > we could re-schedule one of them. >=20 > Best regards, >=20 > Ray >=20 > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Jan Seedorf > Sent: vrijdag 7 december 2012 16:19 > To: Jan Seedorf; cdni-footprint@ietf.org > Cc: cdni@ietf.org > Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities phon= e > call ... >=20 > Dear all, >=20 > The most popular date is WED, DEC. 19th. Stefano, can you please arrange > WebEx for Dec. 19th, 16:00-18:00 CET? >=20 > Thanks, > Jan >=20 > > -----Original Message----- > > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > > bounces@ietf.org] On Behalf Of Jan Seedorf > > Sent: Monday, December 03, 2012 2:41 PM > > To: cdni-footprint@ietf.org > > Cc: cdni@ietf.org > > Subject: [cdni-footprint] Doodle for next Footprint/Capabilities phone > call ... > > > > http://www.doodle.com/azcc8dtes5vvegqy > > > > Please try to fill out by the end of this week. > > > > 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 > > Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4= 342-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 Limited Registered Office: NEC House, > > 1 Victoria Road, London W3 6BL Registered in England 2832014 > > > > > > _______________________________________________ > > 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 > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer >=20 > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint From ggolovinsky@qualys.com Fri Dec 7 09:44:48 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE6021F85FA for ; Fri, 7 Dec 2012 09:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjnjsB-Xx+FP for ; Fri, 7 Dec 2012 09:44:47 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE54121F8936 for ; Fri, 7 Dec 2012 09:44:46 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id b25so390627qca.31 for ; Fri, 07 Dec 2012 09:44:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:references:in-reply-to:mime-version:x-mailer:thread-index:date :message-id:subject:to:cc:content-type:content-transfer-encoding :x-gm-message-state; bh=MRqxIMg1iz0iLsdN/MjPkqcfc1eLkK/RQST2LWCHwy0=; b=JLMFU9F/ZFN6ZGGjgAp2spYU8XCbmhbtEtCpmz028sboipzq05xygA0hATlWnJL0la toyih9M6b/D2rcFAzDr+4O36atpahM7bXaqevG0qRhb6NyvJgXQ4LNIissXf8QQ73pG7 EMZqJnHsW34chJQRvBJ7IjpCxEmQz2ZyERxcJOde9CT8HwWh4SQeMQc2FrF2tq+E2V+h SXL7MHJEjiQf647/Ih+MgKdAzkHWZLJXlHLdZGnxxsiAJphDu8cLTunRw+rG55fOGu2H ryfM5W/wC/IO5uvELZRhzmWeH3ljy4Sl3msKch40mPFxGXZGPWZxkytQhIACSq9l6M91 jbjA== Received: by 10.49.118.138 with SMTP id km10mr11652798qeb.18.1354902285886; Fri, 07 Dec 2012 09:44:45 -0800 (PST) From: Gene Golovinsky References: <2779C9F0771F974CAD742BAE6D9904FE553BD553@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE553C4373@DAPHNIS.office.hd> <291CC3F9E50E7641901A54E85D0977C653612EE311@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C653612EE311@MAILR002.mail.lan> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG+9JJqU3b3chSuzNsUQgCLNkSiEwH5gh/rAhwKopYCslDhIZf1HNOg Date: Fri, 7 Dec 2012 09:44:46 -0800 Message-ID: To: Kevin J Ma , "Brandenburg, R. (Ray) van" , Jan Seedorf , flefauch@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk+8qqBqF+HCTFU8gIuWr+wRHlAKkCmGsfhz51E8AYdRHJQ+ySySbXmZgDhhCnBeAkQrCdT Cc: cdni@ietf.org, cdni-footprint@ietf.org Subject: Re: [CDNi] [cdni-footprint] Doodle for next Footprint/Capabilities phone 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, 07 Dec 2012 17:44:48 -0000 I am interested in Logging discussion. So, if time and place changes for Logging pls let the list know. Thanks. --Gene -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Kevin J Ma Sent: Friday, December 07, 2012 09:38 AM To: Brandenburg, R. (Ray) van; Jan Seedorf; flefauch@cisco.com Cc: cdni@ietf.org; cdni-footprint@ietf.org Subject: Re: [CDNi] [cdni-footprint] Doodle for next Footprint/Capabilities phone call ... +1 > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Brandenburg, R. (Ray) van > Sent: Friday, December 07, 2012 11:08 AM > To: Jan Seedorf; flefauch@cisco.com > Cc: cdni@ietf.org; cdni-footprint@ietf.org > Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities > phone call ... > > Hi Jan, Francois, > > The proposed date and time (Dec. 19 16:00-18:00) has now been > scheduled for both the Footprint Design Team call as well as for the > call to discuss Logging. > > As someone who would like to participate in both calls, I would prefer > if we could re-schedule one of them. > > Best regards, > > Ray > > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Jan Seedorf > Sent: vrijdag 7 december 2012 16:19 > To: Jan Seedorf; cdni-footprint@ietf.org > Cc: cdni@ietf.org > Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities > phone call ... > > Dear all, > > The most popular date is WED, DEC. 19th. Stefano, can you please > arrange WebEx for Dec. 19th, 16:00-18:00 CET? > > Thanks, > Jan > > > -----Original Message----- > > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > > bounces@ietf.org] On Behalf Of Jan Seedorf > > Sent: Monday, December 03, 2012 2:41 PM > > To: cdni-footprint@ietf.org > > Cc: cdni@ietf.org > > Subject: [cdni-footprint] Doodle for next Footprint/Capabilities > > phone > call ... > > > > http://www.doodle.com/azcc8dtes5vvegqy > > > > Please try to fill out by the end of this week. > > > > 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 > > 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 Limited Registered Office: NEC House, > > 1 Victoria Road, London W3 6BL Registered in England 2832014 > > > > > > _______________________________________________ > > 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 > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Mon Dec 10 01:11:03 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C2C21F8D6F; Mon, 10 Dec 2012 01:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pDslhIHkye5; Mon, 10 Dec 2012 01:11:01 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 477CC21F8C75; Mon, 10 Dec 2012 01:11:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A8AF510291C; Mon, 10 Dec 2012 10:10:59 +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 26-kieBZcSd7; Mon, 10 Dec 2012 10:10:59 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 87BC610291B; Mon, 10 Dec 2012 10:10:39 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 10 Dec 2012 10:10:14 +0100 From: Jan Seedorf To: "Francois Le Faucheur (flefauch)" Thread-Topic: [cdni-footprint] Doodle for next Footprint/Capabilities phone call ... Thread-Index: Ac3RW95y8Ex+/D0NS6ua278666054wDMiXVQAAGnjgAADMYPAAB7i/yQ Date: Mon, 10 Dec 2012 09:10:14 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553C58AF@DAPHNIS.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE553BD553@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE553C4373@DAPHNIS.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , "cdni-footprint@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for next Footprint/Capabilities phone call ... X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:11:03 -0000 Hi Francois and all, Sorry, I missed that the logging call is in parallel. The next popular date= for the "footprint/capabilities" call according to the doodle is WED Dec. = 12th. So I suggest having the "footprint/capabilities" call on Dec 12th, 16= :00-18:00 CET. Any objections? Jan > -----Original Message----- > From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > Sent: Friday, December 07, 2012 5:11 PM > To: Jan Seedorf > Cc: Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) van > Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities phon= e call > ... >=20 > Hi Jan, >=20 > The CDNI Logging webex has been announced for a while on the list. Could > you pick another date for the Footprint? >=20 > On 7 Dec 2012, at 17:07, Brandenburg, R. (Ray) van wrote: >=20 > > Hi Jan, Francois, > > > > The proposed date and time (Dec. 19 16:00-18:00) has now been scheduled > for both the Footprint Design Team call as well as for the call to discus= s > Logging. > > > > As someone who would like to participate in both calls, I would prefer = if we > could re-schedule one of them. > > > > Best regards, > > > > Ray > > > > -----Original Message----- > > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Jan Seedorf > > Sent: vrijdag 7 december 2012 16:19 > > To: Jan Seedorf; cdni-footprint@ietf.org > > Cc: cdni@ietf.org > > Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities ph= one > call ... > > > > Dear all, > > > > The most popular date is WED, DEC. 19th. Stefano, can you please arrang= e > WebEx for Dec. 19th, 16:00-18:00 CET? > > > > Thanks, > > Jan > > > >> -----Original Message----- > >> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > >> bounces@ietf.org] On Behalf Of Jan Seedorf > >> Sent: Monday, December 03, 2012 2:41 PM > >> To: cdni-footprint@ietf.org > >> Cc: cdni@ietf.org > >> Subject: [cdni-footprint] Doodle for next Footprint/Capabilities phone= call > ... > >> > >> http://www.doodle.com/azcc8dtes5vvegqy > >> > >> Please try to fill out by the end of this week. > >> > >> 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 > >> Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-221 > >> Fax: +49 (0)6221 4342-155 > >> e-mail: 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 Limited Registered Office: NEC House, > >> 1 Victoria Road, London W3 6BL Registered in England 2832014 > >> > >> > >> _______________________________________________ > >> 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 > > This e-mail and its contents are subject to the DISCLAIMER at > http://www.tno.nl/emaildisclaimer > > From sprevidi@cisco.com Mon Dec 10 01:21:17 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570E721F8E70 for ; Mon, 10 Dec 2012 01:21:16 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY-jnO58D-J2 for ; Mon, 10 Dec 2012 01:21:16 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 18B9321F8E6D for ; Mon, 10 Dec 2012 01:21:14 -0800 (PST) X-TACSUNS: Virus Scanned Received: from stew-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBA9K3qZ021880 for ; Mon, 10 Dec 2012 10:20:04 +0100 (CET) Received: from dhcp-10-55-80-64.cisco.com (dhcp-10-55-80-64.cisco.com [10.55.80.64]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBA9K0kG012140; Mon, 10 Dec 2012 10:20:00 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE553C58AF@DAPHNIS.office.hd> Date: Mon, 10 Dec 2012 10:20:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2779C9F0771F974CAD742BAE6D9904FE553BD553@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE553C4373@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE553C58AF@DAPHNIS.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1283) Cc: "cdni@ietf.org" , "cdni-footprint@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for next Footprint/Capabilities phone call ... X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:21:17 -0000 On Dec 10, 2012, at 10:10 AM, Jan Seedorf wrote: > Hi Francois and all, >=20 > Sorry, I missed that the logging call is in parallel. The next popular = date for the "footprint/capabilities" call according to the doodle is = WED Dec. 12th. So I suggest having the "footprint/capabilities" call on = Dec 12th, 16:00-18:00 CET. if ok for everybody, I'll update the bridge. s. >=20 > Any objections? >=20 > Jan >=20 >> -----Original Message----- >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >> Sent: Friday, December 07, 2012 5:11 PM >> To: Jan Seedorf >> Cc: Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) van >> Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities = phone call >> ... >>=20 >> Hi Jan, >>=20 >> The CDNI Logging webex has been announced for a while on the list. = Could >> you pick another date for the Footprint? >>=20 >> On 7 Dec 2012, at 17:07, Brandenburg, R. (Ray) van wrote: >>=20 >>> Hi Jan, Francois, >>>=20 >>> The proposed date and time (Dec. 19 16:00-18:00) has now been = scheduled >> for both the Footprint Design Team call as well as for the call to = discuss >> Logging. >>>=20 >>> As someone who would like to participate in both calls, I would = prefer if we >> could re-schedule one of them. >>>=20 >>> Best regards, >>>=20 >>> Ray >>>=20 >>> -----Original Message----- >>> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- >> bounces@ietf.org] On Behalf Of Jan Seedorf >>> Sent: vrijdag 7 december 2012 16:19 >>> To: Jan Seedorf; cdni-footprint@ietf.org >>> Cc: cdni@ietf.org >>> Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities = phone >> call ... >>>=20 >>> Dear all, >>>=20 >>> The most popular date is WED, DEC. 19th. Stefano, can you please = arrange >> WebEx for Dec. 19th, 16:00-18:00 CET? >>>=20 >>> Thanks, >>> Jan >>>=20 >>>> -----Original Message----- >>>> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- >>>> bounces@ietf.org] On Behalf Of Jan Seedorf >>>> Sent: Monday, December 03, 2012 2:41 PM >>>> To: cdni-footprint@ietf.org >>>> Cc: cdni@ietf.org >>>> Subject: [cdni-footprint] Doodle for next Footprint/Capabilities = phone call >> ... >>>>=20 >>>> http://www.doodle.com/azcc8dtes5vvegqy >>>>=20 >>>> Please try to fill out by the end of this week. >>>>=20 >>>> Jan >>>>=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 >>>> Jan Seedorf >>>> Senior Researcher >>>> NEC Europe Ltd., NEC Laboratories Europe, Network Division >>>> Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 = 4342-221 >>>> Fax: +49 (0)6221 4342-155 >>>> e-mail: jan.seedorf@neclab.eu >>>>=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 >>>> NEC Europe Limited Registered Office: NEC House, >>>> 1 Victoria Road, London W3 6BL 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 >>> This e-mail and its contents are subject to the DISCLAIMER at >> http://www.tno.nl/emaildisclaimer >>>=20 >=20 > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint >=20 From Jan.Seedorf@neclab.eu Mon Dec 10 01:25:41 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6450F21F8D87; Mon, 10 Dec 2012 01:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKfqTojIvBSX; Mon, 10 Dec 2012 01:25:40 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0D521F8D83; Mon, 10 Dec 2012 01:25:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A273C10291B; Mon, 10 Dec 2012 10:25:39 +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 3d0QvTWnnQmb; Mon, 10 Dec 2012 10:25:39 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 85CE010291A; Mon, 10 Dec 2012 10:25:14 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Mon, 10 Dec 2012 10:24:53 +0100 From: Jan Seedorf To: stefano previdi Thread-Topic: [cdni-footprint] Doodle for next Footprint/Capabilities phone call ... Thread-Index: Ac3RW95y8Ex+/D0NS6ua278666054wDMiXVQAAGnjgAADMYPAAB7i/yQ///ydQD//+4PIA== Date: Mon, 10 Dec 2012 09:24:27 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553C593A@DAPHNIS.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE553BD553@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE553C4373@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE553C58AF@DAPHNIS.office.hd> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" , "cdni-footprint@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for next Footprint/Capabilities phone call ... X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:25:41 -0000 > if ok for everybody, I'll update the bridge. Yes, please do that. Thanks, Jan > -----Original Message----- > From: stefano previdi [mailto:sprevidi@cisco.com] > Sent: Monday, December 10, 2012 10:20 AM > To: Jan Seedorf > Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; cdni-footprint@ietf.o= rg; > Brandenburg, R. (Ray) van > Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities phon= e call > ... >=20 >=20 > On Dec 10, 2012, at 10:10 AM, Jan Seedorf wrote: >=20 > > Hi Francois and all, > > > > Sorry, I missed that the logging call is in parallel. The next popular = date for > the "footprint/capabilities" call according to the doodle is WED Dec. 12t= h. So I > suggest having the "footprint/capabilities" call on Dec 12th, 16:00-18:00= CET. >=20 >=20 > if ok for everybody, I'll update the bridge. >=20 > s. >=20 >=20 >=20 > > > > Any objections? > > > > Jan > > > >> -----Original Message----- > >> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] > >> Sent: Friday, December 07, 2012 5:11 PM > >> To: Jan Seedorf > >> Cc: Francois Le Faucheur (flefauch); Brandenburg, R. (Ray) van > >> Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities p= hone > call > >> ... > >> > >> Hi Jan, > >> > >> The CDNI Logging webex has been announced for a while on the list. > Could > >> you pick another date for the Footprint? > >> > >> On 7 Dec 2012, at 17:07, Brandenburg, R. (Ray) van wrote: > >> > >>> Hi Jan, Francois, > >>> > >>> The proposed date and time (Dec. 19 16:00-18:00) has now been > scheduled > >> for both the Footprint Design Team call as well as for the call to dis= cuss > >> Logging. > >>> > >>> As someone who would like to participate in both calls, I would prefe= r if > we > >> could re-schedule one of them. > >>> > >>> Best regards, > >>> > >>> Ray > >>> > >>> -----Original Message----- > >>> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > >> bounces@ietf.org] On Behalf Of Jan Seedorf > >>> Sent: vrijdag 7 december 2012 16:19 > >>> To: Jan Seedorf; cdni-footprint@ietf.org > >>> Cc: cdni@ietf.org > >>> Subject: Re: [cdni-footprint] Doodle for next Footprint/Capabilities > phone > >> call ... > >>> > >>> Dear all, > >>> > >>> The most popular date is WED, DEC. 19th. Stefano, can you please > arrange > >> WebEx for Dec. 19th, 16:00-18:00 CET? > >>> > >>> Thanks, > >>> Jan > >>> > >>>> -----Original Message----- > >>>> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > >>>> bounces@ietf.org] On Behalf Of Jan Seedorf > >>>> Sent: Monday, December 03, 2012 2:41 PM > >>>> To: cdni-footprint@ietf.org > >>>> Cc: cdni@ietf.org > >>>> Subject: [cdni-footprint] Doodle for next Footprint/Capabilities pho= ne > call > >> ... > >>>> > >>>> http://www.doodle.com/azcc8dtes5vvegqy > >>>> > >>>> Please try to fill out by the end of this week. > >>>> > >>>> 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 > >>>> Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 4342-2= 21 > >>>> Fax: +49 (0)6221 4342-155 > >>>> e-mail: 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 Limited Registered Office: NEC House, > >>>> 1 Victoria Road, London W3 6BL Registered in England 2832014 > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> This e-mail and its contents are subject to the DISCLAIMER at > >> http://www.tno.nl/emaildisclaimer > >>> > > > > _______________________________________________ > > cdni-footprint mailing list > > cdni-footprint@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni-footprint > > From flefauch@cisco.com Mon Dec 10 01:33:16 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB5221F8DE7 for ; Mon, 10 Dec 2012 01:33:16 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0hFkivXw-KX for ; Mon, 10 Dec 2012 01:33:15 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3AA21F8D24 for ; Mon, 10 Dec 2012 01:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1016; q=dns/txt; s=iport; t=1355131995; x=1356341595; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=bl1TuGzjlD2FW6JgtnXaDRTKQKiUs8nGIZqZd36KVPk=; b=jCsQ6edhddVdZGNrLsT4FD/LFzx4Evq0CQ4k6K6VijsLFd92vQbCbipO 9U2vIChXrBrnCxivpDGHGLcLMyMJffO+QW4ADTSGzQNFXohIyIQJWvZ8p vMLwz9qm2PcIVl8b+EuJTYeMYRfV9628X8ui6XJ1yrZTxNbrLSibSv90N I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmIFADerxVCtJXHB/2dsb2JhbABEhXC5ARZzgh4BAQEDAQEBATc0EAsCAQgiFBAnCyUCBBMIiAMGDLkiBIw/g2JhA6ZOgnOCIg X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="151175024" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 10 Dec 2012 09:33:15 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBA9XDQT023804 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Dec 2012 09:33:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.128]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 03:33:13 -0600 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: [CDNi] Confirming some IETF-85 decisions Thread-Index: AQHNx8+pxDEjRjrDOki2Ny1w43ylTZgSR7iA Date: Mon, 10 Dec 2012 09:33:13 +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.198] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Confirming some IETF-85 decisions X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:33:16 -0000 All, The decisions below are now considered confirmed. Francois On 21 Nov 2012, at 11:04, Francois Le Faucheur (flefauch) wrote: > All, >=20 > As documented in the minutes, the following decisions were tentatively ma= de at IETF-85: >=20 > * Content Deduplication: The WG will continue the work on this topic ins= ide the WG, but will not aim to support it in first version of the CDNI int= erfaces. >=20 > * Long Tail Content: The WG will not continue the work on this topic ins= ide the WG for now (at least not as a priority item) and will not aim to su= pport something specific for it in first version of the CDNI interfaces. >=20 > * CDNI Logging: draft-bertrand-cdni-logging is accepted as WG document >=20 > We will consider these decisions confirmed unless we hear substantiated o= bjections by 30 Nov. >=20 > Cheers >=20 > Francois & Rich > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Dec 10 01:34:58 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AC421F8DDF for ; Mon, 10 Dec 2012 01:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKCpAUg+i7XV for ; Mon, 10 Dec 2012 01:34:57 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DA62421F8DE7 for ; Mon, 10 Dec 2012 01:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14612; q=dns/txt; s=iport; t=1355132097; x=1356341697; h=from:to:cc:subject:date:message-id:references: mime-version; bh=XUrlagkNUxGQsAdJdaziD3QyGEwk7gmRxteaKDK2pdc=; b=TY7FAy5CcDVA/1oIrHHQ8CtAadbvQMzKTTNPZ6W1zlMivRUdzdmQwXEP 2zOFDbm9UXbRfwTgYQQHGgxYvQcTMF2bY5J5eVrxTNkdYktP175SMqymi JFT+OnHZR0MsHORMUxC9GnpyrLBNkt9QNhhCORDURv11+B+ulzVgR8+Ys g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAD2sxVCtJXG8/2dsb2JhbAAqFwO+cRZzgh4BAQEEAQEBLCYRCAsQAgEPCgMBAgsKBAwDBycLFAMBAwIHAQIBAw4FCIgJDC2rJ41ujD8LG28HgkZhA5cijyyCI1CBbTU X-IronPort-AV: E=McAfee;i="5400,1158,6921"; a="151143653" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 10 Dec 2012 09:34:56 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBA9YuKM006160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Dec 2012 09:34:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.128]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Mon, 10 Dec 2012 03:34:55 -0600 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: [cdni-footprint] [UPDATE]: Meeting rescheduled: cdni-footprint Thread-Index: AQHN1rjrURo3k7aSPUaaiXWjZ7sWvw== Date: Mon, 10 Dec 2012 09:34:55 +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.198] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D2C1C6Exmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] Fwd: [cdni-footprint] [UPDATE]: Meeting rescheduled: cdni-footprint X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2012 09:34:58 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D2C1C6Exmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just copying the full "cdni" alias since some people not subscribed to "cdn= i-footprint" may be interested in that information. Francois Begin forwarded message: From: stefano previdi > Subject: [cdni-footprint] [UPDATE]: Meeting rescheduled: cdni-footprint Date: 10 December 2012 10:29:48 CET To: >, Jan Seedorf = > here's the updated info. s. Begin forwarded message: From: Stefano Previdi > Subject: Meeting rescheduled: cdni-footprint Date: December 10, 2012 10:28:03 AM GMT+01:00 To: sprevidi@cisco.com Reply-To: sprevidi@cisco.com Hello Stefano Previdi, Stefano Previdi changed the date for this online meeting. Topic: cdni-footprint Date: Wednesday, December 12, 2012 Time: 4:00 pm, Europe Time (Amsterdam, GMT+01:00) Meeting Number: 206 222 299 Meeting Password: cdni ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D212295627&UID=3D1934= 573207&PW=3DNNTU1YjY2ZTkz&RT=3DMiMyMg%3D%3D 2. Enter your name and email address. 3. Enter the meeting password: cdni 4. Click "Join Now". To view in other time zones or languages, please click the link: https://cisco.webex.com/ciscosales/j.php?ED=3D212295627&UID=3D1934573207&PW= =3DNNTU1YjY2ZTkz&ORT=3DMiMyMg%3D%3D ---------------------------------------------------------------- ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes ---------------------------------------------------------------- The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area. Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/mc 2. On the left navigation bar, click "Support". You can contact me at: sprevidi@cisco.com 39-0651644491 To update this meeting to your calendar program (for example Microsoft Outl= ook), click this link: https://cisco.webex.com/ciscosales/j.php?ED=3D212295627&UID=3D1934573207&IC= S=3DMRS2&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAuKFGKld79Y3YZs/1zbNkHw6/W5WGJfFlt= a4DEanF68m&RT=3DMiMyMg%3D%3D WebEx will automatically setup Meeting Manager for Windows the first time y= ou join a meeting. To save time, you can setup prior to the meeting by clic= king this link: https://cisco.webex.com/ciscosales/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://cisco.webex.com/ciscosales/systemdiagnosis.php. http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ cdni-footprint mailing list cdni-footprint@ietf.org https://www.ietf.org/mailman/listinfo/cdni-footprint --_000_FC236DA6F2DA77449EF2D02DF4471A8D2C1C6Exmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <13A88B1E2BCD2B45A212EFC36BFB5B0C@cisco.com> Content-Transfer-Encoding: quoted-printable Just copying the full "cdni" alias since some people not subscrib= ed to "cdni-footprint" may be interested in that information.
Francois

Begin forwarded message:

From: stefa= no previdi <sprevidi@cisco.com= >
Subject: [c= dni-footprint] [UPDATE]: Meeting rescheduled: cdni-footprint
Date: 10 De= cember 2012 10:29:48 CET
To: <<= a href=3D"mailto:cdni-footprint@ietf.org">cdni-footprint@ietf.org>, = Jan Seedorf <Jan.Seedorf@neclab= .eu>

here's the updated info.


s.


Begin forwarded message:

From: Stefa= no Previdi <messenger@webex.com>
Subject: Me= eting rescheduled: cdni-footprint
Date: Decem= ber 10, 2012 10:28:03 AM GMT+01:00
Reply-To: sprevidi@cisco.com

Hell= o Stefano Previdi,

Stefano Previdi changed the date for this online meeting.

Topic: cdni-footprint
Date: Wednesday, December 12, 2012
Time: 4:00 pm, Europe Time (Amsterdam, GMT+01:00)
Meeting Number: 206 222 299
Meeting Password: cdni


-------------------------------------------------------
To join the online meeting (Now from mobile devices!)
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D212295627&UID=3D193457320= 7&PW=3DNNTU1YjY2ZTkz&RT=3DMiMyMg%3D%3D
2. Enter your name and email address.
3. Enter the meeting password: cdni
4. Click "Join Now".

To view in other time zones or languages, please click the link:
https://cisco.webex.com/ciscosales/j.php?ED=3D212295627&UID=3D19345= 73207&PW=3DNNTU1YjY2ZTkz&ORT=3DMiMyMg%3D%3D

----------------------------------------------------------------
ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
----------------------------------------------------------------

The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area.

Please dial the local access number for your area from the list below:
- San Jose/Milpitas (408) area: 525-6800
- RTP (919) area: 392-3330

-------------------------------------------------------
To join the teleconference only
-------------------------------------------------------
1. Dial into Cisco WebEx (view all Global Access Numbers at
http://cisco.com/en/US/about/doing_business/conferen= cing/index.html
2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign.

San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330

US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117

India: +91.80.4350.1111 Germany: +49.619.6773.9002

Japan: +81.3.5763.9394 China: +86.10.8515.5666

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://cisco.webex.com/ciscosales/mc
2. On the left navigation bar, click "Support".

You can contact me at:
sprevidi@cisco.com
39-0651644491

To update this meeting to your calendar program (for example Microsoft Outl= ook), click this link:
https://cisco.webex.com/ciscosales/j.php?ED=3D212295627&UI= D=3D1934573207&ICS=3DMRS2&LD=3D1&RD=3D2&ST=3D1&SHA2=3DA= AAAAuKFGKld79Y3YZs/1zbNkHw6/W5WGJfFlta4DEanF68m&RT=3DMiMyMg%3D%3D


WebEx will automatically setup Meeting Manager for Windows the first time y= ou join a meeting. To save time, you can setup prior to the meeting by clic= king this link:
https://cisco.webex.com/ciscosales/meetingcenter/mcsetup.ph= p


The playback of UCF (Universal Communications Format) rich media files requ= ires appropriate players. To view this type of rich media files in the meet= ing, please check whether you have the players installed on your computer b= y going to https://= cisco.webex.com/ciscosales/systemdiagnosis.php.




http://www.webex.com



IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the= start of the recording or do not join the session. Please note that any su= ch recordings may be subject to discovery in the event of litigation.

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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D2C1C6Exmbrcdx10ciscocom_-- From Jan.Seedorf@neclab.eu Wed Dec 12 00:49:11 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF4F21F894E for ; Wed, 12 Dec 2012 00:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYSw6Z5mgyns for ; Wed, 12 Dec 2012 00:49:10 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id EDCD821F8925 for ; Wed, 12 Dec 2012 00:49:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 119F3FFE61 for ; Wed, 12 Dec 2012 09:49:09 +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 jI4rzfuzNSFZ for ; Wed, 12 Dec 2012 09:49:08 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id EA497FFE5F for ; Wed, 12 Dec 2012 09:49:03 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.105]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 12 Dec 2012 09:48:53 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: CDNI Footprint/Capabilities call today at 16:00 CET Thread-Index: Ac3YRUXg6sEg9MErQdKUSo0eW0NdSw== Date: Wed, 12 Dec 2012 08:48:53 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553C79A9@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI Footprint/Capabilities call today at 16:00 CET X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 08:49:11 -0000 ..,. just a reminder, see below. I hope that the people interested in this = (and in making progress) can join. We should discuss a) how to proceed with the footprint discussion that has = been somewhat stuck, and in particular consider the latest comments from En= rico regarding ISP's not willing to disclose certain things, and b) how to = proceed with our workplan for capabilities, where I think in Atlanta we der= ived a reasonable plan on how to proceed. - Jan -----Original Message----- From: stefano previdi [mailto:sprevidi@cisco.com]=20 Sent: Monday, December 10, 2012 10:30 AM To: cdni-footprint@ietf.org; Jan Seedorf Subject: [UPDATE]: Meeting rescheduled: cdni-footprint here's the updated info. s. Begin forwarded message: From: Stefano Previdi =09 Subject: Meeting rescheduled: cdni-footprint =09 Date: December 10, 2012 10:28:03 AM GMT+01:00 =09 To: sprevidi@cisco.com =09 Reply-To: sprevidi@cisco.com =09 Hello Stefano Previdi,=20 =09 Stefano Previdi changed the date for this online meeting.=20 =09 Topic: cdni-footprint=20 Date: Wednesday, December 12, 2012=20 Time: 4:00 pm, Europe Time (Amsterdam, GMT+01:00)=20 Meeting Number: 206 222 299=20 Meeting Password: cdni=20 =09 =09 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D212295627&UID=3D193= 4573207&PW=3DNNTU1YjY2ZTkz&RT=3DMiMyMg%3D%3D=20 2. Enter your name and email address.=20 3. Enter the meeting password: cdni=20 4. Click "Join Now".=20 =09 To view in other time zones or languages, please click the link:=20 https://cisco.webex.com/ciscosales/j.php?ED=3D212295627&UID=3D1934573207&P= W=3DNNTU1YjY2ZTkz&ORT=3DMiMyMg%3D%3D=20 =09 ----------------------------------------------------------------=20 ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 ----------------------------------------------------------------=20 =09 The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpit= as area and (866) 349-3520 for the RTP area.=20 =09 Please dial the local access number for your area from the list below:=20 - San Jose/Milpitas (408) area: 525-6800=20 - RTP (919) area: 392-3330=20 =09 -------------------------------------------------------=20 To join the teleconference only=20 -------------------------------------------------------=20 1. Dial into Cisco WebEx (view all Global Access Numbers at=20 http://cisco.com/en/US/about/doing_business/conferencing/index.html=20 2. Follow the prompts to enter the Meeting Number (listed above) or Access= Code followed by the # sign.=20 =09 San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 =09 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 =09 India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 =09 Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 =09 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://cisco.webex.com/ciscosales/mc=20 2. On the left navigation bar, click "Support".=20 =09 You can contact me at:=20 sprevidi@cisco.com=20 39-0651644491=20 =09 To update this meeting to your calendar program (for example Microsoft Out= look), click this link:=20 https://cisco.webex.com/ciscosales/j.php?ED=3D212295627&UID=3D1934573207&I= CS=3DMRS2&LD=3D1&RD=3D2&ST=3D1&SHA2=3DAAAAAuKFGKld79Y3YZs/1zbNkHw6/W5WGJfFl= ta4DEanF68m&RT=3DMiMyMg%3D%3D=20 =09 =09 WebEx will automatically setup Meeting Manager for Windows the first time = you join a meeting. To save time, you can setup prior to the meeting by cli= cking this link:=20 https://cisco.webex.com/ciscosales/meetingcenter/mcsetup.php=20 =09 =09 The playback of UCF (Universal Communications Format) rich media files req= uires appropriate players. To view this type of rich media files in the mee= ting, please check whether you have the players installed on your computer = by going to https://cisco.webex.com/ciscosales/systemdiagnosis.php.=20 =09 =09 =09 =09 http://www.webex.com =20 =09 =09 =09 IMPORTANT NOTICE: This WebEx service includes a feature that allows audio = and any documents and other materials exchanged or viewed during the sessio= n to be recorded. By joining this session, you automatically consent to suc= h recordings. If you do not consent to the recording, discuss your concerns= with the meeting host prior to the start of the recording or do not join t= he session. Please note that any such recordings may be subject to discover= y in the event of litigation.=20 =09 From Jan.Seedorf@neclab.eu Wed Dec 12 07:16:01 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E1D21F8A34 for ; Wed, 12 Dec 2012 07:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDs31otoutLw for ; Wed, 12 Dec 2012 07:15:59 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFFB21F854F for ; Wed, 12 Dec 2012 07:15:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 361851029F8 for ; Wed, 12 Dec 2012 16:15: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 DXhyzvV8fhx9 for ; Wed, 12 Dec 2012 16:15:54 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id DD8D51029F7 for ; Wed, 12 Dec 2012 16:15:48 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.222]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 12 Dec 2012 16:15:27 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: [CDNi] Fwd: Re: [cdni-footprint] Rough Agenda for today's "CDNI Footprint/Capabilties Design Team Call" Thread-Index: AQHNveoBAEj7Z9Hs1EyF7G8YGUvdoZgVexpA Date: Wed, 12 Dec 2012 15:14:27 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553CDD88@PALLENE.office.hd> References: <507577DF.3020602@telecomitalia.it> <509C0C56.2050006@telecomitalia.it> In-Reply-To: <509C0C56.2050006@telecomitalia.it> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.1.2.227] Content-Type: multipart/mixed; boundary="_003_2779C9F0771F974CAD742BAE6D9904FE553CDD88PALLENEofficehd_" MIME-Version: 1.0 Subject: [CDNi] FW: Fwd: Re: [cdni-footprint] Rough Agenda for today's "CDNI Footprint/Capabilties Design Team 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: Wed, 12 Dec 2012 15:16:01 -0000 --_003_2779C9F0771F974CAD742BAE6D9904FE553CDD88PALLENEofficehd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just resending it for discussion ... Jan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Enr= ico Marocco Sent: Thursday, November 08, 2012 8:48 PM To: cdni@ietf.org Subject: [CDNi] Fwd: Re: [cdni-footprint] Rough Agenda for today's "CDNI Fo= otprint/Capabilties Design Team Call" Hi all, as the chairs suggested, here's an email sent some time ago on the footprint design team list a while ago. It has both a proposal for a solution to the issue just discussed in the room, and a description of the issue itself -- in the wrong order they should appear, I agree. Enrico -------- Original Message -------- Subject: Re: [cdni-footprint] [CDNi] Rough Agenda for today's "CDNI Footprint/Capabilties Design Team Call" Date: Wed, 10 Oct 2012 15:27:59 +0200 From: Enrico Marocco To: Scott Wainner CC: Jan Seedorf , "cdni-footprint@ietf.org" At the risk of biting off more than we can chew... after giving some thought at the use cases, here's how the footprint information may look like (JSON-encoded with , and operators in brackets, to show possible alternatives): "footprint" : [ { "zone" : { "from" : { "as" : "123" , "ipv4" : "1.2.3.0/24" , "geo" : "France" , } , "include" : { "as" : [ "123" , "456" ] , "ipv4" : [ "1.2.3.0/24" ] , "geo" : "France" } , "exclude" : { "as" : [ "789" ] , "ipv4" : [ "1.2.3.128/25" ] , "geo" : "Provence" } , } , "capabilities" : { ... } } , ... ] The "capabilities" are the topic of the next call, but I guess they will include properties such as RTT, RTSP/HLS support, etc, possibly bound to the business contract. In "include" goes what we have so far called the "willing to serve" area. Little doubt that for many people that's essential. Despite being optional, the "from" attribute is necessary in at least two cases: 1. as additional information for the uCDN to make a decision (e.g. when the contractual agreement does not constitute a solid basis for using the advertized "capabilities" alone); 2. when the dCDN cannot specify an explicit coverage area. An example of point 2 is when the traffic generated by a dCDN may have an impact on the peering (or possibly transit) agreements between the dCDN itself (or the transit provider associated with it) and the networks advertized in its "willing to serve" list. The fact that such agreements are quite often resolved in court constitutes a strong disincentive for the dCDN -- that may in fact be very willing to serve -- to advertize that explicitly. Finally the "exclude" attribute is the complementary of "include", for completeness and for cases when defining what's out is easier than defining what's in. Forget the encoding if you don't like it, if people agree something along this line could be used as a starting point -- and if people actually started pointing out what they believe is missing and what's to remove -- that I guess would be good progress. Enrico On 10/10/12 5:41 AM, Scott Wainner wrote: >=20 > Jan, >=20 > I propose two use cases that may be foundational building blocks=20 > for more sophisticated use cases: >=20 > Definition: > regional coverage: The CDN has cache nodes that service a well-defined=20 > geographic or topologically bounded network > global coverage: The CDN has cache nodes that service any geographic=20 > region and is topologically unbounded >=20 > 1) uCDN with regional coverage delegates to one or more dCDN for global=20 > coverage >=20 > Motivations for uCDN to delegate to dCDN might include the following: > - DECISION: uCDN client is outside the region > IMPACT: uCDN client is better served by global dCDN > CRITERIA: uCDN ascertains if the client is outside a=20 > well-defined region or IP topology > CRITERIA: uCDN ascertains if the requested content can be=20 > delivered by dCDN(s) (short list created) > CRITERIA: uCDN determines which dCDN is appropriate (chosen by= =20 > priority) > In this use case, I think its quite simple for the uCDN to know the BGP=20 > AS or geography covered because the uCDN is under the same=20 > administrative authority as the IP network to which it is attached. The= =20 > well-defined region is much more easily bounded. The global dCDN becomes= =20 > a CDN of last-resort. >=20 > 2) uCDN with global coverage delegates to one or more dCDN for regional=20 > coverage >=20 > Motivations for uCDN to delegate to dCDN might include the following: > - DECISION: uCDN client is inside a dCDN's well-defined region=20 > or IP topology > IMPACT: uCDN client is better served by regional dCDN > CRITERIA: uCDN ascertains if the client is inside a=20 > well-defined region or IP topology > CRITERIA: uCDN ascertains which dCDN's associated with the=20 > region can deliver the requested content (short list) > CRITERIA: uCDN determines which dCDN is appropriate (chosen by= =20 > priority) > In this case, the uCDN needs to know the candidate regions and have the=20 > ability to associate a client to the candidate region. That means each=20 > dCDN needs to advertise its candidate region to the global uCDN. The=20 > regional dCDN become CDN of preference provided the dCDN is available=20 > and capable of delivering the content. >=20 > I see three fundamental requirements: >=20 > region of coverage: either AS or geography or both > capability of delivery: services the content delivery method > availability: active and operational for servicing delivery requests >=20 > On 10/9/12 9:48 AM, Jan Seedorf wrote: >> Hi all, >> >> As rough thread for today's call, I suggest the following: >> -- short recap of the Vancouver discussions (Jan) >> -- continue discussions on capabilities >> -- discuss suggestion from Francois on focusing on some key use cases >> >> - Jan >> >> >>> -----Original Message----- >>> From: Jan Seedorf >>> Sent: Tuesday, October 02, 2012 10:49 AM >>> To: Jan Seedorf; cdni-footprint@ietf.org >>> Cc: cdni@ietf.org >>> Subject: RE: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties De= sign >>> Team Call" >>> >>> Based on the doodle, I suggest having design team phone calls on the >>> following dates (let's schedule two calls for now and then see where to= go >>> from there...): >>> >>> ** Tuesday, Oct. 9th, 16:00-18:00 CET ** >>> ** Tuesday, Oct. 16th, 16:00-18:00 CET ** >>> >>> On these dates most people seem to be able to join. Can someone please >>> set up a WebEx meeting for those dates and times? >>> >>> - Jan >>> >>> >>> >>>> -----Original Message----- >>>> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- >>>> bounces@ietf.org] On Behalf Of Jan Seedorf >>>> Sent: Friday, September 28, 2012 2:42 PM >>>> To: cdni-footprint@ietf.org >>>> Cc: cdni@ietf.org >>>> Subject: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Desig= n >>> Team >>>> Call" >>>> >>>> Hi all, >>>> >>>> I created a doodle for a CDNI Footprint/Capabilties Design Team Call: >>>> >>>> http://www.doodle.com/3u7pkrfctqa6u33g >>>> >>>> I would be good if we could make two calls in October to make progress >>>> before the Atlanta meeting, so please fill in the doodle if you are in= terested >>>> in joining the discussion. >>>> >>>> - Jan >>>> _______________________________________________ >>>> cdni-footprint mailing list >>>> cdni-footprint@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cdni-footprint >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> . >> >=20 > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint >=20 --_003_2779C9F0771F974CAD742BAE6D9904FE553CDD88PALLENEofficehd_ Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Description: S/MIME Cryptographic Signature.p7s Content-Disposition: attachment; filename="smime.p7s"; size=4498; creation-date="Thu, 08 Nov 2012 19:48:11 GMT"; modification-date="Thu, 08 Nov 2012 19:48:11 GMT" Content-ID: <86AB31E08C0A8F4082F3F58BC2E713A2@office.hd> Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCCBjQw ggQcoAMCAQICAR4wDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDE1NVoX DTE3MTAyNDIxMDE1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMcJg8zOLdgasSmkLhOrlr6KMoOMpohBllVHrdRvEg/q6r8jR+EK 75xCGhR8ToREoqe7zM9/UnC6TS2y9UKTpT1v7RSMzR0t6ndl0TWBuUr/UXBhPk+Kmy7bI4yW4urC +y7P3/1/X7U8ocb8VpH/Clt+4iq7nirMcNh6qJR+xjOhV+VHzQMALuGYn5KZmc1NbJQYclsGkDxD z2UbFqE2+6vIZoL+jb9x4Pa5gNf1TwSDkOkikZB1xtB4ZqtXThaABSONdfmv/Z1pua3FYxnCFmdr /+N2JLKutIxMYqQOJebr/f/h5t95m4JgrM3Y/w7YX9d7YAL9jvN4SydHsU6n65cCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBRTcu2SnODaywFc fH6WNU7y1LhRgjAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBAAqDCH14qywG XLhjjF6uHLkjd02hcdh9hrw+VUsv+q1eeQWB21jWj3kJ96AUlPCoEGZ/ynJNScWy6QMVQjbbMXlt UfO4n4bGGdKo3awPWp61tjAFgraLJgDk+DsSvUD6EowjMTNx25GQgyYJ5RPIzKKR9tQW8gGK+2+R HxkUCTbYFnL6kl8Ch507rUdPPipJ9CgJFws3kDS3gOS5WFMxcjO5DwKfKSETEPrHh7p5shuuNktv sv6hxHTLhiMKX893gxdT3XLS9OKmCv87vkINQcNEcIIoFWbP9HORz9v3vQwR4e3ksLc2JZOAFK+s sS5XMEoznzpihEP0PLc4dCBYjbvSD7kxgDwZ+Aj8Q9PkbvE9sIPP7ON0fz095HdThKjiVJe6vofq +n6b1NBc8XdrQvBmunwxD5nvtTW4vtN6VY7mUCmxsCieuoBJ9OlqmsVWQvifIYf40dJPZkk9YgGT zWLpXDSfLSplbY2LL9C9U0ptvjcDjefLTvqSFc7tw1sEhF0n/qpA2r0GpvkLRDmcSwVyPvmjFBGq Up/pNy8ZuPGQmHwFi2/14+xeSUDG2bwnsYJQG2EdJCB6luQ57GEnTA/yKZSTKI8dDQa8Sd3zfXb1 9mOgSF0bBdXbuKhEpuP9wirslFe6fQ1t5j5R0xi72MZ8ikMu1RQZKCyDbMwazlHiMIIHOzCCBiOg AwIBAgIDBKfoMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwHhcN MTIwODA3MDkxNTQzWhcNMTMwODA4MDczMzM3WjB1MRkwFwYDVQQNExBvWkNPVnNYc09NME9mcExw MSgwJgYDVQQDDB9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MS4wLAYJKoZIhvcNAQkB Fh9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAshI2shfUZ7P5RVcP04fJ4OfYmK/RUyokJpuJE4KaSOLArtpNtlYo6MtXfmZzA8y/ 5HChSAmPvqUwhMMYh1LurWbOdX4uKXO1gsFrPOtxTa6qin6lXaJ3bo2pKnkN9mQkjvm0E23rrrT3 MC6h6UfyFAcvs01+yq9wVuxxRdC4LZTGAbXGkE34GQAnBy9eqvJ+m351hPaaVw9u8CWNuyv9YKLX picS/q8j2EOpFBCkZVp0E8fViSXViGtuhfbW6R+TjTXJZN06DEqb/vpRSWkvBDf0UqDFrgmlmSnX J/xpaygAJcHyE5qjRXkIV7adTkg9Z/Z2lJXvtDUdHbNBiYcVOwIDAQABo4IDujCCA7YwCQYDVR0T BAIwADALBgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQW BBT1YgWCbkVCN8iNgS49Fh9R2ZC8wTAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAq BgNVHREEIzAhgR9lbnJpY28ubWFyb2Njb0B0ZWxlY29taXRhbGlhLml0MIICIQYDVR0gBIICGDCC AhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wu Y29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVy bWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNjb3JkaW5nIHRvIHRo ZSBDbGFzcyAxIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFydENvbSBDQSBwb2xp Y3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGluIGNvbXBsaWFuY2Ug b2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcCAjCBjzAnFiBTdGFy dENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkgYW5kIHdhcnJhbnRp ZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRhdGlvbnMiIG9mIHRo ZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0dHA6 Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggrBgEFBQcwAoY2aHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQuY2EuY3J0MCMGA1Ud EgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUFAAOCAQEAIn8FoRaq vQzo8aGNi4EbPhIMX8aPIMhX3L/N+8sMyFe3cpSyjij47DW1K330zDJnoyZskuI10EzfK0wwY+D2 qMQPGAmPDkix5t2dYQj6DKh1yBlBwAf7c65Ty1kpgtdymSptDJKVZcK6R2CJ91oRBCZIObcWrG/0 FZIr55+InAYyLDrlk34MwBmINhBZ4oRJdrzG6OC7cK4vG1ZWrAFEGHVwx1uG2NXRUXQTH9DGYcww fPo4uinFCwHZAJ2Il/J0Mqui5x+N/7p+WUlGRyb67qxg7ectf2095+YDnbqIKIz7fGzw8XTwpjYb vWZplkG93qRXr8MRD9ukgxpxpHG2dTGCA90wggPZAgEBMIGUMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAwSn6DAJBgUrDgMCGgUAoIICHTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0xMjExMDgxOTQ3MzRaMCMGCSqGSIb3DQEJBDEWBBTYoqDp+Z05d+/K65cQ A7B8D+lFSzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBKfo MIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMEp+gw DQYJKoZIhvcNAQEBBQAEggEAmwt29aT+3JMC3SFjN53ahnw3fK3kJG7F+t8dTkdNt//CMb953857 +b9fjWra0FrZmqYCJdaNunlJqe+Y1fZSsV+lTNTYA8mG9q5r2evqV5lFRyh3ChKTBzNarb0GMuQn lmt+rhl4Z3N7xXtpok9jtigZd1XENGTF/ATwuse6saTESWoxaDNKXWMxDF6DdLv8tWhcSgJweiDW 8L0jIC8tjFgDsLxsQLWsOQs1dhLJdEiwyp6JzRtPpkIaU5evmocvOLs8qvDhmu99TniPpw4tSyRT 2Ba8hCLsD+MgkHgpBe85Xru9e8LTCYtq7Vyc0xFSl9U9yZUrZwEDb2ydLAkWngAAAAAAAA== --_003_2779C9F0771F974CAD742BAE6D9904FE553CDD88PALLENEofficehd_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=127; creation-date="Thu, 08 Nov 2012 19:48:11 GMT"; modification-date="Thu, 08 Nov 2012 19:48:11 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNETmkgbWFp bGluZyBsaXN0DQpDRE5pQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2NkbmkNCg== --_003_2779C9F0771F974CAD742BAE6D9904FE553CDD88PALLENEofficehd_-- From internet-drafts@ietf.org Wed Dec 12 11:04:43 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE01F21E810B; Wed, 12 Dec 2012 11:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cd-Nfj0d+1U3; Wed, 12 Dec 2012 11:04:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722A921E80F7; Wed, 12 Dec 2012 11:04:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121212190442.1199.40846.idtracker@ietfa.amsl.com> Date: Wed, 12 Dec 2012 11:04:42 -0800 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Dec 2012 19:04:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Roy Peterkofsky Francois Le Faucheur Pawel Grochocki Filename : draft-ietf-cdni-logging-00.txt Pages : 43 Date : 2012-12-10 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the actual protocol for CDNI logging information exchange covering the information elements as well as the transport of those. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-logging-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gilles.bertrand@orange.com Wed Dec 12 23:53:59 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6E121F8A60 for ; Wed, 12 Dec 2012 23:53:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqCvBor+gqUo for ; Wed, 12 Dec 2012 23:53:58 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3891521F8A53 for ; Wed, 12 Dec 2012 23:53:58 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id E4F0C3B41F1 for ; Thu, 13 Dec 2012 08:53:56 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id A4C56238072 for ; Thu, 13 Dec 2012 08:53:56 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Thu, 13 Dec 2012 08:53:56 +0100 From: To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-00.txt Thread-Index: AQHN2JuNnCHMOfOhS0akoaSU4NJ2rJgWW6Cw Date: Thu, 13 Dec 2012 07:53:55 +0000 Message-ID: <1814_1355385236_50C98994_1814_14274_1_2AC63C9F27AF8446B0C064C50FC0A89306DF0A80@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20121212190442.1199.40846.idtracker@ietfa.amsl.com> In-Reply-To: <20121212190442.1199.40846.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.12.13.50327 Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2012 07:53:59 -0000 Hi, We have posted a revision of the logging draft with minor changes, just to = reflect the adoption of this draft by the working group. We will publish a = revision with more substantial modifications in the upcoming weeks.=20 Best regards, Gilles -----Message d'origine----- De=A0: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] De la part de i= nternet-drafts@ietf.org Envoy=E9=A0: mercredi 12 d=E9cembre 2012 20:05 =C0=A0: i-d-announce@ietf.org Cc=A0: cdni@ietf.org Objet=A0: [CDNi] I-D Action: draft-ietf-cdni-logging-00.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 : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Roy Peterkofsky Francois Le Faucheur Pawel Grochocki Filename : draft-ietf-cdni-logging-00.txt Pages : 43 Date : 2012-12-10 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the actual protocol for CDNI logging information exchange covering the information elements as well as the transport of those. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-logging-00 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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From Jan.Seedorf@neclab.eu Mon Dec 17 01:09:51 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A09F21F8A52 for ; Mon, 17 Dec 2012 01:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=-1.164, BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0DEOumyft3h for ; Mon, 17 Dec 2012 01:09:50 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5F08921F8A46 for ; Mon, 17 Dec 2012 01:09:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7AE1F102A6C for ; Mon, 17 Dec 2012 10:09: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 J-qmLWiz3CNI for ; Mon, 17 Dec 2012 10:09:48 +0100 (CET) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 5F47C102A68 for ; Mon, 17 Dec 2012 10:09:43 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.222]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 17 Dec 2012 10:08:59 +0100 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: Notes from last week's (Dec 12th, 2012) "footprint/capabilities" design team call Thread-Index: Ac3cNjNKgc35ZZQ5Tp+VbrWZnYY/wA== Date: Mon, 17 Dec 2012 09:08:58 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553DC04C@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 Subject: [CDNi] Notes from last week's (Dec 12th, 2012) "footprint/capabilities" design team call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 09:09:51 -0000 -- Discussion of Comment/Use case from Enrico; use case not clear by partic= ipants; Enrico not there to precisely explain, so decision not to discuss n= ow, but to postpone this discussion and have Enrico explain problem / use c= ase in more detail on mailing list;=20 -- suggestion from Francois to document progress & current issues in design= team so that before call people are up to date -- plan to make progress with "footprint" is to go through use case from Em= ile & Anne; Emile describes use case;=20 -- Jan: informal description of use case uses "country" as footprint, does = that make sense, i.e. geographical location? discussion on geographical loc= ation, Emile: makes sense, Stefano: makes sense; Stefano: problem is that t= here is no universal format for geographical location; Emile: there is ISO = format for regions; Stefano: what about relationship between geographical r= egions, e.g. distance between regions;=20 -- Jan: for reachability, what else is on the table besides IP-prefix, ASN,= geographical region? -- Emile mentions ISO 3166-2; Rich: were would that be encoded? -- Rich: let's go through use case with the footprint types on the table; J= an: indeed, that is the plan; question is where in detail some types of inf= ormation are problematic or better than others, on a high level all the rea= chability types of information on the table make sense to support the use c= ase; -- Jan: seems to be agreement that all reachability types on the table are = useful to support use case; Jan: so what about resource type of information= ? -- Stefano: should we go into more detail about the information types we de= finetely agree on (i.e. IP-prefix and AS-number)?=20 -- Jan: what about deriving requirements for conveying these types of infor= mation? -- Rich: what be interesting to derive rationale and requirements for resou= rce type use case -- Jan: summary is to digg deeper into requirements for agreed reachability= information types and to find out more the use case behind the resource ty= pe of information and what the requirements for conveying this type of info= rmation are =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 2832014=20 From internet-drafts@ietf.org Mon Dec 17 14:54:36 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0406221F89E8; Mon, 17 Dec 2012 14:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVE2Boe7GCbs; Mon, 17 Dec 2012 14:54:35 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB3221F89A5; Mon, 17 Dec 2012 14:54:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20121217225435.6225.11830.idtracker@ietfa.amsl.com> Date: Mon, 17 Dec 2012 14:54:35 -0800 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 22:54:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Framework for CDN Interconnection Author(s) : Larry Peterson Bruce Davie Filename : draft-ietf-cdni-framework-02.txt Pages : 55 Date : 2012-12-17 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. It obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-framework-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From flefauch@cisco.com Tue Dec 18 10:29:31 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6133821E8039 for ; Tue, 18 Dec 2012 10:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAGyG7NrZbWW for ; Tue, 18 Dec 2012 10:29:30 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C46DF21F8AD8 for ; Tue, 18 Dec 2012 10:29:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34316; q=dns/txt; s=iport; t=1355855370; x=1357064970; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=mG9AtUQwBZA4B+vJOCKSBReVjDrtf1L2Icxcec6CkL8=; b=CMJwlHTPD3u/ZQH3x0ZW0Jlul8rhxQ3PX8fFQpLqoWPSXKGrcXdYauUa 0YnC88fb2MK/ekPn12C8CeNS56ofYMX9XNk3Qg7vwGai2ak2pxsLJ8aGV Ef9983VWyp9rn7CvlOWeCYLIGJOFiAtjWuxAdlk+YRkQtkzAcPR3hQgY5 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEm10FCtJXG+/2dsb2JhbAArFwO+KRZzgh8BAQICAQEBYwIGGwIBCBQOCgQIAQIBAwcnCxQQAQIBAxMIiAsMLKdhgU+Oa4xJCxtvB4JGYQOmUoIjUIFtNQ X-IronPort-AV: E=Sophos;i="4.84,310,1355097600"; d="scan'208,217";a="154303981" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 18 Dec 2012 18:29:21 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBIITLgS018167 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 18 Dec 2012 18:29:21 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.128]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 12:29:21 -0600 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: [CDNi] Informal discussion on CDNI interface to use for customization of CDNI Logging: 19 Dec 8:00am PST Thread-Index: AQHN3U2YouAyfsLtkUqagB3TjjqgOA== Date: Tue, 18 Dec 2012 18:29:20 +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.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D2DBA9Dxmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [CDNi] Informal discussion on CDNI interface to use for customization of CDNI Logging: 19 Dec 8:00am PST X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 18:29:31 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D2DBA9Dxmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a friendly reminder about tomorrow's informal discussion (08:00 PST = =3D 11:00 EST =3D 17:00 CET). Talk to you then. Francois On 29 Nov 2012, at 11:28, Francois Le Faucheur wrote: Folks, Meeting has been rescheduled to 19 Dec. So here are the updated details: Date: Wednesday 19 December 2012 Start: 08:00 PST aka 17:00 CET Duration: 90 mins Webex details: see below Please mark this in your agenda if you are interested in attending. Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic. Francois Webex details: Topic: CDNI Logging Customization/Control Date: Wednesday, December 19, 2012 Time: 5:00 pm, Europe Time (Paris, GMT+01:00) Meeting Number: 207 377 422 Password: cdni ------------------------------------------------------- To join the meeting online ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D4843= 18167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:207 377 422 CCP:+14085256800x207377422# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. On 28 Nov 2012, at 16:19, Francois Le Faucheur (flefauch) wrote: Hi, It appeared in Atlanta that we need more discussion to conclude on which CD= NI interface (CI or MI) is to be used for customization/control of CDNI Log= ging. To facilitate an informal discussion on that topic, I have setup a Webex se= ssion for remote participation: Date: Wednesday 12 December 2012 Start: 08:00 PST aka 17:00 CET Duration: 90 mins Webex details: see below Please mark this in your agenda if you are interested in attending. Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic. Cheers Francois Topic: CDNI Logging Customization/Control Date: Wednesday, December 12, 2012 Time: 5:00 pm, Europe Time (Paris, GMT+01:00) Meeting Number: 207 377 422 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D4843= 18167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:207 377 422 CCP:+14085256800x207377422# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D2DBA9Dxmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9CC149EE765F234D8C16B642C77C9FF5@cisco.com> Content-Transfer-Encoding: quoted-printable Just a friendly reminder about tomorrow's informal discussion (08:00 PST = =3D 11:00 EST =3D 17:00 CET).
Talk to you then.
Francois

On 29 Nov 2012, at 11:28, Francois Le Faucheur wrote:

Folks,

Meeting has been rescheduled to 19 Dec. So here are the updated detail= s:

Date: Wednesday 19 December 2012
Start: 08:00 PST aka 17:00 CET
Duration: 90 mins
Webex details: see below

Please mark this in your agenda if you are interested in attending.

Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic.

Francois



Webex details:

Topic: CDNI Logging Cust= omization/Control = ;
Date: Wednesday, Decem= ber 19, 2012 
Time: 5:00 pm, Europe = Time (Paris, GMT+01:00) 
Meeting Number: 207 37= 7 422 
Password: cdni<= span class=3D"Apple-style-span" style=3D"font-family: Tahoma, Arial, sans-s= erif, Helvetica, Geneva; font-size: small; "> 

----------------------= --------------------------------- 
To join the meeting on= line 
----------------------= --------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D21125= 2322&UID=3D484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 
2. If requested, enter= your name and email address. 
3. If a password is re= quired, enter the meeting password: cdni 4. Click "Join&qu= ot;. 
5. If the meeting incl= udes a teleconference, follow the instructions that appear on your screen.<= /span> 

----------------------= --------------------------------- 
To join the audio conf= erence only 
----------------------= --------------------------------- 
To receive a call back= , provide your phone number when you join the meeting, or call the number b= elow and enter the access code. 
Call-in toll-free numb= er (US/Canada): +1-866-432-9903  Call-in toll number (U= S/Canada): +1-408-525-6800 
Toll-free dialing rest= rictions: = http://www.webex.com/pd= f/tollfree_restrictions.pdf 

Access code:207 377 42= 2 




CCP:+14085256800x2= 07377422# =

IMPORTANT NOTICE: This= WebEx service includes a feature that allows audio and any documents and o= ther materials exchanged or viewed during the session to be recorded. By joining this session, you automatically con= sent to such recordings. If you do not consent to the recording, discuss yo= ur concerns with the meeting host prior to the start of the recording or do= not join the session. Please note that any such recordings may be subject to discovery in the event of litig= ation. 
On 28 Nov 2012, at 16:19, Francois Le Faucheur (flefauch) wrote:

Hi,

It appeared in Atlanta that we need more discussion to conclude on whi= ch CDNI interface (CI or MI) is to be used for customization/control of CDN= I Logging.

To facilitate an informal discussion on that topic, I have setup a Web= ex session for remote participation:
Date:&= nbsp;Wednesday 12 December 2012
Start:=  08:00 PST aka 17:00 CET
Durati= on: 90 mins
Webex = details: see below

Please mark this in your agenda if you are interested in attending.

Again, note that this is not a formal session nor an IETF Interim Meet= ing. Just an informal discussion to exchange views on that topic.

Cheers

Francois 


Topic: CDNI Logging Cust= omization/Control = ;
Date: Wednesday, Decem= ber 12, 2012 
Time: 5:00 pm, Europe = Time (Paris, GMT+01:00) 
Meeting Number: 207 37= 7 422 
Password: cdni<= span class=3D"Apple-style-span" style=3D"font-family: Tahoma, Arial, sans-s= erif, Helvetica, Geneva; font-size: small; "> 

----------------------= --------------------------------- 
To join the meeting on= line(Now from mobile devices!) 
----------------------= --------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D21125= 2322&UID=3D484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 
2. If requested, enter= your name and email address. 
3. If a password is re= quired, enter the meeting password: cdni 4. Click "Join&qu= ot;. 
5. If the meeting incl= udes a teleconference, follow the instructions that appear on your screen.<= /span> 

----------------------= --------------------------------- 
To join the audio conf= erence only 
----------------------= --------------------------------- 
To receive a call back= , provide your phone number when you join the meeting, or call the number b= elow and enter the access code. 
Call-in toll-free numb= er (US/Canada): +1-866-432-9903  Call-in toll number (U= S/Canada): +1-408-525-6800 
Toll-free dialing rest= rictions: = http://www.webex.com/pd= f/tollfree_restrictions.pdf 

Access code:207 377 42= 2 




CCP:+14085256800x2= 07377422# =

IMPORTANT NOTICE: This= WebEx service includes a feature that allows audio and any documents and o= ther materials exchanged or viewed during the session to be recorded. By joining this session, you automatically con= sent to such recordings. If you do not consent to the recording, discuss yo= ur concerns with the meeting host prior to the start of the recording or do= not join the session. Please note that any such recordings may be subject to discovery in the event of litig= ation. 
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org= /mailman/listinfo/cdni


--_000_FC236DA6F2DA77449EF2D02DF4471A8D2DBA9Dxmbrcdx10ciscocom_-- From flefauch@cisco.com Wed Dec 19 07:40:32 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6F021F85BC for ; Wed, 19 Dec 2012 07:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOqOmzfHSNOj for ; Wed, 19 Dec 2012 07:40:31 -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 05B4121F85BA for ; Wed, 19 Dec 2012 07:40:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36833; q=dns/txt; s=iport; t=1355931631; x=1357141231; h=from:to:subject:date:message-id:references:mime-version; bh=uIkzQvqCu8mvneooirv/yjA2vYcYqVE6vjqdUsi05+w=; b=fvOL8E6rtJHLxrNUSJIKHUXzYLbyZw14WmI4bItfRN8otQWTlOliLZf1 1czQ/jdPiKK9C9gUHUDO/N5t6lG8wTGXwqkqkxEOzVyt85IhAIx9zrKrf pRcsa3CwNN5JHuO1C6nv9hQXuQBot9xVZYHPkad4h408DyHUmi3z2T5AK g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI7e0VCtJV2d/2dsb2JhbAAqFwO+BxZzgh4BAQECAgEBAWMCBhsCARkDAQILCgQIAQIBAwcnCxQJBwECAQMTCIgLDCyocY5sjE0LG28HgkZhA6ZSgiRQgW01 X-IronPort-AV: E=Sophos;i="4.84,318,1355097600"; d="scan'208,217";a="151662748" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 19 Dec 2012 15:40:30 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBJFeU1w029552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 19 Dec 2012 15:40:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.128]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 19 Dec 2012 09:40:30 -0600 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: Informal discussion on CDNI interface to use for customization of CDNI Logging: - starting in 20 mins Thread-Index: AQHN3f8sVAr0ltVCwECTUYJjx8Xuow== Date: Wed, 19 Dec 2012 15:40:29 +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.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D2DE50Exmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] Informal discussion on CDNI interface to use for customization of CDNI Logging: - starting in 20 mins X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Dec 2012 15:40:32 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D2DE50Exmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Begin forwarded message: From: "Francois Le Faucheur (flefauch)" > Subject: Re: [CDNi] Informal discussion on CDNI interface to use for custom= ization of CDNI Logging: 19 Dec 8:00am PST Date: 18 December 2012 19:29:20 CET To: ">" > Just a friendly reminder about tomorrow's informal discussion (08:00 PST = =3D 11:00 EST =3D 17:00 CET). Talk to you then. Francois On 29 Nov 2012, at 11:28, Francois Le Faucheur wrote: Folks, Meeting has been rescheduled to 19 Dec. So here are the updated details: Date: Wednesday 19 December 2012 Start: 08:00 PST aka 17:00 CET Duration: 90 mins Webex details: see below Please mark this in your agenda if you are interested in attending. Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic. Francois Webex details: Topic: CDNI Logging Customization/Control Date: Wednesday, December 19, 2012 Time: 5:00 pm, Europe Time (Paris, GMT+01:00) Meeting Number: 207 377 422 Password: cdni ------------------------------------------------------- To join the meeting online ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D4843= 18167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:207 377 422 CCP:+14085256800x207377422# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. On 28 Nov 2012, at 16:19, Francois Le Faucheur (flefauch) wrote: Hi, It appeared in Atlanta that we need more discussion to conclude on which CD= NI interface (CI or MI) is to be used for customization/control of CDNI Log= ging. To facilitate an informal discussion on that topic, I have setup a Webex se= ssion for remote participation: Date: Wednesday 12 December 2012 Start: 08:00 PST aka 17:00 CET Duration: 90 mins Webex details: see below Please mark this in your agenda if you are interested in attending. Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic. Cheers Francois Topic: CDNI Logging Customization/Control Date: Wednesday, December 12, 2012 Time: 5:00 pm, Europe Time (Paris, GMT+01:00) Meeting Number: 207 377 422 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D4843= 18167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:207 377 422 CCP:+14085256800x207377422# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ 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_FC236DA6F2DA77449EF2D02DF4471A8D2DE50Exmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <39E26C9705D9CE4EA9D8F24BD0CF3C02@cisco.com> Content-Transfer-Encoding: quoted-printable

Begin forwarded message:

From: "= ;Francois Le Faucheur (flefauch)" <flefauch@cisco.com>
Subject: Re= : [CDNi] Informal discussion on CDNI interface to use for customization of = CDNI Logging: 19 Dec 8:00am PST
Date: 18 De= cember 2012 19:29:20 CET

Just a friendly reminder about tomorrow's informal discussion (08:00 PST = =3D 11:00 EST =3D 17:00 CET).
Talk to you then.
Francois

On 29 Nov 2012, at 11:28, Francois Le Faucheur wrote:

Folks,

Meeting has been rescheduled to 19 Dec. So here are the updated detail= s:

Date: Wednesday 19 December 2012
Start: 08:00 PST aka 17:00 CET
Duration: 90 mins
Webex details: see below

Please mark this in your agenda if you are interested in attending.

Again, note that this is not a formal session nor an IETF Interim Meeting. = Just an informal discussion to exchange views on that topic.

Francois



Webex details:

Topic: CDNI Logging Cust= omization/Control = ;
Date: Wednesday, Decem= ber 19, 2012 
Time: 5:00 pm, Europe = Time (Paris, GMT+01:00) 
Meeting Number: 207 37= 7 422 
Password: cdni<= span class=3D"Apple-style-span" style=3D"font-family: Tahoma, Arial, sans-s= erif, Helvetica, Geneva; font-size: small; "> 

----------------------= --------------------------------- 
To join the meeting on= line 
----------------------= --------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D21125= 2322&UID=3D484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 
2. If requested, enter= your name and email address. 
3. If a password is re= quired, enter the meeting password: cdni 4. Click "Join&qu= ot;. 
5. If the meeting incl= udes a teleconference, follow the instructions that appear on your screen.<= /span> 

----------------------= --------------------------------- 
To join the audio conf= erence only 
----------------------= --------------------------------- 
To receive a call back= , provide your phone number when you join the meeting, or call the number b= elow and enter the access code. 
Call-in toll-free numb= er (US/Canada): +1-866-432-9903  Call-in toll number (U= S/Canada): +1-408-525-6800 
Toll-free dialing rest= rictions: = http://www.webex.com/pd= f/tollfree_restrictions.pdf 

Access code:207 377 42= 2 




CCP:+14085256800x2= 07377422# =

IMPORTANT NOTICE: This= WebEx service includes a feature that allows audio and any documents and o= ther materials exchanged or viewed during the session to be recorded. By joining this session, you automatically con= sent to such recordings. If you do not consent to the recording, discuss yo= ur concerns with the meeting host prior to the start of the recording or do= not join the session. Please note that any such recordings may be subject to discovery in the event of litig= ation. 
On 28 Nov 2012, at 16:19, Francois Le Faucheur (flefauch) wrote:

Hi,

It appeared in Atlanta that we need more discussion to conclude on whi= ch CDNI interface (CI or MI) is to be used for customization/control of CDN= I Logging.

To facilitate an informal discussion on that topic, I have setup a Web= ex session for remote participation:
Date:&= nbsp;Wednesday 12 December 2012
Start:=  08:00 PST aka 17:00 CET
Durati= on: 90 mins
Webex = details: see below

Please mark this in your agenda if you are interested in attending.

Again, note that this is not a formal session nor an IETF Interim Meet= ing. Just an informal discussion to exchange views on that topic.

Cheers

Francois 


Topic: CDNI Logging Cust= omization/Control = ;
Date: Wednesday, Decem= ber 12, 2012 
Time: 5:00 pm, Europe = Time (Paris, GMT+01:00) 
Meeting Number: 207 37= 7 422 
Password: cdni<= span class=3D"Apple-style-span" style=3D"font-family: Tahoma, Arial, sans-s= erif, Helvetica, Geneva; font-size: small; "> 

----------------------= --------------------------------- 
To join the meeting on= line(Now from mobile devices!) 
----------------------= --------------------------------- 
1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D21125= 2322&UID=3D484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D 
2. If requested, enter= your name and email address. 
3. If a password is re= quired, enter the meeting password: cdni 4. Click "Join&qu= ot;. 
5. If the meeting incl= udes a teleconference, follow the instructions that appear on your screen.<= /span> 

----------------------= --------------------------------- 
To join the audio conf= erence only 
----------------------= --------------------------------- 
To receive a call back= , provide your phone number when you join the meeting, or call the number b= elow and enter the access code. 
Call-in toll-free numb= er (US/Canada): +1-866-432-9903  Call-in toll number (U= S/Canada): +1-408-525-6800 
Toll-free dialing rest= rictions: = http://www.webex.com/pd= f/tollfree_restrictions.pdf 

Access code:207 377 42= 2 




CCP:+14085256800x2= 07377422# =

IMPORTANT NOTICE: This= WebEx service includes a feature that allows audio and any documents and o= ther materials exchanged or viewed during the session to be recorded. By joining this session, you automatically con= sent to such recordings. If you do not consent to the recording, discuss yo= ur concerns with the meeting host prior to the start of the recording or do= not join the session. Please note that any such recordings may be subject to discovery in the event of litig= ation. 
_______________________________________________
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_FC236DA6F2DA77449EF2D02DF4471A8D2DE50Exmbrcdx10ciscocom_-- From flefauch@cisco.com Thu Dec 20 02:45:48 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A3C21F87E7 for ; Thu, 20 Dec 2012 02:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.579 X-Spam-Level: X-Spam-Status: No, score=-9.579 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5z-ZqKkoKS4 for ; Thu, 20 Dec 2012 02:45:47 -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 D0B3121F87D2 for ; Thu, 20 Dec 2012 02:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9831; q=dns/txt; s=iport; t=1356000346; x=1357209946; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=/onaILIvNEy7Bpk/pbX1UdVLe8rkNRJY6dn98hPIjtc=; b=NzGUxOgqnFxMpiPP1IGzgkINT8JoL15Ug5znSyRcAZrhRMWe+dzRoVVT 25Km4AbdoRXyeoOT116AWBoKE7X+WGuQlFkW9nS8QeZW95xUUNiiw52yh 7lKXmDailuogSnkUvVxGkrvwKJbZAHJpVpEsH4a9XDruNDLOXcKAg82R/ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABXr0lCtJXHB/2dsb2JhbAAqFQIDvWoWc4IeAQEBAgEBAQEBJD8CBgYKCwIBHAQKCgQMCicLJAECAQMTCIgFBgwsqUuPC4xSCxsDbAeCRmEDplOCJFCBbTU X-IronPort-AV: E=Sophos;i="4.84,322,1355097600"; d="scan'208";a="152005915" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 20 Dec 2012 10:45:46 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBKAjj3l017756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 20 Dec 2012 10:45:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.128]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 04:45:45 -0600 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: CDNI Logging - 2 proposals for scoping of the first version of the CDNI interfaces Thread-Index: AQHN3p8pa0G21pA480etWVfhG/tsHA== Date: Thu, 20 Dec 2012 10:45:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI Logging - 2 proposals for scoping of the first version of the CDNI interfaces X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 10:45:48 -0000 Folks, (speaking as an individual) As announced earlier, a bunch of us (1) interested in CDNI Logging had an i= nformal discussion around two aspects of CDNI Logging Yesterday. We converg= ed on two proposals detailed below for which we are solliciting comments. P= lease review those and pass on the comments you may have, so the WG can mak= e a decision on those. Proposal 1: =3D=3D=3D=3D=3D=3D=3D=3D=20 o Aim to support in the first version of the CDNI interfaces: * customizable set of CDNI Logging fields (e.g. include a customizable se= t of logging information elements in a given log - possibly with a default = set) * customizable set of CDNI Logging events (e.g. include logs for a custom= izable set of events -eg for delivery but not for redirection) o Do _not_ aim to support in the first version of the CDNI interfaces: * a signaling mechanism to control such Logging customization. The rationale behind this proposal includes: * for initial CDNI deployments, it is reasonable to rely on "management pl= ane". In other words, humans in uCDN and dCDN can agree on what events are = to be logged by the other CDN and what set of logging fields are to be incl= uded, and then humans in uCDN and dCDN can configure their CDNI Logging sys= tems accordingly. * while a signaling mechanism allowing automation of such customization wo= uld be nice (and is a good candidate work item if/when CDNI WG recharters) = it is not an absolute-must-have for initial deployment * defining such a signaling mechanism would require non-negligible time an= d energy, that may be better spent in the short term on developing the CDNI= Logging interface itself that is not progressing as fast as needed Additional points: * there was no convergence among us on which CDNI interface (CDNI Control = or CDNI Metadata) should be used for signaling CDNI Logging customization/c= ontrol, if/when we decide to specify that * authors of the CDNI Metadata interface felt it is likely that the Metada= ta interface could be extended later to support CDNI Logging customization/= control, if/when we decide to specify it and if we decide to include it in = the CDNI Metadata interface. Authors of the CDNI Metadata are requested to = keep this topic in the back of their head to facilitate such potential exte= nsion * If the CDNI Control interface was to be used for CDNI Logging customizat= ion/control, the necessary mechanism would be quite different from the CDNI= Trigger proposal because CDNI Logging customization/control requires persi= stence of state. Proposal 2:=20 =3D=3D=3D=3D=3D=3D=3D=3D o Aim to support in the first version of the CDNI interfaces: * CDNI Logging in the dCDN-->uCDN direction o Do _not_ aim to support in the first version of the CDNI interfaces: * CDNI Logging in the uCDN-->dCDN direction The rationale behind this proposal includes: * there is unanimous agreement that CDNI Logging in the dCDN-->uCDN direct= ion is urgently needed * we did not convergence on whether CDNI Logging in the uCDN-->dCDN direct= ion is really needed and what are the exact use cases for it * while a few felt that it would probably be useful to have the ability to= pass CDNI Logs in the uCDN-->dCDN direction, it is clearly not an absolute= -must-have for initial deployment * since the CDNI Logging protocol itself (whether built on Syslog, IPFIX, = web-services,=85) is likely to pass information in one direction, adding lo= gs in the opposite direction can be easily done at a later stage by adding = another instance of the same protocol with opposite roles on both ends.=20 * defining CDNI Logging in the uCDN-->dCDN direction would require non-neg= ligible time and energy, that may be better spent in the short term on deve= loping CDNI Logging in the dCDN-->uCDN direction that is not progressing as= fast as needed Francois (1) Gilles B, Roy P, Emile S, Kevin M, Rob M, Ray v B, Bhumip K, Iuniana, R= ich W, Francois LF & a few others part of the time. On 18 Dec 2012, at 19:29, Francois Le Faucheur (flefauch) wrote: > Just a friendly reminder about tomorrow's informal discussion (08:00 PST = =3D 11:00 EST =3D 17:00 CET). > Talk to you then. > Francois >=20 > On 29 Nov 2012, at 11:28, Francois Le Faucheur wrote: >=20 >> Folks, >>=20 >> Meeting has been rescheduled to 19 Dec. So here are the updated details: >>=20 >> Date: Wednesday 19 December 2012 >> Start: 08:00 PST aka 17:00 CET >> Duration: 90 mins >> Webex details: see below >>=20 >> Please mark this in your agenda if you are interested in attending. >>=20 >> Again, note that this is not a formal session nor an IETF Interim Meetin= g. Just an informal discussion to exchange views on that topic. >>=20 >> Francois >>=20 >>=20 >>=20 >> Webex details: >>=20 >> Topic: CDNI Logging Customization/Control=20 >> Date: Wednesday, December 19, 2012=20 >> Time: 5:00 pm, Europe Time (Paris, GMT+01:00)=20 >> Meeting Number: 207 377 422=20 >> Password: cdni=20 >>=20 >> -------------------------------------------------------=20 >> To join the meeting online=20 >> -------------------------------------------------------=20 >> 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D4= 84318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D=20 >> 2. If requested, enter your name and email address.=20 >> 3. If a password is required, enter the meeting password: cdni=20 >> 4. Click "Join".=20 >> 5. If the meeting includes a teleconference, follow the instructions tha= t appear on your screen.=20 >>=20 >> -------------------------------------------------------=20 >> To join the audio conference only=20 >> -------------------------------------------------------=20 >> To receive a call back, provide your phone number when you join the meet= ing, or call the number below and enter the access code.=20 >> Call-in toll-free number (US/Canada): +1-866-432-9903=20 >> Call-in toll number (US/Canada): +1-408-525-6800=20 >> Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restri= ctions.pdf=20 >>=20 >> Access code:207 377 422=20 >>=20 >>=20 >>=20 >>=20 >> CCP:+14085256800x207377422#=20 >>=20 >> IMPORTANT NOTICE: This WebEx service includes a feature that allows audi= o and any documents and other materials exchanged or viewed during the sess= ion to be recorded. By joining this session, you automatically consent to s= uch recordings. If you do not consent to the recording, discuss your concer= ns with the meeting host prior to the start of the recording or do not join= the session. Please note that any such recordings may be subject to discov= ery in the event of litigation.=20 >>=20 >> On 28 Nov 2012, at 16:19, Francois Le Faucheur (flefauch) wrote: >>=20 >>> Hi, >>>=20 >>> It appeared in Atlanta that we need more discussion to conclude on whic= h CDNI interface (CI or MI) is to be used for customization/control of CDNI= Logging. >>>=20 >>> To facilitate an informal discussion on that topic, I have setup a Webe= x session for remote participation: >>> Date: Wednesday 12 December 2012 >>> Start: 08:00 PST aka 17:00 CET >>> Duration: 90 mins >>> Webex details: see below >>>=20 >>> Please mark this in your agenda if you are interested in attending. >>>=20 >>> Again, note that this is not a formal session nor an IETF Interim Meeti= ng. Just an informal discussion to exchange views on that topic. >>>=20 >>> Cheers >>>=20 >>> Francois=20 >>>=20 >>>=20 >>> Topic: CDNI Logging Customization/Control=20 >>> Date: Wednesday, December 12, 2012=20 >>> Time: 5:00 pm, Europe Time (Paris, GMT+01:00)=20 >>> Meeting Number: 207 377 422=20 >>> Password: cdni=20 >>>=20 >>> -------------------------------------------------------=20 >>> To join the meeting online(Now from mobile devices!)=20 >>> -------------------------------------------------------=20 >>> 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D211252322&UID=3D= 484318167&PW=3DNMTM0ZDI5MmM0&RT=3DMiMyMw%3D%3D=20 >>> 2. If requested, enter your name and email address.=20 >>> 3. If a password is required, enter the meeting password: cdni=20 >>> 4. Click "Join".=20 >>> 5. If the meeting includes a teleconference, follow the instructions th= at appear on your screen.=20 >>>=20 >>> -------------------------------------------------------=20 >>> To join the audio conference only=20 >>> -------------------------------------------------------=20 >>> To receive a call back, provide your phone number when you join the mee= ting, or call the number below and enter the access code.=20 >>> Call-in toll-free number (US/Canada): +1-866-432-9903=20 >>> Call-in toll number (US/Canada): +1-408-525-6800=20 >>> Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restr= ictions.pdf=20 >>>=20 >>> Access code:207 377 422=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> CCP:+14085256800x207377422#=20 >>>=20 >>> IMPORTANT NOTICE: This WebEx service includes a feature that allows aud= io and any documents and other materials exchanged or viewed during the ses= sion to be recorded. By joining this session, you automatically consent to = such recordings. If you do not consent to the recording, discuss your conce= rns with the meeting host prior to the start of the recording or do not joi= n the session. Please note that any such recordings may be subject to disco= very in the event of litigation.=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Thu Dec 20 09:48:06 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F32F21F8A71 for ; Thu, 20 Dec 2012 09:48:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.293 X-Spam-Level: X-Spam-Status: No, score=-10.293 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfvAL97Se90M for ; Thu, 20 Dec 2012 09:48:03 -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 1C54A21F8A70 for ; Thu, 20 Dec 2012 09:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=51100; q=dns/txt; s=iport; t=1356025683; x=1357235283; h=from:to:subject:date:message-id:references:mime-version; bh=EsfIOMRknWOp7b7DNimBZd2mbkU8oyWflTy0l9SOh3g=; b=Ek6jKq1TKV/eG3+liqu7kf68xpUJDw0eoMcyuQBFeDXvkbV0FSkOm6ta XMu55EGyjajEBOmnCtGMesKjCQdYREpD4htkn7abyD+ws+Ysg9A8BCy8W 1PocS41ICImgElx6AlEHSjujTUR+gs7dQqDdaEdQsxwujciruLyNgo9Oq o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOxN01CtJV2Y/2dsb2JhbABFvXIWc4IeAQEBBBoBDEALFwIBGQMBAgsLCwEGBzIUBwIIAgQBEggTh3i5Uok0gx4WeIJUYQOXJ48sgnSBZT0 X-IronPort-AV: E=Sophos;i="4.84,325,1355097600"; d="scan'208,217";a="155208582" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 20 Dec 2012 17:48:01 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBKHm1fE006375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Dec 2012 17:48:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.128]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 11:48:01 -0600 From: "Francois Le Faucheur (flefauch)" To: "" , "" Thread-Topic: 2nd batch of comments on cdni-framework Thread-Index: AQHN3tonyQaOyBK++E67F+Eqt1sqRw== Date: Thu, 20 Dec 2012 17:48:01 +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.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D2E3EF7xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] Fwd: 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: Thu, 20 Dec 2012 17:48:06 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D2E3EF7xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable To the WG, I just realized that I had inadvertently omitted to copy the cdni alias whe= n I sent my 2nd batch of comments on cdni-framework last October. So here i= t is below, just for the records. 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 message in = the message flows of Figure 3 and Figure 4. Is this an omission on your end= , or am I missing something and these messages are actually not needed? " section 3.2, Figure 3: I believe a HTTP request is missing in the acquisition phase (i.e. after st= ep 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dCDN wi= ll follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" which is = missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should happen = just before the "Data" message. " " Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.net" r= equest missing from the figure. " Thanks Francois Begin forwarded message: From: Francois Le Faucheur > Subject: 2nd batch of comments on cdni-framework Date: 31 October 2012 18:44:51 CET To: > Larry, Bruce, Below is the second batch of my detailed comments on cdni-framework-01 (as = an Individual). I don't think there is anything major missing from the document. I hope these comments are useful and can be addressed in a new version soon= . Cheers Francois =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As discussed off-line, one general change needed is to reflect the IETF-84 = decisions with respect to HAS. 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 sim= ilar 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. " 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. " section 3: I suggest tweaking titles of the example sections to make them more consist= ent and explicit: * section 3.2: "HTTP Redirect Example" --> "Iterative HTTP Redirection Exa= mple" * section 3.3: "Recursive Redirection Example" --> "Recursive HTTP Redirec= tion Example" * section 3.4: "DNS-based redirection example" --> "Iterative DNS-based Re= direction Example" * section 3.5: "Dynamic Footprint Discovery" --> "Dynamic Footprint Discov= ery example" * section 3.6: "Content Removal" --> "Content Removal Example" section 3: All figures are titled as "Request Trace for =85" I'd suggest titling them with something like "Message Flow for=85". This is= not really a "trace" and I am not sure what "request" is, because the mess= age flows contain both "requests" and "responses", and there are message fl= ows that don't relate to any "content request". section 3.2, Figure 3: I believe a HTTP request is missing in the acquisition phase (i.e. after st= ep 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dCDN wi= ll follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" which is = missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should happen = just before the "Data" message. 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 earlier st= eps e.g. to look at metadata to decide if/how to redirect etc, so better le= ave it open). section 3.2.1: OLD " For example, obtaining information from dCDN regarding the set of client 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 client IP addresses or geographic regions it might be able to serve is an aspect of the CDNI request routing interface (specifically of the CDNI Fo= otprint & Capabilities advertisement interface). " section 3.2.1: OLD " Hence, there is no explicit metadata interface invoked in this example. " NEW: " The example also assumes that the CSP does not require any distribution pol= icy (e.g. time window, geo-blocking) or delivery processing to be applied b= y the interconnected CDNs. Hence, there is no explicit metadata interface i= nvoked in this example. " 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 Routi= ng Redirection interface) to enable "recursive" CDNI request routing. " 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 convenie= nt to do it that way, it is not an absolute requirement.) 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 those 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 brought up = multiple times wrt current framework is a need to clarify what is example f= rom what is prescription. Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.net" r= equest missing from the figure. 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 Operator B " (more generally, you need to check all occurrences of "Request Routing Inte= rface" or "RRI" throughout the document and align to our finalized nomencla= ture of "CDNI Request Routing Redirection interface" and "CDNI Footprint & = Capabilities advertisement interface". In Figure 4, "RRI REQ" needs to be changed to something like "RR-RI REQ") 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 informati= on is cached). " (Rationale: in the HTTP redirection case, the extra RTTs have to do with DN= S request for very stable information such as the IP address of the CDN dom= ains or delivery nodes. Those can be appropriately handled with long TTLs -= certainly compared to the TTL that needs to be applied in case of DNS redi= rection. So in practice, for many requests the nb of real RTTs would be sim= ilar. In fact, I'd suggest you bring up this point). OLD: " In this case, one option is for the upstream CDN to treat the end-user as it would any user not connected to a peer CDN. " NEW: " In this case, and assuming the uCDN is capable of detecting that situation,= one option is for the upstream CDN to treat the end-user as it would any user not connected to a peer CDN. " 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 conseque= nces are arguably less serious in existing CDNs" or "the consequences are = arguably less serious CDNI". Second, I don't quite see the difference between the two: if an enduser use= s a global DNS, then a single CDN just cannot make any reasonable decision,= nor can an uCDN in CDNI. section 3.5, Figure 6: OLD: " RRI REQ " NEW: " RR-F&CAI REQ " (in line with earlier comment: for "Request Routing - Footprint and Capabil= ities Advertisement interface) section 3.5: The notion of Footprint discovery could be illustrated with either DNS or H= TTP. The document currently illustrates it with DNS. However, it gets a lit= tle confusing because (i) the example interaction mentioned is "Can you serve clients from this IP Prefix?" and (ii) the text just before section= 3.5 just discussed the issue of identifying the client IP address in case = of HTTP redirection (which is why a note was added : "(Note that the issues= of determining the client's subnet from DNS requests, as described above, = are exactly the same here as in Section 3.4.) ". I would suggest simply using HTTP redirection (instead of DNS) in the examp= le of section 3.5. I think it would make the concept of footprint discovery= easier to get for the reader. Figure 7: you included step numbers (e.g "(1)") in the Figure but did not refer to th= ose in the description text. 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. " section 3.7, Figure 8: Figure 8 actually shows a scenario where dCDN performs DNS redirection for = intra-CDN request routing (i.e. in step 6). This is in contradiction with t= he 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 and in= volved an additional step 5. Also it is the first time where an example mix= es HTTP redirection across CDNs with DNS redirection inside a CDN, and whil= e I don't have a problem in showing such a combination, I don't think it sh= ould be introduced in the middle of the example illustrating prepositioning= . 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). section 3.8: We have progressed on the topic of "metadata push" and this is now seen 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 : "Pre-posi= tioned 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 Figure 7). If you feel it is useful you could put a note that this could have been rea= lized via a push mechanism, but that CDNI solution has selected a triggered= Pull solution at least initially. But I suggest the description be made us= ing triggered Pull. 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 ietf-cd= ni-metadata, there is only one single bit of info that needs to be known ah= ead of time which is the URI of the Metadata server, from which everything = can be learnt. And this info is expected to be known via config, or learnt = via some future CDNI auto discovery protocol. This basically removes the ne= ed for any seed info related to a content or content range. So I recommend removing step 1 from the Figure and from the text. section 3.10: OLD: " 3.10. Content Acquisition with Multiple Upstream CDNs " NEW: " 3.10. Content Acquisition and Metadata Acquisition with Multiple Upstream = CDNs " OLD: " Given that the dCDN has established a business relationship with each of it= s 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 metadata from each to determine which uCDNs are hosting metadata for the requested content. If there is a single uCDN hosting metadata for the req= uested content, the dCDN can assume that the request redirection is coming = from this uCDN and can acquire content from that uCDN. If there are multipl= e uCDNs hosting metadata for the requested content, the dCDN may be ready t= o 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 uCD= Ns, it needs to ensure via out of band arrangements that, for a given conte= nt, only a single uCDN will ever redirect requests to the dCDN. " OLD: " tightly c coupled " NEW: " tightly coupled " 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 other rel= evant interfaces. " 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-cdni-p= roblem-statement] and [I-D.ietf-cdni-requirements] for some discussion of the interfaces. " 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" interface = 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. " section 4.2: OLD: " While in the the limit " NEW: " While in the limit " section 4.2: I recommend the text in this section: * be aligned to our finalized nomenclature of "CDNI Request Routing Redirec= tion interface" and "CDNI Footprint & Capabilities advertisement interface"= . * be structured to separate discussion on these two interfaces * refers to draft-spp-cdni-rr-foot-cap-semantics ( CDNI Request Routing: Fo= otprint and Capabilities Semantics) when discussing the information to adv= ertise as footprint 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. " section 4.4: [I-D.lefaucheur-cdni-logging-delivery] has been incorporated into [I-D.bert= rand-cdni-logging], so you only need to refer to the latter. section 4.6: [I-D.ma-cdni-metadata] and [I-D.cjlmw-cdni-metadata] are now merged into ie= tf-cdni-metadata, so you only need to refer to that document. 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 content= by dCDN (e.g. alternate sources for the content, authorization information= needed to acquire the content from the source). " (Rationale: just aligning metadata examples to what is likely supported by = the metadata interface, to avoid confusion). 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 mechanis= ms. 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 come w= ith shortcomings such as inability to prevent from replay outside the time = window or inability to make use of a downstream CDN that covers a broader f= ootprint than the geo-blocking restrictions. " 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 themselves = (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 s= hortcomings with that approach, such as difficulty in preventing replays th= at bypass the access control policies) OLD: " to express this its desire " NEW: " to express its desire " section 5: OLD: " and that may other models " NEW: " and that many other models " --_000_FC236DA6F2DA77449EF2D02DF4471A8D2E3EF7xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
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.

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= ?

"
section 3.2, Figure 3:
I believe a HTTP request is missing in the acquis= ition phase (i.e. after step 8). After the uCDN issues the "302 node2.= op-b.acq.op-A.net", the dCDN will follow the redirect and issue a &quo= t;HTTP node2.op-b.acq.op-A.net" which is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should happ= en 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.
"

Thanks

Francois





Begin forwarded message:

From: Franc= ois Le Faucheur <flefauch@cisco.co= m>
Subject: 2n= d batch of comments on cdni-framework
Date: 31 Oc= tober 2012 18:44:51 CET
To: <<= a href=3D"mailto:draft-ietf-cdni-framework@tools.ietf.org">draft-ietf-cdni-= framework@tools.ietf.org>

Larry, Bruce,

Below is the second batch of my detailed comments on cdni-framework-01 (as = an Individual).
I don't think there is anything major missing from the document.

I hope these comments are useful and can be addressed in a new version soon= .

Cheers

Francois


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


As discussed off-line, one general change needed is to reflect the IETF-84 = decisions with respect to HAS.


section 1.1:
OLD:
"
Recursive CDNI request routing: When an Upstream CDN elects to
  redirect a request towards a Downstream CDN, the Upstream CDN c= an
  query the Downstream CDN Request Routing system via the CDNI Re= quest
  Routing interface (or use information cached from earlier simil= ar
  queries) to find out how the Downstream CDN wants the request t= o be
  redirected, which allows the Upstream CDN to factor in the Down= stream
  CDN response when redirecting the user agent.  This approa= ch is
  referred to as "recursive" CDNI request routing. &nbs= p;Note that the
  Downstream CDN may elect to have the request redirected directl= y to a
  Surrogate inside the Downstream CDN, to the Request-Routing Sys= tem 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 c= an
  query the Downstream CDN Request Routing system via the CDNI Re= quest
  Routing Redirection interface (or use information cached from e= arlier similar
  queries) to find out how the Downstream CDN wants the request t= o be
  redirected, which allows the Upstream CDN to factor in the Down= stream
  CDN response when redirecting the user agent.  This approa= ch is
  referred to as "Recursive" CDNI Request Redirection. =  Note that the
  Downstream CDN may elect to have the request redirected directl= y to a
  Surrogate inside the Downstream CDN, to the Request-Routing Sys= tem of
  the Downstream CDN, to another CDN, or to any other system that= the
  Downstream CDN sees as fit for handling the redirected request.=
"


OLD:
"
  Iterative CDNI Request Routing: When an Upstream CDN elects to<= br>   redirect a request towards a Downstream CDN, the Upstream CDN c= an
  base its redirection purely on a local decision (and without   attempting to take into account how the Downstream CDN may in t= urn
  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 ap= proach
  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 c= an
  base its redirection purely on a local decision (and without   attempting to take into account how the Downstream CDN may in t= urn
  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 ap= proach
  is referred to as "Iterative" CDNI Request Redirectio= n.
"



section 3:
I suggest tweaking titles of the example sections to make them more consist= ent and explicit:
* section 3= .2:  "HTTP Redirect Example" --> "Iterative HTTP Red= irection Example"
* section 3= .3:  "Recursive Redirection Example" --> "Recursive = HTTP Redirection Example"
* section 3= .4:  "DNS-based redirection example" --> "Iterative = DNS-based Redirection Example"
* section 3= .5:  "Dynamic Footprint Discovery" --> "Dynamic Foot= print Discovery example"
* section 3= .6:  "Content Removal" --> "Content Removal Example&= quot;


section 3:
All figures are titled as "Request Trace for =85"
I'd suggest titling them with something like "Message Flow for=85"= ;. This is not really a "trace" and I am not sure what "requ= est" is, because the message flows contain both "requests" a= nd "responses", and there are message flows that don't relate to = any "content request".


section 3.2, Figure 3:
I believe a HTTP request is missing in the acquisition phase (i.e. after st= ep 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", t= he dCDN will follow the redirect and issue a "HTTP node2.op-b.acq.op-A= .net" which is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should happen just before the "Data&quo= t; message.


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 earlier st= eps e.g. to look at metadata to decide if/how to redirect etc, so better le= ave it open).


section 3.2.1:
OLD
"
For example, obtaining information from dCDN regarding the set of client   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 client   IP addresses or geographic regions it might be able to serve is= an
  aspect of the CDNI request routing interface (specifically of t= he CDNI Footprint & Capabilities advertisement interface).
"


section 3.2.1:
OLD
"
Hence, there is no explicit metadata interface invoked in this example.
"
NEW:
"
The example also assumes that the CSP does not require any distribution pol= icy (e.g. time window, geo-blocking) or delivery processing to be applied b= y the interconnected CDNs. Hence, there is no explicit metadata interface i= nvoked in this example.
"


section 3.3:
OLD:
"
The following example builds on the previous one to illustrate the
  use of the Request Routing interface to enable "recursive&= quot; CDNI
  request routing.
"
NEW:
"
The following example builds on the previous one to illustrate the
  use of the Request Routing interface (specifically the CDNI Req= uest Routing Redirection interface) to enable "recursive" CDNI re= quest routing.
"

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 convenie= nt to do it that way, it is not an absolute requirement.)


section 3.3:
"
DNS must be configured in the following way:
"
Again, I suggest the text is tweaked in multiple places so that the "m= ust" is replaced by something like "we assume that". Because= a lot of those are just how the example works, but is not a "must&quo= t; 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 brought up = multiple times wrt current framework is a need to clarify what is example f= rom what is prescription.


Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.n= et" request missing from the figure.

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 Operator B<= br> "
(more generally, you need to check all occurrences of "Request Routing= Interface" or "RRI" throughout the document and align to ou= r finalized nomenclature of "CDNI Request Routing Redirection interfac= e" and "CDNI Footprint & Capabilities advertisement interface= ".
In Figure 4, "RRI REQ" needs to be changed to something like &quo= t;RR-RI REQ")


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= information is cached).
"
(Rationale: in the HTTP redirection case, the extra RTTs have to do with DN= S request for very stable information such as the IP address of the CDN dom= ains or delivery nodes. Those can be appropriately handled with long TTLs -= certainly compared to the TTL that needs to be applied in case of DNS redirection. So in practice, for many r= equests the nb of real RTTs would be similar. In fact, I'd suggest you brin= g up this point).


OLD:
"
In this case, one option is for the upstream CDN to treat the end-user
  as it would any user not connected to a peer CDN.
"
NEW:
"
In this case, and assuming the uCDN is capable of detecting that situation,= one option is for the upstream CDN to treat the end-user
  as it would any user not connected to a peer CDN.
"


OLD:
"
Note that this
  problem affects existing CDNs that rely on DNS to determine whe= re to
  redirect client requests, but the consequences are arguably les= s
  serious since the LDNS is likely in the same network as the dCD= N
  serves.
"
I don't quite get that sentence.
First, I suggest you make it explicit as to whether you mean  "th= e consequences are arguably less serious in existing CDNs" or  &q= uot;the consequences are arguably less serious CDNI".
Second, I don't quite see the difference between the two: if an enduser use= s a global DNS, then a single CDN just cannot make any reasonable decision,= nor can an uCDN in CDNI.


section 3.5, Figure 6:
OLD:
"
RRI REQ
"
NEW:
"
RR-F&CAI REQ
"
(in line with earlier comment: for "Request Routing - Footprint and Ca= pabilities Advertisement interface)


section 3.5:
The notion of Footprint discovery could be illustrated with either DNS or H= TTP. The document currently illustrates it with DNS. However, it gets a lit= tle confusing because (i) the example interaction mentioned is "Can yo= u
  serve clients from this IP Prefix?" and (ii) the text just= before section 3.5 just discussed the issue of identifying the client IP a= ddress in case of HTTP redirection (which is why a note was added : "(= Note that the issues of determining the client's subnet from DNS requests, as described above, are exactly the same here as
  in Section 3.4.) ".
I would suggest simply using HTTP redirection (instead of DNS) in the examp= le of section 3.5. I think it would make the concept of footprint discovery= easier to get for the reader.


Figure 7:
you included step numbers (e.g "(1)") in the Figure but did not r= efer to those in the description text.


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 dC= DN.
"


section 3.7, Figure 8:
Figure 8 actually shows a scenario where dCDN performs DNS redirection for = intra-CDN request routing (i.e. in step 6). This is in contradiction with t= he 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 and 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 it should be introduced in the middle of= the example illustrating prepositioning.
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).


section 3.8:
We have progressed on the topic of "metadata push" and this is no= w seen as "triggered pull" initiated by the Control interface. While it is logically close to a metadata push, I recommend that:
* the termi= nology be updated to current one e.g. as per RFC6707 : "Pre-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 Figure 7).
If you feel it is useful you could put a note that this could have been rea= lized via a push mechanism, but that CDNI solution has selected a triggered= Pull solution at least initially. But I suggest the description be made us= ing triggered Pull.


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 ietf-cdni-metadata, there is only one single bit of info that needs to b= e known ahead of time which is the URI of the Metadata server, from which e= verything can be learnt. And this info is expected to be known via config, or learnt via some future CDNI auto disco= very 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.


section 3.10:
OLD:
"
3.10.  Content Acquisition with Multiple Upstream CDNs
"
NEW:
"
3.10.  Content Acquisition and Metadata Acquisition with Multiple Upst= ream CDNs
"


OLD:
"
Given that the dCDN has established a business relationship with each of it= s 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 metada= ta
  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 metadata<= br>   from each to determine which uCDNs are hosting metadata for the=
  requested content. If there is a single uCDN hosting metadata f= or the requested content, the dCDN can assume that the request redirection = is coming from this uCDN and can acquire content from that uCDN. If there a= re multiple uCDNs hosting metadata for the requested content, the dCDN may be ready to trust any of these uCDNs to ac= quire 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 o= f band arrangements that, for a given content, only a single uCDN will ever redirect requests to the dCDN.= "


OLD:
"
tightly c coupled
"
NEW:
"
tightly coupled
"


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 other rel= evant interfaces.
"


OLD:
"
The detailed specifications
  of these interfaces are left to other documents (mostly still t= o be
  written, but see [I-D.ietf-cdni-problem-statement] and
  [I-D.ietf-cdni-requirements] for some discussion of the interfa= ces).
"
NEW:
"
The detailed specifications
  of these interfaces are left to other documents, but see [I-D.i= etf-cdni-problem-statement] and
  [I-D.ietf-cdni-requirements] for some discussion of the interfa= ces.
"


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 pass= ing
  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 "Requ= est" interface in Figure 1).  As we saw in some of the
  preceding examples, that interface can be used as a way of pass= ing
  information a subset of metadata such as the minimum informatio= n that is required for dCDN to obtain the
  content from uCDN.
"

section 4.2:
OLD:
"
While in the the limit
"
NEW:
"
While in the limit
"


section 4.2:
I recommend the text in this section:
* be aligne= d to our finalized nomenclature of "CDNI Request Routing Redirection i= nterface" and "CDNI Footprint & Capabilities advertisement in= terface".
* be struct= ured to separate discussion on these two interfaces
* refers to= draft-spp-cdni-rr-foot-cap-semantics ( CDNI Request Routing: Footprint and= Capabilities Semantics)  when discussing the information to advertise= as footprint


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.
"

section 4.4:
[I-D.lefaucheur-cdni-logging-delivery] has been incorporated into [I-D.bert= rand-cdni-logging], so you only need to refer to the latter.

section 4.6:
[I-D.ma-cdni-metadata] and [I-D.cjlmw-cdni-metadata] are now merged into ie= tf-cdni-metadata, so you only need to refer to that document.

section 4.6:
OLD:
"
Such metadata includes geo-blocking
  restrictions, availability windows, access control policies, an= d so
  on.  It may also include policy information such as the de= sire to
  pre-position content rather than fetch it on demand.
"
NEW:
"
Such metadata includes geo-blocking
  restrictions, availability windows, access control policies, an= d so
  on.  It may also include information to facilitate acquisi= tion of content by dCDN (e.g. alternate sources for the content, authorizat= ion information needed to acquire the content from the source).
"
(Rationale: just aligning metadata examples to what is likely supported by = the metadata interface, to avoid confusion).


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 U= RL.
  Similarly, the request could be forwarded only if the current t= ime is
  within the availability window.
"
NEW:
"
Some distribution metadata may be partially emulated using in-band mechanis= ms.
  For example, in case of any geo-blocking
  restrictions or availability windows, the upstream CDN can elec= t to
  redirect a request to the downstream CDN only if that CDN's
  advertised delivery footprint is acceptable for the requested U= RL.
  Similarly, the request could be forwarded only if the current t= ime is
  within the availability window. However, such approaches typica= lly come with shortcomings such as inability to prevent from replay outside= the time window or inability to make use of a downstream CDN that covers a= broader footprint than the geo-blocking restrictions.
"


OLD:
"
All of these in-band techniques serve to illustrate that uCDNs have
  the option of enforcing their access control policies themselve= s,
  rather than delegating enforcement to dCDNs using the Metadata<= br>   interface.
"
NEW:
"
All of these in-band techniques serve to illustrate that uCDNs have
  the option of enforcing some of their access control policies t= hemselves (at the expense of increased inter-CDN signaling load),
  rather than delegating enforcement to dCDNs using the Metadata<= br>   interface.
"
(Rationale: the text is toned down a little bit because I think there are s= hortcomings with that approach, such as difficulty in preventing replays th= at bypass the access control policies)


OLD:
"
to express this its desire
"
NEW:
"
to express its desire
"

section 5:
OLD:
"
and that may other models
"
NEW:
"
and that many other models
"

--_000_FC236DA6F2DA77449EF2D02DF4471A8D2E3EF7xmbrcdx10ciscocom_-- From lpeterson@verivue.com Fri Dec 21 06:26:30 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F11BD21F842C for ; Fri, 21 Dec 2012 06:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7zZVYL7Jz-1 for ; Fri, 21 Dec 2012 06:26:28 -0800 (PST) Received: from exprod8og101.obsmtp.com (exprod8og101.obsmtp.com [64.18.3.82]) by ietfa.amsl.com (Postfix) with SMTP id DE0E321F8455 for ; Fri, 21 Dec 2012 06:26:27 -0800 (PST) Received: from vvexch.verivue.com ([38.83.192.68]) by exprod8ob101.postini.com ([64.18.7.12]) with SMTP ID DSNKUNRxhiKRARoZ3au6kIPqYgjY/w0bkn+T@postini.com; Fri, 21 Dec 2012 06:26:28 PST Received: from vvexch.verivue.com ([10.160.6.20]) by vvexch.verivue.com ([10.160.6.20]) with mapi; Fri, 21 Dec 2012 09:14:38 -0500 From: "Peterson, Larry" To: "Francois Le Faucheur (flefauch)" Date: Fri, 21 Dec 2012 09:14:37 -0500 Thread-Topic: 2nd batch of comments on cdni-framework Thread-Index: Ac3fhYKveQsjlh3vTeCXEWejLptb9A== Message-ID: <8E46261D-5CD6-46CC-AD81-7F5CF8E7F595@verivue.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" 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, 21 Dec 2012 14:26:30 -0000 Francois, You're right. I should have warned you. My reading is that the explanation in the text covers (explains) that case, which we don't need to trace expli= citly. Larry On Dec 20, 2012, at 10:48 AM, Francois Le Faucheur (flefauch) wrote: > To the WG, > I just realized that I had inadvertently omitted to copy the cdni alias w= hen I sent my 2nd batch of comments on cdni-framework last October. So here= it is below, just for the records. > > 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 message i= n the message flows of Figure 3 and Figure 4. Is this an omission on your e= nd, or am I missing something and these messages are actually not needed? > > " >> section 3.2, Figure 3: >> I believe a HTTP request is missing in the acquisition phase (i.e. after= step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dCDN= will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" which = is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should happ= en 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. > " > > Thanks > > Francois > > > > > > Begin forwarded message: > >> From: Francois Le Faucheur >> Subject: 2nd batch of comments on cdni-framework >> Date: 31 October 2012 18:44:51 CET >> To: >> >> Larry, Bruce, >> >> Below is the second batch of my detailed comments on cdni-framework-01 (= as an Individual). >> I don't think there is anything major missing from the document. >> >> I hope these comments are useful and can be addressed in a new version s= oon. >> >> Cheers >> >> Francois >> >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >> >> As discussed off-line, one general change needed is to reflect the IETF-= 84 decisions with respect to HAS. >> >> >> 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. >> " >> >> >> 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. >> " >> >> >> >> section 3: >> I suggest tweaking titles of the example sections to make them more cons= istent and explicit: >> * section 3.2: "HTTP Redirect Example" --> "Iterative HTTP Redirection = Example" >> * section 3.3: "Recursive Redirection Example" --> "Recursive HTTP Redi= rection Example" >> * section 3.4: "DNS-based redirection example" --> "Iterative DNS-based= Redirection Example" >> * section 3.5: "Dynamic Footprint Discovery" --> "Dynamic Footprint Dis= covery example" >> * section 3.6: "Content Removal" --> "Content Removal Example" >> >> >> section 3: >> All figures are titled as "Request Trace for =85" >> I'd suggest titling them with something like "Message Flow for=85". This= is not really a "trace" and I am not sure what "request" is, because the m= essage flows contain both "requests" and "responses", and there are message= flows that don't relate to any "content request". >> >> >> section 3.2, Figure 3: >> I believe a HTTP request is missing in the acquisition phase (i.e. after= step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dCDN= will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" which = is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should happ= en just before the "Data" message. >> >> >> 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 earlier= steps e.g. to look at metadata to decide if/how to redirect etc, so better= leave it open). >> >> >> section 3.2.1: >> OLD >> " >> For example, obtaining information from dCDN regarding the set of client >> 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 client >> IP addresses or geographic regions it might be able to serve is an >> aspect of the CDNI request routing interface (specifically of the CDNI= Footprint & Capabilities advertisement interface). >> " >> >> >> section 3.2.1: >> OLD >> " >> Hence, there is no explicit metadata interface invoked in this example. >> " >> NEW: >> " >> The example also assumes that the CSP does not require any distribution = policy (e.g. time window, geo-blocking) or delivery processing to be applie= d by the interconnected CDNs. Hence, there is no explicit metadata interfac= e invoked in this example. >> " >> >> >> 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 Ro= uting Redirection interface) to enable "recursive" CDNI request routing. >> " >> >> 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 conve= nient to do it that way, it is not an absolute requirement.) >> >> >> section 3.3: >> " >> DNS must be configured in the following way: >> " >> Again, I suggest the text is tweaked in multiple places so that the "mus= t" is replaced by something like "we assume that". Because a lot of those a= re 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 brought = up multiple times wrt current framework is a need to clarify what is exampl= e from what is prescription. >> >> >> Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.net= " request missing from the figure. >> >> 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 Operator= B >> " >> (more generally, you need to check all occurrences of "Request Routing I= nterface" or "RRI" throughout the document and align to our finalized nomen= clature of "CDNI Request Routing Redirection interface" and "CDNI Footprint= & Capabilities advertisement interface". >> In Figure 4, "RRI REQ" needs to be changed to something like "RR-RI REQ"= ) >> >> >> 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 inform= ation is cached). >> " >> (Rationale: in the HTTP redirection case, the extra RTTs have to do with= DNS request for very stable information such as the IP address of the CDN = domains or delivery nodes. Those can be appropriately handled with long TTL= s - certainly compared to the TTL that needs to be applied in case of DNS r= edirection. So in practice, for many requests the nb of real RTTs would be = similar. In fact, I'd suggest you bring up this point). >> >> >> OLD: >> " >> In this case, one option is for the upstream CDN to treat the end-user >> as it would any user not connected to a peer CDN. >> " >> NEW: >> " >> In this case, and assuming the uCDN is capable of detecting that situati= on, one option is for the upstream CDN to treat the end-user >> as it would any user not connected to a peer CDN. >> " >> >> >> 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 conse= quences are arguably less serious in existing CDNs" or "the consequences a= re arguably less serious CDNI". >> Second, I don't quite see the difference between the two: if an enduser = uses a global DNS, then a single CDN just cannot make any reasonable decisi= on, nor can an uCDN in CDNI. >> >> >> section 3.5, Figure 6: >> OLD: >> " >> RRI REQ >> " >> NEW: >> " >> RR-F&CAI REQ >> " >> (in line with earlier comment: for "Request Routing - Footprint and Capa= bilities Advertisement interface) >> >> >> section 3.5: >> The notion of Footprint discovery could be illustrated with either DNS o= r HTTP. The document currently illustrates it with DNS. However, it gets a = little confusing because (i) the example interaction mentioned is "Can you >> serve clients from this IP Prefix?" and (ii) the text just before sect= ion 3.5 just discussed the issue of identifying the client IP address in ca= se of HTTP redirection (which is why a note was added : "(Note that the iss= ues of determining the client's subnet from DNS requests, as described abov= e, are exactly the same here as >> in Section 3.4.) ". >> I would suggest simply using HTTP redirection (instead of DNS) in the ex= ample of section 3.5. I think it would make the concept of footprint discov= ery easier to get for the reader. >> >> >> Figure 7: >> you included step numbers (e.g "(1)") in the Figure but did not refer to= those in the description text. >> >> >> 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. >> " >> >> >> section 3.7, Figure 8: >> Figure 8 actually shows a scenario where dCDN performs DNS redirection f= or intra-CDN request routing (i.e. in step 6). This is in contradiction wit= h 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 and= 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 w= hile I don't have a problem in showing such a combination, I don't think it= should be introduced in the middle of the example illustrating preposition= ing. >> My recommendation is to tweak the current example in Figure 8 to show HT= TP redirection in dCDN (as is done in the referenced Figure 3). >> >> >> section 3.8: >> We have progressed on the topic of "metadata push" and this is now seen = 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 : "Pre-p= ositioned 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 Figure = 7). >> If you feel it is useful you could put a note that this could have been = realized via a push mechanism, but that CDNI solution has selected a trigge= red Pull solution at least initially. But I suggest the description be made= using triggered Pull. >> >> >> 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 ietf= -cdni-metadata, there is only one single bit of info that needs to be known= ahead of time which is the URI of the Metadata server, from which everythi= ng can be learnt. And this info is expected to be known via config, or lear= nt 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. >> >> >> section 3.10: >> OLD: >> " >> 3.10. Content Acquisition with Multiple Upstream CDNs >> " >> NEW: >> " >> 3.10. Content Acquisition and Metadata Acquisition with Multiple Upstre= am CDNs >> " >> >> >> 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 metada= ta >> 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 comi= ng from this uCDN and can acquire content from that uCDN. If there are mult= iple uCDNs hosting metadata for the requested content, the dCDN may be read= y 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 co= ntent, only a single uCDN will ever redirect requests to the dCDN. " >> >> >> OLD: >> " >> tightly c coupled >> " >> NEW: >> " >> tightly coupled >> " >> >> >> 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 other = relevant interfaces. >> " >> >> >> 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-cdn= i-problem-statement] and >> [I-D.ietf-cdni-requirements] for some discussion of the interfaces. >> " >> >> >> 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" interfa= ce 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. >> " >> >> section 4.2: >> OLD: >> " >> While in the the limit >> " >> NEW: >> " >> While in the limit >> " >> >> >> section 4.2: >> I recommend the text in this section: >> * be aligned to our finalized nomenclature of "CDNI Request Routing Redi= rection interface" and "CDNI Footprint & Capabilities advertisement interfa= ce". >> * be structured to separate discussion on these two interfaces >> * refers to draft-spp-cdni-rr-foot-cap-semantics ( CDNI Request Routing:= Footprint and Capabilities Semantics) when discussing the information to = advertise as footprint >> >> >> 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. >> " >> >> section 4.4: >> [I-D.lefaucheur-cdni-logging-delivery] has been incorporated into [I-D.b= ertrand-cdni-logging], so you only need to refer to the latter. >> >> section 4.6: >> [I-D.ma-cdni-metadata] and [I-D.cjlmw-cdni-metadata] are now merged into= ietf-cdni-metadata, so you only need to refer to that document. >> >> 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 cont= ent by dCDN (e.g. alternate sources for the content, authorization informat= ion needed to acquire the content from the source). >> " >> (Rationale: just aligning metadata examples to what is likely supported = by the metadata interface, to avoid confusion). >> >> >> 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 mecha= nisms. >> 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 com= e with shortcomings such as inability to prevent from replay outside the ti= me window or inability to make use of a downstream CDN that covers a broade= r footprint than the geo-blocking restrictions. >> " >> >> >> 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 themselv= es (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 ar= e shortcomings with that approach, such as difficulty in preventing replays= that bypass the access control policies) >> >> >> OLD: >> " >> to express this its desire >> " >> NEW: >> " >> to express its desire >> " >> >> section 5: >> OLD: >> " >> and that may other models >> " >> NEW: >> " >> and that many other models >> " > From flefauch@cisco.com Fri Dec 21 06:57:29 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C4E21F85E8 for ; Fri, 21 Dec 2012 06:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSGNggxuHY8D for ; Fri, 21 Dec 2012 06:57:27 -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 6801F21F8651 for ; Fri, 21 Dec 2012 06:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27353; q=dns/txt; s=iport; t=1356101847; x=1357311447; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OIlr1uUR6VqdRK6wwgiFnrXHf4mI5eu1bc7ad1ZSi3g=; b=XqY/kEQgfn5P72X4u1HAjJz4r2cmVhPUNkwxJ2gAt0Py3yM/6TjLFQ7j ws+go5PCHK7p79pu1UpxnDLin0AT5xr5rU2UPKhH3tb8FSIQ0z6LBiPb5 HUyg+UrMBPupV21hHiAiAKf/EAqUjPxoMqFywxQqjVPCWvh/bkdL1/HGl I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFt41FCtJXHA/2dsb2JhbABFvXsWc4IeAQEBAwEaDUALBwULAgEIEQMBAgEKCxkyHQgCBA4FCBOHcga2PYk3gyAWeIJUYQOXJ48sgnSBZT0 X-IronPort-AV: E=Sophos;i="4.84,329,1355097600"; d="scan'208";a="152509849" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 21 Dec 2012 14:57:26 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBLEvQ2O020750 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Dec 2012 14:57:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.128]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 08:57:26 -0600 From: "Francois Le Faucheur (flefauch)" To: "Peterson, Larry" Thread-Topic: 2nd batch of comments on cdni-framework Thread-Index: AQHN3tonyQaOyBK++E67F+Eqt1sqR5gjseWAgAAL9YA= Date: Fri, 21 Dec 2012 14:57:25 +0000 Message-ID: References: <8E46261D-5CD6-46CC-AD81-7F5CF8E7F595@verivue.com> In-Reply-To: <8E46261D-5CD6-46CC-AD81-7F5CF8E7F595@verivue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="Windows-1252" Content-ID: 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, 21 Dec 2012 14:57:29 -0000 Hi Larry, On 21 Dec 2012, at 15:14, Peterson, Larry wrote: > Francois, >=20 > You're right. I should have warned you. My reading is that the explanatio= n > in the text covers (explains) that case, which we don't need to trace exp= licitly. There seems to be a disconnect. Let me try clarify (and please let me know = if I am missing something) I am not talking about some special case. In the message flow that is shown= , I believe there is simply one single mandatory message that is missing. 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 | | |<------------------------| " 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 | |<------------------------| | |HTTP node2.op-b-acq.op-a.net | |------------------------>| | | |(10) | |Data | | |<------------------------| " 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 all = the ones are shown. In step 2, 3 and 4 above, you have the exact same sequence of HTTP redirect= , DNS , HTTP request and the HTTP request is shown. Why would you not show = in step (9). 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 that = the content is served. But the content won't be served until operator B iss= ues 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 redirec= tion 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. Same applies to Figure 4. What am I missing? Thanks >=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 alias = when I sent my 2nd batch of comments on cdni-framework last October. So her= e 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 message = in the message flows of Figure 3 and Figure 4. Is this an omission on your = 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. afte= r step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dCD= N will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" which= is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should hap= pen just before the "Data" message. >> " >> " >>> Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.ne= t" 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-01 = (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 version = 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 IETF= -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 con= sistent and explicit: >>> * section 3.2: "HTTP Redirect Example" --> "Iterative HTTP Redirection= Example" >>> * section 3.3: "Recursive Redirection Example" --> "Recursive HTTP Red= irection Example" >>> * section 3.4: "DNS-based redirection example" --> "Iterative DNS-base= d Redirection Example" >>> * section 3.5: "Dynamic Footprint Discovery" --> "Dynamic Footprint Di= scovery 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". Thi= s is not really a "trace" and I am not sure what "request" is, because the = message flows contain both "requests" and "responses", and there are messag= e 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. afte= r step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dCD= N will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" which= is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should hap= pen 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 earlie= r steps e.g. to look at metadata to decide if/how to redirect etc, so bette= r leave it open). >>>=20 >>>=20 >>> section 3.2.1: >>> OLD >>> " >>> For example, obtaining information from dCDN regarding the set of clien= t >>> 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 clien= t >>> IP addresses or geographic regions it might be able to serve is an >>> aspect of the CDNI request routing interface (specifically of the CDNI= Footprint & Capabilities advertisement interface). >>> " >>>=20 >>>=20 >>> section 3.2.1: >>> OLD >>> " >>> Hence, there is no explicit metadata interface invoked in this example. >>> " >>> NEW: >>> " >>> The example also assumes that the CSP does not require any distribution= policy (e.g. time window, geo-blocking) or delivery processing to be appli= ed by the interconnected CDNs. Hence, there is no explicit metadata interfa= ce 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 Ro= uting 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 conv= enient 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 "mu= st" is replaced by something like "we assume that". Because a lot of those = 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 brought= up multiple times wrt current framework is a need to clarify what is examp= le from what is prescription. >>>=20 >>>=20 >>> Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.ne= t" 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 Operato= r B >>> " >>> (more generally, you need to check all occurrences of "Request Routing = Interface" or "RRI" throughout the document and align to our finalized nome= nclature of "CDNI Request Routing Redirection interface" and "CDNI Footprin= t & Capabilities advertisement interface". >>> In Figure 4, "RRI REQ" needs to be changed to something like "RR-RI REQ= ") >>>=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 inform= ation is cached). >>> " >>> (Rationale: in the HTTP redirection case, the extra RTTs have to do wit= h DNS request for very stable information such as the IP address of the CDN= domains or delivery nodes. Those can be appropriately handled with long TT= Ls - certainly compared to the TTL that needs to be applied in case of DNS = 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-user >>> as it would any user not connected to a peer CDN. >>> " >>> NEW: >>> " >>> In this case, and assuming the uCDN is capable of detecting that situat= ion, 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 cons= equences are arguably less serious in existing CDNs" or "the consequences = are arguably less serious CDNI". >>> Second, I don't quite see the difference between the two: if an enduser= uses a global DNS, then a single CDN just cannot make any reasonable decis= ion, 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 Cap= abilities Advertisement interface) >>>=20 >>>=20 >>> section 3.5: >>> The notion of Footprint discovery could be illustrated with either DNS = or HTTP. The document currently illustrates it with DNS. However, it gets a= little confusing because (i) the example interaction mentioned is "Can you >>> serve clients from this IP Prefix?" and (ii) the text just before sect= ion 3.5 just discussed the issue of identifying the client IP address in ca= se of HTTP redirection (which is why a note was added : "(Note that the iss= ues of determining the client's subnet from DNS requests, as described abov= e, are exactly the same here as >>> in Section 3.4.) ". >>> I would suggest simply using HTTP redirection (instead of DNS) in the e= xample of section 3.5. I think it would make the concept of footprint disco= very easier to get for the reader. >>>=20 >>>=20 >>> Figure 7: >>> you included step numbers (e.g "(1)") in the Figure but did not refer t= o 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 redirection = for intra-CDN request routing (i.e. in step 6). This is in contradiction wi= th 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 and= 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 w= hile I don't have a problem in showing such a combination, I don't think it= should be introduced in the middle of the example illustrating preposition= ing. >>> My recommendation is to tweak the current example in Figure 8 to show H= TTP 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 seen= 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 : "Pre-= positioned CDNI Metadata acquisition: " >>> * the "MI push" in the figure be replaced with a "CI pre-position" + "C= I OK" + "MI pull" (the "CI" messages would be analogous to those of Figure= 7). >>> If you feel it is useful you could put a note that this could have been= realized via a push mechanism, but that CDNI solution has selected a trigg= ered Pull solution at least initially. But I suggest the description be mad= e 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 iet= f-cdni-metadata, there is only one single bit of info that needs to be know= n ahead of time which is the URI of the Metadata server, from which everyth= ing can be learnt. And this info is expected to be known via config, or lea= rnt via some future CDNI auto discovery protocol. This basically removes th= e 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 Upstr= eam CDNs >>> " >>>=20 >>>=20 >>> OLD: >>> " >>> Given that the dCDN has established a business relationship with each o= f 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 metad= ata >>> 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 comi= ng from this uCDN and can acquire content from that uCDN. If there are mult= iple uCDNs hosting metadata for the requested content, the dCDN may be read= y 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 co= ntent, 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 other= 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-cdn= i-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" interfa= ce 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 Red= irection interface" and "CDNI Footprint & Capabilities advertisement interf= ace". >>> * be structured to separate discussion on these two interfaces >>> * refers to draft-spp-cdni-rr-foot-cap-semantics ( CDNI Request Routing= : 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 int= o 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 cont= ent by dCDN (e.g. alternate sources for the content, authorization informat= ion needed to acquire the content from the source). >>> " >>> (Rationale: just aligning metadata examples to what is likely supported= 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 mech= anisms. >>> 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 com= e with shortcomings such as inability to prevent from replay outside the ti= me window or inability to make use of a downstream CDN that covers a broade= r 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 themselv= es (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 a= re shortcomings with that approach, such as difficulty in preventing replay= s 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 From lpeterson@verivue.com Fri Dec 21 13:40:01 2012 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8861E21F88E6 for ; Fri, 21 Dec 2012 13:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI0vkEGF5Lie for ; Fri, 21 Dec 2012 13:39:59 -0800 (PST) Received: from exprod8og119.obsmtp.com (exprod8og119.obsmtp.com [64.18.3.38]) by ietfa.amsl.com (Postfix) with SMTP id 1051521F88B0 for ; Fri, 21 Dec 2012 13:39:52 -0800 (PST) Received: from vvexch.verivue.com ([38.83.192.68]) by exprod8ob119.postini.com ([64.18.7.12]) with SMTP ID DSNKUNTXHxBaw1A4vVUJfVd6HGspTfvgKUX3@postini.com; Fri, 21 Dec 2012 13:39:59 PST Received: from vvexch.verivue.com ([10.160.6.20]) by vvexch.verivue.com ([10.160.6.20]) with mapi; Fri, 21 Dec 2012 16:39:42 -0500 From: "Peterson, Larry" To: "Francois Le Faucheur (flefauch)" Date: Fri, 21 Dec 2012 16:40:38 -0500 Thread-Topic: 2nd batch of comments on cdni-framework Thread-Index: Ac3fw6+BzV9DxOJFSOOLHyiRWxMjhA== 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: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" 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, 21 Dec 2012 21:40:01 -0000 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. Larry On Dec 21, 2012, at 9:57 AM, Francois Le Faucheur (flefauch) wrote: > Hi Larry, > > On 21 Dec 2012, at 15:14, Peterson, Larry wrote: > >> Francois, >> >> You're right. I should have warned you. My reading is that the explanati= on >> in the text covers (explains) that case, which we don't need to trace ex= plicitly. > > There seems to be a disconnect. Let me try clarify (and please let me kno= w if I am missing something) > I am not talking about some special case. In the message flow that is sho= wn, I believe there is simply one single mandatory message that is missing. > > 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 | > | |<------------------------| > " > > 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 > | |<------------------------| > > | |HTTP node2.op-b-acq.op-a.net > | |------------------------>| > > | | |(10) > | |Data | > | |<------------------------| > " > > The message flows always show every DNS message and every HTTP message, i= t does not make sense to me to omit one single HTTP request message when al= l the ones are shown. > In step 2, 3 and 4 above, you have the exact same sequence of HTTP redire= ct, DNS , HTTP request and the HTTP request is shown. Why would you not sho= w in step (9). > > BTW, the text that follows the figure also makes the same omission i.e. i= t describe the HTTP redirect, the corresponding DNS, and then just says tha= t the content is served. But the content won't be served until operator B i= ssues 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 redir= ection 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 a= nd the HTTP message flow and does not seem correct to me. > > Same applies to Figure 4. > > What am I missing? > > Thanks > > >> >> Larry >> >> On Dec 20, 2012, at 10:48 AM, Francois Le Faucheur (flefauch) wrote: >> >>> To the WG, >>> I just realized that I had inadvertently omitted to copy the cdni alias= when I sent my 2nd batch of comments on cdni-framework last October. So he= re it is below, just for the records. >>> >>> 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 message= in the message flows of Figure 3 and Figure 4. Is this an omission on your= end, or am I missing something and these messages are actually not needed? >>> >>> " >>>> section 3.2, Figure 3: >>>> I believe a HTTP request is missing in the acquisition phase (i.e. aft= er step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dC= DN will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" whic= h is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should ha= ppen just before the "Data" message. >>> " >>> " >>>> Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.n= et" request missing from the figure. >>> " >>> >>> Thanks >>> >>> Francois >>> >>> >>> >>> >>> >>> Begin forwarded message: >>> >>>> From: Francois Le Faucheur >>>> Subject: 2nd batch of comments on cdni-framework >>>> Date: 31 October 2012 18:44:51 CET >>>> To: >>>> >>>> Larry, Bruce, >>>> >>>> Below is the second batch of my detailed comments on cdni-framework-01= (as an Individual). >>>> I don't think there is anything major missing from the document. >>>> >>>> I hope these comments are useful and can be addressed in a new version= soon. >>>> >>>> Cheers >>>> >>>> Francois >>>> >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> >>>> As discussed off-line, one general change needed is to reflect the IET= F-84 decisions with respect to HAS. >>>> >>>> >>>> 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. >>>> " >>>> >>>> >>>> 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. >>>> " >>>> >>>> >>>> >>>> section 3: >>>> I suggest tweaking titles of the example sections to make them more co= nsistent and explicit: >>>> * section 3.2: "HTTP Redirect Example" --> "Iterative HTTP Redirectio= n Example" >>>> * section 3.3: "Recursive Redirection Example" --> "Recursive HTTP Re= direction Example" >>>> * section 3.4: "DNS-based redirection example" --> "Iterative DNS-bas= ed Redirection Example" >>>> * section 3.5: "Dynamic Footprint Discovery" --> "Dynamic Footprint D= iscovery example" >>>> * section 3.6: "Content Removal" --> "Content Removal Example" >>>> >>>> >>>> section 3: >>>> All figures are titled as "Request Trace for =85" >>>> I'd suggest titling them with something like "Message Flow for=85". Th= is is not really a "trace" and I am not sure what "request" is, because the= message flows contain both "requests" and "responses", and there are messa= ge flows that don't relate to any "content request". >>>> >>>> >>>> section 3.2, Figure 3: >>>> I believe a HTTP request is missing in the acquisition phase (i.e. aft= er step 8). After the uCDN issues the "302 node2.op-b.acq.op-A.net", the dC= DN will follow the redirect and issue a "HTTP node2.op-b.acq.op-A.net" whic= h is missing from the figure. This "HTTP node2.op-b.acq.op-A.net" should ha= ppen just before the "Data" message. >>>> >>>> >>>> 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 earli= er steps e.g. to look at metadata to decide if/how to redirect etc, so bett= er leave it open). >>>> >>>> >>>> section 3.2.1: >>>> OLD >>>> " >>>> For example, obtaining information from dCDN regarding the set of clie= nt >>>> 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 clie= nt >>>> IP addresses or geographic regions it might be able to serve is an >>>> aspect of the CDNI request routing interface (specifically of the CDNI= Footprint & Capabilities advertisement interface). >>>> " >>>> >>>> >>>> section 3.2.1: >>>> OLD >>>> " >>>> Hence, there is no explicit metadata interface invoked in this example= . >>>> " >>>> NEW: >>>> " >>>> The example also assumes that the CSP does not require any distributio= n policy (e.g. time window, geo-blocking) or delivery processing to be appl= ied by the interconnected CDNs. Hence, there is no explicit metadata interf= ace invoked in this example. >>>> " >>>> >>>> >>>> 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 Ro= uting Redirection interface) to enable "recursive" CDNI request routing. >>>> " >>>> >>>> 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 con= venient to do it that way, it is not an absolute requirement.) >>>> >>>> >>>> section 3.3: >>>> " >>>> DNS must be configured in the following way: >>>> " >>>> Again, I suggest the text is tweaked in multiple places so that the "m= ust" is replaced by something like "we assume that". Because a lot of those= 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 brough= t up multiple times wrt current framework is a need to clarify what is exam= ple from what is prescription. >>>> >>>> >>>> Figure 4: same comment as for Figure 3 wrt "HTTP node2.op-b.acq.op-A.n= et" request missing from the figure. >>>> >>>> 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 Operat= or B >>>> " >>>> (more generally, you need to check all occurrences of "Request Routing= Interface" or "RRI" throughout the document and align to our finalized nom= enclature of "CDNI Request Routing Redirection interface" and "CDNI Footpri= nt & Capabilities advertisement interface". >>>> In Figure 4, "RRI REQ" needs to be changed to something like "RR-RI RE= Q") >>>> >>>> >>>> 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 inform= ation is cached). >>>> " >>>> (Rationale: in the HTTP redirection case, the extra RTTs have to do wi= th DNS request for very stable information such as the IP address of the CD= N domains or delivery nodes. Those can be appropriately handled with long T= TLs - certainly compared to the TTL that needs to be applied in case of DNS= redirection. So in practice, for many requests the nb of real RTTs would b= e similar. In fact, I'd suggest you bring up this point). >>>> >>>> >>>> OLD: >>>> " >>>> In this case, one option is for the upstream CDN to treat the end-user >>>> as it would any user not connected to a peer CDN. >>>> " >>>> NEW: >>>> " >>>> In this case, and assuming the uCDN is capable of detecting that situa= tion, one option is for the upstream CDN to treat the end-user >>>> as it would any user not connected to a peer CDN. >>>> " >>>> >>>> >>>> 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 con= sequences are arguably less serious in existing CDNs" or "the consequences= are arguably less serious CDNI". >>>> Second, I don't quite see the difference between the two: if an enduse= r uses a global DNS, then a single CDN just cannot make any reasonable deci= sion, nor can an uCDN in CDNI. >>>> >>>> >>>> section 3.5, Figure 6: >>>> OLD: >>>> " >>>> RRI REQ >>>> " >>>> NEW: >>>> " >>>> RR-F&CAI REQ >>>> " >>>> (in line with earlier comment: for "Request Routing - Footprint and Ca= pabilities Advertisement interface) >>>> >>>> >>>> section 3.5: >>>> The notion of Footprint discovery could be illustrated with either DNS= or HTTP. The document currently illustrates it with DNS. However, it gets = a little confusing because (i) the example interaction mentioned is "Can yo= u >>>> serve clients from this IP Prefix?" and (ii) the text just before sect= ion 3.5 just discussed the issue of identifying the client IP address in ca= se of HTTP redirection (which is why a note was added : "(Note that the iss= ues of determining the client's subnet from DNS requests, as described abov= e, 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 disc= overy easier to get for the reader. >>>> >>>> >>>> Figure 7: >>>> you included step numbers (e.g "(1)") in the Figure but did not refer = to those in the description text. >>>> >>>> >>>> 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. >>>> " >>>> >>>> >>>> section 3.7, Figure 8: >>>> Figure 8 actually shows a scenario where dCDN performs DNS redirection= for intra-CDN request routing (i.e. in step 6). This is in contradiction w= ith 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 and= 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 w= hile I don't have a problem in showing such a combination, I don't think it= should be introduced in the middle of the example illustrating preposition= ing. >>>> 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). >>>> >>>> >>>> section 3.8: >>>> We have progressed on the topic of "metadata push" and this is now see= n 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 : "Pre= -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 Figur= e 7). >>>> If you feel it is useful you could put a note that this could have bee= n realized via a push mechanism, but that CDNI solution has selected a trig= gered Pull solution at least initially. But I suggest the description be ma= de using triggered Pull. >>>> >>>> >>>> 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 ie= tf-cdni-metadata, there is only one single bit of info that needs to be kno= wn ahead of time which is the URI of the Metadata server, from which everyt= hing can be learnt. And this info is expected to be known via config, or le= arnt via some future CDNI auto discovery protocol. This basically removes t= he 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. >>>> >>>> >>>> section 3.10: >>>> OLD: >>>> " >>>> 3.10. Content Acquisition with Multiple Upstream CDNs >>>> " >>>> NEW: >>>> " >>>> 3.10. Content Acquisition and Metadata Acquisition with Multiple Upst= ream CDNs >>>> " >>>> >>>> >>>> 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 meta= data >>>> 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 comi= ng from this uCDN and can acquire content from that uCDN. If there are mult= iple uCDNs hosting metadata for the requested content, the dCDN may be read= y 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 co= ntent, only a single uCDN will ever redirect requests to the dCDN. " >>>> >>>> >>>> OLD: >>>> " >>>> tightly c coupled >>>> " >>>> NEW: >>>> " >>>> tightly coupled >>>> " >>>> >>>> >>>> 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 othe= r relevant interfaces. >>>> " >>>> >>>> >>>> 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-cdn= i-problem-statement] and >>>> [I-D.ietf-cdni-requirements] for some discussion of the interfaces. >>>> " >>>> >>>> >>>> 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" interfa= ce 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. >>>> " >>>> >>>> section 4.2: >>>> OLD: >>>> " >>>> While in the the limit >>>> " >>>> NEW: >>>> " >>>> While in the limit >>>> " >>>> >>>> >>>> section 4.2: >>>> I recommend the text in this section: >>>> * be aligned to our finalized nomenclature of "CDNI Request Routing Re= direction interface" and "CDNI Footprint & Capabilities advertisement inter= face". >>>> * be structured to separate discussion on these two interfaces >>>> * refers to draft-spp-cdni-rr-foot-cap-semantics ( CDNI Request Routin= g: Footprint and Capabilities Semantics) when discussing the information t= o advertise as footprint >>>> >>>> >>>> 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. >>>> " >>>> >>>> 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. >>>> >>>> section 4.6: >>>> [I-D.ma-cdni-metadata] and [I-D.cjlmw-cdni-metadata] are now merged in= to ietf-cdni-metadata, so you only need to refer to that document. >>>> >>>> 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 cont= ent by dCDN (e.g. alternate sources for the content, authorization informat= ion needed to acquire the content from the source). >>>> " >>>> (Rationale: just aligning metadata examples to what is likely supporte= d by the metadata interface, to avoid confusion). >>>> >>>> >>>> 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 mec= hanisms. >>>> 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 com= e with shortcomings such as inability to prevent from replay outside the ti= me window or inability to make use of a downstream CDN that covers a broade= r footprint than the geo-blocking restrictions. >>>> " >>>> >>>> >>>> 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 themselv= es (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 repla= ys that bypass the access control policies) >>>> >>>> >>>> OLD: >>>> " >>>> to express this its desire >>>> " >>>> NEW: >>>> " >>>> to express its desire >>>> " >>>> >>>> section 5: >>>> OLD: >>>> " >>>> and that may other models >>>> " >>>> NEW: >>>> " >>>> and that many other models >>>> " >>> >> >