From Martin.Stiemerling@neclab.eu Tue Apr 2 12:18:59 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61D221F8CDF for ; Tue, 2 Apr 2013 12:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.528 X-Spam-Level: X-Spam-Status: No, score=-103.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt75TAdpLPYT for ; Tue, 2 Apr 2013 12:18:59 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3550021F8CC9 for ; Tue, 2 Apr 2013 12:18:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 9CAA8103A39 for ; Tue, 2 Apr 2013 21:18: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 Zy3NCpqI1aRO for ; Tue, 2 Apr 2013 21:18:58 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 7EDA0103A35 for ; Tue, 2 Apr 2013 21:18:53 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 2 Apr 2013 21:18:53 +0200 Message-ID: <515B2F1C.7020708@neclab.eu> Date: Tue, 2 Apr 2013 21:18:52 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: [CDNi] Announcing a new CDNI co-chair 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 Apr 2013 19:18:59 -0000 Dear all, Rich Woundy stepped down as CDNI co-chair at the end of the IETF-86 meeting. A big thank you to Rich for being co-chair since the establishment of the CDNI working group! Daryl Malas (D.Malas@cablelabs.com) is the new co-chair. Thanks to Daryl and let's welcome him! Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From Martin.Stiemerling@neclab.eu Tue Apr 2 12:22:03 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8BE21F8DD4 for ; Tue, 2 Apr 2013 12:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.538 X-Spam-Level: X-Spam-Status: No, score=-103.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lb1U8-MrDjg2 for ; Tue, 2 Apr 2013 12:22:02 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0A28A21F8DD1 for ; Tue, 2 Apr 2013 12:22:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C67CA103A3B for ; Tue, 2 Apr 2013 21:21: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 Fel+4mGi7fnA for ; Tue, 2 Apr 2013 21:21:59 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id A0D7E103A35 for ; Tue, 2 Apr 2013 21:21:54 +0200 (CEST) Received: from [10.7.0.105] (10.7.0.105) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 2 Apr 2013 21:21:54 +0200 Message-ID: <515B2FD1.5000407@neclab.eu> Date: Tue, 2 Apr 2013 21:21:53 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: References: <515B2F1C.7020708@neclab.eu> In-Reply-To: <515B2F1C.7020708@neclab.eu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.7.0.105] Subject: Re: [CDNi] Announcing a new CDNI co-chair 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 Apr 2013 19:22:03 -0000 adding a missing part of my message: Thank you to everybody who volunteered! Martin On 04/02/2013 09:18 PM, Martin Stiemerling wrote: > Dear all, > > Rich Woundy stepped down as CDNI co-chair at the end of the IETF-86 > meeting. > > A big thank you to Rich for being co-chair since the establishment of > the CDNI working group! > > Daryl Malas (D.Malas@cablelabs.com) is the new co-chair. > > Thanks to Daryl and let's welcome him! > > Martin > -- martin.stiemerling@neclab.eu NEC Laboratories Europe NEC Europe Limited Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB Registered in England 2832014 From RMurray@velocix.com Wed Apr 3 14:25:33 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0137921F8F53 for ; Wed, 3 Apr 2013 14:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89s4mANsDoOr for ; Wed, 3 Apr 2013 14:25:32 -0700 (PDT) Received: from owa.velocix.com (mail-out1.velocix.com [81.134.152.10]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7AE21F8F35 for ; Wed, 3 Apr 2013 14:25:29 -0700 (PDT) Received: from EXB01-MLT.corp.velocix.com ([169.254.2.90]) by EXC00CAM.corp.velocix.com ([172.18.4.40]) with mapi id 14.02.0247.003; Wed, 3 Apr 2013 22:25:22 +0100 From: Rob Murray To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-murray-cdni-triggers-03.txt Thread-Index: AQHOMLDgTi/5GWUrf0SqukptLaxglZjFEtWA Date: Wed, 3 Apr 2013 21:25:22 +0000 Message-ID: <49C77373835C5A479BC2A84B2A1D66BD8E3D8DB7@EXB01-MLT.corp.velocix.com> In-Reply-To: <20130403211850.1122.57330.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [2.122.69.111] Content-Type: text/plain; charset="us-ascii" Content-ID: <3EBDBF23CCE1854884C35548881922CB@velocix.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-murray-cdni-triggers-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: Wed, 03 Apr 2013 21:25:33 -0000 Hi all, There's a new version of the triggers draft, just the following mods: - name changed to "Control Interface / Triggers" (CI/T) - CCID can be used to refer to content for invalidate/purge - updated refs, including re-worded and new req's copied from the req's draft Cheers, Rob. -----Original Message----- From: "internet-drafts@ietf.org" Date: Wednesday, 3 April 2013 21:18 To: Rob Murray Cc: Ben Niven-Jenkins Subject: New Version Notification for draft-murray-cdni-triggers-03.txt > >A new version of I-D, draft-murray-cdni-triggers-03.txt >has been successfully submitted by Rob Murray and posted to the >IETF repository. > >Filename: draft-murray-cdni-triggers >Revision: 03 >Title: CDNI Control Interface / Triggers >Creation date: 2013-04-03 >Group: Individual Submission >Number of pages: 36 >URL: =20 >http://www.ietf.org/internet-drafts/draft-murray-cdni-triggers-03.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-murray-cdni-triggers >Htmlized: http://tools.ietf.org/html/draft-murray-cdni-triggers-03 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-murray-cdni-triggers-03 > >Abstract: > This document describes the part of the CDN Interconnect Control > Interface that allows a CDN to trigger activity in an interconnected > CDN that is configured to deliver content on its behalf. The > upstream CDN can use this mechanism to request that the downstream > CDN pre-positions metadata or content, or that it re-validate or > purge metadata or content. The upstream CDN can monitor the status > of activity that it has triggered in the downstream CDN. > > > =20 > =20 > > >The IETF Secretariat > From flefauch@cisco.com Mon Apr 8 05:07:27 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7412C21F93B0 for ; Mon, 8 Apr 2013 05:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8mq0HLO8OaK for ; Mon, 8 Apr 2013 05:07:26 -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 B4FC821F93C4 for ; Mon, 8 Apr 2013 05:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=713; q=dns/txt; s=iport; t=1365422846; x=1366632446; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KWzVSp8Am959YHZH1GHqZ1s6Mjx1SlI48ZJUauIKk6E=; b=cJ5BMCB2UYpnB1obovMwVPVKpJYtXJK10acQLXOuCJXlpkcP6a+VnpCe GF0RPApUcdRb8H9SRvIFx43nIob1u9/jQkr32NXuF8fddnUgmyi9FAxPU 65KLjEvGk/oQVSQX0Az79PEfcraSchM3TI3sKQegIKWUCrq2C10jlsfbe M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAACyYlGtJV2a/2dsb2JhbABRgwY2gmO+RYEIFnSCHwEBAQMBAQEBNzQQCwIBCCIUECcLJQIEARIIiAYGDLwwBI5wAjiCYGEDqAKDC4Io X-IronPort-AV: E=Sophos;i="4.87,431,1363132800"; d="scan'208";a="196226984" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 08 Apr 2013 12:07:26 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r38C7PQl015763 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 12:07:26 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.181]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 07:07:25 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" , "draft-murray-cdni-triggers@tools.ietf.org" Thread-Topic: [CDNi] Agreement to adopt cdni-triggers as WG document Thread-Index: AQHONFGh7sEeCrhZgEeLmNVlnUJd6g== Date: Mon, 8 Apr 2013 12:07:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B4C519CBB69054B9065E16EC3E42987@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Agreement to adopt cdni-triggers as WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 12:07:27 -0000 All, No concerns/issues have been expressed, so draft-murray-cdni-triggers is no= w considered as adopted as a WG document. Authors, Please re-issue the latest version as draft-ietf-cdni-control-triggers-00 a= t your convenience. Francois and Daryl On 22 Mar 2013, at 13:35, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > During IETF-86, the WG tentatively agreed to adopt draft-murray-cdni-trig= gers-02 as a Working Group document. If you have concerns/issues with that,= let us know by 5 April 2013.=20 >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Apr 8 05:16:16 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29B6A21F9409 for ; Mon, 8 Apr 2013 05:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0lzdRKDFfWMm for ; Mon, 8 Apr 2013 05:16:09 -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 BBA7421F93A5 for ; Mon, 8 Apr 2013 05:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=738; q=dns/txt; s=iport; t=1365423368; x=1366632968; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=L0uAC7nNhgopILjGiqWAc4iQ7vcXAcdJXE8xcExl934=; b=OrXp2rBwWBkszJJk9USZYVJewPx70FAOUX0lmVta3WG7U4y7yc2x9oO8 nqrKivRjcFoN4t1AR3YpBzXbXkHI9GawlbLfgJqmJUVuyEAgsz6RFsnyj D4vi4CQlYVMGgxuiGtc/OLgQQjJJnrJ0bha4RL+HokK5Wp0nE3/KrtRYg g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAMCzYlGtJV2Y/2dsb2JhbABRgwY2gmO+RYEIFnSCHwEBAQMBAQEBNzQQCwIBCCIUECcLJQIEARIIiAYGDLwvBI5wAjiCYGEDqAKDC4Io X-IronPort-AV: E=Sophos;i="4.87,431,1363132800"; d="scan'208";a="196116314" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 08 Apr 2013 12:16:08 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r38CG8V1001273 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 12:16:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.181]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 07:16:08 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" , "draft-he-cdni-routing-request-redirection@tools.ietf.org" Thread-Topic: [CDNi] Agreement to adopt cdni-routing-request-redirection as WG document Thread-Index: AQHONFLZPjJ2cpixvU6yIJESSJNtFw== Date: Mon, 8 Apr 2013 12:16:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <71433AED44ECE048B305D249955AC28B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Agreement to adopt cdni-routing-request-redirection as WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 12:16:16 -0000 All, No concerns/issues have been expressed, so draft-he-cdni-routing-request-re= direction is now considered as adopted as a WG document. Authors, Please re-issue the latest version as draft-ietf-cdni-redirection-00 at you= r convenience. Francois and Daryl On 22 Mar 2013, at 13:37, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > During IETF-86, the WG tentatively agreed to adopt draft-he-cdni-routing-= request-redirection-04 as a Working Group document. If you have concerns/is= sues with that, let us know by 5 April 2013.=20 >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Apr 8 05:20:38 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9B021F93D8 for ; Mon, 8 Apr 2013 05:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMeWDmBziwkK for ; Mon, 8 Apr 2013 05:20:37 -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 AA51521F93D6 for ; Mon, 8 Apr 2013 05:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=746; q=dns/txt; s=iport; t=1365423637; x=1366633237; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=N+A9sJ9ON99QrdD/SZNMDz2gIqJkGvQuZDNHMXsO/hg=; b=Nf31Up/AEIoTC6DypQ01LVdifYf+CwGAmdomNJPx4+0RuAdny0ZK00RI 2H7dabtQNA9loKeazwzjOYe8A7JtURXWZB6uoM4KVvUP68DT3d65Aimig QyQC86TZY6R8x2DbRTu2u2gBNN200K2axKtVWOBOYIRhZhEvmw9V133Ed c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAB61YlGtJXG//2dsb2JhbABRgwY2gmO+RYEIFnSCHwEBAQMBAQEBNzQQCwIBCCIUECcLJQIEARIIiAYGDLw0BI5wAjiCYGEDqAKDC4Io X-IronPort-AV: E=Sophos;i="4.87,431,1363132800"; d="scan'208";a="196171985" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-3.cisco.com with ESMTP; 08 Apr 2013 12:20:37 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r38CKbhH016707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 12:20:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.181]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 07:20:36 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" , "draft-spp-cdni-rr-foot-cap-semantics@tools.ietf.org" Thread-Topic: [CDNi] Agreement to adopt cdni-rr-foot-cap-semantics-04 as WG document Thread-Index: AQHONFN4QtcGDZagrk26Vtl4KDvXJg== Date: Mon, 8 Apr 2013 12:20:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <648834204022D54FA33188AC9EB7D28B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Agreement to adopt cdni-rr-foot-cap-semantics-04 as WG document X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 12:20:38 -0000 All, No concerns/issues have been expressed, so draft-spp-cdni-rr-foot-cap-seman= tics is now considered as adopted as a WG document. Authors, Please issue the next version as draft-ietf-cdni-footprint-capabilities-sem= antics-00 at your convenience. Francois and Daryl On 22 Mar 2013, at 13:38, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > During IETF-86, the WG tentatively agreed to adopt draft-spp-cdni-rr-foot= -cap-semantics-04 as a Working Group document. If you have concerns/issues = with that, let us know by 5 April 2013.=20 >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Apr 8 05:22:39 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3E121F93D8 for ; Mon, 8 Apr 2013 05:22: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg3IkBvXn4Vk for ; Mon, 8 Apr 2013 05:22:38 -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 134BC21F93D6 for ; Mon, 8 Apr 2013 05:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=613; q=dns/txt; s=iport; t=1365423758; x=1366633358; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=v5JZM5kmUVvMEQ8FMw4GQUxJXu/EUU3mpIz4F2ra9rg=; b=aGPSxS6dLt0gHF5t4d+Ys6Ij2Oxnfw+VcrxonrC0N85m+t/FonhoJ5aB lnmbVNAZTbdpqrLGAcCJXT61gBTmkFgACiaa8EQbj52OI8DnlFa2hCZFK NW+pBmFT9TmlRBVnfwokSoBGkBaSGyZXoUjdhlRqdTGe+il/AduskFBLT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAB61YlGtJV2Z/2dsb2JhbABRgwY2gmO+RYEIFnSCHwEBAQMBAQEBNzQQCwIBCCIUECcLJQIEEwiIBgYMvDQEjnACOIJgYQOoAoMLgig X-IronPort-AV: E=Sophos;i="4.87,431,1363132800"; d="scan'208";a="196144841" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 08 Apr 2013 12:22:37 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r38CMbUN007488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Apr 2013 12:22:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.181]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 07:22:37 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Agreement to move cdni-framework to WG Last Call Thread-Index: AQHONFPAVxiBRWOlgk6pFuACcYtvvQ== Date: Mon, 8 Apr 2013 12:22:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <125AD80B2D91004CA1FBA9A116E2D594@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Agreement to move cdni-framework to WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 12:22:39 -0000 All, No concerns/issues have been expressed, so we will issue a WG Last Call as = soon as the next rev of cdni-framework is posted. Francois and Daryl On 22 Mar 2013, at 13:31, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > During IETF-86, the WG tentatively agreed to go to WG Last Call once the = next rev of cdni-framework is posted. If you have concerns/issues with that= , let us know by 5 April 2013.=20 >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Mon Apr 8 05:23:06 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5A621F93E8 for ; Mon, 8 Apr 2013 05:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc+WARDdVrx4 for ; Mon, 8 Apr 2013 05:23:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 2336E21F93D8 for ; Mon, 8 Apr 2013 05:23:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=619; q=dns/txt; s=iport; t=1365423786; x=1366633386; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dKLxddUwzrwfa7dXWY9MuwOlLdqS4tmkpMqIMpxpPzY=; b=PjczQ+LxFGJ4cx4wV3b3PotbiZI7ced2IJ8MxmlCK+RMOSHYA3QRJ9pI IayIdBIhx2MrgENUPWZz91NSQg9Gp7r9ilufkIC95Dm2Ouei1cMvgZSWK Gq4lx00dA9quFexFi1nEv4Ynlp0wkmK5kNQRTJcLEcCbzDQc5SsLZ+bBK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFAJK1YlGtJV2a/2dsb2JhbABRgwY2gmO+RYEIFnSCHwEBAQMBAQEBNzQQCwIBCCIUECcLJQIEEwiIBgYMvDAEjnACOIJgYQOoAoMLgig X-IronPort-AV: E=Sophos;i="4.87,431,1363132800"; d="scan'208";a="196139816" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 08 Apr 2013 12:23:04 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r38CN3fn005990 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Apr 2013 12:23:03 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.181]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 07:23:03 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Agreement to move cdni-requirements to WG Last Call Thread-Index: AQHONFPQ3gXT6Iy4FkerT8CbK9Bbxw== Date: Mon, 8 Apr 2013 12:23:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BC5FC9462116545B173CDB45B4D333F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Agreement to move cdni-requirements to WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 12:23:06 -0000 All, No concerns/issues have been expressed, so we will issue a WG Last Call as = soon as the next rev of cdni-requirements is posted. Francois and Daryl On 22 Mar 2013, at 13:33, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > During IETF-86, the WG tentatively agreed to go to WG Last Call once the = next rev of cdni-requirements is posted. If you have concerns/issues with t= hat, let us know by 5 April 2013.=20 >=20 > Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From internet-drafts@ietf.org Mon Apr 8 06:55:32 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B2421F944A; Mon, 8 Apr 2013 06:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjbvJuutnGNv; Mon, 8 Apr 2013 06:55:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CCC21F949A; Mon, 8 Apr 2013 06:55: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.43.p3 Message-ID: <20130408135531.4819.8703.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 06:55:31 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-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, 08 Apr 2013 13:55:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Control Interface / Triggers Author(s) : Rob Murray Ben Niven-Jenkins Filename : draft-ietf-cdni-control-triggers-00.txt Pages : 36 Date : 2013-04-08 Abstract: This document describes the part of the CDN Interconnect Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it re-validate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kleung@cisco.com Mon Apr 8 11:54:10 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE3021F86C0 for ; Mon, 8 Apr 2013 11:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzc+QoBXFPKl for ; Mon, 8 Apr 2013 11:54:06 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C08F221F8675 for ; Mon, 8 Apr 2013 11:54:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27666; q=dns/txt; s=iport; t=1365447245; x=1366656845; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=bxxpnxttjaceFRMgIp4KdD4fl9bEsbvukuOdJ/zl/FY=; b=IxM7n9zOo/Bos0NQWGYjktE+hzD6GXr8V1Z6zK71MmYz8TT9xMSXqf7+ be7f+ImtVfnNTxawLXIPgkdl01TIYA5mFzvBhM2QJ/guOyU4M2a5K0+nq +OsdEdkNs+qV6PycAN78XtiW+xkaWcuF4Ct2SOtOAi/GANnh9NzwcUAGk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQFAKgRY1GtJV2Y/2dsb2JhbABRgwY2RMBngQsWdIIfAQEBAwEBAQEXIDQCAgIFBQcEAgEIEQEDAQEBChQJBycLFAMGCAIECgQFCAESh3MFAQcFvU+NYg8GeyYLAgUGglphA5gVj22DC4FrAQcXAQUY X-IronPort-AV: E=Sophos;i="4.87,432,1363132800"; d="scan'208";a="193354794" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 08 Apr 2013 18:54:04 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r38Is4Ka029675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Apr 2013 18:54:04 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.24]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 13:54:04 -0500 From: "Kent Leung (kleung)" To: "Francois Le Faucheur (flefauch)" Thread-Topic: Comments on draft-ietf-cdni-requirements-05.txt Thread-Index: AQHONIpwHLzh3hoU6kCD0dCNIDs+8w== Date: Mon, 8 Apr 2013 18:54:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.69.41.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-ietf-cdni-requirements-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 18:54:10 -0000 Hi Francois. Thanks for the thorough review. I'll incorporate your feedback= . Just a few comments and clarification questions below. I should be able t= o publish the draft in a few days. -----Original Message----- From: Francois Le Faucheur (flefauch)=20 Sent: Saturday, March 30, 2013 2:50 AM To: Kent Leung (kleung) Cc: cdni@ietf.org Subject: Comments on draft-ietf-cdni-requirements-05.txt Hi Kent and all, In addition to the comment already discussed below, here are my remaining c= omments (as an Individual): OLD: " GEN-4 [HIGH] The CDNI solution shall not require intra-CDN information ... " NEW: " GEN-4 [HIGH] The CDNI solution shall not depend on intra-CDN information ... " KL> ok OLD: " GEN-5 [HIGH] The CDNI solution shall support delivery to the user agent based on HTTP [RFC2616]. (Note that while delivery and acquisition "data plane" protocols are out of the CDNI solution scope, the CDNI solution "control plane" protocols are expected to participate in enabling, selecting or facilitating operations of such acquisition and delivery protocols. Hence it is useful to state requirements on the CDNI solution in terms of which acquisition and delivery protocols). GEN-6 [HIGH] The CDNI solution shall support acquisition across CDNs based on HTTP [RFC2616]. " NEW: " GEN-5 [HIGH] The CDNI solution shall support delivery to the user agent based on HTTP [RFC2616]. =20 GEN-6 [HIGH] The CDNI solution shall support acquisition across CDNs based on HTTP [RFC2616]. (Note that while delivery and acquisition "data plane" protocols are out of= the CDNI solution scope, the CDNI solution "control plane" protocols are e= xpected to participate in enabling, selecting or facilitating operations of= such acquisition and delivery protocols. Hence it is useful to state requ= irements on the CDNI solution in terms of which acquisition and delivery pr= otocols). " (Rationale: the note applies to both GEN-5 and GEN-6) KL> ok. I've kept the note for GEN-5 and added " (The note above applies to= this requirement too)" to GEN-6. Formatting remains consistent this way. Regarding: " GEN-13 Removed. " I suggest you just remove altogether the requirements that were dropped and= renumber the following ones to avoid gaps. KL> ok. It was better to keep all the requirement numbers for discussions (= i.e. clear reference) up to this point. Now we are ready for last call. We'= ll clean up all the removed requirements. This means the authors of the int= erface drafts need to update their references to the requirements draft. I = can create a mapping of the numbering changes between ver -05 to -06 if tha= t's helpful. What do you think? Regarding: " CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream CDN to request that the Downstream CDN (and, if cascaded CDNs are supported by the solution, that the potential cascaded Downstream CDNs) perform the following actions on an object or object set: * Mark an object or set of objects and/or its CDNI metadata as "stale" and revalidate them before they are delivered again * Delete an object or set of objects and/or its CDNI metadata from the CDN surrogates and any storage. Only the object(s) and CDNI metadata that pertain to the requesting Upstream CDN are allowed to be purged. " It is clear to me that the 2nd bullet is a [HIGH].=20 But it is not clear to me that the first bullet is really a [HIGH]. I see i= t as an optimisation, not a must-have. I'd rate it as a [MID] or [LOW]. In = fact, does the "triggers" interface actually cope for that ? Perhaps you can split the two bullets so they can have a different priority= level. KL> ok. It's better to split the bullets and prioritize differently. The c= urrent triggers interface deals with delete only, AFAIK. Regarding: " CNTL-3 [HIGH] The CDNI Control interface shall support initiation and control by the Upstream CDN of pre-positioned CDNI metadata acquisition by the Downstream CDN. " I thought we have agreed that pre-positioning would be a [MED] whether cont= ent or metadata. CNTL-4 is already a [MED]. I suggest making CNTL-3 a [MED]= also. KL> ok.=20 Regarding: " CNTL-10 [LOW] The CDNI Control interface may allow exchange and negotiation of delivery authorization mechanisms to be supported across the CDNs (e.g. URI signature based validation). " This functionality has moved to the FCI. How about, you move this functiona= lity with the rest of the text discussing the FCI requirements? KL> ok Regarding: " CNTL-12 [MED] The CDNI Control interface should allow for multiple content items identified by a Content Collection ID to be purged using a single Content Purge action. " I suggest moving this requirement up so it follows the first purge-related = requirements i.e. place it right after CNTL-1. KL> ok Regarding Section 5: I strongly recommend that: * you split this into separate sections for RI and FCI.=20 * in each requirement, you mention the actual interface (i.e. RI or FCI) i= nstead of "the Request Routing Interface". It will make it much easier to read, and much more useful so we know which = requirements applies to which interface. KL> ok. Requirements will be renamed to RI-# and FCI-#. (note to self: TODO= ) Regarding REQ-15 and "[Ed: chunk is treated as any content, is this needed?= ]" I vote for keeping it in. Explicit is better.=20 KL> ok Regarding REQ-16 and REQ-17: I vote for [LOW]. I see Manifest-file-Manipula= tion approaches as nice-to-allow but not [MED]. KL> ok Regarding REQ-19: it is a [MED] but you use "may". I think it shoudl say "s= hould" for a [MED]. BTW: at the very end of editing , you should probably do a pass and check t= he shall/should/may correspond to HIGH/MED/LOW in each and every requiremen= t. e.g. there is also a mismatch in REQ-20. KL> ok (note to self: TODO) Regarding REQ-20: The list of capabilities here is a little out of date (e.g. "support for cu= stomised CDNI logging" - which is dropped) and only covers the ones related= to logging while it shoudl bring up the other ones (e.g. delivery protocol= ). Since the actual capabilities are discussed in the FCI semantics draft, = I would suggest not trying to list specific capabilities in that requiremen= t, and instead keep it high level and probably just list the types of capab= ilities (e.g. mention it needs to cover capabilities associated with loggin= g, with distribution protocols, with acquisition protocols, etc..) KL> ok OLD: " META-7 [HIGH] The CDNI Metadata Distribution interface shall allow the Upstream CDN to request addition and modification of CDNI Metadata into the Downstream CDN. " NEW: " META-7 [HIGH] The CDNI Metadata Distribution interface (possibly in conju= nction with the CDNI Control interface) shall allow the Upstream CDN to request addition and modification of CDNI Metadata into the Downstream CDN. " KL> ok OLD: " META-8 [HIGH] The CDNI Metadata Distribution interface shall allow removal of obsolete CDNI Metadata from the Downstream CDN (this could, for example, be achieved via an explicit removal request from the Upstream CDN or via expiration of a Time-To-Live associated to the Metadata). " NEW: " META-8 [HIGH] The CDNI Metadata Distribution interface (possibly in conju= nction with the CDNI Control interface) shall allow removal of obsolete CDNI Metadata from the Downstream CDN (this could, for example, be achieved via an explicit removal request from the Upstream CDN or via expiration of a Time-To-Live associated to the Metadata). " KL> ok OLD: " META-15 [HIGH] The CDNI Metadata interface shall be able to exchange a set of well-accepted metadata elements with specified semantics (e.g. start of time window, end of time window). " NEW: " META-15 [HIGH] The CDNI Metadata interface shall be able to exchange a set of metadata elements with specified semantics (e.g. start of time window, end of time window). " KL> ok Regarding META-18: see thread below. KL> The thread below is about logging customization and directional logging= . Not clear about relationship to this requirement? Regarding META-20: As documented in http://www.ietf.org/mail-archive/web/cd= ni/current/msg01375.html, it is felt that this requirement shoudl not be pu= rsued for initial deliverables. Besides, there was no hard conclusion as to= whether this would belong to MI or CI. This requirement should be a [MED] = (instead of a [HIGH]) and I suggest you add a note indicating that there is= still some thinking to be done to conclude whether this should really be M= I or CI. KL> ok OLD: " LOG-1 [HIGH] The CDNI logging architecture and interface shall ensure reliable logging of CDNI events. " NEW: " LOG-1 [HIGH] The CDNI logging architecture and interface shall ensure reliable transfer of CDNI logging information across CDNs= . " KL> ok OLD: " LOG-7 [HIGH] The CDNI Logging interface shall define a log file format and a set of fields to be exported through the Logging protocol, with some granularity (e.g. On a per content type basis). " NEW: " LOG-7 [HIGH] The CDNI Logging interface shall define a log file format and a set of fields to be exported for various CDNI loggi= ng events. " KL> ok re LOG-8: s/mechanisms/mechanism/ re LOG-14: This requirement should be removed since it is already covered by another r= equirement on the CI. KL> ok OLD: " LOG-17 [HIGH] The CDNI Logging interface shall support the notification from Downstream CDN to Upstream CDN for the event that the logging retention duration or maximum size of logging data has exceeded. " NEW: " LOG-17 [HIGH] The CDNI Logging interface shall allow a CDN to notify anoth= er CDN about which CDNI logging information is available for transfer (and/= or no longer available, say because it exceeded some logging retention peri= od or some logging retention volume). " Rationale: The current wording was overly prescriptive. I think the key poi= nt is that the CDNs should inform each other about which info can be obtain= ed.=20 KL> ok OLD: " LOG-18 [MED] The CDNI Logging interface should support the ability for the Downstream CDN to include the Content Collection ID and Session ID fields in CDNI log entries generated for HTTP Adaptive Streaming content. This fields can be supported by the "customizable" log format which is expected to be defined independently of HTTP Adaptive Streaming. " NEW: " LOG-18 [MED] The CDNI Logging interface should support the ability for the Downstream CDN to include the Content Collection ID and Session ID fields in CDNI log entries generated for HTTP Adaptive Streaming content. " Rationale: again custom log likely not supported initially. KL> ok Kent Francois On 12 Mar 2013, at 17:53, Kent Leung (kleung) wrote: > Hi Francois. Comments below in "KL>". >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Tuesday, March 12, 2013 7:08 AM > To: Kent Leung (kleung) > Cc: cdni@ietf.org > Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt >=20 > Kent and all, >=20 > I have received consistent feed-back from two CDN operators and a Content= Provider that the CDNI solution ought to support: > *A* enforcement of caching directives by dCDN that are different to the = ones signalled in the HTTP headers > *B* choice of ignoring/factoring query string in dCDN caching > *C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive=20 > Download) >=20 > *A* and *B* are already mostly covered in META-18 but it is listed as [LO= W]. I would recommend we raise META-18 to [MED]. >=20 > KL> That sounds reasonable to me. Unless others object, this requirement = will be set to MED priority in the next version. >=20 > I don't think *C* is covered. I would recommend we add rate-pacing as a 3= rd example of "surrogate cache behaviour" in META-18.=20 >=20 > KL> I can see some value of this feature. I'll see how the debate settles= before updating the draft. >=20 > I will bring this up in the CDNI session today, but wanted to give folks = some heads-up. >=20 > KL> Thanks for the heads up. >=20 > I also have other comments on -05 which I will either pass on to Kent dir= ectly or post on the list. >=20 > KL> Thanks. >=20 > Kent >=20 >=20 > Cheers >=20 > Francois >=20 >=20 >=20 > " > META-18 [LOW] The CDNI Metadata Distribution interface may allow > signaling of CDNI-relevant surrogate cache behavior > parameters. For example, this could potentially include: >=20 > * control of whether the query string of HTTP URI is to be > ignored by surrogate cache >=20 > * content revalidation parameters (e.g. TTL) > " >=20 >=20 > On 6 Mar 2013, at 18:08, Kent Leung (kleung) wrote: >=20 >> Hi folks. The requirements draft was updated based on the feedback from = the authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), d= raft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-loggi= ng. >>=20 >> In preparation for the next WG session, the edits were published in the = draft for review. Please provide your comments to the list of requirement c= hanges below. Thanks. >>=20 >> 1. New CDNI Control Interface requirement >>=20 >> a. Based on recommendations in ID-HAS, CCID is introduced for HAS= content without the need for HAS-aware CDN. >>=20 >> CNTL-12 [MED] The CDNI Control interface should allow for multip= le=09 >> content items identified by a Content Collection ID to be=09 >> purged using a single Content Purge action. >>=20 >> 2. New CDNI Request Routing Interface requirements >>=20 >> a. This is an explicit requirement for RRI to support per-chunk = request routing. Since the chunk is same as any content, it's not clear if = the requirement is needed? >>=20 >> REQ-15 [HIGH] The CDNI Request-Routing interface shall allow fo= r=09 >> per-chunk request routing of HTTP Adaptive Streaming content= .=09 >> [Ed: chunk is treated as any content, is this needed?]=09 >> =09 >> b. Manifest rewrite by uCDN is considered as optional feature in= the ID-HAS, should the priority be LOW instead of MED? >>=20 >> REQ-16 [MED] The CDNI Request-Routing interface should allow th= e=09 >> Upstream CDN to use the information conveyed by the=09 >> Downstream CDN during the Recursive Request Routing process= =09 >> to rewrite an HTTP Adaptive Streaming manifest file. [Ed:=09 >> should this be LOW?]=09 >>=20 >> c. Manifest rewrite by uCDN for URI Signing is considered as op= tional feature in the ID-HAS, should the priority be LOW instead of MED? >> =09 >> REQ-17 [MED] The CDNI Request-Routing interface should allow t= he=09 >> Upstream CDN to re-sign the invariant portion of the chunk=09 >> URIs embedded in the HTTP Adaptive Streaming manifest file.= =09 >> [Ed: should this be LOW?]=09 >> =09 >> d. Use of cookie for URI Signing is is considered as optional fe= ature in the ID-HAS, should the priority be LOW instead of MED? >>=20 >> REQ-18 [MED] The CDNI Request-routing interface should allow th= e use=09 >> of HTTP cookie to associate the chunks with the HTTP Adaptiv= e=09 >> Stream manifest file (which is verified by the URI signature= )=09 >> basedon the Authorization Group ID (which is an identifier=09 >> used to correlate the manifest file to the related chunks).= =09 >> [Ed: should this be LOW?]=09 >>=20 >> e. LOW instead of MED priority?=09 >>=20 >> REQ-19 [MED] The CDNI Request-Routing interface may allow for a= n=09 >> efficient method of transferring request routing information= =09 >> for multiple chunks from the Downstream CDN to the Upstream= =09 >> CDN as part of the recursive request routing process. [Ed:= =09 >> should this be LOW?]=09 >> =09 >> f. Based on ID-HAS and logging drafts, the following requirement= was introduced to log HAS content and customization of the logging. >> =09 >> REQ-20 [MED] The CDNI Request-Routing/Footprint and Advertising= =09 >> interface shall support advertisement of the following=09 >> capabilities:=09 >> =09 >> * support for customized CDNI Logging=09 >> =09 >> * support of Content Collection ID logging=09 >> =09 >> * support for Session ID logging >>=20 >> 3. Removed CDNI Metadata Distribution Interface requirement. >>=20 >> a. Based on the metadata draft, there is no need for dCDN to ind= icate to the uCDN the result of delivering the metadata since the "pull" or= "triggered pull" model is used (i.e. dCDN request for metadata from uCDN). >>=20 >> META-13 [HIGH] The CDNI Metadata Distribution interface shall =09 >> provide indication by the Downstream CDN to the Upstream CDN = =09 >> of whether the CDNI metadata (and corresponding future =09 >> request redirections) is accepted or rejected. When =09 >> rejected, the CDNI Metadata Distribution protocol Must allow = =09 >> the Downstream CDN to provide information about the cause of = =09 >> the rejection. =09 >>=20 >> 4. New CDNI Metadata Distribution Interface requirements >>=20 >> a. Based on ID-HAS's recommendations, this is introduced. >>=20 >> META-19 [HIGH] The CDNI Metadata interface shall provide indicati= on=09 >> of related content (e.g. HTTP Adaptive Bit Rate chunks) by= =09 >> the Content Collection ID (CCID) metadata. This could be=09 >> used by the Downstream CDN for operations on the group of=09 >> content. For example, this could potentially include:=09 >> =09 >> * content acquisition for the entire set of files when on= e=09 >> piece of content is requested=09 >> =09 >> * local file management and storage bundles all the files= =09 >> for the content=09 >> =09 >> * purging the entire set of files associated with the=09 >> content=09 >> =09 >> * logging of the delivery of the content for the session= =09 >> when at least one file in the set was delivered=09 >> =09 >> b. Based on the logging draft, this is introduced. >>=20 >> META-20 [HIGH] The CDNI Metadata Distribution interface shall=09 >> support an OPTIONAL mechanism allowing the Upstream CDN to= =09 >> indicate to the Downstream CDN which CDNI Log fields are to= =09 >> be provided for all, for specific sets of, or for specific= =09 >> content items delivered using HTTP. A CDNI implementation= =09 >> that does not support this optional CDNI Metadata=09 >> Distribution Interface mechanism MUST ignore this log forma= t=09 >> indication and generate CDNI logging format for HTTP=09 >> Adaptive Streaming using the default set of CDNI Logging=09 >> fields.=09 >> =09 >> c. Based on the ID-HAS's recommendations, this is introduced. >>=20 >> META-21 [MED] The CDNI Metadata Distribution interface shall allo= w=09 >> the Upstream CDN to signal to the Downstream CDN the Conten= t=09 >> Collection ID value for all, for specific sets of, or for=09 >> specific content items delivered using HTTP. Whenever the= =09 >> Downstream CDN is instructed by the Upstream CDN to report= =09 >> the Content Collection ID field in the log records, the=09 >> Downstream CDN is to use the value provided through the CDN= I=09 >> Metadata interface for the corresponding content. Note the= =09 >> Session ID field along with Content Collection ID may be=09 >> used for HTTP Adaptive Streaming content.=09 >> =09 >> d. Based on ID-HAS's recommendations, this is introduced. >>=20 >> META-22 [MED] The CDNI Metadata Distribution interface shall allo= w=09 >> the Upstream CDN to signal to the Downstream CDN the=09 >> Authorization Group ID value for all the related HTTP=09 >> Adaptive Streamin content (i.e. manifest file and chunks).= =09 >> The authorization result of a content (e.g. manifest file)= =09 >> is transferred over to related content (e.g. chunks). [Ed:= =09 >> need to improve wording?] >>=20 >> 5. Remove CDNI Logging Interface requirement >>=20 >> a. It is deemed unnecessary for dCDN to obtain logs from uCDN, whi= ch has access to all the logs for trouble-shooting and auditing. >>=20 >> LOG-4 [HIGH] The CDNI Logging interface shall provide logging of =09 >> distribution performed by the Upstream CDN as a result of =09 >> acquisition request by the Downstream CDN. >>=20 >> 6. Add CDNI Logging Interface requirements >>=20 >> a. Based on the logging draft, this is introduced. >>=20 >> LOG-17 [HIGH] The CDNI Logging interface shall support the=09 >> notification from Downstream CDN to Upstream CDN for the=09 >> event that the logging retention duration or maximum size of= =09 >> logging data has exceeded.=09 >> =09 >> b. Based on the ID-HAS, CCID is a field to report in the log. Al= so, based on the logging draft, Session ID is another field needed in the l= og. >>=20 >> LOG-18 [MED] The CDNI Logging interface should support the abil= ity=09 >> for the Downstream CDN to include the Content Collection ID= =09 >> and Session ID fields in CDNI log entries generated for HTTP= =09 >> Adaptive Streaming content. This fields can be supported by= =09 >> the "customizable" log format which is expected to be define= d=09 >> independently of HTTP Adaptive Streaming. >>=20 >> Kent >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 >> Of internet-drafts@ietf.org >> Sent: Saturday, February 23, 2013 1:16 PM >> To: i-d-announce@ietf.org >> Cc: cdni@ietf.org >> Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Content Delivery Networks Interconnecti= on Working Group of the IETF. >>=20 >> Title : Content Distribution Network Interconnection (CDNI) R= equirements >> Author(s) : Kent Leung >> Yiu Lee >> Filename : draft-ietf-cdni-requirements-05.txt >> Pages : 23 >> Date : 2013-02-23 >>=20 >> Abstract: >> Content Delivery Networks (CDNs) are frequently used for large-scale =20 >> content delivery. As a result, existing CDN providers are scaling up =20 >> their infrastructure and many Network Service Providers (NSPs) are =20 >> deploying their own CDNs. There is a requirement for interconnecting =20 >> standalone CDNs so that their collective CDN footprint can be =20 >> leveraged for the end-to-end delivery of content from Content Service =20 >> Providers (CSPs) to end users. The Content Distribution Network =20 >> Interconnection (CDNI) working group has been chartered to develop an =20 >> interoperable and scalable solution for such CDN interconnection. >>=20 >> The goal of the present document is to outline the requirements for =20 >> the solution and interfaces to be specified by the CDNI working =20 >> group. This draft is a work in progress and requirements may be =20 >> added, modified, or removed by the working group. >>=20 >> Requirements Language >>=20 >> The key words "High Priority", "Medium Priority" and "Low Priority" >> in this document are to be interpreted in the following way: >>=20 >> o "High Priority" indicates requirements that are to be supported by >> the CDNI interfaces. A requirement is stated as "High Priority" >> when it is established by the working group that it can be met >> without compromising the targeted schedule for WG deliverables, or >> when it is established that specifying a solution without meeting >> this requirement would not make sense and would justify re- >> adjusting the WG schedule, or both. This is tagged as "[HIGH]". >>=20 >> o "Medium Priority" indicates requirements that are to be supported >> by the CDNI interfaces unless the WG realizes at a later stage >> that attempting to meet this requirement would compromise the >> overall WG schedule (for example it would involve complexities >> that would result in significantly delaying the deliverables). >> This is tagged as "[MED]". >>=20 >> o "Low Priority" indicates requirements that are to be supported by >> the CDNI interfaces provided that dedicating WG resources to this >> work does not prevent addressing "High Priority" and "Medium >> Priority" requirements and that attempting to meet this >> requirement would not compromise the overall WG schedule. This is >> tagged as "[LOW]". >>=20 >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-cdni-requirements-05 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-05 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From kevin.ma@azukisystems.com Mon Apr 8 18:17:32 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8BC21F8E59 for ; Mon, 8 Apr 2013 18:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huoARGtgWxdj for ; Mon, 8 Apr 2013 18:17:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id F0D6121F8E62 for ; Mon, 8 Apr 2013 18:17:27 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 56D7E7A5931; Mon, 8 Apr 2013 21:17:27 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6029E7A4F73; Mon, 8 Apr 2013 21:17:21 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Mon, 8 Apr 2013 21:17:21 -0400 From: Kevin J Ma To: "Kent Leung (kleung)" , "Francois Le Faucheur (flefauch)" Date: Mon, 8 Apr 2013 21:17:19 -0400 Thread-Topic: Comments on draft-ietf-cdni-requirements-05.txt Thread-Index: AQHONIpwHLzh3hoU6kCD0dCNIDs+85jNEvRQ Message-ID: <291CC3F9E50E7641901A54E85D0977C665EFCE2334@MAILR002.mail.lan> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-ietf-cdni-requirements-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 01:17:32 -0000 > In fact, does the "triggers" interface actually cope for that ? > Perhaps you can split the two bullets so they can have a different > priority level. > > KL> ok. It's better to split the bullets and prioritize differently. The > current triggers interface deals with delete only, AFAIK. the triggers draft covers invalidate... the invalidate trigger type is defined in sections 5.5.1 and 6.1.1, and an example is provided in section 7.1.2. > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Kent Leung (kleung) > Sent: Monday, April 08, 2013 2:54 PM > To: Francois Le Faucheur (flefauch) > Cc: cdni@ietf.org > Subject: Re: [CDNi] Comments on draft-ietf-cdni-requirements-05.txt > > Hi Francois. Thanks for the thorough review. I'll incorporate your > feedback. Just a few comments and clarification questions below. I should > be able to publish the draft in a few days. > > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Saturday, March 30, 2013 2:50 AM > To: Kent Leung (kleung) > Cc: cdni@ietf.org > Subject: Comments on draft-ietf-cdni-requirements-05.txt > > Hi Kent and all, > > In addition to the comment already discussed below, here are my remaining > comments (as an Individual): > > > OLD: > " > GEN-4 [HIGH] The CDNI solution shall not require intra-CDN > information ... > " > NEW: > " > GEN-4 [HIGH] The CDNI solution shall not depend on intra-CDN > information ... > " > > KL> ok > > OLD: > " > GEN-5 [HIGH] The CDNI solution shall support delivery to the user > agent based on HTTP [RFC2616]. (Note that while delivery and > acquisition "data plane" protocols are out of the CDNI > solution scope, the CDNI solution "control plane" protocols > are expected to participate in enabling, selecting or > facilitating operations of such acquisition and delivery > protocols. Hence it is useful to state requirements on the > CDNI solution in terms of which acquisition and delivery > protocols). > > GEN-6 [HIGH] The CDNI solution shall support acquisition across > CDNs based on HTTP [RFC2616]. > " > NEW: > " > GEN-5 [HIGH] The CDNI solution shall support delivery to the user > agent based on HTTP [RFC2616]. > > GEN-6 [HIGH] The CDNI solution shall support acquisition across > CDNs based on HTTP [RFC2616]. > > (Note that while delivery and acquisition "data plane" protocols are out > of the CDNI solution scope, the CDNI solution "control plane" protocols > are expected to participate in enabling, selecting or facilitating > operations of such acquisition and delivery protocols. Hence it is usefu= l > to state requirements on the CDNI solution in terms of which acquisition > and delivery protocols). > " > (Rationale: the note applies to both GEN-5 and GEN-6) > > KL> ok. I've kept the note for GEN-5 and added " (The note above applies > to this requirement too)" to GEN-6. Formatting remains consistent this > way. > > Regarding: > " > GEN-13 Removed. > " > I suggest you just remove altogether the requirements that were dropped > and renumber the following ones to avoid gaps. > > KL> ok. It was better to keep all the requirement numbers for discussions > (i.e. clear reference) up to this point. Now we are ready for last call. > We'll clean up all the removed requirements. This means the authors of th= e > interface drafts need to update their references to the requirements > draft. I can create a mapping of the numbering changes between ver -05 to > -06 if that's helpful. What do you think? > > Regarding: > " > CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream > CDN to request that the Downstream CDN (and, if cascaded > CDNs are supported by the solution, that the potential > cascaded Downstream CDNs) perform the following actions on > an object or object set: > > * Mark an object or set of objects and/or its CDNI > metadata as "stale" and revalidate them before they are > delivered again > > * Delete an object or set of objects and/or its CDNI > metadata from the CDN surrogates and any storage. Only > the object(s) and CDNI metadata that pertain to the > requesting Upstream CDN are allowed to be purged. > " > It is clear to me that the 2nd bullet is a [HIGH]. > But it is not clear to me that the first bullet is really a [HIGH]. I see > it as an optimisation, not a must-have. I'd rate it as a [MID] or [LOW]. > In fact, does the "triggers" interface actually cope for that ? > Perhaps you can split the two bullets so they can have a different > priority level. > > KL> ok. It's better to split the bullets and prioritize differently. The > current triggers interface deals with delete only, AFAIK. > > > Regarding: > " > CNTL-3 [HIGH] The CDNI Control interface shall support initiation > and control by the Upstream CDN of pre-positioned CDNI > metadata acquisition by the Downstream CDN. > " > I thought we have agreed that pre-positioning would be a [MED] whether > content or metadata. CNTL-4 is already a [MED]. I suggest making CNTL-3 a > [MED] also. > > KL> ok. > > Regarding: > " > CNTL-10 [LOW] The CDNI Control interface may allow exchange and > negotiation of delivery authorization mechanisms to be > supported across the CDNs (e.g. URI signature based > validation). > " > This functionality has moved to the FCI. How about, you move this > functionality with the rest of the text discussing the FCI requirements? > > KL> ok > > Regarding: > " > CNTL-12 [MED] The CDNI Control interface should allow for multiple > content items identified by a Content Collection ID to be > purged using a single Content Purge action. > " > I suggest moving this requirement up so it follows the first purge-relate= d > requirements i.e. place it right after CNTL-1. > > KL> ok > > Regarding Section 5: > I strongly recommend that: > * you split this into separate sections for RI and FCI. > * in each requirement, you mention the actual interface (i.e. RI or > FCI) instead of "the Request Routing Interface". > It will make it much easier to read, and much more useful so we know whic= h > requirements applies to which interface. > > KL> ok. Requirements will be renamed to RI-# and FCI-#. (note to self: > TODO) > > Regarding REQ-15 and "[Ed: chunk is treated as any content, is this > needed?]" > I vote for keeping it in. Explicit is better. > > KL> ok > > Regarding REQ-16 and REQ-17: I vote for [LOW]. I see Manifest-file- > Manipulation approaches as nice-to-allow but not [MED]. > > KL> ok > > Regarding REQ-19: it is a [MED] but you use "may". I think it shoudl say > "should" for a [MED]. > BTW: at the very end of editing , you should probably do a pass and check > the shall/should/may correspond to HIGH/MED/LOW in each and every > requirement. e.g. there is also a mismatch in REQ-20. > > KL> ok (note to self: TODO) > > Regarding REQ-20: > The list of capabilities here is a little out of date (e.g. "support for > customised CDNI logging" - which is dropped) and only covers the ones > related to logging while it shoudl bring up the other ones (e.g. delivery > protocol). Since the actual capabilities are discussed in the FCI > semantics draft, I would suggest not trying to list specific capabilities > in that requirement, and instead keep it high level and probably just lis= t > the types of capabilities (e.g. mention it needs to cover capabilities > associated with logging, with distribution protocols, with acquisition > protocols, etc..) > > KL> ok > > OLD: > " > META-7 [HIGH] The CDNI Metadata Distribution interface shall allow > the Upstream CDN to request addition and modification of > CDNI Metadata into the Downstream CDN. > " > NEW: > " > META-7 [HIGH] The CDNI Metadata Distribution interface (possibly in > conjunction with the CDNI Control interface) shall allow > the Upstream CDN to request addition and modification of > CDNI Metadata into the Downstream CDN. > " > > KL> ok > > > OLD: > " > META-8 [HIGH] The CDNI Metadata Distribution interface shall allow > removal of obsolete CDNI Metadata from the Downstream CDN > (this could, for example, be achieved via an explicit > removal request from the Upstream CDN or via expiration of a > Time-To-Live associated to the Metadata). > " > NEW: > " > META-8 [HIGH] The CDNI Metadata Distribution interface (possibly in > conjunction with the CDNI Control interface) shall allow > removal of obsolete CDNI Metadata from the Downstream CDN > (this could, for example, be achieved via an explicit > removal request from the Upstream CDN or via expiration of a > Time-To-Live associated to the Metadata). > " > > KL> ok > > OLD: > " > META-15 [HIGH] The CDNI Metadata interface shall be able to exchange > a set of well-accepted metadata elements with specified > semantics (e.g. start of time window, end of time window). > " > NEW: > " > META-15 [HIGH] The CDNI Metadata interface shall be able to exchange > a set of metadata elements with specified > semantics (e.g. start of time window, end of time window). > " > > KL> ok > > Regarding META-18: see thread below. > > KL> The thread below is about logging customization and directional > logging. Not clear about relationship to this requirement? > > > Regarding META-20: As documented in http://www.ietf.org/mail- > archive/web/cdni/current/msg01375.html, it is felt that this requirement > shoudl not be pursued for initial deliverables. Besides, there was no har= d > conclusion as to whether this would belong to MI or CI. This requirement > should be a [MED] (instead of a [HIGH]) and I suggest you add a note > indicating that there is still some thinking to be done to conclude > whether this should really be MI or CI. > > KL> ok > > OLD: > " > LOG-1 [HIGH] The CDNI logging architecture and interface shall > ensure reliable logging of CDNI events. > " > NEW: > " > LOG-1 [HIGH] The CDNI logging architecture and interface shall > ensure reliable transfer of CDNI logging information across > CDNs. > " > > KL> ok > > OLD: > " > LOG-7 [HIGH] The CDNI Logging interface shall define a log file > format and a set of fields to be exported through the Logging > protocol, with some granularity (e.g. On a per content type > basis). > " > NEW: > " > LOG-7 [HIGH] The CDNI Logging interface shall define a log file > format and a set of fields to be exported for various CDNI > logging events. > " > > KL> ok > > re LOG-8: > s/mechanisms/mechanism/ > > > re LOG-14: > This requirement should be removed since it is already covered by another > requirement on the CI. > > KL> ok > > OLD: > " > LOG-17 [HIGH] The CDNI Logging interface shall support the > notification from Downstream CDN to Upstream CDN for the > event that the logging retention duration or maximum size of > logging data has exceeded. > " > NEW: > " > LOG-17 [HIGH] The CDNI Logging interface shall allow a CDN to notify > another CDN about which CDNI logging information is available for transfe= r > (and/or no longer available, say because it exceeded some logging > retention period or some logging retention volume). > " > Rationale: The current wording was overly prescriptive. I think the key > point is that the CDNs should inform each other about which info can be > obtained. > > KL> ok > > OLD: > " > LOG-18 [MED] The CDNI Logging interface should support the ability > for the Downstream CDN to include the Content Collection ID > and Session ID fields in CDNI log entries generated for HTTP > Adaptive Streaming content. This fields can be supported by > the "customizable" log format which is expected to be defined > independently of HTTP Adaptive Streaming. > " > NEW: > " > LOG-18 [MED] The CDNI Logging interface should support the ability > for the Downstream CDN to include the Content Collection ID > and Session ID fields in CDNI log entries generated for HTTP > Adaptive Streaming content. > " > Rationale: again custom log likely not supported initially. > > KL> ok > > Kent > > > > Francois > > On 12 Mar 2013, at 17:53, Kent Leung (kleung) wrote: > > > Hi Francois. Comments below in "KL>". > > > > -----Original Message----- > > From: Francois Le Faucheur (flefauch) > > Sent: Tuesday, March 12, 2013 7:08 AM > > To: Kent Leung (kleung) > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt > > > > Kent and all, > > > > I have received consistent feed-back from two CDN operators and a > Content Provider that the CDNI solution ought to support: > > *A* enforcement of caching directives by dCDN that are different to > the ones signalled in the HTTP headers > > *B* choice of ignoring/factoring query string in dCDN caching > > *C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive > > Download) > > > > *A* and *B* are already mostly covered in META-18 but it is listed as > [LOW]. I would recommend we raise META-18 to [MED]. > > > > KL> That sounds reasonable to me. Unless others object, this requiremen= t > will be set to MED priority in the next version. > > > > I don't think *C* is covered. I would recommend we add rate-pacing as a > 3rd example of "surrogate cache behaviour" in META-18. > > > > KL> I can see some value of this feature. I'll see how the debate > settles before updating the draft. > > > > I will bring this up in the CDNI session today, but wanted to give folk= s > some heads-up. > > > > KL> Thanks for the heads up. > > > > I also have other comments on -05 which I will either pass on to Kent > directly or post on the list. > > > > KL> Thanks. > > > > Kent > > > > > > Cheers > > > > Francois > > > > > > > > " > > META-18 [LOW] The CDNI Metadata Distribution interface may allow > > signaling of CDNI-relevant surrogate cache behavior > > parameters. For example, this could potentially include: > > > > * control of whether the query string of HTTP URI is to be > > ignored by surrogate cache > > > > * content revalidation parameters (e.g. TTL) > > " > > > > > > On 6 Mar 2013, at 18:08, Kent Leung (kleung) wrote: > > > >> Hi folks. The requirements draft was updated based on the feedback fro= m > the authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), > draft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni- > logging. > >> > >> In preparation for the next WG session, the edits were published in th= e > draft for review. Please provide your comments to the list of requirement > changes below. Thanks. > >> > >> 1. New CDNI Control Interface requirement > >> > >> a. Based on recommendations in ID-HAS, CCID is introduced for > HAS content without the need for HAS-aware CDN. > >> > >> CNTL-12 [MED] The CDNI Control interface should allow for > multiple > >> content items identified by a Content Collection ID to > be > >> purged using a single Content Purge action. > >> > >> 2. New CDNI Request Routing Interface requirements > >> > >> a. This is an explicit requirement for RRI to support per-chun= k > request routing. Since the chunk is same as any content, it's not clear i= f > the requirement is needed? > >> > >> REQ-15 [HIGH] The CDNI Request-Routing interface shall allow > for > >> per-chunk request routing of HTTP Adaptive Streaming > content. > >> [Ed: chunk is treated as any content, is this needed?] > >> > >> b. Manifest rewrite by uCDN is considered as optional feature > in the ID-HAS, should the priority be LOW instead of MED? > >> > >> REQ-16 [MED] The CDNI Request-Routing interface should allow > the > >> Upstream CDN to use the information conveyed by the > >> Downstream CDN during the Recursive Request Routing > process > >> to rewrite an HTTP Adaptive Streaming manifest file. > [Ed: > >> should this be LOW?] > >> > >> c. Manifest rewrite by uCDN for URI Signing is considered as > optional feature in the ID-HAS, should the priority be LOW instead of MED= ? > >> > >> REQ-17 [MED] The CDNI Request-Routing interface should allow > the > >> Upstream CDN to re-sign the invariant portion of the > chunk > >> URIs embedded in the HTTP Adaptive Streaming manifest > file. > >> [Ed: should this be LOW?] > >> > >> d. Use of cookie for URI Signing is is considered as optional > feature in the ID-HAS, should the priority be LOW instead of MED? > >> > >> REQ-18 [MED] The CDNI Request-routing interface should allow > the use > >> of HTTP cookie to associate the chunks with the HTTP > Adaptive > >> Stream manifest file (which is verified by the URI > signature) > >> basedon the Authorization Group ID (which is an > identifier > >> used to correlate the manifest file to the related > chunks). > >> [Ed: should this be LOW?] > >> > >> e. LOW instead of MED priority? > >> > >> REQ-19 [MED] The CDNI Request-Routing interface may allow for > an > >> efficient method of transferring request routing > information > >> for multiple chunks from the Downstream CDN to the > Upstream > >> CDN as part of the recursive request routing process. > [Ed: > >> should this be LOW?] > >> > >> f. Based on ID-HAS and logging drafts, the following > requirement was introduced to log HAS content and customization of the > logging. > >> > >> REQ-20 [MED] The CDNI Request-Routing/Footprint and > Advertising > >> interface shall support advertisement of the following > >> capabilities: > >> > >> * support for customized CDNI Logging > >> > >> * support of Content Collection ID logging > >> > >> * support for Session ID logging > >> > >> 3. Removed CDNI Metadata Distribution Interface requirement. > >> > >> a. Based on the metadata draft, there is no need for dCDN to > indicate to the uCDN the result of delivering the metadata since the > "pull" or "triggered pull" model is used (i.e. dCDN request for metadata > from uCDN). > >> > >> META-13 [HIGH] The CDNI Metadata Distribution interface shall > > >> provide indication by the Downstream CDN to the Upstream CDN > > >> of whether the CDNI metadata (and corresponding future > > >> request redirections) is accepted or rejected. When > > >> rejected, the CDNI Metadata Distribution protocol Must allow > > >> the Downstream CDN to provide information about the cause of > > >> the rejection. > >> > >> 4. New CDNI Metadata Distribution Interface requirements > >> > >> a. Based on ID-HAS's recommendations, this is introduced. > >> > >> META-19 [HIGH] The CDNI Metadata interface shall provide > indication > >> of related content (e.g. HTTP Adaptive Bit Rate chunks= ) > by > >> the Content Collection ID (CCID) metadata. This could > be > >> used by the Downstream CDN for operations on the group > of > >> content. For example, this could potentially include: > > >> > >> * content acquisition for the entire set of files whe= n > one > >> piece of content is requested > >> > >> * local file management and storage bundles all the > files > >> for the content > >> > >> * purging the entire set of files associated with the > > >> content > >> > >> * logging of the delivery of the content for the > session > >> when at least one file in the set was delivered > >> > >> b. Based on the logging draft, this is introduced. > >> > >> META-20 [HIGH] The CDNI Metadata Distribution interface shall > >> support an OPTIONAL mechanism allowing the Upstream CDN > to > >> indicate to the Downstream CDN which CDNI Log fields ar= e > to > >> be provided for all, for specific sets of, or for > specific > >> content items delivered using HTTP. A CDNI > implementation > >> that does not support this optional CDNI Metadata > >> Distribution Interface mechanism MUST ignore this log > format > >> indication and generate CDNI logging format for HTTP > >> Adaptive Streaming using the default set of CDNI Loggin= g > > >> fields. > >> > >> c. Based on the ID-HAS's recommendations, this is introduced. > >> > >> META-21 [MED] The CDNI Metadata Distribution interface shall > allow > >> the Upstream CDN to signal to the Downstream CDN the > Content > >> Collection ID value for all, for specific sets of, or > for > >> specific content items delivered using HTTP. Whenever > the > >> Downstream CDN is instructed by the Upstream CDN to > report > >> the Content Collection ID field in the log records, the > > >> Downstream CDN is to use the value provided through the > CDNI > >> Metadata interface for the corresponding content. Note > the > >> Session ID field along with Content Collection ID may b= e > > >> used for HTTP Adaptive Streaming content. > >> > >> d. Based on ID-HAS's recommendations, this is introduced. > >> > >> META-22 [MED] The CDNI Metadata Distribution interface shall > allow > >> the Upstream CDN to signal to the Downstream CDN the > >> Authorization Group ID value for all the related HTTP > >> Adaptive Streamin content (i.e. manifest file and > chunks). > >> The authorization result of a content (e.g. manifest > file) > >> is transferred over to related content (e.g. chunks). > [Ed: > >> need to improve wording?] > >> > >> 5. Remove CDNI Logging Interface requirement > >> > >> a. It is deemed unnecessary for dCDN to obtain logs from uCDN, > which has access to all the logs for trouble-shooting and auditing. > >> > >> LOG-4 [HIGH] The CDNI Logging interface shall provide logging of > > >> distribution performed by the Upstream CDN as a result of > > >> acquisition request by the Downstream CDN. > >> > >> 6. Add CDNI Logging Interface requirements > >> > >> a. Based on the logging draft, this is introduced. > >> > >> LOG-17 [HIGH] The CDNI Logging interface shall support the > >> notification from Downstream CDN to Upstream CDN for the > > >> event that the logging retention duration or maximum siz= e > of > >> logging data has exceeded. > >> > >> b. Based on the ID-HAS, CCID is a field to report in the log. > Also, based on the logging draft, Session ID is another field needed in > the log. > >> > >> LOG-18 [MED] The CDNI Logging interface should support the > ability > >> for the Downstream CDN to include the Content Collection > ID > >> and Session ID fields in CDNI log entries generated for > HTTP > >> Adaptive Streaming content. This fields can be supporte= d > by > >> the "customizable" log format which is expected to be > defined > >> independently of HTTP Adaptive Streaming. > >> > >> Kent > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > >> Of internet-drafts@ietf.org > >> Sent: Saturday, February 23, 2013 1:16 PM > >> To: i-d-announce@ietf.org > >> Cc: cdni@ietf.org > >> Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Content Delivery Networks > Interconnection Working Group of the IETF. > >> > >> Title : Content Distribution Network Interconnection > (CDNI) Requirements > >> Author(s) : Kent Leung > >> Yiu Lee > >> Filename : draft-ietf-cdni-requirements-05.txt > >> Pages : 23 > >> Date : 2013-02-23 > >> > >> Abstract: > >> Content Delivery Networks (CDNs) are frequently used for large-scale > >> content delivery. As a result, existing CDN providers are scaling up > >> their infrastructure and many Network Service Providers (NSPs) are > >> deploying their own CDNs. There is a requirement for interconnecting > >> standalone CDNs so that their collective CDN footprint can be > >> leveraged for the end-to-end delivery of content from Content Service > >> Providers (CSPs) to end users. The Content Distribution Network > >> Interconnection (CDNI) working group has been chartered to develop an > >> interoperable and scalable solution for such CDN interconnection. > >> > >> The goal of the present document is to outline the requirements for > >> the solution and interfaces to be specified by the CDNI working > >> group. This draft is a work in progress and requirements may be > >> added, modified, or removed by the working group. > >> > >> Requirements Language > >> > >> The key words "High Priority", "Medium Priority" and "Low Priority" > >> in this document are to be interpreted in the following way: > >> > >> o "High Priority" indicates requirements that are to be supported by > >> the CDNI interfaces. A requirement is stated as "High Priority" > >> when it is established by the working group that it can be met > >> without compromising the targeted schedule for WG deliverables, or > >> when it is established that specifying a solution without meeting > >> this requirement would not make sense and would justify re- > >> adjusting the WG schedule, or both. This is tagged as "[HIGH]". > >> > >> o "Medium Priority" indicates requirements that are to be supported > >> by the CDNI interfaces unless the WG realizes at a later stage > >> that attempting to meet this requirement would compromise the > >> overall WG schedule (for example it would involve complexities > >> that would result in significantly delaying the deliverables). > >> This is tagged as "[MED]". > >> > >> o "Low Priority" indicates requirements that are to be supported by > >> the CDNI interfaces provided that dedicating WG resources to this > >> work does not prevent addressing "High Priority" and "Medium > >> Priority" requirements and that attempting to meet this > >> requirement would not compromise the overall WG schedule. This is > >> tagged as "[LOW]". > >> > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-cdni-requirements-05 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-05 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Tue Apr 9 09:14:55 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D7721F9409 for ; Tue, 9 Apr 2013 09:14: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=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTGbDSJxlqdK for ; Tue, 9 Apr 2013 09:14:53 -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 18D1321F93E8 for ; Tue, 9 Apr 2013 09:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30335; q=dns/txt; s=iport; t=1365524093; x=1366733693; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ked+H6GnWbwSjwF1q1XLZR1edQkT3Il1FtnVz08QvGY=; b=SQS5mUWHmArzkvCJmIF3zDsfsLh8iOkIfzZThdq/obMstlAeW1fs4Bgu OIhr7JTnPG9gIve6GeG3C4BYh5w2xIA2oP0oyBDCtPYz99dAcrLgJdyrM 9Ouc6qTavfErt3M54zVNQvzO+LPQPvjlNnh5KpQU9+dzxRRbJxcESg6Nq k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAKA9ZFGtJV2c/2dsb2JhbABRgzzBL4EVFnSCHwEBBQEBGCA0AgICBQUHBAIBCBEBAwEBAQoUCQcnCxQDBggCBAEJBA0Th3kHrkWQNI1TDwZ7MQcGglphA5gailWFGYMLgWsBBxcBBRg X-IronPort-AV: E=Sophos;i="4.87,439,1363132800"; d="scan'208";a="196737881" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 09 Apr 2013 16:13:28 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r39GDSc1001371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Apr 2013 16:13:28 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.24]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 11:13:28 -0500 From: "Kent Leung (kleung)" To: Kevin J Ma , "Francois Le Faucheur (flefauch)" Thread-Topic: Comments on draft-ietf-cdni-requirements-05.txt Thread-Index: AQHONIpwHLzh3hoU6kCD0dCNIDs+85jNEvRQgAD9c3A= Date: Tue, 9 Apr 2013 16:13:28 +0000 Message-ID: References: <291CC3F9E50E7641901A54E85D0977C665EFCE2334@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C665EFCE2334@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.123.195] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-ietf-cdni-requirements-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 16:14:55 -0000 Thanks Kevin.. I couldn't reference the draft yesterday to confirm. There w= ill be two requirements due to the different priority levels. Kent -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Monday, April 08, 2013 6:17 PM To: Kent Leung (kleung); Francois Le Faucheur (flefauch) Cc: cdni@ietf.org Subject: RE: Comments on draft-ietf-cdni-requirements-05.txt > In fact, does the "triggers" interface actually cope for that ? > Perhaps you can split the two bullets so they can have a different=20 > priority level. > > KL> ok. It's better to split the bullets and prioritize differently.=20 > KL> The > current triggers interface deals with delete only, AFAIK. the triggers draft covers invalidate... the invalidate trigger type is defined in sections 5.5.1 and 6.1.1, and an = example is provided in section 7.1.2. > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 > Of Kent Leung (kleung) > Sent: Monday, April 08, 2013 2:54 PM > To: Francois Le Faucheur (flefauch) > Cc: cdni@ietf.org > Subject: Re: [CDNi] Comments on draft-ietf-cdni-requirements-05.txt > > Hi Francois. Thanks for the thorough review. I'll incorporate your=20 > feedback. Just a few comments and clarification questions below. I=20 > should be able to publish the draft in a few days. > > -----Original Message----- > From: Francois Le Faucheur (flefauch) > Sent: Saturday, March 30, 2013 2:50 AM > To: Kent Leung (kleung) > Cc: cdni@ietf.org > Subject: Comments on draft-ietf-cdni-requirements-05.txt > > Hi Kent and all, > > In addition to the comment already discussed below, here are my=20 > remaining comments (as an Individual): > > > OLD: > " > GEN-4 [HIGH] The CDNI solution shall not require intra-CDN > information ... > " > NEW: > " > GEN-4 [HIGH] The CDNI solution shall not depend on intra-CDN > information ... > " > > KL> ok > > OLD: > " > GEN-5 [HIGH] The CDNI solution shall support delivery to the user > agent based on HTTP [RFC2616]. (Note that while delivery and > acquisition "data plane" protocols are out of the CDNI > solution scope, the CDNI solution "control plane" protocols > are expected to participate in enabling, selecting or > facilitating operations of such acquisition and delivery > protocols. Hence it is useful to state requirements on the > CDNI solution in terms of which acquisition and delivery > protocols). > > GEN-6 [HIGH] The CDNI solution shall support acquisition across > CDNs based on HTTP [RFC2616]. > " > NEW: > " > GEN-5 [HIGH] The CDNI solution shall support delivery to the user > agent based on HTTP [RFC2616]. > > GEN-6 [HIGH] The CDNI solution shall support acquisition across > CDNs based on HTTP [RFC2616]. > > (Note that while delivery and acquisition "data plane" protocols are=20 > out of the CDNI solution scope, the CDNI solution "control plane"=20 > protocols are expected to participate in enabling, selecting or=20 > facilitating operations of such acquisition and delivery protocols. =20 > Hence it is useful to state requirements on the CDNI solution in terms=20 > of which acquisition and delivery protocols). > " > (Rationale: the note applies to both GEN-5 and GEN-6) > > KL> ok. I've kept the note for GEN-5 and added " (The note above=20 > KL> applies > to this requirement too)" to GEN-6. Formatting remains consistent this=20 > way. > > Regarding: > " > GEN-13 Removed. > " > I suggest you just remove altogether the requirements that were=20 > dropped and renumber the following ones to avoid gaps. > > KL> ok. It was better to keep all the requirement numbers for=20 > KL> discussions > (i.e. clear reference) up to this point. Now we are ready for last call. > We'll clean up all the removed requirements. This means the authors of=20 > the interface drafts need to update their references to the=20 > requirements draft. I can create a mapping of the numbering changes=20 > between ver -05 to > -06 if that's helpful. What do you think? > > Regarding: > " > CNTL-1 [HIGH] The CDNI Control interface shall allow the Upstream > CDN to request that the Downstream CDN (and, if cascaded > CDNs are supported by the solution, that the potential > cascaded Downstream CDNs) perform the following actions on > an object or object set: > > * Mark an object or set of objects and/or its CDNI > metadata as "stale" and revalidate them before they are > delivered again > > * Delete an object or set of objects and/or its CDNI > metadata from the CDN surrogates and any storage. Only > the object(s) and CDNI metadata that pertain to the > requesting Upstream CDN are allowed to be purged. > " > It is clear to me that the 2nd bullet is a [HIGH]. > But it is not clear to me that the first bullet is really a [HIGH]. I=20 > see it as an optimisation, not a must-have. I'd rate it as a [MID] or [LO= W]. > In fact, does the "triggers" interface actually cope for that ? > Perhaps you can split the two bullets so they can have a different=20 > priority level. > > KL> ok. It's better to split the bullets and prioritize differently.=20 > KL> The > current triggers interface deals with delete only, AFAIK. > > > Regarding: > " > CNTL-3 [HIGH] The CDNI Control interface shall support initiation > and control by the Upstream CDN of pre-positioned CDNI > metadata acquisition by the Downstream CDN. > " > I thought we have agreed that pre-positioning would be a [MED] whether=20 > content or metadata. CNTL-4 is already a [MED]. I suggest making=20 > CNTL-3 a [MED] also. > > KL> ok. > > Regarding: > " > CNTL-10 [LOW] The CDNI Control interface may allow exchange and > negotiation of delivery authorization mechanisms to be > supported across the CDNs (e.g. URI signature based > validation). > " > This functionality has moved to the FCI. How about, you move this=20 > functionality with the rest of the text discussing the FCI requirements? > > KL> ok > > Regarding: > " > CNTL-12 [MED] The CDNI Control interface should allow for multiple > content items identified by a Content Collection ID to be > purged using a single Content Purge action. > " > I suggest moving this requirement up so it follows the first=20 > purge-related requirements i.e. place it right after CNTL-1. > > KL> ok > > Regarding Section 5: > I strongly recommend that: > * you split this into separate sections for RI and FCI. > * in each requirement, you mention the actual interface (i.e. RI=20 > or > FCI) instead of "the Request Routing Interface". > It will make it much easier to read, and much more useful so we know=20 > which requirements applies to which interface. > > KL> ok. Requirements will be renamed to RI-# and FCI-#. (note to self: > TODO) > > Regarding REQ-15 and "[Ed: chunk is treated as any content, is this=20 > needed?]" > I vote for keeping it in. Explicit is better. > > KL> ok > > Regarding REQ-16 and REQ-17: I vote for [LOW]. I see Manifest-file-=20 > Manipulation approaches as nice-to-allow but not [MED]. > > KL> ok > > Regarding REQ-19: it is a [MED] but you use "may". I think it shoudl=20 > say "should" for a [MED]. > BTW: at the very end of editing , you should probably do a pass and=20 > check the shall/should/may correspond to HIGH/MED/LOW in each and=20 > every requirement. e.g. there is also a mismatch in REQ-20. > > KL> ok (note to self: TODO) > > Regarding REQ-20: > The list of capabilities here is a little out of date (e.g. "support=20 > for customised CDNI logging" - which is dropped) and only covers the=20 > ones related to logging while it shoudl bring up the other ones (e.g.=20 > delivery protocol). Since the actual capabilities are discussed in the=20 > FCI semantics draft, I would suggest not trying to list specific=20 > capabilities in that requirement, and instead keep it high level and=20 > probably just list the types of capabilities (e.g. mention it needs to=20 > cover capabilities associated with logging, with distribution=20 > protocols, with acquisition protocols, etc..) > > KL> ok > > OLD: > " > META-7 [HIGH] The CDNI Metadata Distribution interface shall allow > the Upstream CDN to request addition and modification of > CDNI Metadata into the Downstream CDN. > " > NEW: > " > META-7 [HIGH] The CDNI Metadata Distribution interface (possibly in > conjunction with the CDNI Control interface) shall allow > the Upstream CDN to request addition and modification of > CDNI Metadata into the Downstream CDN. > " > > KL> ok > > > OLD: > " > META-8 [HIGH] The CDNI Metadata Distribution interface shall allow > removal of obsolete CDNI Metadata from the Downstream CDN > (this could, for example, be achieved via an explicit > removal request from the Upstream CDN or via expiration of a > Time-To-Live associated to the Metadata). > " > NEW: > " > META-8 [HIGH] The CDNI Metadata Distribution interface (possibly in > conjunction with the CDNI Control interface) shall allow > removal of obsolete CDNI Metadata from the Downstream CDN > (this could, for example, be achieved via an explicit > removal request from the Upstream CDN or via expiration of a > Time-To-Live associated to the Metadata). > " > > KL> ok > > OLD: > " > META-15 [HIGH] The CDNI Metadata interface shall be able to exchange > a set of well-accepted metadata elements with specified > semantics (e.g. start of time window, end of time window). > " > NEW: > " > META-15 [HIGH] The CDNI Metadata interface shall be able to exchange > a set of metadata elements with specified > semantics (e.g. start of time window, end of time window). > " > > KL> ok > > Regarding META-18: see thread below. > > KL> The thread below is about logging customization and directional > logging. Not clear about relationship to this requirement? > > > Regarding META-20: As documented in http://www.ietf.org/mail-=20 > archive/web/cdni/current/msg01375.html, it is felt that this=20 > requirement shoudl not be pursued for initial deliverables. Besides,=20 > there was no hard conclusion as to whether this would belong to MI or=20 > CI. This requirement should be a [MED] (instead of a [HIGH]) and I=20 > suggest you add a note indicating that there is still some thinking to=20 > be done to conclude whether this should really be MI or CI. > > KL> ok > > OLD: > " > LOG-1 [HIGH] The CDNI logging architecture and interface shall > ensure reliable logging of CDNI events. > " > NEW: > " > LOG-1 [HIGH] The CDNI logging architecture and interface shall > ensure reliable transfer of CDNI logging information across=20 > CDNs. > " > > KL> ok > > OLD: > " > LOG-7 [HIGH] The CDNI Logging interface shall define a log file > format and a set of fields to be exported through the Logging > protocol, with some granularity (e.g. On a per content type > basis). > " > NEW: > " > LOG-7 [HIGH] The CDNI Logging interface shall define a log file > format and a set of fields to be exported for various CDNI=20 > logging events. > " > > KL> ok > > re LOG-8: > s/mechanisms/mechanism/ > > > re LOG-14: > This requirement should be removed since it is already covered by=20 > another requirement on the CI. > > KL> ok > > OLD: > " > LOG-17 [HIGH] The CDNI Logging interface shall support the > notification from Downstream CDN to Upstream CDN for the > event that the logging retention duration or maximum size of > logging data has exceeded. > " > NEW: > " > LOG-17 [HIGH] The CDNI Logging interface shall allow a CDN to notify=20 > another CDN about which CDNI logging information is available for=20 > transfer (and/or no longer available, say because it exceeded some=20 > logging retention period or some logging retention volume). > " > Rationale: The current wording was overly prescriptive. I think the=20 > key point is that the CDNs should inform each other about which info=20 > can be obtained. > > KL> ok > > OLD: > " > LOG-18 [MED] The CDNI Logging interface should support the ability > for the Downstream CDN to include the Content Collection ID > and Session ID fields in CDNI log entries generated for HTTP > Adaptive Streaming content. This fields can be supported by > the "customizable" log format which is expected to be defined > independently of HTTP Adaptive Streaming. > " > NEW: > " > LOG-18 [MED] The CDNI Logging interface should support the ability > for the Downstream CDN to include the Content Collection ID > and Session ID fields in CDNI log entries generated for HTTP > Adaptive Streaming content. > " > Rationale: again custom log likely not supported initially. > > KL> ok > > Kent > > > > Francois > > On 12 Mar 2013, at 17:53, Kent Leung (kleung) wrote: > > > Hi Francois. Comments below in "KL>". > > > > -----Original Message----- > > From: Francois Le Faucheur (flefauch) > > Sent: Tuesday, March 12, 2013 7:08 AM > > To: Kent Leung (kleung) > > Cc: cdni@ietf.org > > Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt > > > > Kent and all, > > > > I have received consistent feed-back from two CDN operators and a > Content Provider that the CDNI solution ought to support: > > *A* enforcement of caching directives by dCDN that are different=20 > > to > the ones signalled in the HTTP headers > > *B* choice of ignoring/factoring query string in dCDN caching > > *C* rate-pacing by the dCDN on behalf of the uCDN (for=20 > > Progressive > > Download) > > > > *A* and *B* are already mostly covered in META-18 but it is listed=20 > > as > [LOW]. I would recommend we raise META-18 to [MED]. > > > > KL> That sounds reasonable to me. Unless others object, this=20 > > KL> requirement > will be set to MED priority in the next version. > > > > I don't think *C* is covered. I would recommend we add rate-pacing=20 > > as a > 3rd example of "surrogate cache behaviour" in META-18. > > > > KL> I can see some value of this feature. I'll see how the debate > settles before updating the draft. > > > > I will bring this up in the CDNI session today, but wanted to give=20 > > folks > some heads-up. > > > > KL> Thanks for the heads up. > > > > I also have other comments on -05 which I will either pass on to=20 > > Kent > directly or post on the list. > > > > KL> Thanks. > > > > Kent > > > > > > Cheers > > > > Francois > > > > > > > > " > > META-18 [LOW] The CDNI Metadata Distribution interface may allow > > signaling of CDNI-relevant surrogate cache behavior > > parameters. For example, this could potentially include: > > > > * control of whether the query string of HTTP URI is to be > > ignored by surrogate cache > > > > * content revalidation parameters (e.g. TTL) > > " > > > > > > On 6 Mar 2013, at 18:08, Kent Leung (kleung) wrote: > > > >> Hi folks. The requirements draft was updated based on the feedback=20 > >> from > the authors of the following drafts: draft-brandenburg-cdni-has=20 > (ID-HAS), draft-bertrand-cdni-logging, draft-ietf-cdni-metadata,=20 > draft-ietf-cdni- logging. > >> > >> In preparation for the next WG session, the edits were published in=20 > >> the > draft for review. Please provide your comments to the list of=20 > requirement changes below. Thanks. > >> > >> 1. New CDNI Control Interface requirement > >> > >> a. Based on recommendations in ID-HAS, CCID is introduced=20 > >> for > HAS content without the need for HAS-aware CDN. > >> > >> CNTL-12 [MED] The CDNI Control interface should allow for > multiple > >> content items identified by a Content Collection ID=20 > >> to > be > >> purged using a single Content Purge action. > >> > >> 2. New CDNI Request Routing Interface requirements > >> > >> a. This is an explicit requirement for RRI to support=20 > >> per-chunk > request routing. Since the chunk is same as any content, it's not=20 > clear if the requirement is needed? > >> > >> REQ-15 [HIGH] The CDNI Request-Routing interface shall=20 > >> allow > for > >> per-chunk request routing of HTTP Adaptive Streaming > content. > >> [Ed: chunk is treated as any content, is this=20 > >> needed?] > >> > >> b. Manifest rewrite by uCDN is considered as optional=20 > >> feature > in the ID-HAS, should the priority be LOW instead of MED? > >> > >> REQ-16 [MED] The CDNI Request-Routing interface should=20 > >> allow > the > >> Upstream CDN to use the information conveyed by the > >> Downstream CDN during the Recursive Request Routing > process > >> to rewrite an HTTP Adaptive Streaming manifest file. > [Ed: > >> should this be LOW?] > >> > >> c. Manifest rewrite by uCDN for URI Signing is considered=20 > >> as > optional feature in the ID-HAS, should the priority be LOW instead of MED= ? > >> > >> REQ-17 [MED] The CDNI Request-Routing interface should=20 > >> allow > the > >> Upstream CDN to re-sign the invariant portion of the > chunk > >> URIs embedded in the HTTP Adaptive Streaming manifest > file. > >> [Ed: should this be LOW?] > >> > >> d. Use of cookie for URI Signing is is considered as=20 > >> optional > feature in the ID-HAS, should the priority be LOW instead of MED? > >> > >> REQ-18 [MED] The CDNI Request-routing interface should=20 > >> allow > the use > >> of HTTP cookie to associate the chunks with the HTTP > Adaptive > >> Stream manifest file (which is verified by the URI > signature) > >> basedon the Authorization Group ID (which is an > identifier > >> used to correlate the manifest file to the related > chunks). > >> [Ed: should this be LOW?] > >> > >> e. LOW instead of MED priority? > >> > >> REQ-19 [MED] The CDNI Request-Routing interface may allow=20 > >> for > an > >> efficient method of transferring request routing > information > >> for multiple chunks from the Downstream CDN to the > Upstream > >> CDN as part of the recursive request routing process. > [Ed: > >> should this be LOW?] > >> > >> f. Based on ID-HAS and logging drafts, the following > requirement was introduced to log HAS content and customization of the=20 > logging. > >> > >> REQ-20 [MED] The CDNI Request-Routing/Footprint and > Advertising > >> interface shall support advertisement of the following > >> capabilities: > >> > >> * support for customized CDNI Logging > >> > >> * support of Content Collection ID logging > >> > >> * support for Session ID logging > >> > >> 3. Removed CDNI Metadata Distribution Interface requirement. > >> > >> a. Based on the metadata draft, there is no need for dCDN=20 > >> to > indicate to the uCDN the result of delivering the metadata since the=20 > "pull" or "triggered pull" model is used (i.e. dCDN request for=20 > metadata from uCDN). > >> > >> META-13 [HIGH] The CDNI Metadata Distribution interface shall > > >> provide indication by the Downstream CDN to the Upstream=20 > >> CDN > > >> of whether the CDNI metadata (and corresponding future > > >> request redirections) is accepted or rejected. When > > >> rejected, the CDNI Metadata Distribution protocol Must=20 > >> allow > > >> the Downstream CDN to provide information about the cause=20 > >> of > > >> the rejection. > >> > >> 4. New CDNI Metadata Distribution Interface requirements > >> > >> a. Based on ID-HAS's recommendations, this is introduced. > >> > >> META-19 [HIGH] The CDNI Metadata interface shall provide > indication > >> of related content (e.g. HTTP Adaptive Bit Rate=20 > >> chunks) > by > >> the Content Collection ID (CCID) metadata. This=20 > >> could > be > >> used by the Downstream CDN for operations on the=20 > >> group > of > >> content. For example, this could potentially include: > > >> > >> * content acquisition for the entire set of files whe= n > one > >> piece of content is requested > >> > >> * local file management and storage bundles all the > files > >> for the content > >> > >> * purging the entire set of files associated with the > > >> content > >> > >> * logging of the delivery of the content for the > session > >> when at least one file in the set was delivered > >> > >> b. Based on the logging draft, this is introduced. > >> > >> META-20 [HIGH] The CDNI Metadata Distribution interface shall > >> support an OPTIONAL mechanism allowing the Upstream=20 > >> CDN > to > >> indicate to the Downstream CDN which CDNI Log fields=20 > >> are > to > >> be provided for all, for specific sets of, or for > specific > >> content items delivered using HTTP. A CDNI > implementation > >> that does not support this optional CDNI Metadata > >> Distribution Interface mechanism MUST ignore this=20 > >> log > format > >> indication and generate CDNI logging format for HTTP > >> Adaptive Streaming using the default set of CDNI=20 > >> Logging > > >> fields. > >> > >> c. Based on the ID-HAS's recommendations, this is introduced. > >> > >> META-21 [MED] The CDNI Metadata Distribution interface shall > allow > >> the Upstream CDN to signal to the Downstream CDN the > Content > >> Collection ID value for all, for specific sets of,=20 > >> or > for > >> specific content items delivered using HTTP. =20 > >> Whenever > the > >> Downstream CDN is instructed by the Upstream CDN to > report > >> the Content Collection ID field in the log records,=20 > >> the > > >> Downstream CDN is to use the value provided through=20 > >> the > CDNI > >> Metadata interface for the corresponding content. =20 > >> Note > the > >> Session ID field along with Content Collection ID=20 > >> may be > > >> used for HTTP Adaptive Streaming content. > >> > >> d. Based on ID-HAS's recommendations, this is introduced. > >> > >> META-22 [MED] The CDNI Metadata Distribution interface shall > allow > >> the Upstream CDN to signal to the Downstream CDN the > >> Authorization Group ID value for all the related HTTP > >> Adaptive Streamin content (i.e. manifest file and > chunks). > >> The authorization result of a content (e.g. manifest > file) > >> is transferred over to related content (e.g. chunks). > [Ed: > >> need to improve wording?] > >> > >> 5. Remove CDNI Logging Interface requirement > >> > >> a. It is deemed unnecessary for dCDN to obtain logs from=20 > >> uCDN, > which has access to all the logs for trouble-shooting and auditing. > >> > >> LOG-4 [HIGH] The CDNI Logging interface shall provide logging of > > >> distribution performed by the Upstream CDN as a result of > > >> acquisition request by the Downstream CDN. > >> > >> 6. Add CDNI Logging Interface requirements > >> > >> a. Based on the logging draft, this is introduced. > >> > >> LOG-17 [HIGH] The CDNI Logging interface shall support the > >> notification from Downstream CDN to Upstream CDN for=20 > >> the > > >> event that the logging retention duration or maximum=20 > >> size > of > >> logging data has exceeded. > >> > >> b. Based on the ID-HAS, CCID is a field to report in the log. > Also, based on the logging draft, Session ID is another field needed=20 > in the log. > >> > >> LOG-18 [MED] The CDNI Logging interface should support the > ability > >> for the Downstream CDN to include the Content=20 > >> Collection > ID > >> and Session ID fields in CDNI log entries generated=20 > >> for > HTTP > >> Adaptive Streaming content. This fields can be=20 > >> supported > by > >> the "customizable" log format which is expected to be > defined > >> independently of HTTP Adaptive Streaming. > >> > >> Kent > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 > >> Behalf Of internet-drafts@ietf.org > >> Sent: Saturday, February 23, 2013 1:16 PM > >> To: i-d-announce@ietf.org > >> Cc: cdni@ietf.org > >> Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the Content Delivery Networks > Interconnection Working Group of the IETF. > >> > >> Title : Content Distribution Network Interconnection > (CDNI) Requirements > >> Author(s) : Kent Leung > >> Yiu Lee > >> Filename : draft-ietf-cdni-requirements-05.txt > >> Pages : 23 > >> Date : 2013-02-23 > >> > >> Abstract: > >> Content Delivery Networks (CDNs) are frequently used for=20 > >> large-scale content delivery. As a result, existing CDN providers=20 > >> are scaling up their infrastructure and many Network Service=20 > >> Providers (NSPs) are deploying their own CDNs. There is a=20 > >> requirement for interconnecting standalone CDNs so that their=20 > >> collective CDN footprint can be leveraged for the end-to-end=20 > >> delivery of content from Content Service Providers (CSPs) to end=20 > >> users. The Content Distribution Network Interconnection (CDNI)=20 > >> working group has been chartered to develop an interoperable and scala= ble solution for such CDN interconnection. > >> > >> The goal of the present document is to outline the requirements=20 > >> for the solution and interfaces to be specified by the CDNI working=20 > >> group. This draft is a work in progress and requirements may be=20 > >> added, modified, or removed by the working group. > >> > >> Requirements Language > >> > >> The key words "High Priority", "Medium Priority" and "Low Priority" > >> in this document are to be interpreted in the following way: > >> > >> o "High Priority" indicates requirements that are to be supported by > >> the CDNI interfaces. A requirement is stated as "High Priority" > >> when it is established by the working group that it can be met > >> without compromising the targeted schedule for WG deliverables, or > >> when it is established that specifying a solution without meeting > >> this requirement would not make sense and would justify re- > >> adjusting the WG schedule, or both. This is tagged as "[HIGH]". > >> > >> o "Medium Priority" indicates requirements that are to be supported > >> by the CDNI interfaces unless the WG realizes at a later stage > >> that attempting to meet this requirement would compromise the > >> overall WG schedule (for example it would involve complexities > >> that would result in significantly delaying the deliverables). > >> This is tagged as "[MED]". > >> > >> o "Low Priority" indicates requirements that are to be supported by > >> the CDNI interfaces provided that dedicating WG resources to this > >> work does not prevent addressing "High Priority" and "Medium > >> Priority" requirements and that attempting to meet this > >> requirement would not compromise the overall WG schedule. This is > >> tagged as "[LOW]". > >> > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements > >> > >> There's also a htmlized version available at: > >> http://tools.ietf.org/html/draft-ietf-cdni-requirements-05 > >> > >> A diff from the previous version is available at: > >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-05 > >> > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From internet-drafts@ietf.org Tue Apr 9 10:52:57 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5E3921F9608; Tue, 9 Apr 2013 10:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.765 X-Spam-Level: X-Spam-Status: No, score=-101.765 tagged_above=-999 required=5 tests=[AWL=0.835, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbubRJgl61VX; Tue, 9 Apr 2013 10:52:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6DF21F9593; Tue, 9 Apr 2013 10:52:54 -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.43.p4 Message-ID: <20130409175254.29406.34599.idtracker@ietfa.amsl.com> Date: Tue, 09 Apr 2013 10:52:54 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-06.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, 09 Apr 2013 17:52:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-06.txt Pages : 24 Date : 2013-04-09 Abstract: Content Delivery Networks (CDNs) are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. There is a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. This draft is a work in progress and requirements may be added, modified, or removed by the working group. Requirements Language The key words "High Priority", "Medium Priority" and "Low Priority" in this document are to be interpreted in the following way: o "High Priority" indicates requirements that are to be supported by the CDNI interfaces. A requirement is stated as "High Priority" when it is established by the working group that it can be met without compromising the targeted schedule for WG deliverables, or when it is established that specifying a solution without meeting this requirement would not make sense and would justify re- adjusting the WG schedule, or both. This is tagged as "[HIGH]". o "Medium Priority" indicates requirements that are to be supported by the CDNI interfaces unless the WG realizes at a later stage that attempting to meet this requirement would compromise the overall WG schedule (for example it would involve complexities that would result in significantly delaying the deliverables). This is tagged as "[MED]". o "Low Priority" indicates requirements that are to be supported by the CDNI interfaces provided that dedicating WG resources to this work does not prevent addressing "High Priority" and "Medium Priority" requirements and that attempting to meet this requirement would not compromise the overall WG schedule. This is tagged as "[LOW]". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-requirements-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kleung@cisco.com Tue Apr 9 11:54:33 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495DB21F9323 for ; Tue, 9 Apr 2013 11:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h203hVt0HHsx for ; Tue, 9 Apr 2013 11:54:32 -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 5B32721F9030 for ; Tue, 9 Apr 2013 11:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4450; q=dns/txt; s=iport; t=1365533672; x=1366743272; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SvKDEo/tK3Q1n3S/605YmWCgpVvh2c2ZO3vdCk8kf1c=; b=Di5mjLoP5H6/EA3SjnhQnqxqmUfs1sbBCpcyFbhU7ZcGyNyuUKWopATq Wj8PX9eNMMZHy25NEkz7pQoql4VsMMeuv8Sgk9MSMMgklRZ7PRSKMEZHm qSyuzFei32cvOWpA4aE04Ows4+ZK60oYrxnCN3GvdydYyri8iY8ye9oJk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAPZiZFGtJXHA/2dsb2JhbABRgwY2RMBygRcWdIIfAQEBBAEBATc0AgQRBAIBCBEEAQELFAkHJwsUCQgCBBMIARKHeAEHBa5QkDeOYyYSBoJaYQOYGo9ugwuCKA X-IronPort-AV: E=Sophos;i="4.87,441,1363132800"; d="scan'208";a="196810716" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 09 Apr 2013 18:54:32 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r39IsVi1011508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Apr 2013 18:54:31 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.24]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 13:54:30 -0500 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-requirements-06.txt Thread-Index: AQHONUsZ0gd1vvHobkiqAdmRZm+1EJjOOVNw Date: Tue, 9 Apr 2013 18:54:29 +0000 Message-ID: References: <20130409175254.29406.34599.idtracker@ietfa.amsl.com> In-Reply-To: <20130409175254.29406.34599.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.69.41.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-requirements-06.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, 09 Apr 2013 18:54:33 -0000 Hi. This version incorporated the extensive comments from Francois. The CDN= I Request Routing Interface section was split into two: CDNI request routin= g/Redirection Interface and CDNI request routing/Footprint & Capabilities a= dvertisement Interface. The labels were changed to adhere to the new acrony= ms (i.e. CI, MI, RI, FCI, LI). Some of the numbering changed to reflect rem= oval of some requirements and placement into the right sections. There is a= table to reference the requirements between versions. I would suggest that= authors of the CDNI interface specs update their reference to requirements= based on the new label and number. I just noticed an editorial nit for MI-21. That will be fixed for review co= mments during WGLC. Kent -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Tuesday, April 09, 2013 10:53 AM To: i-d-announce@ietf.org Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-06.txt Pages : 24 Date : 2013-04-09 Abstract: Content Delivery Networks (CDNs) are frequently used for large-scale content delivery. As a result, existing CDN providers are scaling up their infrastructure and many Network Service Providers (NSPs) are deploying their own CDNs. There is a requirement for interconnecting standalone CDNs so that their collective CDN footprint can be leveraged for the end-to-end delivery of content from Content Service Providers (CSPs) to end users. The Content Distribution Network Interconnection (CDNI) working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. This draft is a work in progress and requirements may be added, modified, or removed by the working group. Requirements Language The key words "High Priority", "Medium Priority" and "Low Priority" in this document are to be interpreted in the following way: o "High Priority" indicates requirements that are to be supported by the CDNI interfaces. A requirement is stated as "High Priority" when it is established by the working group that it can be met without compromising the targeted schedule for WG deliverables, or when it is established that specifying a solution without meeting this requirement would not make sense and would justify re- adjusting the WG schedule, or both. This is tagged as "[HIGH]". o "Medium Priority" indicates requirements that are to be supported by the CDNI interfaces unless the WG realizes at a later stage that attempting to meet this requirement would compromise the overall WG schedule (for example it would involve complexities that would result in significantly delaying the deliverables). This is tagged as "[MED]". o "Low Priority" indicates requirements that are to be supported by the CDNI interfaces provided that dedicating WG resources to this work does not prevent addressing "High Priority" and "Medium Priority" requirements and that attempting to meet this requirement would not compromise the overall WG schedule. This is tagged as "[LOW]". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-requirements-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Thu Apr 11 02:21:13 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C30B21F8EB2 for ; Thu, 11 Apr 2013 02:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sInj-EqxyfYN for ; Thu, 11 Apr 2013 02:21:01 -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 4AA5F21F8E34 for ; Thu, 11 Apr 2013 02:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2366; q=dns/txt; s=iport; t=1365672061; x=1366881661; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GXQ3+ewp10fmLVVQVrlPUXGyldoFzdE+uIQUAdca20E=; b=ZgKqCnZolIxCO/j9nAAIWr8CzeGrTYNVegTGxUpQV6OT55ilXUNDUhIO LPD6NPauGggCugOzmZx/BakzCQoUW/5LGU3SIYbC4bk2hjBn01W9acwR7 fFZYPxQ8sMBXXrkArBecXgtahDEnqyb6fHr5xkdPaX48MQ7PfkIVHH+Gj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAGR/ZlGtJXHA/2dsb2JhbABQgwY2wUuBARZ0giABAQRyBxACAQgEAR0dBzIUEQIEDgUIAYgLDL5IjWSBATEHgmBhA6gOgwuBczU X-IronPort-AV: E=Sophos;i="4.87,454,1363132800"; d="scan'208,217";a="197489293" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 11 Apr 2013 09:20:59 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3B9Kxdc021696 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Apr 2013 09:20:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.181]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 04:20:58 -0500 From: "Francois Le Faucheur (flefauch)" To: "Kent Leung (kleung)" Thread-Topic: Comments on draft-ietf-cdni-requirements-05.txt Thread-Index: AQHOLSv9aBLjbrhBMEqVd2LAvpipbQ== Date: Thu, 11 Apr 2013 09:20:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D3E4E70xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Comments on draft-ietf-cdni-requirements-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 09:21:13 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D3E4E70xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Kent, Thanks for following up on all the comments. One clarification below: On 8 Apr 2013, at 20:54, Kent Leung (kleung) > wrote: ... Regarding META-18: see thread below. KL> The thread below is about logging customization and directional logging= . Not clear about relationship to this requirement? I was referring to http://www.ietf.org/mail-archive/web/cdni/current/msg014= 27.html (which was embedded in the message). This indeed relates to META-18. But the way you addressed that in -06 (i.e.= MI-17) is all fine by me, so we are all good. Thanks Francois --_000_FC236DA6F2DA77449EF2D02DF4471A8D3E4E70xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <933622D57621384AA3830BDDBDBD2026@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hello Kent,

Thanks for following up on all the comments. One clarification below:<= /div>

On 8 Apr 2013, at 20:54, Kent Leung (kleung) <kleung@cisco.com> wrote:
...

Regarding META-18: see thread below.

KL> The thread below is about logging customization and directional logg= ing. Not clear about relationship to this requirement?


I was referring to http://www.ietf.org/mail-archive/web/cdni/cur= rent/msg01427.html  (which was embedded in the message).
This indeed relates to META-18. But the way you addressed that in -06 = (i.e. MI-17) is all fine by me, so we are all good.

Thanks

Francois
--_000_FC236DA6F2DA77449EF2D02DF4471A8D3E4E70xmbrcdx10ciscocom_-- From flefauch@cisco.com Thu Apr 11 09:48:10 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA08721F8F44 for ; Thu, 11 Apr 2013 09:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NGy6Z4gGdJ4N for ; Thu, 11 Apr 2013 09:48:09 -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 71D5A21F8F3C for ; Thu, 11 Apr 2013 09:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1667; q=dns/txt; s=iport; t=1365698889; x=1366908489; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7vcMB3lmEP4yC+aFnLqDNIz6CMJ/w7Jsbj35MFJ4pKQ=; b=W4qVHBg9ztc6SAP05/6cGXw9qcSwpMQIo2Sl5yMp3vCkRjTcNa5l6nWh OKt4JmOmXKCvRGFtoAEi5QochH8nzxWfk1ZSlDPVsq4ZIO28oAnpJ8dhS 6yboPP1psPGmBouF18pw7TEig4ValO1DrsFMHSxXmU7d7Nxd+Edh1eP23 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAnoZlGtJXG+/2dsb2JhbABQgwbBfoEFFnSCHwEBAQMBOj8FBwQCAQgRBAEBCxQQMh0IAgQOBQiIBga9bI5jAiYLBwaCWmEDqBGBVYE2gig X-IronPort-AV: E=Sophos;i="4.87,456,1363132800"; d="scan'208";a="197701388" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 11 Apr 2013 16:48:09 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3BGm8aX000556 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Apr 2013 16:48:08 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.181]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 11:48:08 -0500 From: "Francois Le Faucheur (flefauch)" To: "Matt Caulfield (mcaulfie)" Thread-Topic: Incorporating text on Metadata Rewrite in cdni-framework before it goes to WG Last Call Thread-Index: AQHONrw2A7Kdfst5W0aRK62kifzV6pjRIKlAgABuYAA= Date: Thu, 11 Apr 2013 16:48:08 +0000 Message-ID: References: <166EBB70C264A9479E459B01B1BA6C921037213C@xmb-aln-x03.cisco.com> In-Reply-To: <166EBB70C264A9479E459B01B1BA6C921037213C@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.49.80.13] Content-Type: text/plain; charset="us-ascii" Content-ID: <4CAF3D61C01E4E4C9FC5EC5BB817C089@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "draft-ietf-cdni-framework@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Incorporating text on Metadata Rewrite in cdni-framework before it goes to WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 16:48:10 -0000 Thanks Matt. (ccing the WG which I intended to do in the first place). Francois On 11 Apr 2013, at 17:17, "Matt Caulfield (mcaulfie)" wrote: > Hi Francois, >=20 > Larry contacted me earlier this week and I pointed him to Ben.=20 >=20 > To recap: Ben will need a couple more weeks to work on the text. Larry ma= y have time sooner, so Ben will be providing the text as-is to Larry.=20 >=20 > Matt >=20 > -----Original Message----- > From: Francois Le Faucheur (flefauch)=20 > Sent: Thursday, April 11, 2013 9:55 AM > To: draft-ietf-cdni-framework@tools.ietf.org; draft-ietf-cdni-metadata@to= ols.ietf.org > Cc: Francois Le Faucheur (flefauch) > Subject: Incorporating text on Metadata Rewrite in cdni-framework before = it goes to WG Last Call >=20 > Authors of cdni-framework and cdni-metadata, >=20 > Following up on the following point from IETF-86 CDNI WG Minutes: > " > - francois: re metadata rewriting: it is something a CDN needs to do, but= it does not affect the interfaces themselves > - ben: where is the correct place to document it? > - kevin ma: since it affects multiple interfaces should it be in the fram= ework doc? > - francois: yes. it is not controversial, just something that needs docu= mented > - ben: existing text may not be fully baked > - francois: provide the text on metadata rewrite and work with Larry to g= eneralise it (to other interfaces) and have it included in framework. > " >=20 > Can you update us on where that is? > Do you want to circulate some draft text for quick review before incorpor= ating in cdni-framework? >=20 > Thanks >=20 > Francois From flefauch@cisco.com Thu Apr 11 09:55:30 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C912421F8FA5 for ; Thu, 11 Apr 2013 09:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeVBXKNmV-6k for ; Thu, 11 Apr 2013 09:55:27 -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 8CD4821F8F7F for ; Thu, 11 Apr 2013 09:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6111; q=dns/txt; s=iport; t=1365699326; x=1366908926; h=from:to:subject:date:message-id:references:mime-version; bh=n29auhWmbYiF6qWaajocagZSWYXEWdSk7hDHOlY3C5E=; b=H/oBgPnVdf40OkdXP49mJS+8jC461BSN1bDAxZfWhBPkc6sYCzzCgZC9 3SxtTYIhkhO/7+aBn4mCyPmxWIdJmdvtNqJTYf2sucrMcBDJxfgttutxB kErIyYgG+/N2OlBsKr/ms1dvm1e1uJeiIfiKYwlEqM0PPxgYv6OT08RYx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAF7qZlGtJV2d/2dsb2JhbABQgwY2RMEEgQUWdIIfAQEBBIEJAgEZAwECCx0HMhQJCAIEEwgBiAsHBb1kjVSBESAGEQeCWmEDqBGDC4FzNQ X-IronPort-AV: E=Sophos;i="4.87,456,1363132800"; d="scan'208,217";a="197503028" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 11 Apr 2013 16:55:26 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3BGtOVZ023642 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Apr 2013 16:55:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.181]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 11:55:24 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: WG Last Call on draft-ietf-cdni-requirements-06.txt Thread-Index: AQHONtVcTTK3EhU+h0KHYCH7+69QVA== Date: Thu, 11 Apr 2013 16:55:24 +0000 Message-ID: References: <20130409175254.29406.52063.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.49.80.13] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D3E6AC5xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] WG Last Call on draft-ietf-cdni-requirements-06.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, 11 Apr 2013 16:55:31 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D3E6AC5xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This email initiates a CDNI WG Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-cdni-requirements-06.txt Please comment on the list on this document in view of publishing it as a S= tandards Track RFC from the CDNI WG. This Last Call will close on Friday April 26th. Francois & Daryl Begin forwarded message: Resent-From: > From: > Subject: New Version Notification - draft-ietf-cdni-requirements-06.txt Date: 9 April 2013 19:52:54 CEST Resent-To: >, >, >, > To: >, >, > A new version (-06) has been submitted for draft-ietf-cdni-requirements: http://www.ietf.org/internet-drafts/draft-ietf-cdni-requirements-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-06 IETF Secretariat. --_000_FC236DA6F2DA77449EF2D02DF4471A8D3E6AC5xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <33D070BA53A38B44A44674F6879495E6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Folks,

This email initiates a CDNI WG Last Call on:



Please comment on the list on this document in view of publishing it&n= bsp;as a Standards Track RFC from the CDNI WG.

This Last Call will close on Friday April 26th.

Francois & Daryl


Begin forwarded message:

Resent-From: <<= a href=3D"mailto:wg-alias-bounces@tools.ietf.org">wg-alias-bounces@tools.ie= tf.org>
From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: Ne= w Version Notification - draft-ietf-cdni-requirements-06.txt
Date: 9 Apr= il 2013 19:52:54 CEST
Resent-To: <<= a href=3D"mailto:kleung@cisco.com">kleung@cisco.com>, <yiu_lee@cable.comcast.com>, <<= a href=3D"mailto:d.malas@cablelabs.com">d.malas@cablelabs.com>, <flefauch@cisco.com>
To: <<= a href=3D"mailto:cdni-chairs@tools.ietf.org">cdni-chairs@tools.ietf.org= >, <dr= aft-ietf-cdni-requirements@tools.ietf.org>, <martin.stiemerling@nec= lab.eu>


A new version (-06) has been submitted for draft-ietf-cdni-requirements: http://www.ietf.org/internet-drafts/draft-ietf-cdni-requirements-0= 6.txt


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-06

IETF Secretariat.


--_000_FC236DA6F2DA77449EF2D02DF4471A8D3E6AC5xmbrcdx10ciscocom_-- From internet-drafts@ietf.org Fri Apr 12 00:56:35 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E551D21F8D11; Fri, 12 Apr 2013 00:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.173 X-Spam-Level: X-Spam-Status: No, score=-99.173 tagged_above=-999 required=5 tests=[AWL=-2.856, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_XBL=3.033, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFymtFISAisS; Fri, 12 Apr 2013 00:56:35 -0700 (PDT) Received: from jlonline.com (pip46.ptt.js.cn [61.155.13.222]) by ietfa.amsl.com (Postfix) with SMTP id E31D521F8D05; Fri, 12 Apr 2013 00:56:34 -0700 (PDT) Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm95167cd6f; Fri, 12 Apr 2013 16:02:20 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm265162dace; Mon, 08 Apr 2013 22:02:05 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Mon, 08 Apr 2013 22:02:05 +0800 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC92221F9516; Mon, 8 Apr 2013 06:55:33 -0700 (PDT) X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B2421F944A; Mon, 8 Apr 2013 06:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjbvJuutnGNv; Mon, 8 Apr 2013 06:55:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CCC21F949A; Mon, 8 Apr 2013 06:55:31 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130408135531.4819.8703.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 06:55:31 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: 1vFeMZ4B X-AIMC-AUTH: (null) X-AIMC-MAILFROM: internet-drafts@ietf.org Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-control-triggers-00.txt X-BeenThere: cdni@ietf.org Reply-To: internet-drafts@ietf.org 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 Apr 2013 07:56:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : CDNI Control Interface / Triggers Author(s) : Rob Murray Ben Niven-Jenkins Filename : draft-ietf-cdni-control-triggers-00.txt Pages : 36 Date : 2013-04-08 Abstract: This document describes the part of the CDN Interconnect Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it re-validate or purge metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-control-triggers There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-control-triggers-00 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 internet-drafts@ietf.org Mon Apr 15 04:51:49 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7317021F93D3; Mon, 15 Apr 2013 04:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.301 X-Spam-Level: X-Spam-Status: No, score=-101.301 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1m7-ti2fMlD; Mon, 15 Apr 2013 04:51:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2647921F93C5; Mon, 15 Apr 2013 04:51:48 -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.43.p4 Message-ID: <20130415115147.9824.22968.idtracker@ietfa.amsl.com> Date: Mon, 15 Apr 2013 04:51:47 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-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, 15 Apr 2013 11:51:49 -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 : Request Routing Redirection Interface for CDN Interconne= ction Author(s) : Wang Danhua Ben Niven-Jenkins He Xiaoyan Ge Chen Ni Wei Filename : draft-ietf-cdni-redirection-00.txt Pages : 22 Date : 2013-04-15 Abstract: The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream CDN that allows a upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e. the CDNI request routing/ Redirection Interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-redirection-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ben@niven-jenkins.co.uk Mon Apr 15 11:22:45 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E0721F95F9 for ; Mon, 15 Apr 2013 11:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X98ChfqJbJDj for ; Mon, 15 Apr 2013 11:22:45 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2194121F95EC for ; Mon, 15 Apr 2013 11:22:39 -0700 (PDT) Received: from [81.134.152.4] (helo=xxx.corp.velocix.com) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from ) id 1URo31-0003oC-Mn; Mon, 15 Apr 2013 19:22:36 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 15 Apr 2013 19:22:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <58C3F499-D6A5-4034-AF0F-9066096EBCD9@niven-jenkins.co.uk> References: <166EBB70C264A9479E459B01B1BA6C921037213C@xmb-aln-x03.cisco.com> To: Francois Le Faucheur (flefauch) X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "draft-ietf-cdni-framework@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Incorporating text on Metadata Rewrite in cdni-framework before it goes to WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:22:46 -0000 Francois, Larry, colleagues, The current text we have is in Appendix B of the Metadata draft, here: http://tools.ietf.org/html/draft-ietf-cdni-metadata-01#page-37 If Larry has time in the next couple of weeks he can lift the text = directly from the metadata draft & play with it. Ben On 11 Apr 2013, at 17:48, Francois Le Faucheur (flefauch) wrote: > Thanks Matt. >=20 > (ccing the WG which I intended to do in the first place). >=20 > Francois >=20 > On 11 Apr 2013, at 17:17, "Matt Caulfield (mcaulfie)" = > wrote: >=20 >> Hi Francois, >>=20 >> Larry contacted me earlier this week and I pointed him to Ben.=20 >>=20 >> To recap: Ben will need a couple more weeks to work on the text. = Larry may have time sooner, so Ben will be providing the text as-is to = Larry.=20 >>=20 >> Matt >>=20 >> -----Original Message----- >> From: Francois Le Faucheur (flefauch)=20 >> Sent: Thursday, April 11, 2013 9:55 AM >> To: draft-ietf-cdni-framework@tools.ietf.org; = draft-ietf-cdni-metadata@tools.ietf.org >> Cc: Francois Le Faucheur (flefauch) >> Subject: Incorporating text on Metadata Rewrite in cdni-framework = before it goes to WG Last Call >>=20 >> Authors of cdni-framework and cdni-metadata, >>=20 >> Following up on the following point from IETF-86 CDNI WG Minutes: >> " >> - francois: re metadata rewriting: it is something a CDN needs to do, = but it does not affect the interfaces themselves >> - ben: where is the correct place to document it? >> - kevin ma: since it affects multiple interfaces should it be in the = framework doc? >> - francois: yes. it is not controversial, just something that needs = documented >> - ben: existing text may not be fully baked >> - francois: provide the text on metadata rewrite and work with Larry = to generalise it (to other interfaces) and have it included in = framework. >> " >>=20 >> Can you update us on where that is? >> Do you want to circulate some draft text for quick review before = incorporating in cdni-framework? >>=20 >> Thanks >>=20 >> Francois >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Tue Apr 23 09:08:01 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3651121F9401 for ; Tue, 23 Apr 2013 09:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gO2mFvT7nmm9 for ; Tue, 23 Apr 2013 09:08:00 -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 4F3FB21F9684 for ; Tue, 23 Apr 2013 09:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3326; q=dns/txt; s=iport; t=1366733280; x=1367942880; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CKpAXAGjenSafZBDTmUfIdxAtNcMpFFCWfbOhZlDIaY=; b=Ws5I3t1kQkyV6kcFMNQKLMoD1rH5dTU5YCVow4V+RDK/WhtGtBuiK7bM TboFfPZWhkgk5f/5sUHxzBwSBM8evtx8mpWnzs8Rh9DjPu7Isy5UthnpM DCC2j5CZz9BX0KoG9FrZDbaIuP/SUfWogKi10radUj4jQ5JQVv7ZAvd6i M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFADWxdlGtJXHB/2dsb2JhbABRgwY2wRyBAxZ0gh8BAQEDATo/BQsCAQgiFBAyJQIEDgUIE4dzBq4CjnmOdQIxB4JoYQOoN4MOgig X-IronPort-AV: E=Sophos;i="4.87,534,1363132800"; d="scan'208";a="202021113" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 23 Apr 2013 16:07:59 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3NG7xJc007043 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Apr 2013 16:07:59 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.150]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Tue, 23 Apr 2013 11:07:59 -0500 From: "Francois Le Faucheur (flefauch)" To: "draft-ietf-cdni-framework@tools.ietf.org" Thread-Topic: Tweaking text in draft-ietf-cdni-framework before it goes to WG Last Call Thread-Index: AQHOQDy5B5O2CrJ7ekaaZnsd9l0jmg== Date: Tue, 23 Apr 2013 16:07:59 +0000 Message-ID: References: <347CB797-BAAA-41CA-AFCA-D783DCB4534A@cisco.com> In-Reply-To: <347CB797-BAAA-41CA-AFCA-D783DCB4534A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: <78FE48126E667144A90A26F845EA822D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Tweaking text in draft-ietf-cdni-framework before it goes to WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 16:08:01 -0000 Larry, You OK incorporating the suggestions below in the next rev of the framework= ? Thanks Francois PS: any progress re editing & incorporating the text from cdni-metadata pro= vided by Ben on "rewrite"? On 11 Apr 2013, at 15:42, Francois Le Faucheur wrote: > Larry, Bruce, >=20 > Following up on the following point (from IETF-86 CDNI WG Minutes): > " > - francois (as himself): need to tweak "check with me" support i.e. to cl= arify this might require protocol extension or protocol changes to support > - larry peterson (channeled via webex): ok with tweaking "check with me" = text > " >=20 > I believe the last 3 paragraphs of section "4.6 Metadata Interface" in cd= ni-framework-03 relate to that topic. >=20 > Regarding: > " > Fine-grain control over how the downstream CDN delivers content on > behalf of the upstream CDN is also possible. For example, by > including the X-Forwarded-For HTTP header with the conditional GET > request, the downstream CDN can report the end-user's IP address to > the upstream CDN, giving it an opportunity to control whether the > downstream CDN should serve the content to this particular end-user. > The upstream CDN would communicate its directive through its response > to the conditional GET. The downstream CDN can cache information for > a period of time specified by the upstream CDN, thereby reducing > control overhead. > " >=20 > 1) I recommend you also refer to the "Forwarded" header, which is the IET= F standardised version of X-Forwarded-For and refer to draft-ietf-appsawg-h= ttp-forwarded-10, "Forwarded HTTP Extension" that , as far as I can tell, i= s in RFC Editor queue. >=20 > 2) to be crystal clear, we may want to replace: > OLD: > " > The downstream CDN can cache information for > a period of time specified by the upstream CDN, thereby reducing > control overhead. > " > by > NEW: > " > The downstream CDN can cache information for > a period of time specified by the upstream CDN, thereby reducing > control overhead, but then preventing per request control during the co= rresponding caching period. > " >=20 >=20 >=20 > Regarding: > " > All of these in-band techniques serve to illustrate that uCDNs have > the option of enforcing some of their access control policies > themselves (at the expense of increased inter-CDN signaling load), > rather than delegating enforcement to dCDNs using the Metadata > Interface. As a consequence, the Metadata Interface should 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. > " >=20 > 1) I suggest replacing "the Metadata Interface should provide" by "the Me= tadata Interface could provide". (just to avoid suggesting this is placing = "requirements" on the solution. > 2) I suggest adding a sentence along the lines of "The realisation of suc= h in-band techniques over the various inter-CDN acquisition protocol (e.g. = HTTP) requires further investigation and may require small extensions or se= mantics re-definition of the acquisition protocol." >=20 > How does that sound? >=20 > Francois From lapeters@akamai.com Tue Apr 23 14:18:18 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1D9921F8D2E for ; Tue, 23 Apr 2013 14:18:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtisLy0ii9z5 for ; Tue, 23 Apr 2013 14:18:18 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id C5E1B21F8CE9 for ; Tue, 23 Apr 2013 14:18:17 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 10A9A165630; Tue, 23 Apr 2013 21:18:15 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 00EFB16556B; Tue, 23 Apr 2013 21:18:15 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub5.dfw01.corp.akamai.com [172.27.25.71]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id ED85C2FD5E; Tue, 23 Apr 2013 21:18:11 +0000 (GMT) Received: from USMBX2.msg.corp.akamai.com ([169.254.1.246]) by ustx2ex-cashub5.dfw01.corp.akamai.com ([172.27.25.71]) with mapi; Tue, 23 Apr 2013 16:18:11 -0500 From: "Peterson, Larry" To: "Francois Le Faucheur (flefauch)" Date: Tue, 23 Apr 2013 16:18:08 -0500 Thread-Topic: [CDNi] Tweaking text in draft-ietf-cdni-framework before it goes to WG Last Call Thread-Index: Ac5AaA7NMnSlsk3JRI+fX8SYKn+Bug== Message-ID: <037BD591-D040-485D-819C-00307C250786@akamai.com> References: <347CB797-BAAA-41CA-AFCA-D783DCB4534A@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail=_B989667C-B651-41B3-9AB0-4A5DA99E0A93"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "draft-ietf-cdni-framework@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] Tweaking text in draft-ietf-cdni-framework before it goes to WG Last Call X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 21:18:18 -0000 --Apple-Mail=_B989667C-B651-41B3-9AB0-4A5DA99E0A93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii These changes are all fine. --Larry On Apr 23, 2013, at 12:07 PM, Francois Le Faucheur (flefauch) wrote: > Larry, > You OK incorporating the suggestions below in the next rev of the = framework? > Thanks > Francois >=20 > PS: any progress re editing & incorporating the text from = cdni-metadata provided by Ben on "rewrite"? >=20 > On 11 Apr 2013, at 15:42, Francois Le Faucheur = wrote: >=20 >> Larry, Bruce, >>=20 >> Following up on the following point (from IETF-86 CDNI WG Minutes): >> " >> - francois (as himself): need to tweak "check with me" support i.e. = to clarify this might require protocol extension or protocol changes to = support >> - larry peterson (channeled via webex): ok with tweaking "check with = me" text >> " >>=20 >> I believe the last 3 paragraphs of section "4.6 Metadata Interface" = in cdni-framework-03 relate to that topic. >>=20 >> Regarding: >> " >> Fine-grain control over how the downstream CDN delivers content on >> behalf of the upstream CDN is also possible. For example, by >> including the X-Forwarded-For HTTP header with the conditional GET >> request, the downstream CDN can report the end-user's IP address to >> the upstream CDN, giving it an opportunity to control whether the >> downstream CDN should serve the content to this particular end-user. >> The upstream CDN would communicate its directive through its = response >> to the conditional GET. The downstream CDN can cache information = for >> a period of time specified by the upstream CDN, thereby reducing >> control overhead. >> " >>=20 >> 1) I recommend you also refer to the "Forwarded" header, which is the = IETF standardised version of X-Forwarded-For and refer to = draft-ietf-appsawg-http-forwarded-10, "Forwarded HTTP Extension" that , = as far as I can tell, is in RFC Editor queue. >>=20 >> 2) to be crystal clear, we may want to replace: >> OLD: >> " >> The downstream CDN can cache information for >> a period of time specified by the upstream CDN, thereby reducing >> control overhead. >> " >> by >> NEW: >> " >> The downstream CDN can cache information for >> a period of time specified by the upstream CDN, thereby reducing >> control overhead, but then preventing per request control during the = corresponding caching period. >> " >>=20 >>=20 >>=20 >> Regarding: >> " >> All of these in-band techniques serve to illustrate that uCDNs have >> the option of enforcing some of their access control policies >> themselves (at the expense of increased inter-CDN signaling load), >> rather than delegating enforcement to dCDNs using the Metadata >> Interface. As a consequence, the Metadata Interface should 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. >> " >>=20 >> 1) I suggest replacing "the Metadata Interface should provide" by = "the Metadata Interface could provide". (just to avoid suggesting this = is placing "requirements" on the solution. >> 2) I suggest adding a sentence along the lines of "The realisation of = such in-band techniques over the various inter-CDN acquisition protocol = (e.g. HTTP) requires further investigation and may require small = extensions or semantics re-definition of the acquisition protocol." >>=20 >> How does that sound? >>=20 >> Francois >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni --Apple-Mail=_B989667C-B651-41B3-9AB0-4A5DA99E0A93 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOPjCCBjYw ggUeoAMCAQICChsbaFcAAAAAAAQwDQYJKoZIhvcNAQEFBQAwGDEWMBQGA1UEAxMNQWthbWFpUEtJ Um9vdDAeFw0wOTA2MDMxMzE2MjFaFw0xOTA2MDMxMzI2MjFaMF4xEzARBgoJkiaJk/IsZAEZFgNj b20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQD ExBBa2FtYWlQS0lJc3N1aW5nMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoqPGGQN5 Xz5QhjrAOiR5ZeKJ877eOxX2Ais/T5cLkVeRoJCv18uNcEhuRqbDl9G47784PzZi8nkjNbblwyXg 8ZSweWnz1en5ZeDMdO6XQ8eQrKGMJ2FN70WUbW8uDJRw6oGcnsLvcFiN3lKRi/RdSSuO649Tkfzq +A9zFcxABosmmYDCSJ1+B6noMarjHG62AjwjPotnJo95wR7raXs+JRDsBVPXazas8aPduNyN/yBN /ianrjc/AKi2vzRETb98qvv3h2GWdif7nBew1UN2dIKmImH3AA5djlfpjU4NtP+XCoBHUtaLg7Np i7+GsYLcmB0b63L02cs9QCXA4oOeawIDAQABo4IDOjCCAzYwDwYDVR0TAQH/BAUwAwEB/zAdBgNV HQ4EFgQUB+y0jq9nhlSI772zFFdJz4JMvxQwCwYDVR0PBAQDAgGGMBAGCSsGAQQBgjcVAQQDAgEC MCMGCSsGAQQBgjcVAgQWBBSoJ9lbQyx7FwMht3LPL4u8ambeJDAZBgkrBgEEAYI3FAIEDB4KAFMA dQBiAEMAQTAfBgNVHSMEGDAWgBTYPTvz/hw6QnfgXMovZhPk2qAFDDCCATAGA1UdHwSCAScwggEj MIIBH6CCARugggEXhiJodHRwOi8vYWthbWFpcGtpL0FrYW1haVBLSVJvb3QuY3JshjhodHRwOi8v YWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNvbS9Ba2FtYWlQS0lSb290LmNybIaBtmxkYXA6 Ly8vQ049QWthbWFpUEtJUm9vdCxDTj11c21hMWNhLXBraTAsQ049Q0RQLENOPVB1YmxpYyUyMEtl eSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/ Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlv blBvaW50MIIBTgYIKwYBBQUHAQEEggFAMIIBPDA7BggrBgEFBQcwAoYvaHR0cDovL2FrYW1haXBr aS91c21hMWNhLXBraTBfQWthbWFpUEtJUm9vdC5jcnQwUQYIKwYBBQUHMAKGRWh0dHA6Ly9ha2Ft YWlwa2kuZGZ3MDEuY29ycC5ha2FtYWkuY29tL3VzbWExY2EtcGtpMF9Ba2FtYWlQS0lSb290LmNy dDCBqQYIKwYBBQUHMAKGgZxsZGFwOi8vL0NOPUFrYW1haVBLSVJvb3QsQ049QUlBLENOPVB1Ymxp YyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9 YWRzdmM/Y0FDZXJ0aWZpY2F0ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3Jp dHkwDQYJKoZIhvcNAQEFBQADggEBADkqmsMzAXzel+sFb7Z3lFZ3uydL4mgSW5taIvqlvy7gAFfW aAgkurkKqzDSVT4TRGH7eJP1yVK/L2R6oII4e6NlJFM1iyD+AFhPR7qVzOAnrDlJD/v9q0JZBNDv NQSSApRMHQ0VYRuMC1HruQexFvqDBoqjJ1oEGYWthlOt+sLWXwqQxBILOGt0vcsUx/QJX3FRhLjE ri+aO0XVBdRaNiZyB50kmhNelgWRPT5OsDuz17HVVF6R8KpDzOKCJ1nS/eUxW9nkxH0E5/BC2Q0I MP9TGxKs4j8qKTW2gbqOBDekUsWFDgvv6HJlYSDJNwqy0j38ANOSuw0LPg6v6nLsDx0wgggAMIIG 6KADAgECAgodVbdHAAIAAOWFMA0GCSqGSIb3DQEBBQUAMF4xEzARBgoJkiaJk/IsZAEZFgNjb20x FjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBB a2FtYWlQS0lJc3N1aW5nMB4XDTEyMTIwNDE5MzYxN1oXDTEzMTIwNDE5MzYxN1owgZwxCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJNQTESMBAGA1UEBxMJQ2FtYnJpZGdlMRwwGgYDVQQKExNBa2FtYWkg VGVjaG5vbG9naWVzMRcwFQYDVQQLEw5BVVRPLWJvcy1tcGFnYjERMA8GA1UEAxMIbGFwZXRlcnMx IjAgBgkqhkiG9w0BCQEWE2xhcGV0ZXJzQGFrYW1haS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCbmb+XJz2L/fxTvAIagVUCs7TkIOaqRAwQxpOn9wxVL6rtNHCjLSUoblRzOkb3 baEGF1kVXiGDGI/2b1M8za3SHJc/pmbTbhhLGyBNO6k4+cdzjzZF+oK7h0iO58kIGU8YWrrD3JVF GBiPu7dw3KLW5q5SxKcyV3BXIWQ6lhHBZ1vTpgkc9hG3RDZV9YBccj8HZqUrKb6qsVSDkdyELyvs BKVYkRQ0Imu8IMckbflYew+52pTGchuSRKldFYmdhCJ1yrZohjVId+h2n3GYPAWlz0+jDuyY1CLV lZoZFwfAYs+NU+04A/FLWp7Vy48j6MzdfxIlSPot0/9xjkNCIxFNAgMBAAGjggR/MIIEezALBgNV HQ8EBAMCBaAwMwYDVR0lBCwwKgYIKwYBBQUHAwcGCCsGAQUFBwMCBgorBgEEAYI3CgMEBggrBgEF BQcDBDAzBgNVHREELDAqoCgGCisGAQQBgjcUAgOgGgwYbGFwZXRlcnNAY29ycC5ha2FtYWkuY29t MB0GA1UdDgQWBBQbw+hP1X8ejh4BkPijwLbJXNFMfDAfBgNVHSMEGDAWgBQH7LSOr2eGVIjvvbMU V0nPgky/FDCCATkGA1UdHwSCATAwggEsMIIBKKCCASSgggEghiVodHRwOi8vYWthbWFpcGtpL0Fr YW1haVBLSUlzc3VpbmcuY3JshjtodHRwOi8vYWthbWFpcGtpLmRmdzAxLmNvcnAuYWthbWFpLmNv bS9Ba2FtYWlQS0lJc3N1aW5nLmNybIaBuWxkYXA6Ly8vQ049QWthbWFpUEtJSXNzdWluZyxDTj11 c21hMWNhLXBraTEsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz LENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlz dD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50MIIBvAYIKwYBBQUHAQEEggGu MIIBqjBZBggrBgEFBQcwAoZNaHR0cDovL2FrYW1haXBraS91c21hMWNhLXBraTEua2VuZGFsbC5j b3JwLmFrYW1haS5jb21fQWthbWFpUEtJSXNzdWluZygyKS5jcnQwbwYIKwYBBQUHMAKGY2h0dHA6 Ly9ha2FtYWlwa2kuZGZ3MDEuY29ycC5ha2FtYWkuY29tL3VzbWExY2EtcGtpMS5rZW5kYWxsLmNv cnAuYWthbWFpLmNvbV9Ba2FtYWlQS0lJc3N1aW5nKDIpLmNydDCBrAYIKwYBBQUHMAKGgZ9sZGFw Oi8vL0NOPUFrYW1haVBLSUlzc3VpbmcsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2Vz LENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9ZnIsREM9YWRzdmM/Y0FDZXJ0aWZpY2F0 ZT9iYXNlP29iamVjdENsYXNzPWNlcnRpZmljYXRpb25BdXRob3JpdHkwLQYIKwYBBQUHMAGGIWh0 dHA6Ly9ha2FtYWlvY3NwLmFrYW1haS5jb20vb2NzcDA8BgkrBgEEAYI3FQcELzAtBiUrBgEEAYI3 FQiCzuU6h7jULYGFiwei4yGG0g+BSYTk3wWBkPoUAgFkAgEWMEEGCSsGAQQBgjcVCgQ0MDIwCgYI KwYBBQUHAwcwCgYIKwYBBQUHAwIwDAYKKwYBBAGCNwoDBDAKBggrBgEFBQcDBDBEBgkqhkiG9w0B CQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcN AwcwDQYJKoZIhvcNAQEFBQADggEBAGJ0DGpvXHPRk+t1KHfshPIJLXaaOh3irSMk2BpTVkXnvzmR K+X7ZJueCKhK7e6UVyyi1QrGx3U+XkRmCCLLAYbKyyqSIBRibWbzIovfkWp8BFOHhajrMimuWERD nJJuteZAhpUexBDCEatkTbPQ+Y8EGLAKxI4HpaWWmagUDaAAKpqrkxMXHP93pYRCWfzoSqrk3zGR Cq4d4g66vDaTvjp5FykQLHNTplCIgp6Yy1pCgkSXZT+2ZSQyACbXPrt917QwvxHIB7w8256R9804 DPIKF1j3ryjtiVePBBHokfiRAQlJjrEV3KDVrXAM7riy+XpePAYojrDcR8+cXgFZtzYxggLwMIIC 7AIBATBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZha2FtYWkxFDAS BgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJc3N1aW5nAgodVbdHAAIAAOWF MAkGBSsOAwIaBQCgggFZMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDQyMzIxMTgwOVowIwYJKoZIhvcNAQkEMRYEFPgi3oRHmYWN5rdM+YjSZApYrLS1MHsGCSsG AQQBgjcQBDFuMGwwXjETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmFrYW1h aTEUMBIGCgmSJomT8ixkARkWBGNvcnAxGTAXBgNVBAMTEEFrYW1haVBLSUlzc3VpbmcCCh1Vt0cA AgAA5YUwfQYLKoZIhvcNAQkQAgsxbqBsMF4xEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJ k/IsZAEZFgZha2FtYWkxFDASBgoJkiaJk/IsZAEZFgRjb3JwMRkwFwYDVQQDExBBa2FtYWlQS0lJ c3N1aW5nAgodVbdHAAIAAOWFMA0GCSqGSIb3DQEBAQUABIIBAEp4ABMC1gQEgKQ/3YsoM3UgF0rD wlaGcKTZIDAx3T31xfzaYsLO4ekTSeGHydbmiucUxV6pSYvhwAYSD3vgujmxjcABl2NdrxmA509n LQHzZdxPqf+TqWWgYK4ii2Px7PdjH0wAt7eh+oYMrfeqsKdAvK7V3Lpp8mpTgaNMJEKsUcl8idgp Jr9/U1+TXZVHO6P0PGsLY//DHbPi3y32gMUzNIXrV/qZi28IpFoL3l62PEv9nJBtiljT3j7lzUWR BLJ68SYh+flgloKCWWOhkhNA1MudmzedpHUMyOCQwmlKf0B45ksUa1A7uL+Yk3y7Ei1gNEhVeg45 ne8Vedx/U6MAAAAAAAA= --Apple-Mail=_B989667C-B651-41B3-9AB0-4A5DA99E0A93-- From johnsonhammond2@hushmail.com Sat Apr 27 10:12:23 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FCF21F9822 for ; Sat, 27 Apr 2013 10:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgRd7leCT4Ki for ; Sat, 27 Apr 2013 10:12:23 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id 4465521F9821 for ; Sat, 27 Apr 2013 10:12:23 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id 174D31B5313 for ; Sat, 27 Apr 2013 17:12:23 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:12:22 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id CC45314DBDE; Sat, 27 Apr 2013 17:12:22 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:12:22 -0400 To: cdni@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427171222.CC45314DBDE@smtp.hushmail.com> Subject: [CDNi] Biggest Fake Conference in Computer Science X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:39:04 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From flefauch@cisco.com Sun Apr 28 23:36:15 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00321F9763 for ; Sun, 28 Apr 2013 23:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzR-SRLCR8t1 for ; Sun, 28 Apr 2013 23:36:14 -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 71BE421F9749 for ; Sun, 28 Apr 2013 23:36:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7361; q=dns/txt; s=iport; t=1367217374; x=1368426974; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=/VmnlVP2YGwIVtuSq2O1MwDVRzSrjL7kjd+QYM/zMLw=; b=bKNZ3U8xean7mvkLOF1ruWNrnlg4+Dwfy5Z24zkD0JIWtSVbCH2owTRC sFKd6ITYQ2Kov0fLLNi1jA/4BqHjkSvmGhJJaZdCAh5vmxDS5yuU8gcd2 LSC9zFdNS9fRmdBOYGYbVXS6ufK7xrJPEW/7IBmVJmbbbro/P+s4KKCpW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmQGAPcTflGtJXHA/2dsb2JhbABSgwc2RL4EfxZtB4IfAQEBBAEBAWsbAgEIEQMBAgsdBycLFAkIAgQTCAGIDQcFvHeNWIERIA0KAQaCaGEDqEiDEYFzNQ X-IronPort-AV: E=Sophos;i="4.87,571,1363132800"; d="scan'208,217";a="204118416" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 29 Apr 2013 06:36:14 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3T6aDWA001797 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 29 Apr 2013 06:36:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.150]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Mon, 29 Apr 2013 01:36:13 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] WG Last Call on draft-ietf-cdni-requirements-06.txt Thread-Index: AQHONtVcTTK3EhU+h0KHYCH7+69QVJjtLdUA Date: Mon, 29 Apr 2013 06:36:12 +0000 Message-ID: References: <20130409175254.29406.52063.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.196] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D4197C8xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: Re: [CDNi] WG Last Call on draft-ietf-cdni-requirements-06.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, 29 Apr 2013 06:36:15 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D4197C8xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, This closes the WG Last Call on draft-ietf-cdni-requirements-06.txt. We'll move the document forward. Cheers Francois & Daryl On 11 Apr 2013, at 18:55, Francois Le Faucheur (flefauch) > wrote: Folks, This email initiates a CDNI WG Last Call on: http://www.ietf.org/internet-drafts/draft-ietf-cdni-requirements-06.txt Please comment on the list on this document in view of publishing it as a S= tandards Track RFC from the CDNI WG. This Last Call will close on Friday April 26th. Francois & Daryl Begin forwarded message: Resent-From: > From: > Subject: New Version Notification - draft-ietf-cdni-requirements-06.txt Date: 9 April 2013 19:52:54 CEST Resent-To: >, >, >, > To: >, >, > A new version (-06) has been submitted for draft-ietf-cdni-requirements: http://www.ietf.org/internet-drafts/draft-ietf-cdni-requirements-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-06 IETF Secretariat. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D4197C8xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <498CEF2B613780418197422E2A0B557B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hello,

This closes the WG Last Call on draft-ietf-cdni-requirements-06.t= xt.
We'll move the document forward.

Cheers

Francois & Daryl

On 11 Apr 2013, at 18:55, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Folks,

This email initiates a CDNI WG Last Call on:



Please comment on the list on this document in view of publishing it&n= bsp;as a Standards Track RFC from the CDNI WG.

This Last Call will close on Friday April 26th.

Francois & Daryl


Begin forwarded message:

Subject: New V= ersion Notification - draft-ietf-cdni-requirements-06.txt
Date: 9 April 201= 3 19:52:54 CEST
Resent-To: <= /b><kleung@cisco.com>, <yiu_lee@cable.comcast.com>, <d.malas@cablelabs.com>= , <flefauch@cisco.com>


A new version (-06) has been submitted for draft-ietf-cdni-requirements: http://www.ietf.org/internet-drafts/draft-ietf-cdni-requirements-0= 6.txt


The IETF datatracker page for this Internet-Draft is:
= https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/

Diff from previous version:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-06<= br>
IETF Secretariat.


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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D4197C8xmbrcdx10ciscocom_-- From swainner@cisco.com Mon Apr 29 08:49:44 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B548C21F9E2C for ; Mon, 29 Apr 2013 08:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcjB4EwaHGnz for ; Mon, 29 Apr 2013 08:49:42 -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 B7D4921F9E26 for ; Mon, 29 Apr 2013 08:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20115; q=dns/txt; s=iport; t=1367250581; x=1368460181; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=pTQEgKsEvbPXhmq7DQBs52+vZKFvUFKnbn9YUSV7vuk=; b=jjkOBGj8nNfeTjCYUHC9V+iZhkJ6sBSX24kyQZUJekT3j3AF38SZ+uNH ntC0BDx/wLVGvFc6au6GtpjfR9TxACuBc9y3MIXaz5FfehoXelf52KTyS 7lw8RD600gI4JU8yVVlr9MFt8PxJsMaEzh36+wuXxQgEwg5m4YuCfHyrZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4GAFuVflGtJXG//2dsb2JhbABTgkNENkSIUbUsgQYWdIIfAQEBBAEBAWsJAQEMBAsRBAEBAQkWCAcJAwIBAgEVHwkIBg0BBQIBAQWIDQcFu1SNYoE4BwaDSQOTT4NPgSaQBIMtIIEuJA X-IronPort-AV: E=Sophos;i="4.87,574,1363132800"; d="scan'208,217";a="204349564" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 29 Apr 2013 15:49:41 +0000 Received: from rtp-swainner-8912.cisco.com (rtp-swainner-8912.cisco.com [10.116.109.195]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3TFnduO022753; Mon, 29 Apr 2013 15:49:40 GMT Message-ID: <517E9693.4050009@cisco.com> Date: Mon, 29 Apr 2013 11:49:39 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Jan Seedorf References: <2779C9F0771F974CAD742BAE6D9904FE55452F7E@PALLENE.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE55452F7E@PALLENE.office.hd> Content-Type: multipart/alternative; boundary="------------000908070802050507070909" Cc: "cdni@ietf.org" Subject: Re: [CDNi] New Version Notification for draft-spp-cdni-rr-foot-cap-semantics-04 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 Apr 2013 15:49:44 -0000 This is a multi-part message in MIME format. --------------000908070802050507070909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit | 1. Introduction and scope | o The uCDN has received footprint and/or capability advertisements from a set of dCDNs. Footprint advertisement and capability advertisement need not use the same underlying protocol. I think we want to use the same protocol in order to avoid having another layer of referencing between a footprint associated with a capability. I think we concluded that capability would be fairly static (e.g. HTTP) and the footprint is more likely to change. They are intrinsically coupled even if they are coupled implicitly. | 2. CDNI FCI in existing CDNI Documents | In the following section, the existing descriptions of the CDNI FCI interface in existing documents will be examined. After this, the apparent common understanding of what this interface is intended to offer and accomplished will be carved out. Descriptions of the CDNI FCI interface are highlighted in the CDNI Problem Statement [RFC6707], CDNI Use Cases [RFC6770], the CDNI draft requirements [I-D. ietf-cdni-requirements], and the CDNI framework draft [I-D ietf-cdni-framework]. An assessment of these descriptions is highlighted in the subsequent sections where the ambiguity associated with footprint and capabilities is highlighted. The objective of this document is to clarify the meaning of footprint and capability and define the semantics and method for which these attributes are exchanged between two cooperating CDN's. Untitled | 3.1 ... I would replace this whole section with a motivation for advertising limited coverage. CDN's are built to minimize the cost of transport and optimize the performance of content delivery across that transport. A dCDN operator may elect to advertise only the footprint for which the CDN is optimized. While a dCDN might feasibly 'reach' a much larger footprint, the operator of the dCDN has elected to narrow the scope of footprint to insure that the CDN is only used for media delivery when clients are topologically or geographically close. A uCDN may have global coverage enabling media delivery anywhere on the Internet; however, the uCDN may recognize that a specific dCDN has been optimized for media delivery in a specific topological footprint or a specific geographic region. The quality of 'coverage' and 'reach' may be somewhat subjective. It is incumbent upon the uCDN to assess the relative quality of a dCDN; therefore, a dCDN should advertise a footprint that is contextually consistent with the advertisements of any other dCDN. | 5. Towards Semantics for Footprint Advertisement Two types of footprint may be advertised - topological and geographical. A topological advertisement describes the dCDN's footprint relative to it's connectivity to the Internet using the BGP ASN attributes. A geographical advertisement describes the dCDN's footprint relative to its coverage of a define location. We might consider two models: a. Topological Footprint (ASN) scoped by a geographical boundary (think of a global ASN where CDN coverage is limited to a particular continent) ASN <#>: FR, GE, UK, BE, ... b. Geographical Footprint scoped by a set of topological boundaries (think of a continent where CDN coverage includes a set of ASN) US: ASN <#1>, ASN <#2>, ... If the FCI is intended to provide the temporary state of the negotiated contract, either of the above could change over time. A dCDN that covers an ASN (by contract) could be expanded to include new countries. Likewise, a dCDN that covers a region (by contract) could be expanded to include new ASN. Should the FCI support one or the other of the above models? | 6. Towards Semantics for Capabilities Advertisement My experience has highlighted the fact that most of the base capabilities must be configured (according to a negotiated contract) to facilitate redirection. What seems relevant to me is where the footprint of a given capability changes. Let's say uCDN has negotiated with dCDN to delivery both HTTP and RTMP. At the time of service initialization, the RTMP footprint is smaller than the HTTP footprint; therefore, the capability should be advertised and scoped according to a footprint. The default case might be that HTTP and RTMP are configured (no capability advertisement required), but that assumes both capabilities have global footprint. Not sure that is always the case. That is why I'm inclined to include a capability update which is scoped by a footprint. | 7. Open Issues and Questions | o What is the service model of this interface:... I'm inclined to say the dCDN advertises its capability and footprint to the uCDN and periodically refreshes that advertisement. | o In addition to "reachability" types of footprint, ... Not clear that a dCDN will want to advertise resource availability ... just service availability. | o Does a footprint need to explicitly include the "transitive" ... I would think that the transitive dCDN MAY aggregate and represent a concatenated footprint. Alternatively, the dCDN MAY advertise a subset of footprint to conform to a contract between the uCDN and the transitive CDN. | o How exactly can a give dCDN derive its footprint? I would expect this to be configured. A dCDN might have a large footprint, but only want to advertise to a uCDN a portion of its footprint in accordance to a contract. | o Should the footprint/capabilities advertisement interface only ... I think the capability advertisement should be mandatory (e.g. HTTP | RTMP | RTSP) and it should conform to the contract. It SHOULD be scoped by geography and/or topology where the absence of both footprint means global coverage. On 2/26/13 5:27 AM, Jan Seedorf wrote: > Dear all, > > We have submitted a new version of the footprint/capabilities semantics draft. We revised in particular the sections on what a footprint and capabilities should actually look like, so that the document now reflects the latest agreements in the design team. Thanks to Kevin and Ray for their help with the revision. > > Small note: we submitted yesterday the -03 version and shortly after the -04 version, which only fixed minor things in the author's affiliations compared to the -03 version. Just for people who were wondering how we got from -02 to -04. > > If you are interested in this, please join the phone call this afternoon. We also intend to update the WG during the CDNI sessions at the upcoming IETF-86 in Orlando. > > - Jan > > -----Original Message----- > From:internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, February 25, 2013 5:13 PM > To: Jan Seedorf > Cc:kevin.ma@azukisystems.com;sprevidi@cisco.com;jon.peterson@neustar.biz;ray.vanbrandenburg@tno.nl > Subject: New Version Notification for draft-spp-cdni-rr-foot-cap-semantics-04.txt > > > A new version of I-D, draft-spp-cdni-rr-foot-cap-semantics-04.txt > has been successfully submitted by Jan Seedorf and posted to the > IETF repository. > > Filename: draft-spp-cdni-rr-foot-cap-semantics > Revision: 04 > Title: CDNI Request Routing: Footprint and Capabilities Semantics > Creation date: 2013-02-25 > Group: Individual Submission > Number of pages: 22 > URL:http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics-04.txt > Status:http://datatracker.ietf.org/doc/draft-spp-cdni-rr-foot-cap-semantics > Htmlized:http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-04 > Diff:http://www.ietf.org/rfcdiff?url2=draft-spp-cdni-rr-foot-cap-semantics-04 > > Abstract: > This document tries to capture the semantics of the "Footprint and > Capabilities Advertisement" part of the CDNI Request Routing > interface, i.e. the desired meaning and what "Footprint and > Capabilities Advertisement" is expected to offer within CDNI. The > discussion in this document has the goal to facilitate the choosing > of one or more suitable protocols for "Footprint and Capabilities > Advertisement" within CDNI Request Routing. > > > > > The IETF Secretariat > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > . > --------------000908070802050507070909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
| 1. Introduction and scope

| o The uCDN has received footprint and/or capability advertisements from a set of dCDNs.  Footprint advertisement and capability advertisement need not use the same underlying protocol.

I think we want to use the same protocol in order to avoid having another layer of referencing between a footprint associated with a capability.  I think we concluded that capability would be fairly static (e.g. HTTP) and the footprint is more likely to change.  They are intrinsically coupled even if they are coupled implicitly.

| 2. CDNI FCI in existing CDNI Documents

| In the following section, the existing descriptions of the CDNI FCI interface in existing documents will be examined.  After this, the apparent common understanding of what this interface is intended to offer and accomplished will be carved out.

Descriptions of the CDNI FCI interface are highlighted in the CDNI Problem Statement [RFC6707], CDNI Use Cases [RFC6770], the CDNI draft requirements [I-D. ietf-cdni-requirements], and the CDNI framework draft [I-D ietf-cdni-framework].  An assessment of these descriptions is highlighted in the subsequent sections where the ambiguity associated with footprint and capabilities is highlighted.  The objective of this document is to clarify the meaning of footprint and capability and define the semantics and method for which these attributes are exchanged between two cooperating CDN's.
Untitled
| 3.1

 ... I would replace this whole section with a motivation for advertising limited coverage.

CDN's are built to minimize the cost of transport and optimize the performance of content delivery across that transport.

A dCDN operator may elect to advertise only the footprint for which the CDN is optimized.  While a dCDN might feasibly 'reach' a much larger footprint, the operator of the dCDN has elected to narrow the scope of footprint to insure that the CDN is only used for media delivery when clients are topologically or geographically close.

A uCDN may have global coverage enabling media delivery anywhere on the Internet; however, the uCDN may recognize that a specific dCDN has been optimized for media delivery in a specific topological footprint or a specific geographic region.

The quality of 'coverage' and 'reach' may be somewhat subjective.  It is incumbent upon the uCDN to assess the relative quality of a dCDN; therefore, a dCDN should advertise a footprint that is contextually consistent with the advertisements of any other dCDN.

| 5. Towards Semantics for Footprint Advertisement

Two types of footprint may be advertised - topological and geographical.  A topological advertisement describes the dCDN's footprint relative to it's connectivity to the Internet using the BGP ASN attributes.  A geographical advertisement describes the dCDN's footprint relative to its coverage of a define location.

We might consider two models:

a. Topological Footprint (ASN) scoped by a geographical boundary (think of a global ASN where CDN coverage is limited to a particular continent)

    ASN <#>: FR, GE, UK, BE, ...

b. Geographical Footprint scoped by a set of topological boundaries (think of a continent where CDN coverage includes a set of ASN)

    US: ASN <#1>, ASN <#2>, ...

If the FCI is intended to provide the temporary state of the negotiated contract, either of the above could change over time.  A dCDN that covers an ASN (by contract) could be expanded to include new countries.  Likewise, a dCDN that covers a region (by contract) could be expanded to include new ASN.

Should the FCI support one or the other of the above models?

| 6. Towards Semantics for Capabilities Advertisement

My experience has highlighted the fact that most of the base capabilities must be configured (according to a negotiated contract) to facilitate redirection.  What seems relevant to me is where the footprint of a given capability changes.  Let's say uCDN has negotiated with dCDN to delivery both HTTP and RTMP.  At the time of service initialization, the RTMP footprint is smaller than the HTTP footprint; therefore, the capability should be advertised and scoped according to a footprint.  The default case might be that HTTP and RTMP are configured (no capability advertisement required), but that assumes both capabilities have global footprint.  Not sure that is always the case.

That is why I'm inclined to include a capability update which is scoped by a footprint.

| 7. Open Issues and Questions

| o What is the service model of this interface:...

I'm inclined to say the dCDN advertises its capability and footprint to the uCDN and periodically refreshes that advertisement.

| o In addition to "reachability" types of footprint, ...

Not clear that a dCDN will want to advertise resource availability ... just service availability.

| o Does a footprint need to explicitly include the "transitive" ...

I would think that the transitive dCDN MAY aggregate and represent a concatenated footprint.  Alternatively, the dCDN MAY advertise a subset of footprint to conform to a contract between the uCDN and the transitive CDN.

| o How exactly can a give dCDN derive its footprint?

I would expect this to be configured.  A dCDN might have a large footprint, but only want to advertise to a uCDN a portion of its footprint in accordance to a contract.

| o Should the footprint/capabilities advertisement interface only ...

I think the capability advertisement should be mandatory (e.g. HTTP | RTMP | RTSP) and it should conform to the contract.  It SHOULD be scoped by geography and/or topology where the absence of both footprint means global coverage.


On 2/26/13 5:27 AM, Jan Seedorf wrote:
Dear all,

We have submitted a new version of the footprint/capabilities semantics draft. We revised in particular the sections on what a footprint and capabilities should actually look like, so that the document now reflects the latest agreements in the design team. Thanks to Kevin and Ray for their help with the revision.

Small note: we submitted yesterday the -03 version and shortly after the -04 version, which only fixed minor things in the author's affiliations compared to the -03 version. Just for people who were wondering how we got from -02 to -04.

If you are interested in this, please join the phone call this afternoon. We also intend to update the WG during the CDNI sessions at the upcoming IETF-86 in Orlando.

 - Jan

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] 
Sent: Monday, February 25, 2013 5:13 PM
To: Jan Seedorf
Cc: kevin.ma@azukisystems.com; sprevidi@cisco.com; jon.peterson@neustar.biz; ray.vanbrandenburg@tno.nl
Subject: New Version Notification for draft-spp-cdni-rr-foot-cap-semantics-04.txt


A new version of I-D, draft-spp-cdni-rr-foot-cap-semantics-04.txt
has been successfully submitted by Jan Seedorf and posted to the
IETF repository.

Filename:	 draft-spp-cdni-rr-foot-cap-semantics
Revision:	 04
Title:		 CDNI Request Routing: Footprint and Capabilities Semantics
Creation date:	 2013-02-25
Group:		 Individual Submission
Number of pages: 22
URL:             http://www.ietf.org/internet-drafts/draft-spp-cdni-rr-foot-cap-semantics-04.txt
Status:          http://datatracker.ietf.org/doc/draft-spp-cdni-rr-foot-cap-semantics
Htmlized:        http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap-semantics-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-spp-cdni-rr-foot-cap-semantics-04

Abstract:
   This document tries to capture the semantics of the "Footprint and
   Capabilities Advertisement" part of the CDNI Request Routing
   interface, i.e. the desired meaning and what "Footprint and
   Capabilities Advertisement" is expected to offer within CDNI.  The
   discussion in this document has the goal to facilitate the choosing
   of one or more suitable protocols for "Footprint and Capabilities
   Advertisement" within CDNI Request Routing.

                                                                                  


The IETF Secretariat

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

--------------000908070802050507070909--