From Jan.Seedorf@neclab.eu Tue Oct 2 01:49: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 9A69D21F8B09; Tue, 2 Oct 2012 01:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7U6VyYgZ4Dw; Tue, 2 Oct 2012 01:49:00 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 80F8D21F8B08; Tue, 2 Oct 2012 01:49:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DED11101395; Tue, 2 Oct 2012 10:48:59 +0200 (CEST) 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 ny7hp5OVYEow; Tue, 2 Oct 2012 10:48:59 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id BF66F10135C; Tue, 2 Oct 2012 10:48:49 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.21]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 2 Oct 2012 10:48:35 +0200 From: Jan Seedorf To: Jan Seedorf , "cdni-footprint@ietf.org" Thread-Topic: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Design Team Call" Thread-Index: Ac2ddnTPiTJ29apcQ0OfVr1sQPYGZgDA4haA Date: Tue, 2 Oct 2012 08:48:34 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55355F4F@PALLENE.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE553513E5@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE553513E5@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for "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: Tue, 02 Oct 2012 08:49:01 -0000 Based on the doodle, I suggest having design team phone calls on the follow= ing dates (let's schedule two calls for now and then see where to go from t= here...): ** 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 Design T= eam > Call" >=20 > Hi all, >=20 > I created a doodle for a CDNI Footprint/Capabilties Design Team Call: >=20 > http://www.doodle.com/3u7pkrfctqa6u33g >=20 > 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 inter= ested > in joining the discussion. >=20 > - Jan > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint From sprevidi@cisco.com Tue Oct 2 03:38:19 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 362E721F8B0B for ; Tue, 2 Oct 2012 03:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, 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 ihQNRWs4NxhR for ; Tue, 2 Oct 2012 03:38:18 -0700 (PDT) Received: from av-tac-bru.cisco.com (spooky-brew.cisco.com [144.254.15.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6B121F8B06 for ; Tue, 2 Oct 2012 03:38:17 -0700 (PDT) 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 q92AcFUu028663 for ; Tue, 2 Oct 2012 12:38:16 +0200 (CEST) Received: from dhcp-rom2-bb-gw-vla250-10-147-74-11.cisco.com (dhcp-rom2-bb-gw-vla250-10-147-74-11.cisco.com [10.147.74.11]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q92AcF8L021340; Tue, 2 Oct 2012 12:38:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: stefano previdi In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE55355F4F@PALLENE.office.hd> Date: Tue, 2 Oct 2012 12:38:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18AD77C1-B4A2-4156-B4A0-86D21B0837D0@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE553513E5@PALLENE.office.hd> <2779C9F0771F974CAD742BAE6D9904FE55355F4F@PALLENE.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1283) Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for "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: Tue, 02 Oct 2012 10:38:19 -0000 Jan,=20 I did setup the two webex bridges.=20 As mentioned in the poll, I will not be able to join the first meeting=20= (I'll be on track) but will be there for the second.=20 Thanks. s. On Oct 2, 2012, at 10:48 AM, Jan Seedorf wrote: > 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...): >=20 > ** Tuesday, Oct. 9th, 16:00-18:00 CET ** > ** Tuesday, Oct. 16th, 16:00-18:00 CET ** >=20 > On these dates most people seem to be able to join. Can someone please = set up a WebEx meeting for those dates and times? >=20 > - Jan >=20 >=20 >=20 >> -----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 = Design Team >> Call" >>=20 >> Hi all, >>=20 >> I created a doodle for a CDNI Footprint/Capabilties Design Team Call: >>=20 >> http://www.doodle.com/3u7pkrfctqa6u33g >>=20 >> 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 = interested >> in joining the discussion. >>=20 >> - Jan >> _______________________________________________ >> 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 >=20 From Jan.Seedorf@neclab.eu Tue Oct 2 04:54:02 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 0A04321F8919; Tue, 2 Oct 2012 04:54:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ccX1iLJN68y7; Tue, 2 Oct 2012 04:54:01 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 15BE821F88B6; Tue, 2 Oct 2012 04:54:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 66237101FEE; Tue, 2 Oct 2012 13:54:00 +0200 (CEST) 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 tHij5SvNmf7z; Tue, 2 Oct 2012 13:54:00 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 4D54B101FED; Tue, 2 Oct 2012 13:53:45 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.21]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 2 Oct 2012 13:53:31 +0200 From: Jan Seedorf To: stefano previdi Thread-Topic: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Design Team Call" Thread-Index: Ac2ddnTPiTJ29apcQ0OfVr1sQPYGZgDA4haA///+jgD//8mPIA== Date: Tue, 2 Oct 2012 11:53:31 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553573E7@PALLENE.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE553513E5@PALLENE.office.hd> <2779C9F0771F974CAD742BAE6D9904FE55355F4F@PALLENE.office.hd> <18AD77C1-B4A2-4156-B4A0-86D21B0837D0@cisco.com> In-Reply-To: <18AD77C1-B4A2-4156-B4A0-86D21B0837D0@cisco.com> 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-footprint@ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for "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: Tue, 02 Oct 2012 11:54:02 -0000 Thanks a lot, Stefano, and yes, I saw that you can only attend the second m= eeting Jan > -----Original Message----- > From: stefano previdi [mailto:sprevidi@cisco.com] > Sent: Tuesday, October 02, 2012 12:38 PM > To: Jan Seedorf > Cc: cdni-footprint@ietf.org; cdni@ietf.org > Subject: Re: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Desi= gn > Team Call" >=20 > Jan, >=20 > I did setup the two webex bridges. >=20 > As mentioned in the poll, I will not be able to join the first meeting > (I'll be on track) but will be there for the second. >=20 > Thanks. >=20 > s. >=20 >=20 >=20 > On Oct 2, 2012, at 10:48 AM, Jan Seedorf wrote: >=20 > > 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 g= o > 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 > interested > >> in joining the discussion. > >> > >> - Jan > >> _______________________________________________ > >> cdni-footprint mailing list > >> cdni-footprint@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni-footprint > > _______________________________________________ > > cdni-footprint mailing list > > cdni-footprint@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni-footprint > > From internet-drafts@ietf.org Tue Oct 2 10:34: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 9E7C821F8570; Tue, 2 Oct 2012 10:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 j+tTF3-RJRaC; Tue, 2 Oct 2012 10:34:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C28721F851E; Tue, 2 Oct 2012 10:34:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121002173431.31982.75133.idtracker@ietfa.amsl.com> Date: Tue, 02 Oct 2012 10:34:31 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:34:31 -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 : CDN Interconnect Metadata Author(s) : Ben Niven-Jenkins Rob Murray Grant Watson Matt Caulfield Kent Leung Kevin J. Ma Filename : draft-ietf-cdni-metadata-00.txt Pages : 35 Date : 2012-10-02 Abstract: The CDNI Metadata Interface enables interconnected CDNs to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both the core set of CDNI metadata and the protocol for exchanging that metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-metadata-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcaulfie@cisco.com Tue Oct 2 10:40:54 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 79B5E21F8533 for ; Tue, 2 Oct 2012 10:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 UsAa2DpC88ZF for ; Tue, 2 Oct 2012 10:40:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id A0EBF21F846A for ; Tue, 2 Oct 2012 10:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2354; q=dns/txt; s=iport; t=1349199653; x=1350409253; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=bYHBRHWhEFepFh3+yE/m9PAs+YBRDo3znNVu6KpQ6Zg=; b=JtlsOfTjyEnWWKj9ekky1/H4/2IXWKKnmp3DHohasTnGF8f9klholzLZ erwffRR44F1cBLyGvPaZOOySJ2POx6tMbcyhPKK5Bq9i+ahD1sY4aPXII ewPckHELXPioezixBTEPxJ5DSUAOa0xPdGJA///ZM5jLkKUCgF/DrYGUb 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAFoma1CtJXHA/2dsb2JhbABFhgu3TYECgQiCIAEBAQQSARARQw4EAgEIEQQBAQMCBh0DAgICMBQBBgEBBQMCBBMIARmHYwuZBI0bgjuQW4EhigKFKDJgA5I4hEaNLYFpgmeCFw X-IronPort-AV: E=Sophos;i="4.80,524,1344211200"; d="scan'208";a="124557086" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 02 Oct 2012 17:40:53 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q92Heqp7009092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 2 Oct 2012 17:40:53 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.244]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.001; Tue, 2 Oct 2012 12:40:52 -0500 From: "Matt Caulfield (mcaulfie)" To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-ietf-cdni-metadata-00.txt Thread-Index: AQHNoMQvj8JXDxzz3UK9964XIcYRtJemR4xw Date: Tue, 2 Oct 2012 17:40:51 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C920F3D5FC5@xmb-aln-x03.cisco.com> References: <20121002173431.31982.57229.idtracker@ietfa.amsl.com> In-Reply-To: <20121002173431.31982.57229.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.173.115] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19230.001 x-tm-as-result: No--24.836200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-ietf-cdni-metadata-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Oct 2012 17:40:54 -0000 SGkgZXZlcnlvbmUsDQoNCldlIGhhdmUgcG9zdGVkIHRoZSBmaXJzdCByZXZpc2lvbiBvZiB0aGUg TWV0YWRhdGEgSW50ZXJmYWNlIERyYWZ0IHdoaWNoIHdhcyBhY2NlcHRlZCBhcyBhIFdHIGRvYyBp biBWYW5jb3V2ZXI6IGRyYWZ0LWlldGYtY2RuaS1tZXRhZGF0YS4NCg0KWW91ciBjb21tZW50cyBh bmQgZmVlZGJhY2sgYXJlIGFwcHJlY2lhdGVkLg0KDQpSZWdhcmRzLA0KTWF0dCBDYXVsZmllbGQN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBUdWVzZGF5LCBP Y3RvYmVyIDAyLCAyMDEyIDE6MzUgUE0NClRvOiBNYXR0IENhdWxmaWVsZCAobWNhdWxmaWUpDQpD YzogYmVuQHZlbG9jaXguY29tOyBLZW50IExldW5nIChrbGV1bmcpOyBrZXZpbi5tYUBhenVraXN5 c3RlbXMuY29tOyBybXVycmF5QHZlbG9jaXguY29tOyBnd2F0c29uQHZlbG9jaXguY29tDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtY2RuaS1tZXRhZGF0 YS0wMC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWV0Zi1jZG5pLW1ldGFk YXRhLTAwLnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IE1hdHQgQ2F1bGZp ZWxkIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFm dC1pZXRmLWNkbmktbWV0YWRhdGENClJldmlzaW9uOgkgMDANClRpdGxlOgkJIENETiBJbnRlcmNv bm5lY3QgTWV0YWRhdGENCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTEwLTAyDQpXRyBJRDoJCSBjZG5p DQpOdW1iZXIgb2YgcGFnZXM6IDM1DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2RuaS1tZXRhZGF0YS0wMC50eHQNClN0YXR1 czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWNk bmktbWV0YWRhdGENCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1jZG5pLW1ldGFkYXRhLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGUgQ0ROSSBN ZXRhZGF0YSBJbnRlcmZhY2UgZW5hYmxlcyBpbnRlcmNvbm5lY3RlZCBDRE5zIHRvIGV4Y2hhbmdl DQogICBjb250ZW50IGRpc3RyaWJ1dGlvbiBtZXRhZGF0YSBpbiBvcmRlciB0byBlbmFibGUgY29u dGVudCBhY3F1aXNpdGlvbg0KICAgYW5kIGRlbGl2ZXJ5LiAgVGhlIENETkkgbWV0YWRhdGEgYXNz b2NpYXRlZCB3aXRoIGEgcGllY2Ugb2YgY29udGVudA0KICAgcHJvdmlkZXMgYSBkb3duc3RyZWFt IENETiB3aXRoIHN1ZmZpY2llbnQgaW5mb3JtYXRpb24gZm9yIHRoZQ0KICAgZG93bnN0cmVhbSBD RE4gdG8gc2VydmljZSBjb250ZW50IHJlcXVlc3RzIG9uIGJlaGFsZiBvZiBhbiB1cHN0cmVhbQ0K ICAgQ0ROLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYm90aCB0aGUgY29yZSBzZXQgb2YgQ0RO SSBtZXRhZGF0YSBhbmQNCiAgIHRoZSBwcm90b2NvbCBmb3IgZXhjaGFuZ2luZyB0aGF0IG1ldGFk YXRhLg0KDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRh cmlhdA0KDQo= From yannick.lelouedec@orange.com Sun Oct 7 00:45:05 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 A548221F8495; Sun, 7 Oct 2012 00:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 KzN03O8cJhyM; Sun, 7 Oct 2012 00:45:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1E08C21F8498; Sun, 7 Oct 2012 00:45:03 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 6BE3522C3DB; Sun, 7 Oct 2012 09:45:02 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 50BE935C045; Sun, 7 Oct 2012 09:45:02 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Sun, 7 Oct 2012 09:45:01 +0200 From: To: Jan Seedorf Thread-Topic: [cdni-footprint] Doodle for "CDNI Footprint/Capabilties Design Team Call" Thread-Index: AQHNoIoMydkmFdcQ5EmecDT0R71C9Zete/rg Date: Sun, 7 Oct 2012 07:45:01 +0000 Message-ID: <4460_1349595902_507132FE_4460_15406_1_457F4B94DBADF743B61D350B3E7929FE0334CE@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <2779C9F0771F974CAD742BAE6D9904FE553513E5@PALLENE.office.hd> <2779C9F0771F974CAD742BAE6D9904FE55355F4F@PALLENE.office.hd> <18AD77C1-B4A2-4156-B4A0-86D21B0837D0@cisco.com> In-Reply-To: <18AD77C1-B4A2-4156-B4A0-86D21B0837D0@cisco.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.6] 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.10.7.51517 Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Doodle for "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: Sun, 07 Oct 2012 07:45:05 -0000 Dear Jan, I will not be able to join the first meeting, and I will be available durin= g the first 20 minutes of the second meeting only (I travel a lot these day= s). Anyway this could be enough to propose several inputs we discussed with Fr= an=E7ois. And some of my colleagues should be able to join too. Thanks. Yannick Le Louedec. On Oct 2, 2012, at 10:48 AM, Jan Seedorf wrote: > Based on the doodle, I suggest having design team phone calls on the foll= owing dates (let's schedule two calls for now and then see where to go from= there...): >=20 > ** Tuesday, Oct. 9th, 16:00-18:00 CET ** > ** Tuesday, Oct. 16th, 16:00-18:00 CET ** >=20 > On these dates most people seem to be able to join. Can someone please se= t up a WebEx meeting for those dates and times? >=20 > - Jan >=20 >=20 >=20 >> -----Original Message----- >> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-=20 >> 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=20 >> Design Team Call" >>=20 >> Hi all, >>=20 >> I created a doodle for a CDNI Footprint/Capabilties Design Team Call: >>=20 >> http://www.doodle.com/3u7pkrfctqa6u33g >>=20 >> I would be good if we could make two calls in October to make=20 >> progress before the Atlanta meeting, so please fill in the doodle if=20 >> you are interested in joining the discussion. >>=20 >> - Jan >> _______________________________________________ >> 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 >=20 _______________________________________________ cdni-footprint mailing list cdni-footprint@ietf.org https://www.ietf.org/mailman/listinfo/cdni-footprint ___________________________________________________________________________= ______________________________________________ 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 Tue Oct 9 06:49: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 93D2921F87B5; Tue, 9 Oct 2012 06:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.858 X-Spam-Level: X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[AWL=0.742, 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 v0by6OFqRz7j; Tue, 9 Oct 2012 06:49:35 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id AE9E821F8760; Tue, 9 Oct 2012 06:49:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C1C27102083; Tue, 9 Oct 2012 15:49:22 +0200 (CEST) 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 voyEAKIeI+yk; Tue, 9 Oct 2012 15:49:22 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id A98391005FB; Tue, 9 Oct 2012 15:49:12 +0200 (CEST) Received: from PALLENE.office.hd ([169.254.1.21]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 9 Oct 2012 15:48:51 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Rough Agenda for today's "CDNI Footprint/Capabilties Design Team Call" Thread-Index: Ac2mJIfq7ZEW2hjkTwW6tm3p55jyLQ== Date: Tue, 9 Oct 2012 13:48:50 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5535EC00@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] 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: Tue, 09 Oct 2012 13:49:36 -0000 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 Desi= gn > Team Call" >=20 > 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 g= o > from there...): >=20 > ** Tuesday, Oct. 9th, 16:00-18:00 CET ** > ** Tuesday, Oct. 16th, 16:00-18:00 CET ** >=20 > On these dates most people seem to be able to join. Can someone please > set up a WebEx meeting for those dates and times? >=20 > - Jan >=20 >=20 >=20 > > -----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 Design > 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 int= erested > > in joining the discussion. > > > > - Jan > > _______________________________________________ > > cdni-footprint mailing list > > cdni-footprint@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni-footprint From vinayakh@gmail.com Tue Oct 9 07:08:23 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 B17D421F8702; Tue, 9 Oct 2012 07:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 UkVGSp94qQrM; Tue, 9 Oct 2012 07:08:22 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4A88421F85A8; Tue, 9 Oct 2012 07:08:22 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so3797712eek.31 for ; Tue, 09 Oct 2012 07:08:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yVeDxTAz4VW4tNLtbQalaAHiiNzBzxvefLe/zC8dPr8=; b=J7IujCTLzLmf3Eo8AhhdasOEqMrZVHiJXQSe7SykuRaN+0zwIfUpRuoXPIDUom3HEo ifK73qmr6BKQungiAeskKsAOp4RSpJUaB1PnPp+OuU8quc7QWLmFL6hsSHC51GVmP4qX FgqivQ4jvbyAiJ6mS6MZe3W3WdG09ahU3GO+2iPTyRXNualfNhoodHB/wMPzsB3zYtyl LWxoZJ4aXXZy/R+E9NT/clYTY4Om35ehDPq/BlW8lCgPOEoIuQkeleQrg3Mm+GT4enEC T/YWClj38Ax05ILnGVxXHG97C7inPKBhL5Iln2Oaj+qaf1JC5aOHx657qNvT8BQG3Er3 mgiw== MIME-Version: 1.0 Received: by 10.14.213.201 with SMTP id a49mr27724467eep.4.1349791700673; Tue, 09 Oct 2012 07:08:20 -0700 (PDT) Received: by 10.14.198.135 with HTTP; Tue, 9 Oct 2012 07:08:20 -0700 (PDT) In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE5535EC00@PALLENE.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE5535EC00@PALLENE.office.hd> Date: Tue, 9 Oct 2012 19:38:20 +0530 Message-ID: From: Vinayak Hegde To: Jan Seedorf Content-Type: text/plain; charset=ISO-8859-1 Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] 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: Tue, 09 Oct 2012 14:08:23 -0000 On Tue, Oct 9, 2012 at 7:18 PM, 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 > Hi Jan, Can you resend the webex link to the list ? I am unable to find it. Regards Vinayak From swainner@cisco.com Wed Oct 10 02:52:55 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 D702121F8758; Wed, 10 Oct 2012 02:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUZy00U2wSOr; Wed, 10 Oct 2012 02:52:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id D3C8C21F85A2; Wed, 10 Oct 2012 02:52:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6452; q=dns/txt; s=iport; t=1349862775; x=1351072375; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=e3VcqeyUP/4+oUAWzRcIon4MJZlLXLPIueX7YK+maN8=; b=gM6vBi6M7Agjczktfz372xVkSEByGLE8/8icU8GBhrQgQJ3YlxcDYXDn PyfYxK4Ukr5pL7qgH47o3jCBLcBITcc/2bRZxWSCruLNa9wwVTLncB3X5 DtpSl6z2wHlOsOU6zZ1/pJHWzxU4J0AVVfhHvTOM9EARWaN9wf4RL2MH3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKxEdVCtJV2Y/2dsb2JhbABEvyuBCIIgAQEBBAEBAQ8BJTYKAQwEHAQBAQEJFggHCQMCAQIBFR8JCAYBDAEFAgEBHodjC5cToByLRoYgA5VrjkWBa4MJ X-IronPort-AV: E=Sophos;i="4.80,564,1344211200"; d="scan'208";a="130085821" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 10 Oct 2012 09:52:54 +0000 Received: from rtp-swainner-89111.cisco.com (rtp-swainner-89111.cisco.com [10.116.109.204]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9A9qrWF027345; Wed, 10 Oct 2012 09:52:53 GMT Message-ID: <50754575.1060908@cisco.com> Date: Wed, 10 Oct 2012 05:52:53 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Jan Seedorf , cdni-footprint@ietf.org References: <2779C9F0771F974CAD742BAE6D9904FE5535EC00@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE5535EC00@PALLENE.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cdni@ietf.org Subject: [CDNi] Thoughts on the 'CDNI 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: Wed, 10 Oct 2012 09:52:56 -0000 Jan & Team, (resent with edits and CC to cdni) I propose two base use cases that may be foundational building blocks for more sophisticated use cases: Definition: - regional coverage: The CDN has cache nodes that service a well-defined geographic or topologically bounded network - global coverage: The CDN has cache nodes that service any geographic region and is topologically unbounded 1) uCDN with regional coverage delegates to one or more dCDN for global coverage 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 well-defined region or IP topology CRITERIA: uCDN ascertains if the requested content can be delivered by dCDN(s) (short list created) CRITERIA: uCDN determines which dCDN is appropriate (chosen by priority) In this use case, I think its quite simple for the uCDN to know the BGP AS or geography covered because the uCDN is under the same administrative authority as the IP network to which it is attached. The well-defined region is much more easily bounded. The global dCDN becomes a CDN of last-resort. Let's assume for the moment that the global dCDN does NOT provide transitive delegation to other dCDN. The uCDN decision is simple: IF (client is in my network AND my region) THEN (service client from my uCDN) ELSE (consider serving client from global dCDN) Now you can start adding optional conditions to either service the client from either choice such as Time-of-Day, Priority, Cost, etc. 2) uCDN with global coverage delegates to one or more dCDN for regional coverage Motivations for uCDN to delegate to dCDN might include the following: - DECISION: uCDN client is inside a dCDN's well-defined region or IP topology IMPACT: uCDN client is better served by regional dCDN CRITERIA: uCDN ascertains if the client is inside a well-defined region or IP topology CRITERIA: uCDN ascertains which dCDN's associated with the region can deliver the requested content (short list) CRITERIA: uCDN determines which dCDN is appropriate (chosen by priority) In this case, the uCDN needs to know the candidate regions and have the ability to associate a client to the candidate region. That means each dCDN needs to advertise its candidate region to the global uCDN. The regional dCDN become may be preferred provided the dCDN is available and capable of delivering the content. We have a fairly simple decision process: IF (client is in region X) AND (ISP 1 services region X) AND (client is attached to ISP 1's AS) THEN (service the client from dCDN of ISP 1) ELSE (consider serving client from global uCDN) Now you can start adding optional conditions to either service the client from either choice such as Time-of-Day, Priority, Cost, etc. N) The intermediate CDN delegates to one or more regional dCDN for regional coverage. The intermediate CDN is also a delegate of a regional uCDN. I don't see that the motivations change from the two cases previously defined. The uCDN delegates to the intermediate CDN to get better coverage and the intermediate CDN delegates to the regional dCDN's to get better performance. What is different is the transitive nature of the coverage where a regional dCDN advertises its regional footprint (region and associated AS) to the intermediate CDN. The intermediate CDN now aggregates all its delegates (regions and associated AS's) and advertises that to the uCDN. For a well connected intermediate CDN, that could be a lot of information to flood to the regional uCDN. If the intermediate CDN doesn't have robust coverage, then perhaps it is really a regional CDN which means the information in the footprint advertisement is sparse. The decision is simply to indicate which regions associated with which AS are transitive in nature. Summary I see three mandatory requirements: 1) COVERAGE: - AS to which the dCDN is attached AND - regions to which that dCDN services 2) CAPABILITY: - content delivery method - authentication method 3) AVAILABILITY: - active / operational for servicing requests 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 Design >> 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 Design >> 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 interested >>> 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 > . > From Jan.Seedorf@neclab.eu Wed Oct 10 05:57:38 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 858AD21F86C5; Wed, 10 Oct 2012 05:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.981 X-Spam-Level: X-Spam-Status: No, score=-102.981 tagged_above=-999 required=5 tests=[AWL=0.618, 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 plR1vmrMX7Gm; Wed, 10 Oct 2012 05:57:37 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 504B621F8686; Wed, 10 Oct 2012 05:57:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4F6C7102108; Wed, 10 Oct 2012 14:57:36 +0200 (CEST) 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 1w5Zrqefrqwv; Wed, 10 Oct 2012 14:57:36 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 2F9AF1020FE; Wed, 10 Oct 2012 14:57:26 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 10 Oct 2012 14:57:25 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Notes and summary of yesterday's footprint/capabilities design team call Thread-Index: Ac2m5MYJYITJQEdTRQqdozkV/5/nIA== Date: Wed, 10 Oct 2012 12:56:38 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553651B7@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] Notes and summary of yesterday's 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: Wed, 10 Oct 2012 12:57:38 -0000 Hi all, Below are detailed notes from yesterday's footprint/capabilities design tea= m call. Many thanks to Enrico for taking the notes. Let me briefly summariz= e the discussion and the next steps: -- first we recapped the things we had agreed on (or at least largely agree= d on) in Vancouver and the open issues. -- Regarding footprint, agreement has been found on some issues (see the sl= ides I presented at the CDNI session at IETF-84 for a summary), but there a= re still some open issues: a) what exactly is a footprint and how can it be= derived in practice? What information needs to be "tagged along" with a fo= otprint to prevent the "I can cover the whole world" problem, and is this a= dditional information being agreed in contracts (out of scope if our work) = or within the CDNI RR interface? -- Regarding capabilities, we continued the discussion we had at a side mee= ting in Vancouver. There is agreement that capabilities are mostly going to= be agreed in contracts, but the CDNI protocol can be used to "update" a uC= DN when things have changed. Since things can change only for a part of a f= ootprint, capabilities and footprint are likely to be tied together in some= cases. We do not know much how actual CDNI contracts will look like at thi= s point in time, so the challenge is to agree on a small set of capabilitie= s that we think will be mandatory in any case. In order to make progress wi= th this challenge, we agreed to focus on some key use cases. These use case= s should however not be simple / straightforward ones, but rather some inte= resting/challenging ones. -- Several such use cases were raised in the call by various participants a= nd discussed. We agreed to circulate these use cases on this list to discus= s them and particular find out where they overlap or are actually subcases = of each other. The plan is to have this discussion on the list (with everyb= ody who has an interesting use case sending it on the list), so that we hop= efully carve out 2-3 key use cases by the next call. Thanks to all for participating and an interesting discussion. If you thing= the above is missing a key point or misleading, please comment in this lis= t. Next call is next Tuesday, 16:00-18:00. I will circulate the WebEx details = again. - Jan ************************************ Meeting starts at 16:10 CEST. Jan recaps. Agreed: footprint is willingness to serve. But it's not enough. Need to find something more. Agreed: much will be decided in contractual agreements. Agreed: dcdn updates ucdn when something changed. Agreed: monetary costs are out of scope. Open question: what exactly is footprint? Open question: what's the missing part other than what's defined in contractual agreements? Open question: what capabilities are useful? Agreed: capabilities will be negotiated in the contract, the protocol will provide updates according to them. Open question: tie-breaking information. Quite agreed that will have to do with economics. Jon: Capabilities and footprint are tied together. [Interruption] We need to figure out the distinction between capabilities and footprint over the wire. Jan: Need to understand what information will be useful. Jon: We can't figure out what contracts will look like. Suggest to define something simple and extensible. Jan: What do others think? [No one comments] Jon: Lot of key people missing. Jan: Progress would be to identify mandatory capabilities. Jon: Willing to trade interoperability with flexibility at this time. Jan: Agreed. If there would be an easily agreeable mandatory set of feature= s at this point we would have identified that. Jon: Should we go through the use-cases exercise? Jan: If we go there, let's skip the basic ones. Jon: If we consider only the on-net use case, that would be easy. Jan: More advanced use-cases raise questions that we cannot answer. Jon: How the dcdn expresses it's ability to cover a particular area is the important issue here. Scott: The protocol should help answer the question: "are you a candidate for serving that request?" Jan: It was raised that tie-breaking info can be in the contract, maybe there's no need to have that in the protocol. Scott: Two things are needed: the set of candidates and info for choosing among them. Jon: The more realtime the information is, the less useful it is to advertise it. Jon: Do we see a use case where a ucdn can decide more than one dcdn? Scott: It is possible, but you're still using the same mechanism. Jan: Agree that protocol-wise the dcdn process can return more than one. Scott: The client gets one answer in the end. Jon: In parallel forking in SIP you get the first valid response. This is strictly related to the request routing interface. Jan: If rr return more than one, the ucdn can still pick the one it prefers= . Jon: Maybe we're just moving the line between advertizing and rr. [Jon leaves] Scott: I'd assume that between ucdn and dcdn there is one specific interface. Either there is one transaction or more in parallel, from an interface perpective things are the same. Jan: If you involve two dcdns, you have to pay both. Scott: Yeah, that's where economics get in place. Anne Marrec: We need to allow only one dcdn. Scott: What people do today is HTTP and DNS redirect, and in that case you need to pick one. Jan: I agree that the footprint advertizing can return more than one. Anne: Do you consider one agreement between ucdn and dcdn or more? Jan: I guess there would be one contract. Anne: There could be several, based on contract. A dcdn can have an on-net contract and an off-net one. Jan: We agreed that contracts are out-of-scope. [Discussion about possible multiple contracts, whether they should be seen as different dcdns, whether they can exist at all, ...] Emile: Believe Anne's use case should be described in the draft. Anne: We need to make some assumptions on which parameters are in the contract. Jan: I agree that we need to address the distinction of what is going to be in the contract and what needs to be advertized through the footprint ad interface. Emile: Stresses that a use case for different contracts for the same dcdn should be added. Anne: Explains that an off-net dcdn can delegate to an on-net dcdn if requested. This would resolve in two sub-contracts. Jan: I understand now. But what should matter is not whether the dcdn is on- or off-net, but the performance guaranteed. Jan: Second consideration: what if the situation expressed in the contract changes, like e.g. after an hardware upgrade? Scott: What is important is not the coverage, but the location of the dcdn caches. I can advertize the entire planet. Jan: On that point there is agreement, willingness to serve is not enough, parameters are also important. And parameters will be bound to contractual clauses. Anne: If advertizing changes often, that may overload the ucdn. Should be coarse-grained info. Jan: The question is what is realistically feasible? Scott: Let's identify what is the minimum. One use case is a global cdn that delegates to a local cdn that has caches in the region to be served. Another use case is an ucdn that is localized and get a request for a region far away. What's required to do that. Jan: I agree that those are important use cases. Enrico: Scott's use cases cover are the most intresting ones. Jan: Suggest to describe them and have them written down. Scott: Let's start from the two main use cases, and then other will follow from them. Jan: Should we focus on describe the main use cases better? Scott: Yes, and from there let's identify what are the mandatory pieces of information. Jan: And there we'll try to draw a line between what will be in the protocol and what will be addressed by the contract. Emile: Information necessary for making a decision are about the end-to-end quality information. Scott: Realtime information cannot be signalled. Jan: We agreed that it should be more averaged information. Emile: Sort of disagrees. Need to be discussed. Scott: Let's define what's strictly mandatory for making a decision. Everthing else can be set in configurations. Jan: We should discuss the use cases on the list before we have the next meeting next Tuesday. Meeting ends at 17:40 CEST. ************************************ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 Jan.Seedorf@neclab.eu Wed Oct 10 05:58:53 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 C96A121F84A0; Wed, 10 Oct 2012 05:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.069 X-Spam-Level: X-Spam-Status: No, score=-104.069 tagged_above=-999 required=5 tests=[AWL=1.530, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 40CbI8LYZ8zw; Wed, 10 Oct 2012 05:58:53 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B1ECF21F8493; Wed, 10 Oct 2012 05:58:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 28A87102108; Wed, 10 Oct 2012 14:58:52 +0200 (CEST) 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 60qhHTXVY2E1; Wed, 10 Oct 2012 14:58:52 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 0F5411020FE; Wed, 10 Oct 2012 14:58:42 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 10 Oct 2012 14:58:41 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Meeting invitation: CDNI Footprint Design Team Interim Meeting 2 Thread-Index: AQHNoInGxJ4PDxCBhEq948BEZAgqXpeyjJ1w Date: Wed, 10 Oct 2012 12:57:55 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553651CF@DAPHNIS.office.hd> References: <122344879.6216.1349174178766.JavaMail.nobody@jsj6tc004.webex.com> In-Reply-To: <122344879.6216.1349174178766.JavaMail.nobody@jsj6tc004.webex.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] FW: Meeting invitation: CDNI Footprint Design Team Interim Meeting 2 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, 10 Oct 2012 12:58:53 -0000 SGVyZSBhcmUgdGhlIGRldGFpbHMgZm9yIHRoZSBuZXh0IGNhbGwgbmV4dCBUdWVzZGF5LCBJIHRv bGQgT3V0bG9vayB0byByZW1pbmQgbWUgb24gTW9uZGF5IHRvIGNpcmN1bGF0ZSBpdCBhZ2Fpbi4N Cg0KIC0gSmFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVmYW5vIFBy ZXZpZGkgW21haWx0bzptZXNzZW5nZXJAd2ViZXguY29tXSANClNlbnQ6IFR1ZXNkYXksIE9jdG9i ZXIgMDIsIDIwMTIgMTI6MzYgUE0NClRvOiBKYW4gU2VlZG9yZg0KU3ViamVjdDogTWVldGluZyBp bnZpdGF0aW9uOiBDRE5JIEZvb3RwcmludCBEZXNpZ24gVGVhbSBJbnRlcmltIE1lZXRpbmcgMg0K DQpIZWxsbyBKYW4gU2VlZG9yZiwgDQoNClN0ZWZhbm8gUHJldmlkaSBpbnZpdGVzIHlvdSB0byBh dHRlbmQgdGhpcyBvbmxpbmUgbWVldGluZy4gDQoNClRvcGljOiBDRE5JIEZvb3RwcmludCBEZXNp Z24gVGVhbSBJbnRlcmltIE1lZXRpbmcgMiANCkRhdGU6IFR1ZXNkYXksIE9jdG9iZXIgMTYsIDIw MTIgDQpUaW1lOiA0OjAwIHBtLCBFdXJvcGUgU3VtbWVyIFRpbWUgKEFtc3RlcmRhbSwgR01UKzAy OjAwKSANCk1lZXRpbmcgTnVtYmVyOiAyMDggMjgzIDUxOSANCk1lZXRpbmcgUGFzc3dvcmQ6IGNk bmkgDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSANClRvIGpvaW4gdGhlIG9ubGluZSBtZWV0aW5nIChOb3cgZnJvbSBtb2JpbGUgZGV2 aWNlcyEpIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSANCjEuIEdvIHRvIGh0dHBzOi8vY2lzY29zYWxlcy53ZWJleC5jb20vY2lzY29zYWxl cy9qLnBocD9FRD0yMDYwMjAxOTcmVUlEPTE4ODI0MTA3MzImUFc9Tk9ESTBabUkxTkRZMiZSVD1N aU15TWclM0QlM0QgDQoyLiBFbnRlciB5b3VyIG5hbWUgYW5kIGVtYWlsIGFkZHJlc3MuIA0KMy4g RW50ZXIgdGhlIG1lZXRpbmcgcGFzc3dvcmQ6IGNkbmkgDQo0LiBDbGljayAiSm9pbiBOb3ciLiAN Cg0KVG8gdmlldyBpbiBvdGhlciB0aW1lIHpvbmVzIG9yIGxhbmd1YWdlcywgcGxlYXNlIGNsaWNr IHRoZSBsaW5rOiANCmh0dHBzOi8vY2lzY29zYWxlcy53ZWJleC5jb20vY2lzY29zYWxlcy9qLnBo cD9FRD0yMDYwMjAxOTcmVUlEPTE4ODI0MTA3MzImUFc9Tk9ESTBabUkxTkRZMiZPUlQ9TWlNeU1n JTNEJTNEIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KQUxFUlQ6VG9sbC1GcmVlIERpYWwgUmVzdHJpY3Rpb25zIGZv ciAoNDA4KSBhbmQgKDkxOSkgQXJlYSBDb2RlcyANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoNClRoZSBhZmZlY3RlZCB0 b2xsIGZyZWUgbnVtYmVycyBhcmU6ICg4NjYpIDQzMi05OTAzIGZvciB0aGUgU2FuIEpvc2UvTWls cGl0YXMgYXJlYSBhbmQgKDg2NikgMzQ5LTM1MjAgZm9yIHRoZSBSVFAgYXJlYS4gDQoNClBsZWFz ZSBkaWFsIHRoZSBsb2NhbCBhY2Nlc3MgbnVtYmVyIGZvciB5b3VyIGFyZWEgZnJvbSB0aGUgbGlz dCBiZWxvdzogDQotIFNhbiBKb3NlL01pbHBpdGFzICg0MDgpIGFyZWE6IDUyNS02ODAwIA0KLSBS VFAgKDkxOSkgYXJlYTogMzkyLTMzMzAgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpUbyBqb2luIHRoZSB0ZWxlY29uZmVyZW5jZSBv bmx5IA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSANCjEuIERpYWwgaW50byBDaXNjbyBXZWJFeCAodmlldyBhbGwgR2xvYmFsIEFjY2VzcyBO dW1iZXJzIGF0IA0KaHR0cDovL2Npc2NvLmNvbS9lbi9VUy9hYm91dC9kb2luZ19idXNpbmVzcy9j b25mZXJlbmNpbmcvaW5kZXguaHRtbCANCjIuIEZvbGxvdyB0aGUgcHJvbXB0cyB0byBlbnRlciB0 aGUgTWVldGluZyBOdW1iZXIgKGxpc3RlZCBhYm92ZSkgb3IgQWNjZXNzIENvZGUgZm9sbG93ZWQg YnkgdGhlICMgc2lnbi4gDQoNClNhbiBKb3NlLCBDQTogKzEuNDA4LjUyNS42ODAwIFJUUDogKzEu OTE5LjM5Mi4zMzMwIA0KDQpVUy9DYW5hZGE6ICsxLjg2Ni40MzIuOTkwMyBVbml0ZWQgS2luZ2Rv bTogKzQ0LjIwLjg4MjQuMDExNyANCg0KSW5kaWE6ICs5MS44MC40MzUwLjExMTEgR2VybWFueTog KzQ5LjYxOS42NzczLjkwMDIgDQoNCkphcGFuOiArODEuMy41NzYzLjkzOTQgQ2hpbmE6ICs4Ni4x MC44NTE1LjU2NjYgDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gDQpGb3IgYXNzaXN0YW5jZSANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQoxLiBHbyB0byBodHRwczovL2Npc2Nv c2FsZXMud2ViZXguY29tL2Npc2Nvc2FsZXMvbWMgDQoyLiBPbiB0aGUgbGVmdCBuYXZpZ2F0aW9u IGJhciwgY2xpY2sgIlN1cHBvcnQiLiANCg0KWW91IGNhbiBjb250YWN0IG1lIGF0OiANCnNwcmV2 aWRpQGNpc2NvLmNvbSANCjM5LTA2NTE2NDQ0OTEgDQoNClRvIGFkZCB0aGlzIG1lZXRpbmcgdG8g eW91ciBjYWxlbmRhciBwcm9ncmFtIChmb3IgZXhhbXBsZSBNaWNyb3NvZnQgT3V0bG9vayksIGNs aWNrIHRoaXMgbGluazogDQpodHRwczovL2Npc2Nvc2FsZXMud2ViZXguY29tL2Npc2Nvc2FsZXMv ai5waHA/RUQ9MjA2MDIwMTk3JlVJRD0xODgyNDEwNzMyJklDUz1NSSZMRD0xJlJEPTImU1Q9MSZT SEEyPXZJVmxJb1p0YTFDa016aVNIaVppUnZzMlpNaG5tTTdSRE1qc2o3QmRzWmM9JlJUPU1pTXlN ZyUzRCUzRCANCg0KVGhlIHBsYXliYWNrIG9mIFVDRiAoVW5pdmVyc2FsIENvbW11bmljYXRpb25z IEZvcm1hdCkgcmljaCBtZWRpYSBmaWxlcyByZXF1aXJlcyBhcHByb3ByaWF0ZSBwbGF5ZXJzLiBU byB2aWV3IHRoaXMgdHlwZSBvZiByaWNoIG1lZGlhIGZpbGVzIGluIHRoZSBtZWV0aW5nLCBwbGVh c2UgY2hlY2sgd2hldGhlciB5b3UgaGF2ZSB0aGUgcGxheWVycyBpbnN0YWxsZWQgb24geW91ciBj b21wdXRlciBieSBnb2luZyB0byBodHRwczovL2Npc2Nvc2FsZXMud2ViZXguY29tL2Npc2Nvc2Fs ZXMvc3lzdGVtZGlhZ25vc2lzLnBocC4gDQoNCg0KDQoNCmh0dHA6Ly93d3cud2ViZXguY29tIA0K DQpDQ1A6KzE0MDg1MjU2ODAweDIwODI4MzUxOSMgDQoNCklNUE9SVEFOVCBOT1RJQ0U6IFRoaXMg V2ViRXggc2VydmljZSBpbmNsdWRlcyBhIGZlYXR1cmUgdGhhdCBhbGxvd3MgYXVkaW8gYW5kIGFu eSBkb2N1bWVudHMgYW5kIG90aGVyIG1hdGVyaWFscyBleGNoYW5nZWQgb3Igdmlld2VkIGR1cmlu ZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRlZC4gQnkgam9pbmluZyB0aGlzIHNlc3Npb24sIHlv dSBhdXRvbWF0aWNhbGx5IGNvbnNlbnQgdG8gc3VjaCByZWNvcmRpbmdzLiBJZiB5b3UgZG8gbm90 IGNvbnNlbnQgdG8gdGhlIHJlY29yZGluZywgZGlzY3VzcyB5b3VyIGNvbmNlcm5zIHdpdGggdGhl IG1lZXRpbmcgaG9zdCBwcmlvciB0byB0aGUgc3RhcnQgb2YgdGhlIHJlY29yZGluZyBvciBkbyBu b3Qgam9pbiB0aGUgc2Vzc2lvbi4gUGxlYXNlIG5vdGUgdGhhdCBhbnkgc3VjaCByZWNvcmRpbmdz IG1heSBiZSBzdWJqZWN0IHRvIGRpc2NvdmVyeSBpbiB0aGUgZXZlbnQgb2YgbGl0aWdhdGlvbi4g DQoNCg== From flefauch@cisco.com Thu Oct 11 12:54:24 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 B464D21F85A8 for ; Thu, 11 Oct 2012 12:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgHuzrqkNLIc for ; Thu, 11 Oct 2012 12:54:24 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2154721F84DD for ; Thu, 11 Oct 2012 12:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=266; q=dns/txt; s=iport; t=1349985264; x=1351194864; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=gDcYPTGaU7/5eacfTmtEg3hQ+2fdd9mDotV6uPZdcow=; b=OErrvv6MxiQuMk8gK0N8GohqEZzMy9M+xL77a84OyFp7xj83S1IWA3yV d8SSA1LJoBosuHabLdqY1QwA1kf6br5YN/HS+A7FOsxJc1M+MS7XorNj5 /JzVYP2XweNhunaFdeUDzAFezVspKXvc3EOsbz3X7a3B0YpAhFuKkeuwK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAQjd1CtJXG+/2dsb2JhbABEv1WBCIIiAQQSAXgBKlYnBBsah2KYKIEooC+RB2ADpDKBa4Jtghc X-IronPort-AV: E=Sophos;i="4.80,573,1344211200"; d="scan'208";a="130757779" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 11 Oct 2012 19:54:23 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9BJsNYr019327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Oct 2012 19:54:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 14:54:23 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Cut-off dates reminder Thread-Index: AQHNp+o1DqakNkIhGE+W19uDx4SNtw== Date: Thu, 11 Oct 2012 19:54:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19262.000 x-tm-as-result: No--27.292300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" Content-ID: <1285A9519803B04E99DC91F1B40A38AC@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Cut-off dates reminder 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, 11 Oct 2012 19:54:24 -0000 =95 2012-10-15 (Monday): Internet Draft Cut-off for initial document (-00)= submission by UTC 24:00, upload using IETF ID Submission Tool. =95 2012-10-22 (Monday): Internet Draft final submission cut-off by UTC 24= :00, upload using IETF ID Submission Tool.= From Jan.Seedorf@neclab.eu Fri Oct 12 08:31:53 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 55FC021F86B3; Fri, 12 Oct 2012 08:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.261 X-Spam-Level: X-Spam-Status: No, score=-103.261 tagged_above=-999 required=5 tests=[AWL=0.338, 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 qde3MOQzQ1-r; Fri, 12 Oct 2012 08:31:52 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id ABEA521F86B8; Fri, 12 Oct 2012 08:31:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 16AC710216A; Fri, 12 Oct 2012 17:31:47 +0200 (CEST) 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 NTTQ2ixgucI6; Fri, 12 Oct 2012 17:31:47 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id ECF61102179; Fri, 12 Oct 2012 17:31:31 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 12 Oct 2012 17:31:32 +0200 From: Jan Seedorf To: Scott Wainner , "cdni-footprint@ietf.org" Thread-Topic: Thoughts on the 'CDNI Footprint/Capabilities Design Team Call' Thread-Index: AQHNps0K3zgNY7lfFEavQ3U5L72Pb5e1zt1Q Date: Fri, 12 Oct 2012 15:31:01 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55375008@DAPHNIS.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE5535EC00@PALLENE.office.hd> <50754575.1060908@cisco.com> In-Reply-To: <50754575.1060908@cisco.com> 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" Subject: Re: [CDNi] Thoughts on the 'CDNI 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: Fri, 12 Oct 2012 15:31:53 -0000 Dear Scott, Thanks for sending these use cases. I will in another email send the use ca= ses that Francois had originally suggested (just as input to this discussio= n). Anne and Emil: can you please also describe in a mail to this list the use = cases you had sketched in the phone call this week? Then - as discussed - we can hopefully carve out 2-3 use cases we agree on = and start the discussion on what capabilities are mandatory for these agree= d use cases. - Jan > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com] > Sent: Wednesday, October 10, 2012 11:53 AM > To: Jan Seedorf; cdni-footprint@ietf.org > Cc: cdni@ietf.org > Subject: Thoughts on the 'CDNI Footprint/Capabilities Design Team Call' >=20 >=20 > Jan & Team, (resent with edits and CC to cdni) >=20 > I propose two base use cases that may be foundational building > blocks for more sophisticated use cases: >=20 > Definition: > - regional coverage: The CDN has cache nodes that service a well-defined > geographic or topologically bounded network >=20 > - global coverage: The CDN has cache nodes that service any geographic > region and is topologically unbounded >=20 > 1) uCDN with regional coverage delegates to one or more dCDN for global > 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 > well-defined region or IP topology > CRITERIA: uCDN ascertains if the requested content can be > delivered by dCDN(s) (short list created) > CRITERIA: uCDN determines which dCDN is appropriate (chosen by > priority) > In this use case, I think its quite simple for the uCDN to know the BGP > AS or geography covered because the uCDN is under the same > administrative authority as the IP network to which it is attached. The > well-defined region is much more easily bounded. The global dCDN becomes > a CDN of last-resort. Let's assume for the moment that the global dCDN > does NOT provide transitive delegation to other dCDN. The uCDN decision > is simple: > IF (client is in my network AND my region) > THEN (service client from my uCDN) > ELSE (consider serving client from global dCDN) > Now you can start adding optional conditions to either service the > client from either choice such as Time-of-Day, Priority, Cost, etc. >=20 > 2) uCDN with global coverage delegates to one or more dCDN for regional > coverage >=20 > Motivations for uCDN to delegate to dCDN might include the following: > - DECISION: uCDN client is inside a dCDN's well-defined region > or IP topology > IMPACT: uCDN client is better served by regional dCDN > CRITERIA: uCDN ascertains if the client is inside a > well-defined region or IP topology > CRITERIA: uCDN ascertains which dCDN's associated with the > region can deliver the requested content (short list) > CRITERIA: uCDN determines which dCDN is appropriate (chosen by > priority) > In this case, the uCDN needs to know the candidate regions and have the > ability to associate a client to the candidate region. That means each > dCDN needs to advertise its candidate region to the global uCDN. The > regional dCDN become may be preferred provided the dCDN is available and > capable of delivering the content. We have a fairly simple decision > process: > IF (client is in region X) > AND (ISP 1 services region X) > AND (client is attached to ISP 1's AS) > THEN (service the client from dCDN of ISP 1) > ELSE (consider serving client from global uCDN) > Now you can start adding optional conditions to either service the > client from either choice such as Time-of-Day, Priority, Cost, etc. >=20 > N) The intermediate CDN delegates to one or more regional dCDN for > regional coverage. The intermediate CDN is also a delegate of a > regional uCDN. >=20 > I don't see that the motivations change from the two cases previously > defined. The uCDN delegates to the intermediate CDN to get better > coverage and the intermediate CDN delegates to the regional dCDN's to > get better performance. What is different is the transitive nature of > the coverage where a regional dCDN advertises its regional footprint > (region and associated AS) to the intermediate CDN. The intermediate > CDN now aggregates all its delegates (regions and associated AS's) and > advertises that to the uCDN. For a well connected intermediate CDN, > that could be a lot of information to flood to the regional uCDN. If > the intermediate CDN doesn't have robust coverage, then perhaps it is > really a regional CDN which means the information in the footprint > advertisement is sparse. The decision is simply to indicate which > regions associated with which AS are transitive in nature. >=20 > Summary >=20 > I see three mandatory requirements: >=20 > 1) COVERAGE: > - AS to which the dCDN is attached > AND > - regions to which that dCDN services > 2) CAPABILITY: > - content delivery method > - authentication method > 3) AVAILABILITY: > - active / operational for servicing 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 > Design > >> 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 t= o 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 Desi= gn > >> 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 progres= s > >>> before the Atlanta meeting, so please fill in the doodle if you are > interested > >>> 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 > > . > > From Jan.Seedorf@neclab.eu Fri Oct 12 08:35:05 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 E407321F86A4; Fri, 12 Oct 2012 08:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 T+aBO8sO55UW; Fri, 12 Oct 2012 08:35:05 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id D353021F86A3; Fri, 12 Oct 2012 08:35:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4154A102178; Fri, 12 Oct 2012 17:35:04 +0200 (CEST) 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 8-xPR5dhEuDJ; Fri, 12 Oct 2012 17:35:04 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 27AAB10216A; Fri, 12 Oct 2012 17:34:54 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 12 Oct 2012 17:34:24 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases Thread-Index: AQHNb+6ww4n8+TU+PUiV/pXzBj3LXZe2Phkw Date: Fri, 12 Oct 2012 15:34:23 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55375025@DAPHNIS.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE32CE33F7@PALLENE.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" Subject: [CDNi] FW: CDNI Footprint/Capabilities Design Team - Suggestion to work from simple usecases 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, 12 Oct 2012 15:35:06 -0000 Hi all, Just as a reminder: below are the use cases Francois suggested a while ago. - Jan -----Original Message----- From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]=20 Sent: Wednesday, August 01, 2012 4:05 PM To: cdni-footprint@ietf.org Cc: Francois Le Faucheur (flefauch); cdni@ietf.org; Jan Seedorf; Guillou Al= lan Subject: CDNI Footprint/Capabilities Design Team - Suggestion to work from = simple usecases Jan, Stefano, Jon, I just wanted to reiterate the suggestion I made at the very end of the WG = meeting Yesterday. A possible way to make progress might be to: 1) identify one, or a very small number, of use case(s) that we want the C= DNI Footprint/Capabilities to support 2) identify the semantics of the required information for this/these speci= fic use cases. While this approach may arguably not allow us to define the most flexible u= niversal solution, it would have the merit of allowing us to define a solut= ion addressing some part of the problem. With respect to 1), I think the design team has already identified ISP CDNs= and global CDNs as targeted dCDNs. So perhaps the use cases of focus could= include something like: * the uCDN wants to use dCDN1 (CDN of ISP1) when the enduser is attached t= o a part of ISP1 and where ISP1 feels the request can be well served by on-= net caches of ISP1 (an interesting flavor of this is where ISP1 has some of= his AS not covered well by his own CDN - e.g. some remote territory) * the uCDN wants to use dCDN2 (CDN of ISP 2) when the enduser is attached = to a part of ISP1 where ISP1 feels the request can _not_ be well served by = on-net caches of ISP1 but where ISP2 claims that the request can be well se= rved by CDN of ISP2 (because he has caches that - while not "on-net" on ISP= 1 - are well connected to ISP1 e.g. via many regional peering points) * the uCDN wants to use dCDN3 (a global CDN) when the enduser is attached = to any other ISP network with whom dCDN3 is well interconnected (e.g. via m= any regional peering points) * the uCDN wants to use dCDN 4 (another global CDN) when the enduser is at= tached to an ISP network with whom dCDN3 is not well interconnected (e.g. v= ia single centralized peering points) I just made that up so it needs more thinking, but take is as an example of= the sort of use case we may want to start from. =20 I hope that helps Francois On 31 Jul 2012, at 18:05, Jan Seedorf wrote: > Several people have indicated that they will come to this meeting, so: "i= t's on" :) Let's meet tomorrow (WED) at 15:00 at the IETF registration desk= to continue our discussions, trying to make some progress ... >=20 > - Jan >=20 >> -----Original Message----- >> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- >> bounces@ietf.org] On Behalf Of Jan Seedorf >> Sent: Wednesday, August 01, 2012 1:18 AM >> To: cdni-footprint@ietf.org >> Cc: Brandenburg, R. (Ray) van (ray.vanbrandenburg@tno.nl); Enrico >> Marocco; gilles.bertrand@orange.com; emile.stephan@orange.com; Kevin J >> Ma (kevin.ma@azukisystems.com) >> Subject: Re: [cdni-footprint] Doodle for 2nd CDNI Footprint/Capabilities >> Design Team Side Meeting at IETF-84 >>=20 >> Guys, >>=20 >> Looking at the latest doodle it seems that actually *** WED 15:00-17:00 = *** >> would be a good slot where a reasonable amount of people can make it. So= I >> suggest having another CDNI Footprint/Capabilities Design Team Side >> Meeting at this time. >>=20 >> Please confirm via email if you can actually make this slot, so that we = see if it >> really makes sense to have the meeting (i.e. all people that indicated s= o in >> the doodle really coming). >>=20 >> - Jan >>=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Mon Oct 15 06:34: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 127A921F86BE; Mon, 15 Oct 2012 06:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.328 X-Spam-Level: X-Spam-Status: No, score=-104.328 tagged_above=-999 required=5 tests=[AWL=1.271, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 VEhnFhf2ujlx; Mon, 15 Oct 2012 06:34:58 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C72ED21F86C5; Mon, 15 Oct 2012 06:34:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3A892102185; Mon, 15 Oct 2012 15:34:57 +0200 (CEST) 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 6FABX5vQEpCa; Mon, 15 Oct 2012 15:34:57 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 18E2010216B; Mon, 15 Oct 2012 15:34:47 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 15 Oct 2012 15:34:17 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Meeting invitation: CDNI Footprint Design Team Interim Meeting 2 Thread-Index: AQHNoInGxJ4PDxCBhEq948BEZAgqXpe6ckNQ Date: Mon, 15 Oct 2012 13:34:17 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55377A86@DAPHNIS.office.hd> References: <122344879.6216.1349174178766.JavaMail.nobody@jsj6tc004.webex.com> In-Reply-To: <122344879.6216.1349174178766.JavaMail.nobody@jsj6tc004.webex.com> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] FW: Meeting invitation: CDNI Footprint Design Team Interim Meeting 2 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, 15 Oct 2012 13:34:59 -0000 SGkgYWxsLA0KDQpQbGVhc2UgZmluZCBiZWxvdyB0aGUgaW5mb3JtYXRpb24gZm9yIHRoZSBDRE5J IEZvb3RwcmludCBEZXNpZ24gVGVhbSBJbnRlcmltIE1lZXRpbmcgdG9tb3Jyb3cuDQoNCiAtIEph bg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlZmFubyBQcmV2aWRpIFtt YWlsdG86bWVzc2VuZ2VyQHdlYmV4LmNvbV0gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDAyLCAy MDEyIDEyOjM2IFBNDQpUbzogSmFuIFNlZWRvcmYNClN1YmplY3Q6IE1lZXRpbmcgaW52aXRhdGlv bjogQ0ROSSBGb290cHJpbnQgRGVzaWduIFRlYW0gSW50ZXJpbSBNZWV0aW5nIDINCg0KSGVsbG8g SmFuIFNlZWRvcmYsIA0KDQpTdGVmYW5vIFByZXZpZGkgaW52aXRlcyB5b3UgdG8gYXR0ZW5kIHRo aXMgb25saW5lIG1lZXRpbmcuIA0KDQpUb3BpYzogQ0ROSSBGb290cHJpbnQgRGVzaWduIFRlYW0g SW50ZXJpbSBNZWV0aW5nIDIgDQpEYXRlOiBUdWVzZGF5LCBPY3RvYmVyIDE2LCAyMDEyIA0KVGlt ZTogNDowMCBwbSwgRXVyb3BlIFN1bW1lciBUaW1lIChBbXN0ZXJkYW0sIEdNVCswMjowMCkgDQpN ZWV0aW5nIE51bWJlcjogMjA4IDI4MyA1MTkgDQpNZWV0aW5nIFBhc3N3b3JkOiBjZG5pIA0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g DQpUbyBqb2luIHRoZSBvbmxpbmUgbWVldGluZyAoTm93IGZyb20gbW9iaWxlIGRldmljZXMhKSAN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0g DQoxLiBHbyB0byBodHRwczovL2Npc2Nvc2FsZXMud2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/ RUQ9MjA2MDIwMTk3JlVJRD0xODgyNDEwNzMyJlBXPU5PREkwWm1JMU5EWTImUlQ9TWlNeU1nJTNE JTNEIA0KMi4gRW50ZXIgeW91ciBuYW1lIGFuZCBlbWFpbCBhZGRyZXNzLiANCjMuIEVudGVyIHRo ZSBtZWV0aW5nIHBhc3N3b3JkOiBjZG5pIA0KNC4gQ2xpY2sgIkpvaW4gTm93Ii4gDQoNClRvIHZp ZXcgaW4gb3RoZXIgdGltZSB6b25lcyBvciBsYW5ndWFnZXMsIHBsZWFzZSBjbGljayB0aGUgbGlu azogDQpodHRwczovL2Npc2Nvc2FsZXMud2ViZXguY29tL2Npc2Nvc2FsZXMvai5waHA/RUQ9MjA2 MDIwMTk3JlVJRD0xODgyNDEwNzMyJlBXPU5PREkwWm1JMU5EWTImT1JUPU1pTXlNZyUzRCUzRCAN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSANCkFMRVJUOlRvbGwtRnJlZSBEaWFsIFJlc3RyaWN0aW9ucyBmb3IgKDQwOCkg YW5kICg5MTkpIEFyZWEgQ29kZXMgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KDQpUaGUgYWZmZWN0ZWQgdG9sbCBmcmVl IG51bWJlcnMgYXJlOiAoODY2KSA0MzItOTkwMyBmb3IgdGhlIFNhbiBKb3NlL01pbHBpdGFzIGFy ZWEgYW5kICg4NjYpIDM0OS0zNTIwIGZvciB0aGUgUlRQIGFyZWEuIA0KDQpQbGVhc2UgZGlhbCB0 aGUgbG9jYWwgYWNjZXNzIG51bWJlciBmb3IgeW91ciBhcmVhIGZyb20gdGhlIGxpc3QgYmVsb3c6 IA0KLSBTYW4gSm9zZS9NaWxwaXRhcyAoNDA4KSBhcmVhOiA1MjUtNjgwMCANCi0gUlRQICg5MTkp IGFyZWE6IDM5Mi0zMzMwIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KVG8gam9pbiB0aGUgdGVsZWNvbmZlcmVuY2Ugb25seSANCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQox LiBEaWFsIGludG8gQ2lzY28gV2ViRXggKHZpZXcgYWxsIEdsb2JhbCBBY2Nlc3MgTnVtYmVycyBh dCANCmh0dHA6Ly9jaXNjby5jb20vZW4vVVMvYWJvdXQvZG9pbmdfYnVzaW5lc3MvY29uZmVyZW5j aW5nL2luZGV4Lmh0bWwgDQoyLiBGb2xsb3cgdGhlIHByb21wdHMgdG8gZW50ZXIgdGhlIE1lZXRp bmcgTnVtYmVyIChsaXN0ZWQgYWJvdmUpIG9yIEFjY2VzcyBDb2RlIGZvbGxvd2VkIGJ5IHRoZSAj IHNpZ24uIA0KDQpTYW4gSm9zZSwgQ0E6ICsxLjQwOC41MjUuNjgwMCBSVFA6ICsxLjkxOS4zOTIu MzMzMCANCg0KVVMvQ2FuYWRhOiArMS44NjYuNDMyLjk5MDMgVW5pdGVkIEtpbmdkb206ICs0NC4y MC44ODI0LjAxMTcgDQoNCkluZGlhOiArOTEuODAuNDM1MC4xMTExIEdlcm1hbnk6ICs0OS42MTku Njc3My45MDAyIA0KDQpKYXBhbjogKzgxLjMuNTc2My45Mzk0IENoaW5hOiArODYuMTAuODUxNS41 NjY2IA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tIA0KRm9yIGFzc2lzdGFuY2UgDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KMS4gR28gdG8gaHR0cHM6Ly9jaXNjb3NhbGVzLndl YmV4LmNvbS9jaXNjb3NhbGVzL21jIA0KMi4gT24gdGhlIGxlZnQgbmF2aWdhdGlvbiBiYXIsIGNs aWNrICJTdXBwb3J0Ii4gDQoNCllvdSBjYW4gY29udGFjdCBtZSBhdDogDQpzcHJldmlkaUBjaXNj by5jb20gDQozOS0wNjUxNjQ0NDkxIA0KDQpUbyBhZGQgdGhpcyBtZWV0aW5nIHRvIHlvdXIgY2Fs ZW5kYXIgcHJvZ3JhbSAoZm9yIGV4YW1wbGUgTWljcm9zb2Z0IE91dGxvb2spLCBjbGljayB0aGlz IGxpbms6IA0KaHR0cHM6Ly9jaXNjb3NhbGVzLndlYmV4LmNvbS9jaXNjb3NhbGVzL2oucGhwP0VE PTIwNjAyMDE5NyZVSUQ9MTg4MjQxMDczMiZJQ1M9TUkmTEQ9MSZSRD0yJlNUPTEmU0hBMj12SVZs SW9adGExQ2tNemlTSGlaaVJ2czJaTWhubU03UkRNanNqN0Jkc1pjPSZSVD1NaU15TWclM0QlM0Qg DQoNClRoZSBwbGF5YmFjayBvZiBVQ0YgKFVuaXZlcnNhbCBDb21tdW5pY2F0aW9ucyBGb3JtYXQp IHJpY2ggbWVkaWEgZmlsZXMgcmVxdWlyZXMgYXBwcm9wcmlhdGUgcGxheWVycy4gVG8gdmlldyB0 aGlzIHR5cGUgb2YgcmljaCBtZWRpYSBmaWxlcyBpbiB0aGUgbWVldGluZywgcGxlYXNlIGNoZWNr IHdoZXRoZXIgeW91IGhhdmUgdGhlIHBsYXllcnMgaW5zdGFsbGVkIG9uIHlvdXIgY29tcHV0ZXIg YnkgZ29pbmcgdG8gaHR0cHM6Ly9jaXNjb3NhbGVzLndlYmV4LmNvbS9jaXNjb3NhbGVzL3N5c3Rl bWRpYWdub3Npcy5waHAuIA0KDQoNCg0KDQpodHRwOi8vd3d3LndlYmV4LmNvbSANCg0KQ0NQOisx NDA4NTI1NjgwMHgyMDgyODM1MTkjIA0KDQpJTVBPUlRBTlQgTk9USUNFOiBUaGlzIFdlYkV4IHNl cnZpY2UgaW5jbHVkZXMgYSBmZWF0dXJlIHRoYXQgYWxsb3dzIGF1ZGlvIGFuZCBhbnkgZG9jdW1l bnRzIGFuZCBvdGhlciBtYXRlcmlhbHMgZXhjaGFuZ2VkIG9yIHZpZXdlZCBkdXJpbmcgdGhlIHNl c3Npb24gdG8gYmUgcmVjb3JkZWQuIEJ5IGpvaW5pbmcgdGhpcyBzZXNzaW9uLCB5b3UgYXV0b21h dGljYWxseSBjb25zZW50IHRvIHN1Y2ggcmVjb3JkaW5ncy4gSWYgeW91IGRvIG5vdCBjb25zZW50 IHRvIHRoZSByZWNvcmRpbmcsIGRpc2N1c3MgeW91ciBjb25jZXJucyB3aXRoIHRoZSBtZWV0aW5n IGhvc3QgcHJpb3IgdG8gdGhlIHN0YXJ0IG9mIHRoZSByZWNvcmRpbmcgb3IgZG8gbm90IGpvaW4g dGhlIHNlc3Npb24uIFBsZWFzZSBub3RlIHRoYXQgYW55IHN1Y2ggcmVjb3JkaW5ncyBtYXkgYmUg c3ViamVjdCB0byBkaXNjb3ZlcnkgaW4gdGhlIGV2ZW50IG9mIGxpdGlnYXRpb24uIA0KDQo= From Jan.Seedorf@neclab.eu Mon Oct 15 06:37:10 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 6BA2011E8097; Mon, 15 Oct 2012 06:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.444 X-Spam-Level: X-Spam-Status: No, score=-104.444 tagged_above=-999 required=5 tests=[AWL=1.155, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 3qz5bKgnfkVf; Mon, 15 Oct 2012 06:37:09 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 23CF511E808D; Mon, 15 Oct 2012 06:37:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id E393E10216B; Mon, 15 Oct 2012 15:37:06 +0200 (CEST) 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 CJBpHVoCr8+V; Mon, 15 Oct 2012 15:37:06 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C98C110218F; Mon, 15 Oct 2012 15:36:56 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Mon, 15 Oct 2012 15:36:48 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Meeting invitation: CDNI Footprint Phone Call tomorrow Thread-Index: Ac2q2gzCOFN/ugxZThCmsG96+vylfQ== Date: Mon, 15 Oct 2012 13:36:47 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55377AD2@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 Cc: "cdni@ietf.org" Subject: [CDNi] FW: Meeting invitation: CDNI Footprint Phone Call tomorrow 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, 15 Oct 2012 13:37:10 -0000 To be clear: it is not an official interim meeting, just a phone call to ma= ke progress -----Original Message----- From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.o= rg] On Behalf Of Jan Seedorf Sent: Monday, October 15, 2012 3:34 PM To: cdni-footprint@ietf.org Cc: cdni@ietf.org Subject: [cdni-footprint] FW: Meeting invitation: CDNI Footprint Design Tea= m Interim Meeting 2 Hi all, Please find below the information for the CDNI Footprint Design Team Interi= m Meeting tomorrow. - Jan -----Original Message----- From: Stefano Previdi [mailto:messenger@webex.com]=20 Sent: Tuesday, October 02, 2012 12:36 PM To: Jan Seedorf Subject: Meeting invitation: CDNI Footprint Design Team Interim Meeting 2 Hello Jan Seedorf,=20 Stefano Previdi invites you to attend this online meeting.=20 Topic: CDNI Footprint Design Team Interim Meeting 2=20 Date: Tuesday, October 16, 2012=20 Time: 4:00 pm, Europe Summer Time (Amsterdam, GMT+02:00)=20 Meeting Number: 208 283 519=20 Meeting Password: cdni=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D206020197&UID= =3D1882410732&PW=3DNODI0ZmI1NDY2&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 To view in other time zones or languages, please click the link:=20 https://ciscosales.webex.com/ciscosales/j.php?ED=3D206020197&UID=3D18824107= 32&PW=3DNODI0ZmI1NDY2&ORT=3DMiMyMg%3D%3D=20 ----------------------------------------------------------------=20 ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 ----------------------------------------------------------------=20 The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area.=20 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 -------------------------------------------------------=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 San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://ciscosales.webex.com/ciscosales/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 sprevidi@cisco.com=20 39-0651644491=20 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:=20 https://ciscosales.webex.com/ciscosales/j.php?ED=3D206020197&UID=3D18824107= 32&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DvIVlIoZta1CkMziSHiZiRvs2ZMhnmM7RDMj= sj7BdsZc=3D&RT=3DMiMyMg%3D%3D=20 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://ciscosales.webex.com/ciscosales/systemdiagnosis.php.=20 http://www.webex.com=20 CCP:+14085256800x208283519#=20 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.=20 _______________________________________________ cdni-footprint mailing list cdni-footprint@ietf.org https://www.ietf.org/mailman/listinfo/cdni-footprint From anne.marrec@orange.com Mon Oct 15 07:16:40 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 C096921F8776; Mon, 15 Oct 2012 07:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, 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 PEHjFZ81qTqd; Mon, 15 Oct 2012 07:16:35 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDB721F8772; Mon, 15 Oct 2012 07:16:34 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 35CB23B4332; Mon, 15 Oct 2012 16:16:33 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 047A8238086; Mon, 15 Oct 2012 16:16:33 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 15 Oct 2012 16:16:32 +0200 From: To: "cdni-footprint@ietf.org" Thread-Topic: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call' Thread-Index: Ac2q36xlryg5CtK4SEe1SaSbbvQPIA== Date: Mon, 15 Oct 2012 14:16:31 +0000 Message-ID: <28062_1350310593_507C1AC1_28062_2925_3_E5E1F88FBF39A84689D4A4791AE362B901FA4D@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/related; boundary="_006_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.15.122430 Cc: "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI 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, 15 Oct 2012 14:16:40 -0000 --_006_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_ Content-Type: multipart/alternative; boundary="_000_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_" --_000_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We propose the following use case Anne & Emile Use case for Request routing =AB footprint & capabilities =BB Figure 1 shows the context of CDN interconnection used to illustrate the us= e case "footprint & capabilities". An example of the CDNI interface Request= Routing/footprint&capabilities exchanges between CDN A and CDN B will be d= etailed. [cid:image006.png@01CDAAF0.6FE27F00] I) Use case assumptions: CP demand example: =B7 A given CP1 wishes to delegate the delivery of its content to C= DNA. Most of CP1 client are from "France" but wants that client all over th= e world be also delivered through a CDN. Its contents are two types : o content delivers in HTTP o and content delivers in RTMP CP1 describes its content as per class of request, footprint and capabiliti= es parameters. Example of CP1's "service" demand for the use case: "Class of request": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint" : geo =3D world" "quality/capabilities": maxDeliveryStartLatency =3D 500 CDN interconnection negotiations phase: CDN A capabilities compared to CP1 demand are the following: "Class of request ": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint" : Geo=3D "france" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN A capabilities are not enough compared to CP1 demand (limited to "footp= rint/geo=3D france). CDN A already has an agreement with a global CDN (CDN = D) to deliver any content to "world" with url_signing=3D"bb" ("service_ad" = compatible with CP1 demand) but the price is very high. Beside, CDN A operator is also aware that another CDN, CDN B, has the possi= bility to deliver content to "Europe" with a lower price than CDN D. 1) CDN A notes the CP1 demand 2) CDN A contacts CDN B operator and demand CDN B capabilities compared to = CP1 demand. 3) CDN B notes the CDN A demand and verify if it can manage the CDNA demand. CDN B capabilities compared to CDN A demand: "Class of request ": "URI_class": http://cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN B owns capabilities are not enough compared to CDN A demand (limited to= footprint/geo=3D"europe" and protocol=3DHTTP). But CDN B operator already has an agreement with CDN C to deliver any conte= nt in RTMP to "Europe": "service_bc": "Class of request ": "URI_class": rtmp://cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN B is able to satisfy the CDN A demand for "footprint/geo=3DEurope" when= it delegates content delivered in RTMP to CDN C. 4) CDN B announces its capabilities to CDN A limited to "Europe" compared = to CDN A demand "Class of request": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint": Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 5) CDN A is ok and an agreement is concluded between CDNA and CAN B operato= rs for the following service: "service_ab": "Class of request ": "URI_class": *//cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 [ed.note] This CDN interconnection negotiation phase is out of scope of IET= F CDNI WG. In this example, potential dCDN capabilities are known by uCDN t= hanks to "relationship" or already concluded agreement. One can imagine ano= ther way for the uCDN to know potential dCDN capabilities: potential dCDN c= apabilities automatic advertisement directly to all potential uCDN or throu= gh a "CDN capability portal" accessible to all CDNs. II) Use case: II-1) CDN A- CDN B Interconnection initialization phase CDN A - CDN B interconnection initialization Parameters needed to initialize CDNI interfaces between CDN A and CDN B (re= quest Routing, metadata and logging) for the agreed "service" are exchanged= via the control interface. These parameters will be used to configure CDN = A and CDN B. Among those, the following parameters are needed to initialize the Request = Routing interface accordingly to the agreed "service_ab": Service_id : "service_ab" { "Class of request ": { "URI_class": *//cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" } "quality/capabilities" : maxDeliveryStartLatency =3D 500 } CDN A - CDN B Request Routing/footprint&capabilities Notification Once CDN A and CDN B are configured and operational, CDN B (dCDN) advertize= s CDN A (uCDN) with request routing information via the Request Routing/foo= tprint and capabilities interface. CDN A (dCDN) sends a Request Routing information notification to CDN B (uCD= N). This notification includes the following parameters: Service : { Service_id =3D service_ab Status =3D operational } After CDN A has received this Request routing information notification, an = example of its selection algorithm could be as following (as an example and= for information only) If the End-user request of content matches the class of request "*//cdn.cp1= .com/video/*? url_signing=3D"bb"&*" And { If the IP source address belongs to the footprint/geo=3D"France" then, the delivery of the requested content is done by the CDN A itse= lf else { if the IP source address belongs to the footprint/geo=3D"Europe" then, the = delivery of the requested content is delegated to CDN B (which will delegat= e it to CDN C if protocol =3D "RTMP") else { if the IP source address belongs to the footprint/geo=3D"World" then, the d= elivery of the requested content is delegated to CDN D } } II-2) Request routing information modification A problem occurs on CDN C so that it is not able to deliver anymore content= using RTMP. CDN A must now selects CDN D for the delivery of CP1's content in RTMP for = client other than in France. Request Routing/footprint&capabilities Notifications CDN C - CDN B Request Routing/footprint&capabilities Notification CDN C will then send a request routing information notification to CDN B This notification includes the following parameters: Service : { Service_id =3D service_bc Status =3D not_operational } CDN A - CDN B Request Routing/footprint&capabilities Notification CDN B will then send a request routing information notification to CDN A This notification includes the following parameters: Service : { Service_id =3D service_ab Status =3D partially_operational Modified_parameters : { Class of request/URI_class: http//cdn.cp1.com/video/*? url_signing=3D"bb"&* } } After CDN A has received this Request routing information notification, an = example of its modified selection algorithm is presented (as an example and= for information only) If the End-user request of content matches the class of request "*//cdn.cp1= .com/video/*? url_signing=3D"bb"&*" and { If the IP source address belongs to the footprint/geo=3D"France" then, the delivery of the requested content is done by the CDN A itse= lf else { if the IP source address belongs to the footprint/geo=3D"Europe" and the En= d-user request of content matches the class of request "http//*?*&*" then, the delivery of the requested content is delegated to CDN B else { if the IP source address belongs to the footprint/geo=3D"World" then, the d= elivery of the requested content is delegated to CDN D } } [cid:image007.png@01CDAAF0.6FE27F00] Anne MARREC FT/ OLNC/ OLN/ CNC/ IDA/ CDS t=E9l. +33 2 96 05 18 71 anne.marrec@orange.com [cid:image008.png@01CDAAF0.6FE27F00] ___________________________________________________________________________= ______________________________________________ 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. --_000_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We propose the following use ca= se

 

Anne & Emile

 

 

Use case for Request rout= ing =AB footprint & capabilities =BB

 

Figure 1 shows the context of C= DN interconnection used to illustrate the use case “footprint & c= apabilities”. An example of the CDNI interface Request Routing/footpr= int&capabilities exchanges between CDN A and CDN B will be detailed.

 

 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


I)  &nbs= p;           Use case assumptions:

 

CP demand example:

=B7         A given CP1 wishes to delegate the delivery of its content to CDNA. Most = of CP1 client are from “France” but wants that client all over = the world be also delivered through a CDN. Its contents are two types :

o    content delivers in HTTP

o    and content delivers in RTMP

CP= 1 describes its content as per class of request, footprint and capabilities= parameters.

Ex= ample of CP1’s “service” demand for the use case:

&#= 8220;Class of request”:

&= #8220;URI_class”:

*//cdn.cp1.com/video/*?url_signing=3D”bb”&*

&= quot;footprint" :

g= eo =3D world”

&#= 8220;quality/capabilities”:

&= nbsp;           &nbs= p;  maxDeliveryStartLatency =3D 500

 

CDN interconnection negotiat= ions phase:

 

CD= N A capabilities compared to CP1 demand are the following:

&#= 8220;Class of request “:

&= #8220;URI_class”:

*//cdn.cp1.com/video/*?url_signing=3D”bb”&*

&= #8220;footprint” :

Geo=3D “france”

&#= 8220;quality/capabilities” :

&= nbsp;           &nbs= p;  maxDeliveryStartLatency =3D 500

 

 

CD= N A capabilities are not enough compared to CP1 demand (limited to “f= ootprint/geo=3D france). CDN A already has an agreement with a global CDN (= CDN D) to deliver any content to “world” with url_signing=3D”bb” (“service_ad” compatible with C= P1 demand) but the price is very high.

Be= side, CDN A operator is also aware that another CDN, CDN B, has the possibi= lity to deliver content to “Europe” with a lower price than CDN= D.

 

     &= nbsp;          1) CDN A notes = the CP1 demand

2)= CDN A contacts CDN B operator and demand CDN B capabilities compared to CP= 1 demand.

3)= CDN B notes the CDN A demand and verify if it can manage the CDNA demand.<= o:p>

&n= bsp;            = ;  

CD= N B capabilities compared to CDN A demand:

&#= 8220;Class of request “:

&= #8220;URI_class”:

http://cdn.cp1.com/video/*= ? url_signing=3D”bb”&*

&= #8220;footprint” :

G= eo=3D “Europe”

&#= 8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

 

CD= N B owns capabilities are not enough compared to CDN A demand (limited to f= ootprint/geo=3D”europe” and protocol=3DHTTP).

Bu= t CDN B operator already has an agreement with CDN C to deliver any content= in RTMP to “Europe”:

&#= 8220;service_bc”:

&= #8220;Class of request “:

&= #8220;URI_class”:

rtmp://cdn.cp1.com/video/*= ? url_signing=3D”bb”&*

&= #8220;footprint” :

G= eo=3D “Europe”

&= #8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

CD= N B is able to satisfy the CDN A demand for “footprint/geo=3DEurope&#= 8221; when it delegates content delivered in RTMP to CDN C.

<= o:p> 

4)= CDN B announces its capabilities to CDN A limited to “Europe”&= nbsp; compared to CDN A demand

 

&#= 8220;Class of request“:

&= #8220;URI_class”:

*//cdn.cp1.com/video/*?url_signing=3D”bb”&*

&= #8220;footprint”:

Geo=3D “Europe”

&#= 8220;quality/capabilities” :

&n= bsp;            = ;   maxDeliveryStartLatency =3D 500

 

5)= CDN A is ok and an agreement is concluded between CDNA and CAN B operators= for the following service:

&#= 8220;service_ab”:

&= #8220;Class of request “:

&= #8220;URI_class”:

*//cdn.cp1.com/video/*? url_signing=3D”bb”&*

&= #8220;footprint” :

G= eo=3D “Europe”

&= #8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

<= o:p> 

<= o:p> 

[e= d.note] This CDN interconnection negotiation phase is out of scope of IETF = CDNI WG. In this example, potential dCDN capabilities are known by uCDN tha= nks to “relationship” or already concluded agreement. One can imagine another way for the uCDN to know potential dCDN= capabilities: potential dCDN capabilities automatic advertisement directly= to all potential uCDN or through a “CDN capability portal” acc= essible to all CDNs.

 

 

II)  &nb= sp;         Use case:

 

     &= nbsp;          II-1) CDN A-= CDN B Interconnection initialization phase

 

 

CDN A - CDN B interconnection initialization

 

Pa= rameters needed to initialize CDNI interfaces between CDN A and CDN B (requ= est Routing, metadata and logging) for the agreed “service” are= exchanged via the control interface. These parameters will be used to configure CDN A = and CDN B.

Am= ong those, the following parameters are needed to initialize the Request Ro= uting interface accordingly to the agreed “service_ab”:

 

Se= rvice_id : “service_ab”

&n= bsp;            = ;            &n= bsp;     {

&= #8220;Class of request “:

&= nbsp;           &nbs= p;  {

&= #8220;URI_class”:

*//cdn.cp1.com/video/*? url_signing=3D”bb”&*

&= #8220;footprint” :

G= eo=3D “Europe”

}=

&= #8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

}=

 

CDN A - CDN B Request Routing/footprint&capabilities Notification

 

On= ce CDN A and CDN B are configured and operational, CDN B (dCDN) advertizes = CDN A (uCDN) with request routing information via the Request Routing/footp= rint and capabilities interface.

 

CDN A (dCDN) sends a Request Routing information notification to CDN B (uC= DN). This notification includes the following parameters:=

Service :

      { 

          Service_id =3D= service_ab

           Status =3D op= erational

     }

 

After CDN A has received this R= equest routing information notification, an example of its selection algori= thm could be as following (as an example and for information only) &nb= sp;             = ;            &n= bsp;            = ; 

 

If= the End-user request of content matches the class of request “*//cdn.cp1.com/video/*? url_signing=3D”bb”&*”

An= d

{<= o:p>

If=   the IP source address belongs to the footprint/geo=3D”France”

&n= bsp;     then, the delivery of the requested content is= done by the CDN A itself

&n= bsp;     else {

i= f the IP source address belongs to the footprint/geo=3D”Europe” then, the delivery of the reque= sted content is delegated to CDN B (which will delegate it to CDN C if prot= ocol =3D “RTMP”)

e= lse {

<= o:p> 

i= f the IP source address belongs to the footprint/geo=3D”World” then, the delivery of the reques= ted content is delegated to CDN D

 

         &nb= sp;                     }

&n= bsp;       }

 

     &= nbsp;          II-2) Reques= t routing information modification

 

A problem occurs on CDN C so th= at it is not able to deliver anymore content using RTMP.<= /p>

CDN A must now selects CDN D fo= r the delivery of CP1’s content in RTMP for client other than in Fran= ce.

 

Request Routing/footprint&am= p;capabilities Notifications

 

CDN C - CDN B Request Routing/footprint&capabilities Notification

 

CD= N C will then send a request routing information notification to CDN B=

This notification includes the following parameters:=

Service :

      { 

          Service_id =3D= service_bc

           Status =3D no= t_operational

     }

 

CDN A - CDN B Request Routing/footprint&capabilities Notification

 

CD= N B will then send a request routing information notification to CDN A=

This notification includes the following parameters:=

Service :

      { 

          Service_id =3D= service_ab

           Status =3D pa= rtially_operational

          Modified_parameters= :

            &n= bsp;            = ;             {=

Class of request/URI_class:

http//cdn.cp1.com/video/*<= span lang=3D"EN-US">? url_signing=3D”bb”&*

}

     }

 

 

After CDN A has received this R= equest routing information notification, an example of its modified selection algorithm is presented (as an example and for inf= ormation only)           =             &nb= sp;            =   

 

If= the End-user request of content matches the class of request “*//cdn.cp1.com/video/*? url_signing=3D”bb”&*”

an= d

{<= o:p>

If=   the IP source address belongs to the footprint/geo=3D”France”

&n= bsp;     then, the delivery of the requested content is= done by the CDN A itself

&n= bsp;     else {

i= f the IP source address belongs to the footprint/geo=3D”Europe” and the End-user request of = content matches the class of request “http//*?*&*̶= 1;

t= hen, the delivery of the requested content is delegated to CDN B else {

<= o:p> 

i= f the IP source address belongs to the footprint/geo=3D”World” then, the delivery of the reques= ted content is delegated to CDN D

 

         &nb= sp;                     }

&n= bsp;       }

 

 

 

 

Anne MARREC
FT/ OLNC/ OLN/ CNC/ IDA/ CDS
t=E9l. +33 2 96 05 18 71

anne.marrec@orange.com

 

______________________________________________________________________=
___________________________________________________

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.
--_000_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_-- --_006_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=236; creation-date="Mon, 15 Oct 2012 14:16:31 GMT"; modification-date="Mon, 15 Oct 2012 14:16:31 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMoAAAEhCAMAAAAJT89vAAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAAUElEQVR42u3BMQEAAADCoPVPbQsvoAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgIMB5SsAAbohqIUAAAAA SUVORK5CYII= --_006_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_ Content-Type: image/png; name="image007.png" Content-Description: image007.png Content-Disposition: inline; filename="image007.png"; size=1137; creation-date="Mon, 15 Oct 2012 14:16:31 GMT"; modification-date="Mon, 15 Oct 2012 14:16:31 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACgAAAAoCAYAAACM/rhtAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAPxSURBVFjD 7ZVrbBRVGIZLNCHRYAgoCYQIkgiKf7imCAgxagJiVDQR2trbsrtDI0kTihSoBRYUuRRqKReh0AIC 4d4SLm2lgtCm3G9WBbq1FipgW8AARv338A5nVsZmEX72x/z4dnbOnHO+53u/98zEEIyhrUYoFIqJ 8QA9QA/QA/QAPUAP0AP0AD1AD9AD9AA9QA/QA3x0BBR+1/+2B9jOAPoUKQY2OqC7kuB/K/r3GnTm +B+SzN9qbiDKWCR8Dty0HvDFYMh6CbL7wuTnogDa5B8rkhSJignOpkmu8QnONRLJTvIUZ437WQQs 0bVnZF+/a1875gyErZOhZCZU5MKXw1sBpiomPQvLPoBNk2D+CFX3BKS1h3mxiuGQNwamPA+z+kFh KqxNghkvK6EUmN4L5g6CnLdgnV//Y406Nsznr8L6AOSOUuKh2qObKSwkxTZOhPyxkNlbe0m53Ddh 5YcwtbsL0IZLewbKF8Pt63DzV2j+RQvf18IXoLYS7jRDWNel78L3q6CmFBpOwU/fqi2CLF8CTbVw fq+udVB/XCDdBTEAGs/D5dOaf1J7N6iwFEGr4NojWl8BdUdhzxwV1N6ommrUN4CWbuIVee8ZuL0L BaVNfz4EF76DRaqoQZuHq/V/NKR3gYJEhU+gq+Gfu/C17qs3wa1GtWoYLB8Hf1yVEh+Zoq+cg4wX 4Rt15s7vsDMTKtcI9jfNiYcT2+HPFnVpJMSJxXKfYvtmvGJLhjZVgtmvwRDd75oF12qUXBs0nNFz +WOsxjP7KOkiKJNiVevg7g1YpVZXb5QiVVLgSUEOgRv1UCSlzhYbgFFamy0LNIWhdAH8WAYt6lRx Fhz4Cg7mS9VY49GogCvGq7om2KYFaYI4p1bVKWGufNco0JIsM29fDvx9Gxa8IV9ZqvyW1JQfj22R UlLaelrPRhgFV8fJ8Evh+iUlfx12h9QlKbhDCp7YrPGLgn5Fyqmg/Hd0BjoYzwZbA9qGTe8qFTYY j9iJbl4RQJoxru2fnZ8a+YsE1SyPVRXJh/uNLVYIpFL3YXnKekoJ1eYWzclT0mydzouyS1jF1h/T /GuwQQdj8dsq/Ad5dp+sdBAOrxRgR/M2iPolsR9M6QnbVd0RHYKCZBlVpv1EihSozXP7Oye9k06w /FfymfwjsDVq73T5K0eKLtdptNTijK7mhE/tZSyxR8oVyzIVy+AvKV4YMN1YIsgDskpxtqw14MFr 7aGfumTnwCQ44XMWJDgFWM5YfKvwud5pQefVEueM2a27dNh054KUrJFiM/oYryU46yNzH/tbHHjM z5P1iG+rDZre2XSjdL5exDqIWX0ftNH6/1z3Ae2fthz3AEjkYXGbuPXAAAAAAElFTkSuQmCC --_006_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_ Content-Type: image/png; name="image008.png" Content-Description: image008.png Content-Disposition: inline; filename="image008.png"; size=923; creation-date="Mon, 15 Oct 2012 14:16:31 GMT"; modification-date="Mon, 15 Oct 2012 14:16:31 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABIAAAAUCAYAAACAl21KAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAMbSURBVDjL lZRrSBRRFMfHHmYR5oMoelhBH6IoSEQiEsYiM3p8kCKkJwY96INpVL62NkqzoKcRFZUfCiqF3mWg lQjVlmhiStHD8jWb7e7M7I6zMzuzM/+Os1BtGW0Dh+FyD797zv/872UQwae9qIe4ewH43Hgo9ScG S5nK/Auiv2mBfLUMYulsePKGQ7q0DIbQ9X8gzfESUulBaC31UB3HIBRGQyhJgPbufuSgYC8HYeMm yJWV1tqQuuE9nARx33hoH2ojB0nlR+FOT0ewszMEdr+Ht3wKpIoUGGJnZKBgTy9cKSkQVq+C6feH tGq/A/FAApQ6O2AGIwMpN6rhjIuHkJMDM2AQ2Q+5aiMJnQGD/xz51HwFReCGDoO4ZTvMfgla6xX0 X8mC/uXF35QYHCRsyEEPw4Bfvw5a0zUoDYdI/OZfMswIQWs3oZdArow0qC+rYaqusH3Dx0H/WAdT dv8dZEifIWSvsCrqmzMLakPDn8NwtqL/cgYCry4OAjKC0DueQm06DW/+BnDRMXDGxkIqKyNnauFG ffsAQtEw+B/s+g1kaOTe65BvbkbwayO0Zw44x0+w2nNnZpDYLT/P8/ZQNSvB7xoC9fmpcJDWWgVf RTLUxlCppqKCX7rcas+ZmABfkY0AMk2wF/5bW+HZwcB3kozpav8J0jueQDqTBvHgOOjdjh8nq3cf wTl2sgX7NmsmpPMlkK9lgc9j6L6NoUMvhE9NupAGYV8ihL3RUB7tIcN1wNQVGKoMcfNaOJOi4FoS RQCKAgbioQRq6ciA18NBQmEUrNhDSSUxkC4uJhHzIT/Mo/JTSQvaK2Ks8GyjnNz50JsaSSwzHOQ7 mwrBNjpU8m4y4U6KXMbSYeAvUBXC/jh41oykVkmz2Di4Fy6CdLQcgcd10NvagE+fSKMuB/x38+lC ToJQTO9NMV0N2yh4SyfCd2oe/Le3IPD6KuRzFfCkL0HflGngRoSs8W1uMnx2O5SaGmtqrM41s1Jl Jsvb4ylGs3zZZGutNBxnIXHsQM5AKPdqWD57PctNn8Fy8WNZbup0VrLZWNTWxnwH0IGi/mC19kkA AAAASUVORK5CYII= --_006_E5E1F88FBF39A84689D4A4791AE362B901FA4DPEXCVZYM12corpora_-- From Jan.Seedorf@neclab.eu Tue Oct 16 06:26:13 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 0BE4C21F8980; Tue, 16 Oct 2012 06:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.853 X-Spam-Level: X-Spam-Status: No, score=-101.853 tagged_above=-999 required=5 tests=[AWL=-1.628, BAYES_05=-1.11, EXTRA_MPART_TYPE=1, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=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 lBk6eOLXXNg8; Tue, 16 Oct 2012 06:26:07 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 69DD021F897F; Tue, 16 Oct 2012 06:26:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B331C1021ED; Tue, 16 Oct 2012 15:26:03 +0200 (CEST) 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 FvGnTh4w2oOA; Tue, 16 Oct 2012 15:26:03 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 6E55C10207D; Tue, 16 Oct 2012 15:25:48 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 16 Oct 2012 15:25:47 +0200 From: Jan Seedorf To: "anne.marrec@orange.com" , "cdni-footprint@ietf.org" Thread-Topic: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call' Thread-Index: Ac2q36xlryg5CtK4SEe1SaSbbvQPIAAwQPPw Date: Tue, 16 Oct 2012 13:25:47 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55379360@DAPHNIS.office.hd> References: <28062_1350310593_507C1AC1_28062_2925_3_E5E1F88FBF39A84689D4A4791AE362B901FA4D@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <28062_1350310593_507C1AC1_28062_2925_3_E5E1F88FBF39A84689D4A4791AE362B901FA4D@PEXCVZYM12.corporate.adroot.infra.ftgroup> 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/related; boundary="_006_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI 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: Tue, 16 Oct 2012 13:26:13 -0000 --_006_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_ Content-Type: multipart/alternative; boundary="_000_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_" --_000_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Anne and Emile, Thanks for sharing this use case and the detailed examples. It is all clear= to me, and I think good input to our discussions. Two quick comments (we can discuss more in the call today): - According to your example, "capabilities_updates" must not only = include "operational" or "non-operational", but probably "partially-operati= onal" plus some specification what partially means; - What about the case where capabilities updates may contain a ref= erral to a given footprint, as we have discussed, e.g. the "partially-opera= tional" update from B to A shall indicate that B can only serve RTMP in som= e parts of Europe? Do you agree to this scenario and that it should be supp= orted? - Jan From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.o= rg] On Behalf Of anne.marrec@orange.com Sent: Monday, October 15, 2012 4:17 PM To: cdni-footprint@ietf.org Cc: cdni@ietf.org Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities = Design Team Call' Hi all, We propose the following use case Anne & Emile Use case for Request routing =AB footprint & capabilities =BB Figure 1 shows the context of CDN interconnection used to illustrate the us= e case "footprint & capabilities". An example of the CDNI interface Request= Routing/footprint&capabilities exchanges between CDN A and CDN B will be d= etailed. [cid:image004.png@01CDABB2.837DA3B0] I) Use case assumptions: CP demand example: =B7 A given CP1 wishes to delegate the delivery of its content to C= DNA. Most of CP1 client are from "France" but wants that client all over th= e world be also delivered through a CDN. Its contents are two types : o content delivers in HTTP o and content delivers in RTMP CP1 describes its content as per class of request, footprint and capabiliti= es parameters. Example of CP1's "service" demand for the use case: "Class of request": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint" : geo =3D world" "quality/capabilities": maxDeliveryStartLatency =3D 500 CDN interconnection negotiations phase: CDN A capabilities compared to CP1 demand are the following: "Class of request ": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint" : Geo=3D "france" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN A capabilities are not enough compared to CP1 demand (limited to "footp= rint/geo=3D france). CDN A already has an agreement with a global CDN (CDN = D) to deliver any content to "world" with url_signing=3D"bb" ("service_ad" = compatible with CP1 demand) but the price is very high. Beside, CDN A operator is also aware that another CDN, CDN B, has the possi= bility to deliver content to "Europe" with a lower price than CDN D. 1) CDN A notes the CP1 demand 2) CDN A contacts CDN B operator and demand CDN B capabilities compared to = CP1 demand. 3) CDN B notes the CDN A demand and verify if it can manage the CDNA demand= . CDN B capabilities compared to CDN A demand: "Class of request ": "URI_class": http://cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN B owns capabilities are not enough compared to CDN A demand (limited to= footprint/geo=3D"europe" and protocol=3DHTTP). But CDN B operator already has an agreement with CDN C to deliver any conte= nt in RTMP to "Europe": "service_bc": "Class of request ": "URI_class": rtmp://cdn.cp1.com/video/*? url_signing=3D"bb"&= * "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN B is able to satisfy the CDN A demand for "footprint/geo=3DEurope" when= it delegates content delivered in RTMP to CDN C. 4) CDN B announces its capabilities to CDN A limited to "Europe" compared = to CDN A demand "Class of request": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint": Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 5) CDN A is ok and an agreement is concluded between CDNA and CAN B operato= rs for the following service: "service_ab": "Class of request ": "URI_class": *//cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 [ed.note] This CDN interconnection negotiation phase is out of scope of IET= F CDNI WG. In this example, potential dCDN capabilities are known by uCDN t= hanks to "relationship" or already concluded agreement. One can imagine ano= ther way for the uCDN to know potential dCDN capabilities: potential dCDN c= apabilities automatic advertisement directly to all potential uCDN or throu= gh a "CDN capability portal" accessible to all CDNs. II) Use case: II-1) CDN A- CDN B Interconnection initialization phase CDN A - CDN B interconnection initialization Parameters needed to initialize CDNI interfaces between CDN A and CDN B (re= quest Routing, metadata and logging) for the agreed "service" are exchanged= via the control interface. These parameters will be used to configure CDN = A and CDN B. Among those, the following parameters are needed to initialize the Request = Routing interface accordingly to the agreed "service_ab": Service_id : "service_ab" { "Class of request ": { "URI_class": *//cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" } "quality/capabilities" : maxDeliveryStartLatency =3D 500 } CDN A - CDN B Request Routing/footprint&capabilities Notification Once CDN A and CDN B are configured and operational, CDN B (dCDN) advertize= s CDN A (uCDN) with request routing information via the Request Routing/foo= tprint and capabilities interface. CDN A (dCDN) sends a Request Routing information notification to CDN B (uCD= N). This notification includes the following parameters: Service : { Service_id =3D service_ab Status =3D operational } After CDN A has received this Request routing information notification, an = example of its selection algorithm could be as following (as an example and= for information only) If the End-user request of content matches the class of request "*//cdn.cp1= .com/video/*? url_signing=3D"bb"&*" And { If the IP source address belongs to the footprint/geo=3D"France" then, the delivery of the requested content is done by the CDN A itse= lf else { if the IP source address belongs to the footprint/geo=3D"Europe" then, the = delivery of the requested content is delegated to CDN B (which will delegat= e it to CDN C if protocol =3D "RTMP") else { if the IP source address belongs to the footprint/geo=3D"World" then, the d= elivery of the requested content is delegated to CDN D } } II-2) Request routing information modification A problem occurs on CDN C so that it is not able to deliver anymore content= using RTMP. CDN A must now selects CDN D for the delivery of CP1's content in RTMP for = client other than in France. Request Routing/footprint&capabilities Notifications CDN C - CDN B Request Routing/footprint&capabilities Notification CDN C will then send a request routing information notification to CDN B This notification includes the following parameters: Service : { Service_id =3D service_bc Status =3D not_operational } CDN A - CDN B Request Routing/footprint&capabilities Notification CDN B will then send a request routing information notification to CDN A This notification includes the following parameters: Service : { Service_id =3D service_ab Status =3D partially_operational Modified_parameters : { Class of request/URI_class: http//cdn.cp1.com/video/*? url_signing=3D"bb"&* } } After CDN A has received this Request routing information notification, an = example of its modified selection algorithm is presented (as an example and= for information only) If the End-user request of content matches the class of request "*//cdn.cp1= .com/video/*? url_signing=3D"bb"&*" and { If the IP source address belongs to the footprint/geo=3D"France" then, the delivery of the requested content is done by the CDN A itse= lf else { if the IP source address belongs to the footprint/geo=3D"Europe" and the En= d-user request of content matches the class of request "http//*?*&*" then, the delivery of the requested content is delegated to CDN B else { if the IP source address belongs to the footprint/geo=3D"World" then, the d= elivery of the requested content is delegated to CDN D } } [cid:image002.png@01CDABB2.01EE8670] Anne MARREC FT/ OLNC/ OLN/ CNC/ IDA/ CDS t=E9l. +33 2 96 05 18 71 anne.marrec@orange.com [cid:image003.png@01CDABB2.01EE8670] ___________________________________________________________________________= ______________________________________________ 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. --_000_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

= Hi Anne and Emile,

=  

= Thanks for sharing this use = case and the detailed examples. It is all clear to me, and I think good inp= ut to our discussions.

=  

= Two quick comments (we can d= iscuss more in the call today):

-          According to your example, “capabilities_updat= es” must not only include “operational” or “non-ope= rational”, but probably “partially-operational” plus some specification what = partially means;

-          What about the case where capabilities updates may c= ontain a referral to a given footprint, as we have discussed, e.g. the “partially-operational” update from B to A shall indi= cate that B can only serve RTMP in some parts of Europe? Do you agree to th= is scenario and that it should be supported?

=  

-          Jan

=  

=  

From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.org] On Behalf Of anne.marrec@orange.com
Sent: Monday, October 15, 20= 12 4:17 PM
To: cdni-footprint@ietf.org<= br> Cc: cdni@ietf.org
Subject: Re: [cdni-footprint= ] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call'=

 

Hi all,

 

We propose the following use case

 

Anne & Emile

 

 

Use case for Request routing =AB&nbs= p;footprint & capabilities =BB

 

Figure 1 shows the context of CDN interconnection used to il= lustrate the use case “footprint & capabilities”. An exampl= e of the CDNI interface Request Routing/footprint&capabilities exchanges between CDN A and CDN B will be detailed.

 

 
 =

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


I)        &n= bsp;           Use case assumptions:

 

CP demand example:

= =B7         A given CP1 wishes to delegate= the delivery of its content to CDNA. Most of CP1 client are from “Fr= ance” but wants that client all over the world be also delivered thro= ugh a CDN. Its contents are two types :

o    content delivers in HTTP =

o    and content delivers in RTMP

CP1 describes its content as = per class of request, footprint and capabilities parameters.

Example of CP1’s “= ;service” demand for the use case:

“Class of request”= ;:

“URI_class”:=

*//cdn.cp1.com/video/*?url_signing=3D”bb”&*

"footprint" :

geo =3D world”

“quality/capabilities&#= 8221;:

     = ;          maxDeliveryStartLat= ency =3D 500

 

CDN interconnection negotiations phase:=

 

CDN A capabilities compared to C= P1 demand are the following:

“Class of request ̶= 0;:

“URI_class”:=

*//cdn.cp1.com/video/*?url_signing=3D”bb”&*

“footprint” :

Geo=3D R= 20;france”

“quality/capabilities&#= 8221; :

     = ;          maxDeliveryStartLat= ency =3D 500

 <= /o:p>

 

CDN A capabilities are not en= ough compared to CP1 demand (limited to “footprint/geo=3D france). CD= N A already has an agreement with a global CDN (CDN D) to deliver any content to “world” with url_signing=3D”= ;bb” (“service_ad” compatible with CP1 demand) but the pr= ice is very high.

Beside, CDN A operator is als= o aware that another CDN, CDN B, has the possibility to deliver content to = “Europe” with a lower price than CDN D.

 

          =       1) CDN A notes the CP1 demand

2) CDN A contacts CDN B opera= tor and demand CDN B capabilities compared to CP1 demand.

3) CDN B notes the CDN A dema= nd and verify if it can manage the CDNA demand.

     = ;          

CDN B capabilities compared t= o CDN A demand:

“Class of request ̶= 0;:

“URI_class”:=

http://cdn.cp1.com/video/*? url_signing=3D”bb”&*

“footprint” :

Geo=3D “Europe”

“quality/capabilities&#= 8221; :

maxDeliveryStartLatency =3D 5= 00

 

CDN B owns capabilities are n= ot enough compared to CDN A demand (limited to footprint/geo=3D”europ= e” and protocol=3DHTTP).

But CDN B operator already ha= s an agreement with CDN C to deliver any content in RTMP to “Europe&#= 8221;:

“service_bc”:

“Class of request ̶= 0;:

“URI_class”:=

rtmp://cdn.cp1.com/video/*? url_signing=3D”bb”&*

“footprint” :

Geo=3D “Europe”

“quality/capabilities&#= 8221; :

maxDeliveryStartLatency =3D 5= 00

CDN B is able to satisfy the = CDN A demand for “footprint/geo=3DEurope” when it delegates con= tent delivered in RTMP to CDN C.

 

4) CDN B announces its capabi= lities to CDN A limited to “Europe”  compared to CDN A dem= and

 

“Class of request“= ;:

“URI_class”:=

*//cdn.cp1.com/video/*?url_signing=3D”bb”&*

“footprint”:=

Geo=3D R= 20;Europe”

“quality/capabilities&#= 8221; :

     = ;           maxDeliverySt= artLatency =3D 500

 

5) CDN A is ok and an agreeme= nt is concluded between CDNA and CAN B operators for the following service:=

“service_ab”:

“Class of request ̶= 0;:

“URI_class”:=

*//cdn.cp1.com/video/*? url_signing=3D”bb”&*

“footprint” :

Geo=3D “Europe”

“quality/capabilities&#= 8221; :

maxDeliveryStartLatency =3D 5= 00

 

 

[ed.note] This CDN interconne= ction negotiation phase is out of scope of IETF CDNI WG. In this example, p= otential dCDN capabilities are known by uCDN thanks to “relationship” or already concluded agreement. One c= an imagine another way for the uCDN to know potential dCDN capabilities: po= tential dCDN capabilities automatic advertisement directly to all potential= uCDN or through a “CDN capability portal” accessible to all CDNs.

 

 

II)        &= nbsp;        Use case:

 

          =       II-1) CDN A- CDN B Interconnection initialization phase<= /font>

 

 

CDN A - CDN B interconnectio= n initialization

 

Parameters needed to initiali= ze CDNI interfaces between CDN A and CDN B (request Routing, metadata and l= ogging) for the agreed “service” are exchanged via the control interface. = These parameters will be used to configure CDN A and CDN B.

Among those, the following pa= rameters are needed to initialize the Request Routing interface accordingly= to the agreed “service_ab”:

 

Service_id : “service_a= b”

     = ;            &n= bsp;            = ; {

“Class of request ̶= 0;:

     = ;          {=

“URI_class”:=

*//cdn.cp1.com/video/*? url_signing=3D”bb”&*

“footprint” :

Geo=3D “Europe”

}

“quality/capabilities&#= 8221; :

maxDeliveryStartLatency =3D 5= 00

}

 

CDN A - CDN B Request Routin= g/footprint&capabilities Notification

 

Once CDN A and CDN B are configu= red and operational, CDN B (dCDN) advertizes CDN A (uCDN) with request rout= ing information via the Request Routing/footprint and capabilities interface.

 <= /p>

CDN A (dCDN)= sends a Request Routing information notification to CDN B (uCDN). This not= ification includes the following parameters:

Service :

  =     { 

  =         Service_id =3D service_ab

  =          Status =3D operational

  =    }

 <= /o:p>

After CDN A has received this Request routing information no= tification, an example of its selection algorithm could be as following (as= an example and for information only)                   &n= bsp;            = ;          <= /font>

 <= /p>

If the End-user request of content = matches the class of request “*//cdn.cp1.com/video/*? url_signing=3D”= ;bb”&*”

And

{

If  the IP source address belongs to= the footprint/geo=3D”France”<= /o:p>

      t= hen, the delivery of the requested content is done by the CDN A itself=

      e= lse {

if the IP source address belongs to= the footprint/geo=3D”Europe” then, the delivery of the requested content is delegated to CDN B (wh= ich will delegate it to CDN C if protocol =3D “RTMP”)

else {

 

if the IP source address belo= ngs to the footprint/geo=3D”World” then, the delivery of the requested content is delegated to CDN D

 <= /p>

 =             &nb= sp;                 }

     &n= bsp;  }

 

          =       II-2) Request routing information modification

 

A problem occurs on CDN C so that it is not able to deliver = anymore content using RTMP.

CDN A must now selects CDN D for the delivery of CP1’s= content in RTMP for client other than in France.<= /p>

 

Request Routing/footprint&capabilities Notifications

 

CDN C - CDN B Request Routin= g/footprint&capabilities Notification

 

CDN C will then send a reques= t routing information notification to CDN B

This notifi= cation includes the following parameters:

Service :

  = ;    { 

  = ;        Service_id =3D service_bc<= o:p>

  = ;         Status =3D not_operationa= l

  = ;   }

 

CDN A - CDN B Request Routin= g/footprint&capabilities Notification

 

CDN B will then send a reques= t routing information notification to CDN A

This notifi= cation includes the following parameters:

Service :

  = ;    { 

  = ;        Service_id =3D service_ab<= o:p>

  = ;         Status =3D partially_oper= ational

  = ;        Modified_parameters :

  = ;            &n= bsp;            = ;           {<= /span>

Class of r= equest/URI_class:

http//cdn.cp1.com/video/*= ? url_signing=3D”bb”&*

}

  = ;   }

 <= /p>

 

After CDN A has received this Request routing information no= tification, an example of its modified selection algorithm is presented (as an example and for inf= ormation only)           =             &nb= sp;            =   

 <= /p>

If the End-user request of content = matches the class of request “*//cdn.cp1.com/video/*? url_signing=3D”= ;bb”&*”

and

{

If  the IP source address belongs to= the footprint/geo=3D”France”<= /o:p>

      t= hen, the delivery of the requested content is done by the CDN A itself

      e= lse {

if the IP source address belongs to= the footprint/geo=3D”Europe” and the End-user request of conte= nt matches the class of request “http//*?*&*”

then, the delivery of the req= uested content is delegated to CDN B else {

 

if the IP source address belo= ngs to the footprint/geo=3D”World” then, the delivery of the requested content is delegated to CDN D

 <= /p>

 =             &nb= sp;                 }

     &n= bsp;  }

 <= /p>

 

 

 

Anne MARREC
FT/ OLNC/ OLN/ CNC/ IDA/ CDS
t=E9l. +33 2 96 05 18 71

anne.marrec@orange.com<= /font>

 

______________________________________________________________=
___________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informat=
ions confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si v=
ous avez recu ce message par erreur, veuillez le signaler=

a l'expediteur et le detruire ainsi que les pieces jointes. Le=
s messages electroniques etant susceptibles d'alteration,=

France Telecom - Orange decline toute responsabilite si ce mes=
sage a ete altere, deforme ou falsifie. Merci.

 


This message and its attachments may contain confidential or p=
rivileged information that may be protected by law;


they should not be distributed, used or copied without authori=
sation.


If you have received this email in error, please notify the se=
nder and delete this message and its attachments.<=
/pre>

As emails may be altered, France Telecom - Orange is not liabl=
e for messages that have been modified, changed or falsified.


Thank you.
--_000_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_-- --_006_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=1137; creation-date="Tue, 16 Oct 2012 13:25:47 GMT"; modification-date="Tue, 16 Oct 2012 13:25:47 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACgAAAAoCAYAAACM/rhtAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAPxSURBVFjD 7ZVrbBRVGIZLNCHRYAgoCYQIkgiKf7imCAgxagJiVDQR2trbsrtDI0kTihSoBRYUuRRqKReh0AIC 4d4SLm2lgtCm3G9WBbq1FipgW8AARv338A5nVsZmEX72x/z4dnbOnHO+53u/98zEEIyhrUYoFIqJ 8QA9QA/QA/QAPUAP0AP0AD1AD9AD9AA9QA/QA3x0BBR+1/+2B9jOAPoUKQY2OqC7kuB/K/r3GnTm +B+SzN9qbiDKWCR8Dty0HvDFYMh6CbL7wuTnogDa5B8rkhSJignOpkmu8QnONRLJTvIUZ437WQQs 0bVnZF+/a1875gyErZOhZCZU5MKXw1sBpiomPQvLPoBNk2D+CFX3BKS1h3mxiuGQNwamPA+z+kFh KqxNghkvK6EUmN4L5g6CnLdgnV//Y406Nsznr8L6AOSOUuKh2qObKSwkxTZOhPyxkNlbe0m53Ddh 5YcwtbsL0IZLewbKF8Pt63DzV2j+RQvf18IXoLYS7jRDWNel78L3q6CmFBpOwU/fqi2CLF8CTbVw fq+udVB/XCDdBTEAGs/D5dOaf1J7N6iwFEGr4NojWl8BdUdhzxwV1N6ommrUN4CWbuIVee8ZuL0L BaVNfz4EF76DRaqoQZuHq/V/NKR3gYJEhU+gq+Gfu/C17qs3wa1GtWoYLB8Hf1yVEh+Zoq+cg4wX 4Rt15s7vsDMTKtcI9jfNiYcT2+HPFnVpJMSJxXKfYvtmvGJLhjZVgtmvwRDd75oF12qUXBs0nNFz +WOsxjP7KOkiKJNiVevg7g1YpVZXb5QiVVLgSUEOgRv1UCSlzhYbgFFamy0LNIWhdAH8WAYt6lRx Fhz4Cg7mS9VY49GogCvGq7om2KYFaYI4p1bVKWGufNco0JIsM29fDvx9Gxa8IV9ZqvyW1JQfj22R UlLaelrPRhgFV8fJ8Evh+iUlfx12h9QlKbhDCp7YrPGLgn5Fyqmg/Hd0BjoYzwZbA9qGTe8qFTYY j9iJbl4RQJoxru2fnZ8a+YsE1SyPVRXJh/uNLVYIpFL3YXnKekoJ1eYWzclT0mydzouyS1jF1h/T /GuwQQdj8dsq/Ad5dp+sdBAOrxRgR/M2iPolsR9M6QnbVd0RHYKCZBlVpv1EihSozXP7Oye9k06w /FfymfwjsDVq73T5K0eKLtdptNTijK7mhE/tZSyxR8oVyzIVy+AvKV4YMN1YIsgDskpxtqw14MFr 7aGfumTnwCQ44XMWJDgFWM5YfKvwud5pQefVEueM2a27dNh054KUrJFiM/oYryU46yNzH/tbHHjM z5P1iG+rDZre2XSjdL5exDqIWX0ftNH6/1z3Ae2fthz3AEjkYXGbuPXAAAAAAElFTkSuQmCC --_006_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=923; creation-date="Tue, 16 Oct 2012 13:25:47 GMT"; modification-date="Tue, 16 Oct 2012 13:25:47 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABIAAAAUCAYAAACAl21KAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAMbSURBVDjL lZRrSBRRFMfHHmYR5oMoelhBH6IoSEQiEsYiM3p8kCKkJwY96INpVL62NkqzoKcRFZUfCiqF3mWg lQjVlmhiStHD8jWb7e7M7I6zMzuzM/+Os1BtGW0Dh+FyD797zv/872UQwae9qIe4ewH43Hgo9ScG S5nK/Auiv2mBfLUMYulsePKGQ7q0DIbQ9X8gzfESUulBaC31UB3HIBRGQyhJgPbufuSgYC8HYeMm yJWV1tqQuuE9nARx33hoH2ojB0nlR+FOT0ewszMEdr+Ht3wKpIoUGGJnZKBgTy9cKSkQVq+C6feH tGq/A/FAApQ6O2AGIwMpN6rhjIuHkJMDM2AQ2Q+5aiMJnQGD/xz51HwFReCGDoO4ZTvMfgla6xX0 X8mC/uXF35QYHCRsyEEPw4Bfvw5a0zUoDYdI/OZfMswIQWs3oZdArow0qC+rYaqusH3Dx0H/WAdT dv8dZEifIWSvsCrqmzMLakPDn8NwtqL/cgYCry4OAjKC0DueQm06DW/+BnDRMXDGxkIqKyNnauFG ffsAQtEw+B/s+g1kaOTe65BvbkbwayO0Zw44x0+w2nNnZpDYLT/P8/ZQNSvB7xoC9fmpcJDWWgVf RTLUxlCppqKCX7rcas+ZmABfkY0AMk2wF/5bW+HZwcB3kozpav8J0jueQDqTBvHgOOjdjh8nq3cf wTl2sgX7NmsmpPMlkK9lgc9j6L6NoUMvhE9NupAGYV8ihL3RUB7tIcN1wNQVGKoMcfNaOJOi4FoS RQCKAgbioQRq6ciA18NBQmEUrNhDSSUxkC4uJhHzIT/Mo/JTSQvaK2Ks8GyjnNz50JsaSSwzHOQ7 mwrBNjpU8m4y4U6KXMbSYeAvUBXC/jh41oykVkmz2Di4Fy6CdLQcgcd10NvagE+fSKMuB/x38+lC ToJQTO9NMV0N2yh4SyfCd2oe/Le3IPD6KuRzFfCkL0HflGngRoSs8W1uMnx2O5SaGmtqrM41s1Jl Jsvb4ylGs3zZZGutNBxnIXHsQM5AKPdqWD57PctNn8Fy8WNZbup0VrLZWNTWxnwH0IGi/mC19kkA AAAASUVORK5CYII= --_006_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=4149; creation-date="Tue, 16 Oct 2012 13:25:47 GMT"; modification-date="Tue, 16 Oct 2012 13:25:47 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMoAAAEhCAYAAAA+kT9dAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAA+1SURBVHja 7d1PaBT9HcfxhRniOOOYNX80SpCAF8FLwEsOHgIiPAeRXCpeKkEoinhIReQRfVDxKSlYSamgUBH7 nDwITXsQe2pulZ726K2hh1Z4rI3Rx0dbD/PMZ3bWnZ3dnd0xye7szPsHX9Ds/5nv6/dvfjNTunnz ZokgiOQo3g8ulab8mG0R837cCGO+zXOmSBqgDGril8MknlOSl8vl78bGxiqu677y/+/FY3x8/N3h w4fX4nHq1Kl3169f9xT6d6vn6LWt3lOfpc8cGRl5EoM2QZIBpR+twI1t27bdVlKOjo6+UJJu3779 o5L42LFjb5Tk9+/f91ZWVrzV1VWvV0Wfpc989OhRA7Th4eH3+o4+3n/pO+/YseNeCEmop0lAoGwU xowfC35y/dVxnPVaK6AkXFxcDJLy+fPn3qCUFy9eBN95aWkpgCTUBw4ceOOj/9H/bc9DPLMkJFA6 dZ2+UrKo1lUNfOjQobULFy58XF5e9l6+fDkwINKWtbU179mzZwEeVQT67Wopw5Znjq5bwaEoCTSW 2LVr1z/UdTpy5EjQWqjWLXpRS6mWR62Oum4a/4Rjn1OqVEjaHENRzagBrrpSpml+UhJoLFGpVAoP o5vxj8Y+J06cWFelEnbVzjEDlyMoqgWFQzWjBrjqSn348IHs30BRV+3MmTPvNW4Lu6qaYbNI5gGD 4peD6lZpEK5aUDgoW1PUVVUF5I9p3obdsxmSOuNQNGuj1mNycnJd3ao8D8KzVjQpoO6ZJkHCVmaO 5M4YFO0UzdRo1obWIxutjMaA4QHXeZK8z1B0wEy1l3bKIB3TKErRJIC6ZTrYqel3kr3HUDSDpf6w DpgxnZv9ooOdmn4PZ8sOkvQ9gOIPGn+xZ8+e/6g/TBmsotmyqamp134Lc4PE3yIoakVUI508efKN Bo6UwSyamr948eIP4To5WpfNhKIpR7UiqpEo+SgaU6p12blz589AsAlQ/A358+np6Ve0IvlsXY4e Pfrab12uAGEDUPbu3fur48eP/5cj6fku586dW5+YmHgMhi+AIiTagKRRMcrt27d/BEtKKOpuqSUh fYpVFhYW3qiCBEUXULQMZWZm5hXdrWIWVZCqKIGRAEUrUEdGRl728hRaSraKJm00w8kJYwlQdu/e /ZsrV668I12KXR4+fPh/Pxf+CI4WUFSDjI6OrtPloqhoeRIXv2gBxbKsa5cuXUIJJSh37tz55HfD fw+QGBSdu85puZRa0blEw8PDrzlzsmGiqzShU3VJD0q06CQwzphshDKjjUJqUKJFp3HrmgcgqUOZ 1wk+pAYlWnT5KF1rDSQFguLalmdErxdsWJ7juMFjthm/lrDp2eFjteIMGcFjxpADlAJDmdX57rlF Ypn+Djc8y3YbEr+W9IISBVBFUcXiOrZnBkBszzKKBUWVJ+fcN0KZGhsby2WLUkt003LbPicOpdVr XMcpHJTwEq+zIIlMD+uKHXlculLtcjV3pRKhBK9pbIGKBkVLWRzHecv0cPMBx2+vXbv2KXdQgm5X OijBmCUyhikiFF0ToVwuPwFI8xKWXHa/uoVSajPQLyoUul0JiyK1ZEFLF3IF5QvGKK3fpzhQdBFD XfETHO2X2Zf9DfR93i6FWp3F6n7Wq8hQtCh27969a1wpPwGKIq9nN9aOg7Q7jtIOQK1Fit+zMa9g zp49u87FJrqAotDpoDotNNdVJ6Wp3L17l/Pm00BR7Nu3788PHjxgoWRBytOnT/+3Z8+evwMiJRTN n/u1y1/8f78ljfJdVCHu37//bxwz+QIokW7YvdOnT6+RTvksly9fXlPvASQbhKIYHx//pZbh66ro lHwUzWzqCveTk5O/BcEmQQm7YjNjY2P/vHXrFqcLD3jRxSP8yu977pmyBVBq45bR0dHfqXXhtOHB K1rLp1ZEV1jhNtxbCCXauugce50BxzXAsl+0wPH8+fM/hLeqoxXpFZQImFO6YJ52AmCyCeTq1asf /EptzbKsSyR7n6DUumPaCaqtdKIPXbL+F1Vaqrx0S+3h4eFf083KAJQYmnl1yXTz08ePH5OxPS66 0ZO6w6q0VHkx5ZtRKBEwc2NjY091CaQLFy58ZFp5a1uPb7755tP4+Pi78GamXDVlUKBEwEz4saDb N+sSnYuLix5oNgfH0tJScM5I2Hp8y2rfAYYSQzO9bdu220IzOTm5rpaGe9N3XzT2U0WjCkc4/PHH PU6syiGUGJqDamnCO9MGNePly5c/6YShvJ0L8yVF54SsrKwElwvScQ/TND9p7KeKhgtnFwhKCziz fnyts+ocx1lXf1szaPfv3/eKMIum7qjOUT9z5sx7tRiC4W+Liq6ppeMeDMqB0g7OlGbQ/G7ad6pJ lThqdVTDqvuh2nYQu21Cr++u8UWttdi+fftHdUdHRkae+L/5HC0GUDZ0rCZsdW6o+6HattZtU6IJ kaaklXxqhZSM/Zg00CBbn63WQd9FU7X6bpr903cVen33cHxRay04xgGUniAqh4jmlHxqhZSMqqWj p+6qO6ekjcb09PSb48ePv1dSJ4W6gfHXKvSe0c/QIFufHbYOgnAq/G7c5g0oAwNqKkzaaPzBjz+F SZ0U8y1eO8uULFCKgucGF6EmgAIUAihAIYDSKyhLOvBJEhBASYbyiPt/EEABCgEUoBBA6RWUx5y/ QQClM5QVlqoTQAEKARSgEEABCgGUDEHRUv2DJAEBlGQoq6wAJoACFAIoQCGA0isoa5yKSwClMxSP BCCAAhQCKEAhgAIUAigZQaKrsqySAARQgEIABSgEUIBCACUjUGb8eE4CEEBJhqJLoq6QAARQgEIA BSgEUHoBRfcmeUYCEEBJhqJbOTwiAQigAIUAClCInEPxSyV6S7eCRYWkA0q3UPp+h17dmLQft+Zm xTJQBgpKvwpQgAIUoAAFKEABClCAQgAFKARQgEIABSgEUIBCAGUzobi25RnRo9uG5TmO67mO41lG 89Fv03IbXm+b1b8bQ07D350hwyuZduJn114bf0+gACVTUFzL9JPL8CzbbUhwJX0NShRA9fmNf1Oy G4aPomR6tuN2DcV1bM/0P9s0O4MCClD6BqWaqO1r81ZQ6ljqKAIoQ3a19YkkfEcoeh+1XkGL1ogM KEDJDpQOCdoWSgxYFYoTvl+9deoE5fPr2nwOUICSDSixlmGjUD6POcIxThKUlqjC1wEFKLmHUntM /0+CEocRhwMUoOR0jOI0PW61gdJuNq3VzBlQgJKJWa+gZk8z6xVOJTfNekWfE4XQCkqLmbb6d9nY oB4oQNkSKPUE7fY4SnOCx6FEQbWCEoxjWrY0yS0cUIDSVyh5KkABClCAAhSgAAUoQAEKARSgEEAB CgEUoBBAAQoBFKAABShAAQpQgAIUAihAIYACFAIoQCGAAhQCKLEol8tFvduWp99O0gFlMH5wqbQS Sd6PfsyRCARQkqH8249lP1bDG6BaJAUBlGYoq+HfpnSX4BDMDT/KJAcBlBiUyGMTIZSXfiwJEElC ACUGJfIcy4+FsIVRSzNNsgAFKMnP19ilEr7uK5IGKEBJft2sH89CNPMkD1CAkvz66cjAf4GBP1CA kvw+U+GAX2AWNRFAQgEFKO3fr+zH15GB/xSJBRSgtH9fKxz4r4YHMWdJMKAAJfkz5sLPec4SGaAA pfNnzbBEBihASTfwZ4kMUIDS5WezRAYoQEk58GeJDFCAkuL7sEQGKEBJ8b1YIgMUoKT4fiyRAQpQ UnxPlsgABSgpvi9LZIAClBTfmyUyQAFKyt/AEhmgACXFb2GJDFCAknLgzxIZoACly9/GEhmgACXl wJ8lMkABSorfyxIZoAAlxe9miQxQgJLi97NEBihASbEdWCIDFKCk2B4skQEKUFJsF5bIAAUoKbcR S2SAApQU24olMkABSsqBf6GXyAAFCGm2XWGXyAAFAF868C/UEhmgkPgb3Z6FWCIDFJJ9s7ZrrpfI AIUk3+ztm8slMkAhubdqO+dqiQxQSOqt3t65WCLTjw1XiSRq0aIyYEnOvuojFK+oRb99wKBsyXZY Xl72KpXKQO0roACFfQUUoLCvgAIU9hVQgAIUoLDxgQIUNj5QgMLGBwpQ2PhAYV8NKBTXtjwjesTU sDzHcT3XcTzLaD6ialpuw+tts/p3Y8hp+LszZHgl027+vJbva3q24wJlIPZV8/vmHoprmf4XNjzL dhs2mjZkbSNFN2r1+Y1/08Y3DKMp2Ttt/Np7fN4ZLZ4LlGztq3bvm2sormN7ZkLt0Goj1TdUfUMH G3/Ibkr2NBs/eG5YOwIl2/uq1fvmG0rQjLf/sW03UmynVTe+E75fvcZL26JstIbKNZSM7Ktu4eYL SodaIe3Gr/271jKk6/c2dimAkq19BZRN3vi1x/T/9P3ejWMBytbvq+JB2dR+r9P0uJUGyiZs+FxD ydC+6gZurqCoBDVJmpmUcHqyaSalIekjXStalPztqxbvm3so9R3Q7dx8czLHN350Y/Z7bj5vx1Gy sa+2ZjzJ0d4eFo7MD+6+YuMDhX0FFKCwr4ACFPYVUIACFKCw8YECFDY+UIDCxgcKUNj4QGFfAQUo 7CugAIV9BRSgAAUoQAEKUNj4QAEKGx8oQNmiKJfLRb2Dk6ffPkhQ2Fd9hJKl2rKov534gnwBCkEA BSgEUIBCAAUoBFCAQgAFKARQgEIABSgEARSgEEABCgEUoBBAAQoBFKAQQAEKARSgEARQgEIABSgE UIBCAAUoBFCAQgAFKARQgEIABSgEARSgEEABCgEUoBBAAQoBFKAQQAEKARSgEARQgEIABSgEUIBC AAUoBFCAQgAFKARQgEIQQCEBCKAAhQAKUAigAIUAClAIoACFAApQCKAAhSCAAhRisKD4paIkLWhU SDqgdF2TF7XQigEFKEABClCAAhSgAIUAClAIoACFAApQCKAAhQAKUIAClB5DcW3LM6JHtw3LcxzX cx3Hs4zmo9+m5Ta83jarfzeGnIa/O0OGVzLt1J8LFKBkDoprmX5yGZ5luw0JrqSvQYkCqD6/8W+C Yhg+ipLp2Y7bFZSkzwUKUDIFxXVsz2zRQtQfb4ZST/I6igDKkF1tfSIw2kHp9LlAAUq2oARdn8ZW oCsosUSvQnHC96u3Em2hdPhcoAAlW1BiLcNGoXwer4RjjbZQOnwuUICSeyi1x/R/oBCMUZrGKE7T 4xZjFCIvs15BrZ9m1iuc0m2a9Yo+Jzqt3GbWK+lzgQKUzEGpJ223x1Eak7sVlCiopOMo7T4XKEDJ JJQ8FaAABShAAQpQgAIUoACFAApQCKAAhQAKUAigAIUAClCAAhSgAAUoQAEKARSgEEABCgEUoBBA AQoBlFiUy+Wi3m3L028n6YBCEEAhiCLHT1hJaJfBluQjAAAAAElFTkSuQmCC --_006_2779C9F0771F974CAD742BAE6D9904FE55379360DAPHNISofficehd_-- From anne.marrec@orange.com Tue Oct 16 07:00:15 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 0282C21F8868; Tue, 16 Oct 2012 07:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.668 X-Spam-Level: X-Spam-Status: No, score=-0.668 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, 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 0afPmmV3WVUa; Tue, 16 Oct 2012 07:00:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id E88C221F885F; Tue, 16 Oct 2012 07:00:02 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 4EBE022C56F; Tue, 16 Oct 2012 16:00:01 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 296D64C06E; Tue, 16 Oct 2012 16:00:01 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 16 Oct 2012 16:00:00 +0200 From: To: Jan Seedorf , "cdni-footprint@ietf.org" Thread-Topic: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call' Thread-Index: Ac2q36xlryg5CtK4SEe1SaSbbvQPIAAwQPPwAAFKPBA= Date: Tue, 16 Oct 2012 14:00:00 +0000 Message-ID: <17306_1350396001_507D6861_17306_3179_1_E5E1F88FBF39A84689D4A4791AE362B901FD11@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <28062_1350310593_507C1AC1_28062_2925_3_E5E1F88FBF39A84689D4A4791AE362B901FA4D@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2779C9F0771F974CAD742BAE6D9904FE55379360@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE55379360@DAPHNIS.office.hd> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/related; boundary="_006_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.16.125538 Cc: "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI 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: Tue, 16 Oct 2012 14:00:15 -0000 --_006_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_ Content-Type: multipart/alternative; boundary="_000_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_" --_000_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable De : Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] Envoy=E9 : mardi 16 octobre 2012 15:26 =C0 : MARREC Anne OLNC/OLN; cdni-footprint@ietf.org Cc : cdni@ietf.org Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabiliti= es Design Team Call' Hi Anne and Emile, Thanks for sharing this use case and the detailed examples. It is all clear= to me, and I think good input to our discussions. Two quick comments (we can discuss more in the call today): - According to your example, "capabilities_updates" must not only = include "operational" or "non-operational", but probably "partially-operati= onal" plus some specification what partially means; [AM] "partially_operationnel" means thet the "service" is not anymore suppo= rted by the dCDN as it was originally specified - What about the case where capabilities updates may contain a ref= erral to a given footprint, as we have discussed, e.g. the "partially-opera= tional" update from B to A shall indicate that B can only serve RTMP in som= e parts of Europe? Do you agree to this scenario and that it should be supp= orted? [AM] Yes, this scenario should be supported... more thinks are necessary to= describe how the modified parameter have to be specified - Jan From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.org] On Behalf Of anne.marrec@orange= .com Sent: Monday, October 15, 2012 4:17 PM To: cdni-footprint@ietf.org Cc: cdni@ietf.org Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities = Design Team Call' Hi all, We propose the following use case Anne & Emile Use case for Request routing =AB footprint & capabilities =BB Figure 1 shows the context of CDN interconnection used to illustrate the us= e case "footprint & capabilities". An example of the CDNI interface Request= Routing/footprint&capabilities exchanges between CDN A and CDN B will be d= etailed. [cid:image001.png@01CDABB7.3378C4D0] I) Use case assumptions: CP demand example: =B7 A given CP1 wishes to delegate the delivery of its content to C= DNA. Most of CP1 client are from "France" but wants that client all over th= e world be also delivered through a CDN. Its contents are two types : o content delivers in HTTP o and content delivers in RTMP CP1 describes its content as per class of request, footprint and capabiliti= es parameters. Example of CP1's "service" demand for the use case: "Class of request": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint" : geo =3D world" "quality/capabilities": maxDeliveryStartLatency =3D 500 CDN interconnection negotiations phase: CDN A capabilities compared to CP1 demand are the following: "Class of request ": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint" : Geo=3D "france" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN A capabilities are not enough compared to CP1 demand (limited to "footp= rint/geo=3D france). CDN A already has an agreement with a global CDN (CDN = D) to deliver any content to "world" with url_signing=3D"bb" ("service_ad" = compatible with CP1 demand) but the price is very high. Beside, CDN A operator is also aware that another CDN, CDN B, has the possi= bility to deliver content to "Europe" with a lower price than CDN D. 1) CDN A notes the CP1 demand 2) CDN A contacts CDN B operator and demand CDN B capabilities compared to = CP1 demand. 3) CDN B notes the CDN A demand and verify if it can manage the CDNA demand. CDN B capabilities compared to CDN A demand: "Class of request ": "URI_class": http://cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN B owns capabilities are not enough compared to CDN A demand (limited to= footprint/geo=3D"europe" and protocol=3DHTTP). But CDN B operator already has an agreement with CDN C to deliver any conte= nt in RTMP to "Europe": "service_bc": "Class of request ": "URI_class": rtmp://cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN B is able to satisfy the CDN A demand for "footprint/geo=3DEurope" when= it delegates content delivered in RTMP to CDN C. 4) CDN B announces its capabilities to CDN A limited to "Europe" compared = to CDN A demand "Class of request": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint": Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 5) CDN A is ok and an agreement is concluded between CDNA and CAN B operato= rs for the following service: "service_ab": "Class of request ": "URI_class": *//cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 [ed.note] This CDN interconnection negotiation phase is out of scope of IET= F CDNI WG. In this example, potential dCDN capabilities are known by uCDN t= hanks to "relationship" or already concluded agreement. One can imagine ano= ther way for the uCDN to know potential dCDN capabilities: potential dCDN c= apabilities automatic advertisement directly to all potential uCDN or throu= gh a "CDN capability portal" accessible to all CDNs. II) Use case: II-1) CDN A- CDN B Interconnection initialization phase CDN A - CDN B interconnection initialization Parameters needed to initialize CDNI interfaces between CDN A and CDN B (re= quest Routing, metadata and logging) for the agreed "service" are exchanged= via the control interface. These parameters will be used to configure CDN = A and CDN B. Among those, the following parameters are needed to initialize the Request = Routing interface accordingly to the agreed "service_ab": Service_id : "service_ab" { "Class of request ": { "URI_class": *//cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" } "quality/capabilities" : maxDeliveryStartLatency =3D 500 } CDN A - CDN B Request Routing/footprint&capabilities Notification Once CDN A and CDN B are configured and operational, CDN B (dCDN) advertize= s CDN A (uCDN) with request routing information via the Request Routing/foo= tprint and capabilities interface. CDN A (dCDN) sends a Request Routing information notification to CDN B (uCD= N). This notification includes the following parameters: Service : { Service_id =3D service_ab Status =3D operational } After CDN A has received this Request routing information notification, an = example of its selection algorithm could be as following (as an example and= for information only) If the End-user request of content matches the class of request "*//cdn.cp1= .com/video/*? url_signing=3D"bb"&*" And { If the IP source address belongs to the footprint/geo=3D"France" then, the delivery of the requested content is done by the CDN A itse= lf else { if the IP source address belongs to the footprint/geo=3D"Europe" then, the = delivery of the requested content is delegated to CDN B (which will delegat= e it to CDN C if protocol =3D "RTMP") else { if the IP source address belongs to the footprint/geo=3D"World" then, the d= elivery of the requested content is delegated to CDN D } } II-2) Request routing information modification A problem occurs on CDN C so that it is not able to deliver anymore content= using RTMP. CDN A must now selects CDN D for the delivery of CP1's content in RTMP for = client other than in France. Request Routing/footprint&capabilities Notifications CDN C - CDN B Request Routing/footprint&capabilities Notification CDN C will then send a request routing information notification to CDN B This notification includes the following parameters: Service : { Service_id =3D service_bc Status =3D not_operational } CDN A - CDN B Request Routing/footprint&capabilities Notification CDN B will then send a request routing information notification to CDN A This notification includes the following parameters: Service : { Service_id =3D service_ab Status =3D partially_operational Modified_parameters : { Class of request/URI_class: http//cdn.cp1.com/video/*? url_signing=3D"bb"&* } } After CDN A has received this Request routing information notification, an = example of its modified selection algorithm is presented (as an example and= for information only) If the End-user request of content matches the class of request "*//cdn.cp1= .com/video/*? url_signing=3D"bb"&*" and { If the IP source address belongs to the footprint/geo=3D"France" then, the delivery of the requested content is done by the CDN A itse= lf else { if the IP source address belongs to the footprint/geo=3D"Europe" and the En= d-user request of content matches the class of request "http//*?*&*" then, the delivery of the requested content is delegated to CDN B else { if the IP source address belongs to the footprint/geo=3D"World" then, the d= elivery of the requested content is delegated to CDN D } } [cid:image002.png@01CDABB7.3378C4D0] Anne MARREC FT/ OLNC/ OLN/ CNC/ IDA/ CDS t=E9l. +33 2 96 05 18 71 anne.marrec@orange.com [cid:image003.png@01CDABB7.3378C4D0] ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. --_000_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

De : Jan = Seedorf [mailto:Jan.Seedorf@neclab.eu]
Envoy=E9 : mardi 16 octobre 2012 15:26
=C0 : MARREC Anne OLNC/OLN; cdni-footprint@ietf.org
Cc : cdni@ietf.org
Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprin= t/Capabilities Design Team Call'

 

Hi Anne= and Emile,

&n= bsp;

Thanks = for sharing this use case and the detailed examples. It is all clear to me,= and I think good input to our discussions.

&n= bsp;

Two qui= ck comments (we can discuss more in the call today):

- &= nbsp;        According to your example, “capabilities_updates” must no= t only include “operational” or “non-operational”, = but probably “partially-operational” plus some specification what partially means;

[= AM] “partially_operationnel” means thet the “service̶= 1; is not anymore supported by the dCDN as it was originally specified

- &= nbsp;        What about the case where capabilities updates may contain a referral= to a given footprint, as we have discussed, e.g. the “partially-oper= ational” update from B to A shall indicate that B can only serve RTMP in some parts= of Europe? Do you agree to this scenario and that it should be supported?<= o:p>

[= AM] Yes, this scenario should be supported… more thinks are necessary= to describe how the modified parameter have to be specified

&n= bsp;

- &= nbsp;        Jan

&n= bsp;

&n= bsp;

From: cdni-footprint-bounces@i= etf.org [mailto:cdni= -footprint-bounces@ietf.org] On Behalf Of anne.marrec@o= range.com
Sent: Monday, October 15, 2012 4:17 PM
To: cdni-footprint@ietf.o= rg
Cc: cdni@ietf.org
Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabi= lities Design Team Call'

 

Hi all,

 

We propose the following use ca= se

 

Anne & Emile

 

 

Use case for Request rout= ing =AB footprint & capabilities =BB

 

Figure 1 shows the context of C= DN interconnection used to illustrate the use case “footprint & c= apabilities”. An example of the CDNI interface Request Routing/footpr= int&capabilities exchanges between CDN A and CDN B will be detailed.

 

 
 = ;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


I)  &nbs= p;           Use case assumptions:

 

CP demand example:

=B7         A given CP1 wishes to delegate the delivery of its content to CDNA. Most = of CP1 client are from “France” but wants that client all over = the world be also delivered through a CDN. Its contents are two types :

o    content delivers in HTTP

o    and content delivers in RTMP

CP= 1 describes its content as per class of request, footprint and capabilities= parameters.

Ex= ample of CP1’s “service” demand for the use case:

&#= 8220;Class of request”:

&= #8220;URI_class”:

*//cdn.cp1.com/video/*?url_signing=3D”bb”= &*

&= quot;footprint" :

g= eo =3D world”

&#= 8220;quality/capabilities”:

&= nbsp;           &nbs= p;  maxDeliveryStartLatency =3D 500

 

CDN interconnection negotiat= ions phase:

 

CD= N A capabilities compared to CP1 demand are the following:

&#= 8220;Class of request “:

&= #8220;URI_class”:

*//cdn.cp1.com/video/*?url_signing=3D”bb”= &*

&= #8220;footprint” :

Geo=3D “france”

&#= 8220;quality/capabilities” :

&= nbsp;           &nbs= p;  maxDeliveryStartLatency =3D 500

 

 

CD= N A capabilities are not enough compared to CP1 demand (limited to “f= ootprint/geo=3D france). CDN A already has an agreement with a global CDN (= CDN D) to deliver any content to “world” with url_signing=3D”bb” (“service_ad” compatible with C= P1 demand) but the price is very high.

Be= side, CDN A operator is also aware that another CDN, CDN B, has the possibi= lity to deliver content to “Europe” with a lower price than CDN= D.

 

     &= nbsp;          1) CDN A notes = the CP1 demand

2)= CDN A contacts CDN B operator and demand CDN B capabilities compared to CP= 1 demand.

3)= CDN B notes the CDN A demand and verify if it can manage the CDNA demand.<= o:p>

&n= bsp;            = ;  

CD= N B capabilities compared to CDN A demand:

&#= 8220;Class of request “:

&= #8220;URI_class”:

http://cdn.cp1.com/video/*= ? url_signing=3D”bb&#= 8221;&*

&= #8220;footprint” :

G= eo=3D “Europe”

&#= 8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

 

CD= N B owns capabilities are not enough compared to CDN A demand (limited to f= ootprint/geo=3D”europe” and protocol=3DHTTP).

Bu= t CDN B operator already has an agreement with CDN C to deliver any content= in RTMP to “Europe”:

&#= 8220;service_bc”:

&= #8220;Class of request “:

&= #8220;URI_class”:

rtmp://cdn.cp1.com/video/*= ? url_signing=3D”bb&#= 8221;&*

&= #8220;footprint” :

G= eo=3D “Europe”

&= #8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

CD= N B is able to satisfy the CDN A demand for “footprint/geo=3DEurope&#= 8221; when it delegates content delivered in RTMP to CDN C.

<= o:p> 

4)= CDN B announces its capabilities to CDN A limited to “Europe”&= nbsp; compared to CDN A demand

 

&#= 8220;Class of request“:

&= #8220;URI_class”:

*//cdn.cp1.com/video/*?url_signing=3D”bb”= &*

&= #8220;footprint”:

Geo=3D “Europe”

&#= 8220;quality/capabilities” :

&n= bsp;            = ;   maxDeliveryStartLatency =3D 500

 

5)= CDN A is ok and an agreement is concluded between CDNA and CAN B operators= for the following service:

&#= 8220;service_ab”:

&= #8220;Class of request “:

&= #8220;URI_class”:

*//cdn.cp1.com/video/*? url_signing=3D”bb”= ;&*

&= #8220;footprint” :

G= eo=3D “Europe”

&= #8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

<= o:p> 

<= o:p> 

[e= d.note] This CDN interconnection negotiation phase is out of scope of IETF = CDNI WG. In this example, potential dCDN capabilities are known by uCDN tha= nks to “relationship” or already concluded agreement. One can imagine another way for the uCDN to know potential dCDN= capabilities: potential dCDN capabilities automatic advertisement directly= to all potential uCDN or through a “CDN capability portal” acc= essible to all CDNs.

 

 

II)  &nb= sp;         Use case:

 

     &= nbsp;          II-1) CDN A-= CDN B Interconnection initialization phase

 

 

CDN A - CDN B interconnection initialization

 

Pa= rameters needed to initialize CDNI interfaces between CDN A and CDN B (requ= est Routing, metadata and logging) for the agreed “service” are= exchanged via the control interface. These parameters will be used to configure CDN A = and CDN B.

Am= ong those, the following parameters are needed to initialize the Request Ro= uting interface accordingly to the agreed “service_ab”:

 

Se= rvice_id : “service_ab”

&n= bsp;            = ;            &n= bsp;     {

&= #8220;Class of request “:

&= nbsp;           &nbs= p;  {

&= #8220;URI_class”:

*//cdn.cp1.com/video/*? url_signing=3D”bb”= ;&*

&= #8220;footprint” :

G= eo=3D “Europe”

}=

&= #8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

}=

 

CDN A - CDN B Request Routing/footprint&capabilities Notification

 

On= ce CDN A and CDN B are configured and operational, CDN B (dCDN) advertizes = CDN A (uCDN) with request routing information via the Request Routing/footp= rint and capabilities interface.

 

CDN A (dCDN) sends a Request Routing information notification to CDN B (uC= DN). This notification includes the following parameters:=

Service :

      { 

          Service_id =3D= service_ab

           Status =3D op= erational

     }

 

After CDN A has received this R= equest routing information notification, an example of its selection algori= thm could be as following (as an example and for information only) &nb= sp;             = ;            &n= bsp;            = ; 

 

If= the End-user request of content matches the class of request “*//cdn.cp1.com/video/*? url_signing=3D”bb”&*”

An= d

{<= o:p>

If=   the IP source address belongs to the footprint/geo=3D”France”

&n= bsp;     then, the delivery of the requested content is= done by the CDN A itself

&n= bsp;     else {

i= f the IP source address belongs to the footprint/geo=3D”Europe” then, the delivery of the reque= sted content is delegated to CDN B (which will delegate it to CDN C if prot= ocol =3D “RTMP”)

e= lse {

<= o:p> 

i= f the IP source address belongs to the footprint/geo=3D”World” then, the delivery of the reques= ted content is delegated to CDN D

 

         &nb= sp;                     }

&n= bsp;       }

 

     &= nbsp;          II-2) Reques= t routing information modification

 

A problem occurs on CDN C so th= at it is not able to deliver anymore content using RTMP.<= /p>

CDN A must now selects CDN D fo= r the delivery of CP1’s content in RTMP for client other than in Fran= ce.

 

Request Routing/footprint&am= p;capabilities Notifications

 

CDN C - CDN B Request Routing/footprint&capabilities Notification

 

CD= N C will then send a request routing information notification to CDN B=

This notification includes the following parameters:=

Service :

      { 

          Service_id =3D= service_bc

           Status =3D no= t_operational

     }

 

CDN A - CDN B Request Routing/footprint&capabilities Notification

 

CD= N B will then send a request routing information notification to CDN A=

This notification includes the following parameters:=

Service :

      { 

          Service_id =3D= service_ab

           Status =3D pa= rtially_operational

          Modified_parameters= :

            &n= bsp;            = ;             {=

Class of request/URI_class:

http//cdn.cp1.com/video/*<= span lang=3D"EN-US" style=3D"font-size:10.0pt">? url_signing=3D”bb= 221;&*

}

     }

 

 

After CDN A has received this R= equest routing information notification, an example of its modified selection algorithm is presented (as an example and for inf= ormation only)           =             &nb= sp;            =   

 

If= the End-user request of content matches the class of request “*//cdn.cp1.com/video/*? url_signing=3D”bb”&*”

an= d

{<= o:p>

If=   the IP source address belongs to the footprint/geo=3D”France”

&n= bsp;     then, the delivery of the requested content is= done by the CDN A itself

&n= bsp;     else {

i= f the IP source address belongs to the footprint/geo=3D”Europe” and the End-user request of = content matches the class of request “http//*?*&*̶= 1;

t= hen, the delivery of the requested content is delegated to CDN B else {

<= o:p> 

i= f the IP source address belongs to the footprint/geo=3D”World” then, the delivery of the reques= ted content is delegated to CDN D

 

         &nb= sp;                     }

&n= bsp;       }

 

 

 

 

Anne MARREC
FT/ OLNC/ OLN/ CNC/ IDA/ CDS
t=E9l. +33 2 96 05 18 71

anne.marrec@orange.com

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles 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 messag=
es electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a e=
te altere, deforme ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for me=
ssages that have been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

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.
--_000_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_-- --_006_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=236; creation-date="Tue, 16 Oct 2012 14:00:00 GMT"; modification-date="Tue, 16 Oct 2012 14:00:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMoAAAEhCAMAAAAJT89vAAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAAUElEQVR42u3BMQEAAADCoPVPbQsvoAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgIMB5SsAAbohqIUAAAAA SUVORK5CYII= --_006_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=1137; creation-date="Tue, 16 Oct 2012 14:00:00 GMT"; modification-date="Tue, 16 Oct 2012 14:00:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACgAAAAoCAYAAACM/rhtAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAPxSURBVFjD 7ZVrbBRVGIZLNCHRYAgoCYQIkgiKf7imCAgxagJiVDQR2trbsrtDI0kTihSoBRYUuRRqKReh0AIC 4d4SLm2lgtCm3G9WBbq1FipgW8AARv338A5nVsZmEX72x/z4dnbOnHO+53u/98zEEIyhrUYoFIqJ 8QA9QA/QA/QAPUAP0AP0AD1AD9AD9AA9QA/QA3x0BBR+1/+2B9jOAPoUKQY2OqC7kuB/K/r3GnTm +B+SzN9qbiDKWCR8Dty0HvDFYMh6CbL7wuTnogDa5B8rkhSJignOpkmu8QnONRLJTvIUZ437WQQs 0bVnZF+/a1875gyErZOhZCZU5MKXw1sBpiomPQvLPoBNk2D+CFX3BKS1h3mxiuGQNwamPA+z+kFh KqxNghkvK6EUmN4L5g6CnLdgnV//Y406Nsznr8L6AOSOUuKh2qObKSwkxTZOhPyxkNlbe0m53Ddh 5YcwtbsL0IZLewbKF8Pt63DzV2j+RQvf18IXoLYS7jRDWNel78L3q6CmFBpOwU/fqi2CLF8CTbVw fq+udVB/XCDdBTEAGs/D5dOaf1J7N6iwFEGr4NojWl8BdUdhzxwV1N6ommrUN4CWbuIVee8ZuL0L BaVNfz4EF76DRaqoQZuHq/V/NKR3gYJEhU+gq+Gfu/C17qs3wa1GtWoYLB8Hf1yVEh+Zoq+cg4wX 4Rt15s7vsDMTKtcI9jfNiYcT2+HPFnVpJMSJxXKfYvtmvGJLhjZVgtmvwRDd75oF12qUXBs0nNFz +WOsxjP7KOkiKJNiVevg7g1YpVZXb5QiVVLgSUEOgRv1UCSlzhYbgFFamy0LNIWhdAH8WAYt6lRx Fhz4Cg7mS9VY49GogCvGq7om2KYFaYI4p1bVKWGufNco0JIsM29fDvx9Gxa8IV9ZqvyW1JQfj22R UlLaelrPRhgFV8fJ8Evh+iUlfx12h9QlKbhDCp7YrPGLgn5Fyqmg/Hd0BjoYzwZbA9qGTe8qFTYY j9iJbl4RQJoxru2fnZ8a+YsE1SyPVRXJh/uNLVYIpFL3YXnKekoJ1eYWzclT0mydzouyS1jF1h/T /GuwQQdj8dsq/Ad5dp+sdBAOrxRgR/M2iPolsR9M6QnbVd0RHYKCZBlVpv1EihSozXP7Oye9k06w /FfymfwjsDVq73T5K0eKLtdptNTijK7mhE/tZSyxR8oVyzIVy+AvKV4YMN1YIsgDskpxtqw14MFr 7aGfumTnwCQ44XMWJDgFWM5YfKvwud5pQefVEueM2a27dNh054KUrJFiM/oYryU46yNzH/tbHHjM z5P1iG+rDZre2XSjdL5exDqIWX0ftNH6/1z3Ae2fthz3AEjkYXGbuPXAAAAAAElFTkSuQmCC --_006_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=923; creation-date="Tue, 16 Oct 2012 14:00:00 GMT"; modification-date="Tue, 16 Oct 2012 14:00:00 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABIAAAAUCAYAAACAl21KAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAMbSURBVDjL lZRrSBRRFMfHHmYR5oMoelhBH6IoSEQiEsYiM3p8kCKkJwY96INpVL62NkqzoKcRFZUfCiqF3mWg lQjVlmhiStHD8jWb7e7M7I6zMzuzM/+Os1BtGW0Dh+FyD797zv/872UQwae9qIe4ewH43Hgo9ScG S5nK/Auiv2mBfLUMYulsePKGQ7q0DIbQ9X8gzfESUulBaC31UB3HIBRGQyhJgPbufuSgYC8HYeMm yJWV1tqQuuE9nARx33hoH2ojB0nlR+FOT0ewszMEdr+Ht3wKpIoUGGJnZKBgTy9cKSkQVq+C6feH tGq/A/FAApQ6O2AGIwMpN6rhjIuHkJMDM2AQ2Q+5aiMJnQGD/xz51HwFReCGDoO4ZTvMfgla6xX0 X8mC/uXF35QYHCRsyEEPw4Bfvw5a0zUoDYdI/OZfMswIQWs3oZdArow0qC+rYaqusH3Dx0H/WAdT dv8dZEifIWSvsCrqmzMLakPDn8NwtqL/cgYCry4OAjKC0DueQm06DW/+BnDRMXDGxkIqKyNnauFG ffsAQtEw+B/s+g1kaOTe65BvbkbwayO0Zw44x0+w2nNnZpDYLT/P8/ZQNSvB7xoC9fmpcJDWWgVf RTLUxlCppqKCX7rcas+ZmABfkY0AMk2wF/5bW+HZwcB3kozpav8J0jueQDqTBvHgOOjdjh8nq3cf wTl2sgX7NmsmpPMlkK9lgc9j6L6NoUMvhE9NupAGYV8ihL3RUB7tIcN1wNQVGKoMcfNaOJOi4FoS RQCKAgbioQRq6ciA18NBQmEUrNhDSSUxkC4uJhHzIT/Mo/JTSQvaK2Ks8GyjnNz50JsaSSwzHOQ7 mwrBNjpU8m4y4U6KXMbSYeAvUBXC/jh41oykVkmz2Di4Fy6CdLQcgcd10NvagE+fSKMuB/x38+lC ToJQTO9NMV0N2yh4SyfCd2oe/Le3IPD6KuRzFfCkL0HflGngRoSs8W1uMnx2O5SaGmtqrM41s1Jl Jsvb4ylGs3zZZGutNBxnIXHsQM5AKPdqWD57PctNn8Fy8WNZbup0VrLZWNTWxnwH0IGi/mC19kkA AAAASUVORK5CYII= --_006_E5E1F88FBF39A84689D4A4791AE362B901FD11PEXCVZYM12corpora_-- From Jan.Seedorf@neclab.eu Tue Oct 16 07:07:47 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 4AF4C21F8890; Tue, 16 Oct 2012 07:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.415 X-Spam-Level: X-Spam-Status: No, score=-104.415 tagged_above=-999 required=5 tests=[AWL=1.184, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 ayylXGa+D1tp; Tue, 16 Oct 2012 07:07:46 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2C44C21F8880; Tue, 16 Oct 2012 07:07:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 3D2971021F3; Tue, 16 Oct 2012 16:07:42 +0200 (CEST) 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 s+djcm8Q+rzC; Tue, 16 Oct 2012 16:07:42 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 2312F1021EF; Tue, 16 Oct 2012 16:07:32 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 16 Oct 2012 16:07:32 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: [cdni-footprint] FW: Meeting invitation: CDNI Footprint Design Team Interim Meeting 2 Thread-Index: AQHNqtnkqfNPDRUCeUyuiEXjYuJvupe7+VSw Date: Tue, 16 Oct 2012 14:07:31 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55379455@DAPHNIS.office.hd> References: <122344879.6216.1349174178766.JavaMail.nobody@jsj6tc004.webex.com> <2779C9F0771F974CAD742BAE6D9904FE55377A86@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE55377A86@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 Cc: "cdni@ietf.org" Subject: [CDNi] FW: [cdni-footprint] FW: Meeting invitation: CDNI Footprint Design Team Interim Meeting 2 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, 16 Oct 2012 14:07:47 -0000 Meeting has started, see WebEx info below ... -----Original Message----- From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.o= rg] On Behalf Of Jan Seedorf Sent: Monday, October 15, 2012 3:34 PM To: cdni-footprint@ietf.org Cc: cdni@ietf.org Subject: [cdni-footprint] FW: Meeting invitation: CDNI Footprint Design Tea= m Interim Meeting 2 Hi all, Please find below the information for the CDNI Footprint Design Team Interi= m Meeting tomorrow. - Jan -----Original Message----- From: Stefano Previdi [mailto:messenger@webex.com]=20 Sent: Tuesday, October 02, 2012 12:36 PM To: Jan Seedorf Subject: Meeting invitation: CDNI Footprint Design Team Interim Meeting 2 Hello Jan Seedorf,=20 Stefano Previdi invites you to attend this online meeting.=20 Topic: CDNI Footprint Design Team Interim Meeting 2=20 Date: Tuesday, October 16, 2012=20 Time: 4:00 pm, Europe Summer Time (Amsterdam, GMT+02:00)=20 Meeting Number: 208 283 519=20 Meeting Password: cdni=20 -------------------------------------------------------=20 To join the online meeting (Now from mobile devices!)=20 -------------------------------------------------------=20 1. Go to https://ciscosales.webex.com/ciscosales/j.php?ED=3D206020197&UID= =3D1882410732&PW=3DNODI0ZmI1NDY2&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 To view in other time zones or languages, please click the link:=20 https://ciscosales.webex.com/ciscosales/j.php?ED=3D206020197&UID=3D18824107= 32&PW=3DNODI0ZmI1NDY2&ORT=3DMiMyMg%3D%3D=20 ----------------------------------------------------------------=20 ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes=20 ----------------------------------------------------------------=20 The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpita= s area and (866) 349-3520 for the RTP area.=20 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 -------------------------------------------------------=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 San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330=20 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117=20 India: +91.80.4350.1111 Germany: +49.619.6773.9002=20 Japan: +81.3.5763.9394 China: +86.10.8515.5666=20 -------------------------------------------------------=20 For assistance=20 -------------------------------------------------------=20 1. Go to https://ciscosales.webex.com/ciscosales/mc=20 2. On the left navigation bar, click "Support".=20 You can contact me at:=20 sprevidi@cisco.com=20 39-0651644491=20 To add this meeting to your calendar program (for example Microsoft Outlook= ), click this link:=20 https://ciscosales.webex.com/ciscosales/j.php?ED=3D206020197&UID=3D18824107= 32&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DvIVlIoZta1CkMziSHiZiRvs2ZMhnmM7RDMj= sj7BdsZc=3D&RT=3DMiMyMg%3D%3D=20 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://ciscosales.webex.com/ciscosales/systemdiagnosis.php.=20 http://www.webex.com=20 CCP:+14085256800x208283519#=20 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.=20 _______________________________________________ cdni-footprint mailing list cdni-footprint@ietf.org https://www.ietf.org/mailman/listinfo/cdni-footprint From haibin.song@huawei.com Tue Oct 16 23:25:02 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 3DA2921F8704; Tue, 16 Oct 2012 23:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.712 X-Spam-Level: X-Spam-Status: No, score=-5.712 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, 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 69KULZ3NPux9; Tue, 16 Oct 2012 23:24:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B66E421F8796; Tue, 16 Oct 2012 23:24:53 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKR27512; Wed, 17 Oct 2012 06:24:52 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 07:24:17 +0100 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 07:24:51 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Wed, 17 Oct 2012 14:24:43 +0800 From: Songhaibin To: "anne.marrec@orange.com" , Jan Seedorf , "cdni-footprint@ietf.org" Thread-Topic: [CDNi] [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call' Thread-Index: AQHNq6HXydNZUhejLEmuWW6an+F0h5e7b7AAgAGX9vA= Date: Wed, 17 Oct 2012 06:24:43 +0000 Message-ID: References: <28062_1350310593_507C1AC1_28062_2925_3_E5E1F88FBF39A84689D4A4791AE362B901FA4D@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2779C9F0771F974CAD742BAE6D9904FE55379360@DAPHNIS.office.hd> <17306_1350396001_507D6861_17306_3179_1_E5E1F88FBF39A84689D4A4791AE362B901FD11@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <17306_1350396001_507D6861_17306_3179_1_E5E1F88FBF39A84689D4A4791AE362B901FD11@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.123] Content-Type: multipart/related; boundary="_006_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI 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: Wed, 17 Oct 2012 06:25:02 -0000 --_006_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_ Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_" --_000_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Excellent use case and discussion! And I think the negotiation phase should= be in scope, which should not be left as a hole for CDNI. -Haibin From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of ann= e.marrec@orange.com Sent: Tuesday, October 16, 2012 10:00 PM To: Jan Seedorf; cdni-footprint@ietf.org Cc: cdni@ietf.org Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabi= lities Design Team Call' De : Jan Seedorf [mailto:Jan.Seedorf@neclab.eu] Envoy=E9 : mardi 16 octobre 2012 15:26 =C0 : MARREC Anne OLNC/OLN; cdni-footprint@ietf.org Cc : cdni@ietf.org Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabiliti= es Design Team Call' Hi Anne and Emile, Thanks for sharing this use case and the detailed examples. It is all clear= to me, and I think good input to our discussions. Two quick comments (we can discuss more in the call today): - According to your example, "capabilities_updates" must not only = include "operational" or "non-operational", but probably "partially-operati= onal" plus some specification what partially means; [AM] "partially_operationnel" means thet the "service" is not anymore suppo= rted by the dCDN as it was originally specified - What about the case where capabilities updates may contain a ref= erral to a given footprint, as we have discussed, e.g. the "partially-opera= tional" update from B to A shall indicate that B can only serve RTMP in som= e parts of Europe? Do you agree to this scenario and that it should be supp= orted? [AM] Yes, this scenario should be supported... more thinks are necessary to= describe how the modified parameter have to be specified - Jan From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.org] On Behalf Of anne.marrec@orange= .com Sent: Monday, October 15, 2012 4:17 PM To: cdni-footprint@ietf.org Cc: cdni@ietf.org Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities = Design Team Call' Hi all, We propose the following use case Anne & Emile Use case for Request routing =AB footprint & capabilities =BB Figure 1 shows the context of CDN interconnection used to illustrate the us= e case "footprint & capabilities". An example of the CDNI interface Request= Routing/footprint&capabilities exchanges between CDN A and CDN B will be d= etailed. [cid:image004.png@01CDAC73.25206930] I) Use case assumptions: CP demand example: =B7 A given CP1 wishes to delegate the delivery of its content to C= DNA. Most of CP1 client are from "France" but wants that client all over th= e world be also delivered through a CDN. Its contents are two types : o content delivers in HTTP o and content delivers in RTMP CP1 describes its content as per class of request, footprint and capabiliti= es parameters. Example of CP1's "service" demand for the use case: "Class of request": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint" : geo =3D world" "quality/capabilities": maxDeliveryStartLatency =3D 500 CDN interconnection negotiations phase: CDN A capabilities compared to CP1 demand are the following: "Class of request ": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint" : Geo=3D "france" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN A capabilities are not enough compared to CP1 demand (limited to "footp= rint/geo=3D france). CDN A already has an agreement with a global CDN (CDN = D) to deliver any content to "world" with url_signing=3D"bb" ("service_ad" = compatible with CP1 demand) but the price is very high. Beside, CDN A operator is also aware that another CDN, CDN B, has the possi= bility to deliver content to "Europe" with a lower price than CDN D. 1) CDN A notes the CP1 demand 2) CDN A contacts CDN B operator and demand CDN B capabilities compared to = CP1 demand. 3) CDN B notes the CDN A demand and verify if it can manage the CDNA demand= . CDN B capabilities compared to CDN A demand: "Class of request ": "URI_class": http://cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN B owns capabilities are not enough compared to CDN A demand (limited to= footprint/geo=3D"europe" and protocol=3DHTTP). But CDN B operator already has an agreement with CDN C to deliver any conte= nt in RTMP to "Europe": "service_bc": "Class of request ": "URI_class": rtmp://cdn.cp1.com/video/*? url_signing=3D"bb"&= * "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 CDN B is able to satisfy the CDN A demand for "footprint/geo=3DEurope" when= it delegates content delivered in RTMP to CDN C. 4) CDN B announces its capabilities to CDN A limited to "Europe" compared = to CDN A demand "Class of request": "URI_class": *//cdn.cp1.com/video/*?url_signing=3D"bb"&* "footprint": Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 5) CDN A is ok and an agreement is concluded between CDNA and CAN B operato= rs for the following service: "service_ab": "Class of request ": "URI_class": *//cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" "quality/capabilities" : maxDeliveryStartLatency =3D 500 [ed.note] This CDN interconnection negotiation phase is out of scope of IET= F CDNI WG. In this example, potential dCDN capabilities are known by uCDN t= hanks to "relationship" or already concluded agreement. One can imagine ano= ther way for the uCDN to know potential dCDN capabilities: potential dCDN c= apabilities automatic advertisement directly to all potential uCDN or throu= gh a "CDN capability portal" accessible to all CDNs. II) Use case: II-1) CDN A- CDN B Interconnection initialization phase CDN A - CDN B interconnection initialization Parameters needed to initialize CDNI interfaces between CDN A and CDN B (re= quest Routing, metadata and logging) for the agreed "service" are exchanged= via the control interface. These parameters will be used to configure CDN = A and CDN B. Among those, the following parameters are needed to initialize the Request = Routing interface accordingly to the agreed "service_ab": Service_id : "service_ab" { "Class of request ": { "URI_class": *//cdn.cp1.com/video/*? url_signing=3D"bb"&* "footprint" : Geo=3D "Europe" } "quality/capabilities" : maxDeliveryStartLatency =3D 500 } CDN A - CDN B Request Routing/footprint&capabilities Notification Once CDN A and CDN B are configured and operational, CDN B (dCDN) advertize= s CDN A (uCDN) with request routing information via the Request Routing/foo= tprint and capabilities interface. CDN A (dCDN) sends a Request Routing information notification to CDN B (uCD= N). This notification includes the following parameters: Service : { Service_id =3D service_ab Status =3D operational } After CDN A has received this Request routing information notification, an = example of its selection algorithm could be as following (as an example and= for information only) If the End-user request of content matches the class of request "*//cdn.cp1= .com/video/*? url_signing=3D"bb"&*" And { If the IP source address belongs to the footprint/geo=3D"France" then, the delivery of the requested content is done by the CDN A itse= lf else { if the IP source address belongs to the footprint/geo=3D"Europe" then, the = delivery of the requested content is delegated to CDN B (which will delegat= e it to CDN C if protocol =3D "RTMP") else { if the IP source address belongs to the footprint/geo=3D"World" then, the d= elivery of the requested content is delegated to CDN D } } II-2) Request routing information modification A problem occurs on CDN C so that it is not able to deliver anymore content= using RTMP. CDN A must now selects CDN D for the delivery of CP1's content in RTMP for = client other than in France. Request Routing/footprint&capabilities Notifications CDN C - CDN B Request Routing/footprint&capabilities Notification CDN C will then send a request routing information notification to CDN B This notification includes the following parameters: Service : { Service_id =3D service_bc Status =3D not_operational } CDN A - CDN B Request Routing/footprint&capabilities Notification CDN B will then send a request routing information notification to CDN A This notification includes the following parameters: Service : { Service_id =3D service_ab Status =3D partially_operational Modified_parameters : { Class of request/URI_class: http//cdn.cp1.com/video/*? url_signing=3D"bb"&* } } After CDN A has received this Request routing information notification, an = example of its modified selection algorithm is presented (as an example and= for information only) If the End-user request of content matches the class of request "*//cdn.cp1= .com/video/*? url_signing=3D"bb"&*" and { If the IP source address belongs to the footprint/geo=3D"France" then, the delivery of the requested content is done by the CDN A itse= lf else { if the IP source address belongs to the footprint/geo=3D"Europe" and the En= d-user request of content matches the class of request "http//*?*&*" then, the delivery of the requested content is delegated to CDN B else { if the IP source address belongs to the footprint/geo=3D"World" then, the d= elivery of the requested content is delegated to CDN D } } [cid:image005.png@01CDAC73.25206930] Anne MARREC FT/ OLNC/ OLN/ CNC/ IDA/ CDS t=E9l. +33 2 96 05 18 71 anne.marrec@orange.com [cid:image006.png@01CDAC73.25206930] ___________________________________________________________________________= ______________________________________________ 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. ___________________________________________________________________________= ______________________________________________ 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. --_000_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Excellent use case and discussion! And I think the negotiation ph= ase should be in scope, which should not be left as a hole for CDNI.

 

-Haibin

 

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of anne.marrec@orange.com
Sent: Tuesday, October 16, 2012 10:00 PM
To: Jan Seedorf; cdni-footprint@ietf.org
Cc: cdni@ietf.org
Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI Footprint= /Capabilities Design Team Call'

 

 = ;

 = ;

De : Jan Seedorf [mailto:Jan.Seedorf@neclab.eu]
Envoy=E9 : mardi 16 octobre 2012 15:26
=C0 : MARREC Anne OLNC/OLN; cdni-footprint@ietf.org
Cc : cdni@ietf.org
Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprin= t/Capabilities Design Team Call'

 

Hi Anne= and Emile,

&n= bsp;

Thanks = for sharing this use case and the detailed examples. It is all clear to me,= and I think good input to our discussions.

&n= bsp;

Two qui= ck comments (we can discuss more in the call today):

- &= nbsp;        According to your e= xample, “capabilities_updates” must not only include “ope= rational” or “non-operational”, but probably “parti= ally-operational” plus some specification what partially means;

[= AM] “partially_operationnel” means thet the “service̶= 1; is not anymore supported by the dCDN as it was originally specified

- &= nbsp;        What about the case= where capabilities updates may contain a referral to a given footprint, as= we have discussed, e.g. the “partially-operational” update from B to A shall indicate that B can only serve RTMP in some parts of Eur= ope? Do you agree to this scenario and that it should be supported?

[= AM] Yes, this scenario should be supported… more thinks are necessary= to describe how the modified parameter have to be specified

&n= bsp;

- &= nbsp;        Jan

&n= bsp;

&n= bsp;

From: cdni-footprint-bounces@i= etf.org [mailto:cdni= -footprint-bounces@ietf.org] On Behalf Of anne.marrec@o= range.com
Sent: Monday, October 15, 2012 4:17 PM
To: cdni-footprint@ietf.o= rg
Cc: cdni@ietf.org
Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabi= lities Design Team Call'

 

Hi all,

 

We propose the following use ca= se

 

Anne & Emile

 

 

Use case for Request rout= ing =AB footprint & capabilities =BB

 

Figure 1 shows the context of C= DN interconnection used to illustrate the use case “footprint & c= apabilities”. An example of the CDNI interface Request Routing/footpr= int&capabilities exchanges between CDN A and CDN B will be detailed.

 

 
 = ;

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


I)  &nbs= p;            &= nbsp;    Use case assu= mptions:

 

CP demand example:

=B7         A given CP1 wishes to d= elegate the delivery of its content to CDNA. Most of CP1 client are from &#= 8220;France” but wants that client all over the world be also deliver= ed through a CDN. Its contents are two types :

o    content delivers in HTT= P

o    and content delivers in= RTMP

CP= 1 describes its content as per class of request, footprint and capabilities= parameters.

Ex= ample of CP1’s “service” demand for the use case:

&#= 8220;Class of request”:

&= #8220;URI_class”:

*//cdn.cp1.com/vide= o/*?url_s= igning=3D”bb”&*

&= quot;footprint" :

g= eo =3D world”

&#= 8220;quality/capabilities”:

&= nbsp;           &nbs= p;  maxDeliveryStartLatency =3D 500

 

CDN interconnection negotiat= ions phase:

 

CD= N A capabilities compared to CP1 demand are the following:

&#= 8220;Class of request “:

&= #8220;URI_class”:

*//cdn.cp1.com/vide= o/*?url_s= igning=3D”bb”&*

&= #8220;footprint” :

Geo=3D “france”

&#= 8220;quality/capabilities” :

&= nbsp;           &nbs= p;  maxDeliveryStartLatency =3D 500

 

 

CD= N A capabilities are not enough compared to CP1 demand (limited to “f= ootprint/geo=3D france). CDN A already has an agreement with a global CDN (= CDN D) to deliver any content to “world” with url_signing=3D”bb” (“service_ad” compatible with C= P1 demand) but the price is very high.

Be= side, CDN A operator is also aware that another CDN, CDN B, has the possibi= lity to deliver content to “Europe” with a lower price than CDN= D.

 

     &= nbsp;          1) CDN A notes = the CP1 demand

2)= CDN A contacts CDN B operator and demand CDN B capabilities compared to CP= 1 demand.

3)= CDN B notes the CDN A demand and verify if it can manage the CDNA demand.<= o:p>

&n= bsp;            = ;  

CD= N B capabilities compared to CDN A demand:

&#= 8220;Class of request “:

&= #8220;URI_class”:

http://cdn.cp1.com/= video/*? = url_signing=3D”bb”&*

&= #8220;footprint” :

G= eo=3D “Europe”

&#= 8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

 

CD= N B owns capabilities are not enough compared to CDN A demand (limited to f= ootprint/geo=3D”europe” and protocol=3DHTTP).

Bu= t CDN B operator already has an agreement with CDN C to deliver any content= in RTMP to “Europe”:

&#= 8220;service_bc”:

&= #8220;Class of request “:

&= #8220;URI_class”:

rtmp://cdn.cp1.com/= video/*? = url_signing=3D”bb”&*

&= #8220;footprint” :

G= eo=3D “Europe”

&= #8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

CD= N B is able to satisfy the CDN A demand for “footprint/geo=3DEurope&#= 8221; when it delegates content delivered in RTMP to CDN C.

<= o:p> 

4)= CDN B announces its capabilities to CDN A limited to “Europe”&= nbsp; compared to CDN A demand

 

&#= 8220;Class of request“:

&= #8220;URI_class”:

*//cdn.cp1.com/vide= o/*?url_s= igning=3D”bb”&*

&= #8220;footprint”:

Geo=3D “Europe”

&#= 8220;quality/capabilities” :

&n= bsp;            = ;   maxDeliveryStartLatency =3D 500

 

5)= CDN A is ok and an agreement is concluded between CDNA and CAN B operators= for the following service:

&#= 8220;service_ab”:

&= #8220;Class of request “:

&= #8220;URI_class”:

*//cdn.cp1.com/vide= o/*? url_= signing=3D”bb”&*

&= #8220;footprint” :

G= eo=3D “Europe”

&= #8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

<= o:p> 

<= o:p> 

[e= d.note] This CDN interconnection negotiation phase is out of scope of IETF = CDNI WG. In this example, potential dCDN capabilities are known by uCDN tha= nks to “relationship” or already concluded agreement. One can imagine another way for the uCDN to know potential dCDN= capabilities: potential dCDN capabilities automatic advertisement directly= to all potential uCDN or through a “CDN capability portal” acc= essible to all CDNs.

 

 

II)  &nb= sp;            =   Use case:

 

     &= nbsp;          II-1) CDN A-= CDN B Interconnection initialization phase

 

 

CDN A - CDN B interconnection initialization

 

Pa= rameters needed to initialize CDNI interfaces between CDN A and CDN B (requ= est Routing, metadata and logging) for the agreed “service” are= exchanged via the control interface. These parameters will be used to configure CDN A = and CDN B.

Am= ong those, the following parameters are needed to initialize the Request Ro= uting interface accordingly to the agreed “service_ab”:

 

Se= rvice_id : “service_ab”

&n= bsp;            = ;            &n= bsp;     {

&= #8220;Class of request “:

&= nbsp;           &nbs= p;  {

&= #8220;URI_class”:

*//cdn.cp1.com/vide= o/*? url_= signing=3D”bb”&*

&= #8220;footprint” :

G= eo=3D “Europe”

}=

&= #8220;quality/capabilities” :

m= axDeliveryStartLatency =3D 500

}=

 

CDN A - CDN B Request Routing/footprint&capabilities Notification

 

On= ce CDN A and CDN B are configured and operational, CDN B (dCDN) advertizes = CDN A (uCDN) with request routing information via the Request Routing/footp= rint and capabilities interface.

 

CDN A (dCDN) sends a Request Routing information notification to CDN B (uC= DN). This notification includes the following parameters:=

Service :

      { 

          Service_id =3D= service_ab

           Status =3D op= erational

     }

 

After CDN A has received this R= equest routing information notification, an example of its selection algori= thm could be as following (as an example and for information only) &nb= sp;             = ;            &n= bsp;            = ; 

 

If= the End-user request of content matches the class of request “*//cdn.cp1.com/video/*<= /span>? url_signing=3D”bb”&*”

An= d

{<= o:p>

If=   the IP source address belongs to the footprint/geo=3D”France”

&n= bsp;     then, the delivery of the requested content is= done by the CDN A itself

&n= bsp;     else {

i= f the IP source address belongs to the footprint/geo=3D”Europe” then, the delivery of the reque= sted content is delegated to CDN B (which will delegate it to CDN C if prot= ocol =3D “RTMP”)

e= lse {

<= o:p> 

i= f the IP source address belongs to the footprint/geo=3D”World” then, the delivery of the reques= ted content is delegated to CDN D

 

         &nb= sp;                     }

&n= bsp;       }

 

     &= nbsp;          II-2) Reques= t routing information modification

 

A problem occurs on CDN C so th= at it is not able to deliver anymore content using RTMP.<= /p>

CDN A must now selects CDN D fo= r the delivery of CP1’s content in RTMP for client other than in Fran= ce.

 

Request Routing/footprint&am= p;capabilities Notifications

 

CDN C - CDN B Request Routing/footprint&capabilities Notification

 

CD= N C will then send a request routing information notification to CDN B=

This notification includes the following parameters:=

Service :

      { 

          Service_id =3D= service_bc

           Status =3D no= t_operational

     }

 

CDN A - CDN B Request Routing/footprint&capabilities Notification

 

CD= N B will then send a request routing information notification to CDN A=

This notification includes the following parameters:=

Service :

      { 

          Service_id =3D= service_ab

           Status =3D pa= rtially_operational

          Modified_parameters= :

            &n= bsp;            = ;             {=

Class of request/URI_class:

http//cdn.cp1.com/v= ideo/*? u= rl_signing=3D”bb”&*

}

     }

 

 

After CDN A has received this R= equest routing information notification, an example of its modified selection algorithm is presented (as an example and for inf= ormation only)           =             &nb= sp;            =   

 

If= the End-user request of content matches the class of request “*//cdn.cp1.com/video/*<= /span>? url_signing=3D”bb”&*”

an= d

{<= o:p>

If=   the IP source address belongs to the footprint/geo=3D”France”

&n= bsp;     then, the delivery of the requested content is= done by the CDN A itself

&n= bsp;     else {

i= f the IP source address belongs to the footprint/geo=3D”Europe” and the End-user request of = content matches the class of request “http//*?*&*”

t= hen, the delivery of the requested content is delegated to CDN B else {

<= o:p> 

i= f the IP source address belongs to the footprint/geo=3D”World” then, the delivery of the reques= ted content is delegated to CDN D

 

         &nb= sp;                     }

&n= bsp;       }

 

 

 

 

Anne MARREC
FT/ OLNC/ OLN/ CNC/ IDA/ CDS
t=E9l. +33 2 96 05 18 71

anne.marrec@orange.com

=

 

____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.<=
/pre>

 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>
 
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite=
 si ce message a ete altere, deforme ou falsifie. Merci.<=
/pre>

 


This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, France Telecom - Orange is=
 not liable for messages that have been modified, changed or falsified.


Thank you.
--_000_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_-- --_006_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=236; creation-date="Wed, 17 Oct 2012 06:24:42 GMT"; modification-date="Wed, 17 Oct 2012 06:24:42 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAMoAAAEhCAMAAAAJT89vAAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1p Y3Jvc29mdCBPZmZpY2V/7TVxAAAAUElEQVR42u3BMQEAAADCoPVPbQsvoAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgIMB5SsAAbohqIUAAAAA SUVORK5CYII= --_006_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=1137; creation-date="Wed, 17 Oct 2012 06:24:43 GMT"; modification-date="Wed, 17 Oct 2012 06:24:43 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACgAAAAoCAYAAACM/rhtAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAPxSURBVFjD 7ZVrbBRVGIZLNCHRYAgoCYQIkgiKf7imCAgxagJiVDQR2trbsrtDI0kTihSoBRYUuRRqKReh0AIC 4d4SLm2lgtCm3G9WBbq1FipgW8AARv338A5nVsZmEX72x/z4dnbOnHO+53u/98zEEIyhrUYoFIqJ 8QA9QA/QA/QAPUAP0AP0AD1AD9AD9AA9QA/QA3x0BBR+1/+2B9jOAPoUKQY2OqC7kuB/K/r3GnTm +B+SzN9qbiDKWCR8Dty0HvDFYMh6CbL7wuTnogDa5B8rkhSJignOpkmu8QnONRLJTvIUZ437WQQs 0bVnZF+/a1875gyErZOhZCZU5MKXw1sBpiomPQvLPoBNk2D+CFX3BKS1h3mxiuGQNwamPA+z+kFh KqxNghkvK6EUmN4L5g6CnLdgnV//Y406Nsznr8L6AOSOUuKh2qObKSwkxTZOhPyxkNlbe0m53Ddh 5YcwtbsL0IZLewbKF8Pt63DzV2j+RQvf18IXoLYS7jRDWNel78L3q6CmFBpOwU/fqi2CLF8CTbVw fq+udVB/XCDdBTEAGs/D5dOaf1J7N6iwFEGr4NojWl8BdUdhzxwV1N6ommrUN4CWbuIVee8ZuL0L BaVNfz4EF76DRaqoQZuHq/V/NKR3gYJEhU+gq+Gfu/C17qs3wa1GtWoYLB8Hf1yVEh+Zoq+cg4wX 4Rt15s7vsDMTKtcI9jfNiYcT2+HPFnVpJMSJxXKfYvtmvGJLhjZVgtmvwRDd75oF12qUXBs0nNFz +WOsxjP7KOkiKJNiVevg7g1YpVZXb5QiVVLgSUEOgRv1UCSlzhYbgFFamy0LNIWhdAH8WAYt6lRx Fhz4Cg7mS9VY49GogCvGq7om2KYFaYI4p1bVKWGufNco0JIsM29fDvx9Gxa8IV9ZqvyW1JQfj22R UlLaelrPRhgFV8fJ8Evh+iUlfx12h9QlKbhDCp7YrPGLgn5Fyqmg/Hd0BjoYzwZbA9qGTe8qFTYY j9iJbl4RQJoxru2fnZ8a+YsE1SyPVRXJh/uNLVYIpFL3YXnKekoJ1eYWzclT0mydzouyS1jF1h/T /GuwQQdj8dsq/Ad5dp+sdBAOrxRgR/M2iPolsR9M6QnbVd0RHYKCZBlVpv1EihSozXP7Oye9k06w /FfymfwjsDVq73T5K0eKLtdptNTijK7mhE/tZSyxR8oVyzIVy+AvKV4YMN1YIsgDskpxtqw14MFr 7aGfumTnwCQ44XMWJDgFWM5YfKvwud5pQefVEueM2a27dNh054KUrJFiM/oYryU46yNzH/tbHHjM z5P1iG+rDZre2XSjdL5exDqIWX0ftNH6/1z3Ae2fthz3AEjkYXGbuPXAAAAAAElFTkSuQmCC --_006_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=923; creation-date="Wed, 17 Oct 2012 06:24:43 GMT"; modification-date="Wed, 17 Oct 2012 06:24:43 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABIAAAAUCAYAAACAl21KAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAMbSURBVDjL lZRrSBRRFMfHHmYR5oMoelhBH6IoSEQiEsYiM3p8kCKkJwY96INpVL62NkqzoKcRFZUfCiqF3mWg lQjVlmhiStHD8jWb7e7M7I6zMzuzM/+Os1BtGW0Dh+FyD797zv/872UQwae9qIe4ewH43Hgo9ScG S5nK/Auiv2mBfLUMYulsePKGQ7q0DIbQ9X8gzfESUulBaC31UB3HIBRGQyhJgPbufuSgYC8HYeMm yJWV1tqQuuE9nARx33hoH2ojB0nlR+FOT0ewszMEdr+Ht3wKpIoUGGJnZKBgTy9cKSkQVq+C6feH tGq/A/FAApQ6O2AGIwMpN6rhjIuHkJMDM2AQ2Q+5aiMJnQGD/xz51HwFReCGDoO4ZTvMfgla6xX0 X8mC/uXF35QYHCRsyEEPw4Bfvw5a0zUoDYdI/OZfMswIQWs3oZdArow0qC+rYaqusH3Dx0H/WAdT dv8dZEifIWSvsCrqmzMLakPDn8NwtqL/cgYCry4OAjKC0DueQm06DW/+BnDRMXDGxkIqKyNnauFG ffsAQtEw+B/s+g1kaOTe65BvbkbwayO0Zw44x0+w2nNnZpDYLT/P8/ZQNSvB7xoC9fmpcJDWWgVf RTLUxlCppqKCX7rcas+ZmABfkY0AMk2wF/5bW+HZwcB3kozpav8J0jueQDqTBvHgOOjdjh8nq3cf wTl2sgX7NmsmpPMlkK9lgc9j6L6NoUMvhE9NupAGYV8ihL3RUB7tIcN1wNQVGKoMcfNaOJOi4FoS RQCKAgbioQRq6ciA18NBQmEUrNhDSSUxkC4uJhHzIT/Mo/JTSQvaK2Ks8GyjnNz50JsaSSwzHOQ7 mwrBNjpU8m4y4U6KXMbSYeAvUBXC/jh41oykVkmz2Di4Fy6CdLQcgcd10NvagE+fSKMuB/x38+lC ToJQTO9NMV0N2yh4SyfCd2oe/Le3IPD6KuRzFfCkL0HflGngRoSs8W1uMnx2O5SaGmtqrM41s1Jl Jsvb4ylGs3zZZGutNBxnIXHsQM5AKPdqWD57PctNn8Fy8WNZbup0VrLZWNTWxnwH0IGi/mC19kkA AAAASUVORK5CYII= --_006_E33E01DFD5BEA24B9F3F18671078951F23B3BD96szxeml534mbxchi_-- From Jan.Seedorf@neclab.eu Wed Oct 17 07:27:54 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 3352921F8578; Wed, 17 Oct 2012 07:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 HdgQs-IPIM62; Wed, 17 Oct 2012 07:27:53 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2E95721F84B6; Wed, 17 Oct 2012 07:27:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 8A56010221A; Wed, 17 Oct 2012 16:27:52 +0200 (CEST) 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 uDHt8q9N-KWL; Wed, 17 Oct 2012 16:27:52 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 6F85B1021EC; Wed, 17 Oct 2012 16:27:42 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 17 Oct 2012 16:27:42 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Notes from yesterday's Footprint/Capabilities Design Team Call and next steps Thread-Index: Ac2scnBc1MLeTmEvQzOuNWPnSaf1UA== Date: Wed, 17 Oct 2012 14:27:48 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5537AC45@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] Notes from yesterday's Footprint/Capabilities Design Team Call and next steps 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, 17 Oct 2012 14:27:54 -0000 Hi all, Thanks to all for the good discussions yesterday. Below are my notes from y= esterday's call. In summary, we agreed: -- (at least for the time being), take the use case circulated by Anne as b= asis for our discussions -- aim at having at least one more phone call before Atlanta -- next step is to start the discussion on what capabilities are mandatory = to have in advertisement for the use case posted by Anne I set up a doodle for the next call, please fill it in asap: http://www.doodle.com/8e79wgv2d9e42qnc ** -- Jan explains what was discussed last week and that the plan is to agree = on some key use cases to drive the capabilities discussion -- Anne summarizes the use case that she sent around -- question from Jon regarding what "URI_class": *//cdn.cp1.com/video/*?url= _signing=3D"bb"&* means -- Yannick explains rationale behind use case more -- Jon: does CDN-B need to have a relationship with CP-1 in the use case? Y= annick: no necessarily -- Jon: what does CDN-B need to know regarding a URI? -- Jan summarizes use cases posted by Scott on the mailing list -- Jon: we still need to find out what needs to be part of the advertisemen= t and what part of the real-time request routing -- Scott explains that his use cases are supposed to be basic building bloc= ks out of which one can build more complex use case with transitive dCDN de= legation -- discussion about "triangle aspect", i.e. CDNI loops, agreement that this= need to be considered -- agreement on use case from Anne, as it also contains the interesting use= case posted by Scott where a "local" CDN wants to (further) delegate to a = "global" dCDN ** - 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 flefauch@cisco.com Wed Oct 17 08:58:02 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 328F121F865C for ; Wed, 17 Oct 2012 08:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OsILBi5PL-+R for ; Wed, 17 Oct 2012 08:58:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFFB21F867A for ; Wed, 17 Oct 2012 08:58:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=799; q=dns/txt; s=iport; t=1350489481; x=1351699081; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=kgg2goFgkIEFhwClSKLOmtYP40PZPma5MeVLQU9KEhw=; b=dhEUFXXKXi2ufgIWFflNi2rMlJGC1jeH68aFqMvzM7eKBNhWnULteTJJ PGU0b5ip3BMpBJZV18O1SSlZ2SnMojXPLVS++N1CW3FNHoRHq1Wpxd32B lSfU7ZJbvuUU+yHiLciVynx26KiJitdTfDDCwj9xS/URhoxlLfurc7YS8 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EALHUflCtJV2b/2dsb2JhbABFwB+BCIIiAQQSASdRASoUQicEGxqHYQGaBoEroCqROmADpDSBa4Jvghc X-IronPort-AV: E=Sophos;i="4.80,601,1344211200"; d="scan'208";a="132627829" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 17 Oct 2012 15:58:01 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9HFw1SZ009047 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Oct 2012 15:58:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 10:58:00 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Agenda slot requests for CDNI at IETF 85/Atlanta Thread-Index: AQHNrIAujS4zq7pX8kyWajjzssKUiA== Date: Wed, 17 Oct 2012 15:58:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.69.156.96] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19280.000 x-tm-as-result: No--24.834400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Agenda slot requests for CDNI at IETF 85/Atlanta 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, 17 Oct 2012 15:58:02 -0000 Folks, Please send us your agenda slot requests for the upcoming CDNI WG meeting a= t IETF 85. Priority will be given to items on the charter, or to topics alr= eady discussed on the list. If you have requests for agenda slots, please send them to Rich and me by O= ctober 22, identifying the draft, the length of the desired scheduled slot = and the name of the speaker.=20 Two timeslots have been scheduled for CDNI during the Atlanta meeting: cdni Session 1 (1:30:00) Wednesday, Afternoon Session I 1300-1430 Room Name: Salon E --------------------------------------------- cdni Session 2 (1:30:00) Thursday, Afternoon Session I 1300-1500 Room Name: Grand Ballroom C --------------------------------------------- Cheers -- Francois and Rich= From ben@niven-jenkins.co.uk Wed Oct 17 15:39: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 C565921F8569; Wed, 17 Oct 2012 15:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4obAAnzWE3Py; Wed, 17 Oct 2012 15:39:30 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id C4F3421F8554; Wed, 17 Oct 2012 15:39:24 -0700 (PDT) Received: from [31.79.220.171] by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1TOcGn-00013p-Tx; Wed, 17 Oct 2012 23:39:23 +0100 References: <28062_1350310593_507C1AC1_28062_2925_3_E5E1F88FBF39A84689D4A4791AE362B901FA4D@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2779C9F0771F974CAD742BAE6D9904FE55379360@DAPHNIS.office.hd> <17306_1350396001_507D6861_17306_3179_1_E5E1F88FBF39A84689D4A4791AE362B901FD11@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: <17306_1350396001_507D6861_17306_3179_1_E5E1F88FBF39A84689D4A4791AE362B901FD11@PEXCVZYM12.corporate.adroot.infra.ftgroup> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-DA3B6287-B57F-4CA3-BFC4-9A72BF45A762 Message-Id: <9D824FE8-65F2-44EF-B2EC-5EE5F1C8E491@niven-jenkins.co.uk> X-Mailer: iPhone Mail (9B206) From: Ben Niven-Jenkins Date: Wed, 17 Oct 2012 23:39:14 +0100 To: "" X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI 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: Wed, 17 Oct 2012 22:39:31 -0000 --Apple-Mail-DA3B6287-B57F-4CA3-BFC4-9A72BF45A762 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Anne, Jan On 16 Oct 2012, at 15:00, wrote: > =20 > =20 > De : Jan Seedorf [mailto:Jan.Seedorf@neclab.eu]=20 > Envoy=C3=A9 : mardi 16 octobre 2012 15:26 > =C3=80 : MARREC Anne OLNC/OLN; cdni-footprint@ietf.org > Cc : cdni@ietf.org > Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilit= ies Design Team Call' > =20 > Hi Anne and Emile, > =20 > Thanks for sharing this use case and the detailed examples. It is all clea= r to me, and I think good input to our discussions. > =20 > Two quick comments (we can discuss more in the call today): > - According to your example, =E2=80=9Ccapabilities_updates=E2=80=9D= must not only include =E2=80=9Coperational=E2=80=9D or =E2=80=9Cnon-operati= onal=E2=80=9D, but probably =E2=80=9Cpartially-operational=E2=80=9D plus som= e specification what partially means; > [AM] =E2=80=9Cpartially_operationnel=E2=80=9D means thet the =E2=80=9Cserv= ice=E2=80=9D is not anymore supported by the dCDN as it was originally speci= fied Partially operational smells like a rat hole full of interoperability issues= to me. Why can't the dCDN just advertise what it is now capable of doing an= d the uCDN can decide whether it still wishes to use the dCDN.=20 The capability to advertise "this advertisement is different to the last one= i gave you" via a "partially operatiobal" state adds no value IMO.=20 > - What about the case where capabilities updates may contain a re= ferral to a given footprint, as we have discussed, e.g. the =E2=80=9Cpartial= ly-operational=E2=80=9D update from B to A shall indicate that B can only se= rve RTMP in some parts of Europe? Do you agree to this scenario and that it s= hould be supported? > [AM] Yes, this scenario should be supported=E2=80=A6 more thinks are neces= sary to describe how the modified parameter have to be specified Why not have the dCDN advertise the specific part of europe it can still sup= port delivery to? Ben > =20 > - Jan > =20 > =20 > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.= org] On Behalf Of anne.marrec@orange.com > Sent: Monday, October 15, 2012 4:17 PM > To: cdni-footprint@ietf.org > Cc: cdni@ietf.org > Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities= Design Team Call' > =20 > Hi all, > =20 > We propose the following use case > =20 > Anne & Emile > =20 > =20 > Use case for Request routing =C2=AB footprint & capabilities =C2=BB > =20 > Figure 1 shows the context of CDN interconnection used to illustrate the u= se case =E2=80=9Cfootprint & capabilities=E2=80=9D. An example of the CDNI i= nterface Request Routing/footprint&capabilities exchanges between CDN A and C= DN B will be detailed. > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 > I) Use case assumptions: > =20 > CP demand example: > =C2=B7 A given CP1 wishes to delegate the delivery of its content t= o CDNA. Most of CP1 client are from =E2=80=9CFrance=E2=80=9D but wants that c= lient all over the world be also delivered through a CDN. Its contents are t= wo types : > o content delivers in HTTP > o and content delivers in RTMP > CP1 describes its content as per class of request, footprint and capabilit= ies parameters. > Example of CP1=E2=80=99s =E2=80=9Cservice=E2=80=9D demand for the use case= : > =E2=80=9CClass of request=E2=80=9D: > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*?url_signing=3D=E2=80=9Dbb=E2=80=9D&* > "footprint" : > geo =3D world=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D: > maxDeliveryStartLatency =3D 500 > =20 > CDN interconnection negotiations phase: > =20 > CDN A capabilities compared to CP1 demand are the following: > =E2=80=9CClass of request =E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*?url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9Cfrance=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D : > maxDeliveryStartLatency =3D 500 > =20 > =20 > CDN A capabilities are not enough compared to CP1 demand (limited to =E2=80= =9Cfootprint/geo=3D france). CDN A already has an agreement with a global CD= N (CDN D) to deliver any content to =E2=80=9Cworld=E2=80=9D with url_signing= =3D=E2=80=9Dbb=E2=80=9D (=E2=80=9Cservice_ad=E2=80=9D compatible with CP1 de= mand) but the price is very high. > Beside, CDN A operator is also aware that another CDN, CDN B, has the poss= ibility to deliver content to =E2=80=9CEurope=E2=80=9D with a lower price th= an CDN D. > =20 > 1) CDN A notes the CP1 demand > 2) CDN A contacts CDN B operator and demand CDN B capabilities compared to= CP1 demand. > 3) CDN B notes the CDN A demand and verify if it can manage the CDNA deman= d. > =20 > CDN B capabilities compared to CDN A demand: > =E2=80=9CClass of request =E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > http://cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9CEurope=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D : > maxDeliveryStartLatency =3D 500 > =20 > CDN B owns capabilities are not enough compared to CDN A demand (limited t= o footprint/geo=3D=E2=80=9Deurope=E2=80=9D and protocol=3DHTTP). > But CDN B operator already has an agreement with CDN C to deliver any cont= ent in RTMP to =E2=80=9CEurope=E2=80=9D: > =E2=80=9Cservice_bc=E2=80=9D: > =E2=80=9CClass of request =E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > rtmp://cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9CEurope=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D :=20 > maxDeliveryStartLatency =3D 500 > CDN B is able to satisfy the CDN A demand for =E2=80=9Cfootprint/geo=3DEur= ope=E2=80=9D when it delegates content delivered in RTMP to CDN C. > =20 > 4) CDN B announces its capabilities to CDN A limited to =E2=80=9CEurope=E2= =80=9D compared to CDN A demand > =20 > =E2=80=9CClass of request=E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*?url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D: > Geo=3D =E2=80=9CEurope=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D : > maxDeliveryStartLatency =3D 500 > =20 > 5) CDN A is ok and an agreement is concluded between CDNA and CAN B operat= ors for the following service: > =E2=80=9Cservice_ab=E2=80=9D: > =E2=80=9CClass of request =E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9CEurope=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D :=20 > maxDeliveryStartLatency =3D 500 > =20 > =20 > [ed.note] This CDN interconnection negotiation phase is out of scope of IE= TF CDNI WG. In this example, potential dCDN capabilities are known by uCDN t= hanks to =E2=80=9Crelationship=E2=80=9D or already concluded agreement. One= can imagine another way for the uCDN to know potential dCDN capabilities: p= otential dCDN capabilities automatic advertisement directly to all potential= uCDN or through a =E2=80=9CCDN capability portal=E2=80=9D accessible to all= CDNs. > =20 > =20 > II) Use case: > =20 > II-1) CDN A- CDN B Interconnection initialization phase > =20 > =20 > CDN A - CDN B interconnection initialization > =20 > Parameters needed to initialize CDNI interfaces between CDN A and CDN B (r= equest Routing, metadata and logging) for the agreed =E2=80=9Cservice=E2=80=9D= are exchanged via the control interface. These parameters will be used to c= onfigure CDN A and CDN B. > Among those, the following parameters are needed to initialize the Request= Routing interface accordingly to the agreed =E2=80=9Cservice_ab=E2=80=9D: > =20 > Service_id : =E2=80=9Cservice_ab=E2=80=9D > { > =E2=80=9CClass of request =E2=80=9C: > { > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9CEurope=E2=80=9D > } > =E2=80=9Cquality/capabilities=E2=80=9D :=20 > maxDeliveryStartLatency =3D 500 > } > =20 > CDN A - CDN B Request Routing/footprint&capabilities Notification > =20 > Once CDN A and CDN B are configured and operational, CDN B (dCDN) advertiz= es CDN A (uCDN) with request routing information via the Request Routing/foo= tprint and capabilities interface. > =20 > CDN A (dCDN) sends a Request Routing information notification to CDN B (uC= DN). This notification includes the following parameters: > Service : > {=20 > Service_id =3D service_ab > Status =3D operational > } > =20 > After CDN A has received this Request routing information notification, an= example of its selection algorithm could be as following (as an example and= for information only) =20 > =20 > If the End-user request of content matches the class of request =E2=80=9C*= //cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&*=E2=80=9D > And > { > If the IP source address belongs to the footprint/geo=3D=E2=80=9DFrance=E2= =80=9D > then, the delivery of the requested content is done by the CDN A its= elf > else { > if the IP source address belongs to the footprint/geo=3D=E2=80=9DEurope=E2= =80=9D then, the delivery of the requested content is delegated to CDN B (wh= ich will delegate it to CDN C if protocol =3D =E2=80=9CRTMP=E2=80=9D) > else { > =20 > if the IP source address belongs to the footprint/geo=3D=E2=80=9DWorld=E2=80= =9D then, the delivery of the requested content is delegated to CDN D > =20 > } > } > =20 > II-2) Request routing information modification > =20 > A problem occurs on CDN C so that it is not able to deliver anymore conten= t using RTMP. > CDN A must now selects CDN D for the delivery of CP1=E2=80=99s content in R= TMP for client other than in France. > =20 > Request Routing/footprint&capabilities Notifications > =20 > CDN C - CDN B Request Routing/footprint&capabilities Notification > =20 > CDN C will then send a request routing information notification to CDN B > This notification includes the following parameters: > Service : > {=20 > Service_id =3D service_bc > Status =3D not_operational > } > =20 > CDN A - CDN B Request Routing/footprint&capabilities Notification > =20 > CDN B will then send a request routing information notification to CDN A > This notification includes the following parameters: > Service : > {=20 > Service_id =3D service_ab > Status =3D partially_operational > Modified_parameters : > { > Class of request/URI_class: > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint --Apple-Mail-DA3B6287-B57F-4CA3-BFC4-9A72BF45A762 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Anne, Jan

On 16 Oct= 2012, at 15:00, <anne.marrec@o= range.com> wrote:

 

 

De : Jan See= dorf [mailto:Jan.Seedorf@neclab.eu]
Envoy=C3=A9 : mardi 16 octobre 2012 15:26
=C3=80 : MARREC Anne OLNC/OLN; cdni-footprint@ietf.org
Cc : cdni@ietf.org
Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint= /Capabilities Design Team Call'

 

Hi Anne a= nd Emile,

&nb= sp;

Thanks f= or sharing this use case and the detailed examples. It is all clear to me, a= nd I think good input to our discussions.

&nb= sp;

Two quic= k comments (we can discuss more in the call today):

- &= nbsp;        According to your example, =E2=80=9Ccapabilities_updates=E2=80=9D mu= st not only include =E2=80=9Coperational=E2=80=9D or =E2=80=9Cnon-operationa= l=E2=80=9D, but probably =E2=80=9Cpartially-operational=E2=80=9D plus some specification what partially means;

[A= M] =E2=80=9Cpartially_operationnel=E2=80=9D means thet the =E2=80=9Cservice=E2= =80=9D is not anymore supported by the dCDN as it was originally specified


Partially operation= al smells like a rat hole full of interoperability issues to me. Why can't t= he dCDN just advertise what it is now capable of doing and the uCDN can deci= de whether it still wishes to use the dCDN. 

The cap= ability to advertise "this advertisement is different to the last one i gave= you" via a "partially operatiobal" state adds no value IMO. 

- &= nbsp;        What about the case where capabilities updates may contain a referra= l to a given footprint, as we have discussed, e.g. the =E2=80=9Cpartially-op= erational=E2=80=9D update from B to A shall indicate that B can only serve RTMP in some parts o= f Europe? Do you agree to this scenario and that it should be supported?

[A= M] Yes, this scenario should be supported=E2=80=A6 more thinks are necessary= to describe how the modified parameter have to be specified


Why not have the d= CDN advertise the specific part of europe it can still support delivery to?<= /div>

Ben

&nb= sp;

- &= nbsp;        Jan

&nb= sp;

&nb= sp;

From: cdni-footprint-bounces@ie= tf.org [mailto:cdni-f= ootprint-bounces@ietf.org] On Behalf Of anne.marrec@or= ange.com
Sent: Monday, October 15, 2012 4:17 PM
To: cdni-footprint@ietf.or= g
Cc: cdni@ietf.org
Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabil= ities Design Team Call'

 

Hi all,

 

We propose the following use cas= e

 

Anne & Emile

 

 

Use case for Request routi= ng =C2=AB footprint & capabilities =C2=BB

 

Figure 1 shows the context of CD= N interconnection used to illustrate the use case =E2=80=9Cfootprint & c= apabilities=E2=80=9D. An example of the CDNI interface Request Routing/footp= rint&capabilities exchanges between CDN A and CDN B will be detailed.

 

 

<image001.png>
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


I)  &n= bsp;           Use case assumptions:

 

CP demand example:=

=C2=B7         A given CP1 wishes to delegate the delivery of its content to CDNA. Mos= t of CP1 client are from =E2=80=9CFrance=E2=80=9D but wants that client all o= ver the world be also delivered through a CDN. Its contents are two types :

o    content delivers in HTTP

o    and content delivers in RTMP

CP1= describes its content as per class of request, footprint and capabilities p= arameters.

Exa= mple of CP1=E2=80=99s =E2=80=9Cservice=E2=80=9D demand for the use case:

=E2= =80=9CClass of request=E2=80=9D:

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/*?url_signing=3D=E2=80=9Dbb=E2=80=9D= &*

"f= ootprint" :

ge= o =3D world=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D:

&n= bsp;            =   maxDeliveryStartLatency =3D 500

 

CDN interconnection negotiati= ons phase:

 

CDN= A capabilities compared to CP1 demand are the following:<= /p>

=E2= =80=9CClass of request =E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/*?url_signing=3D=E2=80=9Dbb=E2=80=9D= &*

=E2= =80=9Cfootprint=E2=80=9D :

Geo=3D =E2=80=9Cfrance=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

&n= bsp;            =   maxDeliveryStartLatency =3D 500

 

 

CDN= A capabilities are not enough compared to CP1 demand (limited to =E2=80=9Cf= ootprint/geo=3D france). CDN A already has an agreement with a global CDN (C= DN D) to deliver any content to =E2=80=9Cworld=E2=80=9D with url_signing=3D=E2=80=9Dbb=E2=80=9D (=E2=80=9Cservice_ad=E2=80=9D compatible= with CP1 demand) but the price is very high.

Bes= ide, CDN A operator is also aware that another CDN, CDN B, has the possibili= ty to deliver content to =E2=80=9CEurope=E2=80=9D with a lower price than CD= N D.

 

     &n= bsp;          1) CDN A notes th= e CP1 demand

2) C= DN A contacts CDN B operator and demand CDN B capabilities compared to CP1 d= emand.

3) C= DN B notes the CDN A demand and verify if it can manage the CDNA demand.

&nb= sp;            &= nbsp; 

CDN= B capabilities compared to CDN A demand:

=E2= =80=9CClass of request =E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

http://cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2= =80=9D&*

=E2= =80=9Cfootprint=E2=80=9D :

Ge= o=3D =E2=80=9CEurope=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

ma= xDeliveryStartLatency =3D 500

 

CDN= B owns capabilities are not enough compared to CDN A demand (limited to foo= tprint/geo=3D=E2=80=9Deurope=E2=80=9D and protocol=3DHTTP).

But= CDN B operator already has an agreement with CDN C to deliver any content i= n RTMP to =E2=80=9CEurope=E2=80=9D:

=E2= =80=9Cservice_bc=E2=80=9D:

=E2= =80=9CClass of request =E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

rtmp://cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2= =80=9D&*

=E2= =80=9Cfootprint=E2=80=9D :

Ge= o=3D =E2=80=9CEurope=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

ma= xDeliveryStartLatency =3D 500

CDN= B is able to satisfy the CDN A demand for =E2=80=9Cfootprint/geo=3DEurope=E2= =80=9D when it delegates content delivered in RTMP to CDN C.

 

4) C= DN B announces its capabilities to CDN A limited to =E2=80=9CEurope=E2=80=9D=   compared to CDN A demand

 

=E2= =80=9CClass of request=E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/*?url_signing=3D=E2=80=9Dbb=E2=80=9D= &*

=E2= =80=9Cfootprint=E2=80=9D:

Geo=3D =E2=80=9CEurope=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

&nb= sp;            &= nbsp;  maxDeliveryStartLatency =3D 500

 

5) C= DN A is ok and an agreement is concluded between CDNA and CAN B operators fo= r the following service:

=E2= =80=9Cservice_ab=E2=80=9D:

=E2= =80=9CClass of request =E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D= &*

=E2= =80=9Cfootprint=E2=80=9D :

Ge= o=3D =E2=80=9CEurope=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

ma= xDeliveryStartLatency =3D 500

 

 

[ed= .note] This CDN interconnection negotiation phase is out of scope of IETF CD= NI WG. In this example, potential dCDN capabilities are known by uCDN thanks= to =E2=80=9Crelationship=E2=80=9D or already concluded agreement. One can imagine another way for the uCDN to know potential dCDN c= apabilities: potential dCDN capabilities automatic advertisement directly to= all potential uCDN or through a =E2=80=9CCDN capability portal=E2=80=9D acc= essible to all CDNs.

 

 

II)  &= nbsp;         Use case:

 

     &n= bsp;          II-1) CDN A- C= DN B Interconnection initialization phase

 

 

= CDN A - CDN B interconnection initialization

 

Par= ameters needed to initialize CDNI interfaces between CDN A and CDN B (reques= t Routing, metadata and logging) for the agreed =E2=80=9Cservice=E2=80=9D ar= e exchanged via the control interface. These parameters will be used to configure CDN A a= nd CDN B.

Amo= ng those, the following parameters are needed to initialize the Request Rout= ing interface accordingly to the agreed =E2=80=9Cservice_ab=E2=80=9D:

 

Ser= vice_id : =E2=80=9Cservice_ab=E2=80=9D

&nb= sp;            &= nbsp;            = ;     {

=E2= =80=9CClass of request =E2=80=9C:

&n= bsp;            =   {

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D= &*

=E2= =80=9Cfootprint=E2=80=9D :

Ge= o=3D =E2=80=9CEurope=E2=80=9D

}<= o:p>

=E2= =80=9Cquality/capabilities=E2=80=9D :

ma= xDeliveryStartLatency =3D 500

}<= o:p>

 

= CDN A - CDN B Request Routing/footprint&capabilities Notification

 

Onc= e CDN A and CDN B are configured and operational, CDN B (dCDN) advertizes CD= N A (uCDN) with request routing information via the Request Routing/footprin= t and capabilities interface.

 

= CDN A (dCDN) sends a Request Routing information notification to CDN B (uCDN= ). This notification includes the following parameters:

= Service :

=       { 

=           Service_id =3D s= ervice_ab

=            Status =3D oper= ational

=      }

=  

After CDN A has received this Re= quest routing information notification, an example of its selection algorith= m could be as following (as an example and for information only)  =              &nb= sp;            &= nbsp;            = ;

 

If t= he End-user request of content matches the class of request =E2=80=9C*//cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&*=E2=80=9D

And=

{

If&= nbsp; the IP source address belongs to the footprint/geo=3D=E2=80=9DFrance=E2=80=9D

&nb= sp;     then, the delivery of the requested content is d= one by the CDN A itself

&nb= sp;     else {

if= the IP source address belongs to the footprint/geo=3D=E2=80=9DEurope=E2=80=9D then, the delivery of the re= quested content is delegated to CDN B (which will delegate it to CDN C if pr= otocol =3D =E2=80=9CRTMP=E2=80=9D)

el= se {

 

if= the IP source address belongs to the footprint/geo=3D=E2=80=9DWorld=E2=80=9D then, the delivery of the req= uested content is delegated to CDN D

 

          = ;                     }

&nb= sp;       }

 

     &n= bsp;          II-2) Request r= outing information modification

 

A problem occurs on CDN C so tha= t it is not able to deliver anymore content using RTMP.

CDN A must now selects CDN D for= the delivery of CP1=E2=80=99s content in RTMP for client other than in Fran= ce.

 

Request Routing/footprint&= ;capabilities Notifications

 

= CDN C - CDN B Request Routing/footprint&capabilities Notification

 

CDN= C will then send a request routing information notification to CDN B

= This notification includes the following parameters:

= Service :

=       { 

=           Service_id =3D s= ervice_bc

=            Status =3D not_= operational

=      }

 

= CDN A - CDN B Request Routing/footprint&capabilities Notification

 

CDN= B will then send a request routing information notification to CDN A

= This notification includes the following parameters:

= Service :

=       { 

=           Service_id =3D s= ervice_ab

=            Status =3D part= ially_operational

=           Modified_parameters :=

=             &nbs= p;            &n= bsp;            {

Class of request/URI_class:

_______________________________________________=
cdni-footprint mailing list
cdni-footprint@ietf.org
https://www.iet= f.org/mailman/listinfo/cdni-footprint
= --Apple-Mail-DA3B6287-B57F-4CA3-BFC4-9A72BF45A762-- From ben@niven-jenkins.co.uk Wed Oct 17 15:45:02 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 A624921F8711; Wed, 17 Oct 2012 15:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.202 X-Spam-Level: X-Spam-Status: No, score=-101.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8A9hOMD8jrCz; Wed, 17 Oct 2012 15:45:00 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 543AE21F86D8; Wed, 17 Oct 2012 15:44:59 -0700 (PDT) Received: from [31.79.220.171] by mail4.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1TOcMC-0002pH-U0; Wed, 17 Oct 2012 23:44:58 +0100 References: <28062_1350310593_507C1AC1_28062_2925_3_E5E1F88FBF39A84689D4A4791AE362B901FA4D@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2779C9F0771F974CAD742BAE6D9904FE55379360@DAPHNIS.office.hd> <17306_1350396001_507D6861_17306_3179_1_E5E1F88FBF39A84689D4A4791AE362B901FD11@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-93C705A1-B772-4516-9A1F-D3D002BD9D33 Message-Id: <6E038CDC-82FC-48D2-8FA0-A47B8026E5DF@niven-jenkins.co.uk> X-Mailer: iPhone Mail (9B206) From: Ben Niven-Jenkins Date: Wed, 17 Oct 2012 23:44:51 +0100 To: Songhaibin X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" , "anne.marrec@orange.com" Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI 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: Wed, 17 Oct 2012 22:45:02 -0000 --Apple-Mail-93C705A1-B772-4516-9A1F-D3D002BD9D33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Haibin On 17 Oct 2012, at 07:24, Songhaibin wrote: > Excellent use case and discussion! And I think the negotiation phase shoul= d be in scope, which should not be left as a hole for CDNI. I disagree. I don't think there is any need for negotiation or in fact any n= egotiation occurring at all.=20 The dCDN advertises what it is capable/willing to do on the behalf of the uC= DN and the uCDN decides whether it wants to use the dCDN or not.=20 A negotiation implies the dCDN advertises something the uCDN doesn't like an= d the uCDN can reply "that doesn't work for me please try a different offer"= where the dCDN can then advertise a different footprint/capabilities to the= uCDN. I don't see such negotiations occurring at the protocol layer in prac= tice and so CDNI doesn't require a footprint/capabilities negotiation state m= achine.=20 Ben > =20 > -Haibin > =20 > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of an= ne.marrec@orange.com > Sent: Tuesday, October 16, 2012 10:00 PM > To: Jan Seedorf; cdni-footprint@ietf.org > Cc: cdni@ietf.org > Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI Footprint/Capab= ilities Design Team Call' > =20 > =20 > =20 > De : Jan Seedorf [mailto:Jan.Seedorf@neclab.eu]=20 > Envoy=C3=A9 : mardi 16 octobre 2012 15:26 > =C3=80 : MARREC Anne OLNC/OLN; cdni-footprint@ietf.org > Cc : cdni@ietf.org > Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilit= ies Design Team Call' > =20 > Hi Anne and Emile, > =20 > Thanks for sharing this use case and the detailed examples. It is all clea= r to me, and I think good input to our discussions. > =20 > Two quick comments (we can discuss more in the call today): > - According to your example, =E2=80=9Ccapabilities_updates=E2=80=9D= must not only include =E2=80=9Coperational=E2=80=9D or =E2=80=9Cnon-operati= onal=E2=80=9D, but probably =E2=80=9Cpartially-operational=E2=80=9D plus som= e specification what partially means; > [AM] =E2=80=9Cpartially_operationnel=E2=80=9D means thet the =E2=80=9Cserv= ice=E2=80=9D is not anymore supported by the dCDN as it was originally speci= fied > - What about the case where capabilities updates may contain a re= ferral to a given footprint, as we have discussed, e.g. the =E2=80=9Cpartial= ly-operational=E2=80=9D update from B to A shall indicate that B can only se= rve RTMP in some parts of Europe? Do you agree to this scenario and that it s= hould be supported? > [AM] Yes, this scenario should be supported=E2=80=A6 more thinks are neces= sary to describe how the modified parameter have to be specified > =20 > - Jan > =20 > =20 > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.= org] On Behalf Of anne.marrec@orange.com > Sent: Monday, October 15, 2012 4:17 PM > To: cdni-footprint@ietf.org > Cc: cdni@ietf.org > Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabilities= Design Team Call' > =20 > Hi all, > =20 > We propose the following use case > =20 > Anne & Emile > =20 > =20 > Use case for Request routing =C2=AB footprint & capabilities =C2=BB > =20 > Figure 1 shows the context of CDN interconnection used to illustrate the u= se case =E2=80=9Cfootprint & capabilities=E2=80=9D. An example of the CDNI i= nterface Request Routing/footprint&capabilities exchanges between CDN A and C= DN B will be detailed. > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 >=20 > I) Use case assumptions:=20 > =20 > CP demand example: > =C2=B7 A given CP1 wishes to delegate the delivery of its content t= o CDNA. Most of CP1 client are from =E2=80=9CFrance=E2=80=9D but wants that c= lient all over the world be also delivered through a CDN. Its contents are t= wo types : > o content delivers in HTTP > o and content delivers in RTMP > CP1 describes its content as per class of request, footprint and capabilit= ies parameters. > Example of CP1=E2=80=99s =E2=80=9Cservice=E2=80=9D demand for the use case= : > =E2=80=9CClass of request=E2=80=9D: > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*?url_signing=3D=E2=80=9Dbb=E2=80=9D&* > "footprint" : > geo =3D world=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D: > maxDeliveryStartLatency =3D 500 > =20 > CDN interconnection negotiations phase: > =20 > CDN A capabilities compared to CP1 demand are the following: > =E2=80=9CClass of request =E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*?url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9Cfrance=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D : > maxDeliveryStartLatency =3D 500 > =20 > =20 > CDN A capabilities are not enough compared to CP1 demand (limited to =E2=80= =9Cfootprint/geo=3D france). CDN A already has an agreement with a global CD= N (CDN D) to deliver any content to =E2=80=9Cworld=E2=80=9D with url_signing= =3D=E2=80=9Dbb=E2=80=9D (=E2=80=9Cservice_ad=E2=80=9D compatible with CP1 de= mand) but the price is very high. > Beside, CDN A operator is also aware that another CDN, CDN B, has the poss= ibility to deliver content to =E2=80=9CEurope=E2=80=9D with a lower price th= an CDN D. > =20 > 1) CDN A notes the CP1 demand > 2) CDN A contacts CDN B operator and demand CDN B capabilities compared to= CP1 demand. > 3) CDN B notes the CDN A demand and verify if it can manage the CDNA deman= d. > =20 > CDN B capabilities compared to CDN A demand: > =E2=80=9CClass of request =E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > http://cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9CEurope=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D : > maxDeliveryStartLatency =3D 500 > =20 > CDN B owns capabilities are not enough compared to CDN A demand (limited t= o footprint/geo=3D=E2=80=9Deurope=E2=80=9D and protocol=3DHTTP). > But CDN B operator already has an agreement with CDN C to deliver any cont= ent in RTMP to =E2=80=9CEurope=E2=80=9D: > =E2=80=9Cservice_bc=E2=80=9D: > =E2=80=9CClass of request =E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > rtmp://cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9CEurope=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D : > maxDeliveryStartLatency =3D 500 > CDN B is able to satisfy the CDN A demand for =E2=80=9Cfootprint/geo=3DEur= ope=E2=80=9D when it delegates content delivered in RTMP to CDN C. > =20 > 4) CDN B announces its capabilities to CDN A limited to =E2=80=9CEurope=E2= =80=9D compared to CDN A demand > =20 > =E2=80=9CClass of request=E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*?url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D: > Geo=3D =E2=80=9CEurope=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D : > maxDeliveryStartLatency =3D 500 > =20 > 5) CDN A is ok and an agreement is concluded between CDNA and CAN B operat= ors for the following service: > =E2=80=9Cservice_ab=E2=80=9D: > =E2=80=9CClass of request =E2=80=9C: > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9CEurope=E2=80=9D > =E2=80=9Cquality/capabilities=E2=80=9D : > maxDeliveryStartLatency =3D 500 > =20 > =20 > [ed.note] This CDN interconnection negotiation phase is out of scope of IE= TF CDNI WG. In this example, potential dCDN capabilities are known by uCDN t= hanks to =E2=80=9Crelationship=E2=80=9D or already concluded agreement. One c= an imagine another way for the uCDN to know potential dCDN capabilities: pot= ential dCDN capabilities automatic advertisement directly to all potential u= CDN or through a =E2=80=9CCDN capability portal=E2=80=9D accessible to all C= DNs. > =20 > =20 > II) Use case: > =20 > II-1) CDN A- CDN B Interconnection initialization phase > =20 > =20 > CDN A - CDN B interconnection initialization > =20 > Parameters needed to initialize CDNI interfaces between CDN A and CDN B (r= equest Routing, metadata and logging) for the agreed =E2=80=9Cservice=E2=80=9D= are exchanged via the control interface. These parameters will be used to c= onfigure CDN A and CDN B. > Among those, the following parameters are needed to initialize the Request= Routing interface accordingly to the agreed =E2=80=9Cservice_ab=E2=80=9D: > =20 > Service_id : =E2=80=9Cservice_ab=E2=80=9D > { > =E2=80=9CClass of request =E2=80=9C: > { > =E2=80=9CURI_class=E2=80=9D: > *//cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&* > =E2=80=9Cfootprint=E2=80=9D : > Geo=3D =E2=80=9CEurope=E2=80=9D > } > =E2=80=9Cquality/capabilities=E2=80=9D : > maxDeliveryStartLatency =3D 500 > } > =20 > CDN A - CDN B Request Routing/footprint&capabilities Notification > =20 > Once CDN A and CDN B are configured and operational, CDN B (dCDN) advertiz= es CDN A (uCDN) with request routing information via the Request Routing/foo= tprint and capabilities interface. > =20 > CDN A (dCDN) sends a Request Routing information notification to CDN B (uC= DN). This notification includes the following parameters: > Service : > {=20 > Service_id =3D service_ab > Status =3D operational > } > =20 > After CDN A has received this Request routing information notification, an= example of its selection algorithm could be as following (as an example and= for information only) =20 > =20 > If the End-user request of content matches the class of request =E2=80=9C*= //cdn.cp1.com/video/*? url_signing=3D=E2=80=9Dbb=E2=80=9D&*=E2=80=9D > And > { > If the IP source address belongs to the footprint/geo=3D=E2=80=9DFrance=E2= =80=9D > then, the delivery of the requested content is done by the CDN A its= elf > else { > if the IP source address belongs to the footprint/geo=3D=E2=80=9DEurope=E2= =80=9D then, the delivery of the requested content is delegated to CDN B (wh= ich will delegate it to CDN C if protocol =3D =E2=80=9CRTMP=E2=80=9D) > else { > =20 > if the IP source address belongs to the footprint/geo=3D=E2=80=9DWorld=E2=80= =9D then, the delivery of the requested content is delegated to CDN D > =20 > } > } > =20 > II-2) Request routing information modification > =20 > A problem occurs on CDN C so that it is not able to deliver anymore conten= t using RTMP. > CDN A must now selects CDN D for the delivery of CP1=E2=80=99s content in R= TMP for client other than in France. > =20 > Request Routing/footprint&capabilities Notifications > =20 > CDN C - CDN B Request Routing/footprint&capabilities Notification > =20 > CDN C will then send a request routing information notification to CDN B > This notification includes the following parameters: > Service : > {=20 > &nbs > _______________________________________________ > cdni-footprint mailing list > cdni-footprint@ietf.org > https://www.ietf.org/mailman/listinfo/cdni-footprint --Apple-Mail-93C705A1-B772-4516-9A1F-D3D002BD9D33 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Haibin

On 17 Oct 20= 12, at 07:24, Songhaibin <haibi= n.song@huawei.com> wrote:

Excellent use case and discussion! And I think the negotiation phas= e should be in scope, which should not be left as a hole for CDNI.


I disagree. I don't think there is a= ny need for negotiation or in fact any negotiation occurring at all. 
The dCDN advertises what it is capable/willing to do on th= e behalf of the uCDN and the uCDN decides whether it wants to use the dCDN o= r not. 

A negotiation implies the dCDN adverti= ses something the uCDN doesn't like and the uCDN can reply "that doesn't wor= k for me please try a different offer" where the dCDN can then advertise a d= ifferent footprint/capabilities to the uCDN. I don't see such negotiations o= ccurring at the protocol layer in practice and so CDNI doesn't require a foo= tprint/capabilities negotiation state machine. 

Ben

 

-Haibin

 

From: cdni-bounces@iet= f.org [mailto:cdni-bounces@ietf.org] On Behalf Of anne.marrec@or= ange.com
Sent: Tuesday, October 16, 2012 10:00 PM
To: Jan Seedorf; cdni-foot= print@ietf.org
Cc: cdni@ietf.org
Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI Footprint/= Capabilities Design Team Call'

 

 =

 =

De : Jan Seedorf [mailto:Jan.Seedorf@neclab.eu]
Envoy=C3=A9 : mardi 16 octobre 2012 15:26
=C3=80 : MARREC Anne OLNC/OLN; cdni-footprint@ietf.org
Cc : cdni@ietf.org
Objet : RE: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint= /Capabilities Design Team Call'

 

Hi Anne a= nd Emile,

&nb= sp;

Thanks f= or sharing this use case and the detailed examples. It is all clear to me, a= nd I think good input to our discussions.

&nb= sp;

Two quic= k comments (we can discuss more in the call today):

- &= nbsp;        According to your= example, =E2=80=9Ccapabilities_updates=E2=80=9D must not only include =E2=80= =9Coperational=E2=80=9D or =E2=80=9Cnon-operational=E2=80=9D, but probably =E2= =80=9Cpartially-operational=E2=80=9D plus some specification what partially means;

[A= M] =E2=80=9Cpartially_operationnel=E2=80=9D means thet the =E2=80=9Cservice=E2= =80=9D is not anymore supported by the dCDN as it was originally specified=

- &= nbsp;        What about the ca= se where capabilities updates may contain a referral to a given footprint, a= s we have discussed, e.g. the =E2=80=9Cpartially-operational=E2=80=9D update= from B to A shall indicate that B can only serve RTMP in some parts of Euro= pe? Do you agree to this scenario and that it should be supported?

[A= M] Yes, this scenario should be supported=E2=80=A6 more thinks are necessary= to describe how the modified parameter have to be specified

&nb= sp;

- &= nbsp;        Jan

&nb= sp;

&nb= sp;

From: cdni-footprint-bounces@ie= tf.org [mailto:cdni-f= ootprint-bounces@ietf.org] On Behalf Of anne.marrec@or= ange.com
Sent: Monday, October 15, 2012 4:17 PM
To: cdni-footprint@ietf.or= g
Cc: cdni@ietf.org
Subject: Re: [cdni-footprint] Thoughts on the 'CDNI Footprint/Capabil= ities Design Team Call'

 

Hi all,

 

We propose the following use cas= e

 

Anne & Emile

 

 

Use case for Request routi= ng =C2=AB footprint & capabilities =C2=BB

 

Figure 1 shows the context of CD= N interconnection used to illustrate the use case =E2=80=9Cfootprint & c= apabilities=E2=80=9D. An example of the CDNI interface Request Routing/footp= rint&capabilities exchanges between CDN A and CDN B will be detailed.

 

 

<image004.png>
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


I)  &n= bsp;            =      Use case a= ssumptions:

 

CP demand example:=

=C2=B7         A given CP1 wishes t= o delegate the delivery of its content to CDNA. Most of CP1 client are from =E2= =80=9CFrance=E2=80=9D but wants that client all over the world be also deliv= ered through a CDN. Its contents are two types :

o    content delivers in H= TTP

o    and content delivers= in RTMP

CP1= describes its content as per class of request, footprint and capabilities p= arameters.

Exa= mple of CP1=E2=80=99s =E2=80=9Cservice=E2=80=9D demand for the use case:

=E2= =80=9CClass of request=E2=80=9D:

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/= *?url_sign= ing=3D=E2=80=9Dbb=E2=80=9D&*

"f= ootprint" :

ge= o =3D world=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D:

&n= bsp;            =   maxDeliveryStartLatency =3D 500

 

CDN interconnection negotiati= ons phase:

 

CDN= A capabilities compared to CP1 demand are the following:<= /p>

=E2= =80=9CClass of request =E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/= *?url_sign= ing=3D=E2=80=9Dbb=E2=80=9D&*

=E2= =80=9Cfootprint=E2=80=9D :

Geo=3D =E2=80=9Cfrance=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

&n= bsp;            =   maxDeliveryStartLatency =3D 500

 

 

CDN= A capabilities are not enough compared to CP1 demand (limited to =E2=80=9Cf= ootprint/geo=3D france). CDN A already has an agreement with a global CDN (C= DN D) to deliver any content to =E2=80=9Cworld=E2=80=9D with url_signing=3D=E2=80=9Dbb=E2=80=9D (=E2=80=9Cservice_ad=E2=80=9D compatible= with CP1 demand) but the price is very high.

Bes= ide, CDN A operator is also aware that another CDN, CDN B, has the possibili= ty to deliver content to =E2=80=9CEurope=E2=80=9D with a lower price than CD= N D.

 

     &n= bsp;          1) CDN A notes th= e CP1 demand

2) C= DN A contacts CDN B operator and demand CDN B capabilities compared to CP1 d= emand.

3) C= DN B notes the CDN A demand and verify if it can manage the CDNA demand.

&nb= sp;            &= nbsp; 

CDN= B capabilities compared to CDN A demand:

=E2= =80=9CClass of request =E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

http://cdn.cp1.com/vi= deo/*? url= _signing=3D=E2=80=9Dbb=E2=80=9D&*

=E2= =80=9Cfootprint=E2=80=9D :

Ge= o=3D =E2=80=9CEurope=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

ma= xDeliveryStartLatency =3D 500

 

CDN= B owns capabilities are not enough compared to CDN A demand (limited to foo= tprint/geo=3D=E2=80=9Deurope=E2=80=9D and protocol=3DHTTP).

But= CDN B operator already has an agreement with CDN C to deliver any content i= n RTMP to =E2=80=9CEurope=E2=80=9D:

=E2= =80=9Cservice_bc=E2=80=9D:

=E2= =80=9CClass of request =E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

rtmp://cdn.cp1.com/vi= deo/*? url= _signing=3D=E2=80=9Dbb=E2=80=9D&*

=E2= =80=9Cfootprint=E2=80=9D :

Ge= o=3D =E2=80=9CEurope=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

ma= xDeliveryStartLatency =3D 500

CDN= B is able to satisfy the CDN A demand for =E2=80=9Cfootprint/geo=3DEurope=E2= =80=9D when it delegates content delivered in RTMP to CDN C.

 

4) C= DN B announces its capabilities to CDN A limited to =E2=80=9CEurope=E2=80=9D=   compared to CDN A demand

 

=E2= =80=9CClass of request=E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/= *?url_sign= ing=3D=E2=80=9Dbb=E2=80=9D&*

=E2= =80=9Cfootprint=E2=80=9D:

Geo=3D =E2=80=9CEurope=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

&nb= sp;            &= nbsp;  maxDeliveryStartLatency =3D 500

 

5) C= DN A is ok and an agreement is concluded between CDNA and CAN B operators fo= r the following service:

=E2= =80=9Cservice_ab=E2=80=9D:

=E2= =80=9CClass of request =E2=80=9C:

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/= *? url_sig= ning=3D=E2=80=9Dbb=E2=80=9D&*

=E2= =80=9Cfootprint=E2=80=9D :

Ge= o=3D =E2=80=9CEurope=E2=80=9D

=E2= =80=9Cquality/capabilities=E2=80=9D :

ma= xDeliveryStartLatency =3D 500

 

 

[ed= .note] This CDN interconnection negotiation phase is out of scope of IETF CD= NI WG. In this example, potential dCDN capabilities are known by uCDN thanks= to =E2=80=9Crelationship=E2=80=9D or already concluded agreement. One can imagine another way for the uCDN to know potential dCDN c= apabilities: potential dCDN capabilities automatic advertisement directly to= all potential uCDN or through a =E2=80=9CCDN capability portal=E2=80=9D acc= essible to all CDNs.

 

 

II)  &= nbsp;            = ;  Use case: <= o:p>

 

     &n= bsp;          II-1) CDN A- C= DN B Interconnection initialization phase

 

 

= CDN A - CDN B interconnection initialization

 

Par= ameters needed to initialize CDNI interfaces between CDN A and CDN B (reques= t Routing, metadata and logging) for the agreed =E2=80=9Cservice=E2=80=9D ar= e exchanged via the control interface. These parameters will be used to configure CDN A a= nd CDN B.

Amo= ng those, the following parameters are needed to initialize the Request Rout= ing interface accordingly to the agreed =E2=80=9Cservice_ab=E2=80=9D:

 

Ser= vice_id : =E2=80=9Cservice_ab=E2=80=9D

&nb= sp;            &= nbsp;            = ;     {

=E2= =80=9CClass of request =E2=80=9C:

&n= bsp;            =   {

=E2= =80=9CURI_class=E2=80=9D:

*//cdn.cp1.com/video/= *? url_sig= ning=3D=E2=80=9Dbb=E2=80=9D&*

=E2= =80=9Cfootprint=E2=80=9D :

Ge= o=3D =E2=80=9CEurope=E2=80=9D

}<= o:p>

=E2= =80=9Cquality/capabilities=E2=80=9D :

ma= xDeliveryStartLatency =3D 500

}<= o:p>

 

= CDN A - CDN B Request Routing/footprint&capabilities Notification

 

Onc= e CDN A and CDN B are configured and operational, CDN B (dCDN) advertizes CD= N A (uCDN) with request routing information via the Request Routing/footprin= t and capabilities interface.

 

= CDN A (dCDN) sends a Request Routing information notification to CDN B (uCDN= ). This notification includes the following parameters:

= Service :

=       { 

=           Service_id =3D s= ervice_ab

=            Status =3D oper= ational

=      }

=  

After CDN A has received this Re= quest routing information notification, an example of its selection algorith= m could be as following (as an example and for information only)  =              &nb= sp;            &= nbsp;            = ;

 

If t= he End-user request of content matches the class of request =E2=80=9C*//cdn.cp1.com/video/*<= /span>? url_signing=3D=E2=80=9Dbb=E2=80=9D&*=E2=80=9D=

And=

{

If&= nbsp; the IP source address belongs to the footprint/geo=3D=E2=80=9DFrance=E2=80=9D

&nb= sp;     then, the delivery of the requested content is d= one by the CDN A itself

&nb= sp;     else {

if= the IP source address belongs to the footprint/geo=3D=E2=80=9DEurope=E2=80=9D then, the delivery of the re= quested content is delegated to CDN B (which will delegate it to CDN C if pr= otocol =3D =E2=80=9CRTMP=E2=80=9D)

el= se {

 

if= the IP source address belongs to the footprint/geo=3D=E2=80=9DWorld=E2=80=9D then, the delivery of the req= uested content is delegated to CDN D

 

          = ;                     }

&nb= sp;       }

 

     &n= bsp;          II-2) Request r= outing information modification

 

A problem occurs on CDN C so tha= t it is not able to deliver anymore content using RTMP.

CDN A must now selects CDN D for= the delivery of CP1=E2=80=99s content in RTMP for client other than in Fran= ce.

 

Request Routing/footprint&= ;capabilities Notifications

 

= CDN C - CDN B Request Routing/footprint&capabilities Notification

 

CDN= C will then send a request routing information notification to CDN B

= This notification includes the following parameters:

= Service :

=       { 

=      &nbs

_______________________________________________
= cdni-footprint mailing list
cdni-footprint@ietf.org
https://www.ietf.org/mailman/lis= tinfo/cdni-footprint
= --Apple-Mail-93C705A1-B772-4516-9A1F-D3D002BD9D33-- From haibin.song@huawei.com Wed Oct 17 18:16:05 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 67C1221F8698; Wed, 17 Oct 2012 18:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.204 X-Spam-Level: X-Spam-Status: No, score=-6.204 tagged_above=-999 required=5 tests=[AWL=0.394, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 cssXPDOdsxSc; Wed, 17 Oct 2012 18:16:03 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 960EA21F8685; Wed, 17 Oct 2012 18:16:00 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKS00645; Thu, 18 Oct 2012 01:15:57 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 18 Oct 2012 02:14:06 +0100 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 18 Oct 2012 02:14:56 +0100 Received: from SZXEML534-MBX.china.huawei.com ([169.254.2.70]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Thu, 18 Oct 2012 09:14:49 +0800 From: Songhaibin To: Ben Niven-Jenkins Thread-Topic: [cdni-footprint] [CDNi] Thoughts on the 'CDNI Footprint/Capabilities Design Team Call' Thread-Index: AQHNrLkP6cOJellmCEOKGYqznce/PJe+QQjg Date: Thu, 18 Oct 2012 01:14:48 +0000 Message-ID: References: <28062_1350310593_507C1AC1_28062_2925_3_E5E1F88FBF39A84689D4A4791AE362B901FA4D@PEXCVZYM12.corporate.adroot.infra.ftgroup> <2779C9F0771F974CAD742BAE6D9904FE55379360@DAPHNIS.office.hd> <17306_1350396001_507D6861_17306_3179_1_E5E1F88FBF39A84689D4A4791AE362B901FD11@PEXCVZYM12.corporate.adroot.infra.ftgroup> <6E038CDC-82FC-48D2-8FA0-A47B8026E5DF@niven-jenkins.co.uk> In-Reply-To: <6E038CDC-82FC-48D2-8FA0-A47B8026E5DF@niven-jenkins.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.123] Content-Type: multipart/alternative; boundary="_000_E33E01DFD5BEA24B9F3F18671078951F23B3C193szxeml534mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" , "anne.marrec@orange.com" Subject: Re: [CDNi] [cdni-footprint] Thoughts on the 'CDNI 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: Thu, 18 Oct 2012 01:16:05 -0000 --_000_E33E01DFD5BEA24B9F3F18671078951F23B3C193szxeml534mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQmVuLA0KDQpBY3R1YWxseSBpbiB0aGUgZXhhbXBsZSBkZXNjcmliZWQgYnkgQW5uZSwgdGhl IG5lZ290aWF0aW9uIHBoYXNlIGlzIGFib3V0IHRoZSBmb290cHJpbnQvY2FwYWJpbGl0eSBhZHZl cnRpc2VtZW50LiBUaGF0IGlzIHdoYXQgSSBtZWFuLiBJIGFncmVlIHdpdGggeW91ciBwb2ludC4g VGhlIG5vdGUgYmVsb3cgaW4gdGhlIGV4YW1wbGUgaXMgbm90IG5lY2Vzc2FyeSBhbmQgc2hvdWxk IGJlIHJlbW92ZWQuDQoNCltlZC5ub3RlXSBUaGlzIENETiBpbnRlcmNvbm5lY3Rpb24gbmVnb3Rp YXRpb24gcGhhc2UgaXMgb3V0IG9mIHNjb3BlIG9mIElFVEYgQ0ROSSBXRy4gSW4gdGhpcyBleGFt cGxlLCBwb3RlbnRpYWwgZENETiBjYXBhYmlsaXRpZXMgYXJlIGtub3duIGJ5IHVDRE4gdGhhbmtz IHRvIOKAnHJlbGF0aW9uc2hpcOKAnSBvciBhbHJlYWR5IGNvbmNsdWRlZCBhZ3JlZW1lbnQuIE9u ZSBjYW4gaW1hZ2luZSBhbm90aGVyIHdheSBmb3IgdGhlIHVDRE4gdG8ga25vdyBwb3RlbnRpYWwg ZENETiBjYXBhYmlsaXRpZXM6IHBvdGVudGlhbCBkQ0ROIGNhcGFiaWxpdGllcyBhdXRvbWF0aWMg YWR2ZXJ0aXNlbWVudCBkaXJlY3RseSB0byBhbGwgcG90ZW50aWFsIHVDRE4gb3IgdGhyb3VnaCBh IOKAnENETiBjYXBhYmlsaXR5IHBvcnRhbOKAnSBhY2Nlc3NpYmxlIHRvIGFsbCBDRE5zLg0KDQpC UiwNCi1IYWliaW4NCg0KRnJvbTogQmVuIE5pdmVuLUplbmtpbnMgW21haWx0bzpiZW5Abml2ZW4t amVua2lucy5jby51a10NClNlbnQ6IFRodXJzZGF5LCBPY3RvYmVyIDE4LCAyMDEyIDY6NDUgQU0N ClRvOiBTb25naGFpYmluDQpDYzogYW5uZS5tYXJyZWNAb3JhbmdlLmNvbTsgSmFuIFNlZWRvcmY7 IGNkbmktZm9vdHByaW50QGlldGYub3JnOyBjZG5pQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2Nk bmktZm9vdHByaW50XSBbQ0ROaV0gVGhvdWdodHMgb24gdGhlICdDRE5JIEZvb3RwcmludC9DYXBh YmlsaXRpZXMgRGVzaWduIFRlYW0gQ2FsbCcNCg0KSGFpYmluDQoNCk9uIDE3IE9jdCAyMDEyLCBh dCAwNzoyNCwgU29uZ2hhaWJpbiA8aGFpYmluLnNvbmdAaHVhd2VpLmNvbTxtYWlsdG86aGFpYmlu LnNvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KRXhjZWxsZW50IHVzZSBjYXNlIGFuZCBkaXNjdXNz aW9uISBBbmQgSSB0aGluayB0aGUgbmVnb3RpYXRpb24gcGhhc2Ugc2hvdWxkIGJlIGluIHNjb3Bl LCB3aGljaCBzaG91bGQgbm90IGJlIGxlZnQgYXMgYSBob2xlIGZvciBDRE5JLg0KDQpJIGRpc2Fn cmVlLiBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFueSBuZWVkIGZvciBuZWdvdGlhdGlvbiBvciBp biBmYWN0IGFueSBuZWdvdGlhdGlvbiBvY2N1cnJpbmcgYXQgYWxsLg0KDQpUaGUgZENETiBhZHZl cnRpc2VzIHdoYXQgaXQgaXMgY2FwYWJsZS93aWxsaW5nIHRvIGRvIG9uIHRoZSBiZWhhbGYgb2Yg dGhlIHVDRE4gYW5kIHRoZSB1Q0ROIGRlY2lkZXMgd2hldGhlciBpdCB3YW50cyB0byB1c2UgdGhl IGRDRE4gb3Igbm90Lg0KDQpBIG5lZ290aWF0aW9uIGltcGxpZXMgdGhlIGRDRE4gYWR2ZXJ0aXNl cyBzb21ldGhpbmcgdGhlIHVDRE4gZG9lc24ndCBsaWtlIGFuZCB0aGUgdUNETiBjYW4gcmVwbHkg InRoYXQgZG9lc24ndCB3b3JrIGZvciBtZSBwbGVhc2UgdHJ5IGEgZGlmZmVyZW50IG9mZmVyIiB3 aGVyZSB0aGUgZENETiBjYW4gdGhlbiBhZHZlcnRpc2UgYSBkaWZmZXJlbnQgZm9vdHByaW50L2Nh cGFiaWxpdGllcyB0byB0aGUgdUNETi4gSSBkb24ndCBzZWUgc3VjaCBuZWdvdGlhdGlvbnMgb2Nj dXJyaW5nIGF0IHRoZSBwcm90b2NvbCBsYXllciBpbiBwcmFjdGljZSBhbmQgc28gQ0ROSSBkb2Vz bid0IHJlcXVpcmUgYSBmb290cHJpbnQvY2FwYWJpbGl0aWVzIG5lZ290aWF0aW9uIHN0YXRlIG1h Y2hpbmUuDQoNCkJlbg0KDQoNCi1IYWliaW4NCg0KRnJvbTogY2RuaS1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgYW5uZS5tYXJyZWNAb3JhbmdlLmNvbTxtYWlsdG86YW5uZS5tYXJy ZWNAb3JhbmdlLmNvbT4NClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMTYsIDIwMTIgMTA6MDAgUE0N ClRvOiBKYW4gU2VlZG9yZjsgY2RuaS1mb290cHJpbnRAaWV0Zi5vcmc8bWFpbHRvOmNkbmktZm9v dHByaW50QGlldGYub3JnPg0KQ2M6IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW0NETmldIFtjZG5pLWZvb3RwcmludF0gVGhvdWdodHMgb24gdGhlICdD RE5JIEZvb3RwcmludC9DYXBhYmlsaXRpZXMgRGVzaWduIFRlYW0gQ2FsbCcNCg0KDQoNCkRlIDog SmFuIFNlZWRvcmYgW21haWx0bzpKYW4uU2VlZG9yZkBuZWNsYWIuZXVdDQpFbnZvecOpIDogbWFy ZGkgMTYgb2N0b2JyZSAyMDEyIDE1OjI2DQrDgCA6IE1BUlJFQyBBbm5lIE9MTkMvT0xOOyBjZG5p LWZvb3RwcmludEBpZXRmLm9yZzxtYWlsdG86Y2RuaS1mb290cHJpbnRAaWV0Zi5vcmc+DQpDYyA6 IGNkbmlAaWV0Zi5vcmc8bWFpbHRvOmNkbmlAaWV0Zi5vcmc+DQpPYmpldCA6IFJFOiBSZTogW2Nk bmktZm9vdHByaW50XSBUaG91Z2h0cyBvbiB0aGUgJ0NETkkgRm9vdHByaW50L0NhcGFiaWxpdGll cyBEZXNpZ24gVGVhbSBDYWxsJw0KDQpIaSBBbm5lIGFuZCBFbWlsZSwNCg0KVGhhbmtzIGZvciBz aGFyaW5nIHRoaXMgdXNlIGNhc2UgYW5kIHRoZSBkZXRhaWxlZCBleGFtcGxlcy4gSXQgaXMgYWxs IGNsZWFyIHRvIG1lLCBhbmQgSSB0aGluayBnb29kIGlucHV0IHRvIG91ciBkaXNjdXNzaW9ucy4N Cg0KVHdvIHF1aWNrIGNvbW1lbnRzICh3ZSBjYW4gZGlzY3VzcyBtb3JlIGluIHRoZSBjYWxsIHRv ZGF5KToNCg0KLSAgICAgICAgICBBY2NvcmRpbmcgdG8geW91ciBleGFtcGxlLCDigJxjYXBhYmls aXRpZXNfdXBkYXRlc+KAnSBtdXN0IG5vdCBvbmx5IGluY2x1ZGUg4oCcb3BlcmF0aW9uYWzigJ0g b3Ig4oCcbm9uLW9wZXJhdGlvbmFs4oCdLCBidXQgcHJvYmFibHkg4oCccGFydGlhbGx5LW9wZXJh dGlvbmFs4oCdIHBsdXMgc29tZSBzcGVjaWZpY2F0aW9uIHdoYXQgcGFydGlhbGx5IG1lYW5zOw0K W0FNXSDigJxwYXJ0aWFsbHlfb3BlcmF0aW9ubmVs4oCdIG1lYW5zIHRoZXQgdGhlIOKAnHNlcnZp Y2XigJ0gaXMgbm90IGFueW1vcmUgc3VwcG9ydGVkIGJ5IHRoZSBkQ0ROIGFzIGl0IHdhcyBvcmln aW5hbGx5IHNwZWNpZmllZA0KDQotICAgICAgICAgIFdoYXQgYWJvdXQgdGhlIGNhc2Ugd2hlcmUg Y2FwYWJpbGl0aWVzIHVwZGF0ZXMgbWF5IGNvbnRhaW4gYSByZWZlcnJhbCB0byBhIGdpdmVuIGZv b3RwcmludCwgYXMgd2UgaGF2ZSBkaXNjdXNzZWQsIGUuZy4gdGhlIOKAnHBhcnRpYWxseS1vcGVy YXRpb25hbOKAnSB1cGRhdGUgZnJvbSBCIHRvIEEgc2hhbGwgaW5kaWNhdGUgdGhhdCBCIGNhbiBv bmx5IHNlcnZlIFJUTVAgaW4gc29tZSBwYXJ0cyBvZiBFdXJvcGU/IERvIHlvdSBhZ3JlZSB0byB0 aGlzIHNjZW5hcmlvIGFuZCB0aGF0IGl0IHNob3VsZCBiZSBzdXBwb3J0ZWQ/DQpbQU1dIFllcywg dGhpcyBzY2VuYXJpbyBzaG91bGQgYmUgc3VwcG9ydGVk4oCmIG1vcmUgdGhpbmtzIGFyZSBuZWNl c3NhcnkgdG8gZGVzY3JpYmUgaG93IHRoZSBtb2RpZmllZCBwYXJhbWV0ZXIgaGF2ZSB0byBiZSBz cGVjaWZpZWQNCg0KDQotICAgICAgICAgIEphbg0KDQoNCkZyb206IGNkbmktZm9vdHByaW50LWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNkbmktZm9vdHByaW50LWJvdW5jZXNAaWV0Zi5vcmc+IFtt YWlsdG86Y2RuaS1mb290cHJpbnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGFubmUu bWFycmVjQG9yYW5nZS5jb208bWFpbHRvOmFubmUubWFycmVjQG9yYW5nZS5jb20+DQpTZW50OiBN b25kYXksIE9jdG9iZXIgMTUsIDIwMTIgNDoxNyBQTQ0KVG86IGNkbmktZm9vdHByaW50QGlldGYu b3JnPG1haWx0bzpjZG5pLWZvb3RwcmludEBpZXRmLm9yZz4NCkNjOiBjZG5pQGlldGYub3JnPG1h aWx0bzpjZG5pQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtjZG5pLWZvb3RwcmludF0gVGhvdWdo dHMgb24gdGhlICdDRE5JIEZvb3RwcmludC9DYXBhYmlsaXRpZXMgRGVzaWduIFRlYW0gQ2FsbCcN Cg0KSGkgYWxsLA0KDQpXZSBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgdXNlIGNhc2UNCg0KQW5uZSAm IEVtaWxlDQoNCg0KVXNlIGNhc2UgZm9yIFJlcXVlc3Qgcm91dGluZyDCqyBmb290cHJpbnQgJiBj YXBhYmlsaXRpZXMgwrsNCg0KRmlndXJlIDEgc2hvd3MgdGhlIGNvbnRleHQgb2YgQ0ROIGludGVy Y29ubmVjdGlvbiB1c2VkIHRvIGlsbHVzdHJhdGUgdGhlIHVzZSBjYXNlIOKAnGZvb3RwcmludCAm IGNhcGFiaWxpdGllc+KAnS4gQW4gZXhhbXBsZSBvZiB0aGUgQ0ROSSBpbnRlcmZhY2UgUmVxdWVz dCBSb3V0aW5nL2Zvb3RwcmludCZjYXBhYmlsaXRpZXMgZXhjaGFuZ2VzIGJldHdlZW4gQ0ROIEEg YW5kIENETiBCIHdpbGwgYmUgZGV0YWlsZWQuDQoNCg0KQ0ROIEENCkNQMQ0KQ0ROIEINCkNETiBE DQpDRE4gQw0KDQoNCjxpbWFnZTAwNC5wbmc+DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCkkpICAgICAgICAgICAgICAgICAgICBVc2UgY2FzZSBhc3N1bXB0aW9u czoNCg0KQ1AgZGVtYW5kIGV4YW1wbGU6DQoNCsK3ICAgICAgICAgQSBnaXZlbiBDUDEgd2lzaGVz IHRvIGRlbGVnYXRlIHRoZSBkZWxpdmVyeSBvZiBpdHMgY29udGVudCB0byBDRE5BLiBNb3N0IG9m IENQMSBjbGllbnQgYXJlIGZyb20g4oCcRnJhbmNl4oCdIGJ1dCB3YW50cyB0aGF0IGNsaWVudCBh bGwgb3ZlciB0aGUgd29ybGQgYmUgYWxzbyBkZWxpdmVyZWQgdGhyb3VnaCBhIENETi4gSXRzIGNv bnRlbnRzIGFyZSB0d28gdHlwZXMgOg0KDQpvICAgIGNvbnRlbnQgZGVsaXZlcnMgaW4gSFRUUA0K DQpvICAgIGFuZCBjb250ZW50IGRlbGl2ZXJzIGluIFJUTVANCkNQMSBkZXNjcmliZXMgaXRzIGNv bnRlbnQgYXMgcGVyIGNsYXNzIG9mIHJlcXVlc3QsIGZvb3RwcmludCBhbmQgY2FwYWJpbGl0aWVz IHBhcmFtZXRlcnMuDQpFeGFtcGxlIG9mIENQMeKAmXMg4oCcc2VydmljZeKAnSBkZW1hbmQgZm9y IHRoZSB1c2UgY2FzZToNCuKAnENsYXNzIG9mIHJlcXVlc3TigJ06DQrigJxVUklfY2xhc3PigJ06 DQoqLy9jZG4uY3AxLmNvbS92aWRlby8qPGh0dHA6Ly9jZG4uY3AxLmNvbS92aWRlby8qPj91cmxf c2lnbmluZz3igJ1iYuKAnSYqDQoiZm9vdHByaW50IiA6DQpnZW8gPSB3b3JsZOKAnQ0K4oCccXVh bGl0eS9jYXBhYmlsaXRpZXPigJ06DQogICAgICAgICAgICAgICBtYXhEZWxpdmVyeVN0YXJ0TGF0 ZW5jeSA9IDUwMA0KDQpDRE4gaW50ZXJjb25uZWN0aW9uIG5lZ290aWF0aW9ucyBwaGFzZToNCg0K Q0ROIEEgY2FwYWJpbGl0aWVzIGNvbXBhcmVkIHRvIENQMSBkZW1hbmQgYXJlIHRoZSBmb2xsb3dp bmc6DQrigJxDbGFzcyBvZiByZXF1ZXN0IOKAnDoNCuKAnFVSSV9jbGFzc+KAnToNCiovL2Nkbi5j cDEuY29tL3ZpZGVvLyo8aHR0cDovL2Nkbi5jcDEuY29tL3ZpZGVvLyo+P3VybF9zaWduaW5nPeKA nWJi4oCdJioNCuKAnGZvb3RwcmludOKAnSA6DQpHZW89IOKAnGZyYW5jZeKAnQ0K4oCccXVhbGl0 eS9jYXBhYmlsaXRpZXPigJ0gOg0KICAgICAgICAgICAgICAgbWF4RGVsaXZlcnlTdGFydExhdGVu Y3kgPSA1MDANCg0KDQpDRE4gQSBjYXBhYmlsaXRpZXMgYXJlIG5vdCBlbm91Z2ggY29tcGFyZWQg dG8gQ1AxIGRlbWFuZCAobGltaXRlZCB0byDigJxmb290cHJpbnQvZ2VvPSBmcmFuY2UpLiBDRE4g QSBhbHJlYWR5IGhhcyBhbiBhZ3JlZW1lbnQgd2l0aCBhIGdsb2JhbCBDRE4gKENETiBEKSB0byBk ZWxpdmVyIGFueSBjb250ZW50IHRvIOKAnHdvcmxk4oCdIHdpdGggdXJsX3NpZ25pbmc94oCdYmLi gJ0gKOKAnHNlcnZpY2VfYWTigJ0gY29tcGF0aWJsZSB3aXRoIENQMSBkZW1hbmQpIGJ1dCB0aGUg cHJpY2UgaXMgdmVyeSBoaWdoLg0KQmVzaWRlLCBDRE4gQSBvcGVyYXRvciBpcyBhbHNvIGF3YXJl IHRoYXQgYW5vdGhlciBDRE4sIENETiBCLCBoYXMgdGhlIHBvc3NpYmlsaXR5IHRvIGRlbGl2ZXIg Y29udGVudCB0byDigJxFdXJvcGXigJ0gd2l0aCBhIGxvd2VyIHByaWNlIHRoYW4gQ0ROIEQuDQoN CiAgICAgICAgICAgICAgICAxKSBDRE4gQSBub3RlcyB0aGUgQ1AxIGRlbWFuZA0KMikgQ0ROIEEg Y29udGFjdHMgQ0ROIEIgb3BlcmF0b3IgYW5kIGRlbWFuZCBDRE4gQiBjYXBhYmlsaXRpZXMgY29t cGFyZWQgdG8gQ1AxIGRlbWFuZC4NCjMpIENETiBCIG5vdGVzIHRoZSBDRE4gQSBkZW1hbmQgYW5k IHZlcmlmeSBpZiBpdCBjYW4gbWFuYWdlIHRoZSBDRE5BIGRlbWFuZC4NCg0KQ0ROIEIgY2FwYWJp bGl0aWVzIGNvbXBhcmVkIHRvIENETiBBIGRlbWFuZDoNCuKAnENsYXNzIG9mIHJlcXVlc3Qg4oCc Og0K4oCcVVJJX2NsYXNz4oCdOg0KaHR0cDovL2Nkbi5jcDEuY29tL3ZpZGVvLyo/IHVybF9zaWdu aW5nPeKAnWJi4oCdJioNCuKAnGZvb3RwcmludOKAnSA6DQpHZW89IOKAnEV1cm9wZeKAnQ0K4oCc cXVhbGl0eS9jYXBhYmlsaXRpZXPigJ0gOg0KbWF4RGVsaXZlcnlTdGFydExhdGVuY3kgPSA1MDAN Cg0KQ0ROIEIgb3ducyBjYXBhYmlsaXRpZXMgYXJlIG5vdCBlbm91Z2ggY29tcGFyZWQgdG8gQ0RO IEEgZGVtYW5kIChsaW1pdGVkIHRvIGZvb3RwcmludC9nZW894oCdZXVyb3Bl4oCdIGFuZCBwcm90 b2NvbD1IVFRQKS4NCkJ1dCBDRE4gQiBvcGVyYXRvciBhbHJlYWR5IGhhcyBhbiBhZ3JlZW1lbnQg d2l0aCBDRE4gQyB0byBkZWxpdmVyIGFueSBjb250ZW50IGluIFJUTVAgdG8g4oCcRXVyb3Bl4oCd Og0K4oCcc2VydmljZV9iY+KAnToNCuKAnENsYXNzIG9mIHJlcXVlc3Qg4oCcOg0K4oCcVVJJX2Ns YXNz4oCdOg0KcnRtcDovL2Nkbi5jcDEuY29tL3ZpZGVvLyo8aHR0cDovL2Nkbi5jcDEuY29tL3Zp ZGVvLyo+PyB1cmxfc2lnbmluZz3igJ1iYuKAnSYqDQrigJxmb290cHJpbnTigJ0gOg0KR2VvPSDi gJxFdXJvcGXigJ0NCuKAnHF1YWxpdHkvY2FwYWJpbGl0aWVz4oCdIDoNCm1heERlbGl2ZXJ5U3Rh cnRMYXRlbmN5ID0gNTAwDQpDRE4gQiBpcyBhYmxlIHRvIHNhdGlzZnkgdGhlIENETiBBIGRlbWFu ZCBmb3Ig4oCcZm9vdHByaW50L2dlbz1FdXJvcGXigJ0gd2hlbiBpdCBkZWxlZ2F0ZXMgY29udGVu dCBkZWxpdmVyZWQgaW4gUlRNUCB0byBDRE4gQy4NCg0KNCkgQ0ROIEIgYW5ub3VuY2VzIGl0cyBj YXBhYmlsaXRpZXMgdG8gQ0ROIEEgbGltaXRlZCB0byDigJxFdXJvcGXigJ0gIGNvbXBhcmVkIHRv IENETiBBIGRlbWFuZA0KDQrigJxDbGFzcyBvZiByZXF1ZXN04oCcOg0K4oCcVVJJX2NsYXNz4oCd Og0KKi8vY2RuLmNwMS5jb20vdmlkZW8vKjxodHRwOi8vY2RuLmNwMS5jb20vdmlkZW8vKj4/dXJs X3NpZ25pbmc94oCdYmLigJ0mKg0K4oCcZm9vdHByaW504oCdOg0KR2VvPSDigJxFdXJvcGXigJ0N CuKAnHF1YWxpdHkvY2FwYWJpbGl0aWVz4oCdIDoNCiAgICAgICAgICAgICAgICBtYXhEZWxpdmVy eVN0YXJ0TGF0ZW5jeSA9IDUwMA0KDQo1KSBDRE4gQSBpcyBvayBhbmQgYW4gYWdyZWVtZW50IGlz IGNvbmNsdWRlZCBiZXR3ZWVuIENETkEgYW5kIENBTiBCIG9wZXJhdG9ycyBmb3IgdGhlIGZvbGxv d2luZyBzZXJ2aWNlOg0K4oCcc2VydmljZV9hYuKAnToNCuKAnENsYXNzIG9mIHJlcXVlc3Qg4oCc Og0K4oCcVVJJX2NsYXNz4oCdOg0KKi8vY2RuLmNwMS5jb20vdmlkZW8vKjxodHRwOi8vY2RuLmNw MS5jb20vdmlkZW8vKj4/IHVybF9zaWduaW5nPeKAnWJi4oCdJioNCuKAnGZvb3RwcmludOKAnSA6 DQpHZW89IOKAnEV1cm9wZeKAnQ0K4oCccXVhbGl0eS9jYXBhYmlsaXRpZXPigJ0gOg0KbWF4RGVs aXZlcnlTdGFydExhdGVuY3kgPSA1MDANCg0KDQpbZWQubm90ZV0gVGhpcyBDRE4gaW50ZXJjb25u ZWN0aW9uIG5lZ290aWF0aW9uIHBoYXNlIGlzIG91dCBvZiBzY29wZSBvZiBJRVRGIENETkkgV0cu IEluIHRoaXMgZXhhbXBsZSwgcG90ZW50aWFsIGRDRE4gY2FwYWJpbGl0aWVzIGFyZSBrbm93biBi eSB1Q0ROIHRoYW5rcyB0byDigJxyZWxhdGlvbnNoaXDigJ0gb3IgYWxyZWFkeSBjb25jbHVkZWQg YWdyZWVtZW50LiBPbmUgY2FuIGltYWdpbmUgYW5vdGhlciB3YXkgZm9yIHRoZSB1Q0ROIHRvIGtu b3cgcG90ZW50aWFsIGRDRE4gY2FwYWJpbGl0aWVzOiBwb3RlbnRpYWwgZENETiBjYXBhYmlsaXRp ZXMgYXV0b21hdGljIGFkdmVydGlzZW1lbnQgZGlyZWN0bHkgdG8gYWxsIHBvdGVudGlhbCB1Q0RO IG9yIHRocm91Z2ggYSDigJxDRE4gY2FwYWJpbGl0eSBwb3J0YWzigJ0gYWNjZXNzaWJsZSB0byBh bGwgQ0ROcy4NCg0KDQoNCklJKSAgICAgICAgICAgICAgICAgVXNlIGNhc2U6DQoNCiAgICAgICAg ICAgICAgICBJSS0xKSBDRE4gQS0gQ0ROIEIgSW50ZXJjb25uZWN0aW9uIGluaXRpYWxpemF0aW9u IHBoYXNlDQoNCg0KQ0ROIEEgLSBDRE4gQiBpbnRlcmNvbm5lY3Rpb24gaW5pdGlhbGl6YXRpb24N Cg0KUGFyYW1ldGVycyBuZWVkZWQgdG8gaW5pdGlhbGl6ZSBDRE5JIGludGVyZmFjZXMgYmV0d2Vl biBDRE4gQSBhbmQgQ0ROIEIgKHJlcXVlc3QgUm91dGluZywgbWV0YWRhdGEgYW5kIGxvZ2dpbmcp IGZvciB0aGUgYWdyZWVkIOKAnHNlcnZpY2XigJ0gYXJlIGV4Y2hhbmdlZCB2aWEgdGhlIGNvbnRy b2wgaW50ZXJmYWNlLiBUaGVzZSBwYXJhbWV0ZXJzIHdpbGwgYmUgdXNlZCB0byBjb25maWd1cmUg Q0ROIEEgYW5kIENETiBCLg0KQW1vbmcgdGhvc2UsIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycyBh cmUgbmVlZGVkIHRvIGluaXRpYWxpemUgdGhlIFJlcXVlc3QgUm91dGluZyBpbnRlcmZhY2UgYWNj b3JkaW5nbHkgdG8gdGhlIGFncmVlZCDigJxzZXJ2aWNlX2Fi4oCdOg0KDQpTZXJ2aWNlX2lkIDog 4oCcc2VydmljZV9hYuKAnQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCuKAnENs YXNzIG9mIHJlcXVlc3Qg4oCcOg0KICAgICAgICAgICAgICAgew0K4oCcVVJJX2NsYXNz4oCdOg0K Ki8vY2RuLmNwMS5jb20vdmlkZW8vKjxodHRwOi8vY2RuLmNwMS5jb20vdmlkZW8vKj4/IHVybF9z aWduaW5nPeKAnWJi4oCdJioNCuKAnGZvb3RwcmludOKAnSA6DQpHZW89IOKAnEV1cm9wZeKAnQ0K fQ0K4oCccXVhbGl0eS9jYXBhYmlsaXRpZXPigJ0gOg0KbWF4RGVsaXZlcnlTdGFydExhdGVuY3kg PSA1MDANCn0NCg0KQ0ROIEEgLSBDRE4gQiBSZXF1ZXN0IFJvdXRpbmcvZm9vdHByaW50JmNhcGFi aWxpdGllcyBOb3RpZmljYXRpb24NCg0KT25jZSBDRE4gQSBhbmQgQ0ROIEIgYXJlIGNvbmZpZ3Vy ZWQgYW5kIG9wZXJhdGlvbmFsLCBDRE4gQiAoZENETikgYWR2ZXJ0aXplcyBDRE4gQSAodUNETikg d2l0aCByZXF1ZXN0IHJvdXRpbmcgaW5mb3JtYXRpb24gdmlhIHRoZSBSZXF1ZXN0IFJvdXRpbmcv Zm9vdHByaW50IGFuZCBjYXBhYmlsaXRpZXMgaW50ZXJmYWNlLg0KDQpDRE4gQSAoZENETikgc2Vu ZHMgYSBSZXF1ZXN0IFJvdXRpbmcgaW5mb3JtYXRpb24gbm90aWZpY2F0aW9uIHRvIENETiBCICh1 Q0ROKS4gVGhpcyBub3RpZmljYXRpb24gaW5jbHVkZXMgdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJz Og0KU2VydmljZSA6DQogICAgICB7DQogICAgICAgICAgU2VydmljZV9pZCA9IHNlcnZpY2VfYWIN CiAgICAgICAgICAgU3RhdHVzID0gb3BlcmF0aW9uYWwNCiAgICAgfQ0KDQpBZnRlciBDRE4gQSBo YXMgcmVjZWl2ZWQgdGhpcyBSZXF1ZXN0IHJvdXRpbmcgaW5mb3JtYXRpb24gbm90aWZpY2F0aW9u LCBhbiBleGFtcGxlIG9mIGl0cyBzZWxlY3Rpb24gYWxnb3JpdGhtIGNvdWxkIGJlIGFzIGZvbGxv d2luZyAoYXMgYW4gZXhhbXBsZSBhbmQgZm9yIGluZm9ybWF0aW9uIG9ubHkpDQoNCklmIHRoZSBF bmQtdXNlciByZXF1ZXN0IG9mIGNvbnRlbnQgbWF0Y2hlcyB0aGUgY2xhc3Mgb2YgcmVxdWVzdCDi gJwqLy9jZG4uY3AxLmNvbS92aWRlby8qPGh0dHA6Ly9jZG4uY3AxLmNvbS92aWRlby8qPj8gdXJs X3NpZ25pbmc94oCdYmLigJ0mKuKAnQ0KQW5kDQp7DQpJZiAgdGhlIElQIHNvdXJjZSBhZGRyZXNz IGJlbG9uZ3MgdG8gdGhlIGZvb3RwcmludC9nZW894oCdRnJhbmNl4oCdDQogICAgICB0aGVuLCB0 aGUgZGVsaXZlcnkgb2YgdGhlIHJlcXVlc3RlZCBjb250ZW50IGlzIGRvbmUgYnkgdGhlIENETiBB IGl0c2VsZg0KICAgICAgZWxzZSB7DQppZiB0aGUgSVAgc291cmNlIGFkZHJlc3MgYmVsb25ncyB0 byB0aGUgZm9vdHByaW50L2dlbz3igJ1FdXJvcGXigJ0gdGhlbiwgdGhlIGRlbGl2ZXJ5IG9mIHRo ZSByZXF1ZXN0ZWQgY29udGVudCBpcyBkZWxlZ2F0ZWQgdG8gQ0ROIEIgKHdoaWNoIHdpbGwgZGVs ZWdhdGUgaXQgdG8gQ0ROIEMgaWYgcHJvdG9jb2wgPSDigJxSVE1Q4oCdKQ0KZWxzZSB7DQoNCmlm IHRoZSBJUCBzb3VyY2UgYWRkcmVzcyBiZWxvbmdzIHRvIHRoZSBmb290cHJpbnQvZ2VvPeKAnVdv cmxk4oCdIHRoZW4sIHRoZSBkZWxpdmVyeSBvZiB0aGUgcmVxdWVzdGVkIGNvbnRlbnQgaXMgZGVs ZWdhdGVkIHRvIENETiBEDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAg ICAgIH0NCg0KICAgICAgICAgICAgICAgIElJLTIpIFJlcXVlc3Qgcm91dGluZyBpbmZvcm1hdGlv biBtb2RpZmljYXRpb24NCg0KQSBwcm9ibGVtIG9jY3VycyBvbiBDRE4gQyBzbyB0aGF0IGl0IGlz IG5vdCBhYmxlIHRvIGRlbGl2ZXIgYW55bW9yZSBjb250ZW50IHVzaW5nIFJUTVAuDQpDRE4gQSBt dXN0IG5vdyBzZWxlY3RzIENETiBEIGZvciB0aGUgZGVsaXZlcnkgb2YgQ1Ax4oCZcyBjb250ZW50 IGluIFJUTVAgZm9yIGNsaWVudCBvdGhlciB0aGFuIGluIEZyYW5jZS4NCg0KUmVxdWVzdCBSb3V0 aW5nL2Zvb3RwcmludCZjYXBhYmlsaXRpZXMgTm90aWZpY2F0aW9ucw0KDQpDRE4gQyAtIENETiBC IFJlcXVlc3QgUm91dGluZy9mb290cHJpbnQmY2FwYWJpbGl0aWVzIE5vdGlmaWNhdGlvbg0KDQpD RE4gQyB3aWxsIHRoZW4gc2VuZCBhIHJlcXVlc3Qgcm91dGluZyBpbmZvcm1hdGlvbiBub3RpZmlj YXRpb24gdG8gQ0ROIEINClRoaXMgbm90aWZpY2F0aW9uIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcg cGFyYW1ldGVyczoNClNlcnZpY2UgOg0KICAgICAgew0KICAgICAmbmJzDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KY2RuaS1mb290cHJpbnQgbWFpbGlu ZyBsaXN0DQpjZG5pLWZvb3RwcmludEBpZXRmLm9yZzxtYWlsdG86Y2RuaS1mb290cHJpbnRAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NkbmktZm9vdHBy aW50DQo= --_000_E33E01DFD5BEA24B9F3F18671078951F23B3C193szxeml534mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIDU1IFJv bWFuIjt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiLmibnms6jmoYbmlofmnKwgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNt Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6 MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJIZWx2ZXRpY2EgNTUgUm9tYW4iO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLmibnms6jmoYbmlofm nKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOuaJueaz qOahhuaWh+acrDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4u QmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0K CWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLkJhbGxvb25UZXh0LCBsaS5C YWxsb29uVGV4dCwgZGl2LkJhbGxvb25UZXh0DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRl eHQiOw0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFt aWx5OkNvbnNvbGFzO30NCnAuSFRNTFByZWZvcm1hdHRlZCwgbGkuSFRNTFByZWZvcm1hdHRlZCwg ZGl2LkhUTUxQcmVmb3JtYXR0ZWQNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk IjsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21z by1zdHlsZS1uYW1lOiJQcsOpZm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5 OkNvbnNvbGFzO30NCnAuUHJmb3JtYXRIVE1MLCBsaS5QcmZvcm1hdEhUTUwsIGRpdi5QcmZvcm1h dEhUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIjsNCgltc28tc3R5bGUt bGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJU ZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRlZGVidWxs ZXMNCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxlLWxpbms6 IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5FbWFpbFN0eWxlMzENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzUNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTQzNTMzNjU3Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjU5MjMxMzY4IDY3ODk1Mjk3 IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3ODk1Mjk5IDY3ODk1MzAxIDY3ODk1Mjk3IDY3 ODk1Mjk5IDY3ODk1MzAxO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMy NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTAxMTgzODI4MzsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTMwNTExOTk1OCAtNDk3NDk2Mzc2 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6 MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1p ZDoxNDE4NTkyOTI0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotMjAwODExMjk2NCAtODc5MDg3NDAgNjc4OTUzMjEgNjc4OTUzMjMgNjc4OTUzMTEgNjc4 OTUzMjEgNjc4OTUzMjMgNjc4OTUzMTEgNjc4OTUzMjEgNjc4OTUzMjM7fQ0KQGxpc3QgbDI6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLXVwcGVyOw0KCW1zby1sZXZlbC10 ZXh0OiIlMVwpIjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTQuMHB0Ow0KCXRleHQtaW5kZW50Oi0zNi4w cHQ7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxp c3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxl dmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZl bC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMx RjQ5N0QiPkhpIEJlbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkFj dHVhbGx5IGluIHRoZSBleGFtcGxlIGRlc2NyaWJlZCBieSBBbm5lLCB0aGUgbmVnb3RpYXRpb24g cGhhc2UgaXMgYWJvdXQgdGhlIGZvb3RwcmludC9jYXBhYmlsaXR5IGFkdmVydGlzZW1lbnQuIFRo YXQgaXMgd2hhdCBJIG1lYW4uIEkgYWdyZWUgd2l0aCB5b3VyIHBvaW50LiBUaGUgbm90ZSBiZWxv dyBpbg0KIHRoZSBleGFtcGxlIGlzIG5vdCBuZWNlc3NhcnkgYW5kIHNob3VsZCBiZSByZW1vdmVk LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+W2VkLm5vdGVdIFRoaXMgQ0ROIGludGVyY29u bmVjdGlvbiBuZWdvdGlhdGlvbiBwaGFzZSBpcyBvdXQgb2Ygc2NvcGUgb2YgSUVURiBDRE5JIFdH LiBJbiB0aGlzIGV4YW1wbGUsIHBvdGVudGlhbCBkQ0ROIGNhcGFiaWxpdGllcyBhcmUga25vd24g YnkgdUNETiB0aGFua3MgdG8g4oCccmVsYXRpb25zaGlw4oCdIG9yIGFscmVhZHkgY29uY2x1ZGVk DQogYWdyZWVtZW50LiBPbmUgY2FuIGltYWdpbmUgYW5vdGhlciB3YXkgZm9yIHRoZSB1Q0ROIHRv IGtub3cgcG90ZW50aWFsIGRDRE4gY2FwYWJpbGl0aWVzOiBwb3RlbnRpYWwgZENETiBjYXBhYmls aXRpZXMgYXV0b21hdGljIGFkdmVydGlzZW1lbnQgZGlyZWN0bHkgdG8gYWxsIHBvdGVudGlhbCB1 Q0ROIG9yIHRocm91Z2ggYSDigJxDRE4gY2FwYWJpbGl0eSBwb3J0YWzigJ0gYWNjZXNzaWJsZSB0 byBhbGwgQ0ROcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPkJSLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4tSGFpYmluPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQmVuIE5pdmVuLUplbmtpbnMgW21haWx0bzpiZW5Abml2 ZW4tamVua2lucy5jby51a10NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgT2N0b2JlciAx OCwgMjAxMiA2OjQ1IEFNPGJyPg0KPGI+VG86PC9iPiBTb25naGFpYmluPGJyPg0KPGI+Q2M6PC9i PiBhbm5lLm1hcnJlY0BvcmFuZ2UuY29tOyBKYW4gU2VlZG9yZjsgY2RuaS1mb290cHJpbnRAaWV0 Zi5vcmc7IGNkbmlAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtjZG5pLWZvb3Rw cmludF0gW0NETmldIFRob3VnaHRzIG9uIHRoZSAnQ0ROSSBGb290cHJpbnQvQ2FwYWJpbGl0aWVz IERlc2lnbiBUZWFtIENhbGwnPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGFpYmluPGJyPg0KPGJyPg0KT24gMTcg T2N0IDIwMTIsIGF0IDA3OjI0LCBTb25naGFpYmluICZsdDs8YSBocmVmPSJtYWlsdG86aGFpYmlu LnNvbmdAaHVhd2VpLmNvbSI+aGFpYmluLnNvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0QiPkV4Y2VsbGVudCB1c2UgY2FzZSBhbmQgZGlzY3Vzc2lvbiEgQW5kIEkgdGhpbmsgdGhlIG5l Z290aWF0aW9uIHBoYXNlIHNob3VsZCBiZSBpbiBzY29wZSwgd2hpY2ggc2hvdWxkIG5vdCBiZSBs ZWZ0IGFzIGEgaG9sZSBmb3IgQ0ROSS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTrlrovkvZMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+SSBkaXNhZ3JlZS4gSSBkb24ndCB0aGluayB0aGVyZSBp cyBhbnkgbmVlZCBmb3IgbmVnb3RpYXRpb24gb3IgaW4gZmFjdCBhbnkgbmVnb3RpYXRpb24gb2Nj dXJyaW5nIGF0IGFsbC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OuWui+S9kyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+VGhlIGRDRE4gYWR2ZXJ0aXNlcyB3 aGF0IGl0IGlzIGNhcGFibGUvd2lsbGluZyB0byBkbyBvbiB0aGUgYmVoYWxmIG9mIHRoZSB1Q0RO IGFuZCB0aGUgdUNETiBkZWNpZGVzIHdoZXRoZXIgaXQgd2FudHMgdG8gdXNlIHRoZSBkQ0ROIG9y IG5vdC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk65a6L5L2TIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj5BIG5lZ290aWF0aW9uIGltcGxpZXMg dGhlIGRDRE4gYWR2ZXJ0aXNlcyBzb21ldGhpbmcgdGhlIHVDRE4gZG9lc24ndCBsaWtlIGFuZCB0 aGUgdUNETiBjYW4gcmVwbHkgJnF1b3Q7dGhhdCBkb2Vzbid0IHdvcmsgZm9yIG1lIHBsZWFzZSB0 cnkgYSBkaWZmZXJlbnQgb2ZmZXImcXVvdDsgd2hlcmUgdGhlIGRDRE4gY2FuIHRoZW4NCiBhZHZl cnRpc2UgYSBkaWZmZXJlbnQgZm9vdHByaW50L2NhcGFiaWxpdGllcyB0byB0aGUgdUNETi4gSSBk b24ndCBzZWUgc3VjaCBuZWdvdGlhdGlvbnMgb2NjdXJyaW5nIGF0IHRoZSBwcm90b2NvbCBsYXll ciBpbiBwcmFjdGljZSBhbmQgc28gQ0ROSSBkb2Vzbid0IHJlcXVpcmUgYSBmb290cHJpbnQvY2Fw YWJpbGl0aWVzIG5lZ290aWF0aW9uIHN0YXRlIG1hY2hpbmUuJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OuWui+S9kyI+QmVuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4tSGFpYmluPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnIj5j ZG5pLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86Y2RuaS1ib3VuY2VzQGlldGYub3JnXQ0K PGI+T24gQmVoYWxmIE9mIDwvYj48YSBocmVmPSJtYWlsdG86YW5uZS5tYXJyZWNAb3JhbmdlLmNv bSI+YW5uZS5tYXJyZWNAb3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg T2N0b2JlciAxNiwgMjAxMiAxMDowMCBQTTxicj4NCjxiPlRvOjwvYj4gSmFuIFNlZWRvcmY7IDxh IGhyZWY9Im1haWx0bzpjZG5pLWZvb3RwcmludEBpZXRmLm9yZyI+Y2RuaS1mb290cHJpbnRAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+ Y2RuaUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtDRE5pXSBbY2RuaS1m b290cHJpbnRdIFRob3VnaHRzIG9uIHRoZSAnQ0ROSSBGb290cHJpbnQvQ2FwYWJpbGl0aWVzIERl c2lnbiBUZWFtIENhbGwnPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBKYW4gU2VlZG9yZiBbbWFpbHRvOkphbi5TZWVkb3JmQG5l Y2xhYi5ldV0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtYXJkaSAxNiBvY3RvYnJlIDIw MTIgMTU6MjY8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IE1BUlJFQyBBbm5lIE9MTkMvT0xOOyA8YSBo cmVmPSJtYWlsdG86Y2RuaS1mb290cHJpbnRAaWV0Zi5vcmciPmNkbmktZm9vdHByaW50QGlldGYu b3JnPC9hPjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gPGEgaHJlZj0ibWFpbHRvOmNkbmlAaWV0Zi5v cmciPmNkbmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSRTogUmU6IFtj ZG5pLWZvb3RwcmludF0gVGhvdWdodHMgb24gdGhlICdDRE5JIEZvb3RwcmludC9DYXBhYmlsaXRp ZXMgRGVzaWduIFRlYW0gQ2FsbCc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkhpIEFubmUgYW5kIEVtaWxlLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciBzaGFyaW5nIHRoaXMg dXNlIGNhc2UgYW5kIHRoZSBkZXRhaWxlZCBleGFtcGxlcy4gSXQgaXMgYWxsIGNsZWFyIHRvIG1l LCBhbmQgSSB0aGluayBnb29kIGlucHV0IHRvIG91ciBkaXNjdXNzaW9ucy4NCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VHdvIHF1aWNr IGNvbW1lbnRzICh3ZSBjYW4gZGlzY3VzcyBtb3JlIGluIHRoZSBjYWxsIHRvZGF5KTo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZl bDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFjY29yZGluZyB0byB5b3VyIGV4 YW1wbGUsIOKAnGNhcGFiaWxpdGllc191cGRhdGVz4oCdIG11c3Qgbm90IG9ubHkgaW5jbHVkZSDi gJxvcGVyYXRpb25hbOKAnSBvciDigJxub24tb3BlcmF0aW9uYWzigJ0sIGJ1dCBwcm9iYWJseSDi gJxwYXJ0aWFsbHktb3BlcmF0aW9uYWzigJ0gcGx1cw0KIHNvbWUgc3BlY2lmaWNhdGlvbiB3aGF0 IHBhcnRpYWxseSBtZWFuczs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+W0FNXSDigJxwYXJ0aWFsbHlfb3BlcmF0aW9ubmVs4oCdIG1l YW5zIHRoZXQgdGhlIOKAnHNlcnZpY2XigJ0gaXMgbm90IGFueW1vcmUgc3VwcG9ydGVkIGJ5IHRo ZSBkQ0ROIGFzIGl0IHdhcyBvcmlnaW5hbGx5IHNwZWNpZmllZDwvc3Bhbj48L2k+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaGF0IGFib3V0IHRoZSBjYXNlIHdoZXJl IGNhcGFiaWxpdGllcyB1cGRhdGVzIG1heSBjb250YWluIGEgcmVmZXJyYWwgdG8gYSBnaXZlbiBm b290cHJpbnQsIGFzIHdlIGhhdmUgZGlzY3Vzc2VkLCBlLmcuIHRoZSDigJxwYXJ0aWFsbHktb3Bl cmF0aW9uYWzigJ0gdXBkYXRlDQogZnJvbSBCIHRvIEEgc2hhbGwgaW5kaWNhdGUgdGhhdCBCIGNh biBvbmx5IHNlcnZlIFJUTVAgaW4gc29tZSBwYXJ0cyBvZiBFdXJvcGU/IERvIHlvdSBhZ3JlZSB0 byB0aGlzIHNjZW5hcmlvIGFuZCB0aGF0IGl0IHNob3VsZCBiZSBzdXBwb3J0ZWQ/PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltBTV0g WWVzLCB0aGlzIHNjZW5hcmlvIHNob3VsZCBiZSBzdXBwb3J0ZWTigKYgbW9yZSB0aGlua3MgYXJl IG5lY2Vzc2FyeSB0byBkZXNjcmliZSBob3cgdGhlIG1vZGlmaWVkIHBhcmFtZXRlciBoYXZlIHRv IGJlIHNwZWNpZmllZA0KPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5KYW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOmNkbmktZm9vdHBy aW50LWJvdW5jZXNAaWV0Zi5vcmciPmNkbmktZm9vdHByaW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IFs8YSBocmVmPSJtYWlsdG86Y2RuaS1mb290cHJpbnQtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRv OmNkbmktZm9vdHByaW50LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj48YSBocmVmPSJtYWlsdG86YW5uZS5tYXJyZWNAb3JhbmdlLmNvbSI+YW5uZS5tYXJyZWNAb3Jh bmdlLmNvbTwvYT48YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBPY3RvYmVyIDE1LCAyMDEyIDQ6 MTcgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpjZG5pLWZvb3RwcmludEBpZXRm Lm9yZyI+Y2RuaS1mb290cHJpbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVm PSJtYWlsdG86Y2RuaUBpZXRmLm9yZyI+Y2RuaUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtjZG5pLWZvb3RwcmludF0gVGhvdWdodHMgb24gdGhlICdDRE5JIEZvb3Rwcmlu dC9DYXBhYmlsaXRpZXMgRGVzaWduIFRlYW0gQ2FsbCc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPkhpIGFsbCw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBw cm9wb3NlIHRoZSBmb2xsb3dpbmcgdXNlIGNhc2UgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Bbm5lICZh bXA7IEVtaWxlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48dT48c3BhbiBsYW5nPSJFTi1VUyI+VXNlIGNhc2Ug Zm9yIFJlcXVlc3Qgcm91dGluZyDCqyZuYnNwO2Zvb3RwcmludCAmYW1wOyBjYXBhYmlsaXRpZXMm bmJzcDvCuzwvc3Bhbj48L3U+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPkZpZ3VyZSAxIHNob3dzIHRoZSBjb250ZXh0IG9mIENETiBpbnRlcmNvbm5lY3Rpb24gdXNl ZCB0byBpbGx1c3RyYXRlIHRoZSB1c2UgY2FzZSDigJxmb290cHJpbnQgJmFtcDsgY2FwYWJpbGl0 aWVz4oCdLiBBbiBleGFtcGxlIG9mIHRoZSBDRE5JIGludGVyZmFjZSBSZXF1ZXN0IFJvdXRpbmcv Zm9vdHByaW50JmFtcDtjYXBhYmlsaXRpZXMgZXhjaGFuZ2VzIGJldHdlZW4gQ0ROIEEgYW5kIENE TiBCIHdpbGwNCiBiZSBkZXRhaWxlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Q0ROIEE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q1AxPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PkNETiBCPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNETiBEPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNE TiBDPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1h bFRhYmxlIiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgYWxpZ249 ImxlZnQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6Mi4yNXB0Ij4NCjx0ZCB3aWR0aD0i NzMiIHN0eWxlPSJ3aWR0aDo1NC43NXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDoy LjI1cHQiPjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNt IDBjbSI+PC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1l LWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9y LXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47 bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+Jmx0O2ltYWdlMDA0LnBuZyZndDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdDt0ZXh0LWluZGVudDotMzYuMHB0O21zby1saXN0Omwy IGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5JKTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PGI+PHU+PHNwYW4gbGFuZz0iRU4tVVMiPlVzZSBjYXNlIGFzc3VtcHRpb25zOiA8L3NwYW4+ DQo8L3U+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHU+PHNwYW4gbGFuZz0iRU4tVVMiPkNQIGRlbWFuZCBleGFtcGxlOjwvc3Bhbj48L3U+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvNiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9z cGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+QSBnaXZlbiBDUDEgd2lzaGVzIHRvIGRl bGVnYXRlIHRoZSBkZWxpdmVyeSBvZiBpdHMgY29udGVudCB0byBDRE5BLiBNb3N0IG9mIENQMSBj bGllbnQgYXJlIGZyb20g4oCcRnJhbmNl4oCdIGJ1dCB3YW50cyB0aGF0IGNsaWVudCBhbGwgb3Zl ciB0aGUgd29ybGQgYmUgYWxzbyBkZWxpdmVyZWQgdGhyb3VnaCBhIENETi4gSXRzIGNvbnRlbnRz IGFyZSB0d28gdHlwZXMgOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDIgbGZvNiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+Y29udGVudCBkZWxpdmVycyBp biBIVFRQIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwyIGxmbzYiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+bzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPmFuZCBjb250ZW50IGRlbGl2ZXJzIGluIFJUTVA8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q1AxIGRlc2NyaWJlcyBpdHMgY29udGVu dCBhcyBwZXIgY2xhc3Mgb2YgcmVxdWVzdCwgZm9vdHByaW50IGFuZCBjYXBhYmlsaXRpZXMgcGFy YW1ldGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RXhhbXBsZSBvZiBDUDHi gJlzIOKAnHNlcnZpY2XigJ0gZGVtYW5kIGZvciB0aGUgdXNlIGNhc2U6PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPuKAnENsYXNzIG9mIHJlcXVlc3TigJ06PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNi4ycHQi PjxzcGFuIGxhbmc9IkVOLVVTIj7igJxVUklfY2xhc3PigJ06PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE0MS42cHQiPjxzcGFu IGxhbmc9IkZSIj48YSBocmVmPSJodHRwOi8vY2RuLmNwMS5jb20vdmlkZW8vKiI+PHNwYW4gbGFu Zz0iRU4tVVMiPiovL2Nkbi5jcDEuY29tL3ZpZGVvLyo8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPj91cmxfc2lnbmluZz3igJ1iYuKA nSZhbXA7Kjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNi4ycHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mcXVvdDtmb290cHJpbnQmcXVvdDsgOg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE0MS42cHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5nZW8gPSB3b3JsZOKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFuIGxhbmc9IkVO LVVTIj7igJxxdWFsaXR5L2NhcGFiaWxpdGllc+KAnToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDYuMnB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG1heERlbGl2ZXJ5U3RhcnRM YXRlbmN5ID0gNTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjxzcGFuIGxhbmc9IkVO LVVTIj5DRE4gaW50ZXJjb25uZWN0aW9uIG5lZ290aWF0aW9ucyBwaGFzZTo8L3NwYW4+PC91Pjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNETiBBIGNhcGFiaWxpdGllcyBjb21w YXJlZCB0byBDUDEgZGVtYW5kIGFyZSB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFu IGxhbmc9IkVOLVVTIj7igJxDbGFzcyBvZiByZXF1ZXN0IOKAnDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA2LjJwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPuKAnFVSSV9jbGFzc+KAnTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTQxLjZwdCI+PHNwYW4gbGFu Zz0iRlIiPjxhIGhyZWY9Imh0dHA6Ly9jZG4uY3AxLmNvbS92aWRlby8qIj48c3BhbiBsYW5nPSJF Ti1VUyI+Ki8vY2RuLmNwMS5jb20vdmlkZW8vKjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+P3VybF9zaWduaW5nPeKAnWJi4oCdJmFt cDsqPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA2LjJwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPuKAnGZvb3RwcmludOKAnSA6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNi4ycHQ7dGV4dC1pbmRlbnQ6MzUuNHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+R2VvPSDigJxmcmFuY2XigJ08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+4oCccXVhbGl0eS9jYXBhYmlsaXRpZXPigJ0gOg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNi4y cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWF4RGVs aXZlcnlTdGFydExhdGVuY3kgPSA1MDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0O3RleHQtaW5kZW50OjM1LjRwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q0ROIEEgY2FwYWJpbGl0 aWVzIGFyZSBub3QgZW5vdWdoIGNvbXBhcmVkIHRvIENQMSBkZW1hbmQgKGxpbWl0ZWQgdG8g4oCc Zm9vdHByaW50L2dlbz0gZnJhbmNlKS4gQ0ROIEEgYWxyZWFkeSBoYXMgYW4gYWdyZWVtZW50IHdp dGggYSBnbG9iYWwgQ0ROIChDRE4gRCkgdG8gZGVsaXZlciBhbnkgY29udGVudCB0byDigJx3b3Js ZOKAnSB3aXRoDQogdXJsX3NpZ25pbmc94oCdYmLigJ0gKOKAnHNlcnZpY2VfYWTigJ0gY29tcGF0 aWJsZSB3aXRoIENQMSBkZW1hbmQpIGJ1dCB0aGUgcHJpY2UgaXMgdmVyeSBoaWdoLg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlc2lkZSwgQ0ROIEEgb3BlcmF0b3IgaXMgYWxz byBhd2FyZSB0aGF0IGFub3RoZXIgQ0ROLCBDRE4gQiwgaGFzIHRoZSBwb3NzaWJpbGl0eSB0byBk ZWxpdmVyIGNvbnRlbnQgdG8g4oCcRXVyb3Bl4oCdIHdpdGggYSBsb3dlciBwcmljZSB0aGFuIENE TiBELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEpIENETiBBIG5vdGVzIHRoZSBDUDEgZGVtYW5k DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+MikgQ0ROIEEgY29udGFjdHMgQ0RO IEIgb3BlcmF0b3IgYW5kIGRlbWFuZCBDRE4gQiBjYXBhYmlsaXRpZXMgY29tcGFyZWQgdG8gQ1Ax IGRlbWFuZC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4zKSBDRE4gQiBub3Rl cyB0aGUgQ0ROIEEgZGVtYW5kIGFuZCB2ZXJpZnkgaWYgaXQgY2FuIG1hbmFnZSB0aGUgQ0ROQSBk ZW1hbmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNETiBC IGNhcGFiaWxpdGllcyBjb21wYXJlZCB0byBDRE4gQSBkZW1hbmQ6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPuKAnENsYXNzIG9mIHJlcXVlc3Qg4oCcOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDYuMnB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+4oCcVVJJX2NsYXNz4oCdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxNDEuNnB0Ij48c3BhbiBs YW5nPSJGUiI+PGEgaHJlZj0iaHR0cDovL2Nkbi5jcDEuY29tL3ZpZGVvLyoiPjxzcGFuIGxhbmc9 IkVOLVVTIj5odHRwOi8vY2RuLmNwMS5jb20vdmlkZW8vKjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PyB1cmxfc2lnbmluZz3igJ1i YuKAnSZhbXA7Kjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNi4ycHQiPjxzcGFu IGxhbmc9IkVOLVVTIj7igJxmb290cHJpbnTigJ0gOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxNDEuNnB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+R2VvPSDigJxFdXJvcGXigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+4oCccXVhbGl0eS9jYXBhYmlsaXRpZXPigJ0gOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNi4ycHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5tYXhEZWxpdmVyeVN0YXJ0TGF0ZW5jeSA9IDUwMDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q0ROIEIgb3ducyBjYXBhYmlsaXRpZXMgYXJl IG5vdCBlbm91Z2ggY29tcGFyZWQgdG8gQ0ROIEEgZGVtYW5kIChsaW1pdGVkIHRvIGZvb3Rwcmlu dC9nZW894oCdZXVyb3Bl4oCdIGFuZCBwcm90b2NvbD1IVFRQKS4NCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5CdXQgQ0ROIEIgb3BlcmF0b3IgYWxyZWFkeSBoYXMgYW4gYWdyZWVt ZW50IHdpdGggQ0ROIEMgdG8gZGVsaXZlciBhbnkgY29udGVudCBpbiBSVE1QIHRvIOKAnEV1cm9w ZeKAnTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+4oCcc2VydmljZV9iY+KAnTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MTA2LjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPuKAnENsYXNzIG9mIHJlcXVlc3Qg4oCc OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDoxNDEuNnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+4oCcVVJJX2NsYXNz4oCdOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoxNzcuMHB0Ij48c3BhbiBsYW5nPSJGUiI+PGEgaHJlZj0iaHR0cDovL2Nkbi5jcDEuY29tL3Zp ZGVvLyoiPjxzcGFuIGxhbmc9IkVOLVVTIj5ydG1wOi8vY2RuLmNwMS5jb20vdmlkZW8vKjwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ PyB1cmxfc2lnbmluZz3igJ1iYuKAnSZhbXA7Kjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjE0MS42cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj7igJxmb290cHJpbnTigJ0gOjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox NzcuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+R2VvPSDigJxFdXJvcGXigJ08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA2LjJw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPuKAnHF1YWxpdHkvY2FwYWJpbGl0aWVz4oCdIDoNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoxNDEuNnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+bWF4RGVsaXZlcnlTdGFydExhdGVuY3kgPSA1 MDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q0ROIEIgaXMgYWJsZSB0byBzYXRp c2Z5IHRoZSBDRE4gQSBkZW1hbmQgZm9yIOKAnGZvb3RwcmludC9nZW89RXVyb3Bl4oCdIHdoZW4g aXQgZGVsZWdhdGVzIGNvbnRlbnQgZGVsaXZlcmVkIGluIFJUTVAgdG8gQ0ROIEMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE0 MS42cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+NCkgQ0ROIEIgYW5ub3VuY2VzIGl0cyBjYXBhYmlsaXRpZXMgdG8gQ0ROIEEgbGlt aXRlZCB0byDigJxFdXJvcGXigJ0mbmJzcDsgY29tcGFyZWQgdG8gQ0ROIEEgZGVtYW5kPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxzcGFuIGxh bmc9IkVOLVVTIj7igJxDbGFzcyBvZiByZXF1ZXN04oCcOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDYuMnB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+4oCcVVJJX2NsYXNz4oCdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxNDEuNnB0Ij48c3BhbiBsYW5nPSJG UiI+PGEgaHJlZj0iaHR0cDovL2Nkbi5jcDEuY29tL3ZpZGVvLyoiPjxzcGFuIGxhbmc9IkVOLVVT Ij4qLy9jZG4uY3AxLmNvbS92aWRlby8qPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4/dXJsX3NpZ25pbmc94oCdYmLigJ0mYW1wOyo8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDYuMnB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+4oCcZm9vdHByaW504oCdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMDYuMnB0O3RleHQtaW5kZW50OjM1LjRwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPkdlbz0g4oCcRXVyb3Bl4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPuKAnHF1YWxpdHkvY2FwYWJpbGl0aWVz4oCdIDoNCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MC44cHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWF4RGVs aXZlcnlTdGFydExhdGVuY3kgPSA1MDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjUpIENETiBBIGlzIG9rIGFu ZCBhbiBhZ3JlZW1lbnQgaXMgY29uY2x1ZGVkIGJldHdlZW4gQ0ROQSBhbmQgQ0FOIEIgb3BlcmF0 b3JzIGZvciB0aGUgZm9sbG93aW5nIHNlcnZpY2U6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPuKAnHNlcnZpY2VfYWLigJ06PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNi4ycHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij7igJxDbGFzcyBvZiByZXF1ZXN0IOKAnDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTQxLjZwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPuKAnFVSSV9jbGFzc+KAnTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTc3LjBwdCI+PHNwYW4gbGFuZz0iRlIiPjxhIGhy ZWY9Imh0dHA6Ly9jZG4uY3AxLmNvbS92aWRlby8qIj48c3BhbiBsYW5nPSJFTi1VUyI+Ki8vY2Ru LmNwMS5jb20vdmlkZW8vKjwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdCI+PyB1cmxfc2lnbmluZz3igJ1iYuKAnSZhbXA7Kjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE0MS42cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj7igJxm b290cHJpbnTigJ0gOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxNzcuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+R2VvPSDigJxF dXJvcGXigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTA2LjJwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPuKAnHF1YWxpdHkvY2Fw YWJpbGl0aWVz4oCdIDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxNDEuNnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+bWF4RGVs aXZlcnlTdGFydExhdGVuY3kgPSA1MDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTQxLjZwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDoxNDEuNnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1 LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPltlZC5ub3RlXSBUaGlzIENETiBpbnRlcmNvbm5lY3Rp b24gbmVnb3RpYXRpb24gcGhhc2UgaXMgb3V0IG9mIHNjb3BlIG9mIElFVEYgQ0ROSSBXRy4gSW4g dGhpcyBleGFtcGxlLCBwb3RlbnRpYWwgZENETiBjYXBhYmlsaXRpZXMgYXJlIGtub3duIGJ5IHVD RE4gdGhhbmtzIHRvIOKAnHJlbGF0aW9uc2hpcOKAnSBvciBhbHJlYWR5IGNvbmNsdWRlZA0KIGFn cmVlbWVudC4gT25lIGNhbiBpbWFnaW5lIGFub3RoZXIgd2F5IGZvciB0aGUgdUNETiB0byBrbm93 IHBvdGVudGlhbCBkQ0ROIGNhcGFiaWxpdGllczogcG90ZW50aWFsIGRDRE4gY2FwYWJpbGl0aWVz IGF1dG9tYXRpYyBhZHZlcnRpc2VtZW50IGRpcmVjdGx5IHRvIGFsbCBwb3RlbnRpYWwgdUNETiBv ciB0aHJvdWdoIGEg4oCcQ0ROIGNhcGFiaWxpdHkgcG9ydGFs4oCdIGFjY2Vzc2libGUgdG8gYWxs IENETnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40 cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdDt0ZXh0LWlu ZGVudDotMzYuMHB0O21zby1saXN0OmwyIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5JSSk8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxiPjx1PjxzcGFuIGxhbmc9IkVOLVVTIj5Vc2UgY2FzZTogPC9zcGFuPjwvdT48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElJLTEpIDx1PkNE TiBBLSBDRE4gQiBJbnRlcmNvbm5lY3Rpb24gaW5pdGlhbGl6YXRpb24gcGhhc2U8L3U+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48dT48c3BhbiBsYW5nPSJFTi1VUyI+Q0RO IEEgLSBDRE4gQiBpbnRlcmNvbm5lY3Rpb24gaW5pdGlhbGl6YXRpb248L3NwYW4+PC91PjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBhcmFtZXRlcnMgbmVlZGVkIHRvIGluaXRp YWxpemUgQ0ROSSBpbnRlcmZhY2VzIGJldHdlZW4gQ0ROIEEgYW5kIENETiBCIChyZXF1ZXN0IFJv dXRpbmcsIG1ldGFkYXRhIGFuZCBsb2dnaW5nKSBmb3IgdGhlIGFncmVlZCDigJxzZXJ2aWNl4oCd IGFyZSBleGNoYW5nZWQgdmlhIHRoZQ0KPGI+Y29udHJvbCBpbnRlcmZhY2U8L2I+LiBUaGVzZSBw YXJhbWV0ZXJzIHdpbGwgYmUgdXNlZCB0byBjb25maWd1cmUgQ0ROIEEgYW5kIENETiBCLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFtb25nIHRob3NlLCB0aGUgZm9sbG93aW5n IHBhcmFtZXRlcnMgYXJlIG5lZWRlZCB0byBpbml0aWFsaXplIHRoZSBSZXF1ZXN0IFJvdXRpbmcg aW50ZXJmYWNlIGFjY29yZGluZ2x5IHRvIHRoZSBhZ3JlZWQg4oCcc2VydmljZV9hYuKAnTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPlNlcnZpY2VfaWQgOiDigJxzZXJ2aWNlX2Fi4oCdPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNi4ycHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj7igJxDbGFzcyBvZiByZXF1ZXN0IOKAnDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA2LjJwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE0MS42cHQiPjxz cGFuIGxhbmc9IkVOLVVTIj7igJxVUklfY2xhc3PigJ06PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE3Ny4wcHQiPjxzcGFuIGxh bmc9IkZSIj48YSBocmVmPSJodHRwOi8vY2RuLmNwMS5jb20vdmlkZW8vKiI+PHNwYW4gbGFuZz0i RU4tVVMiPiovL2Nkbi5jcDEuY29tL3ZpZGVvLyo8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPj8gdXJsX3NpZ25pbmc94oCdYmLigJ0m YW1wOyo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxNDEuNnB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+4oCcZm9vdHByaW504oCdIDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTc3LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPkdlbz0g4oCcRXVyb3Bl4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjE0MS42cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj59 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjEwNi4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIj7igJxxdWFsaXR5L2NhcGFiaWxpdGll c+KAnSA6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MTQxLjZwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPm1heERlbGl2ZXJ5U3Rh cnRMYXRlbmN5ID0gNTAwPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNi4ycHQiPjxzcGFuIGxhbmc9IkVOLVVTIj59PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjx1PjxzcGFu IGxhbmc9IkVOLVVTIj5DRE4gQSAtIENETiBCIFJlcXVlc3QgUm91dGluZy9mb290cHJpbnQmYW1w O2NhcGFiaWxpdGllcyBOb3RpZmljYXRpb24NCjwvc3Bhbj48L3U+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+T25jZSBDRE4gQSBhbmQgQ0ROIEIgYXJlIGNvbmZpZ3VyZWQgYW5k IG9wZXJhdGlvbmFsLCBDRE4gQiAoZENETikgYWR2ZXJ0aXplcyBDRE4gQSAodUNETikgd2l0aCBy ZXF1ZXN0IHJvdXRpbmcgaW5mb3JtYXRpb24gdmlhIHRoZSBSZXF1ZXN0IFJvdXRpbmcvZm9vdHBy aW50IGFuZCBjYXBhYmlsaXRpZXMgaW50ZXJmYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+Q0ROIEEg KGRDRE4pIHNlbmRzIGEgUmVxdWVzdCBSb3V0aW5nIGluZm9ybWF0aW9uIG5vdGlmaWNhdGlvbiB0 byBDRE4gQiAodUNETikuIFRoaXMgbm90aWZpY2F0aW9uIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcg cGFyYW1ldGVyczo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48 Yj48c3BhbiBsYW5nPSJFTi1VUyI+U2VydmljZSA6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjU0LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB7Jm5ic3A7IDwvc3Bhbj4NCjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjU0LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1NlcnZpY2VfaWQgPSBzZXJ2aWNl X2FiPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBTdGF0dXMgPSBvcGVyYXRpb25hbDwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4w cHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+QWZ0ZXIgQ0ROIEEgaGFzIHJlY2VpdmVkIHRoaXMgUmVxdWVzdCByb3V0aW5n IGluZm9ybWF0aW9uIG5vdGlmaWNhdGlvbiwgYW4gZXhhbXBsZSBvZiBpdHMgc2VsZWN0aW9uIGFs Z29yaXRobSBjb3VsZCBiZSBhcyBmb2xsb3dpbmcgKGFzIGFuIGV4YW1wbGUgYW5kIGZvciBpbmZv cm1hdGlvbiBvbmx5KSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhlIDxiPkVu ZC11c2VyIHJlcXVlc3Qgb2YgY29udGVudDwvYj4gbWF0Y2hlcyB0aGUNCjxiPmNsYXNzIG9mIHJl cXVlc3Q8L2I+IOKAnDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PGEgaHJlZj0iaHR0cDovL2Nkbi5j cDEuY29tL3ZpZGVvLyoiPjxzcGFuIGxhbmc9IkVOLVVTIj4qLy9jZG4uY3AxLmNvbS92aWRlby8q PC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPj8gdXJsX3NpZ25pbmc94oCdYmLi gJ0mYW1wOyrigJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NzAuOHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QW5kIDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 MC44cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj57PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcwLjhwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPklmJm5ic3A7IHRoZSA8Yj5JUCBzb3VyY2UgYWRkcmVzczwvYj4gYmVsb25ncyB0byB0aGUN CjxiPmZvb3RwcmludC9nZW894oCdRnJhbmNl4oCdPC9iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlbiwgdGhlIGRlbGl2 ZXJ5IG9mIHRoZSByZXF1ZXN0ZWQgY29udGVudCBpcyBkb25lIGJ5IHRoZSBDRE4gQSBpdHNlbGY8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NTQuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGVsc2UgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDoxMDYuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+aWYgdGhlIDxi PklQIHNvdXJjZSBhZGRyZXNzPC9iPiBiZWxvbmdzIHRvIHRoZQ0KPGI+Zm9vdHByaW50L2dlbz3i gJ1FdXJvcGXigJ08L2I+IHRoZW4sIHRoZSBkZWxpdmVyeSBvZiB0aGUgcmVxdWVzdGVkIGNvbnRl bnQgaXMgZGVsZWdhdGVkIHRvIENETiBCICh3aGljaCB3aWxsIGRlbGVnYXRlIGl0IHRvIENETiBD IGlmIHByb3RvY29sID0g4oCcUlRNUOKAnSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MTA2LjJwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPmVsc2UgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxMDYuMnB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjE0MS42cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5pZiB0aGUgSVAgc291cmNlIGFkZHJlc3MgYmVs b25ncyB0byB0aGUNCjxiPmZvb3RwcmludC9nZW894oCdV29ybGTigJ08L2I+IHRoZW4sIHRoZSBk ZWxpdmVyeSBvZiB0aGUgcmVxdWVzdGVkIGNvbnRlbnQgaXMgZGVsZWdhdGVkIHRvIENETiBEPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjU0LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6cmVkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NTQuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBJSS0yKSA8dT5SZXF1ZXN0IHJvdXRpbmcgaW5mb3JtYXRpb24gbW9kaWZpY2F0aW9uPC91Pjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QSBwcm9i bGVtIG9jY3VycyBvbiBDRE4gQyBzbyB0aGF0IGl0IGlzIG5vdCBhYmxlIHRvIGRlbGl2ZXIgYW55 bW9yZSBjb250ZW50IHVzaW5nIFJUTVAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNETiBBIG11c3Qgbm93IHNlbGVjdHMgQ0RO IEQgZm9yIHRoZSBkZWxpdmVyeSBvZiBDUDHigJlzIGNvbnRlbnQgaW4gUlRNUCBmb3IgY2xpZW50 IG90aGVyIHRoYW4gaW4gRnJhbmNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48c3BhbiBsYW5nPSJFTi1VUyI+UmVxdWVzdCBSb3V0 aW5nL2Zvb3RwcmludCZhbXA7Y2FwYWJpbGl0aWVzIE5vdGlmaWNhdGlvbnMNCjwvc3Bhbj48L3U+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48dT48c3BhbiBs YW5nPSJFTi1VUyI+Q0ROIEMgLSBDRE4gQiBSZXF1ZXN0IFJvdXRpbmcvZm9vdHByaW50JmFtcDtj YXBhYmlsaXRpZXMgTm90aWZpY2F0aW9uDQo8L3NwYW4+PC91PjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNw YW4gbGFuZz0iRU4tVVMiPkNETiBDIHdpbGwgdGhlbiBzZW5kIGEgcmVxdWVzdCByb3V0aW5nIGlu Zm9ybWF0aW9uIG5vdGlmaWNhdGlvbiB0byBDRE4gQjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIj5UaGlzIG5vdGlmaWNhdGlvbiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFt ZXRlcnM6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiPlNlcnZpY2UgOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNS40cHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgeyZuYnNwOyA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz NS40cHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmYW1wO25iczwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 5a6L5L2TIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCmNkbmktZm9vdHByaW50IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjZG5p LWZvb3RwcmludEBpZXRmLm9yZyI+Y2RuaS1mb290cHJpbnRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pLWZvb3Rwcmlu dCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZG5pLWZvb3RwcmludDwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E33E01DFD5BEA24B9F3F18671078951F23B3C193szxeml534mbxchi_-- From Jan.Seedorf@neclab.eu Fri Oct 19 06:36:35 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 7E0C121F86AC; Fri, 19 Oct 2012 06:36:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.506 X-Spam-Level: X-Spam-Status: No, score=-103.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 WmoRdXKqBDAI; Fri, 19 Oct 2012 06:36:34 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF7021F86A1; Fri, 19 Oct 2012 06:36:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A0A13102265; Fri, 19 Oct 2012 15:36:33 +0200 (CEST) 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 RMWVguKP5Bzm; Fri, 19 Oct 2012 15:36:33 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 7B82F102264; Fri, 19 Oct 2012 15:36:23 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 19 Oct 2012 15:35:44 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Next Footprint/Capabilities Design Team Call Thread-Index: Ac2t/pHghhpl7PJaQ6WgBGEgIzOD1g== Date: Fri, 19 Oct 2012 13:35:43 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5537DA82@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.7.0.214] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Next 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: Fri, 19 Oct 2012 13:36:35 -0000 Hi all, According to the doodle, next week WED or THU seem to be the best options f= or the next call. I suggest having the call on THU: ** Thursday, Oct 25th, 16:00-18:00 CET ** Stefano, would you be so kind to set up once again WebEx for the call? Thanks, Jan > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Jan Seedorf > Sent: Wednesday, October 17, 2012 4:28 PM > To: cdni-footprint@ietf.org > Cc: cdni@ietf.org > Subject: [cdni-footprint] Notes from yesterday's Footprint/Capabilities > Design Team Call and next steps >=20 > Hi all, >=20 > Thanks to all for the good discussions yesterday. Below are my notes from > yesterday's call. In summary, we agreed: > -- (at least for the time being), take the use case circulated by Anne as= basis > for our discussions > -- aim at having at least one more phone call before Atlanta > -- next step is to start the discussion on what capabilities are mandator= y to > have in advertisement for the use case posted by Anne >=20 > I set up a doodle for the next call, please fill it in asap: > http://www.doodle.com/8e79wgv2d9e42qnc >=20 > ** > -- Jan explains what was discussed last week and that the plan is to agre= e on > some key use cases to drive the capabilities discussion > -- Anne summarizes the use case that she sent around > -- question from Jon regarding what "URI_class": > *//cdn.cp1.com/video/*?url_signing=3D"bb"&* means > -- Yannick explains rationale behind use case more > -- Jon: does CDN-B need to have a relationship with CP-1 in the use case? > Yannick: no necessarily > -- Jon: what does CDN-B need to know regarding a URI? > -- Jan summarizes use cases posted by Scott on the mailing list > -- Jon: we still need to find out what needs to be part of the advertisem= ent > and what part of the real-time request routing > -- Scott explains that his use cases are supposed to be basic building bl= ocks > out of which one can build more complex use case with transitive dCDN > delegation > -- discussion about "triangle aspect", i.e. CDNI loops, agreement that th= is > need to be considered > -- agreement on use case from Anne, as it also contains the interesting u= se > case posted by Scott where a "local" CDN wants to (further) delegate to a > "global" dCDN > ** >=20 >=20 > - Jan >=20 >=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.=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 wangdanhua@huawei.com Sun Oct 21 20:04:07 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 8A4F321F842E for ; Sun, 21 Oct 2012 20:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.582 X-Spam-Level: X-Spam-Status: No, score=-4.582 tagged_above=-999 required=5 tests=[AWL=1.565, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 T-SsWSCUK1iz for ; Sun, 21 Oct 2012 20:04:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1766121F841F for ; Sun, 21 Oct 2012 20:04:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKU86642; Mon, 22 Oct 2012 03:04:04 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 04:04:00 +0100 Received: from SZXEML440-HUB.china.huawei.com (10.72.61.75) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 04:04:03 +0100 Received: from SZXEML507-MBX.china.huawei.com ([169.254.8.239]) by SZXEML440-HUB.china.huawei.com ([10.72.61.75]) with mapi id 14.01.0323.003; Mon, 22 Oct 2012 11:03:54 +0800 From: Wangdanhua To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-he-cdni-routing-request-redirection-03.txt Thread-Index: AQHNsAG3onlXu9Hn+0uBEHvlKMByEJfEo4MA Date: Mon, 22 Oct 2012 03:03:54 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.177] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CDNi] =?utf-8?b?6L2s5Y+ROiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9y?= =?utf-8?q?_draft-he-cdni-routing-request-redirection-03=2Etxt?= 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, 22 Oct 2012 03:04:07 -0000 SGkgYWxsLA0KDQpXZSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LWhl LWNkbmktcm91dGluZy1yZXF1ZXN0LXJlZGlyZWN0aW9uICh2ZXJzaW9uIDAzKS4gQW55IGNvbW1l bnRzIG9yIHN1Z2dlc3Rpb25zIGFyZSBhcHByZWNpYXRlZC4NCg0KQmVzdCB3aXNoZXMsDQpEYW5o dWEgV2FuZw0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQrlj5HpgIHm l7bpl7Q6IDIwMTLlubQxMOaciDIy5pelIDExOjAzDQrmlLbku7bkuro6IFdhbmdkYW5odWENCuaK hOmAgTogY2hlbmdAZ3N0YS5jb207IGhleGlhb3lhbiAwMDIxNTk5Nzsgc3BlbmNlci5kYXdraW5z QHdvbmRlcm1hc3Rlci5jb207IHpoYW5neXVuZmVpQGNoaW5hbW9iaWxlLmNvbTsgYmVuQHZlbG9j aXguY29tOyBuaXdlaUBjaGluYW1vYmlsZS5jb20NCuS4u+mimDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1oZS1jZG5pLXJvdXRpbmctcmVxdWVzdC1yZWRpcmVjdGlvbi0wMy50 eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaGUtY2RuaS1yb3V0aW5nLXJlcXVl c3QtcmVkaXJlY3Rpb24tMDMudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFdhbmcgRGFuaHVhIChlZGl0b3IpIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRGIHJlcG9zaXRvcnku DQoNCkZpbGVuYW1lOgkgZHJhZnQtaGUtY2RuaS1yb3V0aW5nLXJlcXVlc3QtcmVkaXJlY3Rpb24N ClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIFJvdXRpbmcgUmVxdWVzdCBSZWRpcmVjdGlvbiBmb3Ig Q0ROIEludGVyY29ubmVjdGlvbg0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMjINCldHIElEOgkJ IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxOQ0KVVJMOiAgICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1oZS1jZG5pLXJv dXRpbmctcmVxdWVzdC1yZWRpcmVjdGlvbi0wMy50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1oZS1jZG5pLXJvdXRpbmctcmVxdWVzdC1y ZWRpcmVjdGlvbg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1oZS1jZG5pLXJvdXRpbmctcmVxdWVzdC1yZWRpcmVjdGlvbi0wMw0KRGlmZjogICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1oZS1jZG5pLXJvdXRp bmctcmVxdWVzdC1yZWRpcmVjdGlvbi0wMw0KDQpBYnN0cmFjdDoNCiAgIFRoZSBSZXF1ZXN0IFJv dXRpbmcgSW50ZXJmYWNlIGNvbXByaXNlcyBvZiAoMSkgdGhlIGFzeW5jaHJvbm91cw0KICAgYWR2 ZXJ0aXNlbWVudCBvZiBmb290cHJpbnQgYW5kIGNhcGFiaWxpdGllcyBieSBhIGRvd25zdHJlYW0g Q0ROIHRoYXQNCiAgIGFsbG93cyBhIHVwc3RyZWFtIENETiB0byBkZWNpZGUgd2hldGhlciB0byBy ZWRpcmVjdCBwYXJ0aWN1bGFyIHVzZXINCiAgIHJlcXVlc3RzIHRvIHRoYXQgZG93bnN0cmVhbSBD RE47IGFuZCAoMikgdGhlIHN5bmNocm9ub3VzIG9wZXJhdGlvbiBvZg0KICAgYW4gdXBzdHJlYW0g Q0ROIHJlcXVlc3Rpbmcgd2hldGhlciBhIGRvd25zdHJlYW0gQ0ROIGlzIHByZXBhcmVkIHRvDQog ICBhY2NlcHQgYSB1c2VyIHJlcXVlc3QgYW5kIG9mIGEgZG93bnN0cmVhbSBDRE4gcmVzcG9uZGlu ZyB3aXRoIGhvdyB0bw0KICAgYWN0dWFsbHkgcmVkaXJlY3QgdGhlIHVzZXIgcmVxdWVzdC4gIFRo aXMgZG9jdW1lbnQgZGVzY3JpYmVzIGFuDQogICBpbnRlcmZhY2UgZm9yIHRoZSBsYXR0ZXIgcGFy dCwgaS5lLiB0aGUgQ0ROSSBSZXF1ZXN0IFJvdXRpbmcNCiAgIFJlZGlyZWN0aW9uIGludGVyZmFj ZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From sprevidi@cisco.com Mon Oct 22 06:03:26 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 5112C21F8B79 for ; Mon, 22 Oct 2012 06:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 BhOCDn8EB0Y2 for ; Mon, 22 Oct 2012 06:03:25 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C04D321F8B76 for ; Mon, 22 Oct 2012 06:03:24 -0700 (PDT) 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 q9MD3Nqb013570 for ; Mon, 22 Oct 2012 15:03:23 +0200 (CEST) Received: from dhcp-rom2-bb-gw-vla250-10-147-74-23.cisco.com (dhcp-rom2-bb-gw-vla250-10-147-74-23.cisco.com [10.147.74.23]) by stew-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q9MD3MnP008971; Mon, 22 Oct 2012 15:03:23 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: stefano previdi In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE5537DA82@DAPHNIS.office.hd> Date: Mon, 22 Oct 2012 15:03:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87333621-8D15-4789-B2F6-3E1FEC3C4365@cisco.com> References: <2779C9F0771F974CAD742BAE6D9904FE5537DA82@DAPHNIS.office.hd> To: Jan Seedorf X-Mailer: Apple Mail (2.1283) Cc: "cdni-footprint@ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Next 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, 22 Oct 2012 13:03:26 -0000 Hi Jan, On Oct 19, 2012, at 3:35 PM, Jan Seedorf wrote: > Hi all, >=20 > According to the doodle, next week WED or THU seem to be the best = options for the next call. I suggest having the call on THU: >=20 > ** Thursday, Oct 25th, 16:00-18:00 CET ** >=20 > Stefano, would you be so kind to set up once again WebEx for the call? I will setup the bridge but I can't attend (I'm on travel until IETF = week). s. >=20 > Thanks, > Jan >=20 >> -----Original Message----- >> From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- >> bounces@ietf.org] On Behalf Of Jan Seedorf >> Sent: Wednesday, October 17, 2012 4:28 PM >> To: cdni-footprint@ietf.org >> Cc: cdni@ietf.org >> Subject: [cdni-footprint] Notes from yesterday's = Footprint/Capabilities >> Design Team Call and next steps >>=20 >> Hi all, >>=20 >> Thanks to all for the good discussions yesterday. Below are my notes = from >> yesterday's call. In summary, we agreed: >> -- (at least for the time being), take the use case circulated by = Anne as basis >> for our discussions >> -- aim at having at least one more phone call before Atlanta >> -- next step is to start the discussion on what capabilities are = mandatory to >> have in advertisement for the use case posted by Anne >>=20 >> I set up a doodle for the next call, please fill it in asap: >> http://www.doodle.com/8e79wgv2d9e42qnc >>=20 >> ** >> -- Jan explains what was discussed last week and that the plan is to = agree on >> some key use cases to drive the capabilities discussion >> -- Anne summarizes the use case that she sent around >> -- question from Jon regarding what "URI_class": >> *//cdn.cp1.com/video/*?url_signing=3D"bb"&* means >> -- Yannick explains rationale behind use case more >> -- Jon: does CDN-B need to have a relationship with CP-1 in the use = case? >> Yannick: no necessarily >> -- Jon: what does CDN-B need to know regarding a URI? >> -- Jan summarizes use cases posted by Scott on the mailing list >> -- Jon: we still need to find out what needs to be part of the = advertisement >> and what part of the real-time request routing >> -- Scott explains that his use cases are supposed to be basic = building blocks >> out of which one can build more complex use case with transitive dCDN >> delegation >> -- discussion about "triangle aspect", i.e. CDNI loops, agreement = that this >> need to be considered >> -- agreement on use case from Anne, as it also contains the = interesting use >> case posted by Scott where a "local" CDN wants to (further) delegate = to a >> "global" dCDN >> ** >>=20 >>=20 >> - Jan >>=20 >>=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 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni >=20 From flefauch@cisco.com Mon Oct 22 09:18: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 980BA21F8923 for ; Mon, 22 Oct 2012 09:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAmnDM7VsLIO for ; Mon, 22 Oct 2012 09:18:31 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7C95921F887B for ; Mon, 22 Oct 2012 09:18:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2626; q=dns/txt; s=iport; t=1350922711; x=1352132311; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=aGyqQ95WEQol6cxO/GnZsIHIGxS+kU8fBayIuVCUQbs=; b=mOCOhO1R533uwcfp1Wl+9ZzjD+UKZDH2Fd0CaNKtXK3t44FwHWriNOi0 BEJ1AbE/oGlTLpPIXK3KfiLvWcod6eF0JJHhvFqQxDF/k8yu3NMgNyGa0 3Oo3/f53S75K+8zbXY2Gyqi6obln2/KGeSka4yNYhAiSENch+OscBv2Ro c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKRwhVCtJXHB/2dsb2JhbABFwRGBCIIgAQEBAwEBAQEPASc0CxACASoUECcLJQIEDgUIGodcBgucB59vi1+GD2ADkj+ESY03gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="134137673" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 22 Oct 2012 16:18:31 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q9MGIV1X008109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 16:18:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 11:18:30 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: comments on Security Considerations of draft-ietf-cdni-metadata-00.txt Thread-Index: AQHNsHDfeUvJyb3JC0iHSPY/1k/KJw== Date: Mon, 22 Oct 2012 16:18:29 +0000 Message-ID: References: <20121002173431.31982.75133.idtracker@ietfa.amsl.com> In-Reply-To: <20121002173431.31982.75133.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--34.301300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] comments on Security Considerations of draft-ietf-cdni-metadata-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: Mon, 22 Oct 2012 16:18:32 -0000 Hi, (As an individual) A few small comments on Security Considerations of draft-ietf-cdni-metadata= -00.txt: " The CDNI Metadata Interface is expected to be secured as a function of the transport protocol (e.g. HTTP authentication, HTTPS, or inter-domain IPSec). " I suggest you include references (at least for "HTTP authentication"). " If a malicious metadata server is contacted by a downstream CDN, the malicious server may provide metadata to the downstream CDN which denies service for any piece of content to any user agent. The malicious server may also provide metadata which directs a downstream CDN to a malicious origin server instead of the actual origin server. " This paragraph points out the risks, but does not indicate any remedy. (The= following paragraph points out the risk in the opposite direction and brin= gs up a remedy). Cheers Francois On 2 Oct 2012, at 19:34, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Content Delivery Networks Interconnectio= n Working Group of the IETF. >=20 > Title : CDN Interconnect Metadata > Author(s) : Ben Niven-Jenkins > Rob Murray > Grant Watson > Matt Caulfield > Kent Leung > Kevin J. Ma > Filename : draft-ietf-cdni-metadata-00.txt > Pages : 35 > Date : 2012-10-02 >=20 > Abstract: > The CDNI Metadata Interface enables interconnected CDNs to exchange > content distribution metadata in order to enable content acquisition > and delivery. The CDNI metadata associated with a piece of content > provides a downstream CDN with sufficient information for the > downstream CDN to service content requests on behalf of an upstream > CDN. This document describes both the core set of CDNI metadata and > the protocol for exchanging that metadata. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-metadata-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Oct 22 09:56:05 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 1216C21F8B46 for ; Mon, 22 Oct 2012 09:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hJ9AAzgW2Rv for ; Mon, 22 Oct 2012 09:56:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3260721F8B4D for ; Mon, 22 Oct 2012 09:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4279; q=dns/txt; s=iport; t=1350924962; x=1352134562; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ayrXOc+fsP7CWJsyHfHvh22SShGHzmvhWbGihnvuXA4=; b=SZgiDxIIMGrc+FWllndOBNvCa0zYOkJucruIL3Xyeg3Aihvokba0ljEY NySsBqeQ+z8asM2jeT35iuTDMZy+srcTTTEZ5fcLCW0AUI2Hotjwjpy8x Vj07tfwUuoY7VSCvmBZrJWlziXa9GfwsN+SmpQXeRTkW29CNhpK8C6Uv/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAGF5hVCtJV2c/2dsb2JhbABFwROBCIIgAQEBAwEBAQEPARQTMgIIAwULAgEIGAoUECcLJQIEDgUIGodcBgucDZ9yi1+GD2ADkj+ESY03gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,630,1344211200"; d="scan'208";a="134154378" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 22 Oct 2012 16:56:01 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9MGu1r2031056 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Oct 2012 16:56:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.001; Mon, 22 Oct 2012 11:56:00 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: [CDNi] comments on Security Considerations of draft-ietf-cdni-metadata-00.txt Thread-Index: AQHNsHDfeUvJyb3JC0iHSPY/1k/KJ5fF3x0A Date: Mon, 22 Oct 2012 16:56:00 +0000 Message-ID: References: <20121002173431.31982.75133.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19294.004 x-tm-as-result: No--40.119000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <524F7FDDE8FAE8459F04BA013E6591F5@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] comments on Security Considerations of draft-ietf-cdni-metadata-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: Mon, 22 Oct 2012 16:56:05 -0000 Two other suggestions: I suggest you discuss separately: * the risks associated with one end of the interface being a malicious end= , which can be addressed by authentication * the risks associated with confidentiality e.g. 3rd party eavesdropping t= he metadata exchange (e.g. to gain information such as acquisition/credenti= al information), which can be addressed by confidentiality protection mecha= nisms such as encryption. * the risks associated with integrity e.g. 3rd party intercepting and modi= fying the metadata exchange , which can be addressed by integrity protectio= n mechanisms such as encryption. And then indicate which protection can be provided in each direction by eac= h mechanism you mention (e.g. HTTPs provides auth + confidentiality + integ= rity protection, in both S-->C and C-->S directions)=20 I suggest you discuss the risks of DoS attack on the Metadata server: i.e. = one dCDN deliberately/inadvertently overloads uCDN Metadata server, prevent= ing another dCDN from obtaining metadata. I'd expect that such risk would b= e fairly low considering that serving metadata is fairly low load (i.e. no = processing involved). It could also be mitigated by access control mechanis= m limiting what devices can access it (e.g. to protect against Bots-based D= DOS attacks). On 22 Oct 2012, at 18:18, Francois Le Faucheur (flefauch) wrote: > Hi, >=20 > (As an individual) >=20 > A few small comments on Security Considerations of draft-ietf-cdni-metada= ta-00.txt: >=20 > " > The CDNI Metadata Interface is expected to be secured as a function > of the transport protocol (e.g. HTTP authentication, HTTPS, or > inter-domain IPSec). > " > I suggest you include references (at least for "HTTP authentication"). >=20 >=20 > " > If a malicious metadata server is contacted by a downstream CDN, the > malicious server may provide metadata to the downstream CDN which > denies service for any piece of content to any user agent. The > malicious server may also provide metadata which directs a downstream > CDN to a malicious origin server instead of the actual origin server. > " > This paragraph points out the risks, but does not indicate any remedy. (T= he following paragraph points out the risk in the opposite direction and br= ings up a remedy). >=20 > Cheers >=20 > Francois >=20 >=20 > On 2 Oct 2012, at 19:34, > wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Content Delivery Networks Interconnecti= on Working Group of the IETF. >>=20 >> Title : CDN Interconnect Metadata >> Author(s) : Ben Niven-Jenkins >> Rob Murray >> Grant Watson >> Matt Caulfield >> Kent Leung >> Kevin J. Ma >> Filename : draft-ietf-cdni-metadata-00.txt >> Pages : 35 >> Date : 2012-10-02 >>=20 >> Abstract: >> The CDNI Metadata Interface enables interconnected CDNs to exchange >> content distribution metadata in order to enable content acquisition >> and delivery. The CDNI metadata associated with a piece of content >> provides a downstream CDN with sufficient information for the >> downstream CDN to service content requests on behalf of an upstream >> CDN. This document describes both the core set of CDNI metadata and >> the protocol for exchanging that metadata. >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-cdni-metadata-00 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From choits@etri.re.kr Mon Oct 22 10:46:21 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 3DA6F11E80A5 for ; Mon, 22 Oct 2012 10:46:21 -0700 (PDT) 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=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 a5cJvA-z5u4S for ; Mon, 22 Oct 2012 10:46:20 -0700 (PDT) Received: from mailx.etri.re.kr (mailx.etri.re.kr [129.254.38.251]) by ietfa.amsl.com (Postfix) with ESMTP id 56A1511E80A2 for ; Mon, 22 Oct 2012 10:46:20 -0700 (PDT) Received: from SMTPEG2.etri.info (ssbmailx [127.0.0.1]) by mailx.etri.re.kr (8.13.8/8.13.8) with ESMTP id q9MHkHPm032465 for ; Tue, 23 Oct 2012 02:46:17 +0900 Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 23 Oct 2012 02:46:18 +0900 Received: from SMTP1.etri.info ([169.254.1.64]) by SMTP3.etri.info ([129.254.28.73]) with mapi id 14.01.0355.002; Tue, 23 Oct 2012 02:46:10 +0900 From: =?utf-8?B?7LWc7YOc7IOB?= To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-choi-cdni-req-routing-redir-loop-prevention-01.txt Thread-Index: AQHNsHwFiifcK+Pl6UWPHxle+DepjpfFmNUg Date: Mon, 22 Oct 2012 17:46:09 +0000 Message-ID: References: <20121022173816.10340.96890.idtracker@ietfa.amsl.com> In-Reply-To: <20121022173816.10340.96890.idtracker@ietfa.amsl.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.0.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-choi-cdni-req-routing-redir-loop-prevention-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 17:46:21 -0000 RGVhciBhbGwsDQoNCldlIGp1c3QgdXBsb2FkZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQt Y2hvaS1jZG5pLXJlcS1yb3V0aW5nLXJlZGlyLWxvb3AtcHJldmVudGlvbiAodmVyc2lvbiAwMSku IEFueSBjb21tZW50cyBvciBzdWdnZXN0aW9ucyBhcmUgYXBwcmVjaWF0ZWQuDQoNCkJlc3QgcmVn YXJkcywNClRhZXNhbmcNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSAN ClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgMjMsIDIwMTIgMjozOCBBTQ0KVG86IOy1nO2DnOyDgQ0K Q2M6IGRqLmtpbUBrdC5jb20NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtY2hvaS1jZG5pLXJlcS1yb3V0aW5nLXJlZGlyLWxvb3AtcHJldmVudGlvbi0wMS50eHQN Cg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jaG9pLWNkbmktcmVxLXJvdXRpbmct cmVkaXItbG9vcC1wcmV2ZW50aW9uLTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBFVFJJIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5h bWU6CSBkcmFmdC1jaG9pLWNkbmktcmVxLXJvdXRpbmctcmVkaXItbG9vcC1wcmV2ZW50aW9uDQpS ZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBDRE5pIFJlcXVlc3QgUm91dGluZyBSZWRpcmVjdGlvbiB3 aXRoIExvb3AgUHJldmVudGlvbg0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMjENCldHIElEOgkJ IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyMA0KVVJMOiAgICAgICAg ICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1jaG9pLWNkbmkt cmVxLXJvdXRpbmctcmVkaXItbG9vcC1wcmV2ZW50aW9uLTAxLnR4dA0KU3RhdHVzOiAgICAgICAg ICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWNob2ktY2RuaS1yZXEtcm91 dGluZy1yZWRpci1sb29wLXByZXZlbnRpb24NCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtY2hvaS1jZG5pLXJlcS1yb3V0aW5nLXJlZGlyLWxvb3AtcHJl dmVudGlvbi0wMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC1jaG9pLWNkbmktcmVxLXJvdXRpbmctcmVkaXItbG9vcC1wcmV2ZW50aW9uLTAx DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgcmVxdWVzdCByb3V0aW5n IHJlZGlyZWN0aW9uIHByb2NlZHVyZXMsIGxvb3ANCiAgIHByZXZlbnRpb24gbWVjaGFuaXNtcywg YW5kIG90aGVyIG9wZXJhdGlvbmFsIGNvbnNpZGVyYXRpb25zIHdoaWNoIGFyZQ0KICAgYXNzb2Np YXRlZCB3aXRoIHJlZGlyZWN0aW9uLg0KDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0K DQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From gilles.bertrand@orange.com Mon Oct 22 12:06:19 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 E50761F0425 for ; Mon, 22 Oct 2012 12:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 7E9Up-ivmBIX for ; Mon, 22 Oct 2012 12:06:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id DA2E921F8232 for ; Mon, 22 Oct 2012 12:06:18 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 514CE3B4104 for ; Mon, 22 Oct 2012 21:06:18 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 39F9B238056 for ; Mon, 22 Oct 2012 21:06:18 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Mon, 22 Oct 2012 21:06:17 +0200 From: To: "cdni@ietf.org" Thread-Topic: New version of the CDNI Logging draft posted Thread-Index: AQHNsIhQpQ5EQkTRwk2UvYifo9SmxQ== Date: Mon, 22 Oct 2012 19:06:17 +0000 Message-ID: <11995_1350932778_5085992A_11995_9963_1_2AC63C9F27AF8446B0C064C50FC0A89306DA472F@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> In-Reply-To: <20121022185902.22651.23401.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.10.22.180348 Subject: [CDNi] New version of the CDNI Logging draft posted 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, 22 Oct 2012 19:06:20 -0000 Folks, We have submitted a new version of the CDNI logging draft: URL: http://www.ietf.org/internet-drafts/draft-bertrand-cdni-lo= gging-02.txt=20 Status: http://datatracker.ietf.org/doc/draft-bertrand-cdni-loggin= g=20 Htmlized: http://tools.ietf.org/html/draft-bertrand-cdni-logging-02= =20 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-log= ging-02=20 Best regards, Gilles -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org Envoy=E9=A0: lundi 22 octobre 2012 20:59 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-bertrand-cdni-logging-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Roy Peterkofsky Francois Le Faucheur Pawel Grochocki Filename : draft-bertrand-cdni-logging-02.txt Pages : 43 Date : 2012-10-22 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-bertrand-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-bertrand-cdni-logging-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ie= tf.org/ietf/1shadow-sites.txt ___________________________________________________________________________= ______________________________________________ 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 Tue Oct 23 00:40:00 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 2581821F85EB for ; Tue, 23 Oct 2012 00:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.512 X-Spam-Level: X-Spam-Status: No, score=-103.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 p0BHAb3keZaw for ; Tue, 23 Oct 2012 00:39:59 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 207E921F8608 for ; Tue, 23 Oct 2012 00:39:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 34A47101B2D for ; Tue, 23 Oct 2012 09:39:58 +0200 (CEST) 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 V54tID6RdjCe for ; Tue, 23 Oct 2012 09:39:58 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 1C43B101B26 for ; Tue, 23 Oct 2012 09:39:53 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 09:39:53 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-seedorf-cdni-request-routing-alto-03.txt Thread-Index: Ac2w8YzcbrSl6AytQzeg+caBhz6GKg== Date: Tue, 23 Oct 2012 07:39:41 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5537F744@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 07:40:00 -0000 SGkgYWxsLA0KDQpJIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgZHJhZnQtc2VlZG9y Zi1jZG5pLXJlcXVlc3Qtcm91dGluZy1hbHRvLiBUaGlzIHZlcnNpb24gY29udGFpbnMganVzdCBt aW5vciBjaGFuZ2VzLCB0cnlpbmcgdG8gZXhwbGFpbiBob3cgY2FwYWJpbGl0aWVzIGNvdWxkIGJl IGNvbnZleWVkIHZpYSBBTFRPIGFjY29yZGluZyB0byB0aGUgbGF0ZXN0IGRpc2N1c3Npb25zIHdl IGhhZCBpbiB0aGUgZGVzaWduIHRlYW0gb24gZm9vdHByaW50L2NhcGFiaWxpdGllcy4NCg0KIC0g SmFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5 LCBPY3RvYmVyIDE5LCAyMDEyIDM6NDAgUE0NClRvOiBKYW4gU2VlZG9yZg0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1zZWVkb3JmLWNkbmktcmVxdWVzdC1yb3V0 aW5nLWFsdG8tMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNlZWRvcmYt Y2RuaS1yZXF1ZXN0LXJvdXRpbmctYWx0by0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgSmFuIFNlZWRvcmYgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9y eS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1zZWVkb3JmLWNkbmktcmVxdWVzdC1yb3V0aW5nLWFsdG8N ClJldmlzaW9uOgkgMDMNClRpdGxlOgkJIENETkkgUmVxdWVzdCBSb3V0aW5nIHdpdGggQUxUTw0K Q3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMTkNCldHIElEOgkJIEluZGl2aWR1YWwgU3VibWlzc2lv bg0KTnVtYmVyIG9mIHBhZ2VzOiAyMA0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYu b3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zZWVkb3JmLWNkbmktcmVxdWVzdC1yb3V0aW5nLWFs dG8tMDMudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtc2VlZG9yZi1jZG5pLXJlcXVlc3Qtcm91dGluZy1hbHRvDQpIdG1saXplZDogICAg ICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNlZWRvcmYtY2RuaS1yZXF1ZXN0 LXJvdXRpbmctYWx0by0wMw0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1zZWVkb3JmLWNkbmktcmVxdWVzdC1yb3V0aW5nLWFsdG8tMDMNCg0K QWJzdHJhY3Q6DQogICBOZXR3b3JrIFNlcnZpY2UgUHJvdmlkZXJzIChOU1BzKSBhcmUgY3VycmVu dGx5IGNvbnNpZGVyaW5nIHRvIGRlcGxveQ0KICAgQ29udGVudCBEZWxpdmVyeSBOZXR3b3JrcyAo Q0ROcykgd2l0aGluIHRoZWlyIG5ldHdvcmtzLiAgQXMgYQ0KICAgY29uc2VxdWVuY2Ugb2YgdGhp cyBkZXZlbG9wbWVudCwgdGhlcmUgaXMgYSBuZWVkIGZvciBpbnRlcmNvbm5lY3RpbmcNCiAgIHRo ZXNlIGxvY2FsIENETnMuICBUaGUgbmVjZXNzYXJ5IGludGVyZmFjZXMgZm9yIGludGVyLWNvbm5l Y3RpbmcgQ0ROcw0KICAgYXJlIGN1cnJlbnRseSBiZWluZyBkZWZpbmVkIGluIHRoZSBDb250ZW50 IERlbGl2ZXJ5IE5ldHdvcmtzDQogICBJbnRlcmNvbm5lY3Rpb24gKENETkkpIFdHLiAgVGhpcyBk b2N1bWVudCBmb2N1c3NlcyBvbiB0aGUgUmVxdWVzdA0KICAgUm91dGluZyBJbnRlcmZhY2Ugb2Yg Q0ROSSwgYW5kIG1vcmUgc3BlY2lmaWNhbGx5IG9uIGhvdyB0aGUgc29sdXRpb25zDQogICBjdXJy ZW50bHkgYmVpbmcgZGVmaW5lZCBpbiB0aGUgQXBwbGljYXRpb24gTGF5ZXIgVHJhZmZpYyBPcHRp bWl6YXRpb24NCiAgIChBTFRPKSBXRyBjYW4gaW1wcm92ZSBDRE5JIHJlcXVlc3Qgcm91dGluZy4g IFRoZSBvdmVyYWxsIGludGVudGlvbg0KICAgYmVoaW5kIHRoaXMgZG9jdW1lbnQgaXMgdG8gZm9z dGVyIGRpc2N1c3Npb25zIChpbiB0aGUgQ0ROSSBhcyB3ZWxsIGFzDQogICBpbiB0aGUgQUxUTyBX RykgcmVnYXJkaW5nIGlmLCBob3csIGFuZCB1bmRlciB3aGF0IGNvbmRpdGlvbnMgQUxUTyBjYW4N CiAgIGJlIHVzZWZ1bCB0byBvcHRpbWl6ZSBDRE5JIHJlcXVlc3Qgcm91dGluZy4gIEFzIGJhc2lz IGZvciB0aGlzDQogICBkaXNjdXNzaW9uLCB0aGlzIGRvY3VtZW50IHByb3ZpZGVzIGNvbmNyZXRl IGV4YW1wbGVzIG9mIGhvdyBBTFRPIGNhbg0KICAgYmUgaW50ZWdyYXRlZCB3aXRoaW4gQ0ROSSBy ZXF1ZXN0IHJvdXRpbmcgYW5kIGluIHBhcnRpY3VsYXIgaW4gdGhlDQogICBwcm9jZXNzIG9mIHNl bGVjdGluZyBhIGRvd25zdHJlYW0gQ0ROLiAgVGhlIGV4YW1wbGVzIGluIHRoaXMgZG9jdW1lbnQN CiAgIGFyZSBiYXNlZCBvbiB0aGUgdXNlIGNhc2VzIGFuZCBleGFtcGxlcyBjdXJyZW50bHkgYmVp bmcgZGlzY3Vzc2VkIGluDQogICB0aGUgQ0ROSSBXRy4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From Jan.Seedorf@neclab.eu Tue Oct 23 00:43: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 C127321F862E for ; Tue, 23 Oct 2012 00:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.517 X-Spam-Level: X-Spam-Status: No, score=-103.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 lSW3GyODOv1g for ; Tue, 23 Oct 2012 00:43:06 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id CF92D21F860C for ; Tue, 23 Oct 2012 00:43:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 420E1101B2D for ; Tue, 23 Oct 2012 09:43:05 +0200 (CEST) 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 CN-3kLX+qEeL for ; Tue, 23 Oct 2012 09:43:05 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 29CC7101B26 for ; Tue, 23 Oct 2012 09:43:00 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 09:42:39 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-spp-cdni-rr-foot-cap-semantics-02.txt Thread-Index: Ac2w8ZjpxZDXo4R4TbOGhnU4fschRQ== Date: Tue, 23 Oct 2012 07:42:28 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5537F757@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-spp-cdni-rr-foot-cap-semantics-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: Tue, 23 Oct 2012 07:43:06 -0000 SGkgYWxsLA0KDQpXZSBoYXZlIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LXNwcC1j ZG5pLXJyLWZvb3QtY2FwLXNlbWFudGljcy4gVGhpcyB2ZXJzaW9uIGhhcyBzb21lIGFkZGl0aW9u cyB0aGF0IHRyeSB0byBjYXB0dXJlIHRoZSBsYXRlc3QgcHJvZ3Jlc3MgKGJvdGggZHVyaW5nIHRo ZSBWYW5jb3V2ZXIgSUVURiBidXQgYWxzbyBkdXJpbmcgc29tZSByZWNlbnQgcGhvbmUgY2FsbHMg d2UgaGFkKSB3ZSBoYXZlIG1hZGUgaW4gdGhlIGZvb3RwcmludC9jYXBhYmlsaXRpZXMgZGVzaWdu IHRlYW0gb24gZGVmaW5pbmcgc2VtYW50aWNzIGZvciB0aGVzZSB0ZXJtcyBpbiB0aGUgQ0ROSSBj b250ZXh0Lg0KDQpDb21tZW50cyBhcmUgd2VsY29tZSwgSSBhbSBzdXJlIHdlIHdpbGwgYmUgZGlz Y3Vzc2luZyB0aGUgYWdyZWVtZW50IHdlIGhhdmUgZm91bmQgYW5kIHRoZSBpc3N1ZXMgc3RpbGwg b3BlbiBpbiBBdGxhbnRhLg0KDQogLSBKYW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZ10gDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMjIsIDIwMTIgNjo1OSBQTQ0KVG86IEph biBTZWVkb3JmDQpDYzogc3ByZXZpZGlAY2lzY28uY29tOyBqb24ucGV0ZXJzb25AbmV1c3Rhci5i aXoNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtc3BwLWNkbmkt cnItZm9vdC1jYXAtc2VtYW50aWNzLTAyLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1zcHAtY2RuaS1yci1mb290LWNhcC1zZW1hbnRpY3MtMDIudHh0DQpoYXMgYmVlbiBzdWNj ZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEphbiBTZWVkb3JmIGFuZCBwb3N0ZWQgdG8gdGhlDQpJRVRG IHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJhZnQtc3BwLWNkbmktcnItZm9vdC1jYXAtc2Vt YW50aWNzDQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBDRE5JIFJlcXVlc3QgUm91dGluZzogRm9v dHByaW50IGFuZCBDYXBhYmlsaXRpZXMgU2VtYW50aWNzDQpDcmVhdGlvbiBkYXRlOgkgMjAxMi0x MC0yMg0KV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDIx DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LXNwcC1jZG5pLXJyLWZvb3QtY2FwLXNlbWFudGljcy0wMi50eHQNClN0YXR1czogICAgICAg ICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1zcHAtY2RuaS1yci1mb290 LWNhcC1zZW1hbnRpY3MNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtc3BwLWNkbmktcnItZm9vdC1jYXAtc2VtYW50aWNzLTAyDQpEaWZmOiAgICAgICAg ICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXNwcC1jZG5pLXJyLWZv b3QtY2FwLXNlbWFudGljcy0wMg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgdHJpZXMg dG8gY2FwdHVyZSB0aGUgc2VtYW50aWNzIG9mIHRoZSAiRm9vdHByaW50IGFuZA0KICAgQ2FwYWJp bGl0aWVzIEFkdmVydGlzZW1lbnQiIHBhcnQgb2YgdGhlIENETkkgUmVxdWVzdCBSb3V0aW5nDQog ICBpbnRlcmZhY2UsIGkuZS4gdGhlIGRlc2lyZWQgbWVhbmluZyBhbmQgd2hhdCAiRm9vdHByaW50 IGFuZA0KICAgQ2FwYWJpbGl0aWVzIEFkdmVydGlzZW1lbnQiIGlzIGV4cGVjdGVkIHRvIG9mZmVy IHdpdGhpbiBDRE5JLiAgVGhlDQogICBkaXNjdXNzaW9uIGluIHRoaXMgZG9jdW1lbnQgaGFzIHRo ZSBnb2FsIHRvIGZhY2lsaXRhdGUgdGhlIGNob29zaW5nDQogICBvZiBvbmUgb3IgbW9yZSBzdWl0 YWJsZSBwcm90b2NvbHMgZm9yICJGb290cHJpbnQgYW5kIENhcGFiaWxpdGllcw0KICAgQWR2ZXJ0 aXNlbWVudCIgd2l0aGluIENETkkgUmVxdWVzdCBSb3V0aW5nLg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From Jan.Seedorf@neclab.eu Tue Oct 23 06:33:20 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 432E021F8708; Tue, 23 Oct 2012 06:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.526 X-Spam-Level: X-Spam-Status: No, score=-103.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 O9BbiyupI1LH; Tue, 23 Oct 2012 06:33:19 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0416921F8704; Tue, 23 Oct 2012 06:33:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 62DA11022AA; Tue, 23 Oct 2012 15:33:18 +0200 (CEST) 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 i1PkTQKudIpK; Tue, 23 Oct 2012 15:33:18 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 40C3D102277; Tue, 23 Oct 2012 15:33:03 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 23 Oct 2012 15:33:03 +0200 From: Jan Seedorf To: stefano previdi , "cdni-footprint@ietf.org" Thread-Topic: WEBEX Information for next CDNI Footprint/Capabilities Design Team Call Thread-Index: Ac2xIsuEFdB+wdXlQL6YGg3OVSTP6Q== Date: Tue, 23 Oct 2012 13:32:53 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5537FC36@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 Cc: "cdni@ietf.org" Subject: [CDNi] WEBEX Information for next CDNI 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: Tue, 23 Oct 2012 13:33:20 -0000 Stefano, Many thanks for setting up the WebEx once again! All, Please find below the WebEx info for the next call on Thursday this week. - Jan > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of stefano previdi > Sent: Monday, October 22, 2012 3:05 PM > To: cdni-footprint@ietf.org > Subject: [cdni-footprint] WEBEX Information Here >=20 >=20 >=20 > Topic: CDNI Footprint Design Team Interim Meeting > Date: Thursday, October 25, 2012 > Time: 4:00 pm, Europe Summer Time (Amsterdam, GMT+02:00) > Meeting Number: 200 625 864 > Meeting Password: cdni >=20 >=20 > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://cisco.webex.com/ciscosales/j.php?ED=3D207882597&UID=3D1897310317 > &PW=3DNM2QxOGQ4NTVi&RT=3DMiMyMg%3D%3D > 2. Enter your name and email address. > 3. Enter the meeting password: cdni > 4. Click "Join Now". > 5. Follow the instructions that appear on your screen. >=20 > To view in other time zones or languages, please click the link: > https://cisco.webex.com/ciscosales/j.php?ED=3D207882597&UID=3D1897310317 > &PW=3DNM2QxOGQ4NTVi&ORT=3DMiMyMg%3D%3D >=20 > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- >=20 > The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpi= tas > area and (866) 349-3520 for the RTP area. >=20 > 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 >=20 > ------------------------------------------------------- > 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 Acces= s > Code followed by the # sign. >=20 > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >=20 > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >=20 > India: +91.80.4350.1111 Germany: +49.619.6773.9002 >=20 > Japan: +81.3.5763.9394 China: +86.10.8515.5666 >=20 > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/mc > 2. On the left navigation bar, click "Support". >=20 > You can contact me at: > sprevidi@cisco.com > 39-0651644491 >=20 > To update this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://cisco.webex.com/ciscosales/j.php?ED=3D207882597&UID=3D1897310317 > &ICS=3DUMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DjZnJr0aeEyFuBdGk0n5hL8B7KM/- > 8hQspEMM8SAYsRI=3D&RT=3DMiMyMg%3D%3D >=20 >=20 > 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 > clicking this link: > https://cisco.webex.com/ciscosales/meetingcenter/mcsetup.php >=20 >=20 > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in th= e > meeting, please check whether you have the players installed on your > computer by going to > https://cisco.webex.com/ciscosales/systemdiagnosis.php. >=20 > http://www.webex.com >=20 > CCP:+14085256800x200625864# >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio > and any documents and other materials exchanged or viewed during the > session to be recorded. By joining this session, you automatically consen= t 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 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 From anne.marrec@orange.com Tue Oct 23 09:13:44 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 BE50B11E8170; Tue, 23 Oct 2012 09:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, 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 rzh1HD8OvfLx; Tue, 23 Oct 2012 09:13:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECFD11E8165; Tue, 23 Oct 2012 09:13:41 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 1CA882DC490; Tue, 23 Oct 2012 18:13:40 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id F1A7527C054; Tue, 23 Oct 2012 18:13:39 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 23 Oct 2012 18:13:39 +0200 From: To: "cdni-footprint@ietf.org" Thread-Topic: [cdni-footprint] - updated Anne use case Thread-Index: Ac2xOVwiielpUa5YQZ+M2iESl622Yw== Date: Tue, 23 Oct 2012 16:13:38 +0000 Message-ID: <13087_1351008820_5086C234_13087_4500_1_E5E1F88FBF39A84689D4A4791AE362B90203AF@PEXCVZYM12.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.4] Content-Type: multipart/mixed; boundary="_007_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.23.154235 Cc: "cdni@ietf.org" Subject: [CDNi] [cdni-footprint] - updated Anne use case 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, 23 Oct 2012 16:13:44 -0000 --_007_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_ Content-Type: multipart/related; boundary="_006_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_"; type="multipart/alternative" --_006_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_ Content-Type: multipart/alternative; boundary="_000_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_" --_000_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This document is an update of the use case "footprint& capabilities" presen= ted during the last footing design team meeting (october 15th). This update is proposed as a discussion and try to take into account commen= ts received on the mailing list : - a more flexible structure to describe content a uCDN delegates to a dCDN= is proposed for discussion - a more complex "request routing information modification" use case is ad= ded Anne [cid:image005.png@01CDB14A.1FA70C30] Anne MARREC FT/ OLNC/ OLN/ CNC/ IDA/ CDS t=E9l. +33 2 96 05 18 71 anne.marrec@orange.com [cid:image006.png@01CDB14A.1FA70C30] ___________________________________________________________________________= ______________________________________________ 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. --_000_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

This document is an update of t= he use case "footprint& capabilities" presented during the la= st footing design team meeting (october 15th).

This update is proposed as a di= scussion and try to take into account comments received on the mailing list= :

-  a more flexible structu= re to describe content a uCDN delegates to a dCDN is proposed for discussio= n

-  a more complex "re= quest routing information modification" use case is added

 

Anne

 

 

<= span style=3D"font-size:10.0pt;font-family:"Arial","sans-ser= if";color:black">

Anne MARREC
FT/ OLNC/ OLN/ CNC/ IDA/ CDS
t=E9l. +33 2 96 05 18 71

anne.marrec@orange.com

 

______________________________________________________________________=
___________________________________________________

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.
--_000_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_-- --_006_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=1137; creation-date="Tue, 23 Oct 2012 16:13:38 GMT"; modification-date="Tue, 23 Oct 2012 16:13:38 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACgAAAAoCAYAAACM/rhtAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAPxSURBVFjD 7ZVrbBRVGIZLNCHRYAgoCYQIkgiKf7imCAgxagJiVDQR2trbsrtDI0kTihSoBRYUuRRqKReh0AIC 4d4SLm2lgtCm3G9WBbq1FipgW8AARv338A5nVsZmEX72x/z4dnbOnHO+53u/98zEEIyhrUYoFIqJ 8QA9QA/QA/QAPUAP0AP0AD1AD9AD9AA9QA/QA3x0BBR+1/+2B9jOAPoUKQY2OqC7kuB/K/r3GnTm +B+SzN9qbiDKWCR8Dty0HvDFYMh6CbL7wuTnogDa5B8rkhSJignOpkmu8QnONRLJTvIUZ437WQQs 0bVnZF+/a1875gyErZOhZCZU5MKXw1sBpiomPQvLPoBNk2D+CFX3BKS1h3mxiuGQNwamPA+z+kFh KqxNghkvK6EUmN4L5g6CnLdgnV//Y406Nsznr8L6AOSOUuKh2qObKSwkxTZOhPyxkNlbe0m53Ddh 5YcwtbsL0IZLewbKF8Pt63DzV2j+RQvf18IXoLYS7jRDWNel78L3q6CmFBpOwU/fqi2CLF8CTbVw fq+udVB/XCDdBTEAGs/D5dOaf1J7N6iwFEGr4NojWl8BdUdhzxwV1N6ommrUN4CWbuIVee8ZuL0L BaVNfz4EF76DRaqoQZuHq/V/NKR3gYJEhU+gq+Gfu/C17qs3wa1GtWoYLB8Hf1yVEh+Zoq+cg4wX 4Rt15s7vsDMTKtcI9jfNiYcT2+HPFnVpJMSJxXKfYvtmvGJLhjZVgtmvwRDd75oF12qUXBs0nNFz +WOsxjP7KOkiKJNiVevg7g1YpVZXb5QiVVLgSUEOgRv1UCSlzhYbgFFamy0LNIWhdAH8WAYt6lRx Fhz4Cg7mS9VY49GogCvGq7om2KYFaYI4p1bVKWGufNco0JIsM29fDvx9Gxa8IV9ZqvyW1JQfj22R UlLaelrPRhgFV8fJ8Evh+iUlfx12h9QlKbhDCp7YrPGLgn5Fyqmg/Hd0BjoYzwZbA9qGTe8qFTYY j9iJbl4RQJoxru2fnZ8a+YsE1SyPVRXJh/uNLVYIpFL3YXnKekoJ1eYWzclT0mydzouyS1jF1h/T /GuwQQdj8dsq/Ad5dp+sdBAOrxRgR/M2iPolsR9M6QnbVd0RHYKCZBlVpv1EihSozXP7Oye9k06w /FfymfwjsDVq73T5K0eKLtdptNTijK7mhE/tZSyxR8oVyzIVy+AvKV4YMN1YIsgDskpxtqw14MFr 7aGfumTnwCQ44XMWJDgFWM5YfKvwud5pQefVEueM2a27dNh054KUrJFiM/oYryU46yNzH/tbHHjM z5P1iG+rDZre2XSjdL5exDqIWX0ftNH6/1z3Ae2fthz3AEjkYXGbuPXAAAAAAElFTkSuQmCC --_006_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=923; creation-date="Tue, 23 Oct 2012 16:13:38 GMT"; modification-date="Tue, 23 Oct 2012 16:13:38 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABIAAAAUCAYAAACAl21KAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAMbSURBVDjL lZRrSBRRFMfHHmYR5oMoelhBH6IoSEQiEsYiM3p8kCKkJwY96INpVL62NkqzoKcRFZUfCiqF3mWg lQjVlmhiStHD8jWb7e7M7I6zMzuzM/+Os1BtGW0Dh+FyD797zv/872UQwae9qIe4ewH43Hgo9ScG S5nK/Auiv2mBfLUMYulsePKGQ7q0DIbQ9X8gzfESUulBaC31UB3HIBRGQyhJgPbufuSgYC8HYeMm yJWV1tqQuuE9nARx33hoH2ojB0nlR+FOT0ewszMEdr+Ht3wKpIoUGGJnZKBgTy9cKSkQVq+C6feH tGq/A/FAApQ6O2AGIwMpN6rhjIuHkJMDM2AQ2Q+5aiMJnQGD/xz51HwFReCGDoO4ZTvMfgla6xX0 X8mC/uXF35QYHCRsyEEPw4Bfvw5a0zUoDYdI/OZfMswIQWs3oZdArow0qC+rYaqusH3Dx0H/WAdT dv8dZEifIWSvsCrqmzMLakPDn8NwtqL/cgYCry4OAjKC0DueQm06DW/+BnDRMXDGxkIqKyNnauFG ffsAQtEw+B/s+g1kaOTe65BvbkbwayO0Zw44x0+w2nNnZpDYLT/P8/ZQNSvB7xoC9fmpcJDWWgVf RTLUxlCppqKCX7rcas+ZmABfkY0AMk2wF/5bW+HZwcB3kozpav8J0jueQDqTBvHgOOjdjh8nq3cf wTl2sgX7NmsmpPMlkK9lgc9j6L6NoUMvhE9NupAGYV8ihL3RUB7tIcN1wNQVGKoMcfNaOJOi4FoS RQCKAgbioQRq6ciA18NBQmEUrNhDSSUxkC4uJhHzIT/Mo/JTSQvaK2Ks8GyjnNz50JsaSSwzHOQ7 mwrBNjpU8m4y4U6KXMbSYeAvUBXC/jh41oykVkmz2Di4Fy6CdLQcgcd10NvagE+fSKMuB/x38+lC ToJQTO9NMV0N2yh4SyfCd2oe/Le3IPD6KuRzFfCkL0HflGngRoSs8W1uMnx2O5SaGmtqrM41s1Jl Jsvb4ylGs3zZZGutNBxnIXHsQM5AKPdqWD57PctNn8Fy8WNZbup0VrLZWNTWxnwH0IGi/mC19kkA AAAASUVORK5CYII= --_006_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_-- --_007_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_ Content-Type: text/plain; name="Footprint and capabilities use case update _23102012.txt" Content-Description: Footprint and capabilities use case update _23102012.txt Content-Disposition: attachment; filename="Footprint and capabilities use case update _23102012.txt"; size=21628; creation-date="Tue, 23 Oct 2012 16:12:51 GMT"; modification-date="Tue, 23 Oct 2012 16:12:36 GMT" Content-Transfer-Encoding: base64 DQpVc2UgY2FzZSBmb3IgUmVxdWVzdCByb3V0aW5nIKsgZm9vdHByaW50ICYgY2FwYWJpbGl0aWVz ILsgLSBVcGRhdGVkIDIyIG9jdG9iZXIgMjAxMg0KQXV0aG9yIDogQW5uZSBNYXJyZWMNCg0KVGhp cyBkb2N1bWVudCBpcyBhbiB1cGRhdGUgb2YgdGhlIHVzZSBjYXNlICJmb290cHJpbnQmIGNhcGFi aWxpdGllcyIgcHJlc2VudGVkIGR1cmluZyB0aGUgbGFzdCBmb290aW5nIGRlc2lnbiB0ZWFtIG1l ZXRpbmcgKG9jdG9iZXIgMTV0aCkuIFRoaXMgdXBkYXRlIGlzIHByb3Bvc2VkIGFzIGEgZGlzY3Vz c2lvbiBhbmQgdHJ5IHRvIHRha2UgaW50byBhY2NvdW50IGNvbW1lbnRzIHJlY2VpdmVkIG9uIHRo ZSBtYWlsaW5nIGxpc3QgOg0KLSAgYSBtb3JlIGZsZXhpYmxlIHN0cnVjdHVyZSB0byBkZXNjcmli ZSBjb250ZW50IGEgdUNETiBkZWxlZ2F0ZXMgdG8gYSBkQ0ROIGlzIHByb3Bvc2VkIGZvciBkaXNj dXNzaW9uDQotICBhIG1vcmUgY29tcGxleCAicmVxdWVzdCByb3V0aW5nIGluZm9ybWF0aW9uIG1v ZGlmaWNhdGlvbiIgdXNlIGNhc2UgaXMgYWRkZWQNCg0KDQoNCiAgIEkgLSBDb250ZW50IGRlc2Ny aXB0aW9uIHN0cnVjdHVyZSANCiAgIA0KICAgVGhlIGNvbnRlbnQgZGVzY3JpcHRpb24gdXNlZCB0 byBkZXNjcmliZSB0aGUgdXNlIGNhc2UgaXMgYXMgdGhlIGZvbGxvd2luZyA6DQoNCgkJCSJTZXJ2 aWNlIEFncmVlbWVudCIgOg0KCQkJew0KCQkJCSJkZWxpdmVyeSBTZXJ2aWNlIjoNCgkJCQl7DQoJ CQkJCSJjbGFzcy1vZi1SZXF1ZXN0IjoNCgkJCQkJew0KCQkJCQkJIlVSSV9DbGFzcyIgOg0KCQkJ CQkJImZvb3RwcmludCIgOg0KCQkJCQl9DQoJCQkJCTxBTkQ+DQoJCQkJCSJjbGFzcy1vZi1SZXF1 ZXN0IjoNCgkJCQkJew0KCQkJCQkJIlVSSV9DbGFzcyIgOg0KCQkJCQkJImZvb3RwcmludCIgOg0K CQkJCQl9DQoJCQkJCTxBTkQ+DQoJCQkJCS4uLi4NCgkJCQkJImxvZyBwYXJhbWV0ZXJzIiA6DQoJ CQkJCXsNCgkJCQkJCSJsb2cgZm9ybWF0IiA6ICANCgkJCQkJCSJsb2cgcGFybTEiCToNCgkJCQkJ CSJsb2cgcGFyYW0yIiA6DQoJCQkJCQkuLi4uDQoJCQkJCX0NCgkJCQkJInF1YWxpdHkvY2FwYWJp bGl0eSByZXF1aXJlbWVudCBwYXJhbWV0ZXJzIiA6DQoJCQkJCXsNCgkJCQkJCSJyZXF1aXJlbWVu dDEiIDoNCgkJCQkJCSJyZXF1aXJlbWVudDIiIDoNCgkJCQkJCSJyZXF1aXJlbWVudDMiIDoNCgkJ CQkJCS4uLi4NCgkJCQkJfQ0KCQkJCX0NCgkJCQk8QU5EPg0KCQkJCSJkZWxpdmVyeSBTZXJ2aWNl IjoNCgkJCQl7DQoJCQkJCSJjbGFzcy1vZi1SZXF1ZXN0IjoNCgkJCQkJew0KCQkJCQkJIlVSSV9D bGFzcyIgOg0KCQkJCQkJImZvb3RwcmludCIgOg0KCQkJCQl9DQoJCQkJCTxBTkQ+DQoJCQkJCSJj bGFzcy1vZi1SZXF1ZXN0IjoNCgkJCQkJew0KCQkJCQkJIlVSSV9DbGFzcyIgOg0KCQkJCQkJImZv b3RwcmludCIgOg0KCQkJCQl9DQoJCQkJCTxBTkQ+DQoJCQkJCS4uLi4NCgkJCQkJImxvZyBwYXJh bWV0ZXJzIiA6DQoJCQkJCXsNCgkJCQkJCSJsb2cgZm9ybWF0IiA6ICANCgkJCQkJCSJsb2cgcGFy bTEiCToNCgkJCQkJCSJsb2cgcGFyYW0yIiA6DQoJCQkJCQkuLi4uDQoJCQkJCX0NCgkJCQkJInF1 YWxpdHkvY2FwYWJpbGl0eSByZXF1aXJlbWVudCBwYXJhbWV0ZXJzIiA6DQoJCQkJCXsNCgkJCQkJ CSJyZXF1aXJlbWVudDEiIDoNCgkJCQkJCSJyZXF1aXJlbWVudDIiIDoNCgkJCQkJCSJyZXF1aXJl bWVudDMiIDoNCgkJCQkJCS4uLi4NCgkJCQkJfQ0KCQkJCX0NCgkJCQk8QU5EPg0KCQkJCS4uLi4N CgkJCQkNCgkJCX0NCg0KCQ0KDQoNCg0KCQ0KCUlJKSBVc2UgY2FzZSBmb3IgUmVxdWVzdCByb3V0 aW5nIKsgZm9vdHByaW50ICYgY2FwYWJpbGl0aWVzILsgLSBVcGRhdGVkIDIyIG9jdG9iZXIgMjAx Mg0KDQpGaWd1cmUgMSBzaG93cyB0aGUgY29udGV4dCBvZiBDRE4gaW50ZXJjb25uZWN0aW9uIHVz ZWQgdG8gaWxsdXN0cmF0ZSB0aGUgdXNlIGNhc2Ugk2Zvb3RwcmludCAmIGNhcGFiaWxpdGllc5Qu IEFuIGV4YW1wbGUgb2YgdGhlIENETkkgaW50ZXJmYWNlIFJlcXVlc3QgUm91dGluZy9mb290cHJp bnQmY2FwYWJpbGl0aWVzIGV4Y2hhbmdlcyBiZXR3ZWVuIENETiBBIGFuZCBDRE4gQiB3aWxsIGJl IGRldGFpbGVkLg0KDQoJCQkJCQ0KDQoNCiAgICAgICAgLy0tLVwNCiAgICAgICAvICAgICBcDQog ICAgICB8ICBDUDEgIHwNCiAgICAgICBcICAgICAvDQogICAgICAgIFwtKy0vDQogICAgICAgICAg fA0KICAgICAgICAgIHwNCiAgICAgICstLS0rLS0rDQogICAgICB8ICAgICAgfA0KICAgICAgfCBD RE4gQXwNCiAgICAgIHwgICAgICB8DQogICAgICArLS0tKy0rKw0KICAgICAgICAgIHwgfA0KICAg ICAgICAgIHwgfA0KICAgICAgICAgIHwgKy0tLS0tLS0tLSsNCiAgICAgICAgICB8ICAgICAgICAg ICB8DQogICAgICArLS0tKy0tKyAgICAgKy0tfC0tLSsNCiAgICAgIHwgICAgICB8ICAgICB8ICAg ICAgfA0KICAgICAgfCBDRE4gQnwgICAgIHwgQ0ROIER8DQogICAgICB8ICAgICAgfCAgICAgfCAg ICAgIHwNCiAgICAgICstLS0rLS0rICAgICArLS0tLS0tKw0KICAgICAgICAgIHwNCiAgICAgICAg ICB8DQogICAgICAgICAgfA0KICAgICAgICAgIHwNCiAgICAgICstLS0rLS0rDQogICAgICB8ICAg ICAgfA0KICAgICAgfCBDRE4gQ3wNCiAgICAgIHwgICAgICB8DQogICAgICArLS0tLS0tKw0KCQlG aWd1cmUgMQ0KCQkNCg0KCUlJIDEpCVVzZSBjYXNlIGFzc3VtcHRpb25zOiANCgkNCgkJCWkpIENQ IGRlbWFuZCBleGFtcGxlOg0KDQqVCUEgZ2l2ZW4gQ1AxIHdpc2hlcyB0byBkZWxlZ2F0ZSB0aGUg ZGVsaXZlcnkgb2YgaXRzIGNvbnRlbnQgdG8gQ0ROQS4gTW9zdCBvZiBDUDEgY2xpZW50IGFyZSBm cm9tIJNGcmFuY2WUIGJ1dCB3YW50cyB0aGF0IGNsaWVudCBhbGwgb3ZlciB0aGUgd29ybGQgYmUg YWxzbyBkZWxpdmVyZWQgdGhyb3VnaCBhIENETi4gSXRzIGNvbnRlbnRzIGFyZSB0d28gdHlwZXMg OiANCm8JY29udGVudCBkZWxpdmVycyBpbiBIVFRQIA0KbwlhbmQgY29udGVudCBkZWxpdmVycyBp biBSVE1QDQpDUDEgZGVzY3JpYmVzIGl0cyBjb250ZW50IGFzIHBlciBkZWxpdmVyeSBzZXJ2aWNl IHdoaWNoIGNvbnRhaW5zIGEgbGlzdCBvZiBjbGFzcy1vZi1yZXF1ZXN0ICh1cmlfY2xhc3MgYW5k IGZvb3RwcmludCkgYW5kIHRoZSBsb2dnaW5nIGZvcm1hIGFuZCBxdWFsaXR5IGRlbGl2ZXJ5IHJl cXVpcmVtZW50cyBoZSB3aXNoZXMgZm9yIGVhY2ggZGVsaXZlcnkgc2VydmljZS4NCg0KRXhhbXBs ZSBvZiBDUDGScyCTc2VydmljZZQgZGVtYW5kIGZvciB0aGUgdXNlIGNhc2U6DQoNCgkJCQkiZGVs aXZlcnktU2VydmljZSI9ZGVsaXZlcnlfc2VydmljZV9zdGFuZGFyZCA6DQoJCQkJCXsNCgkJCQkJ CSJDbGFzcy1vZi1yZXF1ZXN0Ij1DUDFfdmlkZW9fc3RhbmRhcmQgOg0KCQkJCQkJew0KCQkJCQkJ CSJVUkktQ2xhc3MiIDogImh0dHA6Ly9jZG4uY3AxLmNvbS92aWRlby9zdGFuZGFyZC8qP3VybF9z aWduaW5nPSJiYiImKiIgDQoJCQkJCQkJImZvb3RwcmludCIgOiANCgkJCQkJCQl7CQ0KCQkJCQkJ CQkiem9uZSI6DQoJCQkJCQkJCXsNCgkJCQkJCQkJCSJmcm9tIiA6DQoJCQkJCQkJCQl7DQoJCQkJ CQkJCQkJImdlbyI6IHdvcmxkDQoJCQkJCQkJCQl9CQ0KCQkJCQkJCQl9DQoJCQkJCQkJfQ0KCQkJ CQkJfQkJCQkJCQkJCQ0KCQkJCQkJPEFORD4NCgkJCQkJCSJDbGFzcy1vZi1yZXF1ZXN0Ij1DUDFf bGl2ZV9zdGFuZGFyZCA6DQoJCQkJCQl7DQoJCQkJCQkJIlVSSS1DbGFzcyIgOiAicnRtcDovL2Nk bi5jcDEuY29tL2xpdmUvc3RhbmRhcmQvKj91cmxfc2lnbmluZz0iYmIiJioiIA0KCQkJCQkJCSJm b290cHJpbnQiIDogDQoJCQkJCQkJew0KCQkJCQkJCQkiem9uZSI6DQoJCQkJCQkJCXsNCgkJCQkJ CQkJCSJmcm9tIiA6DQoJCQkJCQkJCQl7DQoJCQkJCQkJCQkJImdlbyI6ICJ3b3JsZCINCgkJCQkJ CQkJCX0JDQoJCQkJCQkJCX0NCgkJCQkJCQl9DQoJCQkJCQl9CQkJCQkNCgkJCQkJCSJMb2cgcGFy YW1ldGVyIiA6DQoJCQkJCQl7DQoJCQkJCQkJImxvZyBmb3JtYXQiIDogImRyYWZ0bG9nZ2luZyIN CgkJCQkJCX0JDQoJCQkJCQkicXVhbGl0eS9jYXBhYmlsaXR5IHJlcXVpcmVtZW50IHBhcmFtZXRl cnMiOg0KCQkJCQkJCXsNCgkJCQkJCQkJIm1heERlbGl2ZXJ5U3RhcnRMYXRlbmN5IiA9IDUwMA0K CQkJCQkJCX0NCgkJCQkJCX0NCgkJCQkJCTxBTkQ+CQ0KCQkJCQkJImRlbGl2ZXJ5LVNlcnZpY2Ui PWRlbGl2ZXJ5X3NlcnZpY2VfcHJlbWl1bSA6DQoJCQkJCQl7DQoJCQkJCQkJIkNsYXNzLW9mLXJl cXVlc3QiPUNQMV92aWRlb19wcmVtaXVtIDoNCgkJCQkJCQl7DQoJCQkJCQkJCSJVUkktQ2xhc3Mi IDogImh0dHA6Ly9jZG4uY3AxLmNvbS92aWRlby9wcmVtaXVtLyo/dXJsX3NpZ25pbmc9ImJiIiYq IiANCgkJCQkJCQkJImZvb3RwcmludCIgOiANCgkJCQkJCQkJewkNCgkJCQkJCQkJCSJ6b25lIjoN CgkJCQkJCQkJCXsNCgkJCQkJCQkJCQkiZnJvbSIgOg0KCQkJCQkJCQkJCXsNCgkJCQkJCQkJCQkJ ImdlbyI6IHdvcmxkDQoJCQkJCQkJCQkJfQkNCgkJCQkJCQkJCX0NCgkJCQkJCQkJfQ0KCQkJCQkJ CX0JCQkJCQkJCQkNCgkJCQkJCQkJPEFORD4NCgkJCQkJCQkJIkNsYXNzLW9mLXJlcXVlc3QiPUNQ MV9saXZlX3ByZW1pdW0gOg0KCQkJCQkJCQl7DQoJCQkJCQkJCQkiVVJJLUNsYXNzIiA6ICJydG1w Oi8vY2RuLmNwMS5jb20vbGl2ZS9wcmVtaXVtLyo/dXJsX3NpZ25pbmc9ImJiIiYqIiANCgkJCQkJ CQkJCSJmb290cHJpbnQiIDogDQoJCQkJCQkJCQkJew0KCQkJCQkJCQkJCQkiem9uZSI6DQoJCQkJ CQkJCQkJCXsNCgkJCQkJCQkJCQkJCSJmcm9tIiA6DQoJCQkJCQkJCQkJCQkJew0KCQkJCQkJCQkJ CQkJCQkiZ2VvIjogIndvcmxkIg0KCQkJCQkJCQkJCQkJCX0JDQoJCQkJCQkJCQkJCX0NCgkJCQkJ CQkJCQl9DQoJCQkJCQkJCX0JCQkJCQ0KCQkJCQkJCSJMb2cgcGFyYW1ldGVyIiA6DQoJCQkJCQkJ CXsNCgkJCQkJCQkJCSJsb2cgZm9ybWF0IiA6ICJkcmFmdGxvZ2dpbmciDQoJCQkJCQkJCX0JDQoJ CQkJCQkJInF1YWxpdHkvY2FwYWJpbGl0eSByZXF1aXJlbWVudCBwYXJhbWV0ZXJzIjoNCgkJCQkJ CQkJew0KCQkJCQkJCQkJIm1heERlbGl2ZXJ5U3RhcnRMYXRlbmN5IiA9IDIwMA0KCQkJCQkJCQl9 DQoJCQkJCQkJfQ0KDQoJCTEtLS0tIENETiBBIG5vdGVzIHRoZSBDUDEgZGVtYW5kDQoJCQ0KCQkN Cg0KCQkJCWlpKUNETiBpbnRlcmNvbm5lY3Rpb24gbmVnb2NpYXRpb24gcGhhc2U6DQoJCQkJIA0K CQkJQ0ROIEEgY2FwYWJpbGl0aWVzIGFyZSBub3RlIGVub3VnaCBjb21wYXJlZCB0byBDUDEgZGVt YW5kIDoNCgkJCSBkZWxpdmVyeV9zZXJ2aWNlX3N0YW5kYXJkIGFuZCBkZWxpdmVyeV9zZXJ2aWNl X3ByZW1pdW0gYXJlIHN1cHBvcnRlZCBidXQgbGltaXRlZCB0byAiZm9vdHByaW50L2dlbz0iRnJh bmNlIg0KCQkJICJmb290cHJpbnQiIDogDQoJCQkJCQkJCQkJew0KCQkJCQkJCQkJCQkiem9uZSI6 DQoJCQkJCQkJCQkJCXsNCgkJCQkJCQkJCQkJCSJmcm9tIiA6DQoJCQkJCQkJCQkJCQkJew0KCQkJ CQkJCQkJCQkJCQkiZ2VvIjogIkZyYW5jZSINCgkJCQkJCQkJCQkJCQl9CQ0KCQkJCQkJCQkJCQl9 DQoJCQkJCQkJCQkJfQ0KCQkJDQoJCQlDRE4gQSBhbHJlYWR5IGhhcyBhIHNlcnZpY2UgYWdyZWVt ZW50IHdpdGggYSBnbG9iYWwgQ0ROIChDRE4gRCkgdG8gZGVsaXZlciBhbnkgY29udGVudCB0byCT d29ybGSUIHdpdGggdXJsX3NpZ25pbmc9lGJilCAok3NlcnZpY2VfQWdyZWVtZW50ZV9hZJQgY29t cGF0aWJsZSB3aXRoIENQMSBkZW1hbmQgKGRlbGl2ZXJ5X3NlcnZpY2Vfc3RhbmRhcmQgYW5kIGRl bGl2ZXJ5X3NlcnZpY2VfcHJlbWl1bSkgYnV0IHRoZSBwcmljZSBpcyB2ZXJ5IGhpZ2guIA0KICAg ICAgICAgICAgQmVzaWRlLCBDRE4gQSBvcGVyYXRvciBpcyBhbHNvIGF3YXJlIHRoYXQgYW5vdGhl ciBDRE4sIENETiBCLCBoYXMgdGhlIHBvc3NpYmlsaXR5IHRvIGRlbGl2ZXIgY29udGVudCB0byBm b290cHJpbnQgk0V1cm9wZZQgd2l0aCBhIGxvd2VyIHByaWNlIHRoYW4gQ0ROIEQuDQoNCgkJCQkN CgkJCQkyLS0tLS0gQ0ROIEEgY29udGFjdHMgQ0ROIEIgb3BlcmF0b3IgYW5kIGRlbWFuZHMgQ0RO IEIgY2FwYWJpbGl0aWVzIGNvbXBhcmVkIHRvIENQMSBkZW1hbmQgKGRlbGl2ZXJ5X3NlcnZpY2Vf c3RhbmRhcmQgYW5kIGRlbGl2ZXJ5X3NlcnZpY2VfcHJlbWl1bSkuIA0KCQkJCTMtLS0tLSBDRE4g QiBub3RlcyB0aGUgQ0ROIEEgZGVtYW5kIGFuZCB2ZXJpZnkgaWYgaXQgY2FuIG1hbmFnZSB0aGUg Q0ROQSBkZW1hbmQuDQoJDQoJCQkJCUNETiBCIG93bnMgY2FwYWJpbGl0aWVzIGFyZSBub3RlIGVu b3VnaCBjb21wYXJlZCB0byBDUDEgZGVtYW5kIDoNCgkJCQkJb25seSBDbGFzcy1vZi1yZXF1ZXN0 cyBDUDFfdmlkZW9fc3RhbmRhcmQgYW5kIENQMV92aWRlb19wcmVtaXVtIGFyZSBzdXBwb3J0ZWQg YW5kIGxpbWl0ZWQgdG8gImZvb3RwcmludC9nZW89IkV1cm9wZSIuDQoJCQkJCQkJQ0ROIEIgY2Fw YWJpbGl0aWVzIGFyZSB0aGUgZm9sbG93aW5nIGNvbXBhcmVkIHRvIENQMSBkZW1hbmQgOg0KCQkJ CQkNCgkJCSJkZWxpdmVyeS1TZXJ2aWNlIj1kZWxpdmVyeV9zZXJ2aWNlX3N0YW5kYXJkX0IgOg0K CQkJCXsNCgkJCQkJIkNsYXNzLW9mLXJlcXVlc3QiPUNQMV92aWRlb19zdGFuZGFyZF9CIDoNCgkJ CQkJew0KCQkJCQkJIlVSSS1DbGFzcyIgOiAiaHR0cDovL2Nkbi5jcDEuY29tL3ZpZGVvL3N0YW5k YXJkLyo/dXJsX3NpZ25pbmc9ImJiIiYqIiANCgkJCQkJCSJmb290cHJpbnQiIDogDQoJCQkJCQl7 CQ0KCQkJCQkJCSJ6b25lIjoNCgkJCQkJCQl7DQoJCQkJCQkJCSJmcm9tIiA6DQoJCQkJCQkJCXsN CgkJCQkJCQkJCSJnZW8iOiAiRXVyb3BlIg0KCQkJCQkJCQl9CQ0KCQkJCQkJCX0NCgkJCQkJCX0N CgkJCQkJfQkJCQkJCQkJCQ0KCQkJCQkiTG9nIHBhcmFtZXRlciIgOg0KCQkJCQl7DQoJCQkJCQki bG9nIGZvcm1hdCIgOiAiZHJhZnRsb2dnaW5nIg0KCQkJCQl9CQ0KCQkJCQkicXVhbGl0eS9jYXBh YmlsaXR5IHJlcXVpcmVtZW50IHBhcmFtZXRlcnMiOg0KCQkJCQkJew0KCQkJCQkJCSJtYXhEZWxp dmVyeVN0YXJ0TGF0ZW5jeSIgPSA1MDANCgkJCQkJCX0NCgkJCQkJfQ0KCQkJCQkNCgkJCSJkZWxp dmVyeS1TZXJ2aWNlIj1kZWxpdmVyeV9zZXJ2aWNlX3ByZW1pdW1fQiA6DQoJCQkJew0KCQkJCQki Q2xhc3Mtb2YtcmVxdWVzdCI9Q1AxX3ZpZGVvX3ByZW1pdW1fQiA6DQoJCQkJCXsNCgkJCQkJCSJV UkktQ2xhc3MiIDogImh0dHA6Ly9jZG4uY3AxLmNvbS92aWRlby9wcmVtaXVtLyo/dXJsX3NpZ25p bmc9ImJiIiYqIiANCgkJCQkJCSJmb290cHJpbnQiIDogDQoJCQkJCQl7CQ0KCQkJCQkJCSJ6b25l IjoNCgkJCQkJCQl7DQoJCQkJCQkJCSJmcm9tIiA6DQoJCQkJCQkJCXsNCgkJCQkJCQkJCSJnZW8i OiAiRXVyb3BlIg0KCQkJCQkJCQl9CQ0KCQkJCQkJCX0NCgkJCQkJCX0NCgkJCQkJfQkJCQkJCQkJ CQ0KCQkJCQkiTG9nIHBhcmFtZXRlciIgOg0KCQkJCQkJew0KCQkJCQkJCSJsb2cgZm9ybWF0IiA6 ICJkcmFmdGxvZ2dpbmciDQoJCQkJCQl9CQ0KCQkJCQkicXVhbGl0eS9jYXBhYmlsaXR5IHJlcXVp cmVtZW50IHBhcmFtZXRlcnMiOg0KCQkJCQkJew0KCQkJCQkJCSJtYXhEZWxpdmVyeVN0YXJ0TGF0 ZW5jeSIgPSAyMDANCgkJCQkJCX0NCgkJCQl9DQoNCgkJCQkJCQkJQnV0IENETiBCIG9wZXJhdG9y IGFscmVhZHkgaGFzIGFuIGFncmVlbWVudCB3aXRoIENETiBDIHRvIGRlbGl2ZXIgYW55IGNvbnRl bnQgaW4gUlRNUCB0byCTRXVyb3BllDoNCg0KCQkJIlNlcnZpY2UtQWdyZW1lbnQiPVNlcnZpY2Vf YWdyZWVtZW50X2JjIjoNCgkJCQl7DQoJCQkJCSJkZWxpdmVyeS1TZXJ2aWNlIj1kZWxpdmVyeV9z ZXJ2aWNlX3N0YW5kYXJkX0MgOg0KCQkJCQl7DQoJCQkJCQkiQ2xhc3Mtb2YtcmVxdWVzdCI9bGl2 ZV9zdGFuZGFyZCA6DQoJCQkJCQl7DQoJCQkJCQkJIlVSSS1DbGFzcyIgOiAicnRtcDovLyo/dXJs X3NpZ25pbmc9ImJiIiYqIiANCgkJCQkJCQkiZm9vdHByaW50IiA6IA0KCQkJCQkJCXsNCgkJCQkJ CQkJInpvbmUiOg0KCQkJCQkJCQl7DQoJCQkJCQkJCQkiZnJvbSIgOg0KCQkJCQkJCQkJew0KCQkJ CQkJCQkJCSJnZW8iOiAiRXVyb3BlIg0KCQkJCQkJCQkJfQkNCgkJCQkJCQkJfQ0KCQkJCQkJCX0N CgkJCQkJCX0JCQkJCQ0KCQkJCQkJIkxvZyBwYXJhbWV0ZXIiIDoNCgkJCQkJCXsNCgkJCQkJCQki bG9nIGZvcm1hdCIgOiAiZHJhZnRsb2dnaW5nIg0KCQkJCQkJfQkNCgkJCQkJCSJxdWFsaXR5L2Nh cGFiaWxpdHkgcmVxdWlyZW1lbnQgcGFyYW1ldGVycyI6DQoJCQkJCQkJew0KCQkJCQkJCQkibWF4 RGVsaXZlcnlTdGFydExhdGVuY3kiID0gNTAwDQoJCQkJCQkJfQ0KCQkJCQkJfQ0KCQkJCQkJPEFO RD4JDQoJCQkJCQkiZGVsaXZlcnktU2VydmljZSI9ZGVsaXZlcnlfc2VydmljZV9wcmVtaXVtX0Mg Og0KCQkJCQkJew0KCQkJCQkJCSJDbGFzcy1vZi1yZXF1ZXN0Ij1saXZlX3ByZW1pdW0gOg0KCQkJ CQkJCXsNCgkJCQkJCQkJIlVSSS1DbGFzcyIgOiAicnRtcDovLyo/dXJsX3NpZ25pbmc9ImJiIiYq IiANCgkJCQkJCQkJImZvb3RwcmludCIgOiANCgkJCQkJCQkJCXsNCgkJCQkJCQkJCQkiem9uZSI6 DQoJCQkJCQkJCQkJew0KCQkJCQkJCQkJCQkiZnJvbSIgOg0KCQkJCQkJCQkJCQkJew0KCQkJCQkJ CQkJCQkJCSJnZW8iOiAiRXVyb3BlIg0KCQkJCQkJCQkJCQkJfQkNCgkJCQkJCQkJCQl9DQoJCQkJ CQkJCQl9DQoJCQkJCQkJfQkJCQkJDQoJCQkJCQkJIkxvZyBwYXJhbWV0ZXIiIDoNCgkJCQkJCQkJ ew0KCQkJCQkJCQkJImxvZyBmb3JtYXQiIDogImRyYWZ0bG9nZ2luZyINCgkJCQkJCQkJfQkNCgkJ CQkJCQkicXVhbGl0eS9jYXBhYmlsaXR5IHJlcXVpcmVtZW50IHBhcmFtZXRlcnMiOg0KCQkJCQkJ CQl7DQoJCQkJCQkJCQkibWF4RGVsaXZlcnlTdGFydExhdGVuY3kiID0gMjAwDQoJCQkJCQkJCX0N CgkJCQkJCX0NCgkJCQl9DQoJCQkJCQ0KCQkJCTQtLS0tLS0gQ0ROIEIgYW5ub3VuY2VzIGl0cyBj YXBhYmlsaXRpZXMgdG8gQ0ROIEEgY29tcGFyZWQgdG8gQ0ROIEEgZGVtYW5kIDogZGVsaXZlcnlf c2VydmljZV9zdGFuZGFyZCBhbmQgZGVsaXZlcnlfc2VydmljZV9wcmVtaXVtIGFyZSBzdXBwb3J0 ZWQgYnV0IGxpbWl0ZWQgdG8gZm9vdHByaW50ICJFdXJvcGUiIChhZ2dyZWdhdGlvbiBvZiBDRE4g QyBhbmQgQ0ROIEIgY2FwYWJpbGl0aWVzKQ0KCQkJCQ0KCQkJCTUtLS0tLS0gQ0ROIEEgaXMgb2sg YW5kIHRoZSBmb2xsb3dpbmcgc2VydmljZSBhZ3JlZW1lbnQgaXMgY29uY2x1ZGVkIGJldHdlZW4g Q0ROQSBhbmQgQ0FOIEIgb3BlcmF0b3JzIDoNCgkJCQkNCgkJCQkiU2VydmljZS1BZ3JlbWVudCI9 U2VydmljZV9hZ3JlZW1lbnRfYWJfQ1AxIjoNCgkJCQl7DQoJCQkJCSJkZWxpdmVyeS1TZXJ2aWNl Ij1kZWxpdmVyeV9zZXJ2aWNlX3N0YW5kYXJkX0IgOg0KCQkJCQl7DQoJCQkJCQkiQ2xhc3Mtb2Yt cmVxdWVzdCI9Q1AxX3ZpZGVvX3N0YW5kYXJkX0IgOg0KCQkJCQkJew0KCQkJCQkJCSJVUkktQ2xh c3MiIDogImh0dHA6Ly9jZG4uY3AxLmNvbS92aWRlby9zdGFuZGFyZC8qP3VybF9zaWduaW5nPSJi YiImKiIgDQoJCQkJCQkJImZvb3RwcmludCIgOiANCgkJCQkJCQl7CQ0KCQkJCQkJCQkiem9uZSI6 DQoJCQkJCQkJCXsNCgkJCQkJCQkJCSJmcm9tIiA6DQoJCQkJCQkJCQl7DQoJCQkJCQkJCQkJImdl byI6ICJFdXJvcGUiDQoJCQkJCQkJCQl9CQ0KCQkJCQkJCQl9DQoJCQkJCQkJfQ0KCQkJCQkJfQkJ CQkJCQkJCQ0KCQkJCQkJPEFORD4NCgkJCQkJCSJDbGFzcy1vZi1yZXF1ZXN0Ij1DUDFfbGl2ZV9z dGFuZGFyZF9CIDoNCgkJCQkJCXsNCgkJCQkJCQkiVVJJLUNsYXNzIiA6ICJydG1wOi8vY2RuLmNw MS5jb20vbGl2ZS9zdGFuZGFyZC8qP3VybF9zaWduaW5nPSJiYiImKiIgDQoJCQkJCQkJImZvb3Rw cmludCIgOiANCgkJCQkJCQl7DQoJCQkJCQkJCSJ6b25lIjoNCgkJCQkJCQkJew0KCQkJCQkJCQkJ ImZyb20iIDoNCgkJCQkJCQkJCXsNCgkJCQkJCQkJCQkiZ2VvIjogIkV1cm9wZSINCgkJCQkJCQkJ CX0JDQoJCQkJCQkJCX0NCgkJCQkJCQl9DQoJCQkJCQl9CQkJCQkNCgkJCQkJCSJMb2cgcGFyYW1l dGVyIiA6DQoJCQkJCQl7DQoJCQkJCQkJImxvZyBmb3JtYXQiIDogImRyYWZ0bG9nZ2luZyINCgkJ CQkJCX0JDQoJCQkJCQkicXVhbGl0eS9jYXBhYmlsaXR5IHJlcXVpcmVtZW50IHBhcmFtZXRlcnMi Og0KCQkJCQkJCXsNCgkJCQkJCQkJIm1heERlbGl2ZXJ5U3RhcnRMYXRlbmN5IiA9IDUwMA0KCQkJ CQkJCX0NCgkJCQkJCX0NCgkJCQkJCTxBTkQ+CQ0KCQkJCQkJImRlbGl2ZXJ5LVNlcnZpY2UiPWRl bGl2ZXJ5X3NlcnZpY2VfcHJlbWl1bV9CIDoNCgkJCQkJCXsNCgkJCQkJCQkiQ2xhc3Mtb2YtcmVx dWVzdCI9Q1AxX3ZpZGVvX3ByZW1pdW1fQiA6DQoJCQkJCQkJew0KCQkJCQkJCQkiVVJJLUNsYXNz IiA6ICJodHRwOi8vY2RuLmNwMS5jb20vdmlkZW8vcHJlbWl1bS8qP3VybF9zaWduaW5nPSJiYiIm KiIgDQoJCQkJCQkJCSJmb290cHJpbnQiIDogDQoJCQkJCQkJCXsJDQoJCQkJCQkJCQkiem9uZSI6 DQoJCQkJCQkJCQl7DQoJCQkJCQkJCQkJImZyb20iIDoNCgkJCQkJCQkJCQl7DQoJCQkJCQkJCQkJ CSJnZW8iOiAiRXVyb3BlIg0KCQkJCQkJCQkJCX0JDQoJCQkJCQkJCQl9DQoJCQkJCQkJCX0NCgkJ CQkJCQl9CQkJCQkJCQkJDQoJCQkJCQkJCTxBTkQ+DQoJCQkJCQkJCSJDbGFzcy1vZi1yZXF1ZXN0 Ij1DUDFfbGl2ZV9wcmVtaXVtX0IgOg0KCQkJCQkJCQl7DQoJCQkJCQkJCQkiVVJJLUNsYXNzIiA6 ICJydG1wOi8vY2RuLmNwMS5jb20vbGl2ZS9wcmVtaXVtLyo/dXJsX3NpZ25pbmc9ImJiIiYqIiAN CgkJCQkJCQkJCSJmb290cHJpbnQiIDogDQoJCQkJCQkJCQkJew0KCQkJCQkJCQkJCQkiem9uZSI6 DQoJCQkJCQkJCQkJCXsNCgkJCQkJCQkJCQkJCSJmcm9tIiA6DQoJCQkJCQkJCQkJCQkJew0KCQkJ CQkJCQkJCQkJCQkiZ2VvIjogIkV1cm9wZSINCgkJCQkJCQkJCQkJCQl9CQ0KCQkJCQkJCQkJCQl9 DQoJCQkJCQkJCQkJfQ0KCQkJCQkJCQl9CQkJCQkNCgkJCQkJCQkiTG9nIHBhcmFtZXRlciIgOg0K CQkJCQkJCQl7DQoJCQkJCQkJCQkibG9nIGZvcm1hdCIgOiAiZHJhZnRsb2dnaW5nIg0KCQkJCQkJ CQl9CQ0KCQkJCQkJCSJxdWFsaXR5L2NhcGFiaWxpdHkgcmVxdWlyZW1lbnQgcGFyYW1ldGVycyI6 DQoJCQkJCQkJCXsNCgkJCQkJCQkJCSJtYXhEZWxpdmVyeVN0YXJ0TGF0ZW5jeSIgPSAyMDANCgkJ CQkJCQkJfQ0KCQkJCQkJCX0NCgkJCQl9DQoJCQkJDQoJCQkJNi0tLS0tLSBBIHNlcnZpY2UgYWdy ZWVtZW50IGlzIGNvbmNsdWRlZCBiZXR3ZWVuIENETkEgYW5kIENQMSBhY2NvcmRpbmx5IHRvIHRo ZSB0d28gZGVsaXZlcnkgc2VydmljZXMgQ1AxIGRlbWFuZCAoZGVsaXZlcnlfc2VydmljZV9zdGFu ZGFyZCBhbmQgZGVsaXZlcnlfc2VydmljZV9wcmVtaXVtKQ0KCQkJCQ0KCQkJCUlJIC0gMikJVXNl IGNhc2U6IA0KDQoJCQkJCWkpIENETiBBLSBDRE4gQiBJbnRlcmNvbm5lY3Rpb24gaW5pdGlhbGl6 YXRpb24gcGhhc2UNCg0KCQkJCQkJYSkgQ0ROIEEgLSBDRE4gQiBpbnRlcmNvbm5lY3Rpb24gaW5p dGlhbGl6YXRpb24NCg0KCQkJCQkJUGFyYW1ldGVycyBuZWVkZWQgdG8gaW5pdGlhbGl6ZSBDRE5J IGludGVyZmFjZXMgYmV0d2VlbiBDRE4gQSBhbmQgQ0ROIEIgKHJlcXVlc3QgUm91dGluZywgbWV0 YWRhdGEgYW5kIGxvZ2dpbmcpIA0KCQkJCQkJZm9yIHRoZSBhZ3JlZWQgk3NlcnZpY2UgYWdyZWVt ZW50X2FiX0NQMZQgYXJlIGV4Y2hhbmdlZCB2aWEgdGhlIGNvbnRyb2wgaW50ZXJmYWNlLg0KCQkJ CQkJVGhlc2UgcGFyYW1ldGVycyB3aWxsIGJlIHVzZWQgdG8gY29uZmlndXJlIENETiBBIGFuZCBD RE4gQi4NCgkJCQkJCQ0KCQkJCQkJRXhlbXBsZSBvZiBjb250cm9sIHBhcmFtZXRlcnMgbmVlZGVk IHRvIGNvbmZpZ3VyZSB0aGUgInNlcnZpY2UgYWdyZWVtZW50X2FiX0NQMSINCg0KCQkiU2Vydmlj ZS1BZ3JlbWVudCI9U2VydmljZV9hZ3JlZW1lbnRfYWJfQ1AxIjoNCgkJew0KCQkJImRlbGl2ZXJ5 LVNlcnZpY2UiPWRlbGl2ZXJ5X3NlcnZpY2Vfc3RhbmRhcmRfQiA6DQoJCQl7DQoJCQkJIkNsYXNz LW9mLXJlcXVlc3QiPUNQMV92aWRlb19zdGFuZGFyZF9CIDoNCgkJCQl7DQoJCQkJCSJVUkktQ2xh c3MiIDogImh0dHA6Ly9jZG4uY3AxLmNvbS92aWRlby9zdGFuZGFyZC8qP3VybF9zaWduaW5nPSJi YiImKiIgDQoJCQkJCSJmb290cHJpbnQiIDogDQoJCQkJCXsJDQoJCQkJCQkiem9uZSI6DQoJCQkJ CQl7DQoJCQkJCQkJImZyb20iIDoNCgkJCQkJCQl7DQoJCQkJCQkJCSJnZW8iOiAiRXVyb3BlIg0K CQkJCQkJCX0JDQoJCQkJCQl9DQoJCQkJCX0NCgkJCQl9CQkJCQkJCQkJDQoJCQkJPEFORD4NCgkJ CQkiQ2xhc3Mtb2YtcmVxdWVzdCI9Q1AxX2xpdmVfc3RhbmRhcmRfQiA6DQoJCQkJew0KCQkJCQki VVJJLUNsYXNzIiA6ICJydG1wOi8vY2RuLmNwMS5jb20vbGl2ZS9zdGFuZGFyZC8qP3VybF9zaWdu aW5nPSJiYiImKiIgDQoJCQkJCSJmb290cHJpbnQiIDogDQoJCQkJCXsNCgkJCQkJCSJ6b25lIjoN CgkJCQkJCXsNCgkJCQkJCQkiZnJvbSIgOg0KCQkJCQkJCXsNCgkJCQkJCQkJImdlbyI6ICJFdXJv cGUiDQoJCQkJCQkJfQkNCgkJCQkJCX0NCgkJCQkJfQ0KCQkJCX0JCQkJCQ0KCQkJCSJMb2cgcGFy YW1ldGVyIiA6DQoJCQkJew0KCQkJCQkibG9nIGZvcm1hdCIgOiAiZHJhZnRsb2dnaW5nIg0KCQkJ CX0JDQoJCQkJInF1YWxpdHkvY2FwYWJpbGl0eSByZXF1aXJlbWVudCBwYXJhbWV0ZXJzIjoNCgkJ CQkJew0KCQkJCQkJIm1heERlbGl2ZXJ5U3RhcnRMYXRlbmN5IiA9IDUwMA0KCQkJCQl9DQoJCQkJ fQ0KCQkJCTxBTkQ+CQ0KCQkJCSJkZWxpdmVyeS1TZXJ2aWNlIj1kZWxpdmVyeV9zZXJ2aWNlX3By ZW1pdW1fQiA6DQoJCQkJew0KCQkJCQkiQ2xhc3Mtb2YtcmVxdWVzdCI9Q1AxX3ZpZGVvX3ByZW1p dW1fQiA6DQoJCQkJCXsNCgkJCQkJCSJVUkktQ2xhc3MiIDogImh0dHA6Ly9jZG4uY3AxLmNvbS92 aWRlby9wcmVtaXVtLyo/dXJsX3NpZ25pbmc9ImJiIiYqIiANCgkJCQkJCSJmb290cHJpbnQiIDog DQoJCQkJCQl7CQ0KCQkJCQkJCSJ6b25lIjoNCgkJCQkJCQl7DQoJCQkJCQkJCSJmcm9tIiA6DQoJ CQkJCQkJCXsNCgkJCQkJCQkJCSJnZW8iOiAiRXVyb3BlIg0KCQkJCQkJCQl9CQ0KCQkJCQkJCX0N CgkJCQkJCX0NCgkJCQkJfQkJCQkJCQkJCQ0KCQkJCQkJPEFORD4NCgkJCQkJCSJDbGFzcy1vZi1y ZXF1ZXN0Ij1DUDFfbGl2ZV9wcmVtaXVtX0IgOg0KCQkJCQkJew0KCQkJCQkJCSJVUkktQ2xhc3Mi IDogInJ0bXA6Ly9jZG4uY3AxLmNvbS9saXZlL3ByZW1pdW0vKj91cmxfc2lnbmluZz0iYmIiJioi IA0KCQkJCQkJCSJmb290cHJpbnQiIDogDQoJCQkJCQkJCXsNCgkJCQkJCQkJCSJ6b25lIjoNCgkJ CQkJCQkJCXsNCgkJCQkJCQkJCQkiZnJvbSIgOg0KCQkJCQkJCQkJCQl7DQoJCQkJCQkJCQkJCQki Z2VvIjogIkV1cm9wZSINCgkJCQkJCQkJCQkJfQkNCgkJCQkJCQkJCX0NCgkJCQkJCQkJfQ0KCQkJ CQkJfQkJCQkJDQoJCQkJCSJMb2cgcGFyYW1ldGVyIiA6DQoJCQkJCQl7DQoJCQkJCQkJImxvZyBm b3JtYXQiIDogImRyYWZ0bG9nZ2luZyINCgkJCQkJCX0JDQoJCQkJCSJxdWFsaXR5L2NhcGFiaWxp dHkgcmVxdWlyZW1lbnQgcGFyYW1ldGVycyI6DQoJCQkJCQl7DQoJCQkJCQkJIm1heERlbGl2ZXJ5 U3RhcnRMYXRlbmN5IiA9IDIwMA0KCQkJCQkJfQ0KCQkJCX0NCgkJCSJyZWRpcmVjdGlvbiBwYXJh bWV0ZXJzIg0KCQkJew0KCQkJCSJwYXJhbTEiIDoNCgkJCQkicGFyYW0yIiA6DQoJCQkJLi4uDQoJ CQl9CQ0KCQkJIkNETkkgaW50ZXJmYWNlIGNvbm5lY3Rpdml0eSBhbmQgc2VjdXJpdHkgcGFyYW1l dGVycyAiIDoNCgkJCXsNCgkJCQkicGFyYW0xIiA6DQoJCQkJInBhcmFtMiIgOg0KCQkJCS4uLg0K CQkJfQkJCQ0KCQl9DQoJDQoNCgkJCQkJCWIpQ0ROIEEgLSBDRE4gQiBSZXF1ZXN0IFJvdXRpbmcv Zm9vdHByaW50JmNhcGFiaWxpdGllcyBOb3RpZmljYXRpb24gDQoNCgkJCQkJCU9uY2UgQ0ROIEEg YW5kIENETiBCIGFyZSBjb25maWd1cmVkIGFuZCBvcGVyYXRpb25hbCwgQ0ROIEIgKGRDRE4pIGFk dmVydGl6ZXMgQ0ROIEEgKHVDRE4pIHdpdGggcmVxdWVzdCByb3V0aW5nIGluZm9ybWF0aW9uIHZp YSB0aGUgUmVxdWVzdCBSb3V0aW5nL2Zvb3RwcmludCBhbmQgY2FwYWJpbGl0aWVzIGludGVyZmFj ZS4NCgkJCQkJCUNETiBBIChkQ0ROKSBzZW5kcyBhIFJlcXVlc3QgUm91dGluZyBpbmZvcm1hdGlv biBub3RpZmljYXRpb24gdG8gQ0ROIEIgKHVDRE4pLiBUaGlzIG5vdGlmaWNhdGlvbiBpbmNsdWRl cyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6DQoJCQkJCQkJCQkJCQkNCgkJCVNlcnZpY2UgOg0K CQkJCSAgeyAgDQoJCQkJCSAgU2VydmljZV9BZ3JlZWVtZW50X2lkID0gc2VydmljZV9BZ3JlZWVt ZW50X2FiX0NQMQ0KCQkJCQkgIFN0YXR1cyA9IG9wZXJhdGlvbmFsDQoJCQkJIH0NCg0KCQkJCQkJ QWZ0ZXIgQ0ROIEEgaGFzIHJlY2VpdmVkIHRoaXMgUmVxdWVzdCByb3V0aW5nIGluZm9ybWF0aW9u IG5vdGlmaWNhdGlvbiwgYW4gZXhhbXBsZSBvZiBpdHMgZENETiBzZWxlY3Rpb24gYWxnb3JpdGht IGNvdWxkIGJlIGFzIGZvbGxvd2luZyAoYXMgYW4gZXhhbXBsZSBhbmQgZm9yIGluZm9ybWF0aW9u IG9ubHkpICAgICAgIAkNCg0KCQkJCQkJSWYgdGhlIEVuZC11c2VyIHJlcXVlc3Qgb2YgY29udGVu dCBtYXRjaGVzIHRoZSBjbGFzcy1vZi1yZXF1ZXN0L1VSSV9jbGFzcyCTaHR0cC8vY2RuLmNwMS5j b20vdmlkZW8vKj8gdXJsX3NpZ25pbmc9lGJilCYqlCBvciCTcnRtcC8vY2RuLmNwMS5jb20vdmlk ZW8vKj8gdXJsX3NpZ25pbmc9lGJilCYqlA0KCQkJCQkJQW5kIA0KCQkJCQkJSWYgIHRoZSBJUCBz b3VyY2UgYWRkcmVzcyBiZWxvbmdzIHRvIHRoZSBmb290cHJpbnQvZ2VvPZRGcmFuY2WUDQoJCQkJ CQkJICB0aGVuLCB0aGUgZGVsaXZlcnkgb2YgdGhlIHJlcXVlc3RlZCBjb250ZW50IGlzIGRvbmUg YnkgdGhlIENETiBBIGl0c2VsZg0KCQkJCQkJCQllbHNlIA0KCQkJCQkJCQlpZiB0aGUgSVAgc291 cmNlIGFkZHJlc3MgYmVsb25ncyB0byB0aGUgZm9vdHByaW50L2dlbz2URXVyb3BllCANCgkJCQkJ CQkJdGhlbiwgdGhlIGRlbGl2ZXJ5IG9mIHRoZSByZXF1ZXN0ZWQgY29udGVudCBpcyBkZWxlZ2F0 ZWQgdG8gQ0ROIEIgKHdoaWNoIHdpbGwgZGVsZWdhdGUgaXQgdG8gQ0ROIEMgdGhlIEVuZC11c2Vy IHJlcXVlc3Qgb2YgY29udGVudCBtYXRjaGVzIHRoZSBjbGFzcy1vZi1yZXF1ZXN0L1VSSV9jbGFz cyCTcnRtcC8vY2RuLmNwMS5jb20vdmlkZW8vKj8gdXJsX3NpZ25pbmc9lGJilCYqlCkNCgkJCQkJ CQkJZWxzZSANCgkJCQkJCQkJCWlmIHRoZSBJUCBzb3VyY2UgYWRkcmVzcyBiZWxvbmdzIHRvIHRo ZSBmb290cHJpbnQvZ2VvPZRXb3JsZJQgDQoJCQkJCQkJCQl0aGVuLCB0aGUgZGVsaXZlcnkgb2Yg dGhlIHJlcXVlc3RlZCBjb250ZW50IGlzIGRlbGVnYXRlZCB0byBDRE4gRA0KCQkJCQkJCQkJDQoJ CQkJCQkNCgkJCQkJCQkJDQoJCQkJCQkJCQ0KDQoJCQkJCQlpaSkgUmVxdWVzdCByb3V0aW5nIGlu Zm9ybWF0aW9uIG1vZGlmaWNhdGlvbg0KCQkJCQkJDQoJCQkJCQkgICAgU3ViLXVzZSBjYXNlIDEg Og0KCQkJCQkJCQlBIHByb2JsZW0gb2NjdXJzIG9uIENETiBDIHNvIHRoYXQgaXQgaXMgbm90IGFi bGUgdG8gZGVsaXZlciBhbnltb3JlIGNvbnRlbnQgdXNpbmcgUlRNUC4NCgkJCQkJCQkJQ0ROIEEg bXVzdCBub3cgc2VsZWN0cyBDRE4gRCBmb3IgdGhlIGRlbGl2ZXJ5IG9mIENQMZJzIGNvbnRlbnQg aW4gUlRNUCBmb3IgY2xpZW50IG90aGVyIHRoYW4gaW4gRnJhbmNlLg0KDQoJCQkJCQkJCQlSZXF1 ZXN0IFJvdXRpbmcvZm9vdHByaW50JmNhcGFiaWxpdGllcyBOb3RpZmljYXRpb25zIDogDQoNCgkJ CQkJCQkJCTEpIENETiBDIC0gQ0ROIEIgUmVxdWVzdCBSb3V0aW5nL2Zvb3RwcmludCZjYXBhYmls aXRpZXMgTm90aWZpY2F0aW9uIA0KDQoJCQkJCQkJCQlDRE4gQyB3aWxsIHRoZW4gc2VuZCBhIHJl cXVlc3Qgcm91dGluZyBpbmZvcm1hdGlvbiBub3RpZmljYXRpb24gdG8gQ0ROIEINCgkJCQkJCQkJ CVRoaXMgbm90aWZpY2F0aW9uIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVyczoNCgkJ CQkJCQlTZXJ2aWNlIDoNCgkJCQkJCQkJICB7ICANCgkJCQkJCQkJCSAgU2VydmljZV9BZ3JlZW1l bnRfaWQgPSBzZXJ2aWNlLUFncmVlZW1lbnRfYmMNCgkJCQkJCQkJCSAgU3RhdHVzID0gbm90X29w ZXJhdGlvbmFsDQoJCQkJCQkJCSAgfQ0KDQoJCQkJCQkJCQkyKSBDRE4gQSAtIENETiBCIFJlcXVl c3QgUm91dGluZy9mb290cHJpbnQmY2FwYWJpbGl0aWVzIE5vdGlmaWNhdGlvbiANCg0KCQkJCQkJ CQkJQ0ROIEIgd2lsbCB0aGVuIHNlbmQgYSByZXF1ZXN0IHJvdXRpbmcgaW5mb3JtYXRpb24gbm90 aWZpY2F0aW9uIHRvIENETiBBDQoJCQkJCQkJCQlUaGlzIG5vdGlmaWNhdGlvbiBpbmNsdWRlcyB0 aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6DQoJCQlTZXJ2aWNlIDoNCgkJCQkgIHsgIA0KCQkJCQkg IFNlcnZpY2VfQWdyZWVtZW50X2lkID0gc2VydmljZV9BZ3JlZWVtZW50X2FiX0NQMQ0KCQkJCQkg IFN0YXR1cyA9IG1vZGlmaWVkDQoJCQkJCQl7CQ0KCQkJCQkJICAibW9kaWZpZWQgZGVsaXZlcnkg c2VydmljZSIgOiAiZGVsaXZlcnlfc2VydmljZV9zdGFuZGFyZF9CIiANCgkJCQkJCQl7DQoJCQkJ CQkJCSJNb2RpZmllZCBDbGFzcy1vZi1yZXF1ZXN0IiA6ICJDUDFfbGl2ZV9zdGFuZGFyZF9CIg0K CQkJCQkJCQlTdGF0dXMgPSBub3Rfb3BlcmF0aW9uYWwNCgkJCQkJCQl9DQoJCQkJCQkJPEFORD4N CgkJCQkJCQkibW9kaWZpZWQgZGVsaXZlcnkgc2VydmljZSIgOiAiZGVsaXZlcnlfc2VydmljZV9w cmVtaXVtX0IiIA0KCQkJCQkJCXsNCgkJCQkJCQkJIk1vZGlmaWVkIENsYXNzLW9mLXJlcXVlc3Qi IDogIkNQMV9saXZlX3ByZW1pdW1fQiINCgkJCQkJCQkJIFN0YXR1cyA9IG5vdF9vcGVyYXRpb25h bA0KCQkJCQkJCX0NCgkJCQkJCX0NCgkJCQkJfQkNCgkJCQkJCQkJCQkJCQkNCgkJCQkJCQkJCQkJ CQkNCgkJCQkJCQkJCQkJDQoJCQkJCQkJCQlBZnRlciBDRE4gQSBoYXMgcmVjZWl2ZWQgdGhpcyBS ZXF1ZXN0IHJvdXRpbmcgaW5mb3JtYXRpb24gbm90aWZpY2F0aW9uLCBhbiBleGFtcGxlIG9mIGl0 cyBtb2RpZmllZCBkQ0ROIHNlbGVjdGlvbiBhbGdvcml0aG0gaXMgcHJlc2VudGVkIChhcyBhbiBl eGFtcGxlIGFuZCBmb3IgaW5mb3JtYXRpb24gb25seSkgICAgICAgCQ0KDQoJCQkJCQkJCQlJZiB0 aGUgRW5kLXVzZXIgcmVxdWVzdCBvZiBjb250ZW50IG1hdGNoZXMgdGhlIGNsYXNzLW9mLXJlcXVl c3QvVVJJX2NsYXNzIJNodHRwLy9jZG4uY3AxLmNvbS92aWRlby8qPyB1cmxfc2lnbmluZz2UYmKU JiqUIG9yIJNydG1wLy9jZG4uY3AxLmNvbS92aWRlby8qPyB1cmxfc2lnbmluZz2UYmKUJiqUDQoJ CQkJCQkJCQlBbmQgDQoJCQkJCQkJCQlJZiAgdGhlIElQIHNvdXJjZSBhZGRyZXNzIGJlbG9uZ3Mg dG8gdGhlIGZvb3RwcmludC9nZW89lEZyYW5jZZQNCgkJCQkJCQkJCXRoZW4sIHRoZSBkZWxpdmVy eSBvZiB0aGUgcmVxdWVzdGVkIGNvbnRlbnQgaXMgZG9uZSBieSB0aGUgQ0ROIEEgaXRzZWxmDQoJ CQkJCQkJCQkJZWxzZSANCgkJCQkJCQkJCQlpZiB0aGUgSVAgc291cmNlIGFkZHJlc3MgYmVsb25n cyB0byB0aGUgZm9vdHByaW50L2dlbz2URXVyb3BllCANCgkJCQkJCQkJCQkgICAgYW5kIGlmIHRo ZSBFbmQtdXNlciByZXF1ZXN0IG9mIGNvbnRlbnQgbWF0Y2hlcyB0aGUgY2xhc3Mtb2YtcmVxdWVz dC9VUklfY2xhc3Mgk2h0dHAvL2Nkbi5jcDEuY29tL3ZpZGVvLyo/IHVybF9zaWduaW5nPZRiYpQm KpQNCgkJCQkJCQkJCQkJdGhlbiwgdGhlIGRlbGl2ZXJ5IG9mIHRoZSByZXF1ZXN0ZWQgY29udGVu dCBpcyBkZWxlZ2F0ZWQgdG8gQ0ROIEIgDQoJCQkJCQkJCQkJZWxzZSANCgkJCQkJCQkJCQkJaWYg dGhlIElQIHNvdXJjZSBhZGRyZXNzIGJlbG9uZ3MgdG8gdGhlIGZvb3RwcmludC9nZW89lFdvcmxk lCANCgkJCQkJCQkJCQkJICAgIG9yIGlmIHRoZSBJUCBzb3VyY2UgYWRkcmVzcyBiZWxvbmdzIHRv IHRoZSBmb290cHJpbnQvZ2VvPZRFdXJvcGWUIA0KCQkJCQkJCQkJCSAgICAgICAgICAgIGFuZCBp ZiB0aGUgRW5kLXVzZXIgcmVxdWVzdCBvZiBjb250ZW50IG1hdGNoZXMgdGhlIGNsYXNzLW9mLXJl cXVlc3QvVVJJX2NsYXNzIJNodHRwLy9jZG4uY3AxLmNvbS92aWRlby8qPyB1cmxfc2lnbmluZz2U YmKUJiqUDQoJCQkJCQkJCQkJCXRoZW4sIHRoZSBkZWxpdmVyeSBvZiB0aGUgcmVxdWVzdGVkIGNv bnRlbnQgaXMgZGVsZWdhdGVkIHRvIENETiBEDQoJCQkJCQkJCQkNCgkJDQoJCQ0KCQkNCgkJDQoJ CQkJCQkJCQkJCSAgDQoJCQkJCQkJCVN1Yi11c2UgY2FzZSAyIDoNCgkJCQkJCQkJDQoJCQkJCQkJ CUEgcHJvYmxlbSBvY2N1cnMgb24gQ0ROIEMgc28gdGhhdCBpdCBpcyBub3QgYWJsZSB0byBkZWxp dmVyIGFueW1vcmUgY29udGVudCB1c2luZyBSVE1QIGZvciBmb290cHJpbnQgIlNwYWluIi4NCgkJ CQkJCQkJQ0ROIEEgbXVzdCBub3cgc2VsZWN0cyBDRE4gRCBmb3IgdGhlIGRlbGl2ZXJ5IG9mIENQ MZJzIGNvbnRlbnQgaW4gUlRNUCBmb3IgY2xpZW50IGluIFNwYWluLg0KDQoJCQkJCQkJCQlSZXF1 ZXN0IFJvdXRpbmcvZm9vdHByaW50JmNhcGFiaWxpdGllcyBOb3RpZmljYXRpb25zIDogDQoNCgkJ CQkJCQkJCTEpIENETiBDIC0gQ0ROIEIgUmVxdWVzdCBSb3V0aW5nL2Zvb3RwcmludCZjYXBhYmls aXRpZXMgTm90aWZpY2F0aW9uIA0KDQoJCQkJCQkJCQlDRE4gQyB3aWxsIHRoZW4gc2VuZCBhIHJl cXVlc3Qgcm91dGluZyBpbmZvcm1hdGlvbiBub3RpZmljYXRpb24gdG8gQ0ROIEINCgkJCQkJCQkJ CVRoaXMgbm90aWZpY2F0aW9uIGluY2x1ZGVzIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVyczoNCgkJ U2VydmljZSA6DQoJCQkgIHsgIA0KCQkJCSAgU2VydmljZV9BZ3JlZW1lbnRfaWQgPSBzZXJ2aWNl LUFncmVlZW1lbnRfYmMNCgkJCQkgIFN0YXR1cyA9IG1vZGlmaWVkDQoJCQkJICB7CQ0KCQkJCQkJ Im1vZGlmaWVkIGRlbGl2ZXJ5IFNlcnZpY2UiIDogImRlbGl2ZXJ5X3NlcnZpY2Vfc3RhbmRhcmRf QyIgOg0KCQkJCQkJew0KCQkJCQkJCSJtb2RpZmllZCBDbGFzcy1vZi1yZXF1ZXN0IiA6ICJDUDFf bGl2ZV9zdGFuZGFyZF9DIiA6DQoJCQkJCQkJew0KCQkJCQkJCQkiVVJJLUNsYXNzIiA6ICJydG1w Oi8vY2RuLmNwMS5jb20vbGl2ZS9zdGFuZGFyZC8qP3VybF9zaWduaW5nPSJiYiImKiIgDQoJCQkJ CQkJCSJmb290cHJpbnQiIDogDQoJCQkJCQkJCXsJDQoJCQkJCQkJCQkiem9uZSI6DQoJCQkJCQkJ CQl7DQoJCQkJCQkJCQkJImZyb20iIDoNCgkJCQkJCQkJCQl7DQoJCQkJCQkJCQkJCSJnZW8iOiAi RXVyb3BlIg0KCQkJCQkJCQkJCX0NCgkJCQkJCQkJCQkiZXhjdWRlIiA6DQoJCQkJCQkJCQkJew0K CQkJCQkJCQkJCQkiZ2VvIiA6ICJTcGFpbiINCgkJCQkJCQkJCQl9CQ0KCQkJCQkJCQkJfQ0KCQkJ CQkJCQl9DQoJCQkJCQkJfQkJCQkJCQkJCQ0KCQkJCQkJPEFORD4NCgkJCQkJCSJtb2RpZmllZCBk ZWxpdmVyeSBTZXJ2aWNlIiA6ICJkZWxpdmVyeV9zZXJ2aWNlX3ByZW1pdW1fQyIgDQoJCQkJCQl7 DQoJCQkJCQkJIk1vZGlmaWVkIENsYXNzLW9mLXJlcXVlc3QiIDogIkNQMV9saXZlX3ByZW1pdW1f QyIgOg0KCQkJCQkJCXsNCgkJCQkJCQkJIlVSSS1DbGFzcyIgOiAicnRtcDovL2Nkbi5jcDEuY29t L2xpdmUvcHJlbWl1bS8qP3VybF9zaWduaW5nPSJiYiImKiIgDQoJCQkJCQkJCSJmb290cHJpbnQi IDogDQoJCQkJCQkJCXsJDQoJCQkJCQkJCQkiem9uZSI6DQoJCQkJCQkJCQl7DQoJCQkJCQkJCQkJ ImZyb20iIDoNCgkJCQkJCQkJCQl7DQoJCQkJCQkJCQkJCSJnZW8iOiAiRXVyb3BlIg0KCQkJCQkJ CQkJCX0NCgkJCQkJCQkJCQkiZXhjdWRlIiA6DQoJCQkJCQkJCQkJew0KCQkJCQkJCQkJCQkiZ2Vv IiA6ICJTcGFpbiINCgkJCQkJCQkJCQl9CQ0KCQkJCQkJCQkJfQ0KCQkJCQkJCQl9DQoJCQkJCQkJ fQkJCQkJCQkJCQ0KCQkJCQkJCQ0KCQkJCQkJfQ0KCQkJCQl9DQoJCQkgIH0NCg0KDQoJCQkJCQkJ CQkyKSBDRE4gQiAtIENETiBBIFJlcXVlc3QgUm91dGluZy9mb290cHJpbnQmY2FwYWJpbGl0aWVz IE5vdGlmaWNhdGlvbiANCg0KCQkJCQkJCQkJQ0ROIEIgd2lsbCB0aGVuIHNlbmQgYSByZXF1ZXN0 IHJvdXRpbmcgaW5mb3JtYXRpb24gbm90aWZpY2F0aW9uIHRvIENETiBBDQoJCQkJCQkJCQlUaGlz IG5vdGlmaWNhdGlvbiBpbmNsdWRlcyB0aGUgZm9sbG93aW5nIHBhcmFtZXRlcnM6DQoJCVNlcnZp Y2UgOg0KCQkJICB7ICANCgkJCQkgIFNlcnZpY2VfQWdyZWVtZW50X2lkID0gc2VydmljZS1BZ3Jl ZWVtZW50X2JjDQoJCQkJICBTdGF0dXMgPSBtb2RpZmllZA0KCQkJCSAgewkNCgkJCQkJICAibW9k aWZpZWQgZGVsaXZlcnkgc2VydmljZSIgOiAiZGVsaXZlcnlfc2VydmljZV9zdGFuZGFyZF9CICIN CgkJCQkJCXsNCgkJCQkJCQkibW9kaWZpZWQgQ2xhc3Mtb2YtcmVxdWVzdCIgOiAiQ1AxX2xpdmVf c3RhbmRhcmRfQiIgDQoJCQkJCQkJew0KCQkJCQkJCQkiVVJJLUNsYXNzIiA6ICJydG1wOi8vY2Ru LmNwMS5jb20vbGl2ZS9zdGFuZGFyZC8qP3VybF9zaWduaW5nPSJiYiImKiIgDQoJCQkJCQkJCSJm b290cHJpbnQiIDogDQoJCQkJCQkJCXsNCgkJCQkJCQkJCSJ6b25lIjoNCgkJCQkJCQkJCXsNCgkJ CQkJCQkJCQkiZnJvbSIgOg0KCQkJCQkJCQkJCXsNCgkJCQkJCQkJCQkJImdlbyI6ICJFdXJvcGUi DQoJCQkJCQkJCQkJfQ0KCQkJCQkJCQkJCSJleGN1ZGUiIDoNCgkJCQkJCQkJCQkJew0KCQkJCQkJ CQkJCQkJImdlbyIgOiAiU3BhaW4iDQoJCQkJCQkJCQkJCX0JDQoJCQkJCQkJCQl9DQoJCQkJCQkJ CX0NCgkJCQkJCQl9CQkJCQkNCgkJCQkJCTxBTkQ+DQoJCQkJCQkibW9kaWZpZWQgZGVsaXZlcnkg c2VydmljZSIgOiAiZGVsaXZlcnlfbGl2ZV9wcmVtaXVtX0IiIA0KCQkJCQkJew0KCQkJCQkJCSIg bW9kaWZpZWQgQ2xhc3Mtb2YtcmVxdWVzdCI9ICJDUDFfbGl2ZV9wcmVtaXVtX0IiIA0KCQkJCQkJ CQl7DQoJCQkJCQkJCQkiVVJJLUNsYXNzIiA6ICJydG1wOi8vY2RuLmNwMS5jb20vbGl2ZS9wcmVt aXVtLyo/dXJsX3NpZ25pbmc9ImJiIiYqIiANCgkJCQkJCQkJCSJmb290cHJpbnQiIDogDQoJCQkJ CQkJCQkJew0KCQkJCQkJCQkJCQkiem9uZSI6DQoJCQkJCQkJCQkJCXsNCgkJCQkJCQkJCQkJCSJm cm9tIiA6DQoJCQkJCQkJCQkJCQkJew0KCQkJCQkJCQkJCQkJCQkiZ2VvIjogIkV1cm9wZSINCgkJ CQkJCQkJCQkJCQl9DQoJCQkJCQkJCQkJCQkiZXhjdWRlIiA6DQoJCQkJCQkJCQkJCQkJew0KCQkJ CQkJCQkJCQkJCQkiZ2VvIiA6ICJTcGFpbiINCgkJCQkJCQkJCQkJCQl9CQkNCgkJCQkJCQkJCQkJ fQ0KCQkJCQkJCQkJCX0NCgkJCQkJCQkJfQkJCQkJDQoJCQkJCQl9DQoJCQkJCX0NCgkJCQl9DQoN CgkJCQkJCQkJCQkJQWZ0ZXIgQ0ROIEEgaGFzIHJlY2VpdmVkIHRoaXMgUmVxdWVzdCByb3V0aW5n IGluZm9ybWF0aW9uIG5vdGlmaWNhdGlvbiwgaXMgZENETiBzZWxlY3Rpb24gYWxnb3JpdGhtIGlz IG1vZGlmaWVkLg0KDQoNCg0KDQoJCQkJCQkNCgkJCQkJDQoJCQkJCQkNCgkJCQkJCQ0KCQkJCQkJ DQoJCQkJCQkNCgkNCgkJCQkJDQoJCQkJCQ== --_007_E5E1F88FBF39A84689D4A4791AE362B90203AFPEXCVZYM12corpora_-- From flefauch@cisco.com Tue Oct 23 11:10:52 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 BDC0D21F86B2 for ; Tue, 23 Oct 2012 11:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sWltU1+GYt8 for ; Tue, 23 Oct 2012 11:10:51 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 24C4021F86B1 for ; Tue, 23 Oct 2012 11:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17006; q=dns/txt; s=iport; t=1351015851; x=1352225451; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=moHFHAYEjYj3H34N69a1t4G9nimV4FlBdMp0CaBwBvI=; b=Cyu2Js4Y3TpExWwF9YCfCYoYPvS5iM/krbiC1MG+DdEDTZZsRE4qstLK c3PMX58DT6NC+AyecM78zfF32Ev2LYwaUJgcSMaeHUU6hOjDZEveFSoyR YhPsB+ubNHEAdl1YXS/085XOUnOyke2sR/dANHothLY8SlpqtiNtr4QMj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHTchlCtJV2b/2dsb2JhbABEwXCBCIIeAQEBAwEBAQEPARQTNAsFBwQCARkEAQELFAkHJwsUCQgCBA4FCAEZh1wGC5wDj1yQLotfhX5gA5EzgQyESY03gWuCb4IY X-IronPort-AV: E=Sophos;i="4.80,637,1344211200"; d="scan'208";a="134551130" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 23 Oct 2012 18:10:50 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9NIAm4t010003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Oct 2012 18:10:48 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.001; Tue, 23 Oct 2012 13:10:48 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: First batch of comments from review of draft-ietf-cdni-metadata-00.txt Thread-Index: AQHNsUm63sRF/Xg/pkCylJisS6aMZg== Date: Tue, 23 Oct 2012 18:10:48 +0000 Message-ID: References: <20121002173431.31982.57229.idtracker@ietfa.amsl.com> <166EBB70C264A9479E459B01B1BA6C920F3D5FC5@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C920F3D5FC5@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19298.000 x-tm-as-result: No--40.094700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] First batch of comments from review of draft-ietf-cdni-metadata-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2012 18:10:52 -0000 Hello, I started doing a review of draft-ietf-cdni-metadata-00.txt (as an Individu= al). This document is shaping up very well.=20 My specific comments/questions/suggestions are listed below (I stopped just= before section 4.3). I hope this is useful. Francois Comments/Suggestions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D OLD: " Cacheability improves the latency of acquiring metadata=20 " NEW: " Cacheability improves the latency of acquiring metadata while maintaining i= ts freshness " OLD: " Deterministic mappings from content requests to metadata properties eliminates ambiguity and ensures that the same policies are applied consistently by all downstream CDNs. " NEW: " Deterministic mappings from content to metadata properties eliminates ambiguity and ensures that policies are applied consistently by all downstream CDNs. " (the policies may not be exactly the same for all dCDNs, but they need to b= e deterministic so uCDN can achieve consistent operation) OLD: " describes a data structure for mapping content requests to metadata properties " NEW: " describes a data structure for mapping redirection requests and content requests to metadata properties " (Note: this occurs many times throughout the documents) OLD: " A HostIndex object contains a list of Hostnames (and/or IP addresses) that may be delegated to the downstream CDN. " NEW: " A HostIndex object contains a list of Hostnames (and/or IP addresses) for which content requests may be delegated to the downstream CDN. " OLD: " When looking up CDNI Metadata, the downstream CDN looks up the requested Hostname (or IP address) in the HostIndex, from there it can find HostMetadata which describes delivery rules for a host and PathMetadata which may override those rules for given URI paths within the host. " NEW: " When looking up CDNI Metadata, the downstream CDN looks up the requested Hostname (or IP address) in the HostIndex, from there it can find HostMetadata which describes properties for a host and PathMetadata which may override those properties for given URI paths within the host. " (rationale: there is more to metadata than just delivery rules, e.g. acquis= ition info). OLD: " | HostIndex | A HostIndex object lists the Hostnames (and/or | | | IP addresses) that an upstream CDN can provide | | | CDNI Metadata for and the URIs to use for | | | retrieving that CDNI Metadata. For example, if | | | "example.com" is a content provider, the | | | HostIndex object may include an entry for | | | "example.com" with the URI of the associated | | | HostMetadata object. These hostnames are | | | contained inside a list of HostMatch objects. | | HostMatch | A HostMatch object defines a hostname to match | | | against a requested host, and contains or | | | references a HostMetadata object which contains | | | CDNI Metadata objects to be applied when a | | | content request matches against the hostname. | " NEW: " | HostIndex | A HostIndex object lists HostMatch objects| | HostMatch | A HostMatch object defines a hostname (and/or IP add= resses) to match | | | against a requested host, and contains or | | | references a HostMetadata object which contains | | | CDNI Metadata objects to be applied when a | | | request matches against the hostname. | | | For example, if | | | "example.com" is a content provider, a | | | HostMatch object may include an entry for | | | "example.com" with the URI of the associated | | | HostMetadata object.=20 " (Rationale: as currently written, I had a hard time follow the structure. B= ecause it first says that the HostIndex lists the hostnames and then explai= ns that those are actually contained inside HostMatch) =20 OLD: " | PathMatch | A PathMatch object defines a pattern to match | | | against the requested path, and contains or | " NEW: " | PathMatch | A PathMatch object defines a pattern to match | | | against the requested URI path, and contains or = |=20 " In Figure 1, I think it would help a bit if you indicated next to each refe= rence, the valid number of such references. For example, from HostIndex to HostMatch it would say: " ---(0-N)--->" >From HostMatch to HostMetadata it would say :"---(1)-->" OLD: " | GenericMetadata | A GenericMetadata object contains individual | | | CDNI Metadata property objects which define the | " NEW: " | GenericMetadata | A GenericMetadata object contains individual | | | CDNI Metadata objects which define the |=20 " section 3.2, 1st and 2nd paragraph: "serialization rules, etc.)": this is the first time "serialization" is men= tioned (and "deserialization" is then mentioned in 2nd paragraph). I think = this terms need some description. section 3.2, 2nd & 3rd paragraph: 2nd paragraph specifies behavior when property is not supported and mandato= ry.=20 I think the third paragraph implies that when it is not mandatory then whet= her or not it can be re-distributed in a cascaded CDNs scenario depends on = the specific "redistribution friendliness" of the object. If I am correct t= hen: * you shoudl first indicate that when object is not understood and not man= datory, the request can be served. * and then explain that with respect to redistribution in case of cascaded= CDNs, here is the rule. Have you considered using the term "Transitive" instead of "Redistribution = safety" (i.e. as used in BGP) (this would also impact text in section 4.1.= 7)? section 3.3. You define precisely the scenarios where override happens. While implied, i= t may be worth explicitly saying when inheritance happens. Something like: " Objects of a given type previously defined by a parent object in the tree are inherited when no object of the same type is defined by the= child object. " And I'd suggest using your existing example to illustrate that also. So, OLD: " GenericMetadata objects of a given type override all GenericMetadata objects of the same type previously defined by any parent object in the tree. For example, if HostMetadata for the host "example.com" contains GenericMetadata objects of type LocationACL and TimeWindowACL, while a PathMetadata object which applies to "example.com/movies/*" defines an alternate GenericMetadata object of type TimeWindowACL, The PathMetadata defined TimeWindowACL would override the TimeWindowACL defined in the HostMetadata for all User Agent requests for movies. " NEW: " GenericMetadata objects of a given type override all GenericMetadata objects of the same type previously defined by any parent object in the tree. Objects of a given type previously defined by a parent object= in the tree are inherited when no object of the same type is defined by the= child object. For example, if HostMetadata for the host "example.com" contains GenericMetadata objects of type LocationACL and TimeWindowACL, while a PathMetadata object which applies to "example.com/movies/*" defines an alternate GenericMetadata object of type TimeWindowACL, then: * the TimeWindowACL defined in the PathMetadata would override the TimeWindowACL defined in the HostMetadata * the LocationACL defined in the HostMetadata would be inherited for all User Agent requests for content under "example.com/movies".=20 " OLD: " 3.3. Metadata Inheritance " NEW: " 3.3. Metadata Inheritance and Override=20 " section 3.4. While it is useful to provide an example of naming for vendor extensions, i= t is a little confusing to only provide such an example. I suggest you first include an example of Metadata Name actually specified = by this document (e.g. "HostMetadata"?) and only then go into further detai= ls for vendor extensions. section 4.1.1: OLD: " The HostIndex object is the entry point into the CDNI Metadata hierarchy. An incoming content request is matched against the list of hosts to find the HostMatch object which applies to the request. " NEW: " The HostIndex object is the entry point into the CDNI Metadata hierarchy. It contains a list of HostMatch objects. An incoming request = is matched against the hostname inside each of the listed HostMatch objects= to find the HostMatch object which applies to the request. " section 4.1.2: OLD: " The HostMatch object contains a hostname or IP address to match against content requests. The HostMatch object references Metadata objects to apply if a match is found. " NEW: " The HostMatch object contains a hostname or IP address to match against content requests. The HostMatch object also contains a referenc= e to Metadata objects to apply if a match is found. " section 4.1.2: I think you need to specify behavior in case there are separate HostMatch o= bjects for a domain and one of its subdomain. e.g. "video.example.com" and = "premium.video.example.com". "first match applies" or "more specific match= "?=20 section 4.1.6: "The three literals \ , * and ? should be escaped as \\, \* and \?" why does "\" have to be escaped if it does not have ay special meaning (lik= e "*" and "?") ? section 4.2.1: " Property: sources ... Mandatory-to-Specify: No. " So how would content be acquired in the absence of a "sources" property? vi= a some out-of-scope configuration? in any case, can you discuss your assump= tions here for how content would be acquired in that case? section 4.2.1: You need to indicate expected behavior when there are multiple sources list= ed: is it in descending order of preference from viewpoint of dCDN? is it l= eft to the dCDN? something else? I would assume the 1st option. section 4.2.1.1: Since the sources property contains a list of sources, do we also need to a= llow multiple endpoints within each source? Is the targeted benefit to avoid replication when you have multiple endpoin= ts that can be used with the exact same auth and protocol properties? section 4.2.2: " LocationACL Metadata defines location-based restrictions. Property: locations " Should the Property not be called "Property: locationACL"? If not, does this not conflict with the "Property: locations" of section 4.= 2.2.1? section 4.2.2: OLD: " A LocationRule contains or references a list of Location objects. LocationRule objects are used to construct a LocationACL to apply restrictions to content delivery. " NEW: " A LocationRule contains or references a list of Location objects and the= corresponding action. " (Note: the 2nd sentence is redundant with the description text in section 4= .2.2) section 4.2.2.1: " Property: action Description: Defines whether the rule specifies locations to allow or deny. Type: Enumeration [allow|deny] Mandatory-to-Specify: Yes. " Why not specify a Default action and make this a "Mandatory-to-Specify: No"= ? section 4.2.2.2: OLD: " A Location object describes a Location which may be applied by an ACLRule, e.g. a Location may be an IPv4 address range or a geographic location. " NEW: " A Location object describes a location which may be used as part of a Lo= cationRule,=20 e.g. a Location may be an IPv4 address range or a geographic location. " section 4.2.3: " TimeWindowACL Metadata defines time-based restrictions. Property: times " shoudl the Property not be named something like "Property: TimeWindowACL"? If not, does this not conflict with the "Property: times" of section 4.2.3.= 1? section 4.2.3.1: OLD: " A TimeWindowRule contains or references a list of TimeWindow objects. TimeWindowRule objects are used to construct a TimeWindowACL to apply restrictions to content delivery. " NEW: " A TimeWindowRule contains or references a list of TimeWindow objects and= the corresponding action " section 4.2.3.1: " Property: action Description: Defines whether the rule specifies time windows to allow or deny. Type: Enumeration [allow|deny] Mandatory-to-Specify: Yes. " Why not specify a Default action and make this a "Mandatory-to-Specify: No"= ? Table 3: "Table 3: MIME Media Types for CDNI Metadata resources" You have been using the terms of objects and properties before. Is "resourc= e" really the right term here? Editorials: =3D=3D=3D=3D=3D=3D=3D OLD: " [I-D.ietf-cdni-problem-statement] " NEW: " RFC 6707 " OLD: " are specified in [I-D.ietf-cdni-requirements] " NEW: " are specified in [I-D.ietf-cdni-requirements]. " OLD: " The proposed CDNI Metadata Interface aims to achieve the following design p= rinciples: " NEW: " The CDNI Metadata Interface was designed to achieve the following objective= s: " OLD: " Deterministic mapping from content requests to CDNI metadata properties " NEW: " Deterministic mapping from content to CDNI metadata properties " OR " Deterministic mapping from redirection requests and content requests to CDN= I metadata properties " OLD: " Different Hostnames and URI paths will contain different sets of CDNI Metadata properties " NEW: " Different Hostnames and URI paths will be associated with different sets of= CDNI Metadata properties " OLD: " Property: pattern Description: >A pattern for string matching.=20 " NEW: " Property: pattern Description: A pattern for string matching. =20 " section 4.1.7: OLD: " the the property " NEW: " the property " section 4.2.1 OLD: " how to contact an uCDN Surrogate or an Origin Server. " NEW: " how to contact an uCDN Surrogate or an Origin Server in order to obtain the= content to be served.=20 " section 4.2.1/4.2.1.1/4.2.2/4.2.2.1 "Type: List of Source"/ "List of EndPoint"/"List of LocationRule"/"Type: Li= st of Location" The singular after |list" reads off to me. I can see that those are object = names, but still I would consider using plural (e.g. List of Sources") or p= ossibly something like "List of Source properties"=20 On 2 Oct 2012, at 19:40, Matt Caulfield (mcaulfie) wrote: > Hi everyone, >=20 > We have posted the first revision of the Metadata Interface Draft which w= as accepted as a WG doc in Vancouver: draft-ietf-cdni-metadata. >=20 > Your comments and feedback are appreciated. >=20 > Regards, > Matt Caulfield >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Tuesday, October 02, 2012 1:35 PM > To: Matt Caulfield (mcaulfie) > Cc: ben@velocix.com; Kent Leung (kleung); kevin.ma@azukisystems.com; rmur= ray@velocix.com; gwatson@velocix.com > Subject: New Version Notification for draft-ietf-cdni-metadata-00.txt >=20 >=20 > A new version of I-D, draft-ietf-cdni-metadata-00.txt has been successful= ly submitted by Matt Caulfield and posted to the IETF repository. >=20 > Filename: draft-ietf-cdni-metadata > Revision: 00 > Title: CDN Interconnect Metadata > Creation date: 2012-10-02 > WG ID: cdni > Number of pages: 35 > URL: http://www.ietf.org/internet-drafts/draft-ietf-cdni-meta= data-00.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-cdni-metadata > Htmlized: http://tools.ietf.org/html/draft-ietf-cdni-metadata-00 >=20 >=20 > Abstract: > The CDNI Metadata Interface enables interconnected CDNs to exchange > content distribution metadata in order to enable content acquisition > and delivery. The CDNI metadata associated with a piece of content > provides a downstream CDN with sufficient information for the > downstream CDN to service content requests on behalf of an upstream > CDN. This document describes both the core set of CDNI metadata and > the protocol for exchanging that metadata. >=20 >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Wed Oct 24 07:58:00 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 C304221F86F9; Wed, 24 Oct 2012 07:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.529 X-Spam-Level: X-Spam-Status: No, score=-103.529 tagged_above=-999 required=5 tests=[AWL=0.070, 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 tHODQWpJkl49; Wed, 24 Oct 2012 07:57:59 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8A44621F863B; Wed, 24 Oct 2012 07:57:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id F1F6E1022FD; Wed, 24 Oct 2012 16:57:58 +0200 (CEST) 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 rpSmP9O4N+tv; Wed, 24 Oct 2012 16:57:58 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id D00AF102279; Wed, 24 Oct 2012 16:57:48 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Wed, 24 Oct 2012 16:57:48 +0200 From: Jan Seedorf To: "cdni@ietf.org" , "cdni-footprint@ietf.org" Thread-Topic: WEBEX Information for tomorrow's CDNI Footprint/Capabilities Design Team Call Thread-Index: Ac2x9+1OqGk37CJPQe6/J2jvQolkQw== Date: Wed, 24 Oct 2012 14:57:46 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553806F1@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] WEBEX Information for tomorrow's CDNI 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: Wed, 24 Oct 2012 14:58:00 -0000 Hi all, Just in case somebody missed it: please find below the WebEx information fo= r tomorrow's next CDNI Footprint/Capabilities Design Team Call, i.e. the ca= ll is=20 ** THU, OCT 25th, 16:00-18:00 CET ** - Jan -----Original Message----- From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint-bounces@ietf.o= rg] On Behalf Of Jan Seedorf Sent: Tuesday, October 23, 2012 3:33 PM To: stefano previdi; cdni-footprint@ietf.org Cc: cdni@ietf.org Subject: [cdni-footprint] WEBEX Information for next CDNI Footprint/Capabil= ities Design Team Call Stefano, Many thanks for setting up the WebEx once again! All, Please find below the WebEx info for the next call on Thursday this week. - Jan > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of stefano previdi > Sent: Monday, October 22, 2012 3:05 PM > To: cdni-footprint@ietf.org > Subject: [cdni-footprint] WEBEX Information Here >=20 >=20 >=20 > Topic: CDNI Footprint Design Team Interim Meeting > Date: Thursday, October 25, 2012 > Time: 4:00 pm, Europe Summer Time (Amsterdam, GMT+02:00) > Meeting Number: 200 625 864 > Meeting Password: cdni >=20 >=20 > ------------------------------------------------------- > To join the online meeting (Now from mobile devices!) > ------------------------------------------------------- > 1. Go to > https://cisco.webex.com/ciscosales/j.php?ED=3D207882597&UID=3D1897310317 > &PW=3DNM2QxOGQ4NTVi&RT=3DMiMyMg%3D%3D > 2. Enter your name and email address. > 3. Enter the meeting password: cdni > 4. Click "Join Now". > 5. Follow the instructions that appear on your screen. >=20 > To view in other time zones or languages, please click the link: > https://cisco.webex.com/ciscosales/j.php?ED=3D207882597&UID=3D1897310317 > &PW=3DNM2QxOGQ4NTVi&ORT=3DMiMyMg%3D%3D >=20 > ---------------------------------------------------------------- > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes > ---------------------------------------------------------------- >=20 > The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpi= tas > area and (866) 349-3520 for the RTP area. >=20 > 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 >=20 > ------------------------------------------------------- > 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 Acces= s > Code followed by the # sign. >=20 > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 >=20 > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 >=20 > India: +91.80.4350.1111 Germany: +49.619.6773.9002 >=20 > Japan: +81.3.5763.9394 China: +86.10.8515.5666 >=20 > ------------------------------------------------------- > For assistance > ------------------------------------------------------- > 1. Go to https://cisco.webex.com/ciscosales/mc > 2. On the left navigation bar, click "Support". >=20 > You can contact me at: > sprevidi@cisco.com > 39-0651644491 >=20 > To update this meeting to your calendar program (for example Microsoft > Outlook), click this link: > https://cisco.webex.com/ciscosales/j.php?ED=3D207882597&UID=3D1897310317 > &ICS=3DUMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DjZnJr0aeEyFuBdGk0n5hL8B7KM/- > 8hQspEMM8SAYsRI=3D&RT=3DMiMyMg%3D%3D >=20 >=20 > 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 > clicking this link: > https://cisco.webex.com/ciscosales/meetingcenter/mcsetup.php >=20 >=20 > The playback of UCF (Universal Communications Format) rich media files > requires appropriate players. To view this type of rich media files in th= e > meeting, please check whether you have the players installed on your > computer by going to > https://cisco.webex.com/ciscosales/systemdiagnosis.php. >=20 > http://www.webex.com >=20 > CCP:+14085256800x200625864# >=20 > IMPORTANT NOTICE: This WebEx service includes a feature that allows audio > and any documents and other materials exchanged or viewed during the > session to be recorded. By joining this session, you automatically consen= t 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 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 _______________________________________________ cdni-footprint mailing list cdni-footprint@ietf.org https://www.ietf.org/mailman/listinfo/cdni-footprint From kleung@cisco.com Wed Oct 24 09:28:28 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 AE50721F8CB4 for ; Wed, 24 Oct 2012 09:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Evdyv38Ez932 for ; Wed, 24 Oct 2012 09:28:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 291DA21F8CB2 for ; Wed, 24 Oct 2012 09:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2284; q=dns/txt; s=iport; t=1351096108; x=1352305708; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=J4y01BK0KvXKLTh30tbTzmGoun0dV2s+I5Dmt576Rvo=; b=ZCQTMp6DxsMRE5sX8509WGUZikyMNtdo6NseuVYbkqh98fihFHi1WkbT 29nwWElW9izywrh0mYccZBJLeGmpZXreUZ5s2rhOG4FROWQIQCamhMXj1 9liQSioKtPhAHiUOyQ8dZZlrTfkJ/mRjWxwK+Ej/PNUeUF44RqNbbwlSK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADkWiFCtJV2a/2dsb2JhbABEhhS6ZnqBCIIeAQEBBBIBEBFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBGYdiC5xqjSKSeYEgikGFWjJhA5cKjTeBa4JvgV0kGA X-IronPort-AV: E=Sophos;i="4.80,640,1344211200"; d="scan'208";a="134934523" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 24 Oct 2012 16:28:27 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q9OGSRtY009779 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 24 Oct 2012 16:28:27 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Wed, 24 Oct 2012 11:28:27 -0500 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-leung-cdni-uri-signing-01.txt Thread-Index: AQHNqpmYCRVHdKcDmUSHs+2y3rdZMJfIs0Bg Date: Wed, 24 Oct 2012 16:28:26 +0000 Message-ID: References: <20121015055448.29961.13736.idtracker@ietfa.amsl.com> In-Reply-To: <20121015055448.29961.13736.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.121.212] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19302.000 x-tm-as-result: No--30.010500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2012 16:28:28 -0000 SGkgYWxsLiBXZSBoYXZlIHB1Ymxpc2hlZCBhIG5ldyBkcmFmdCBmb3IgVVJJIFNpZ25pbmcuIFRo aXMgaXMgYSBzdGFydGluZyBwb2ludCBmb3IgRmxleGlibGUgVVJJIFNpZ25pbmcgYXMgbWVudGlv bmVkIGluIHByZXZpb3VzIGRpc2N1c3Npb25zLiBDb21tZW50cyBhcmUgd2VsY29tZS4gVGhhbmtz Lg0KDQpLZW50DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDog U3VuZGF5LCBPY3RvYmVyIDE0LCAyMDEyIDEwOjU1IFBNDQpUbzogRnJhbmNvaXMgTGUgRmF1Y2hl dXIgKGZsZWZhdWNoKQ0KQ2M6IEtlbnQgTGV1bmcgKGtsZXVuZyk7IE1hdHQgQ2F1bGZpZWxkICht Y2F1bGZpZSkNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGV1 bmctY2RuaS11cmktc2lnbmluZy0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJh ZnQtbGV1bmctY2RuaS11cmktc2lnbmluZy0wMS50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgRnJhbmNvaXMgTGUgRmF1Y2hldXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiBy ZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWxldW5nLWNkbmktdXJpLXNpZ25pbmcNClJl dmlzaW9uOgkgMDENClRpdGxlOgkJIFVSSSBTaWduaW5nIGZvciBDRE4gSW50ZXJjb25uZWN0aW9u IChDRE5JKQ0KQ3JlYXRpb24gZGF0ZToJIDIwMTItMTAtMTQNCldHIElEOgkJIEluZGl2aWR1YWwg U3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxOQ0KVVJMOiAgICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1sZXVuZy1jZG5pLXVyaS1zaWduaW5n LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWxldW5nLWNkbmktdXJpLXNpZ25pbmcNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGV1bmctY2RuaS11cmktc2lnbmluZy0wMQ0KRGlmZjog ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1sZXVuZy1j ZG5pLXVyaS1zaWduaW5nLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmli ZXMgaG93IHRoZSBjb25jZXB0IG9mIFVSSSBzaWduaW5nIHN1cHBvcnRzIHRoZQ0KICAgY29udGVu dCBhY2Nlc3MgY29udHJvbCByZXF1aXJlbWVudHMgb2YgQ0ROSSBhbmQgcHJvcG9zZXMgYSBjYW5k aWRhdGUNCiAgIFVSSSBzaWduaW5nIHNjaGVtZS4NCg0KICAgVGhlIHByb3Bvc2VkIFVSSSBzaWdu aW5nIG1ldGhvZCBzcGVjaWZpZXMgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0bw0KICAgYmUgaW5j bHVkZWQgaW4gdGhlIFVSSSBhbmQgdGhlIGFsZ29yaXRobSB1c2VkIHRvIGF1dGhvcml6ZSBhbmQg dG8NCiAgIHZhbGlkYXRlIGFjY2VzcyByZXF1ZXN0IGZvciB0aGUgY29udGVudCByZWZlcmVuY2Vk IGJ5IHRoZSBVUkkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBT ZWNyZXRhcmlhdA0KDQo= From ietfdbh@comcast.net Mon Oct 22 14:17:20 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 0590C21F84C5 for ; Mon, 22 Oct 2012 14:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.437 X-Spam-Level: X-Spam-Status: No, score=-100.437 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.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 eLNlFi08Ll+4 for ; Mon, 22 Oct 2012 14:17:19 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id EECC321F8453 for ; Mon, 22 Oct 2012 14:17:18 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id EC011k0070xGWP853MHPpa; Mon, 22 Oct 2012 21:17:23 +0000 Received: from JV6RVH1 ([71.233.85.150]) by omta12.westchester.pa.mail.comcast.net with comcast id EMGH1k00C3Ecudz3YMGHw1; Mon, 22 Oct 2012 21:16:17 +0000 From: "ietfdbh" To: References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> In-Reply-To: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 17:17:17 -0400 Message-ID: <021501cdb09a$9da68300$d8f38900$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKVJ5ZQVWRGZstnq+mhCPHo4nvoqpY22vMA Content-Language: en-us X-Mailman-Approved-At: Wed, 24 Oct 2012 10:41:48 -0700 Cc: David Harrington Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-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, 22 Oct 2012 21:17:20 -0000 Hi, I took a quick look at this document. I have a few comments. 1) While appendix C is yet to be written, the placeholders seem to already poo-poo the candidates that are existing IETF standards, without documenting why they are not viable choices. 2) Appendix C2 references RFC6707, which states some conclusions that have no documentation as to how the conclusions were reached. What are the scalability requirements for the CDNI logging interface? RFC6707 states that there are "scalability concerns", but doesn't specify the requirements or the specific concerns. There may be valid scalability concerns, but this deserves better documentation than mere handwaving. Which scalability requirements are not possible to meet with SNMPv3? 3) RFC6707 states SNMP does not support guaranteed delivery of traps. I am not sure how this conclusion was reached. SNMPv3 has Informs (acknowledged traps), which support application-level acknowledgement of receipt. An SNMPv3 agent could continue to periodically send the Inform until it receives acknowledgement of receipt. This would seem to mitigate the concern that use of SNMP "could result in log records being lost". Note that SNMPv1 has been declared Historic, so shouldn't even be considered a candidate protocol for new usage. Only version 3 of SNMP is recommended. That said, I would think that syslog [RFC5424] might be a better choice for CDNI logging. It uses secure, reliable transport over TLS (RFC5425). Signed syslog messages [RFC5848] can be used by receivers to verify they have received all the messages sent to them. If messages are out-of-order or missing, the receiver can determine which records are missing and request they be resent. In addition, the signing can be applied to stored logs to verify they have not been modified from the original message stream. If you are considering the RECOMMENDED versions of these candidate protocols, they might better meet the requirements. But the main point is that the consideration process should be documented more clearly than this document (or RFC6707) does. David Harrington ietfdbh@comcast.net +1-603-828-1401 -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, October 22, 2012 2:59 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-bertrand-cdni-logging-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : CDNI Logging Interface Author(s) : Gilles Bertrand Stephan Emile Roy Peterkofsky Francois Le Faucheur Pawel Grochocki Filename : draft-bertrand-cdni-logging-02.txt Pages : 43 Date : 2012-10-22 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-bertrand-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-bertrand-cdni-logging-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-bertrand-cdni-logging-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From ben@niven-jenkins.co.uk Thu Oct 25 11:06:52 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 D10CB21F8914 for ; Thu, 25 Oct 2012 11:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7YMiORRi-9A for ; Thu, 25 Oct 2012 11:06:48 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2B30521F890B for ; Thu, 25 Oct 2012 11:06:48 -0700 (PDT) Received: from [123.124.244.101] (helo=[172.31.12.21]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1TRRpN-0004AC-Ot; Thu, 25 Oct 2012 19:06:46 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: <021501cdb09a$9da68300$d8f38900$@comcast.net> Date: Thu, 25 Oct 2012 19:06:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121022185902.22651.23401.idtracker@ietfa.amsl.com> <021501cdb09a$9da68300$d8f38900$@comcast.net> To: "ietfdbh" X-Mailer: Apple Mail (2.1084) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: cdni@ietf.org Subject: Re: [CDNi] I-D Action: draft-bertrand-cdni-logging-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: Thu, 25 Oct 2012 18:06:52 -0000 David, I haven't read the draft but wanted to make a quick comment on = scalability. On 22 Oct 2012, at 22:17, ietfdbh wrote: > 2) Appendix C2 references RFC6707, which states some conclusions that = have > no documentation as to how the conclusions were reached. > What are the scalability requirements for the CDNI logging interface?=20= I guess we still need to work on that but I have some models that can = predict log volumes given various scenarios and I could probably also = pull together some anonymised data from real deployments (if I can get = permission from a customer) that we could use to inform any scalability = numbers we come up with but that will take a little time to pull = together. But as an example, let's assume a cache is delivering Live MS = Smoothstreaming and the clients are requesting the manifest every 10 = seconds then a CDN will be generating 1100 log lines a second for each = Gbps of traffic it is delivering. Scale that up to what deployed CDNs are actually delivering and the = numbers get pretty big both in terms of log lines/second and data = transferred per log. Of course we need to temper that with the fact that we may want to = exchange log lines in batches rather than individually and that not = every delivery is going to come from an interconnect and that delivery = protocol, HTTP adaptive segment size, average viewing time, etc have a = large impact on the number of log lines produced for a given content = delivery. In terms of data transfer the main contributor to that is the = verbosity of the log line (i.e. how many fields are logged and = specifically which fields are logged) as some fields (such as cookies or = user agent strings) are significantly more verbose than others (such as = port numbers). Ben From Jan.Seedorf@neclab.eu Fri Oct 26 02:07:26 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 EBC2821F84F8; Fri, 26 Oct 2012 02:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.533 X-Spam-Level: X-Spam-Status: No, score=-103.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 9tkVv8DjFqim; Fri, 26 Oct 2012 02:07:24 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C117C21F84F6; Fri, 26 Oct 2012 02:07:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9AB6010232F; Fri, 26 Oct 2012 11:07:23 +0200 (CEST) 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 7mTassOnmD+X; Fri, 26 Oct 2012 11:07:23 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 7E40A10232D; Fri, 26 Oct 2012 11:07:13 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 26 Oct 2012 11:06:52 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: CDNI Footprint/Capabilities Side Meeting at IETF-85 Thread-Index: Ac2zWNJ4Ubn3LbIsRrmDoGCfToaz1g== Date: Fri, 26 Oct 2012 09:06:02 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553821A3@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-footprint@ietf.org" Subject: [CDNi] CDNI Footprint/Capabilities Side Meeting at IETF-85 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, 26 Oct 2012 09:07:26 -0000 Hi all, As discussed in the phone call yesterday, let's aim for one 2h side meeting= at IETF-85, either on Monday or Tuesday (the CDNI WG sessions are on WED a= nd THU, so it's a good idea to have discussions before that). I have set up= a doodle, please fill it in if you are interested in joining: http://www.doodle.com/xcg78pfa5y932c9u - 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 Jan.Seedorf@neclab.eu Fri Oct 26 02:15:12 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 80FCC21F84EF; Fri, 26 Oct 2012 02:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.536 X-Spam-Level: X-Spam-Status: No, score=-103.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 BFR42s3fErM9; Fri, 26 Oct 2012 02:15:11 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFF421F84F3; Fri, 26 Oct 2012 02:15:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id B7B42102332; Fri, 26 Oct 2012 11:15:10 +0200 (CEST) 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 Bzq6jd3hR6hu; Fri, 26 Oct 2012 11:15:10 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 9E9A410232D; Fri, 26 Oct 2012 11:15:00 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.239]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Fri, 26 Oct 2012 11:14:11 +0200 From: Jan Seedorf To: "cdni-footprint@ietf.org" Thread-Topic: Notes from yesterday's Footprint/Capabilities Phone Call Thread-Index: Ac2zWWudW5QKQGK2QFCEx1JfaWF6qg== Date: Fri, 26 Oct 2012 09:14:10 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553821C4@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] Notes from yesterday's 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, 26 Oct 2012 09:15:12 -0000 Hi all, Below are my notes from yesterday's call. The next steps are to continue th= e discussion about what capabilities we regard as mandatory (and which ones= as optional), and also where we see the split between metadata and adverti= sement. Please comment on the list if you have opinions. If someone from the Metadata guys could summarize what they think is in sco= pe of metadata and where they see the split to advertisement, it would prob= ably help our discussion. - Jan CDNI Footprint/Capabilities Phone Call - 20121025 ************************************** -- Jan recaps last two phone calls: focus has been on capabilities and on a= greeing on a use case to drive the discussion; agreement has been found on = the use case proposed by Anne and Emile -- Anne summarizes the changes in the use case she circulated on the mailin= g list -- discussion that the interface will only signal the delta with respect to= a given contract; question is whether to send the whole state each time or= only what has changed; Francois: protocol should be able to signal a small= delta, but also be able to signal the whole state (e.g. at the beginning) -- discussion about quality parameters, agreement that highly dynamic param= eters should not be conveyed with advertisement; Francois: having very coar= se-grained quality information may be ok in advertisement; Jon: we should b= e careful not to over-design -- Scott: problem with quality advertisement may be that things can change = rapidly -- Jon: protocol exchange will not result in changing amount of money being= exchanged -- Francois: not sure that the capabilities should be expressed as a URL-ty= pe-of-syntax (as in the example circulated by Anne); Anne: URL-type-syntax = is important to have for the UCDN; -- agreement that type of delivery protocol is important; agreement that ty= pe of supported authorization mechanism is important; -- Francois: what about the concept of time-window? Is that a mandatory cap= ability? -- Jon: we need to split what is in metadata and what is in advertisement; -- Jon: some things are specific to a CDN (probably capabilities: what a CD= N can do), some things are specific to a piece of content (probably metadat= a) ************************************** =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 flefauch@cisco.com Fri Oct 26 06:27: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 9A2BE21F85E8 for ; Fri, 26 Oct 2012 06:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEYrQiY1gNON for ; Fri, 26 Oct 2012 06:27:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 046C721F85E7 for ; Fri, 26 Oct 2012 06:27:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=198; q=dns/txt; s=iport; t=1351258042; x=1352467642; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=eoBSfZ2BgNu74dU6Qc8YJWK8FH93ka7cGapd47T5zfg=; b=E3Hx0YoGmwnzE5Mpm9TLpbb32jl4FUALJbCRSFKuJzJqBEOGkaTuUlqi +X+hdAhg4/3ihHHz7ZCWvaIUsRSVYvjaKNQSqFF3neCDNPlt4r6N6pjk0 iQMdXH9O4lckeZvbP930+R+5HP6E1/kCxlTUNZtjAGuEgVMr5pcldDhXD A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiENAGKPilCtJV2c/2dsb2JhbABEhAGBULxtgQiCIAEEEgEnPxIBKhRCJwQODQEZh2QLnSGgFZF+YQOkRoFrgm+CGQ X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="135723676" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 26 Oct 2012 13:26:56 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9QDQuAO024078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 26 Oct 2012 13:26:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 08:26:55 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Draft IETF-85 CDNI agenda posted Thread-Index: AQHNs32Rxavj8yqdDUW4qupGyCZLgQ== Date: Fri, 26 Oct 2012 13:26:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19310.001 x-tm-as-result: No--27.194000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <27001F96C4546B43BE5569388AC011CD@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Draft IETF-85 CDNI agenda posted 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, 26 Oct 2012 13:27:22 -0000 Hi, The draft CDNI agenda is available online :http://www.ietf.org/proceedings/= 85/agenda/agenda-85-cdni. Please let us know if you have comments or if we have missed a slot. Cheers Francois From flefauch@cisco.com Fri Oct 26 09:59:05 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 33AB621F865C for ; Fri, 26 Oct 2012 09:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=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 V69IUYEfMNa2 for ; Fri, 26 Oct 2012 09:59:03 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 330C521F845D for ; Fri, 26 Oct 2012 09:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13114; q=dns/txt; s=iport; t=1351270743; x=1352480343; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=c6cRMLamy0EAUbVxL/MIzQeS9jBCpmjGEdH73FUVPD0=; b=ipE7aNmyEITMo8xV0IUuDmRvLHHLD6nxCK9/0WQgMK2pBPuReIx3/XAC JOE2Wl66egLlCxsGlY9adhwbWkmZ37c3CvoNxbHkZIoZWld2sjm4XeU2S 3wfFkV72FiqeJVuy/5J4dOiObiHRPj/dzoYaX713TqismWRI6ZzszYXUl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAILAilCtJXHA/2dsb2JhbABEwj+BCIIgAQQSASctEhIBKg8CA0InBA4NEgiHZAudA6Adj0wCgjBhA5JBhEmNPIFrgm+BPh8eHg X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="135755438" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 26 Oct 2012 16:59:02 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q9QGx24u030108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 16:59:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 11:59:02 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: Second batch of comments from review of draft-ietf-cdni-metadata-00.txt Thread-Index: AQHNs5sy+qvkpqkINECG0nClI2bygA== Date: Fri, 26 Oct 2012 16:59:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.199] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19310.001 x-tm-as-result: No--38.858400-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Second batch of comments from review of draft-ietf-cdni-metadata-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 16:59:05 -0000 Hello, Below are my second batch of comments (as an Individual). I hope this is useful. Francois General comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * When used, MUST/SHOULD/MAY are used appropriately. But I recommend you do= a pass to verify that there is enough MUST to capture everything that is m= andatory for an implementation. For example, I am not sure there is an expl= icit statement stating that all the objects/properties listed in section 3 = and 4 MUST be supported. * You provide examples of both JSON and XML encoding, which is very nice. I= suggest you start driving a discussion on the list as to which should be p= icked. Perhaps you could try list key pros&cons of each on the list? When you have decided , you could then replace "example encodings" by a spe= cification of the encoding. Specific Comments/Suggestions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Section 4.3.1 Link " A link object may be used in place of any of the objects described above. " I think this should be replaced by: " A link object may be used in place of any of the objects or properties desc= ribed above. "=20 because for example in the Source object (Property: auth + Property: endpoi= nts + Property: protocol) each property (e.g. Protocol) can be specified in= dividually using a link. Is this right? * section 4.3.2 Protocol: " This type only appears in Links.=20 " This is confusing because the Protocol type already appears in multiple obj= ects , for example in=20 " 4.2.1.1. Source Property: auth Description: Authentication method to use when requesting content from this source. Type: Auth Mandatory-to-Specify: No. Default is no authentication is required. Property: endpoints Description: Origins from which the dCDN can acquire content. Type: List of EndPoint Mandatory-to-Specify: Yes. Property: protocol Description: Protocol to use for content acquisition. Type: Protocol Mandatory-to-Specify: Yes. " Assuming I understand what you want to do correctly, perhaps you could call= the type define din 4.3.2 with a different name e.g. "ProtocolID" and this= special type would only appear inside a Link. Would that work? Or am I ent= irely missing what you want to do here? * section 4.3.2 Protocol: " The following examples are illustrative: o http://url.cdni.ietf.example/protocol/delivery/http/rfcABCD o http://url.cdni.ietf.example/protocol/delivery/rtmp/rfcEFGH o http://url.vendorY.ietf.example/protocol/delivery/rtmp/releaseP.Q " I think it would be useful to use a URI if that saved you from managing an = IANA register (e.g. because there exist a URI that unambiguously points to = the spec you want to reference e.g. http://datatracker.ietf.org/doc/rfc2616= /) but that will probably not work with /rtmp/releaseP.Q. So what is the be= nefit of using a URI here over defining an IANA register for these protocol= IDs? * section 5: OLD: " The interface can be used by a Downstream CDN to retrieve CDNI Metadata objects either dynamically as required by the Downstream CDN to process received requests (for example in response to receiving a CDNI Request Routing request from an Upstream CDN or in response to receiving a request for content from a User Agent) or in advance of being required. " NEW: " The interface can be used by a Downstream CDN to retrieve CDNI Metadata objects either dynamically as required by the Downstream CDN to process received requests (for example in response to receiving a CDNI Request Routing request from an Upstream CDN or in response to receiving a request for content from a User Agent) or in advance of being required (for example in case of Pre-positioned CDNI Metadata acqu= isition). " * section 5.2: OLD: " the HostIndex which provides the CDNI Metadata client with a list of Hostnames that the upstream CDN may delegate to the downstream CDN. " NEW: " the HostIndex which provides the CDNI Metadata client with a list of Hostnames for which the upstream CDN may delegate content delivery to the downstream CDN. " * section 5.2: " The CDNI metadata client then makes a GET request for the URI specified in the href key of that Host's entry in the HostIndex. " I have a couple of issue with that sentence: 1) the HostMetadata are found in the HostMatch entry for which there was a= match on the Host, so the text news tweaking. 2) while the HostMetadata may contain a href to the Metadata, I think it c= ould also actually contain the Metadata itself. If correct then, you need t= o tweak text to discuss both options. If incorrect then, you may need to tw= eak the text in section 4 that describes HostMatch. The same comment applies also to the following paragraph re PathMetadata. *section 5.2: OLD: " When application level redirection (e.g. HTTP 302 redirects) is being used between CDNs, it is expected that the downstream CDN will be able to determine the upstream CDN that redirected a particular request from information contained in the received request (e.g. via the URI in case of HTTP redirection across CDNs). " NEW: " When application level redirection (e.g. HTTP 302 redirects) is being used between CDNs, it is expected that the downstream CDN will be able to determine the upstream CDN that redirected a particular request from information contained in the received request (e.g. via the URI). " *section 5.2: OLD: " In the case of DNS redirection there is not sufficient information carried in the DNS request from User Agents to determine the upstream CDN that redirected a particular request and therefore downstream CDNs may have to apply local policy when deciding which upstream CDN's metadata to apply. " NEW: " In the case of DNS redirection there is not always sufficient information carried in the DNS request from User Agents to determine the upstream CDN that redirected a particular request (e.g. when content from a given= host is redirected to a given downstream CDN by more than one upstream CDN= ) and therefore downstream CDNs may have to apply local policy when deciding which upstream CDN metadata to apply. " *section5.3 Bootstrapping: OLD: " If the URI for the HostIndex object is not manually configured in the downstream CDN then the HostIndex URI could be discovered via the CDNI Control interface. An upstream CDN would provide the URI of the HostIndex object to the downstream CDN via the CDNI Control Interface. " NEW: " Mechanism allowing the downstream CDN to discover the URI of the HostIndex = are outside the scope of this document. " (Depending on the base protocol leveraged to support CDNI discovery in the = future, it may or may not be obvious that this would be considered part of = the Control Interface, so I recommend we don't try second-guess future work= and leave it open) OLD: " Table 3: MIME Media Types for CDNI Metadata resources " NEW: " Table 3: Example MIME Media Types for CDNI Metadata resources " (this is to make it clear that the table only contains a subset) section 5.4.2: " Dictionary keys in JSON are case sensitive and therefore any dictionary key defined by this document (for example the names of CDNI Metadata object properties) MUST always be represented in lowercase. " Are you saying that there was no choice and they had to be represented in l= ower case (as suggested by "therefore") or are you saying that we need to b= e case sensitive so to make it simpler you have decided to make them all lo= wer case and therefore they MUST be encoded that way? If it is the former, = please explain why. If it is the latter, then adjust text. * section 5.5: " it is suggested that proprietary and/or custom property Metadata be identified by the "ext." " Why not make this a stronger statement i.e. that "ext" MUST be used for any= proprietary/custom extensions? Also, could we specify a rule to define the how to signal "the organization= defining the property Metadata" e.g. FQDN in reverse order like ".com.comp= anyA"? * section 5.5.1: OLD: " Note: Ideally, uCDNs would not delegate content requests to a dCDN which does not support the Metadata=20 " NEW: " Note: Ideally, uCDNs would never delegate content requests to a dCDN which does not support the "mandatory-to-enforce" Metadata=20 " * section 5.5.1: OLD: " The dCDN MUST evaluate all Metadata " NEW: " This is why the dCDN MUST evaluate all Metadata " * section 5.5.2: " Note: Because Metadata is inherently ordered in GenericMetadata lists, as well as in the PathMetadata hierarchy and PathMatch lists, multiple conflicting Metadata types MAY be used, however, Metadata hierarchies MUST ensure that independent PathMatch root objects are used to prevent ambiguous or conflicting Metadata definitions. " I don't think the term PathMatch root object is well defined. I think what = you want to say is that it is OK to use conflicting metadata types as long = as they actually never apply to the same content. Right? It may be simpler = to express it that way. *Appendix A: OLD: " Requirements related to pre-positioning of metadata are not met directly by this document. Triggering metadata pre-positioning is beyond the scope of the CDNI Metadata interface. However, the interface as described by this document supports pulling metadata on- demand for the purpose of pre-positioning. " NEW: " Requirements related to pre-positioning of metadata are met by this document on the assumption that other CDNI Interfaces are to be = used by the upstream CDN to trigger the pre-positioning of metadata by the = downstream CDN via the CDNI Metadata Interface.=20 " *Appendix A: I think it would be useful to discuss how requirement META-7 is met: " META-7 [HIGH] The CDNI Metadata Distribution interface shall allow the Upstream CDN to request addition and modification of CDNI Metadata into the Downstream CDN. " *Appendix A: OLD: " Requirement META-13 relating to feedback from the downstream CDN to the upstream CDN with respect to metadata " NEW: " Requirement META-13 relating to feedback from the downstream CDN to the upstream CDN with respect to rejected metadata " *Appendix A: OLD: " As an alternative, the downstream CDN may use the CDNI Logging interface to convey error conditions related to metadata. " NEW: " As an alternative, the CDNI Logging interface could be extended to convey erro= r conditions related to metadata. " *Appendix A: " Requirement META-18 relating to surrogate cache behavior parameters is supported via extensibility. However, the example parameters in META-18 are not described in this document. " I know that META-18 is listed as [LOW] but I actually think that supporting= the "control of whether the query string of HTTP URI is to be ignored by s= urrogate cache" is actually both useful and extremely simple to add. Would = you be willing to add a simple binary property indicating whether query str= ing is to be ignored or not? Interestingly, the Metadata was expected to include 3 types of info: info r= elated to acquisition, info related to authorizing, info related to how to = deliver: " Metadata properties describe how to acquire, authorize, and deliver content from a downstream CDN. " The Query String ignore property would be a good example of metadata relate= d to how to deliver. Editorials: =3D=3D=3D=3D=3D=3D=3D OLD: " are not intended impose " NEW: " are not intended to impose " OLD: " document.Table 3 " NEW: " document. Table 3 " section 6: IANA OLD: " This document requests the registration of the "application/cdni" MIME type. " NEW: " This document requests the registration of the "application/cdni" MIME Media Type under the IANA MIME Media Type registry (http://www.iana= .org/assignments/media-types/index.html). *section 5.5.2: OLD: " Metadata assigned to a given content asset " NEW: " Metadata assigned to a given content " (asset is not part of the CDNI terminology) Appendix A: OLD: " All metadata requirements are met either directly or indirectly by the CDNI Metadata Interface described in this document. The following paragraphs describe notable exceptions. " NEW: " All metadata requirements are met either directly or indirectly by the CDNI Metadata Interface described in this document, with the clarifi= cations or exceptions=20 described in the following paragraphs. " OLD: " " NEW: " " OLD: " " NEW: " "= From mcaulfie@cisco.com Fri Oct 26 11:45:28 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 E931E21F8611 for ; Fri, 26 Oct 2012 11:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=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 l+ScqoumhAXB for ; Fri, 26 Oct 2012 11:45:26 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5B13421F85B3 for ; Fri, 26 Oct 2012 11:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13729; q=dns/txt; s=iport; t=1351277126; x=1352486726; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BPvoJhzJB6eLQfEEwwUc9CgyAS+D2MSubR3SW0d4zbc=; b=NMYmiTd52Ljl9xoArpBGDuoij3VuD9JXJ6lYdbZQpC0EXQXdxPdxzly8 Ta3gHen31KYdlStEvSDloaKcw+NSJH4+7VEYM9YNRJUDQaR/WK9BW3ST7 9/MAWhx3pQoPD97ZZ3ngUrDSzQNJwKN/3uxsiLlBvzwSbCdL0lK5KObM2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACDZilCtJV2Z/2dsb2JhbABEwlCBCIIeAQEBBAEBAQ8BJy0HCwwEAgEIEQQBAQsPAgMJBycLFAkIAgQBDQUIEgiHZAucaqAVi3GDWwKCMGEDkkGESY08gWuCb4E+Hx4e X-IronPort-AV: E=Sophos;i="4.80,654,1344211200"; d="scan'208";a="135571143" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 26 Oct 2012 18:45:25 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9QIjPAF003599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 26 Oct 2012 18:45:25 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.204]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.001; Fri, 26 Oct 2012 13:45:25 -0500 From: "Matt Caulfield (mcaulfie)" To: "Francois Le Faucheur (flefauch)" , "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: [CDNi] Second batch of comments from review of draft-ietf-cdni-metadata-00.txt Thread-Index: AQHNs5sy+qvkpqkINECG0nClI2bygJfL7Ffw Date: Fri, 26 Oct 2012 18:45:24 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C920F404118@xmb-aln-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.69.153] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19310.001 x-tm-as-result: No--38.431900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Second batch of comments from review of draft-ietf-cdni-metadata-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 18:45:28 -0000 Thank you for the detailed comments, Francois.=20 Hoping we can address both your first batch and second batch of questions r= elatively soon. Matt -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: Friday, October 26, 2012 12:59 PM To: draft-ietf-cdni-metadata@tools.ietf.org Cc: cdni@ietf.org Subject: [CDNi] Second batch of comments from review of draft-ietf-cdni-met= adata-00.txt Hello, Below are my second batch of comments (as an Individual). I hope this is useful. Francois General comments: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * When used, MUST/SHOULD/MAY are used appropriately. But I recommend you do= a pass to verify that there is enough MUST to capture everything that is m= andatory for an implementation. For example, I am not sure there is an expl= icit statement stating that all the objects/properties listed in section 3 = and 4 MUST be supported. * You provide examples of both JSON and XML encoding, which is very nice. I= suggest you start driving a discussion on the list as to which should be p= icked. Perhaps you could try list key pros&cons of each on the list? When you have decided , you could then replace "example encodings" by a spe= cification of the encoding. Specific Comments/Suggestions =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * Section 4.3.1 Link " A link object may be used in place of any of the objects described above. " I think this should be replaced by: " A link object may be used in place of any of the objects or properties desc= ribed above. "=20 because for example in the Source object (Property: auth + Property: endpoi= nts + Property: protocol) each property (e.g. Protocol) can be specified in= dividually using a link. Is this right? * section 4.3.2 Protocol: " This type only appears in Links.=20 " This is confusing because the Protocol type already appears in multiple obj= ects , for example in " 4.2.1.1. Source Property: auth Description: Authentication method to use when requesting content from this source. Type: Auth Mandatory-to-Specify: No. Default is no authentication is required. Property: endpoints Description: Origins from which the dCDN can acquire content. Type: List of EndPoint Mandatory-to-Specify: Yes. Property: protocol Description: Protocol to use for content acquisition. Type: Protocol Mandatory-to-Specify: Yes. " Assuming I understand what you want to do correctly, perhaps you could call= the type define din 4.3.2 with a different name e.g. "ProtocolID" and this= special type would only appear inside a Link. Would that work? Or am I ent= irely missing what you want to do here? * section 4.3.2 Protocol: " The following examples are illustrative: o http://url.cdni.ietf.example/protocol/delivery/http/rfcABCD o http://url.cdni.ietf.example/protocol/delivery/rtmp/rfcEFGH o http://url.vendorY.ietf.example/protocol/delivery/rtmp/releaseP.Q " I think it would be useful to use a URI if that saved you from managing an = IANA register (e.g. because there exist a URI that unambiguously points to = the spec you want to reference e.g. http://datatracker.ietf.org/doc/rfc2616= /) but that will probably not work with /rtmp/releaseP.Q. So what is the be= nefit of using a URI here over defining an IANA register for these protocol= IDs? * section 5: OLD: " The interface can be used by a Downstream CDN to retrieve CDNI Metadata objects either dynamically as required by the Downstream CDN to process received requests (for example in response to receiving a CDNI Request Routing request from an Upstream CDN or in response to receiving a request for content from a User Agent) or in advance of being required. " NEW: " The interface can be used by a Downstream CDN to retrieve CDNI Metadata objects either dynamically as required by the Downstream CDN to process received requests (for example in response to receiving a CDNI Request Routing request from an Upstream CDN or in response to receiving a request for content from a User Agent) or in advance of being required (for example in case of Pre-positioned CDNI Metadata acqu= isition). " * section 5.2: OLD: " the HostIndex which provides the CDNI Metadata client with a list of Hostnames that the upstream CDN may delegate to the downstream CDN. " NEW: " the HostIndex which provides the CDNI Metadata client with a list of Hostnames for which the upstream CDN may delegate content delivery to the downstream CDN. " * section 5.2: " The CDNI metadata client then makes a GET request for the URI specified in the href key of that Host's entry in the HostIndex. " I have a couple of issue with that sentence: 1) the HostMetadata are found in the HostMatch entry for which there was a= match on the Host, so the text news tweaking. 2) while the HostMetadata may contain a href to the Metadata, I think it c= ould also actually contain the Metadata itself. If correct then, you need t= o tweak text to discuss both options. If incorrect then, you may need to tw= eak the text in section 4 that describes HostMatch. The same comment applies also to the following paragraph re PathMetadata. *section 5.2: OLD: " When application level redirection (e.g. HTTP 302 redirects) is being used between CDNs, it is expected that the downstream CDN will be able to determine the upstream CDN that redirected a particular request from information contained in the received request (e.g. via the URI in case of HTTP redirection across CDNs). " NEW: " When application level redirection (e.g. HTTP 302 redirects) is being used between CDNs, it is expected that the downstream CDN will be able to determine the upstream CDN that redirected a particular request from information contained in the received request (e.g. via the URI). " *section 5.2: OLD: " In the case of DNS redirection there is not sufficient information carried in the DNS request from User Agents to determine the upstream CDN that redirected a particular request and therefore downstream CDNs may have to apply local policy when deciding which upstream CDN's metadata to apply. " NEW: " In the case of DNS redirection there is not always sufficient information carried in the DNS request from User Agents to determine the upstream CDN that redirected a particular request (e.g. when content from a given= host is redirected to a given downstream CDN by more than one upstream CDN= ) and therefore downstream CDNs may have to apply local policy when deciding which upstream CDN metadata to apply. " *section5.3 Bootstrapping: OLD: " If the URI for the HostIndex object is not manually configured in the downstream CDN then the HostIndex URI could be discovered via the CDNI Control interface. An upstream CDN would provide the URI of the HostIndex object to the downstream CDN via the CDNI Control Interface. " NEW: " Mechanism allowing the downstream CDN to discover the URI of the HostIndex = are outside the scope of this document. " (Depending on the base protocol leveraged to support CDNI discovery in the = future, it may or may not be obvious that this would be considered part of = the Control Interface, so I recommend we don't try second-guess future work= and leave it open) OLD: " Table 3: MIME Media Types for CDNI Metadata resources " NEW: " Table 3: Example MIME Media Types for CDNI Metadata resources " (this is to make it clear that the table only contains a subset) section 5.4.2: " Dictionary keys in JSON are case sensitive and therefore any dictionary key defined by this document (for example the names of CDNI Metadata object properties) MUST always be represented in lowercase. " Are you saying that there was no choice and they had to be represented in l= ower case (as suggested by "therefore") or are you saying that we need to b= e case sensitive so to make it simpler you have decided to make them all lo= wer case and therefore they MUST be encoded that way? If it is the former, = please explain why. If it is the latter, then adjust text. * section 5.5: " it is suggested that proprietary and/or custom property Metadata be identified by the "ext." " Why not make this a stronger statement i.e. that "ext" MUST be used for any= proprietary/custom extensions? Also, could we specify a rule to define the how to signal "the organization= defining the property Metadata" e.g. FQDN in reverse order like ".com.comp= anyA"? * section 5.5.1: OLD: " Note: Ideally, uCDNs would not delegate content requests to a dCDN which does not support the Metadata=20 " NEW: " Note: Ideally, uCDNs would never delegate content requests to a dCDN which does not support the "mandatory-to-enforce" Metadata=20 " * section 5.5.1: OLD: " The dCDN MUST evaluate all Metadata " NEW: " This is why the dCDN MUST evaluate all Metadata " * section 5.5.2: " Note: Because Metadata is inherently ordered in GenericMetadata lists, as well as in the PathMetadata hierarchy and PathMatch lists, multiple conflicting Metadata types MAY be used, however, Metadata hierarchies MUST ensure that independent PathMatch root objects are used to prevent ambiguous or conflicting Metadata definitions. " I don't think the term PathMatch root object is well defined. I think what = you want to say is that it is OK to use conflicting metadata types as long = as they actually never apply to the same content. Right? It may be simpler = to express it that way. *Appendix A: OLD: " Requirements related to pre-positioning of metadata are not met directly by this document. Triggering metadata pre-positioning is beyond the scope of the CDNI Metadata interface. However, the interface as described by this document supports pulling metadata on- demand for the purpose of pre-positioning. " NEW: " Requirements related to pre-positioning of metadata are met by this document on the assumption that other CDNI Interfaces are to be = used by the upstream CDN to trigger the pre-positioning of metadata by the = downstream CDN via the CDNI Metadata Interface.=20 " *Appendix A: I think it would be useful to discuss how requirement META-7 is met: " META-7 [HIGH] The CDNI Metadata Distribution interface shall allow the Upstream CDN to request addition and modification of CDNI Metadata into the Downstream CDN. " *Appendix A: OLD: " Requirement META-13 relating to feedback from the downstream CDN to the upstream CDN with respect to metadata " NEW: " Requirement META-13 relating to feedback from the downstream CDN to the upstream CDN with respect to rejected metadata " *Appendix A: OLD: " As an alternative, the downstream CDN may use the CDNI Logging interface to convey error conditions related to metadata. " NEW: " As an alternative, the CDNI Logging interface could be extended to convey erro= r conditions related to metadata. " *Appendix A: " Requirement META-18 relating to surrogate cache behavior parameters is supported via extensibility. However, the example parameters in META-18 are not described in this document. " I know that META-18 is listed as [LOW] but I actually think that supporting= the "control of whether the query string of HTTP URI is to be ignored by s= urrogate cache" is actually both useful and extremely simple to add. Would = you be willing to add a simple binary property indicating whether query str= ing is to be ignored or not? Interestingly, the Metadata was expected to include 3 types of info: info r= elated to acquisition, info related to authorizing, info related to how to = deliver: " Metadata properties describe how to acquire, authorize, and deliver content from a downstream CDN. " The Query String ignore property would be a good example of metadata relate= d to how to deliver. Editorials: =3D=3D=3D=3D=3D=3D=3D OLD: " are not intended impose " NEW: " are not intended to impose " OLD: " document.Table 3 " NEW: " document. Table 3 " section 6: IANA OLD: " This document requests the registration of the "application/cdni" MIME type. " NEW: " This document requests the registration of the "application/cdni" MIME Media Type under the IANA MIME Media Type registry (http://www.iana= .org/assignments/media-types/index.html). *section 5.5.2: OLD: " Metadata assigned to a given content asset " NEW: " Metadata assigned to a given content " (asset is not part of the CDNI terminology) Appendix A: OLD: " All metadata requirements are met either directly or indirectly by the CDNI Metadata Interface described in this document. The following paragraphs describe notable exceptions. " NEW: " All metadata requirements are met either directly or indirectly by the CDNI Metadata Interface described in this document, with the clarifi= cations or exceptions=20 described in the following paragraphs. " OLD: " " NEW: " " OLD: " " NEW: " " _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Oct 29 11:16:39 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 A2A9921F84FD for ; Mon, 29 Oct 2012 11:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 732sX2HFHRZz for ; Mon, 29 Oct 2012 11:16:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 22EF221F84EC for ; Mon, 29 Oct 2012 11:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10485; q=dns/txt; s=iport; t=1351534598; x=1352744198; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=oiGTx30Os9HjXZqNRwW1XzASai6/eHtH00o9lmQHJAo=; b=Q2EzKz0u+X2L8mTT9cWu7YVMJI8pbHcPWdhyAq5OVGTwuh/31XEvQnE/ HmDMFathJWSrzsGIWgztBsAKDOPc33VlY4RAE+N2G0ed+vSVwSzvS49pW 9c3EbZHwi4Yh/1Zn4mUc1SWed5qCGPU62hPEM7l+C76b78CygGHx8wjDN o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EANLHjlCtJV2Z/2dsb2JhbABEwnmBCIIgAQQSASc4BxIBKgsJQicEDg0ah2ScDZ9xi38KAYMYgk9hA5JCkgmBa4JvgVsBAR4BHQ X-IronPort-AV: E=Sophos;i="4.80,673,1344211200"; d="scan'208";a="133561404" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 29 Oct 2012 18:16:15 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q9TIGF3Q014894 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Oct 2012 18:16:15 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.001; Mon, 29 Oct 2012 13:16:12 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-framework@tools.ietf.org" Thread-Topic: 1st batch of comments on cdni-framework Thread-Index: AQHNtgF5CrhBxgB73ESFYHYOoDdW7w== Date: Mon, 29 Oct 2012 18:16:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19318.004 x-tm-as-result: No--43.905100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <27622F85041916488894ED1BF87DE35B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] 1st 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: Mon, 29 Oct 2012 18:16:39 -0000 Hi Larry, Bruce, Below is a 1st batch of comments from a review as an Individual (I got till= section 3.2). I'll send more when I continue the review. HTH 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 Abstract section and Introduction section: OLD: " CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, metadata exchange, and the acquisition of content by one CDN from another. " NEW: " 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. " (Rationale: since this discusses the "specification if several interfaces",= these should be aligned to the actual CDNI interfaces). OLD: " (and without attempting to take into account how the Downstream CDN may in turn redirect the user agent) " NEW: " (and without attempting to take into account how the Downstream CDN may in turn redirect the request) " (Rationale: the redirection decision can depend on other parameters/attribu= tes than user agent e.g. type of content). OLD: " In fact, this situation effectively exists today in the sense that a single CSP can currently connect to more than one CDN. " NEW: " In fact, this situation effectively exists today in the sense that a single CSP can currently delegate its content delivery to m= ore than one CDN. " Section 1.2: " o Control Interface: Operations to discover, initialize, and parameterize the other CDNI interfaces, as well as operations to pre-position, revalidate, and purge both metadata and content. The latter sub-set of operations is sometimes collectively called the "trigger interface." o Request Routing Interface: Operations to determine what CDN (and optionally what surrogate within a CDN) is to serve end-user's requests. May include a combination of: * Asynchronous operations to exchange routing information (e.g., the network footprint served by a given CDN) that enables CDN selection for subsequent user requests; and * Synchronous operations to select a delivery CDN (surrogate) for a given user request. o Metadata Interface: Operations to communicate metadata that governs the how content is delivered by interconnected CDNs. Examples of CDNI metadata include geo-blocking directives, availability windows, access control mechanisms, and purge directives. May include a combination of: * Asynchronous operations to exchange metadata that govern subsequent user requests for content; and * Synchronous operations that govern behavior for a given user request for content. o Logging Interface: Operations that allow interconnected CDNs to exchange relevant activity logs. May include a combination of: * Real-time exchanges, suitable for runtime traffic monitoring; and * Off-line exchanges, suitable for analytics and billing. " This is an alternative definition to the one included in the Problem Statem= ent. I would suggest that for each interface you first quote (with quotatio= n marks) the text of the corresponding definition from RFC6707 and then ind= icate (without quotation marks) the additional information you want to prov= ide. Note in particular that the current terminology for the Asynchronous and Sy= nchronous part of RRI is "CDNI Request Routing Redirection interface" and "= CDNI Footprint & Capabilities advertisement interface". section 1.2: OLD: " There is some ambiguity as to the line between the set of trigger- based operations in the Control interface and the Metadata interface. " NEW: " There is some potential overlap between the set of trigger- based operations in the Control interface and the Metadata interface. " OLD: " via the Metadata interface? " NEW: " via the Metadata interface. " OLD: " The distinction we draw has to do with what the caller knows the metadata being applied to content delivery by the callee.=20 " NEW: " The distinction we draw has to do with what the caller knows about the metadata being applied to content delivery by the callee.=20 " section 2.1: OLD: " in-protocol redirection mechanisms such as the HTTP 302 redirection response " NEW: " in-protocol redirection mechanisms such as the HTTP 302 or 307 redirection response " section 2.1.1: 2nd paragraph. I suggest mentioning a few other limitations of DNS redirect= ion such as inability to take into account the type of request content, the= URI path or attributes of the user agent. OLD: " (1) there is a limit to the number of delivery nodes a single DNS server can manage " NEW: " (1) there is a limit to the number of alternate IP addresses a single DNS s= erver can manage " (Rationale: in a context of multi-CDN, the IP address may not point to deli= very nodes" OLD: " to preserve the timeliness of the redirection. " NEW: " to preserve the freshness of the redirection. " (To me "timeliness" refers to the redirection arriving fast enough, which i= s not the issue here. But feel free to ignore if this is not correct) section 2.1.2: OLD: " HTTP redirection makes use of the "302" redirection response of the HTTP protocol.=20 " NEW: " HTTP redirection makes use of the redirection response of the HTTP protocol (e.g. "302", "307").=20 " OLD: " The advantages of 302 redirection " NEW: " The advantages of HTTP redirection " section 2.1.2, 1st paragraph: I suggest mentioning a few additional benefits of HTTP redirection i.e. vis= ibility on other attributes (e.g. URI path, content type, user-agent type,.= .) section 3: OLD: " and the latter being the best CDN to deliver content to the end-user. " NEW: " and the latter being the CDN selected by Operator A to deliver content to t= he end-user. " OLD: " The interconnection relationship may be symmetric between these two CDN ope= rators, but for simplicity we show the interaction in one direction only. " NEW: " The interconnection relationship may be symmetric between these two CDN ope= rators, but each direction can be considered as operating independently of = the other so=20 for simplicity we show the interaction in one direction only. " Figure2: I recommend that all figures try use the same convention for which side is = the uCDN and which is the dCDN. Since RFC6707 model has the uCDN on the lef= t and the dCDN on the rigt, I would recommend that all figures use that con= vention. It avoids having to swap mental picture from figure to figure. Figure2: OLD: " [Asynch RRI Push] " NEW: " [Asynch RRI/Footprint & Cap Push]" " (also, you need to introduce the RRI acronym before) Figure2: OLD: " [Sync RRI Pull] " NEW: " [Synch RRI/Footprint & Cap Pull]" " Figure 2: everywhere, replace "metadata" by "CDNI metadata" Figure 2: I would swap the order between 1 and 2, just cause , if it is to happen, fo= otprint & caps advertisement seems more "pre-requisitite" than content meta= data exchange (i.e. kind of even more asynchronous since it is not even rel= ated to any content, and may be even need to first decide which dCDN to pre= position metadata into). Figure2: in the description for each step below the figure, please make sure that fo= r each step you indicate which CDNI interface is exercised. Figure2: I suggest replacing the phrase "metadata push" everywhere by something like= "CDNI metadata pre-positioning". just cause we are not really "pushing" it= , but triggering a pull.=20 section 3.1: " We use the term "CDN-domain" to refer to the host name (a FQDN) at the begi= nning of each URL. " The text uses "CDN Domain" or "CDN-Domain" or "CDN domain". I suggest you a= lways use the same single form. Since the term is defined at the beginning of the doc, you can probably avo= id to redefine it in section 3.1 (currently with less precise definition). section 3.2: " (It is likely that the agreement would be made in both directions, but we focus on just one here for clarity.) " this is redundant with earlier text ("The interconnection relationship may = be symmetric between these two CDN operators, but each direction can be con= sidered as operating independently of the other so for simplicity we show t= he interaction in one direction only.") and can be safely removed. section 3.2: " We refer to this domain as a "distinguished" CDN domain to convey the fact that its use is limited to the interconnection mechanism; such a domain is never embedded in URLs that end-users request. " This wording is confusing to me because after the uCDN redirect, the CDN Do= main is indeed used by the end-user in its URI : "HTTP peer-a.op-b.net/cdn.= csp.com ". I think the point is that a "distinguish CDN domain" is never used as the C= DN Domain for a CSP. No? While talking about the distinguished CDN domain fro redirection I would me= ntion that the granularity of such a CDN domain is flexible (i.e. there cou= ld be one for the pair of , one per triple uCDN CSP for the pair= of or anywhere in between (i.e. per set of uCDN CSPs, per type= of content across uCDN CSPs). section 3,2: " The operators must also agree on some distinguished CDN-domain that will be used for inter-CDN acquisition of CSP's content from uCDN by dCDN. In this example, we'll use op-b-acq.op-a.net. " I would replace "must also agree" by "can also agree" because it does not a= bsolutely have to be that way: uCDN may be able to distinguish an acquisiti= on request from a end-user request even if they use the same domain name. In fact you should use a consistent terminology everywhere in this section = insisting on the fact that this is just an example (e.g.. "We assume for th= is example that" ) and avoid "must". OLD: " via a defined interface. " NEW: " via a defined CDNI interface. " From flefauch@cisco.com Tue Oct 30 08:13: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 CE6D921F847F for ; Tue, 30 Oct 2012 08:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SwCPsY0rF31 for ; Tue, 30 Oct 2012 08:13:03 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3F35421F847C for ; Tue, 30 Oct 2012 08:13:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=106; q=dns/txt; s=iport; t=1351609983; x=1352819583; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=9CTP7UDlfm5/9GPiO1DD8i2NDfrx2eCWSqBpOj+IJ4A=; b=KfcCflkx5EuV2mdUVDv/eV6PpTBtiDZi9apxWHzSKAeNKvUVHS1kFvzO nzHFBWFip9WzbRqI8Pn3RAcbYxHPfC1mupt29SfkhbMWiGVJjF8zNaGUD 6xJ7Joz4iA5V4b4IpV+DxvcKVQ9+2UzOOxwUU8MwmqWvzOrwEDWgc2i7j Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAXuj1CtJV2Y/2dsb2JhbABEw0iBCIIgAQQSASdRASoUQicEGxqHZJthgSyPZ5A8kXNhA6RMgWuCb4IZ X-IronPort-AV: E=Sophos;i="4.80,679,1344211200"; d="scan'208";a="136922486" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 30 Oct 2012 15:13:00 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q9UFD0aI008508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Oct 2012 15:13:00 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Tue, 30 Oct 2012 10:12:59 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Slides for CDNI Meeting in Atlanta Thread-Index: AQHNtrEMMidEipE4EkiFobPOOWyoQg== Date: Tue, 30 Oct 2012 15:12:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19320.004 x-tm-as-result: No--22.981100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Slides for CDNI Meeting in Atlanta 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, 30 Oct 2012 15:13:03 -0000 To presenters in CDNI at IETF-85, Please send us your slides by 4 November or earlier. Francois & Rich From Jan.Seedorf@neclab.eu Tue Oct 30 09:23:56 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 5266C21F86CE; Tue, 30 Oct 2012 09:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 yeCO+EEoDC3Y; Tue, 30 Oct 2012 09:23:54 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id A687921F86C3; Tue, 30 Oct 2012 09:23:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 0BA4110238D; Tue, 30 Oct 2012 17:23:49 +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 JdN1MFuit5RB; Tue, 30 Oct 2012 17:23:48 +0100 (CET) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id E278910238C; Tue, 30 Oct 2012 17:23:38 +0100 (CET) Received: from DAPHNIS.office.hd ([169.254.2.239]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 30 Oct 2012 17:23:38 +0100 From: Jan Seedorf To: Jan Seedorf , "cdni@ietf.org" Thread-Topic: Date/Time for CDNI Footprint/Capabilities Side Meeting at IETF-85 Thread-Index: Ac22upJng83LN3xBRDigLsybSpMPfQ== Date: Tue, 30 Oct 2012 16:23:20 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE553835BF@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-footprint@ietf.org" Subject: [CDNi] Date/Time for CDNI Footprint/Capabilities Side Meeting at IETF-85 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, 30 Oct 2012 16:23:56 -0000 Dear all, Based on the doodle (see below), I suggest having the CDNI Footprint/Capabi= lities Side Meeting at IETF-85 as follows: ** Tuesday, Nov 6th, 15:00-17:00 ** If there are objections, please let us know on this list :) - Jan > -----Original Message----- > From: cdni-footprint-bounces@ietf.org [mailto:cdni-footprint- > bounces@ietf.org] On Behalf Of Jan Seedorf > Sent: Friday, October 26, 2012 11:06 AM > To: cdni@ietf.org > Cc: cdni-footprint@ietf.org > Subject: [cdni-footprint] CDNI Footprint/Capabilities Side Meeting at IET= F-85 >=20 > Hi all, >=20 > As discussed in the phone call yesterday, let's aim for one 2h side meeti= ng at > IETF-85, either on Monday or Tuesday (the CDNI WG sessions are on WED > and THU, so it's a good idea to have discussions before that). I have set= up a > doodle, please fill it in if you are interested in joining: >=20 > http://www.doodle.com/xcg78pfa5y932c9u >=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 flefauch@cisco.com Wed Oct 31 11:05:05 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 3C37621F8861 for ; Wed, 31 Oct 2012 11:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=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 AB-bl0Owj6i9 for ; Wed, 31 Oct 2012 11:05:03 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 452E821F8858 for ; Wed, 31 Oct 2012 11:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16144; q=dns/txt; s=iport; t=1351706703; x=1352916303; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D8asvA2hcQm4DoS/WQLUi/WpB6gGMPC64UC/+aDdORA=; b=OtXlb88rgohzR0egoe5jleXQoIBWJLHBzPLj/d5/LTSU0iwRaHsaT9YD HkhWsU0l2A3zAIY4PcnkTHm2OZZdGISjIA+uqACozHYdeP3BVDjXyAi31 x/8F+sIG9e4ao18HLG1B+k4s5f1LB89GsqNACtbBdBuMRmHiHtZDxMeGW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIRnkVCtJV2b/2dsb2JhbABEw1iBCIIeAQEBAwEBAQEPASctBwsFBwQCARkEAQELDwIDCQcnCxQJCAIEDgUIAREIh14GC5tqoB2LeIMoAoIwYQOSRIRMjT2Ba4JvgT4fHgYY X-IronPort-AV: E=Sophos;i="4.80,687,1344211200"; d="scan'208";a="137438711" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 31 Oct 2012 18:05:02 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q9VI522e009224 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Oct 2012 18:05:02 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.91]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.001; Wed, 31 Oct 2012 13:05:01 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-metadata@tools.ietf.org" Thread-Topic: And one more comment from review of draft-ietf-cdni-metadata-00.txt Thread-Index: AQHNt5I/3JVIIrCTM0i8+CWIoQwZ5Q== Date: Wed, 31 Oct 2012 18:05:01 +0000 Message-ID: References: <166EBB70C264A9479E459B01B1BA6C920F404118@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C920F404118@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.195] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19324.001 x-tm-as-result: No--36.060900-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: <36C538A1A410C24389C22484BD6E856C@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] And one more comment from review of draft-ietf-cdni-metadata-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, 31 Oct 2012 18:05:05 -0000 As I just reviewed cdni-framework, I noticed the text in there (in section = "4.6. Metadata Interface") reflecting the earlier WG agreement to allow th= e uCDN to enforce access control checks itself. And in particular the follo= wing text: " As a consequence, the Metadata interface must provide a means for the uCDN to express its desire to retain enforcement for itself. For example, this might be done by including a "check with me" flag in the metadata associated with certain content. " I believe this needs to be added to the set of metadata properties currentl= y specified. When you specify its detailed semantics. I'd suggest that you indicate that= when the flag is set, the dCDN should perform the "check-with-uCDN" after = validation of access controls that are present inside metadata. In other wo= rds, I'd picture the "Check-with-uCDN" as something that can be used "in ad= dition" to access control rules that may be distributed to dCDN and not "in= stead of". This way: * if the uCDN wants to have full control, it does not advertise any access= control in CDNI metadata * if the uCDN wants to delegate some simple validations (e.g. time-window = specific to a content range) and enforce on top of that some finer-grain ac= cess control (e.g. per user), it can do so by advertising simple access con= trol in CDNI Metadata + "Check-with-me" flag. This allows filtering of inva= lid requests (and possibly DOS attacks) in dCDN and scales better. On 26 Oct 2012, at 20:45, Matt Caulfield (mcaulfie) wrote: > Thank you for the detailed comments, Francois.=20 >=20 > Hoping we can address both your first batch and second batch of questions= relatively soon. >=20 > Matt >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of F= rancois Le Faucheur (flefauch) > Sent: Friday, October 26, 2012 12:59 PM > To: draft-ietf-cdni-metadata@tools.ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] Second batch of comments from review of draft-ietf-cdni-m= etadata-00.txt >=20 > Hello, >=20 > Below are my second batch of comments (as an Individual). > I hope this is useful. >=20 > Francois >=20 >=20 >=20 > General comments: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > * When used, MUST/SHOULD/MAY are used appropriately. But I recommend you = do a pass to verify that there is enough MUST to capture everything that is= mandatory for an implementation. For example, I am not sure there is an ex= plicit statement stating that all the objects/properties listed in section = 3 and 4 MUST be supported. >=20 > * You provide examples of both JSON and XML encoding, which is very nice.= I suggest you start driving a discussion on the list as to which should be= picked. Perhaps you could try list key pros&cons of each on the list? > When you have decided , you could then replace "example encodings" by a s= pecification of the encoding. >=20 >=20 > Specific Comments/Suggestions > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > * Section 4.3.1 Link > " > A link object may be used in place of any of the objects described above. > " > I think this should be replaced by: > " > A link object may be used in place of any of the objects or properties de= scribed above. > "=20 > because for example in the Source object (Property: auth + Property: endp= oints + Property: protocol) each property (e.g. Protocol) can be specified = individually using a link. Is this right? >=20 >=20 >=20 > * section 4.3.2 Protocol: > " > This type only appears in Links.=20 > " > This is confusing because the Protocol type already appears in multiple o= bjects , for example in " > 4.2.1.1. Source > Property: auth > Description: Authentication method to use when requesting > content from this source. > Type: Auth > Mandatory-to-Specify: No. Default is no authentication is > required. > Property: endpoints > Description: Origins from which the dCDN can acquire content. > Type: List of EndPoint > Mandatory-to-Specify: Yes. > Property: protocol > Description: Protocol to use for content acquisition. > Type: Protocol > Mandatory-to-Specify: Yes. > " > Assuming I understand what you want to do correctly, perhaps you could ca= ll the type define din 4.3.2 with a different name e.g. "ProtocolID" and th= is special type would only appear inside a Link. Would that work? Or am I e= ntirely missing what you want to do here? >=20 >=20 > * section 4.3.2 Protocol: > " > The following examples are illustrative: > o http://url.cdni.ietf.example/protocol/delivery/http/rfcABCD > o http://url.cdni.ietf.example/protocol/delivery/rtmp/rfcEFGH > o http://url.vendorY.ietf.example/protocol/delivery/rtmp/releaseP.Q > " > I think it would be useful to use a URI if that saved you from managing a= n IANA register (e.g. because there exist a URI that unambiguously points t= o the spec you want to reference e.g. http://datatracker.ietf.org/doc/rfc26= 16/) but that will probably not work with /rtmp/releaseP.Q. So what is the = benefit of using a URI here over defining an IANA register for these protoc= ol IDs? >=20 >=20 > * section 5: > OLD: > " > The interface can be used by a Downstream CDN to retrieve CDNI > Metadata objects either dynamically as required by the Downstream CDN > to process received requests (for example in response to receiving a > CDNI Request Routing request from an Upstream CDN or in response to > receiving a request for content from a User Agent) or in advance of > being required. > " > NEW: > " > The interface can be used by a Downstream CDN to retrieve CDNI > Metadata objects either dynamically as required by the Downstream CDN > to process received requests (for example in response to receiving a > CDNI Request Routing request from an Upstream CDN or in response to > receiving a request for content from a User Agent) or in advance of > being required (for example in case of Pre-positioned CDNI Metadata acq= uisition). > " >=20 >=20 > * section 5.2: > OLD: > " > the HostIndex which > provides the CDNI Metadata client with a list of Hostnames that the > upstream CDN may delegate to the downstream CDN. > " > NEW: > " > the HostIndex which > provides the CDNI Metadata client with a list of Hostnames for which th= e > upstream CDN may delegate content delivery to the downstream CDN. > " >=20 >=20 > * section 5.2: > " > The CDNI > metadata client then makes a GET request for the URI specified in the > href key of that Host's entry in the HostIndex. > " > I have a couple of issue with that sentence: > 1) the HostMetadata are found in the HostMatch entry for which there was= a match on the Host, so the text news tweaking. > 2) while the HostMetadata may contain a href to the Metadata, I think it= could also actually contain the Metadata itself. If correct then, you need= to tweak text to discuss both options. If incorrect then, you may need to = tweak the text in section 4 that describes HostMatch. > The same comment applies also to the following paragraph re PathMetadata. >=20 >=20 > *section 5.2: > OLD: > " > When application level redirection (e.g. HTTP 302 redirects) is > being used between CDNs, it is expected that the downstream CDN will > be able to determine the upstream CDN that redirected a particular > request from information contained in the received request (e.g. via > the URI in case of HTTP redirection across CDNs). > " > NEW: > " > When application level redirection (e.g. HTTP 302 redirects) is > being used between CDNs, it is expected that the downstream CDN will > be able to determine the upstream CDN that redirected a particular > request from information contained in the received request (e.g. via > the URI). > " >=20 > *section 5.2: > OLD: > " > In the case of DNS redirection there is not sufficient information > carried in the DNS request from User Agents to determine the upstream > CDN that redirected a particular request and therefore downstream > CDNs may have to apply local policy when deciding which upstream > CDN's metadata to apply. > " > NEW: > " > In the case of DNS redirection there is not always sufficient information > carried in the DNS request from User Agents to determine the upstream > CDN that redirected a particular request (e.g. when content from a give= n host is redirected to a given downstream CDN by more than one upstream CD= N) and therefore downstream > CDNs may have to apply local policy when deciding which upstream > CDN metadata to apply. > " >=20 >=20 > *section5.3 Bootstrapping: > OLD: > " > If the URI for the HostIndex object is not manually configured in the > downstream CDN then the HostIndex URI could be discovered via the > CDNI Control interface. An upstream CDN would provide the URI of the > HostIndex object to the downstream CDN via the CDNI Control > Interface. > " > NEW: > " > Mechanism allowing the downstream CDN to discover the URI of the HostInde= x are outside the scope of this document. > " > (Depending on the base protocol leveraged to support CDNI discovery in th= e future, it may or may not be obvious that this would be considered part o= f the Control Interface, so I recommend we don't try second-guess future wo= rk and leave it open) >=20 >=20 > OLD: > " > Table 3: MIME Media Types for CDNI Metadata resources > " > NEW: > " > Table 3: Example MIME Media Types for CDNI Metadata resources > " > (this is to make it clear that the table only contains a subset) >=20 >=20 > section 5.4.2: > " > Dictionary keys in JSON are case sensitive and therefore any > dictionary key defined by this document (for example the names of > CDNI Metadata object properties) MUST always be represented in > lowercase. > " > Are you saying that there was no choice and they had to be represented in= lower case (as suggested by "therefore") or are you saying that we need to= be case sensitive so to make it simpler you have decided to make them all = lower case and therefore they MUST be encoded that way? If it is the former= , please explain why. If it is the latter, then adjust text. >=20 >=20 > * section 5.5: > " > it is suggested that proprietary and/or custom property Metadata be > identified by the "ext." > " > Why not make this a stronger statement i.e. that "ext" MUST be used for a= ny proprietary/custom extensions? > Also, could we specify a rule to define the how to signal "the organizati= on defining the property Metadata" e.g. FQDN in reverse order like ".com.co= mpanyA"? >=20 >=20 >=20 > * section 5.5.1: > OLD: > " > Note: Ideally, uCDNs would not delegate content requests to a dCDN > which does not support the Metadata=20 > " > NEW: > " > Note: Ideally, uCDNs would never delegate content requests to a dCDN > which does not support the "mandatory-to-enforce" Metadata=20 > " >=20 >=20 > * section 5.5.1: > OLD: > " > The dCDN > MUST evaluate all Metadata > " > NEW: > " > This is why the dCDN > MUST evaluate all Metadata > " >=20 >=20 > * section 5.5.2: > " > Note: Because Metadata is inherently ordered in GenericMetadata > lists, as well as in the PathMetadata hierarchy and PathMatch lists, > multiple conflicting Metadata types MAY be used, however, Metadata > hierarchies MUST ensure that independent PathMatch root objects are > used to prevent ambiguous or conflicting Metadata definitions. > " > I don't think the term PathMatch root object is well defined. I think wha= t you want to say is that it is OK to use conflicting metadata types as lon= g as they actually never apply to the same content. Right? It may be simple= r to express it that way. >=20 >=20 > *Appendix A: > OLD: > " > Requirements related to pre-positioning of metadata are not met > directly by this document. Triggering metadata pre-positioning is > beyond the scope of the CDNI Metadata interface. However, the > interface as described by this document supports pulling metadata on- > demand for the purpose of pre-positioning. > " > NEW: > " > Requirements related to pre-positioning of metadata are met > by this document on the assumption that other CDNI Interfaces are to be= used by the upstream CDN to trigger the pre-positioning of metadata by the= downstream CDN via the CDNI Metadata Interface.=20 > " >=20 >=20 > *Appendix A: > I think it would be useful to discuss how requirement META-7 is met: > " > META-7 [HIGH] The CDNI Metadata Distribution interface shall allow > the Upstream CDN to request addition and modification of > CDNI Metadata into the Downstream CDN. > " >=20 >=20 > *Appendix A: > OLD: > " > Requirement META-13 relating to feedback from the downstream CDN to > the upstream CDN with respect to metadata > " > NEW: > " > Requirement META-13 relating to feedback from the downstream CDN to > the upstream CDN with respect to rejected metadata > " >=20 >=20 > *Appendix A: > OLD: > " > As an > alternative, the downstream CDN may use the CDNI Logging interface to > convey error conditions related to metadata. > " > NEW: > " > As an > alternative, the CDNI Logging interface could be extended to convey err= or conditions related to metadata. > " >=20 >=20 > *Appendix A: > " > Requirement META-18 relating to surrogate cache behavior parameters > is supported via extensibility. However, the example parameters in > META-18 are not described in this document. > " > I know that META-18 is listed as [LOW] but I actually think that supporti= ng the "control of whether the query string of HTTP URI is to be ignored by= surrogate cache" is actually both useful and extremely simple to add. Woul= d you be willing to add a simple binary property indicating whether query s= tring is to be ignored or not? > Interestingly, the Metadata was expected to include 3 types of info: info= related to acquisition, info related to authorizing, info related to how t= o deliver: > " > Metadata properties > describe how to acquire, authorize, and deliver content from a > downstream CDN. > " > The Query String ignore property would be a good example of metadata rela= ted to how to deliver. >=20 >=20 >=20 > Editorials: > =3D=3D=3D=3D=3D=3D=3D >=20 > OLD: > " > are not intended impose > " > NEW: > " > are not intended to impose > " >=20 >=20 >=20 > OLD: > " > document.Table 3 > " > NEW: > " > document. Table 3 > " >=20 >=20 > section 6: IANA > OLD: > " > This document requests the registration of the "application/cdni" > MIME type. > " > NEW: > " > This document requests the registration of the "application/cdni" > MIME Media Type under the IANA MIME Media Type registry (http://www.ian= a.org/assignments/media-types/index.html). >=20 >=20 >=20 > *section 5.5.2: > OLD: > " > Metadata assigned to a given content asset > " > NEW: > " > Metadata assigned to a given content > " > (asset is not part of the CDNI terminology) >=20 >=20 > Appendix A: > OLD: > " > All metadata requirements are met either directly or indirectly by > the CDNI Metadata Interface described in this document. The > following paragraphs describe notable exceptions. > " > NEW: > " > All metadata requirements are met either directly or indirectly by > the CDNI Metadata Interface described in this document, with the clarif= ications or exceptions=20 > described in the following paragraphs. > " >=20 > OLD: > " > " > NEW: > " > " >=20 >=20 > OLD: > " > " > NEW: > " > " > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni