From ietf-secretariat-reply@ietf.org Thu Sep 5 23:58:43 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9906A21F9B92 for ; Thu, 5 Sep 2013 23:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.052, 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 adWqvMsSni53 for ; Thu, 5 Sep 2013 23:58:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3442521F9CAF for ; Thu, 5 Sep 2013 23:58:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: cdni@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130906065839.14449.25586.idtracker@ietfa.amsl.com> Date: Thu, 05 Sep 2013 23:58:39 -0700 From: IETF Secretariat X-Mailman-Approved-At: Fri, 06 Sep 2013 00:02:15 -0700 Subject: [CDNi] Milestones changed for cdni WG X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Sep 2013 06:58:43 -0000 Changed milestone "Submit CDNI requirements to IESG as Informational", set due date to September 2013 from June 2012. Changed milestone "Submit CDNI framework to IESG as Informational", set due date to December 2013 from June 2012. Changed milestone "Submit specification of the CDNI Logging interface to IESG as Proposed Standard", set due date to December 2013 from December 2012. Changed milestone "Submit specification of the CDNI Metadata Distribution interface to IESG as Proposed Standard", set due date to December 2013 from June 2013. Changed milestone "Submit specification of the CDNI Control interface to IESG as proposed Standard", set due date to April 2014 from December 2012. Changed milestone "Submit specification of the CDNI Request Routing/Redirection interface to IESG as Proposed Standard", set due date to April 2014 from December 2012. Changed milestone "Submit specification of the CDNI Request Routing/Footprint & Capabilities Advertisement interface to IESG as Proposed Standard", set due date to September 2014 from June 2013. Changed milestone "Recharter or dissolve", set due date to October 2014 from June 2013. URL: http://datatracker.ietf.org/wg/cdni/charter/ From flefauch@cisco.com Mon Sep 9 02:09:34 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C8911E81A5 for ; Mon, 9 Sep 2013 02:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRvgbW9TSrfZ for ; Mon, 9 Sep 2013 02:09:20 -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 3C40F11E81AD for ; Mon, 9 Sep 2013 02:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20863; q=dns/txt; s=iport; t=1378717760; x=1379927360; h=from:to:subject:date:message-id:mime-version; bh=yrZaU7asJ3GIBxN/+Yx+wk35mk9MH2aCDq7aZfeX8UA=; b=XyCggk1uQcTsjMErlE+5QNE5KLsQSXlk6H41cSv3LGudBxbUokZm6JBB vATYhYjG8TfEsUe8OigxA0MrYE5Cr/MPnl7aIeVMo6McdUFnjUV8lHbNB dtbhgOrOa/ejGKyytRWAZT/cIZqDwrM4HEniN8FE8Hvl2UZUMn/5sXIyE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnsFABGPLVKtJXHB/2dsb2JhbABBFwODBzhRwhWBHRZtB4InAQICZgIjARwOCgQIBDwkAwEDG4d6DDSkO5MjjGeNK4EMG30gAQwcB4MFgQADqVuCT1GBcTk X-IronPort-AV: E=Sophos;i="4.90,866,1371081600"; d="scan'208,217";a="257264477" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 09 Sep 2013 09:09:19 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8999Jco009832 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 9 Sep 2013 09:09:19 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 9 Sep 2013 04:09:19 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Informal Meetings on CDNI Logging - 25 Sept & 16 Oct Thread-Index: AQHOrTxDHg6FULdiaEKH88o3s7qQCQ== Date: Mon, 9 Sep 2013 09:09:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.102.199] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04BA331Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: [CDNi] Informal Meetings on CDNI Logging - 25 Sept & 16 Oct 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, 09 Sep 2013 09:09:34 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BA331Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We (cdni-logging authors) have scheduled two brief (45 mins) open informal = virtual meetings on CDNI Logging to keep the momentum till Vancouver: * Wed 25 Sep, at 9:15am California Time (ie 18:15pm Paris Time) * Wed 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time) These are open meetings aiming at collecting input on open issues, and ever= yone is encouraged to attend. Francois Attendance is via Webex: Wed 25 Sep =3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Informal Meetings on CDNI Logging Date: Wednesday, September 25, 2013 Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 303 072 107 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137768&UID=3D4843= 18167&PW=3DNZTg1MjNlN2Mx&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:303 072 107 CCP:+14085256800x303072107# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. Wed 16 Oct =3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Informal Meetings on CDNI Logging Date: Wednesday, October 16, 2013 Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 304 625 039 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137858&UID=3D4843= 18167&PW=3DNY2IzMDA2NTQ0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:304 625 039 CCP:+14085256800x304625039# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BA331Bxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <08D1AE8636B1C149AA2742953CED57B6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Folks,

We (cdni-logging authors) have scheduled two brief (45 mins) open info= rmal virtual meetings on CDNI Logging to keep the momentum till Vancouver:<= /div>
* Wed = 25 Sep, at 9:15am California Time (ie 18:15pm Paris Time)
* Wed = 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time)

These are open meetings aiming at collecting input on open issues, and= everyone is encouraged to attend.

Francois


Attendance is via Webex:


Wed 25 Sep 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Topic: Informal Meetings on CDNI Logging 
Date: Wednesday, September 25, 2013 
Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 303 072 107 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137768&UID=3D484318167&PW=3DNZTg1MjNlN2= Mx&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:303 072 107 

CCP:+14085256800x303072107# 

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



Wed 16 Oct 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Topic: Informal Meetings on CDNI Logging 
Date: Wednesday, October 16, 2013 
Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 304 625 039 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137858&UID=3D484318167&PW=3DNY2IzMDA2NT= Q0&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:304 625 039 

CCP:+14085256800x304625039# 

IMPORTANT NOTICE: This WebEx service includes a feature = that allows audio and any documents and other materials exchanged or viewed= during the session to be recorded. By joining this session, you automatically consent to such recordings. If = you do not consent to the recording, discuss your concerns with the meeting= host prior to the start of the recording or do not join the session. Pleas= e note that any such recordings may be subject to discovery in the event of litigation. 
--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BA331Bxmbrcdx10ciscoc_-- From internet-drafts@ietf.org Mon Sep 9 11:04: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 5C0CF21F9C17; Mon, 9 Sep 2013 11:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.596 X-Spam-Level: X-Spam-Status: No, score=-102.596 tagged_above=-999 required=5 tests=[AWL=0.004, 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 CAm11rinAcU6; Mon, 9 Sep 2013 11:04:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E41FA21F999E; Mon, 9 Sep 2013 11:04:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.70.p1 Message-ID: <20130909180456.28950.79711.idtracker@ietfa.amsl.com> Date: Mon, 09 Sep 2013 11:04:56 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-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, 09 Sep 2013 18:04:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Framework for CDN Interconnection Author(s) : Larry Peterson Bruce Davie Filename : draft-ietf-cdni-framework-05.txt Pages : 52 Date : 2013-09-09 Abstract: This document presents a framework for Content Distribution Network Interconnection (CDNI). The purpose of the framework is to provide an overall picture of the problem space of CDNI and to describe the relationships among the various components necessary to interconnect CDNs. CDN Interconnection requires the specification of several interfaces and mechanisms to address issues such as request routing, distribution metadata exchange, and logging information exchange across CDNs. The intent of this document is to outline what each interface needs to accomplish, and to describe how these interfaces and mechanisms fit together, while leaving their detailed specification to other documents. It obsoletes RFC 3466. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-framework-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-framework-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From flefauch@cisco.com Tue Sep 10 02:05: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 1705A21F9BB1 for ; Tue, 10 Sep 2013 02:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.448 X-Spam-Level: X-Spam-Status: No, score=-10.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EooYXFNwURMr for ; Tue, 10 Sep 2013 02:05:11 -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 304D821F9BF1 for ; Tue, 10 Sep 2013 02:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1422; q=dns/txt; s=iport; t=1378803911; x=1380013511; h=from:to:subject:date:message-id:mime-version; bh=EqY0WYAaOupEpLI6HiSGqz8SWo32j9NAjin/DN2UMC0=; b=IzhjYeIX10s3x724SGTLejS9a+6hVWPsv02W9C3B4YjSS0SqttfQADwz R4ayqpWCSzbluThGum3ELK9ZSyUG+hU6bzsM9PtUIK+YPZBv1GxJhbElV kjdTlOurHHe60fTunY93A2YIxM0k/gd2g11+pcgbPYGKJ8mIfjLGa4xLe M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnMFAGTfLlKtJXHA/2dsb2JhbABbgwc4UcIxgSgWbQeCHAsBBG4dAQsBHlYnBBuHegyeZqEXBI8qLYMogQADqWGDIIIq X-IronPort-AV: E=Sophos;i="4.90,876,1371081600"; d="scan'208,217";a="257826873" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 10 Sep 2013 09:05:10 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8A95AMC005940 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 10 Sep 2013 09:05:10 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 10 Sep 2013 04:05:10 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Start of WG Last Call on draft-ietf-cdni-framework-05.txt Thread-Index: AQHOrgTZE6q75/TV/EmEyhFJC28T5Q== Date: Tue, 10 Sep 2013 09:05:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04BA6F34xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-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, 10 Sep 2013 09:05:16 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BA6F34xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, This is the start of a two-week working group last call on draft-ietf-cdni-= framework-05.txt: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list. Francois & Daryl --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BA6F34xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
All,

This is the start of a two-week working group last call on draft-ietf-= cdni-framework-05.txt:
http= s://datatracker.ietf.org/doc/draft-ietf-cdni-framework

This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list.

Francois & Daryl
--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BA6F34xmbrcdx10ciscoc_-- From internet-drafts@ietf.org Tue Sep 10 16:52:29 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 3A46E21F9C7B; Tue, 10 Sep 2013 16:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.595 X-Spam-Level: X-Spam-Status: No, score=-102.595 tagged_above=-999 required=5 tests=[AWL=0.005, 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 v3M6NLW5C9MF; Tue, 10 Sep 2013 16:52:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B4821F9C3A; Tue, 10 Sep 2013 16:52:28 -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.71.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130910235228.27138.25084.idtracker@ietfa.amsl.com> Date: Tue, 10 Sep 2013 16:52:28 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-10.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 10 Sep 2013 23:52:29 -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-10.txt Pages : 24 Date : 2013-09-10 Abstract: Content Delivery Networks (CDNs) are frequently used for content delivery. As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers and Enterprise Service Providers are also deploying their own CDNs. To deliver contents from the Content Service Provider (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. 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-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From kleung@cisco.com Wed Sep 11 22:24:07 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC721E8131 for ; Wed, 11 Sep 2013 22:24:07 -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 NEPiVHeJZlgj for ; Wed, 11 Sep 2013 22:24:02 -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 A262821F9CC6 for ; Wed, 11 Sep 2013 22:23:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2970; q=dns/txt; s=iport; t=1378963428; x=1380173028; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PmH9Sjl78gAnjJLnbL6L9c9ReOiTiSe9OPdaP9M49AA=; b=clnvQiQwlYiIRXXOhaU3rezfxnFAMumrvWUqOlMJuTJ+nx9F2QMnn9TR lCsrSHezETYiexq5LDPMJHp2gqfIXh07+ATbZz1DL6e4MXB4Xn3J0ljlj ynuVgED6n/+kbdvdVB03uILOKKGD8kG4lCwV6cBCoQWL0YfbDmuY/JtJQ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmcGANVOMVKtJV2d/2dsb2JhbABbgwc4TAaDKr0KF4EJFm0HgiUBAQEEIxFDDgQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgBh3kHBaw3khCBKY4RFiIGgmM0gQADmSiQQ4MigWokHA X-IronPort-AV: E=Sophos;i="4.90,888,1371081600"; d="scan'208";a="258670487" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 12 Sep 2013 05:23:46 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8C5NkE9013789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 12 Sep 2013 05:23:46 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.174]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Thu, 12 Sep 2013 00:23:46 -0500 From: "Kent Leung (kleung)" To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-leung-cdni-uri-signing-03.txt Thread-Index: AQHOpbdnaJjbAjfax0ehJTbVgqZ395nBn8bQ Date: Thu, 12 Sep 2013 05:23:45 +0000 Message-ID: References: <20130830193036.1149.11538.idtracker@ietfa.amsl.com> In-Reply-To: <20130830193036.1149.11538.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-03.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 05:24:08 -0000 SGkgZm9sa3MuIEJhc2VkIG9uIHRoZSBkaXNjdXNzaW9ucyBhdCB0aGUgbGFzdCBJRVRGIG1lZXRp bmcsIEnigJl2ZSBtYWRlIHRoZSB1cGRhdGVzIHRvIHRoZSBkcmFmdC4gU29tZSBvZiB0aGUga2V5 IGNoYW5nZXMgd2VyZToNCg0KLSBVcGRhdGVkIFVSSSBTaWduaW5nIGluIGEgQ0ROSSBFbnZpcm9u bWVudCBmaWd1cmUNCi0gU3BlY2lmaWVkIHRoYXQgYXR0cmlidXRlcyBhZGRlZCBieSBVQS9vdGhl ciAgZW50aXR5IG5lZWQgdG8gYmUgYWZ0ZXIgdGhlIENETkkgVVJJIFNpZ25pbmcgYXR0cmlidXRl DQotIFVSSSBTaWduaW5nIFRva2VuIGF0dHJpYnV0ZSByZW5hbWVkIHRvIFVSSSBTaWduaW5nIFBh Y2thZ2UgYXR0cmlidXRlLCB3aGljaCBpcyBub3cgbWFuZGF0b3J5DQoNClJldmlldyBjb21tZW50 cyBhcmUgd2VsY29tZS4gVGhhbmtzLg0KDQpLZW50DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddIA0KU2VudDogRnJpZGF5LCBBdWd1c3QgMzAsIDIwMTMgMTI6MzEgUE0NClRv OiBSYXkgdmFuIEJyYW5kZW5idXJnOyBTY290dCBMZWlicmFuZDsgS2VudCBMZXVuZyAoa2xldW5n KTsgRnJhbmNvaXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKTsgQmlsbCBEb3duZXkNClN1YmplY3Q6 IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGV1bmctY2RuaS11cmktc2lnbmlu Zy0wMy50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGV1bmctY2RuaS11cmkt c2lnbmluZy0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgS2VudCBM ZXVuZyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCkZpbGVuYW1lOgkgZHJh ZnQtbGV1bmctY2RuaS11cmktc2lnbmluZw0KUmV2aXNpb246CSAwMw0KVGl0bGU6CQkgVVJJIFNp Z25pbmcgZm9yIENETiBJbnRlcmNvbm5lY3Rpb24gKENETkkpDQpDcmVhdGlvbiBkYXRlOgkgMjAx My0wOC0zMA0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6 IDMzDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWxldW5nLWNkbmktdXJpLXNpZ25pbmctMDMudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGV1bmctY2RuaS11cmktc2lnbmlu Zw0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZXVu Zy1jZG5pLXVyaS1zaWduaW5nLTAzDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxldW5nLWNkbmktdXJpLXNpZ25pbmctMDMNCg0KQWJzdHJh Y3Q6DQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBob3cgdGhlIGNvbmNlcHQgb2YgVVJJIHNp Z25pbmcgc3VwcG9ydHMgdGhlDQogICBjb250ZW50IGFjY2VzcyBjb250cm9sIHJlcXVpcmVtZW50 cyBvZiBDRE5JIGFuZCBwcm9wb3NlcyBhIGNhbmRpZGF0ZQ0KICAgVVJJIHNpZ25pbmcgc2NoZW1l Lg0KDQogICBUaGUgcHJvcG9zZWQgVVJJIHNpZ25pbmcgbWV0aG9kIHNwZWNpZmllcyB0aGUgaW5m b3JtYXRpb24gbmVlZGVkIHRvDQogICBiZSBpbmNsdWRlZCBpbiB0aGUgVVJJIGFuZCB0aGUgYWxn b3JpdGhtIHVzZWQgdG8gYXV0aG9yaXplIGFuZCB0bw0KICAgdmFsaWRhdGUgYWNjZXNzIHJlcXVl c3QgZm9yIHRoZSBjb250ZW50IHJlZmVyZW5jZWQgYnkgdGhlIFVSSS4gIFNvbWUNCiAgIG9mIHRo ZSBpbmZvcm1hdGlvbiBtYXkgYmUgYWNjZXNzZWQgYnkgdGhlIENETiB2aWEgY29uZmlndXJhdGlv biBvcg0KICAgQ0ROSSBtZXRhZGF0YS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoN ClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRo ZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQN Cg0K From ray.vanbrandenburg@tno.nl Tue Sep 17 00:43: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 6194811E822F for ; Tue, 17 Sep 2013 00:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ac2HGXafqqhZ for ; Tue, 17 Sep 2013 00:43:54 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9313F11E820A for ; Tue, 17 Sep 2013 00:43:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,921,1371074400"; d="scan'208,217";a="14044694" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 17 Sep 2013 09:43:52 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.176]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.03.0123.003; Tue, 17 Sep 2013 09:43:52 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: Start of WG Last Call on draft-ietf-cdni-framework-05.txt Thread-Index: AQHOrgTZE6q75/TV/EmEyhFJC28T5ZnJlOxw Date: Tue, 17 Sep 2013 07:43:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.153] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581F495B36EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: Re: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-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, 17 Sep 2013 07:43:59 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F495B36EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I've reviewed draft-ietf-cdni-framework-05. Apart from the following commen= ts, which I would like to see resolved, I think the document is ready for p= ublication. - I've raised this issue before on the list, but didn't see any re= sponse, so let me include it here again: To my knowledge, the current CDNI = documents do not explicitly address the case of HTTP Byte-range requests. A= lthough in most cases byte-range requests will function just as any other r= equests, I think there are some cases where byte-range requests warrant fur= ther attention. An example is the Redirection interface. If a uCDN asks a d= CDN to deliver a particular user request (containing a byte range), and the= dCDN answers positively, can the uCDN assume that the dCDN accepts any fut= ure requests for the same file with a different byte range? And if that is = the case, is this default behavior or do we need an explicit flag in the in= ter-CDN redirection request to indicate the uCDN/dCDN's preference? To be c= lear: I don't think we need any new functionality to handle byte-range requ= ests, but a few sentences in either the Framework or the RI document might = clear up any future uncertainty. Since the framework document will be publi= shed first, I would like to have discussion now. - The security section contains the following text: "CDNs today of= fer a variety of means to control access to content, such as time-of-day re= strictions, geo-blocking, and URI signing. These mechanisms must continue t= o function in CDNI environments, and this consideration is likely to affect= the design of certain CDNI interfaces (e.g. metadata, request routing.)". = Now that we, as a group, have decided that URI signing warrants its own spe= cification, and we added it to the charter, would it make sense to expand o= n this text a little bit? In addition, two small nits: - draft-brandenburg-cdni-has, as listed in the references, has bee= n published as RFC6983. - My name in the acknowledgements (BTW: Thanks for that!) is missp= elled. Could you add the 'van' in the middle? Thanks! Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur (flefauch) Sent: dinsdag 10 september 2013 11:05 To: cdni@ietf.org Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt All, This is the start of a two-week working group last call on draft-ietf-cdni-= framework-05.txt: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list. Francois & Daryl --_000_FCC100FC8D6B034CB88CD8173B2DA1581F495B36EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 = ;

I’ve= reviewed draft-ietf-cdni-framework-05. Apart from the following comments, = which I would like to see resolved, I think the document is ready for publication.

 = ;

-          I&= #8217;ve raised this issue before on the list, but didn’t see any res= ponse, so let me include it here again: To my knowledge, the current CDNI documents do not explicitly address the case of HTTP Byte-range reque= sts. Although in most cases byte-range requests will function just as any o= ther requests, I think there are some cases where byte-range requests warra= nt further attention. An example is the Redirection interface. If a uCDN asks a dCDN to deliver a particula= r user request (containing a byte range), and the dCDN answers positively, = can the uCDN assume that the dCDN accepts any future requests for the same = file with a different byte range? And if that is the case, is this default behavior or do we need an explici= t flag in the inter-CDN redirection request to indicate the uCDN/dCDN's pre= ference? To be clear: I don't think we need any new functionality to handle= byte-range requests, but a few sentences in either the Framework or the RI document might clear up any fu= ture uncertainty. Since the framework document will be published first, I w= ould like to have discussion now.

-          Th= e security section contains the following text: “CDNs today offer a v= ariety of means to control access to content, such as time-of-day restrictions, geo-blocking, and URI signing. These mechanisms must continu= e to function in CDNI environments, and this consideration is likely to aff= ect the design of certain CDNI interfaces (e.g. metadata, request routing.)= ”. Now that we, as a group, have decided that URI signing warrants its own specification, and we added it t= o the charter, would it make sense to expand on this text a little bit?

 = ;

In additio= n, two small nits:

 = ;

-          dr= aft-brandenburg-cdni-has, as listed in the references, has been published a= s RFC6983.

-          My= name in the acknowledgements (BTW: Thanks for that!) is misspelled. Could = you add the ‘van’ in the middle? Thanks!

 = ;

Best regar= ds,

 = ;

Ray

 = ;

From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 10 september 2013 11:05
To: cdni@ietf.org
Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-0= 5.txt

 

All,


This is the start of a two-week working group last call on draft-ietf-= cdni-framework-05.txt:
http= s://datatracker.ietf.org/doc/draft-ietf-cdni-framework

This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list.

Francois & Daryl

--_000_FCC100FC8D6B034CB88CD8173B2DA1581F495B36EXCMBX03tsntnon_-- From flefauch@cisco.com Thu Sep 19 10:26:47 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BED221F9767 for ; Thu, 19 Sep 2013 10:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 9znUjgA+RYsM for ; Thu, 19 Sep 2013 10:26:42 -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 26CA921F964C for ; Thu, 19 Sep 2013 10:26:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19945; q=dns/txt; s=iport; t=1379611602; x=1380821202; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=14rwC8cqGJkLuvjyvkE00kLt2HpnAcxByM+Fobd1cks=; b=Ao6txDgsxzHgTwIQz+kwGedXyHdLSRdefNjhDvFmO4MYQNkWtGnP3Yap cTU67GJ/IHSBRSJztkpBUIwaAlgrZB1ZrwpoCyCx0/MVdJ4n4f8S2FoL4 eDMpegBfgGGZ9voBOgQqSQowtzCSmCRktnsFJOWBFImeqjGSDRWCHjKRt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjIFAJAyO1KtJXHA/2dsb2JhbABbgkNEOFLBLIEiFnSCJQEBAQQBAQFrBgUQAgEIEQQBAQsdBycLFAkIAgQOBQiHewy6HwSPNi0EBgGDHoEAA6lxgySCKg X-IronPort-AV: E=Sophos;i="4.90,938,1371081600"; d="scan'208,217";a="261806811" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 19 Sep 2013 17:26:37 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r8JHQarh013587 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Sep 2013 17:26:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Thu, 19 Sep 2013 12:26:36 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt Thread-Index: AQHOrgTZE6q75/TV/EmEyhFJC28T5Q== Date: Thu, 19 Sep 2013 17:26: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.61.102.99] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04BC8677xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-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, 19 Sep 2013 17:26:47 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BC8677xmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ray and all, (speaking as an individual) On 17 Sep 2013, at 09:43, "Brandenburg, R. (Ray) van" > wrote: Hi all, I=92ve reviewed draft-ietf-cdni-framework-05. Apart from the following comm= ents, which I would like to see resolved, I think the document is ready for= publication. - I=92ve raised this issue before on the list, but didn=92t see an= y response, so let me include it here again: To my knowledge, the current C= DNI documents do not explicitly address the case of HTTP Byte-range request= s. Although in most cases byte-range requests will function just as any oth= er requests, I think there are some cases where byte-range requests warrant= further attention. An example is the Redirection interface. If a uCDN asks= a dCDN to deliver a particular user request (containing a byte range), and= the dCDN answers positively, can the uCDN assume that the dCDN accepts any= future requests for the same file with a different byte range? And if that= is the case, is this default behavior or do we need an explicit flag in th= e inter-CDN redirection request to indicate the uCDN/dCDN's preference? In my mind, what really determines if the dCDN will accept to serve a reque= st received from a client is the metadata distributed by the uCDN for the c= orresponding content; and not so much the fact that this particular request= was redirected by the uCDN or not. So in the particular case where byte-range is used in a client request, the= n the dCDN will makes its decision to honor or not the request based on the= CDNI metadata for that content. At this stage, CDNI metadata is associated= to a URI (or groups of URI) , and cannot be associated to a subset of byte= s for that URI. So, this means that the dCDN would always the same access c= ontrol rules regardless of the byte range, which means by default that if a= certain byte range is allowed, then all other byte ranges are allowed. Would some text capturing the above help? Or do you see a strong requirement for wanting to do something different? To be clear: I don't think we need any new functionality to handle byte-ran= ge requests, but a few sentences in either the Framework or the RI document= might clear up any future uncertainty. Since the framework document will b= e published first, I would like to have discussion now. - The security section contains the following text: =93CDNs today = offer a variety of means to control access to content, such as time-of-day = restrictions, geo-blocking, and URI signing. These mechanisms must continue= to function in CDNI environments, and this consideration is likely to affe= ct the design of certain CDNI interfaces (e.g. metadata, request routing.)= =94. Now that we, as a group, have decided that URI signing warrants its ow= n specification, and we added it to the charter, would it make sense to exp= and on this text a little bit? I don't think we need to expand further on URI signing. It is obviously cov= ered in details in the corresponding document and the specific security con= siderations associated with URI signing will be detailed there. Cheers Francois In addition, two small nits: - draft-brandenburg-cdni-has, as listed in the references, has bee= n published as RFC6983. - My name in the acknowledgements (BTW: Thanks for that!) is missp= elled. Could you add the =91van=92 in the middle? Thanks! Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: dinsdag 10 september 2013 11:05 To: cdni@ietf.org Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt All, This is the start of a two-week working group last call on draft-ietf-cdni-= framework-05.txt: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list. Francois & Daryl _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BC8677xmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Ray and all,

(speaking as an individual)

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

Hi all,
 
I=92ve reviewed draft-ietf-cdni-framework-= 05. Apart from the following comments, which I would like to see resolved, = I think the document is ready for publication.
 
-      =     I=92ve raised this issue before on the list, but didn=92t see any response, so le= t me include it here again: To my knowledge, the current CDNI documents do = not explicitly address the case of HTTP Byte-range requests. Although in mo= st cases byte-range requests will function just as any other requests, I think there are some cases where by= te-range requests warrant further attention. An example is the Redirection = interface. If a uCDN asks a dCDN to deliver a particular user request (cont= aining a byte range), and the dCDN answers positively, can the uCDN assume that the dCDN accepts any future r= equests for the same file with a different byte range? And if that is the c= ase, is this default behavior or do we need an explicit flag in the inter-C= DN redirection request to indicate the uCDN/dCDN's preference?

In my mind, what really determines if the dCDN will accept to serve a = request received from a client is the metadata distributed by the uCDN for = the corresponding content; and not so much the fact that this particular re= quest was redirected by the uCDN or not.
So in the particular case where byte-range is used in a client request= , then the dCDN will makes its decision to honor or not the request based o= n the CDNI metadata for that content. At this stage, CDNI metadata is assoc= iated to a URI (or groups of URI) , and cannot be associated to a subset of bytes for that URI. So, this mea= ns that the dCDN would always the same access control rules regardless of t= he byte range, which means by default that if a certain byte range is allow= ed, then all other byte ranges are allowed.

Would some text capturing the above help?
Or do you see a strong requirement for wanting to do something differe= nt? 

To be clear: I don't think we need any new= functionality to handle byte-range requests, but a few sentences in either= the Framework or the RI document might clear up any future uncertainty. Since the framework document will be publ= ished first, I would like to have discussion now.
-      =     The security section contains the following text: =93CDNs today offer a variet= y of means to control access to content, such as time-of-day restrictions, = geo-blocking, and URI signing. These mechanisms must continue to function i= n CDNI environments, and this consideration is likely to affect the design of certain CDNI interfaces (e.g. metadata, = request routing.)=94. Now that we, as a group, have decided that URI signin= g warrants its own specification, and we added it to the charter, would it = make sense to expand on this text a little bit?

I don't think we need to expand further on URI signing. It is obviousl= y covered in details in the corresponding document and the specific securit= y considerations associated with URI signing will be detailed there.

Cheers

Francois

 
In addition, two small nits:
 
-      =     draft-brandenburg-cdni-has, as listed in the references, has been published as RFC6983.
-      =     My name in the acknowledgements (BTW: Thanks for that!) is misspelled. Could = you add the =91van=92 in the middle? Thanks!
 
Best regards,
 
Ray
 
From:&nbs= p;cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)=
Sent: dinsdag 10 s= eptember 2013 11:05
To: cdni@ietf.org
Subject: [CDNi] St= art of WG Last Call on draft-ietf-cdni-framework-05.txt
 
All,

This is the start of a two-week working group last call on draft-ietf-= cdni-framework-05.txt:
https://datatracker.ietf.= org/doc/draft-ietf-cdni-framework

This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list.

Francois & Daryl
_______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdn= i

--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BC8677xmbrcdx10ciscoc_-- From spencerdawkins.ietf@gmail.com Thu Sep 19 14:37: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 13D6221F85EE for ; Thu, 19 Sep 2013 14:37: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=[AWL=0.000, 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 XrbfTVZy020G for ; Thu, 19 Sep 2013 14:37:17 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B493621F87F5 for ; Thu, 19 Sep 2013 14:37:13 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id gq1so10885158obb.31 for ; Thu, 19 Sep 2013 14:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ZthC0Vm3w24yNtQY/8jq/+O8MZcJN+nqqaX0CnmnDCo=; b=ggLbKQ9xb69zG0ufE9m5AzOi0bR9mil5XIXwS/XRn60E/jAhtPaGyrqHcGulB0bzz7 iQM7DcmF9wwwwwd7kE9TBu3spkT20JjpurtzDxi/CmEAgHsw1pY9g/hRfM19zuTACkjd FPZ6Xao84KbxqGO34v02XJzaYG6XAe9gaQZw7r24mYlJdZfy1LeNGh3I4WpOTSWxdOj5 dmYGtGnnVE4ga9Ssyt+AoXDSRNK2WLd/GiAknGQykfMyEl0WO+CpvW7DH7/8DNpvy18O 0tx0JPMcyJUmYjPxSm5c8BSXs+hKE0wIh1/rqSLQYgPoz3qfyAK1iym+NPn2QiuE2XJq 5A9A== X-Received: by 10.60.70.134 with SMTP id m6mr2860449oeu.14.1379626633223; Thu, 19 Sep 2013 14:37:13 -0700 (PDT) Received: from [192.168.0.23] (70-3-10-184.pools.spcsdns.net. [70.3.10.184]) by mx.google.com with ESMTPSA id rr6sm5160431oeb.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 19 Sep 2013 14:37:12 -0700 (PDT) Message-ID: <523B6E5B.6060508@gmail.com> Date: Thu, 19 Sep 2013 16:36:27 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Daryl Malas References: <20130919110031.19266.92140.idtracker@ietfa.amsl.com> In-Reply-To: <20130919110031.19266.92140.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , cdni@ietf.org Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 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, 19 Sep 2013 21:37:18 -0000 On 9/19/2013 6:00 AM, Daryl Malas wrote: > Daryl Malas has requested publication of draft-ietf-cdni-requirements-10 as Informational on behalf of the CDNI working group. > > Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/ > Hi, Daryl, Thank you for the helpful shepherd writeup. These are my notes from reading through the document. I found it well-written and clear (thank you, editors and working group). I have some pre-IETF Last Call questions that I'd like to ask before moving forward. Please consider them, and let me know if the working group needs to make any text changes. I may also be asking questions that would be more appropriate for another document in the series, so "great question, but not now" could be a fine response. As a high-order bit, I didn't see any requirements for managing the interfaces. That could be OK, or you may have enough requirements in the various sections that when you add them together, you don't need any additional requirements specifically for management, but I wanted to ask before someone else did. As a high-order bit, my questions about GEN-10/GEN-11, RI-5, LI-9 and SEC-1 might require discussion (which would be fine). My other questions are either about clarity or nits. In Section 2. CDNI Model and CDNI Interfaces I found the use of two different line types with the same description odd in Figure 1. Is this just because the figure looked funny with one line type? Or is there something more subtle going on? <==> interfaces inside the scope of CDNI **** interfaces outside the scope of CDNI .... interfaces outside the scope of CDNI In Section 3. Generic CDNI Requirements GEN-3 [HIGH] The CDNI solution shall not require a change, or an upgrade, to the Content Service Provider to benefit from content delivery through interconnected CDNs. I wasn't sure what this requirement meant (change or upgrade from what?). I'm not having a problem with the near-identical GEN-2, only with GEN-3. You provide examples in GEN-4. Could you provide an example here? In the same section, I was confused by GEN-10 and GEN-11: GEN-10 [MED] The CDNI solution should support an arbitrary topology of interconnected CDNs (i.e. the CDN topology cannot be restricted to a tree, a loop-free topology, etc.). Is this "the CDN topology" or "the topology of interconnected CDNs"? I noticed this because I was looking at GEN-11, which says GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI information exchange. If GEN-10 is about "the topology of interconnected CDNs", and doesn't guarantee that the topology is loop-free, I was wondering if this requirement was about preventing looping or detecting looping. In 4. CDNI Control Interface Requirements CI-4 [HIGH] The CDNI Control interface shall allow the Downstream CDN to report on the completion of these actions (by itself, and including downstream cascaded CDNs, in a manner appropriate for the action (e.g. synchronously or asynchronously). The confirmation receipt should include a success or failure indication. The failure indication along with the reason are used if the Downstream CDN cannot delete the content in its storage. Perhaps s/are used if/are included if/ might be clearer. In the same section, CI-11 [LOW] The CDNI Control interface may allow bootstrapping of the Content Acquisition interface. This could, for example, include exchange and negotiation of the Content Acquisition protocols to be used across the CDNs (e.g. HTTP, HTTPS, FTP, ATIS C2). Is "HTTPS" actually a protocol? And adding a reference for "ATIS C2" would be helpful. In 5. CDNI Request Routing Redirection Interface Requirements RI-1 [HIGH] The CDNI Request Routing Redirection interface shall support efficient request-routing for small objects. This may, for example, call for a mode of operation (e.g. DNS- based request routing) where freshness and accuracy of CDN/ Surrogate selection can be traded-off against reduced request- routing load (e.g. Via lighter-weight queries and caching of request-routing decisions). and RI-2 [HIGH] The CDNI Request Routing Redirection interface shall support efficient request-routing for large objects. This may, for example, call for a mode of operation (e.g. HTTP- based request routing) where freshness and accuracy of CDN/ Surrogate selection justifies a per-request decision and a per-request CDNI Request-Routing protocol call. I'm not sure what "efficient" implies here, perhaps because I see the examples but don't know what other efficiencies might be required. In the same section, RI-5 [MED] In case of detection of a request redirection loop, the CDNI Request Routing Redirection interface's loop prevention mechanism should allow routing of the request by avoiding the loop (as opposed to the request loop being simply interrupted without routing the request). I'm not understanding what "by avoiding the loop" means. I can guess, but I'm guessing. In the same section, RI-6 [MED] The CDNI Request Routing Redirection interface should support a mechanism allowing enforcment of a limit on the number of successive CDN redirections for a given request. I noticed a nit: s/enforcment/enforcement/ In Section 7. CDNI Metadata Interface Requirements MI-19 [MED] The CDNI Metadata interface should support an optional mechanism allowing the Upstream CDN to indicate to the Downstream CDN which CDNI Log fields 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 shall ignore this log format indication and generate CDNI logging format for HTTP Adaptive Streaming using the default set of CDNI Logging fields. (Note: this function is not concluded to be in Metadata Interface or Control Interface) I didn't understand the parenthetical note at the end of MI-19 - what does "is not concluded to be in" mean? I can guess, but I'm guessing. In Section 8. CDNI Logging Interface Requirements LI-9 [LOW] The CDNI Logging interface may support aggregate/ summarized logs (e.g. total bytes delivered for a content regardless of individual User Agents to which it was delivered). This requirement is fine, but I didn't see requirements that applied to how the Upstream CDN and Downstream CDN communicated what aggregates/summarized logs were available. If this is captured under "extensible" elsewhere in the section, that's fine. In Section 9. CDNI Security Requirements SEC-1 [HIGH] All the CDNI interface shall support secure operation over unsecured IP connectivity (e.g. The Internet). This includes authentication, confidentiality, integrity protection as well as protection against spoofing and replay. This is excellent, as far as it goes. You might consider whether the requirements go far enough to protect privacy, in a "pervasive passive monitoring" world - perhaps the combination of "unsecured IP connectivity" plus unsecured HTTP as a supported transport has implications for privacy that affect CDNI at the requirements level? (If not, you might consider pointing that out in the Security Considerations section, because that conversation now will be less painful than the same conversation during evaluation of a protocol draft :-) From ray.vanbrandenburg@tno.nl Fri Sep 20 00:36:07 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB9721F8AF4 for ; Fri, 20 Sep 2013 00:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a3I+GRLtcStO for ; Fri, 20 Sep 2013 00:36:02 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 426D021F8A38 for ; Fri, 20 Sep 2013 00:35:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.90,941,1371074400"; d="scan'208,217";a="14218274" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 20 Sep 2013 09:35:55 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.176]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.03.0123.003; Fri, 20 Sep 2013 09:35:55 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt Thread-Index: AQHOrgTZE6q75/TV/EmEyhFJC28T5ZnJlOxwgAOoSoCAAQxq8A== Date: Fri, 20 Sep 2013 07:35:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581F49F0F1EXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-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: Fri, 20 Sep 2013 07:36:07 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F49F0F1EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Francois, See inline. Ray From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] Sent: donderdag 19 september 2013 19:27 To: Brandenburg, R. (Ray) van Cc: cdni@ietf.org Subject: Re: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.t= xt Ray and all, (speaking as an individual) On 17 Sep 2013, at 09:43, "Brandenburg, R. (Ray) van" > wrote: Hi all, I've reviewed draft-ietf-cdni-framework-05. Apart from the following commen= ts, which I would like to see resolved, I think the document is ready for p= ublication. - I've raised this issue before on the list, but didn't see any re= sponse, so let me include it here again: To my knowledge, the current CDNI = documents do not explicitly address the case of HTTP Byte-range requests. A= lthough in most cases byte-range requests will function just as any other r= equests, I think there are some cases where byte-range requests warrant fur= ther attention. An example is the Redirection interface. If a uCDN asks a d= CDN to deliver a particular user request (containing a byte range), and the= dCDN answers positively, can the uCDN assume that the dCDN accepts any fut= ure requests for the same file with a different byte range? And if that is = the case, is this default behavior or do we need an explicit flag in the in= ter-CDN redirection request to indicate the uCDN/dCDN's preference? In my mind, what really determines if the dCDN will accept to serve a reque= st received from a client is the metadata distributed by the uCDN for the c= orresponding content; and not so much the fact that this particular request= was redirected by the uCDN or not. So in the particular case where byte-range is used in a client request, the= n the dCDN will makes its decision to honor or not the request based on the= CDNI metadata for that content. At this stage, CDNI metadata is associated= to a URI (or groups of URI) , and cannot be associated to a subset of byte= s for that URI. So, this means that the dCDN would always the same access c= ontrol rules regardless of the byte range, which means by default that if a= certain byte range is allowed, then all other byte ranges are allowed. Would some text capturing the above help? Or do you see a strong requirement for wanting to do something different? Yes, I was thinking about something along those lines. Again, what I was mo= stly concerned about is the complete lack of any mention of byte ranges and= how they affect CDNI operation. To be clear: I don't think we need any new functionality to handle byte-ran= ge requests, but a few sentences in either the Framework or the RI document= might clear up any future uncertainty. Since the framework document will b= e published first, I would like to have discussion now. - The security section contains the following text: "CDNs today of= fer a variety of means to control access to content, such as time-of-day re= strictions, geo-blocking, and URI signing. These mechanisms must continue t= o function in CDNI environments, and this consideration is likely to affect= the design of certain CDNI interfaces (e.g. metadata, request routing.)". = Now that we, as a group, have decided that URI signing warrants its own spe= cification, and we added it to the charter, would it make sense to expand o= n this text a little bit? I don't think we need to expand further on URI signing. It is obviously cov= ered in details in the corresponding document and the specific security con= siderations associated with URI signing will be detailed there. How I see the framework document, is as a sort of overall CDNI 'system' des= cription, describing how the CDNI interfaces fit together and allowing a pe= rson new to CDNI to get a quick overview. In that sense, I think it would b= e useful to provide a brief discussion on how the URI Signing document ties= in with the other CDNI interfaces. Cheers Francois In addition, two small nits: - draft-brandenburg-cdni-has, as listed in the references, has bee= n published as RFC6983. - My name in the acknowledgements (BTW: Thanks for that!) is missp= elled. Could you add the 'van' in the middle? Thanks! Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: dinsdag 10 september 2013 11:05 To: cdni@ietf.org Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt All, This is the start of a two-week working group last call on draft-ietf-cdni-= framework-05.txt: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list. Francois & Daryl _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FCC100FC8D6B034CB88CD8173B2DA1581F49F0F1EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Francois,
 
See inline.
 
Ray
 
Fr= om: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]
Sent: donderdag 19 september 2013 19:27
To: Brandenburg, R. (Ray) van
Cc: cdni@ietf.org
Subject: Re: [CDNi] Start of WG Last Call on draft-ietf-cdni-framewo= rk-05.txt
 
Ray and all,
 
(speaking as an individual)
 
On 17 Sep 2013, at 09:43, "Brandenburg, R. (Ray) van" <ray.vanbr= andenburg@tno.nl>
 wrote:

Hi all,
 
I’ve reviewed draft-ietf-cdni-framework-= 05. Apart from the following comments, which I would like to see resolved, = I think the document is ready for publication.
 
-   =        I’= ;ve raised this issue before on the list, but didn’t see any response, so let me include it here a= gain: To my knowledge, the current CDNI documents do not explicitly address= the case of HTTP Byte-range requests. Although in most cases byte-range re= quests will function just as any other requests, I think there are some cases where byte-range requests warrant fu= rther attention. An example is the Redirection interface. If a uCDN asks a = dCDN to deliver a particular user request (containing a byte range), and th= e dCDN answers positively, can the uCDN assume that the dCDN accepts any future requests for the same file wit= h a different byte range? And if that is the case, is this default behavior= or do we need an explicit flag in the inter-CDN redirection request to ind= icate the uCDN/dCDN's preference?
 
In my mind, what really determines if the dCDN will accept to serve a r= equest received from a client is the metadata distributed by the uCDN for t= he corresponding content; and not so much the fact that this particular request was redirected by the uCDN or not.
So in the particular case where byte-range is used in a client request,= then the dCDN will makes its decision to honor or not the request based on= the CDNI metadata for that content. At this stage, CDNI metadata is associated to a URI (or groups of URI) , and c= annot be associated to a subset of bytes for that URI. So, this means that = the dCDN would always the same access control rules regardless of the byte = range, which means by default that if a certain byte range is allowed, then all other byte ranges are allowed.=
 
Would some text capturing the above help?
Or do you see a strong requirement for wanting to do something differen= t? 
 
Yes, I was thinking about something along thos= e lines. Again, what I was mostly concerned about is the complete lack of a= ny mention of byte ranges and how they affect CDNI operation.
 
 
To be clear: I do= n't think we need any new functionality to handle byte-range requests, but = a few sentences in either the Framework or the RI document might clear up a= ny future uncertainty. Since the framework document will be published first, I would like to have discussion now.
-   =        The sec= urity section contains the following text: “CDNs today offer a variety of means to control a= ccess to content, such as time-of-day restrictions, geo-blocking, and URI s= igning. These mechanisms must continue to function in CDNI environments, an= d this consideration is likely to affect the design of certain CDNI interfaces (e.g. metadata, request routing.)R= 21;. Now that we, as a group, have decided that URI signing warrants its ow= n specification, and we added it to the charter, would it make sense to exp= and on this text a little bit?
 
I don't think we need to expand further on URI signing. It is obviously= covered in details in the corresponding document and the specific security= considerations associated with URI signing will be detailed there.
 
How I see the framework document, is as a sort= of overall CDNI ‘system’ description, describing how the CDNI = interfaces fit together and allowing a person new to CDNI to get a quick ov= erview. In that sense, I think it would be useful to provide a brief discussion on how the URI Signing document ties in with = the other CDNI interfaces.
 
 
Cheers
 
Francois

 
In addition, two small nits:
 
-   =        draft-b= randenburg-cdni-has, as listed in the references, has been published as RFC6983.
-   =        My name= in the acknowledgements (BTW: Thanks for that!) is misspelled. Could you add the ‘van’ = in the middle? Thanks!
 
Best regards,
 
Ray
 
Fr= om: = cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org= ] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 10 september 2013 11:05
To: cd= ni@ietf.org
Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framew= ork-05.txt
 
All,

This is the start of a two-week working group last call on draft-ietf-= cdni-framework-05.txt:
https://datatracker.ietf.org/doc/draft-ietf-cdni-fram= ework

This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list.

Francois & Daryl
= _______________________________________________
CDNi mailing list
CDNi@ietf.org
https://www.ietf.org/mailman/listinfo/cdni
 
 
 --_000_FCC100FC8D6B034CB88CD8173B2DA1581F49F0F1EXCMBX03tsntnon_-- From flefauch@cisco.com Fri Sep 20 00:43: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 3F49621F8AF4 for ; Fri, 20 Sep 2013 00:43:13 -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 iFlH7AhICcsV for ; Fri, 20 Sep 2013 00:43:08 -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 19D8121F8A84 for ; Fri, 20 Sep 2013 00:43:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16575; q=dns/txt; s=iport; t=1379662988; x=1380872588; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eOHI+AXfVT03IPWkHB1taX8BGTGUqiGn0zAjWYggNZ8=; b=LodnYdDy/eZiAHLLfS+mTFo0vt8JzRacRI1yNjnNWnO598X44R/zmfEO eYaOKQ7Kr62uODoiMu8m2fozeM1md+PQV7mYvwJztYC5pqkC16oYWiIu0 4PcwhwS/4C9SApJjon7dKg+9d7K4AG9A2eqynmfRd8aoD5tvLanj48bXR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAC77O1KtJXG9/2dsb2JhbABbgkNEOFLBNIEZFnSCJQEBAQQBAQFrBgUQAgEIEQQBAQsdBycLFAkIAgQOBQiHewy6cwSPNi0EBgGDHoEAA4VOpCODJIIq X-IronPort-AV: E=Sophos;i="4.90,941,1371081600"; d="scan'208,217";a="262084968" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 20 Sep 2013 07:43:06 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8K7h6JT020708 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 07:43:06 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 02:43:05 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt Thread-Index: AQHOrgTZE6q75/TV/EmEyhFJC28T5ZnOn9yAgAAB/wA= Date: Fri, 20 Sep 2013 07:43:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.103.45] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04BC946Bxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-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: Fri, 20 Sep 2013 07:43:13 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BC946Bxmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 20 Sep 2013, at 09:35, "Brandenburg, R. (Ray) van" > - I=92ve raised this issue before on the list, but didn=92t see an= y response, so let me include it here again: To my knowledge, the current C= DNI documents do not explicitly address the case of HTTP Byte-range request= s. Although in most cases byte-range requests will function just as any oth= er requests, I think there are some cases where byte-range requests warrant= further attention. An example is the Redirection interface. If a uCDN asks= a dCDN to deliver a particular user request (containing a byte range), and= the dCDN answers positively, can the uCDN assume that the dCDN accepts any= future requests for the same file with a different byte range? And if that= is the case, is this default behavior or do we need an explicit flag in th= e inter-CDN redirection request to indicate the uCDN/dCDN's preference? In my mind, what really determines if the dCDN will accept to serve a reque= st received from a client is the metadata distributed by the uCDN for the c= orresponding content; and not so much the fact that this particular request= was redirected by the uCDN or not. So in the particular case where byte-range is used in a client request, the= n the dCDN will makes its decision to honor or not the request based on the= CDNI metadata for that content. At this stage, CDNI metadata is associated= to a URI (or groups of URI) , and cannot be associated to a subset of byte= s for that URI. So, this means that the dCDN would always the same access c= ontrol rules regardless of the byte range, which means by default that if a= certain byte range is allowed, then all other byte ranges are allowed. Would some text capturing the above help? Or do you see a strong requirement for wanting to do something different? Yes, I was thinking about something along those lines. Again, what I was mo= stly concerned about is the complete lack of any mention of byte ranges and= how they affect CDNI operation. all fine then. - The security section contains the following text: =93CDNs today = offer a variety of means to control access to content, such as time-of-day = restrictions, geo-blocking, and URI signing. These mechanisms must continue= to function in CDNI environments, and this consideration is likely to affe= ct the design of certain CDNI interfaces (e.g. metadata, request routing.)= =94. Now that we, as a group, have decided that URI signing warrants its ow= n specification, and we added it to the charter, would it make sense to exp= and on this text a little bit? I don't think we need to expand further on URI signing. It is obviously cov= ered in details in the corresponding document and the specific security con= siderations associated with URI signing will be detailed there. How I see the framework document, is as a sort of overall CDNI =91system=92= description, describing how the CDNI interfaces fit together and allowing = a person new to CDNI to get a quick overview. In that sense, I think it wou= ld be useful to provide a brief discussion on how the URI Signing document = ties in with the other CDNI interfaces. I see, but then this brief discussion would probably not belong in the secu= rity considerations section. It could be a small section somewhere in the b= ody of the documents. I personally woudl be fine with that. Francois Cheers Francois In addition, two small nits: - draft-brandenburg-cdni-has, as listed in the references, has bee= n published as RFC6983. - My name in the acknowledgements (BTW: Thanks for that!) is missp= elled. Could you add the =91van=92 in the middle? Thanks! Best regards, Ray From: cdni-bounces@ietf.org [mailto:cdni-boun= ces@ietf.org] On Behalf Of Francois Le Faucheur (f= lefauch) Sent: dinsdag 10 september 2013 11:05 To: cdni@ietf.org Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framework-05.txt All, This is the start of a two-week working group last call on draft-ietf-cdni-= framework-05.txt: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list. Francois & Daryl _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BC946Bxmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 20 Sep 2013, at 09:35, "Brandenburg, R. (Ray) van" <ray.vanbrandenburg@tno.nl>= ;
 
-  &n= bsp;       I= =92ve raised this issue before on the list, but didn=92t see any response, so let me include it here agai= n: To my knowledge, the current CDNI documents do not explicitly address th= e case of HTTP Byte-range requests. Although in most cases byte-range reque= sts will function just as any other requests, I think there are some cases where byte-range requests warrant f= urther attention. An example is the Redirection interface. If a uCDN asks a= dCDN to deliver a particular user request (containing a byte range), and t= he dCDN answers positively, can the uCDN assume that the dCDN accepts any future requests for the same fil= e with a different byte range? And if that is the case, is this default beh= avior or do we need an explicit flag in the inter-CDN redirection request t= o indicate the uCDN/dCDN's preference?
 
In my mind, what really determines if the dCDN will accept to serve a= request received from a client is the metadata distributed by the uCDN for= the corresponding content; and not so much the fact that this particular request was redirected by the uCDN or n= ot.
So in the particular case where byte-range is used in a client reques= t, then the dCDN will makes its decision to honor or not the request based = on the CDNI metadata for that content. At this stage, CDNI metadata is associated to a URI (or groups of URI) , a= nd cannot be associated to a subset of bytes for that URI. So, this means t= hat the dCDN would always the same access control rules regardless of the b= yte range, which means by default that if a certain byte range is allowed, then all other byte ranges are al= lowed.
 
Would some text capturing the above help?
Or do you see a strong requirement for wanting to do something differ= ent? 
 
Yes, I was thinking about something along thos= e lines. Again, what I was mostly concerned about is the complete lack of a= ny mention of byte ranges and how they affect CDNI operation.

all fine then.

-&n= bsp;         The security section contains the following text: =93CDNs today offer a variet= y of means to control access to content, such as time-of-day restrictions, = geo-blocking, and URI signing. These mechanisms must continue to function i= n CDNI environments, and this consideration is likely to affect the design of certain CDNI interfaces (e.g. metadata, = request routing.)=94. Now that we, as a group, have decided that URI signin= g warrants its own specification, and we added it to the charter, would it = make sense to expand on this text a little bit?
 
I don't think we need to expand further on URI signing. It is obvious= ly covered in details in the corresponding document and the specific securi= ty considerations associated with URI signing will be detailed there.
 
How I see the framework document, is as a sort= of overall CDNI =91system=92 description, describing how the CDNI interfac= es fit together and allowing a person new to CDNI to get a quick overview. = In that sense, I think it would be useful to provide a brief discussion on how the URI Signing document ties in with= the other CDNI interfaces.

I see, but then this brief discussion would probably not belong in the= security considerations section. It could be a small section somewhere in = the body of the documents.
I personally woudl be fine with that.

Francois


 
 
Cheers
 
Francois

 
In addition, two small nits:
 
-  &n= bsp;       d= raft-brandenburg-cdni-has, as listed in the references, has been published as RFC6983.
-  &n= bsp;       M= y name in the acknowledgements (BTW: Thanks for that!) is misspelled. Could you add the =91van=92 in the = middle? Thanks!
 
Best regards,
 
Ray
 
= From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Francois Le Faucheur (flefauch)
Sent: dinsdag 10 september 2013 11:05
To: cd= ni@ietf.org
Subject: [CDNi] Start of WG Last Call on draft-ietf-cdni-framew= ork-05.txt
 
All,

This is the start of a two-week working group last call on draft-ietf-= cdni-framework-05.txt:
https://datatracker.ietf.org/doc/draft-ietf-cdni-fram= ework

This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list.

Francois & Daryl

--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BC946Bxmbrcdx10ciscoc_-- From flefauch@cisco.com Fri Sep 20 07:59:07 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00B921F841B for ; Fri, 20 Sep 2013 07:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 VkddLSHzWK8z for ; Fri, 20 Sep 2013 07:58:53 -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 21C9A21F9B21 for ; Fri, 20 Sep 2013 07:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12017; q=dns/txt; s=iport; t=1379689132; x=1380898732; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OzvFDFyewgcWiEdi0HfGNsTkKsUqmf00Iy7UifUPyEE=; b=juiuWcsnD7rHC6xCE5Vw1vz1467OEnA3dXuAUHtIM81ZeEIp1y85DRBb uOW4YzPPCVSmdfJKb3t6lHNxASmI1BO6nGPR5hCWKSmw7WigzV99jdVxY i6Bt27doNsWeKm/lykEl5BsZ+lfNAIA9yXh2pfo3dqrip6eHi6f/OhD0Z 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAEViPFKtJV2a/2dsb2JhbABbgwc4UrBckF2BGhZ0ggoBGgEBAQMBAQEBGh00BgUFCwIBCBgKDwUQIQYLJQIEDgUIE4dYAwkGDLBlDYlqjHeBMAuBAAIxB4MegQADlB+BdIMYixSFM4FfgUWBaUE X-IronPort-AV: E=Sophos;i="4.90,944,1371081600"; d="scan'208";a="262422518" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 20 Sep 2013 14:58:50 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8KEwotE030639 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Sep 2013 14:58:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 20 Sep 2013 09:58:50 -0500 From: "Francois Le Faucheur (flefauch)" To: Spencer Dawkins Thread-Topic: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 Thread-Index: AQHOtYB7tf0wxTG9T0CtI/0d8V1yQJnPDKIA Date: Fri, 20 Sep 2013 14:58:49 +0000 Message-ID: References: <20130919110031.19266.92140.idtracker@ietfa.amsl.com> <523B6E5B.6060508@gmail.com> In-Reply-To: <523B6E5B.6060508@gmail.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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 14:59:09 -0000 Hi Spencer, Great to have a review performed with a fresh eye. My personal thoughts emb= edded below: On 19 Sep 2013, at 23:36, Spencer Dawkins w= rote: > On 9/19/2013 6:00 AM, Daryl Malas wrote: >> Daryl Malas has requested publication of draft-ietf-cdni-requirements-10= as Informational on behalf of the CDNI working group. >>=20 >> Please verify the document's state at http://datatracker.ietf.org/doc/dr= aft-ietf-cdni-requirements/ >>=20 >=20 > Hi, Daryl, >=20 > Thank you for the helpful shepherd writeup. >=20 > These are my notes from reading through the document. I found it well-wri= tten and clear (thank you, editors and working group). >=20 > I have some pre-IETF Last Call questions that I'd like to ask before movi= ng forward. Please consider them, and let me know if the working group need= s to make any text changes. >=20 > I may also be asking questions that would be more appropriate for another= document in the series, so "great question, but not now" could be a fine r= esponse. >=20 > As a high-order bit, I didn't see any requirements for managing the inter= faces. That could be OK, or you may have enough requirements in the various= sections that when you add them together, you don't need any additional re= quirements specifically for management, but I wanted to ask before someone = else did. >=20 > As a high-order bit, my questions about GEN-10/GEN-11, RI-5, LI-9 and SEC= -1 might require discussion (which would be fine). My other questions are e= ither about clarity or nits. >=20 > In Section 2. CDNI Model and CDNI Interfaces >=20 > I found the use of two different line types with the same description odd= in Figure 1. Is this just because the figure looked funny with one line ty= pe? Or is there something more subtle going on? It was purely to make the figure more readable. The figure shows different = interafces that crosses each other and it just seemed easier to read it wit= h different symbols. We use the same pictorial convention in RFC6707 (CDNI Problem Statement), s= o I'd usggest keeping it as is. >=20 > <=3D=3D> interfaces inside the scope of CDNI > **** interfaces outside the scope of CDNI > .... interfaces outside the scope of CDNI >=20 > In Section 3. Generic CDNI Requirements >=20 > GEN-3 [HIGH] The CDNI solution shall not require a change, or an > upgrade, to the Content Service Provider to benefit from > content delivery through interconnected CDNs. >=20 > I wasn't sure what this requirement meant (change or upgrade from what?). I believe that what this is trying to say is that if a CSP currently uses a= single CDN for content delivery, then if that CDN decides to leverages oth= er CDNs via CDNI, the solution should allow this to happen transparently. T= o illustrate the point, if the CDNI solution imposed that all URIs be struc= tured in some rigid way and therefore imposed that the CSP modifies all the= ir URIs listed in their content portal, that would be a bad solution. > I'm not having a problem with the near-identical GEN-2, only with GEN-3. = You provide examples in GEN-4. Could you provide an example here? >=20 > In the same section, I was confused by GEN-10 and GEN-11: >=20 > GEN-10 [MED] The CDNI solution should support an arbitrary topology > of interconnected CDNs (i.e. the CDN topology cannot be > restricted to a tree, a loop-free topology, etc.). >=20 > Is this "the CDN topology" or "the topology of interconnected CDNs"? It is the "the topology of interconnected CDNs". I agree text can make that= more explicit. > I noticed this because I was looking at GEN-11, which says >=20 > GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI > information exchange. >=20 > If GEN-10 is about "the topology of interconnected CDNs", and doesn't gua= rantee that the topology is loop-free, I was wondering if this requirement = was about preventing looping or detecting looping. Well, I think the key requirement here is that the ongoing looping of infor= mation be prevented. There are multiple ways this might be achieved (eg hav= e a solution that absolutely guarantees it never happens even during transi= ent situations, or have a solution that detects it if/when it happens and t= hen interrupts it). In fact, different CDNI interfaces may use different me= chanisms to prevent such loops. I don't think this particular requirement n= eeds to mandate one approach. >=20 > In 4. CDNI Control Interface Requirements >=20 > CI-4 [HIGH] The CDNI Control interface shall allow the Downstream > CDN to report on the completion of these actions (by itself, > and including downstream cascaded CDNs, in a manner > appropriate for the action (e.g. synchronously or > asynchronously). The confirmation receipt should include a > success or failure indication. The failure indication along > with the reason are used if the Downstream CDN cannot delete > the content in its storage. >=20 > Perhaps s/are used if/are included if/ might be clearer. Agreed. >=20 > In the same section, >=20 > CI-11 [LOW] The CDNI Control interface may allow bootstrapping of > the Content Acquisition interface. This could, for example, > include exchange and negotiation of the Content Acquisition > protocols to be used across the CDNs (e.g. HTTP, HTTPS, FTP, > ATIS C2). >=20 > Is "HTTPS" actually a protocol? Not sure there is a well-accepted definition of protocol. To me "HTTP over = TLS" would probably qualify as a protocol. If you prefer we could just s/Co= ntent Acquisition protocols/Content Acquisition methods. > And adding a reference for "ATIS C2" would be helpful. >=20 > In 5. CDNI Request Routing Redirection Interface Requirements >=20 > RI-1 [HIGH] The CDNI Request Routing Redirection interface shall > support efficient request-routing for small objects. This > may, for example, call for a mode of operation (e.g. DNS- > based request routing) where freshness and accuracy of CDN/ > Surrogate selection can be traded-off against reduced request- > routing load (e.g. Via lighter-weight queries and caching of > request-routing decisions). >=20 > and >=20 > RI-2 [HIGH] The CDNI Request Routing Redirection interface shall > support efficient request-routing for large objects. This > may, for example, call for a mode of operation (e.g. HTTP- > based request routing) where freshness and accuracy of CDN/ > Surrogate selection justifies a per-request decision and a > per-request CDNI Request-Routing protocol call. >=20 > I'm not sure what "efficient" implies here, perhaps because I see the exa= mples but don't know what other efficiencies might be required. As suggested by the examples, the "efficiency" referred to is indeed in ter= ms of trade-offs between request routing load and accuracy of the request r= outing decision. But at the same time, i don't think it is bad if the requirement doesn't co= mpletely close the door on other efficiencies (which may be understood when= finalising teh details of CDNI interfaces).=20 >=20 > In the same section, >=20 > RI-5 [MED] In case of detection of a request redirection loop, the > CDNI Request Routing Redirection interface's loop prevention > mechanism should allow routing of the request by avoiding the > loop (as opposed to the request loop being simply interrupted > without routing the request). >=20 > I'm not understanding what "by avoiding the loop" means. I can guess, but= I'm guessing. How about: " RI-5 [MED] In case of detection of a potential request redirection loop= , the CDNI Request Routing Redirection interface's loop prevention mechanism should prevent or interrupt the loop and allow routing o= f the request (as opposed to the request loop being simply interrupted without routing the request). " >=20 > In the same section, >=20 > RI-6 [MED] The CDNI Request Routing Redirection interface should > support a mechanism allowing enforcment of a limit on the > number of successive CDN redirections for a given request. >=20 > I noticed a nit: s/enforcment/enforcement/ >=20 > In Section 7. CDNI Metadata Interface Requirements >=20 > MI-19 [MED] The CDNI Metadata interface should support an optional > mechanism allowing the Upstream CDN to indicate to the > Downstream CDN which CDNI Log fields 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 shall ignore this log format indication and generate > CDNI logging format for HTTP Adaptive Streaming using the > default set of CDNI Logging fields. (Note: this function is > not concluded to be in Metadata Interface or Control > Interface) >=20 > I didn't understand the parenthetical note at the end of MI-19 - what doe= s "is not concluded to be in" mean? I can guess, but I'm guessing. It was questioned whether this requirement (ie "a mechanism allowing the Up= stream CDN to indicate to the Downstream CDN which CDNI Log fields are to b= e provided") should be realised by the Metadata interface or whether it sho= udl possibly actually be realised by the Control interface. At this stage t= he WG has not concluded that discussion (and the discussion has been paused= since this will not be part of the first version of the interfaces). The note could be improved to make this clearer. >=20 > In Section 8. CDNI Logging Interface Requirements >=20 > LI-9 [LOW] The CDNI Logging interface may support aggregate/ > summarized logs (e.g. total bytes delivered for a content > regardless of individual User Agents to which it was > delivered). >=20 > This requirement is fine, but I didn't see requirements that applied to h= ow the Upstream CDN and Downstream CDN communicated what aggregates/summari= zed logs were available. If this is captured under "extensible" elsewhere i= n the section, that's fine. I would say this is covered by MI-19. This woudl indicate which "aggregate"= fields are to be provided. >=20 > In Section 9. CDNI Security Requirements >=20 > SEC-1 [HIGH] All the CDNI interface shall support secure operation > over unsecured IP connectivity (e.g. The Internet). This > includes authentication, confidentiality, integrity protection > as well as protection against spoofing and replay. >=20 > This is excellent, as far as it goes. You might consider whether the requ= irements go far enough to protect privacy, in a "pervasive passive monitori= ng" world - perhaps the combination of "unsecured IP connectivity" plus uns= ecured HTTP as a supported transport has implications for privacy that affe= ct CDNI at the requirements level? (If not, you might consider pointing tha= t out in the Security Considerations section, because that conversation now= will be less painful than the same conversation during evaluation of a pro= tocol draft :-) In fact, the CDNI Logging interface includes a specific privacy mechanism (= in the form of anonymization of IP addresses). Perhaps a requirement for privacy of CDNI LOgging information should be add= ed? Cheers Francois > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From spencerdawkins.ietf@gmail.com Fri Sep 20 12:02: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 52D7B21F9DE9 for ; Fri, 20 Sep 2013 12:02:06 -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=[AWL=0.000, 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 9jzSClCPbHfd for ; Fri, 20 Sep 2013 12:02:05 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 29DFB21F9E1A for ; Fri, 20 Sep 2013 12:02:00 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id u16so1673006iet.39 for ; Fri, 20 Sep 2013 12:01:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=AElJDufdX1Bmzx/xAH1WYtHrZ4kDJQl++Qzg3If8UDI=; b=a/uhf8tBfwusvhgXKJOp+Vhea4Ycfi8StYf7vms0Iken22IdNwgGvy6L8IkJx9V8Tu 1K5xkm+DlkoZBKpRridNDvR9u2ywxMf2EhWiNN7BhvIOI0pRcfJh5VKqW6O2khegW3BH oXslGlSgIHddo8zzkeDzYN2hJlUmDPdWEcDE3gJHfizCac1G/QKic2rm4bHm4J0WSeAi 6tTS3YZeswtVHpn9qVxrTblDKoNzDAdrPzheGWskif13jgwMMsdl2WjsfhrBXwYe8CnO Ngu6hQUmWBZAfzpU4btUGhOW+NqPY/JeL12BuS67FOzPjOIQZE3MtQjmOH+OA55RtgQQ xUYA== X-Received: by 10.43.19.198 with SMTP id ql6mr5397542icb.22.1379703719589; Fri, 20 Sep 2013 12:01:59 -0700 (PDT) Received: from [192.168.0.30] (70-3-10-184.pools.spcsdns.net. [70.3.10.184]) by mx.google.com with ESMTPSA id yt10sm3905788igb.9.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 20 Sep 2013 12:01:58 -0700 (PDT) Message-ID: <523C9BA9.5050506@gmail.com> Date: Fri, 20 Sep 2013 14:02:01 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Francois Le Faucheur (flefauch)" References: <20130919110031.19266.92140.idtracker@ietfa.amsl.com> <523B6E5B.6060508@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Sep 2013 19:02:06 -0000 On 9/20/2013 9:58 AM, Francois Le Faucheur (flefauch) wrote: > Hi Spencer, > > Great to have a review performed with a fresh eye. My personal thoughts embedded below: Thanks for a quick response with personal thoughts :-) We're in sync on everything but my question about RI-5. This is going really well! Please see inline ... > On 19 Sep 2013, at 23:36, Spencer Dawkins wrote: > >> On 9/19/2013 6:00 AM, Daryl Malas wrote: >>> Daryl Malas has requested publication of draft-ietf-cdni-requirements-10 as Informational on behalf of the CDNI working group. >>> >>> Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/ >>> >> Hi, Daryl, >> >> Thank you for the helpful shepherd writeup. >> >> These are my notes from reading through the document. I found it well-written and clear (thank you, editors and working group). >> >> I have some pre-IETF Last Call questions that I'd like to ask before moving forward. Please consider them, and let me know if the working group needs to make any text changes. >> >> I may also be asking questions that would be more appropriate for another document in the series, so "great question, but not now" could be a fine response. >> >> As a high-order bit, I didn't see any requirements for managing the interfaces. That could be OK, or you may have enough requirements in the various sections that when you add them together, you don't need any additional requirements specifically for management, but I wanted to ask before someone else did. >> >> As a high-order bit, my questions about GEN-10/GEN-11, RI-5, LI-9 and SEC-1 might require discussion (which would be fine). My other questions are either about clarity or nits. >> >> In Section 2. CDNI Model and CDNI Interfaces >> >> I found the use of two different line types with the same description odd in Figure 1. Is this just because the figure looked funny with one line type? Or is there something more subtle going on? > It was purely to make the figure more readable. The figure shows different interafces that crosses each other and it just seemed easier to read it with different symbols. > We use the same pictorial convention in RFC6707 (CDNI Problem Statement), so I'd usggest keeping it as is. > >> <==> interfaces inside the scope of CDNI >> **** interfaces outside the scope of CDNI >> .... interfaces outside the scope of CDNI "More readable" was my guess, so definitely not suggesting a change to the figure itself. The editors might consider something like <==> interfaces inside the scope of CDNI **** and .... interfaces outside the scope of CDNI as the legend. I was guessing the text for "...." was a cut-and-paste error from the previous line, and I think that's the most likely response from any first-time reader. >> In Section 3. Generic CDNI Requirements >> >> GEN-3 [HIGH] The CDNI solution shall not require a change, or an >> upgrade, to the Content Service Provider to benefit from >> content delivery through interconnected CDNs. >> >> I wasn't sure what this requirement meant (change or upgrade from what?). > I believe that what this is trying to say is that if a CSP currently uses a single CDN for content delivery, then if that CDN decides to leverages other CDNs via CDNI, the solution should allow this to happen transparently. To illustrate the point, if the CDNI solution imposed that all URIs be structured in some rigid way and therefore imposed that the CSP modifies all their URIs listed in their content portal, that would be a bad solution. Your explanation helped a LOT. Somewhat frustratingly, almost all the words in your explanation are in the requirement I couldn't understand :D What you added, which made the same words clearer, was the point about a CSP using a single CDN and then deciding to leverage interconnected CDNs. Perhaps the editors could consider a better version of "The CNDI solution shall not require a change, or an upgrade, to the Content Service Provider delivering content through a single CDN, to benefit from content delivery through interconnected CDNs." That answers my "from what?" question. > >> I'm not having a problem with the near-identical GEN-2, only with GEN-3. You provide examples in GEN-4. Could you provide an example here? >> >> In the same section, I was confused by GEN-10 and GEN-11: >> >> GEN-10 [MED] The CDNI solution should support an arbitrary topology >> of interconnected CDNs (i.e. the CDN topology cannot be >> restricted to a tree, a loop-free topology, etc.). >> >> Is this "the CDN topology" or "the topology of interconnected CDNs"? > It is the "the topology of interconnected CDNs". I agree text can make that more explicit. Ack. > >> I noticed this because I was looking at GEN-11, which says >> >> GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI >> information exchange. >> >> If GEN-10 is about "the topology of interconnected CDNs", and doesn't guarantee that the topology is loop-free, I was wondering if this requirement was about preventing looping or detecting looping. > Well, I think the key requirement here is that the ongoing looping of information be prevented. There are multiple ways this might be achieved (eg have a solution that absolutely guarantees it never happens even during transient situations, or have a solution that detects it if/when it happens and then interrupts it). In fact, different CDNI interfaces may use different mechanisms to prevent such loops. I don't think this particular requirement needs to mandate one approach. I agree, but I was reading "prevent looping" in the text as requiring an absolute guarantee, so mandating one approach. Perhaps something like "shall prevent persistent looping" would capture what you're describing? > >> In 4. CDNI Control Interface Requirements >> >> CI-4 [HIGH] The CDNI Control interface shall allow the Downstream >> CDN to report on the completion of these actions (by itself, >> and including downstream cascaded CDNs, in a manner >> appropriate for the action (e.g. synchronously or >> asynchronously). The confirmation receipt should include a >> success or failure indication. The failure indication along >> with the reason are used if the Downstream CDN cannot delete >> the content in its storage. >> >> Perhaps s/are used if/are included if/ might be clearer. > Agreed. Ack. >> In the same section, >> >> CI-11 [LOW] The CDNI Control interface may allow bootstrapping of >> the Content Acquisition interface. This could, for example, >> include exchange and negotiation of the Content Acquisition >> protocols to be used across the CDNs (e.g. HTTP, HTTPS, FTP, >> ATIS C2). >> >> Is "HTTPS" actually a protocol? > Not sure there is a well-accepted definition of protocol. To me "HTTP over TLS" would probably qualify as a protocol. If you prefer we could just s/Content Acquisition protocols/Content Acquisition methods. Your suggested "s/Content Acquisition protocols/Content Acquisition methods" works better than anything I was able to suggest. Thanks! >> And adding a reference for "ATIS C2" would be helpful. >> >> In 5. CDNI Request Routing Redirection Interface Requirements >> >> RI-1 [HIGH] The CDNI Request Routing Redirection interface shall >> support efficient request-routing for small objects. This >> may, for example, call for a mode of operation (e.g. DNS- >> based request routing) where freshness and accuracy of CDN/ >> Surrogate selection can be traded-off against reduced request- >> routing load (e.g. Via lighter-weight queries and caching of >> request-routing decisions). >> >> and >> >> RI-2 [HIGH] The CDNI Request Routing Redirection interface shall >> support efficient request-routing for large objects. This >> may, for example, call for a mode of operation (e.g. HTTP- >> based request routing) where freshness and accuracy of CDN/ >> Surrogate selection justifies a per-request decision and a >> per-request CDNI Request-Routing protocol call. >> >> I'm not sure what "efficient" implies here, perhaps because I see the examples but don't know what other efficiencies might be required. > As suggested by the examples, the "efficiency" referred to is indeed in terms of trade-offs between request routing load and accuracy of the request routing decision. > But at the same time, i don't think it is bad if the requirement doesn't completely close the door on other efficiencies (which may be understood when finalising teh details of CDNI interfaces). I think you're right. I also think I've spent too much time listening to people argue about whether something "really" satisfies a requirement, and I had a Pavlovian response to "efficient" ("how the heck would I know?"). My apologies. If the working group doesn't expect to have such arguments, I'm fine with the existing text :-) > >> In the same section, >> >> RI-5 [MED] In case of detection of a request redirection loop, the >> CDNI Request Routing Redirection interface's loop prevention >> mechanism should allow routing of the request by avoiding the >> loop (as opposed to the request loop being simply interrupted >> without routing the request). >> >> I'm not understanding what "by avoiding the loop" means. I can guess, but I'm guessing. > How about: > " > RI-5 [MED] In case of detection of a potential request redirection loop, the > CDNI Request Routing Redirection interface's loop prevention > mechanism should prevent or interrupt the loop and allow routing of the request (as opposed to the request loop being simply interrupted > without routing the request). > " I'm not clearly explaining what's not clear to me. Let me guess again ... I'm pretty sure I'm choking because I'm reading "allow routing of the request" as "you sent me a request that loops when I route it, so I either prevent or interrupt the loop *and continue to route the request*, like I suddenly know how to route the request that was looping, without looping". Is RI-5 saying that if you send a request that loops, you get a response that tells you that the request looped, as opposed to having the loop prevention mechanism drop the request to protect the CDN, but you get nothing back? Or am I missing this completely? >> In the same section, >> >> RI-6 [MED] The CDNI Request Routing Redirection interface should >> support a mechanism allowing enforcment of a limit on the >> number of successive CDN redirections for a given request. >> >> I noticed a nit: s/enforcment/enforcement/ >> >> In Section 7. CDNI Metadata Interface Requirements >> >> MI-19 [MED] The CDNI Metadata interface should support an optional >> mechanism allowing the Upstream CDN to indicate to the >> Downstream CDN which CDNI Log fields 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 shall ignore this log format indication and generate >> CDNI logging format for HTTP Adaptive Streaming using the >> default set of CDNI Logging fields. (Note: this function is >> not concluded to be in Metadata Interface or Control >> Interface) >> >> I didn't understand the parenthetical note at the end of MI-19 - what does "is not concluded to be in" mean? I can guess, but I'm guessing. > It was questioned whether this requirement (ie "a mechanism allowing the Upstream CDN to indicate to the Downstream CDN which CDNI Log fields are to be provided") should be realised by the Metadata interface or whether it shoudl possibly actually be realised by the Control interface. At this stage the WG has not concluded that discussion (and the discussion has been paused since this will not be part of the first version of the interfaces). > The note could be improved to make this clearer. That was close to one of my guesses. Is it correct to say "this function may be part of the Metadata Interface or the Control Interface"? >> In Section 8. CDNI Logging Interface Requirements >> >> LI-9 [LOW] The CDNI Logging interface may support aggregate/ >> summarized logs (e.g. total bytes delivered for a content >> regardless of individual User Agents to which it was >> delivered). >> >> This requirement is fine, but I didn't see requirements that applied to how the Upstream CDN and Downstream CDN communicated what aggregates/summarized logs were available. If this is captured under "extensible" elsewhere in the section, that's fine. > I would say this is covered by MI-19. This woudl indicate which "aggregate" fields are to be provided. If that works for the working group, that works for me. >> In Section 9. CDNI Security Requirements >> >> SEC-1 [HIGH] All the CDNI interface shall support secure operation >> over unsecured IP connectivity (e.g. The Internet). This >> includes authentication, confidentiality, integrity protection >> as well as protection against spoofing and replay. >> >> This is excellent, as far as it goes. You might consider whether the requirements go far enough to protect privacy, in a "pervasive passive monitoring" world - perhaps the combination of "unsecured IP connectivity" plus unsecured HTTP as a supported transport has implications for privacy that affect CDNI at the requirements level? (If not, you might consider pointing that out in the Security Considerations section, because that conversation now will be less painful than the same conversation during evaluation of a protocol draft :-) > In fact, the CDNI Logging interface includes a specific privacy mechanism (in the form of anonymization of IP addresses). > Perhaps a requirement for privacy of CDNI LOgging information should be added? Perhaps, and I should say "you folks are the experts" at this point. It may be that there are loads of privacy considerations that don't show up at the requirements level, too. I do suggest that the working group keep in mind that on each telechat, the IESG has two SEC ADs, including the one who's sponsoring the "perpass" mailing list, plus an IAB Chair who's a former SEC AD, plus an IETF Chair who's done press interviews about pervasive passive monitoring as recently as this morning. And that's before anyone outside the IESG asks at Last Call time whether the working group thought about privacy in our Brave New World. As long the answer is "yes, they thought about it", I'll be happy with pretty much anything you decide :-) Spencer From D.Malas@cablelabs.com Sat Sep 21 03:07:14 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D5011E813F for ; Sat, 21 Sep 2013 03:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.463 X-Spam-Level: X-Spam-Status: No, score=-100.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 Nzr5k-V2FBys for ; Sat, 21 Sep 2013 03:07:09 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4003811E813B for ; Sat, 21 Sep 2013 03:07:01 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.7/8.14.7) with ESMTP id r8LA6onJ013860; Sat, 21 Sep 2013 04:06:50 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Sat, 21 Sep 2013 04:06:50 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Sat, 21 Sep 2013 04:06:50 -0600 From: Daryl Malas To: Spencer Dawkins , "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 Thread-Index: AQHOtrJJnmQavPG6F0qweViwqjGPig== Date: Sat, 21 Sep 2013 10:06:49 +0000 Message-ID: In-Reply-To: <523C9BA9.5050506@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 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, 21 Sep 2013 10:07:14 -0000 In-line, removing agreed actions for improved clarity. --Daryl On 9/20/13 9:02 PM, "Spencer Dawkins" wrote: >On 9/20/2013 9:58 AM, Francois Le Faucheur (flefauch) wrote: >> Hi Spencer, >> >> Great to have a review performed with a fresh eye. My personal thoughts >>embedded below: > >Thanks for a quick response with personal thoughts :-) > >We're in sync on everything but my question about RI-5. This is going >really well! > >Please see inline ... > >> On 19 Sep 2013, at 23:36, Spencer Dawkins >> wrote: >> >>> On 9/19/2013 6:00 AM, Daryl Malas wrote: >>>> Daryl Malas has requested publication of >>>>draft-ietf-cdni-requirements-10 as Informational on behalf of the CDNI >>>>working group. >>>> >>>> Please verify the document's state at >>>>http://datatracker.ietf.org/doc/draft-ietf-cdni-requirements/ >>>> >>> Hi, Daryl, >>> >>> Thank you for the helpful shepherd writeup. >>> >>> These are my notes from reading through the document. I found it >>>well-written and clear (thank you, editors and working group). >>> >>> I have some pre-IETF Last Call questions that I'd like to ask before >>>moving forward. Please consider them, and let me know if the working >>>group needs to make any text changes. >>> >>> I may also be asking questions that would be more appropriate for >>>another document in the series, so "great question, but not now" could >>>be a fine response. >>> >>> As a high-order bit, I didn't see any requirements for managing the >>>interfaces. That could be OK, or you may have enough requirements in >>>the various sections that when you add them together, you don't need >>>any additional requirements specifically for management, but I wanted >>>to ask before someone else did. >>> >>> As a high-order bit, my questions about GEN-10/GEN-11, RI-5, LI-9 and >>>SEC-1 might require discussion (which would be fine). My other >>>questions are either about clarity or nits. >>> >>> In Section 2. CDNI Model and CDNI Interfaces >>> >>> I found the use of two different line types with the same description >>>odd in Figure 1. Is this just because the figure looked funny with one >>>line type? Or is there something more subtle going on? >> It was purely to make the figure more readable. The figure shows >>different interafces that crosses each other and it just seemed easier >>to read it with different symbols. >> We use the same pictorial convention in RFC6707 (CDNI Problem >>Statement), so I'd usggest keeping it as is. >> >>> <=3D=3D> interfaces inside the scope of CDNI >>> **** interfaces outside the scope of CDNI >>> .... interfaces outside the scope of CDNI > >"More readable" was my guess, so definitely not suggesting a change to >the figure itself. > >The editors might consider something like > ><=3D=3D> interfaces inside the scope of CDNI >**** and .... interfaces outside the scope of CDNI > >as the legend. I was guessing the text for "...." was a cut-and-paste >error from the previous line, and I think that's the most likely >response from any first-time reader. [DM] I agree with you, after reviewing the diagram again it is redundant. The description for one of the "outside the scope" should be changed, or the relative lines should be aligned for consistency. I'll defer to the authors/editors for their recommendation on this. > >>> In Section 3. Generic CDNI Requirements >>> >>> GEN-3 [HIGH] The CDNI solution shall not require a change, or an >>> upgrade, to the Content Service Provider to benefit from >>> content delivery through interconnected CDNs. >>> >>> I wasn't sure what this requirement meant (change or upgrade from >>>what?). >> I believe that what this is trying to say is that if a CSP currently >>uses a single CDN for content delivery, then if that CDN decides to >>leverages other CDNs via CDNI, the solution should allow this to happen >>transparently. To illustrate the point, if the CDNI solution imposed >>that all URIs be structured in some rigid way and therefore imposed that >>the CSP modifies all their URIs listed in their content portal, that >>would be a bad solution. > >Your explanation helped a LOT. Somewhat frustratingly, almost all the >words in your explanation are in the requirement I couldn't understand :D > >What you added, which made the same words clearer, was the point about a >CSP using a single CDN and then deciding to leverage interconnected CDNs. > >Perhaps the editors could consider a better version of > >"The CNDI solution shall not require a change, or an upgrade, to the >Content Service Provider delivering content through a single CDN, to >benefit from content delivery through interconnected CDNs." > >That answers my "from what?" question. [DM] I'm fine with this change. > >> >>> I noticed this because I was looking at GEN-11, which says >>> >>> GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI >>> information exchange. >>> >>> If GEN-10 is about "the topology of interconnected CDNs", and doesn't >>>guarantee that the topology is loop-free, I was wondering if this >>>requirement was about preventing looping or detecting looping. >> Well, I think the key requirement here is that the ongoing looping of >>information be prevented. There are multiple ways this might be achieved >>(eg have a solution that absolutely guarantees it never happens even >>during transient situations, or have a solution that detects it if/when >>it happens and then interrupts it). In fact, different CDNI interfaces >>may use different mechanisms to prevent such loops. I don't think this >>particular requirement needs to mandate one approach. > >I agree, but I was reading "prevent looping" in the text as requiring an >absolute guarantee, so mandating one approach. > >Perhaps something like "shall prevent persistent looping" would capture >what you're describing? [DM] Spencer, I read both your question and Francois' response, and my perception is we are splitting hairs on this one. Adding "persistent", to me, changes the requirement. This requirement says, "define a way to avoid loops" (e.g., Max-Forwards in SIP). The change you suggest indicates to me that we define a solution for attempting to avoid dCDNs that cause loop after a loop has been already detected and shut down. Are you suggesting we add a requirement for loop detection or change this one to better align with the latter? >>> >>> In 5. CDNI Request Routing Redirection Interface Requirements >>> >>> RI-1 [HIGH] The CDNI Request Routing Redirection interface shall >>> support efficient request-routing for small objects. This >>> may, for example, call for a mode of operation (e.g. DNS- >>> based request routing) where freshness and accuracy of CDN/ >>> Surrogate selection can be traded-off against reduced >>>request- >>> routing load (e.g. Via lighter-weight queries and caching of >>> request-routing decisions). >>> >>> and >>> >>> RI-2 [HIGH] The CDNI Request Routing Redirection interface shall >>> support efficient request-routing for large objects. This >>> may, for example, call for a mode of operation (e.g. HTTP- >>> based request routing) where freshness and accuracy of CDN/ >>> Surrogate selection justifies a per-request decision and a >>> per-request CDNI Request-Routing protocol call. >>> >>> I'm not sure what "efficient" implies here, perhaps because I see the >>>examples but don't know what other efficiencies might be required. >> As suggested by the examples, the "efficiency" referred to is indeed in >>terms of trade-offs between request routing load and accuracy of the >>request routing decision. >> But at the same time, i don't think it is bad if the requirement >>doesn't completely close the door on other efficiencies (which may be >>understood when finalising teh details of CDNI interfaces). > >I think you're right. I also think I've spent too much time listening to >people argue about whether something "really" satisfies a requirement, >and I had a Pavlovian response to "efficient" ("how the heck would I >know?"). My apologies. > >If the working group doesn't expect to have such arguments, I'm fine >with the existing text :-) [DM] How can you ever predict what a working group will argue about?? ;-) > >> >>> In the same section, >>> >>> RI-5 [MED] In case of detection of a request redirection loop, the >>> CDNI Request Routing Redirection interface's loop prevention >>> mechanism should allow routing of the request by avoiding the >>> loop (as opposed to the request loop being simply interrupted >>> without routing the request). >>> >>> I'm not understanding what "by avoiding the loop" means. I can guess, >>>but I'm guessing. >> How about: >> " >> RI-5 [MED] In case of detection of a potential request redirection >>loop, the >> CDNI Request Routing Redirection interface's loop prevention >> mechanism should prevent or interrupt the loop and allow >>routing of the request (as opposed to the request loop being simply >>interrupted >> without routing the request). >> " > >I'm not clearly explaining what's not clear to me. Let me guess again ... > >I'm pretty sure I'm choking because I'm reading "allow routing of the >request" as "you sent me a request that loops when I route it, so I >either prevent or interrupt the loop *and continue to route the >request*, like I suddenly know how to route the request that was >looping, without looping". > >Is RI-5 saying that if you send a request that loops, you get a response >that tells you that the request looped, as opposed to having the loop >prevention mechanism drop the request to protect the CDN, but you get >nothing back? Or am I missing this completely? [DM] I think I understand your concern; and, after reviewing the requirement again, I agree with you. If the CDN knew how to avoid the loop in the first place, why would it send a request purposely in a direction that causes a loop. Perhaps the requirement should state something more like: [MED] In case of detection of a request redirection loop, the CDNI Request Routing Redirection interface's loop prevention mechanism should notify the requesting CDNs of the loop, so the requesting CDN could attempt a difference dCDN. > >>> In the same section, >>> >>> RI-6 [MED] The CDNI Request Routing Redirection interface should >>> support a mechanism allowing enforcment of a limit on the >>> number of successive CDN redirections for a given request. >>> >>> I noticed a nit: s/enforcment/enforcement/ [DM] Ack. Easy editor fix. >>> >>> In Section 7. CDNI Metadata Interface Requirements >>> >>> MI-19 [MED] The CDNI Metadata interface should support an optional >>> mechanism allowing the Upstream CDN to indicate to the >>> Downstream CDN which CDNI Log fields 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 shall ignore this log format indication and >>>generate >>> CDNI logging format for HTTP Adaptive Streaming using the >>> default set of CDNI Logging fields. (Note: this function is >>> not concluded to be in Metadata Interface or Control >>> Interface) >>> >>> I didn't understand the parenthetical note at the end of MI-19 - what >>>does "is not concluded to be in" mean? I can guess, but I'm guessing. >> It was questioned whether this requirement (ie "a mechanism allowing >>the Upstream CDN to indicate to the Downstream CDN which CDNI Log fields >>are to be provided") should be realised by the Metadata interface or >>whether it shoudl possibly actually be realised by the Control >>interface. At this stage the WG has not concluded that discussion (and >>the discussion has been paused since this will not be part of the first >>version of the interfaces). >> The note could be improved to make this clearer. > >That was close to one of my guesses. > >Is it correct to say "this function may be part of the Metadata >Interface or the Control Interface"? > > >>> In Section 9. CDNI Security Requirements >>> >>> SEC-1 [HIGH] All the CDNI interface shall support secure operation >>> over unsecured IP connectivity (e.g. The Internet). This >>> includes authentication, confidentiality, integrity >>>protection >>> as well as protection against spoofing and replay. >>> >>> This is excellent, as far as it goes. You might consider whether the >>>requirements go far enough to protect privacy, in a "pervasive passive >>>monitoring" world - perhaps the combination of "unsecured IP >>>connectivity" plus unsecured HTTP as a supported transport has >>>implications for privacy that affect CDNI at the requirements level? >>>(If not, you might consider pointing that out in the Security >>>Considerations section, because that conversation now will be less >>>painful than the same conversation during evaluation of a protocol >>>draft :-) >> In fact, the CDNI Logging interface includes a specific privacy >>mechanism (in the form of anonymization of IP addresses). >> Perhaps a requirement for privacy of CDNI LOgging information should be >>added? > >Perhaps, and I should say "you folks are the experts" at this point. It >may be that there are loads of privacy considerations that don't show up >at the requirements level, too. > >I do suggest that the working group keep in mind that on each telechat, >the IESG has two SEC ADs, including the one who's sponsoring the >"perpass" mailing list, plus an IAB Chair who's a former SEC AD, plus an >IETF Chair who's done press interviews about pervasive passive >monitoring as recently as this morning. > >And that's before anyone outside the IESG asks at Last Call time whether >the working group thought about privacy in our Brave New World. > >As long the answer is "yes, they thought about it", I'll be happy with >pretty much anything you decide :-) > >Spencer >_______________________________________________ >CDNi mailing list >CDNi@ietf.org >https://www.ietf.org/mailman/listinfo/cdni From spencerdawkins.ietf@gmail.com Sat Sep 21 07:01:31 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 4873221F960E for ; Sat, 21 Sep 2013 07:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 qCo-1PJnAaN2 for ; Sat, 21 Sep 2013 07:01:30 -0700 (PDT) Received: from mail-ye0-x236.google.com (mail-ye0-x236.google.com [IPv6:2607:f8b0:4002:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 47CF621F9BC3 for ; Sat, 21 Sep 2013 07:01:30 -0700 (PDT) Received: by mail-ye0-f182.google.com with SMTP id l10so579861yen.27 for ; Sat, 21 Sep 2013 07:01:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=et+3IJ30NVf/XoQaDDMr2xoA1DpsEhclYxnnClGRz8g=; b=nQr+nRornDEU3GbguJOZuzMaY25/nBetW+sIN4iF0VxZq7oCAVARP+jCO+nA+rwIVr 9caeV0FXBQ6ivS6FBb55X+yBbX8x2FS2AP5S2yYUOA/dFJeRF+XEf9xRxmTBgdhMdbzN lJb8Vfte3dbVDgVmGVtcHDBzv0iWZT6Mfv3BrLhXuhraNJwCHw6ysLmaj+GPcUiaCn7I OXfeDqnDREdfVu/NgcLVZDi4Xoy4TdSO1wfkCrcpG2xSs6NhVFoBYbaRvLXdpYYBX8Y0 BWqf3wyGim0OFttFTOhukcSwcljlvwqB1PpgcgygyA9NK3y44d4p/TQU7zlbFe6frVoG yLgQ== X-Received: by 10.236.128.232 with SMTP id f68mr91340yhi.70.1379772089726; Sat, 21 Sep 2013 07:01:29 -0700 (PDT) Received: from [192.168.0.30] (70-3-31-51.pools.spcsdns.net. [70.3.31.51]) by mx.google.com with ESMTPSA id s20sm25399206yhi.0.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 21 Sep 2013 07:01:29 -0700 (PDT) Message-ID: <523DA6BB.1010409@gmail.com> Date: Sat, 21 Sep 2013 09:01:31 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Daryl Malas References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 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, 21 Sep 2013 14:01:31 -0000 On 9/21/2013 5:06 AM, Daryl Malas wrote: > In-line, removing agreed actions for improved clarity. --Daryl Likewise. And thank you for the quick response. I like that these e-mails are getting shorter, by the way ... > >> "More readable" was my guess, so definitely not suggesting a change to >> the figure itself. >> >> The editors might consider something like >> >> <==> interfaces inside the scope of CDNI >> **** and .... interfaces outside the scope of CDNI >> >> as the legend. I was guessing the text for "...." was a cut-and-paste >> error from the previous line, and I think that's the most likely >> response from any first-time reader. > [DM] I agree with you, after reviewing the diagram again it is redundant. > The description for one of the "outside the scope" should be changed, or > the relative lines should be aligned for consistency. I'll defer to the > authors/editors for their recommendation on this. As will I. I note that "ascii art" is a synonym for "barely art", so I understand this isn't easy :-) > >> >>> >>>> I noticed this because I was looking at GEN-11, which says >>>> >>>> GEN-11 [HIGH] The CDNI solution shall prevent looping of any CDNI >>>> information exchange. >>>> >>>> If GEN-10 is about "the topology of interconnected CDNs", and doesn't >>>> guarantee that the topology is loop-free, I was wondering if this >>>> requirement was about preventing looping or detecting looping. >>> Well, I think the key requirement here is that the ongoing looping of >>> information be prevented. There are multiple ways this might be achieved >>> (eg have a solution that absolutely guarantees it never happens even >>> during transient situations, or have a solution that detects it if/when >>> it happens and then interrupts it). In fact, different CDNI interfaces >>> may use different mechanisms to prevent such loops. I don't think this >>> particular requirement needs to mandate one approach. >> I agree, but I was reading "prevent looping" in the text as requiring an >> absolute guarantee, so mandating one approach. >> >> Perhaps something like "shall prevent persistent looping" would capture >> what you're describing? > [DM] Spencer, I read both your question and Francois' response, and my > perception is we are splitting hairs on this one. Adding "persistent", to > me, changes the requirement. This requirement says, "define a way to > avoid loops" (e.g., Max-Forwards in SIP). The change you suggest > indicates to me that we define a solution for attempting to avoid dCDNs > that cause loop after a loop has been already detected and shut down. Are > you suggesting we add a requirement for loop detection or change this one > to better align with the latter? So, I'm not suggesting to change the requirement or to add a new requirement. For background, I lived through at least part of the conversation between IEEE 802.1, with no hop count, so they had to avoid loops, and TRILL, with hop counts, so they could mitigate the effects of forming loops, and that conversation was more memorable than it should have been I understood Francois to be saying that at the requirement level, the working group didn't need to choose between avoiding loops and mitigating the effect of forming loops. I'm OK with that. My struggle was that I was reading "avoid loops" as mandating the choice that Francois didn't think you should be mandating. If the working group doesn't read "avoid loops" as mandating that choice, or reads it as mandating that choice and thinks that's OK, either way is fine. > >> If the working group doesn't expect to have such arguments, I'm fine >> with the existing text :-) > [DM] How can you ever predict what a working group will argue about?? ;-) Daryl, that's easy. Predicting what a working group WON'T argue about is hard :p That's not an actionable comment, by the way :-) ... > >> >>> >>>> In the same section, >>>> >>>> RI-5 [MED] In case of detection of a request redirection loop, the >>>> CDNI Request Routing Redirection interface's loop prevention >>>> mechanism should allow routing of the request by avoiding the >>>> loop (as opposed to the request loop being simply interrupted >>>> without routing the request). >>>> >>>> I'm not understanding what "by avoiding the loop" means. I can guess, >>>> but I'm guessing. >>> How about: >>> " >>> RI-5 [MED] In case of detection of a potential request redirection >>> loop, the >>> CDNI Request Routing Redirection interface's loop prevention >>> mechanism should prevent or interrupt the loop and allow >>> routing of the request (as opposed to the request loop being simply >>> interrupted >>> without routing the request). >>> " >> I'm not clearly explaining what's not clear to me. Let me guess again ... >> >> I'm pretty sure I'm choking because I'm reading "allow routing of the >> request" as "you sent me a request that loops when I route it, so I >> either prevent or interrupt the loop *and continue to route the >> request*, like I suddenly know how to route the request that was >> looping, without looping". >> >> Is RI-5 saying that if you send a request that loops, you get a response >> that tells you that the request looped, as opposed to having the loop >> prevention mechanism drop the request to protect the CDN, but you get >> nothing back? Or am I missing this completely? > [DM] I think I understand your concern; and, after reviewing the > requirement again, I agree with you. If the CDN knew how to avoid the > loop in the first place, why would it send a request purposely in a > direction that causes a loop. Perhaps the requirement should state > something more like: > > [MED] In case of detection of a request redirection loop, the > CDNI Request Routing Redirection interface's loop prevention > mechanism should notify the requesting CDNs of the loop, so the > requesting CDN could attempt a difference dCDN. After looking at the original requirement again, what I was struggling with is that the text sounds like the interface is avoiding the loop that the request caused, but the same interface is still routing the same request with no changes. Your suggestion would work for me (if it works for others, of course), because it doesn't use the same word for what happens before and after a request redirection loops. Other text would work, too. From flefauch@cisco.com Mon Sep 23 01:29: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 9452421F84B7 for ; Mon, 23 Sep 2013 01:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 AYMYqpWLqMnH for ; Mon, 23 Sep 2013 01:29:39 -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 44B2221F93F8 for ; Mon, 23 Sep 2013 01:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4256; q=dns/txt; s=iport; t=1379924975; x=1381134575; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Vue8DC/xARx/USh0frXuiv7wlBnShyAzaxvHi+9xXxM=; b=FRnyKpCk4RJTVl03fTgRPscM11UDPEpsWg3n2N4TTT2RAZxnMUu3jhj1 kt8h/8U9He0gTPK1QhgWyv/SV0Q5ErdLecvzi4MH4BBjVfnhicYskdDnP 0nGnD+Z/nB+I+02YofSz6uijKTMIqCTO1ghwMBXR6O2ghufT0lAaNwXZu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGX7P1KtJV2d/2dsb2JhbABZgweBCsEwgRsWdIIlAQEBAwF5BQsCAQgiJDIlAgQODYd3BrojjzICMQeDHoEAA4kAoHODJIIq X-IronPort-AV: E=Sophos;i="4.90,960,1371081600"; d="scan'208";a="260173549" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-9.cisco.com with ESMTP; 23 Sep 2013 08:29:33 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8N8TV0k030769 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 23 Sep 2013 08:29:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 03:29:30 -0500 From: "Francois Le Faucheur (flefauch)" To: Spencer Dawkins Thread-Topic: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 Thread-Index: AQHOtjPpOEp0aqRAAE21cuRFIexdEZnQS/yAgABBk4CAAsflgA== Date: Mon, 23 Sep 2013 08:29:30 +0000 Message-ID: References: <523DA6BB.1010409@gmail.com> In-Reply-To: <523DA6BB.1010409@gmail.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="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Martin Stiemerling , Daryl Malas , "" Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 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, 23 Sep 2013 08:29:46 -0000 All, >>> "More readable" was my guess, so definitely not suggesting a change to >>> the figure itself. >>>=20 >>> The editors might consider something like >>>=20 >>> <=3D=3D> interfaces inside the scope of CDNI >>> **** and .... interfaces outside the scope of CDNI >>>=20 >>> as the legend. I was guessing the text for "...." was a cut-and-paste >>> error from the previous line, and I think that's the most likely >>> response from any first-time reader. >> [DM] I agree with you, after reviewing the diagram again it is redundant= . >> The description for one of the "outside the scope" should be changed, or >> the relative lines should be aligned for consistency. I'll defer to the >> authors/editors for their recommendation on this. >=20 > As will I. Works for me too. >=20 >>=20 >>>=20 >>>>=20 >>>>> In the same section, >>>>>=20 >>>>> RI-5 [MED] In case of detection of a request redirection loop, t= he >>>>> CDNI Request Routing Redirection interface's loop preventio= n >>>>> mechanism should allow routing of the request by avoiding t= he >>>>> loop (as opposed to the request loop being simply interrupt= ed >>>>> without routing the request). >>>>>=20 >>>>> I'm not understanding what "by avoiding the loop" means. I can guess, >>>>> but I'm guessing. >>>> How about: >>>> " >>>> RI-5 [MED] In case of detection of a potential request redirectio= n >>>> loop, the >>>> CDNI Request Routing Redirection interface's loop prevention >>>> mechanism should prevent or interrupt the loop and allow >>>> routing of the request (as opposed to the request loop being simply >>>> interrupted >>>> without routing the request). >>>> " >>> I'm not clearly explaining what's not clear to me. Let me guess again .= .. >>>=20 >>> I'm pretty sure I'm choking because I'm reading "allow routing of the >>> request" as "you sent me a request that loops when I route it, so I >>> either prevent or interrupt the loop *and continue to route the >>> request*, like I suddenly know how to route the request that was >>> looping, without looping". >>>=20 >>> Is RI-5 saying that if you send a request that loops, you get a respons= e >>> that tells you that the request looped, as opposed to having the loop >>> prevention mechanism drop the request to protect the CDN, but you get >>> nothing back? Or am I missing this completely? >> [DM] I think I understand your concern; and, after reviewing the >> requirement again, I agree with you. If the CDN knew how to avoid the >> loop in the first place, why would it send a request purposely in a >> direction that causes a loop. Perhaps the requirement should state >> something more like: >>=20 >> [MED] In case of detection of a request redirection loop, the >> CDNI Request Routing Redirection interface's loop prevention >> mechanism should notify the requesting CDNs of the loop, so t= he >> requesting CDN could attempt a difference dCDN. >=20 > After looking at the original requirement again, what I was struggling wi= th is that the text sounds like the interface is avoiding the loop that the= request caused, but the same interface is still routing the same request w= ith no changes. >=20 > Your suggestion would work for me (if it works for others, of course), be= cause it doesn't use the same word for what happens before and after a requ= est redirection loops. The text suggested by Daryl could work for me too. Although I would prefer: " [MED] In case of detection of a request redirection loop, the CDNI Request Routing Redirection interface's loop prevention mechanism should allow the uCDN to attempt a different dCDN. " This is because the loop detection might actually be done by the uCDN itsel= f based on information received in the RI request, so the uCDN never really= receive a "notification" of loop (ie the uCDN may look at the information = in the received RI request, and realises that the "initially selected dCDN"= would result in a loop - because it already appears in the received RI req= uest). Francois > Other text would work, too. From flefauch@cisco.com Mon Sep 23 06:51: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 BFEFE21F9F77 for ; Mon, 23 Sep 2013 06:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4iQtUeoTSkVV for ; Mon, 23 Sep 2013 06:51:40 -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 B4C3621F9F4F for ; Mon, 23 Sep 2013 06:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22061; q=dns/txt; s=iport; t=1379944298; x=1381153898; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=6h1+d2qcL7iRm94HD8523HYh+lNfefu4lEzQx7W1jgc=; b=f25tR9lMKHXqSnmkSIpjiR45BHj53jz/VBgorX8yI4hL4LNxUX5dRslK qRqS+7NpI9g3m8zK3+H9scrvqQqOu4Isc6cas8B0o3cMw8tHE79OY7QVA SIT4wvU/FQCO52/899HKb7LaWeuvWzZyE2h2+YV59dJqnl5fo93rbVPHe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApEFAGJGQFKtJV2Y/2dsb2JhbAA/FwODBzhSwTGBIRZtB4ImAQECAgEBAWMCBhsCAQgUDgoECAQDBycLFBABAgEDEwiHfQw2rQ+NfI4cG30gAQwLEQeDBoEAA6lzglJSgXE5 X-IronPort-AV: E=Sophos;i="4.90,962,1371081600"; d="scan'208,217";a="263365903" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 23 Sep 2013 13:51:37 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8NDpbuL022717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Sep 2013 13:51:37 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 23 Sep 2013 08:51:36 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Informal Meetings on CDNI Logging - 25 Sept & 16 Oct Thread-Index: AQHOrTxDHg6FULdiaEKH88o3s7qQCZnTwWGA Date: Mon, 23 Sep 2013 13:51: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: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04BCE5FExmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [CDNi] Informal Meetings on CDNI Logging - 25 Sept & 16 Oct 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, 23 Sep 2013 13:51:44 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BCE5FExmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Just a friendly reminder about this Wed's informal meeting on cdni-logging. Working on a new rev to be posted before for discussion. Francois On 9 Sep 2013, at 11:09, Francois Le Faucheur (flefauch) > wrote: Folks, We (cdni-logging authors) have scheduled two brief (45 mins) open informal = virtual meetings on CDNI Logging to keep the momentum till Vancouver: * Wed 25 Sep, at 9:15am California Time (ie 18:15pm Paris Time) * Wed 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time) These are open meetings aiming at collecting input on open issues, and ever= yone is encouraged to attend. Francois Attendance is via Webex: Wed 25 Sep =3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Informal Meetings on CDNI Logging Date: Wednesday, September 25, 2013 Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 303 072 107 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137768&UID=3D4843= 18167&PW=3DNZTg1MjNlN2Mx&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:303 072 107 CCP:+14085256800x303072107# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. Wed 16 Oct =3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Informal Meetings on CDNI Logging Date: Wednesday, October 16, 2013 Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 304 625 039 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137858&UID=3D4843= 18167&PW=3DNY2IzMDA2NTQ0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:304 625 039 CCP:+14085256800x304625039# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BCE5FExmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <992029B12D0D4F47B7135357CBB08345@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi,
Just a friendly reminder about this Wed's informal meeting on cdni-log= ging.
Working on a new rev to be posted before for discussion.
Francois


On 9 Sep 2013, at 11:09, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Folks,

We (cdni-logging authors) have scheduled two brief (45 mins) open info= rmal virtual meetings on CDNI Logging to keep the momentum till Vancouver:<= /div>
* Wed = 25 Sep, at 9:15am California Time (ie 18:15pm Paris Time)
* Wed = 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time)

These are open meetings aiming at collecting input on open issues, and= everyone is encouraged to attend.

Francois


Attendance is via Webex:


Wed 25 Sep 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Topic: Informal Meetings on CDNI Logging 
Date: Wednesday, September 25, 2013 
Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 303 072 107 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137768&UID=3D484318167&PW=3DNZTg1MjNlN2= Mx&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:303 072 107 

CCP:+14085256800x303072107# 

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



Wed 16 Oct 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Topic: Informal Meetings on CDNI Logging 
Date: Wednesday, October 16, 2013 
Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 304 625 039 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137858&UID=3D484318167&PW=3DNY2IzMDA2NT= Q0&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:304 625 039 

CCP:+14085256800x304625039# 

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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BCE5FExmbrcdx10ciscoc_-- From spencerdawkins.ietf@gmail.com Mon Sep 23 10:51: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 184EA21F915C for ; Mon, 23 Sep 2013 10:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 epVI2XzpnugX for ; Mon, 23 Sep 2013 10:51:22 -0700 (PDT) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 4559521F90AF for ; Mon, 23 Sep 2013 10:51:22 -0700 (PDT) Received: by mail-ve0-f181.google.com with SMTP id oy12so2528265veb.40 for ; Mon, 23 Sep 2013 10:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0AVMN65yRfslzBorWo3WrfddjB3VZ9hHIpDs5OrNsuM=; b=JG8Fc6mRJyq0eju61dLSfbNk2MQ28tpY43YDOkQimteQ4AtWq/0GZdPVBuZdR5qciT fpktRKQJE3aHoq5NEbQdc4FEXDrQ6+NZWSiCsZ7g/oZbdPfTa+bsZ4jOhBZyGuhVkbc1 ZNgcZqFbVcDgvjnI1v1ndmFl/F8WbrQw9wh2hoSCeXB1jLjgfNFlig6+i+7sT4NS8wJN 99ej4fSILl4dRWVryBziVTkPcn+eDw4ebWomvFzj/89WBGEsZfS8wElhVr061EqAJhyo 0Y41p2ztWUHY8IhTJ8OCSzjZNyVkS8uT+WRks6KOGLoQm2lc59kKC6QKbU6Eye87i1MT FmNA== X-Received: by 10.52.107.226 with SMTP id hf2mr19715792vdb.2.1379958681607; Mon, 23 Sep 2013 10:51:21 -0700 (PDT) Received: from [192.168.0.23] (70-3-31-51.pools.spcsdns.net. [70.3.31.51]) by mx.google.com with ESMTPSA id jw6sm16940845veb.3.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Sep 2013 10:51:20 -0700 (PDT) Message-ID: <52407F8A.4020606@gmail.com> Date: Mon, 23 Sep 2013 12:51:06 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: "Francois Le Faucheur (flefauch)" References: <523DA6BB.1010409@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Martin Stiemerling , "" , Daryl Malas Subject: Re: [CDNi] Publication has been requested for draft-ietf-cdni-requirements-10 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, 23 Sep 2013 17:51:23 -0000 On 9/23/2013 3:29 AM, Francois Le Faucheur (flefauch) wrote: > >>>>>> In the same section, >>>>>> >>>>>> RI-5 [MED] In case of detection of a request redirection loop, the >>>>>> CDNI Request Routing Redirection interface's loop prevention >>>>>> mechanism should allow routing of the request by avoiding the >>>>>> loop (as opposed to the request loop being simply interrupted >>>>>> without routing the request). >>>>>> >>>>>> I'm not understanding what "by avoiding the loop" means. I can guess, >>>>>> but I'm guessing. >>>>> How about: >>>>> " >>>>> RI-5 [MED] In case of detection of a potential request redirection >>>>> loop, the >>>>> CDNI Request Routing Redirection interface's loop prevention >>>>> mechanism should prevent or interrupt the loop and allow >>>>> routing of the request (as opposed to the request loop being simply >>>>> interrupted >>>>> without routing the request). >>>>> " >>>> I'm not clearly explaining what's not clear to me. Let me guess again ... >>>> >>>> I'm pretty sure I'm choking because I'm reading "allow routing of the >>>> request" as "you sent me a request that loops when I route it, so I >>>> either prevent or interrupt the loop *and continue to route the >>>> request*, like I suddenly know how to route the request that was >>>> looping, without looping". >>>> >>>> Is RI-5 saying that if you send a request that loops, you get a response >>>> that tells you that the request looped, as opposed to having the loop >>>> prevention mechanism drop the request to protect the CDN, but you get >>>> nothing back? Or am I missing this completely? >>> [DM] I think I understand your concern; and, after reviewing the >>> requirement again, I agree with you. If the CDN knew how to avoid the >>> loop in the first place, why would it send a request purposely in a >>> direction that causes a loop. Perhaps the requirement should state >>> something more like: >>> >>> [MED] In case of detection of a request redirection loop, the >>> CDNI Request Routing Redirection interface's loop prevention >>> mechanism should notify the requesting CDNs of the loop, so the >>> requesting CDN could attempt a difference dCDN. >> After looking at the original requirement again, what I was struggling with is that the text sounds like the interface is avoiding the loop that the request caused, but the same interface is still routing the same request with no changes. >> >> Your suggestion would work for me (if it works for others, of course), because it doesn't use the same word for what happens before and after a request redirection loops. > The text suggested by Daryl could work for me too. Although I would prefer: > " > [MED] In case of detection of a request redirection loop, the > CDNI Request Routing Redirection interface's loop prevention > mechanism should allow the uCDN to attempt a different dCDN. > " > > This is because the loop detection might actually be done by the uCDN itself based on information received in the RI request, so the uCDN never really receive a "notification" of loop (ie the uCDN may look at the information in the received RI request, and realises that the "initially selected dCDN" would result in a loop - because it already appears in the received RI request). This text makes sense to me, and would also work for me if it works for others. I'm not sure how it's equivalent to the original RI-5, but since I said I couldn't understand the original RI-5, that's probably a good thing :-) Spencer From flefauch@cisco.com Tue Sep 24 02:22:12 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 EB2F821E8064 for ; Tue, 24 Sep 2013 02:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gmy6Tzc43wLj for ; Tue, 24 Sep 2013 02:21:54 -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 D227221E8056 for ; Tue, 24 Sep 2013 02:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23082; q=dns/txt; s=iport; t=1380014512; x=1381224112; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=jbwZSMgtiyXm+s5RAMMhBdaPwYSiifv3icxXo2VfBik=; b=ByKckdJLXwtDxTRzTNcW6JiX6rYGZWVLmWZ+L6QYoXeIPE/qGzuDjiGX SUjQMSLiCWg/sL1tC9YFYYof4hR8P04p5NqtMqbtMdhYQesUOG2g9vgN8 N1jnDqH37BbslRq6NpwzIQvMkT1yzNeGWoiioe18vyfxhKdpQDxTaTkbt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFANtYQVKtJV2d/2dsb2JhbABAFwODBzhSwFCBIRZ0giYBAQICAQEBYwIGGwIBHA4KBAgEAwcnCxQQAQIBAxMIh30MNq5IjiqOCBt9IAEMCxEHgwWBAAOpc4JSUoFxOQ X-IronPort-AV: E=Sophos;i="4.90,969,1371081600"; d="scan'208,217";a="263784677" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 24 Sep 2013 09:21:51 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r8O9LoOw029112 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Sep 2013 09:21:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 04:21:50 -0500 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: Informal Meeting on CDNI Logging - moved to 27 Sept (instead of 25 Sept) Thread-Index: AQHOuQeA9aNyhnLhSEq7TUeIjutohA== Date: Tue, 24 Sep 2013 09:21:50 +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_FC236DA6F2DA77449EF2D02DF4471A8D04BD14BCxmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: [CDNi] Informal Meeting on CDNI Logging - moved to 27 Sept (instead of 25 Sept) 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, 24 Sep 2013 09:22:12 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD14BCxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, The next informal meeting on cdni-logging has been re-secheduled to this Fr= iday (27 September) at 9:00 am California Time (ie 18:00pm Paris Time). Sorry for the change. Francois On 23 Sep 2013, at 15:51, Francois Le Faucheur > wrote: Hi, Just a friendly reminder about this Wed's informal meeting on cdni-logging. Working on a new rev to be posted before for discussion. Francois On 9 Sep 2013, at 11:09, Francois Le Faucheur (flefauch) > wrote: Folks, We (cdni-logging authors) have scheduled two brief (45 mins) open informal = virtual meetings on CDNI Logging to keep the momentum till Vancouver: * Wed 25 Sep, at 9:15am California Time (ie 18:15pm Paris Time) * Wed 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time) These are open meetings aiming at collecting input on open issues, and ever= yone is encouraged to attend. Francois Attendance is via Webex: Wed 25 Sep =3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Informal Meetings on CDNI Logging Date: Wednesday, September 25, 2013 Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 303 072 107 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137768&UID=3D4843= 18167&PW=3DNZTg1MjNlN2Mx&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:303 072 107 CCP:+14085256800x303072107# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. Wed 16 Oct =3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Informal Meetings on CDNI Logging Date: Wednesday, October 16, 2013 Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 304 625 039 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137858&UID=3D4843= 18167&PW=3DNY2IzMDA2NTQ0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:304 625 039 CCP:+14085256800x304625039# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD14BCxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Folks,

The next informal meeting on cdni-logging has been re-secheduled to th= is Friday (27 September) at 9:00 am California Time (ie 18:00pm Paris = Time).
Sorry for the change.

Francois

On 23 Sep 2013, at 15:51, Francois Le Faucheur <flefauch@cisco.com> wrote:

Hi,
Just a friendly reminder about this Wed's informal meeting on cdni-log= ging.
Working on a new rev to be posted before for discussion.
Francois


On 9 Sep 2013, at 11:09, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Folks,

We (cdni-logging authors) have scheduled two brief (45 mins) open info= rmal virtual meetings on CDNI Logging to keep the momentum till Vancouver:<= /div>
* Wed = 25 Sep, at 9:15am California Time (ie 18:15pm Paris Time)
* Wed = 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time)

These are open meetings aiming at collecting input on open issues, and= everyone is encouraged to attend.

Francois


Attendance is via Webex:


Wed 25 Sep 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Topic: Informal Meetings on CDNI Logging 
Date: Wednesday, September 25, 2013 
Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 303 072 107 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137768&UID=3D484318167&PW=3DNZTg1MjNlN2= Mx&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:303 072 107 

CCP:+14085256800x303072107# 

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



Wed 16 Oct 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Topic: Informal Meetings on CDNI Logging 
Date: Wednesday, October 16, 2013 
Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 304 625 039 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137858&UID=3D484318167&PW=3DNY2IzMDA2NT= Q0&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:304 625 039 

CCP:+14085256800x304625039# 

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


--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD14BCxmbrcdx10ciscoc_-- From flefauch@cisco.com Tue Sep 24 02:24:36 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0889921E8053 for ; Tue, 24 Sep 2013 02:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Z6gMEbpFuYT for ; Tue, 24 Sep 2013 02:24:31 -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 2469121E8051 for ; Tue, 24 Sep 2013 02:24:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33939; q=dns/txt; s=iport; t=1380014671; x=1381224271; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sBVGYijd2QTw7Z84sBjbK3BSF6+we8+w+Eyh84EJ3Aw=; b=lVUCkneN69XcHZ5KCqHO09p0g8aApEhBCx5p8TVrLP0QwpH09C1a9Cpv b+iO/t1u/lzyY3aXMukU5JuMBZuH7oydRB0jileklNLmZtsMfqXjXcSlz qe7BbWf4c+vLhjhFfSv52R8NZFHcsxYvyi/oOjzfmFf/ITt2XzTZmrrQQ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAEpZQVKtJXG8/2dsb2JhbABAFwODBzhSwFCBIRZ0giYBAQICAQEBYwIGGwIBCBQOCgQIAQMDBycLFBABAgEDEwiHfQw2rkmOKo4IG30gAQwLEQeDBYEAA6lzgWZsUoFxOQ X-IronPort-AV: E=Sophos;i="4.90,969,1371081600"; d="scan'208,217";a="260703125" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 24 Sep 2013 09:24:30 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8O9OULp023741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 24 Sep 2013 09:24:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Tue, 24 Sep 2013 04:24:29 -0500 From: "Francois Le Faucheur (flefauch)" To: "" Thread-Topic: [CDNi] Informal Meeting on CDNI Logging - moved to 27 Sept (instead of 25 Sept) Thread-Index: AQHOuQeA9aNyhnLhSEq7TUeIjutohJnU8X2A Date: Tue, 24 Sep 2013 09:24:29 +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_FC236DA6F2DA77449EF2D02DF4471A8D04BD1554xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: Re: [CDNi] Informal Meeting on CDNI Logging - moved to 27 Sept (instead of 25 Sept) 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, 24 Sep 2013 09:24:36 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD1554xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 24 Sep 2013, at 11:21, "Francois Le Faucheur (flefauch)" > wrote: Folks, The next informal meeting on cdni-logging has been re-secheduled to this Fr= iday (27 September) at 9:00 am California Time (ie 18:00pm Paris Time). Sorry for the change. Webex details remain the same: Topic: Informal Meetings on CDNI Logging Date: Friday, September 27, 2013 Time: 6:00 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 303 072 107 Password: cdni ------------------------------------------------------- To join the meeting online ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137768&UID=3D4843= 18167&PW=3DNZTg1MjNlN2Mx&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:303 072 107 CCP:+14085256800x303072107# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. Francois On 23 Sep 2013, at 15:51, Francois Le Faucheur > wrote: Hi, Just a friendly reminder about this Wed's informal meeting on cdni-logging. Working on a new rev to be posted before for discussion. Francois On 9 Sep 2013, at 11:09, Francois Le Faucheur (flefauch) > wrote: Folks, We (cdni-logging authors) have scheduled two brief (45 mins) open informal = virtual meetings on CDNI Logging to keep the momentum till Vancouver: * Wed 25 Sep, at 9:15am California Time (ie 18:15pm Paris Time) * Wed 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time) These are open meetings aiming at collecting input on open issues, and ever= yone is encouraged to attend. Francois Attendance is via Webex: Wed 25 Sep =3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Informal Meetings on CDNI Logging Date: Wednesday, September 25, 2013 Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 303 072 107 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137768&UID=3D4843= 18167&PW=3DNZTg1MjNlN2Mx&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:303 072 107 CCP:+14085256800x303072107# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. Wed 16 Oct =3D=3D=3D=3D=3D=3D=3D=3D=3D Topic: Informal Meetings on CDNI Logging Date: Wednesday, October 16, 2013 Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00) Meeting Number: 304 625 039 Password: cdni ------------------------------------------------------- To join the meeting online(Now from mobile devices!) ------------------------------------------------------- 1. Go to https://cisco.webex.com/ciscosales/j.php?ED=3D206137858&UID=3D4843= 18167&PW=3DNY2IzMDA2NTQ0&RT=3DMiMyMw%3D%3D 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: cdni 4. Click "Join". 5. If the meeting includes a teleconference, follow the instructions that a= ppear on your screen. ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting= , or call the number below and enter the access code. Call-in toll-free number (US/Canada): +1-866-432-9903 Call-in toll number (US/Canada): +1-408-525-6800 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restricti= ons.pdf Access code:304 625 039 CCP:+14085256800x304625039# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD1554xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <94213BE7E1695C4081036D7504BCEE76@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
On 24 Sep 2013, at 11:21, "Francois Le Faucheur (flefauch)" = <flefauch@cisco.com>
 wrote:

Folks,

The next informal meeting on cdni-logging has been re-secheduled to th= is Friday (27 September) at 9:00 am California Time (ie 18:00pm Paris = Time).
Sorry for the change.


Webex details remain the same:


Topic: Informal Meetings on CDNI Logging  Date: Friday, September 27, 2013 
Time: 6:00 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 303 072 107 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online 
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137768&UID=3D484318167&PW=3DNZTg1MjNlN2= Mx&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:303 072 107 




CCP:+14085256800x303072107# 

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



Francois

On 23 Sep 2013, at 15:51, Francois Le Faucheur <flefauch@cisco.com> wrote:

Hi,
Just a friendly reminder about this Wed's informal meeting on cdni-log= ging.
Working on a new rev to be posted before for discussion.
Francois


On 9 Sep 2013, at 11:09, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

Folks,

We (cdni-logging authors) have scheduled two brief (45 mins) open info= rmal virtual meetings on CDNI Logging to keep the momentum till Vancouver:<= /div>
* Wed = 25 Sep, at 9:15am California Time (ie 18:15pm Paris Time)
* Wed = 16 Oct, at 9:15am California Time (ie 18:15pm Paris Time)

These are open meetings aiming at collecting input on open issues, and= everyone is encouraged to attend.

Francois


Attendance is via Webex:


Wed 25 Sep 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Topic: Informal Meetings on CDNI Logging 
Date: Wednesday, September 25, 2013 
Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 303 072 107 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137768&UID=3D484318167&PW=3DNZTg1MjNlN2= Mx&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:303 072 107 

CCP:+14085256800x303072107# 

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



Wed 16 Oct 
=3D=3D=3D=3D=3D=3D=3D=3D=3D
Topic: Informal Meetings on CDNI Logging 
Date: Wednesday, October 16, 2013 
Time: 6:15 pm, Europe Summer Time (Paris, GMT+02:00)=  
Meeting Number: 304 625 039 
Password: cdni 

-------------------------------------------------------&= nbsp;
To join the meeting online(Now from mobile devices!)&nbs= p;
-------------------------------------------------------&= nbsp;
1. Go to https://cisco.webex.c= om/ciscosales/j.php?ED=3D206137858&UID=3D484318167&PW=3DNY2IzMDA2NT= Q0&RT=3DMiMyMw%3D%3D 
2. If requested, enter your name and email address. = ;
3. If a password is required, enter the meeting password= : cdni 
4. Click "Join". 
5. If the meeting includes a teleconference, follow the = instructions that appear on your screen. 

-------------------------------------------------------&= nbsp;
To join the audio conference only 
-------------------------------------------------------&= nbsp;
To receive a call back, provide your phone number when y= ou join the meeting, or call the number below and enter the access code.&nb= sp;
Call-in toll-free number (US/Canada): +1-866-432-990= 3 
Call-in toll number (US/Canada): +1-408-525-6800&nbs= p;
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf 

Access code:304 625 039 

CCP:+14085256800x304625039# 

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


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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD1554xmbrcdx10ciscoc_-- From flefauch@cisco.com Thu Sep 26 01:13:20 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A795C21E8056 for ; Thu, 26 Sep 2013 01:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.085, 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 bfE+ff3br0fp for ; Thu, 26 Sep 2013 01:13:15 -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 BA07721F918F for ; Thu, 26 Sep 2013 01:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2734; q=dns/txt; s=iport; t=1380183195; x=1381392795; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=z0Vy901ZVC1GSyW2ddnVpgNn8XSKSxJPUihAxs7dAfI=; b=b/LEyLISVHkJ9LvtOCnQa7HygMkl2d7myZ8JMmnCTaQVxkYBrqYsy2w2 bfGNzMJtCord2spOFhxfWC5U+Q+WLU6G3KPSwmLkgC7BXKhym8uF/1DPR Rioc7S4Eii9ZNnjQ2dMp46hWKL/qFg3KxV4dOPoGQFOkBCLGKp8qCYRTL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAHPrQ1KtJV2a/2dsb2JhbABbgwc4UsBIgSIWbQeCJgEBBAEBAWsbAgEMAR0dBycLFBECBBMIh34MvEkEjyAtC4MdgQEDqXODJIIq X-IronPort-AV: E=Sophos;i="4.90,983,1371081600"; d="scan'208,217";a="264484191" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 26 Sep 2013 08:13:13 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8Q8DDnw015140 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 26 Sep 2013 08:13:13 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Thu, 26 Sep 2013 03:13:13 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: End of WG Last Call on draft-ietf-cdni-framework-05.txt Thread-Index: AQHOupA+tn/YMx6MC0y3pfA46U3nig== Date: Thu, 26 Sep 2013 08:13:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD83F0xmbrcdx10ciscoc_" MIME-Version: 1.0 Subject: [CDNi] End of WG Last Call on draft-ietf-cdni-framework-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, 26 Sep 2013 08:13:20 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD83F0xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, This closes the WG Last Call on draft-ietf-cdni-framework-05.txt. If you still have comments/opinion to pass on, please do so right way. Cheers Francois On 10 Sep 2013, at 11:05, Francois Le Faucheur (flefauch) > wrote: All, This is the start of a two-week working group last call on draft-ietf-cdni-= framework-05.txt: https://datatracker.ietf.org/doc/draft-ietf-cdni-framework This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list. Francois & Daryl _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD83F0xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <0F55656EB343FD4288EBB2839F310FD6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Folks,

This closes the WG Last Call on draft-ietf-cdni-framework-05.txt.=

If you still have comments/opinion to pass on, please do so right way.=

Cheers

Francois

On 10 Sep 2013, at 11:05, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

All,

This is the start of a two-week working group last call on draft-ietf-= cdni-framework-05.txt:
http= s://datatracker.ietf.org/doc/draft-ietf-cdni-framework

This working group last call will end on 25 September 2013. Please send you= r comments to the CDNI mailing list.

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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BD83F0xmbrcdx10ciscoc_-- From internet-drafts@ietf.org Fri Sep 27 03:59: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 EB5F111E8150; Fri, 27 Sep 2013 03:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, 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 y+nInL+F1U-Q; Fri, 27 Sep 2013 03:59:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0F611E813A; Fri, 27 Sep 2013 03:59:18 -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.72 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20130927105918.11230.13652.idtracker@ietfa.amsl.com> Date: Fri, 27 Sep 2013 03:59:18 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-06.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 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, 27 Sep 2013 10:59:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Logging Interface Author(s) : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-06.txt Pages : 44 Date : 2013-09-27 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-logging-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From flefauch@cisco.com Fri Sep 27 05:42:52 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C513611E8156 for ; Fri, 27 Sep 2013 05:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.888 X-Spam-Level: X-Spam-Status: No, score=-9.888 tagged_above=-999 required=5 tests=[AWL=-0.561, BAYES_00=-2.599, FRT_BEFORE=1.272, 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 F8ymy9Vb4SXT for ; Fri, 27 Sep 2013 05:42:48 -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 1D63311E8149 for ; Fri, 27 Sep 2013 05:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6122; q=dns/txt; s=iport; t=1380285768; x=1381495368; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=33ojq3GrXAzWREzXELIrPyE/kMHrjLTdxVv3JelBdyE=; b=B27gOrZiA1XzpoIWMcJQwFqb6QMYTJm1itAMLv/w2ZK2KWJSk9eDb88U BKX/Vp1FoePd3CVagiGXUHr0uWcPtBp1Whrq065Wr0KqGcvenBP8qbOM4 dQerkkwXl2hTo9xzZOS8OVmsTeFkdu6MHC2ksKe2DNrgqvcu8uxUIp9YY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFADl8RVKtJXG+/2dsb2JhbABZgwc4TAbASoEeFnSCJQEBAQMBAQEBJBM0CwUHBAIBCBEEAQELFAkHJwsUCQgCBA4FCAGHdwYHBbohjx4CMQcGgxeBAQOZLJBJgySCKg X-IronPort-AV: E=Sophos;i="4.90,992,1371081600"; d="scan'208";a="265286816" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 27 Sep 2013 12:42:45 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8RCgj9b025280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 12:42:45 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 07:42:45 -0500 From: "Francois Le Faucheur (flefauch)" To: Kevin J Ma Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-05.txt Thread-Index: AQHOu38QlANYI6uoGECnOXIQBYhnRA== Date: Fri, 27 Sep 2013 12:42:44 +0000 Message-ID: References: <20130712114707.2936.83778.idtracker@ietfa.amsl.com> <291CC3F9E50E7641901A54E85D0977C6665133C13C@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6665133C13C@MAILR002.mail.lan> 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: <1F0DD083E349F745986E5CAD28C10850@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-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: Fri, 27 Sep 2013 12:42:52 -0000 Hi Kevin, Your comments below have been addressed in -06 that was just posted today i= n teh folowing way: On 29 Jul 2013, at 11:18, Kevin J Ma wrote: > Hi all, >=20 > some comments on the logging draft: >=20 > section 2.1: "benefit form" -> "benefit from" Done. >=20 > section 2.2.: "is obviously only indicative" -> "is obviously only an exa= mple" Done. > section 2.2.5.1: wrt CDNI, are we saying that logging should enable > the uCDN to debug the performance issues in the dCDN? No. The text has been tweaked to avoid suggesting that. >=20 > section 3.3: in general, should occurance be more precise? Yes. > e.g.: > UUID: "there MUST be one and only one instance of this directive." > should specify "per CDNI Logging File" Done. And similar change done for the other directives. > Fields: "The first instance of this directive for a given > Record-Type MUST precede any CDNI Logging Record for this > Record-Type." > should specify before the next Fields directive. > i.e., it is not required to group all the records for a > given Fields directive into a single block in the log file? I agree with the point you make. The text for "directive value" and "Occurrence" has been tweaked to reflect= that. eg: " directive value: this lists the names of all the fields for which a value is to appear in the CDNI Logging Records that follow the instance of this directive (until another instance of this directive).=20 " > section 3.3: for Verified-Origin, when would this be propogated? > Is the use case a transit CDN forwarding a log verbatim > from dCDN to uCDN? The use-case is really for the uCDN receiving the CDNI Logging File to stor= e the fact that it has verified the Origin itself at the time it received a= nd stored the file. For example, the uCDN may use HTTP/HTTPS mechanisms to = authenticate the dCDN providing teh CDNI Logging File, then it can record t= eh authenticated dCDN in the "Verified-Origin". IMHO this is not intended to be propagated, because it is not a universal a= uthentication. It is just an authentication by the uCDN based on its own au= thentication method. >=20 > section 3.3: for Integrity-Hash, it states that the hash is computed > "by the entity that transmits the CDNI Logging File." > though it is possible that the entity that generated the > log file is not the same entity that (re)transmits it. > does the integrity hash need to be recalculated? Right. The text has been changed to say: "The valid Integrity-Hash value is included in this directive by the entity= that transmits the CDNI Logging File". This allows all scenario: ie the trsnmitting entity computes it itself, or = it trusts some other entity that has already computed it. >=20 > section 3.3: the protocol, sc-status, and sc-total-bytes fields are > all mandatory, and HTTP-specific. In the case of > non-HTTP delivery, are these fields just left blank? > Or do we only support HTTP delivery (not that theres > anything wrong with that)? I believe we discussed this and agreed this record-type is exclusively for = HTTP delivery. Hence the record-type name of "cdni_http_request_v1". >=20 > sc-entity-bytes, cs(header), and sc(header) are also > HTTP-specific, but not required, >=20 > section 3.3: the s-cached flag is for: > "whether the Surrogate could serve the request using > content already stored on its local cache"=20 > Should it be fore whether the Surrogate "did serve the > request from content already stored in its local cache"? Agreed. Fixed. > in section 3: "agreements) ." -> "agreements)." Done. >=20 > thanx. Thank you for these thoughtful comments. Francois >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Friday, July 12, 2013 7:47 AM >> To: i-d-announce@ietf.org >> Cc: cdni@ietf.org >> Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-05.txt >>=20 >>=20 >> 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. >>=20 >> Title : CDNI Logging Interface >> Author(s) : Francois Le Faucheur >> Gilles Bertrand >> Iuniana Oprescu >> Roy Peterkofsky >> Filename : draft-ietf-cdni-logging-05.txt >> Pages : 44 >> Date : 2013-07-12 >>=20 >> Abstract: >> This memo specifies the Logging interface between a downstream CDN >> (dCDN) and an upstream CDN (uCDN) that are interconnected as per the >> CDN Interconnection (CDNI) framework. First, it describes a >> reference model for CDNI logging. Then, it specifies the CDNI >> Logging File format and the actual protocol for exchange of CDNI >> Logging Files. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-cdni-logging >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-cdni-logging-05 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-05 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Fri Sep 27 05:57: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 2786F11E815B for ; Fri, 27 Sep 2013 05:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5b7rtkQUxDB for ; Fri, 27 Sep 2013 05:57:24 -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 8AE2C11E815C for ; Fri, 27 Sep 2013 05:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8272; q=dns/txt; s=iport; t=1380286644; x=1381496244; h=from:to:cc:subject:date:message-id:mime-version; bh=XeOuOvuyQ+d73EA2gLqhR3m5KyARmk0jivDv2HlC4hw=; b=l5Iz7Aj9g7xs+FaUQt/qSeezQi38lN1AlBbcbDkTdDfnIbQTI8ws0LHc OUdFUNQlBKv/7xUcdKfcIeNGvHGtzhKHThbyUmDC5oN0VSH7JQfkKycLc 77sLpRfguKdwWNOIiJUCRCdefYPt584Oo3FgJf8fPMF/XHyQSBxCnB5xF w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAPB/RVKtJXG8/2dsb2JhbABQCYMHOFLAS4EeFnSCJwEEaw4SARYUA1MnBAoEDQGHfQy6JI4PgRExgySBAQOpdYMkgio X-IronPort-AV: E=Sophos;i="4.90,992,1371081600"; d="scan'208,217";a="265291609" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 27 Sep 2013 12:57:24 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r8RCvNn7030127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 12:57:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 07:57:23 -0500 From: "Francois Le Faucheur (flefauch)" To: Mark Nottingham Thread-Topic: Mark's review of cdni-logging text related to "compressed" transfer Thread-Index: AQHOu4EbsDLC8JkTHU2n4uuFj0pkww== Date: Fri, 27 Sep 2013 12:57:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04BEB444xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Mark's review of cdni-logging text related to "compressed" transfer X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 12:57:30 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BEB444xmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Mark, For memory, we discussed the following during the CDNI WG meeting in Berlin= : * we'd like to be able to exchange "CDNI Logging Files" in both uncompresse= d and compressed content encoding. * this is a common situation already well addressed by HTTP * "usual way is to advertise one URL then say in the content encoding wheth= er it is compressed" We have attempted to reflect this in the new version of our "CDNI Logging i= nterface": http://www.ietf.org/internet-drafts/draft-ietf-cdni-logging-06.txt Could you (or another HTTP expert that you may designate) have a look and l= et us know if you have comments, suggestions, concerns? The relevant part is section "4.2. CDNI Logging File Pull" of http://www.i= etf.org/internet-drafts/draft-ietf-cdni-logging-06.txt. For convenience, I have quoted below the related subset of the text, highli= ghing in red the text discussing the compressed encoding topic. Thanks for your help. Francois " A client-side implementation of the CDNI Logging interface MUST pull, at its convenience, a CDNI Logging File that is published by the server-side in the CDNI Logging Feed. To do so, the client-side: o MUST use HTTP v1.1 ( [RFC2616]) o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS") as per [RFC2818] whenever protection of the CDNI Logging information is required (see Section 6.1) o MUST use the URI that was associated to the CDNI Logging File (within the "src" attribute of the corresponding atom:content element) in the CDNI Logging Feed o MUST support exchange of uncompressed CDNI Logging Files (i.e. using "identity" content coding as defined in [RFC2616]) o SHOULD support exchange of gzip compressed CDNI Logging Files (i.e. using "gzip" content coding as defined in [RFC2616]) =85 The server-side implementation MUST respond to any valid pull request by a client-side implementation for a CDNI Logging File published by the server-side in the subscription document of the CDNI Logging Feed. The server-side implementation: o MUST handle the client-side request as per HTTP v1.1 o MUST include the CDNI Logging File identified by the request URI inside the body of the HTTP response o MUST support exchange of uncompressed CDNI Logging Files (i.e. using "identity" content-coding as defined in [RFC2616]) o SHOULD support exchange of gzip compressed CDNI Logging Files (i.e. using "gzip" content-coding as defined in [RFC2616] Content negotiation approaches defined in [RFC2616] (e.g. using Accept-Encoding request-header field or Content-Encoding entity- header field) MAY be used by the client-side and server-side implementations to establish the content-coding to be used for a particular exchange of a CDNI Logging File. " --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BEB444xmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hello Mark,

For memory, we discussed the following during the CDNI WG meeting in B= erlin:
* = ;we'd like to be able to exchange "CDNI Logging Files" in both un= compressed and compressed content encoding.
* this= is a common situation already well addressed by HTTP
* &quo= t;usual way is to advertise one URL then say in the content encoding whethe= r it is compressed"

We have attempted to reflect this in the new version of our "CDNI= Logging interface": 

Could you (or another HTTP expert that you may designate) have a look = and let us know if you have comments, suggestions, concerns?

The relevant part is section "4.2.  CDNI Logging File Pull&q= uot; of http://www.ietf.org/internet-drafts/draft-ietf-cdni-loggin= g-06.txt.
For convenience, I have quoted below the related subset of the text, h= ighlighing in red the text discussing the compressed encoding topic.

Thanks for your help.

Francois


"
   A client-side implementation of the CDNI Logging interfac= e MUST pull,
   at its convenience, a CDNI Logging File that is published by t= he
   server-side in the CDNI Logging Feed.  To do so, the client-side:

   o  MUST use HTTP v1.1 ( [RFC2616])

   o  SHOULD use TLS (i.e. use what is loosely referred to a= s "HTTPS")
      as per [RFC2818] whenever protection of the CDNI Loggi= ng
      information is required (see Section 6.1)

   o  MUST use the URI that was associated to the CDNI Loggi= ng File
      (within the "src" attribute of the correspon= ding atom:content
      element) in the CDNI Logging Feed

   o  MUST support exchange of uncom= pressed CDNI Logging Files (i.e.
      using "identity" content coding as defined i= n [RFC2616])

   o  SHOULD support exchange of gzip compressed CDNI Loggin= g Files
      (i.e. using "gzip" content coding as defined= in [RFC2616])

=85

 The server-side implementation MUST respond to any valid pull re= quest
   by a client-side implementation for a CDNI Logging File publis= hed by
   the server-side in the subscription document of the CDNI Loggi= ng
   Feed.  The server-side implementa= tion:

   o  MUST handle the client-side request as per HTTP v1.1
   o  MUST include the CDNI Logging File identified by the r= equest URI
      inside the body of the HTTP response

   o  MUST support exchange of uncom= pressed CDNI Logging Files (i.e.
      using "identity" content-coding as defined i= n [RFC2616])

   o  SHOULD support exchange of gzip compressed CDNI Loggin= g Files
      (i.e. using "gzip" content-coding as defined= in [RFC2616]

   Content negotiation approaches defined= in [RFC2616] (e.g. using
   Accept-Encoding request-header field or Content-Encoding entit= y-
   header field) MAY be used by the client-side and server-side    implementations to establish the content-coding to be used for= a
   particular exchange of a CDNI Logging File.
"


--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BEB444xmbrcdx10ciscoc_-- From flefauch@cisco.com Fri Sep 27 06:15:28 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 C733F11E814D for ; Fri, 27 Sep 2013 06:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.461 X-Spam-Level: X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 7dnBcirLFzxM for ; Fri, 27 Sep 2013 06:15:19 -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 7467111E8149 for ; Fri, 27 Sep 2013 06:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2297; q=dns/txt; s=iport; t=1380287718; x=1381497318; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=VgXyCaFlbYYH38Pf7tu7LsNGFCW6kA83jW1BlywXlwo=; b=RQYx3uZzFrIFny3prtvMlXdlEr0kdBfj5nrOf0zBxk15T13zqbRnqpGL /sCtNQUf2mUS6kMR1iQ+LRhgFCdi8LMIHIxP011sa4Bouqrnd2r0cLEXc tazSYA/5siGuab4OKV+1cqRJzEQkvOm98x2pKhJ6OjISn9pGZfhiPuMzH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFAO2DRVKtJXG+/2dsb2JhbABZgweBCsBLgR4WbQeCJwEEOlEBKgMRBT0nBBuHfpkIoSePIINVgQEDqXWBZoE+gio X-IronPort-AV: E=Sophos;i="4.90,992,1371081600"; d="scan'208";a="265317101" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 27 Sep 2013 13:15:18 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r8RDFHNT006691 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 27 Sep 2013 13:15:17 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 08:15:17 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI Logging : access to CDNI Logging File once it is moved from Subscription to Archive in the Logging Feed Thread-Index: AQHOu4ObUoHE8wHJKkqQcuD6pGxU7A== Date: Fri, 27 Sep 2013 13:15:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.196] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI Logging : access to CDNI Logging File once it is moved from Subscription to Archive in the Logging Feed X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:15:29 -0000 Folks, [as a co-author] I'd like input on one of the very remaining open items in cdni-logging. For memory, the CDNI Logging Feed allows a dCDN to advertise to the uCDN wh= ich CDNI Logging Files can be retrieved by the uCDN from the dCDN. It is structured as an Archived ATOM feed, meaning that a sliding window of= currently available CDNI Logging files is advertised in a "Subscription" d= ocument, and then, over time, the older Logging Files are moved to an "Arch= ive" document and new Logging Files appear in the Subscription document. There is currently an editor's note asking a question about what should hap= pen once a Logging File has been moved to an "archive": " [Editor's note: if a given Logging file is moved away from subscription document to an archive document, do we agree it may no longer be accessible to uCDN?] " I personally agree that the Logging File need not be made available for dow= nload once it has moved away from the Subscripton document to the Archive d= ocument. My rationale is that: * this is precisely the point of the Subscription document i.e. to indicat= e which files are currently downloadable and the server-side is then respon= sible for ensuring it can serve these files (ie it has to retain them and b= e ready to serve them).=20 * it is not reasonable to expect that the server-side will make old Loggin= g Files accessible forever * if the client-side wants to have a large window of time to pull Logging = Files, then it needs to agree with the server-side and this period will be = used as the retention period in the subscripton file.=20 Please let us know if you disagree/agree with that, so we can address that = in the next rev (this has not been addressed in -06 posted today). For memory, I think the current text already implies the above: " The server-side implementation MUST respond to any valid pull request by a client-side implementation for a CDNI Logging File published by the server-side in the subscription document of the CDNI Logging Feed.=20 " If we agree with the position above, we could also tweak the text to say th= at the server-side MUST respond _and_ actually provide the Logging File (ie= responding 404 is not good). Cheers Francois From flefauch@cisco.com Fri Sep 27 06:28: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 75A2021F9B92 for ; Fri, 27 Sep 2013 06:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 NMGZd6G9sf6c for ; Fri, 27 Sep 2013 06:28:54 -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 BF66821F960D for ; Fri, 27 Sep 2013 06:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=725; q=dns/txt; s=iport; t=1380288530; x=1381498130; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iCPNZ8/YvnK1/TNrUsCao1beQCGPMA8kGfFX49ivp30=; b=X0o8GqY7DhAETB8qQt4MCQ+chEdUIKCCwWNjKFLsvGOdueQV183EVkCs zHOaj2YjVcBK1RuTsa/oXYvq/wUO6XGN8mygHlokTdiZ3vVh12xa63SNI fcarY6vG5gZAlnFrS3SeFair1bf+XQBEVSyoJC/MwxNQvDYlGil/e/Q/A w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAP6GRVKtJXHA/2dsb2JhbABPCoMHgQrAS4EcFnSCJgEBBDo/EAIBKhQQMiUCBA4Nh366LI4OgRIxB4MdgQEDqXWDJIIq X-IronPort-AV: E=Sophos;i="4.90,992,1371081600"; d="scan'208";a="265305914" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 27 Sep 2013 13:28:50 +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 r8RDSosn018514 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Sep 2013 13:28:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Fri, 27 Sep 2013 08:28:49 -0500 From: "Francois Le Faucheur (flefauch)" To: Jan Seedorf Thread-Topic: Optional Capabilities for CDNI Logging Thread-Index: AQHOu4WAyjQ8Brg0IUCHYFMn5BaYQw== Date: Fri, 27 Sep 2013 13:28:49 +0000 Message-ID: References: <2779C9F0771F974CAD742BAE6D9904FE55604B98@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE55605381@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE55605381@DAPHNIS.office.hd> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Optional Capabilities for CDNI Logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2013 13:28:59 -0000 Jan and all, [as a cdni-logging co-author] I think we (cdni-logging authors) had an action item to identify the option= al capabilities of a dCDN related to CDNI Logging. There are currently three such optional capabilities: * support of anonymization and of the c-ip-anonimizing Logging Field * support for Content Collection IDentifier (CCID) and of the s-ccid Loggi= ng Field * support for Session IDentifier (SID) and of the s-sid Logging Field Support for all the other Logging Fields and associated finctioanlity is ma= ndatory in the sense that it must be supported by implementations. Please make sure these are covered/registered as appropriate in the FCI wor= k. Thank you. Francois From mnot@mnot.net Sun Sep 29 22:34:28 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 84BCA21F8459 for ; Sun, 29 Sep 2013 22:34:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.013 X-Spam-Level: X-Spam-Status: No, score=-105.013 tagged_above=-999 required=5 tests=[AWL=-3.014, BAYES_00=-2.599, J_CHICKENPOX_47=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMunXKV-iFbI for ; Sun, 29 Sep 2013 22:34:24 -0700 (PDT) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id A064221F99F8 for ; Sun, 29 Sep 2013 22:34:23 -0700 (PDT) Received: from syd-mpyvy.mnot.net (unknown [118.209.29.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id BC1E6509B5; Mon, 30 Sep 2013 01:34:21 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Mark Nottingham In-Reply-To: Date: Mon, 30 Sep 2013 15:35:27 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <5451B1A0-7B80-4939-A9F4-7EBDD680CBFC@mnot.net> References: To: Francois Le Faucheur (flefauch) X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Mon, 30 Sep 2013 00:07:05 -0700 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Mark's review of cdni-logging text related to "compressed" transfer 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, 30 Sep 2013 05:34:28 -0000 Hi Francois, On 27/09/2013, at 10:57 PM, Francois Le Faucheur (flefauch) = wrote: >=20 > " > A client-side implementation of the CDNI Logging interface MUST = pull, > at its convenience, a CDNI Logging File that is published by the > server-side in the CDNI Logging Feed. To do so, the client-side: >=20 > o MUST use HTTP v1.1 ( [RFC2616]) >=20 > o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS") > as per [RFC2818] whenever protection of the CDNI Logging > information is required (see Section 6.1) >=20 > o MUST use the URI that was associated to the CDNI Logging File > (within the "src" attribute of the corresponding atom:content > element) in the CDNI Logging Feed >=20 > o MUST support exchange of uncompressed CDNI Logging Files (i.e. > using "identity" content coding as defined in [RFC2616]) "identity" was left in 2616 by mistake; there is no identity coding. = See: = http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-5.3.= 4 and = http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-3.1.= 2.1 >=20 > o SHOULD support exchange of gzip compressed CDNI Logging Files > (i.e. using "gzip" content coding as defined in [RFC2616]) >=20 > =85 >=20 > The server-side implementation MUST respond to any valid pull request > by a client-side implementation for a CDNI Logging File published = by > the server-side in the subscription document of the CDNI Logging > Feed. The server-side implementation: >=20 > o MUST handle the client-side request as per HTTP v1.1 >=20 > o MUST include the CDNI Logging File identified by the request URI > inside the body of the HTTP response >=20 > o MUST support exchange of uncompressed CDNI Logging Files (i.e. > using "identity" content-coding as defined in [RFC2616]) >=20 > o SHOULD support exchange of gzip compressed CDNI Logging Files > (i.e. using "gzip" content-coding as defined in [RFC2616] >=20 > Content negotiation approaches defined in [RFC2616] (e.g. using > Accept-Encoding request-header field or Content-Encoding entity- > header field) MAY be used by the client-side and server-side > implementations to establish the content-coding to be used for a > particular exchange of a CDNI Logging File. > " Cheers, -- Mark Nottingham http://www.mnot.net/ From flefauch@cisco.com Mon Sep 30 00:28:58 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 0277121F9C89 for ; Mon, 30 Sep 2013 00:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.073 X-Spam-Level: X-Spam-Status: No, score=-10.073 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtMhSnp6EpTm for ; Mon, 30 Sep 2013 00:28:48 -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 94A3721F9C6C for ; Mon, 30 Sep 2013 00:28:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13340; q=dns/txt; s=iport; t=1380526108; x=1381735708; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=szuUEbPXK+61V3g9W8WOuhQ7EA/lJX2cVVspeKPWHDU=; b=nGve4NqzP8lakAM84yhTqesfME0I73/Iyo4Trd6CkX2tpX885Xd9L35D L6MoJcsCkldjWkC+7xDfEct3/MpytCbpj1KhUOqJAecukdeyVDAYvC6a9 WgMaIDeTsjgk7tAgEjZuvxtpWH6O1c7X99cVa+Gi4GWo4/OwJjURqr5Do 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAB4nSVKtJV2b/2dsb2JhbABRCYMHOFK4OIhCgSUWdIImAQEEeRACAQgOFAMaBzIUEQIECgQFCId+DLwrjg+BETEHCYMWgQMDmS6QSoMkgio X-IronPort-AV: E=Sophos;i="4.90,1006,1371081600"; d="scan'208,217";a="266034574" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 30 Sep 2013 07:28:27 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r8U7SRsT022039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Sep 2013 07:28:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.33]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Mon, 30 Sep 2013 02:28:26 -0500 From: "Francois Le Faucheur (flefauch)" To: Mark Nottingham Thread-Topic: Mark's review of cdni-logging text related to "compressed" transfer Thread-Index: AQHOu4EbsDLC8JkTHU2n4uuFj0pkw5neGouAgAAfjwA= Date: Mon, 30 Sep 2013 07:28:25 +0000 Message-ID: References: <5451B1A0-7B80-4939-A9F4-7EBDD680CBFC@mnot.net> In-Reply-To: <5451B1A0-7B80-4939-A9F4-7EBDD680CBFC@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D04BF97DCxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Mark's review of cdni-logging text related to "compressed" transfer 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, 30 Sep 2013 07:28:59 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BF97DCxmbrcdx10ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Mark, Thanks much for your reviwe and comment. Looking at the pointers you sent, I understand that "identity" can still be= conveyed by the client inside "Accept-Encoding" but is no longer to be con= veyed by the server inside "Content-Encoding". To reflect this, I tweaked the text (see below) using the phrase "without e= ncoding applied to the representation". Let us know if this all good now, or not. Thanks Francois " A client-side implementation of the CDNI Logging interface MUST pull, at its convenience, a CDNI Logging File that is published by the server-side in the CDNI Logging Feed. To do so, the client-side: o MUST use HTTP v1.1 ( [RFC2616]) o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS") as per [RFC2818] whenever protection of the CDNI Logging information is required (see Section 6.1) o MUST use the URI that was associated to the CDNI Logging File (within the "src" attribute of the corresponding atom:content element) in the CDNI Logging Feed o MUST support exchange of CDNI Logging Files without content encoding = applied to the representation o SHOULD support exchange of CDNI Logging Files with "gzip" content enc= oding (as defined in [RFC2616]) applied to the representation =85 The server-side implementation MUST respond to any valid pull request by a client-side implementation for a CDNI Logging File published by the server-side in the subscription document of the CDNI Logging Feed. The server-side implementation: o MUST handle the client-side request as per HTTP v1.1 o MUST include the CDNI Logging File identified by the request URI inside the body of the HTTP response o MUST support exchange of CDNI Logging Files without content encoding = applied to the representation o SHOULD support exchange of CDNI Logging Files with "gzip" content enc= oding (as defined in [RFC2616]) applied to the representation Content negotiation approaches defined in [RFC2616] (e.g. using Accept-Encoding request-header field or Content-Encoding entity- header field) MAY be used by the client-side and server-side implementations to establish the content-coding to be used for a particular exchange of a CDNI Logging File. " On 30 Sep 2013, at 07:35, Mark Nottingham > wrote: Hi Francois, On 27/09/2013, at 10:57 PM, Francois Le Faucheur (flefauch) > wrote: " A client-side implementation of the CDNI Logging interface MUST pull, at its convenience, a CDNI Logging File that is published by the server-side in the CDNI Logging Feed. To do so, the client-side: o MUST use HTTP v1.1 ( [RFC2616]) o SHOULD use TLS (i.e. use what is loosely referred to as "HTTPS") as per [RFC2818] whenever protection of the CDNI Logging information is required (see Section 6.1) o MUST use the URI that was associated to the CDNI Logging File (within the "src" attribute of the corresponding atom:content element) in the CDNI Logging Feed o MUST support exchange of uncompressed CDNI Logging Files (i.e. using "identity" content coding as defined in [RFC2616]) "identity" was left in 2616 by mistake; there is no identity coding. See: http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-5.3.= 4 and http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-24#section-3.1.= 2.1 o SHOULD support exchange of gzip compressed CDNI Logging Files (i.e. using "gzip" content coding as defined in [RFC2616]) =85 The server-side implementation MUST respond to any valid pull request by a client-side implementation for a CDNI Logging File published by the server-side in the subscription document of the CDNI Logging Feed. The server-side implementation: o MUST handle the client-side request as per HTTP v1.1 o MUST include the CDNI Logging File identified by the request URI inside the body of the HTTP response o MUST support exchange of uncompressed CDNI Logging Files (i.e. using "identity" content-coding as defined in [RFC2616]) o SHOULD support exchange of gzip compressed CDNI Logging Files (i.e. using "gzip" content-coding as defined in [RFC2616] Content negotiation approaches defined in [RFC2616] (e.g. using Accept-Encoding request-header field or Content-Encoding entity- header field) MAY be used by the client-side and server-side implementations to establish the content-coding to be used for a particular exchange of a CDNI Logging File. " Cheers, -- Mark Nottingham http://www.mnot.net/ --_000_FC236DA6F2DA77449EF2D02DF4471A8D04BF97DCxmbrcdx10ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hello Mark,

Thanks much for your reviwe and comment. 
Looking at the pointers you sent, I understand that "identity&quo= t; can still be conveyed by the client inside "Accept-Encoding" b= ut is no longer to be conveyed by the server inside "Content-Encoding&= quot;. 
To reflect this, I tweaked the text (see below) using the phrase "= ;without encoding applied to the representation".
Let us know if this all good now, or not.
Thanks 

Francois



"
   A client-side implementation of the CDNI Logging interfac= e MUST pull,
   at its convenience, a CDNI Logging File that is published by t= he
   server-side in the CDNI Logging Feed.  To do so, the client-side:

   o  MUST use HTTP v1.1 ( [RFC2616])

   o  SHOULD use TLS (i.e. use what is loosely referred to a= s "HTTPS")
      as per [RFC2818] whenever protection of the CDNI Loggi= ng
      information is required (see Section 6.1)

   o  MUST use the URI that was associated to the CDNI Loggi= ng File
      (within the "src" attribute of the correspon= ding atom:content
      element) in the CDNI Logging Feed

   o  MUST support exchange of CDNI = Logging Files without content encoding applied to the representation=

   o  SHOULD support exchange of CDNI Logging Files with &qu= ot;gzip" content encoding (as defined in [RFC2616]) applied to the representation 
      

=85

 The server-side implementation MUST respond to any valid pull re= quest
   by a client-side implementation for a CDNI Logging File publis= hed by
   the server-side in the subscription document of the CDNI Loggi= ng
   Feed.  The server-side implementa= tion:

   o  MUST handle the client-side request as per HTTP v1.1
   o  MUST include the CDNI Logging File identified by the r= equest URI
      inside the body of the HTTP response

   o  MUST support exchange of = CDNI Logging Files wi= thout content encoding applied to the representation

   o  SHOULD support exchange of CDNI Logging Files with "gzip" content encoding (as defined in [RFC2616])&nbs= p;applied to the represent= ation 

   Content negotiation approaches defined= in [RFC2616] (e.g. using
   Accept-Encoding request-header field or Content-Encoding entit= y-
   header field) MAY be used by the client-side and server-side    implementations to establish the content-coding to be used for= a
   particular exchange of a CDNI Logging File.
"




On 30 Sep 2013, at 07:35, Mark Nottingham <mnot@mnot.net>
 wrote:

Hi Francois,

On 27/09/2013, at 10:57 PM, Francois Le Faucheur (flefauch) <flefauch@cisco.com> wrote:

"
  A client-side implementation of the CDNI Logging interface MUST= pull,
  at its convenience, a CDNI Logging File that is published by th= e
  server-side in the CDNI Logging Feed.  To do so, the clien= t-side:

  o  MUST use HTTP v1.1 ( [RFC2616])

  o  SHOULD use TLS (i.e. use what is loosely referred to as= "HTTPS")
     as per [RFC2818] whenever protection of the C= DNI Logging
     information is required (see Section 6.1)

  o  MUST use the URI that was associated to the CDNI Loggin= g File
     (within the "src" attribute of the = corresponding atom:content
     element) in the CDNI Logging Feed

  o  MUST support exchange of uncompressed CDNI Logging File= s (i.e.
     using "identity" content coding as = defined in [RFC2616])

"identity" was left in 2616 by mistake; there is no identity codi= ng. See:
 http://tools.ietf.org/html/draft-ietf-httpbis-p2-semanti= cs-24#section-5.3.4
and
 http://tools.ietf.org/html/draft-ietf-httpbis-p2-seman= tics-24#section-3.1.2.1


  o  SHOULD support exchange of gzip compressed CDNI Logging= Files
     (i.e. using "gzip" content coding a= s defined in [RFC2616])

=85

The server-side implementation MUST respond to any valid pull request
  by a client-side implementation for a CDNI Logging File publish= ed by
  the server-side in the subscription document of the CDNI Loggin= g
  Feed.  The server-side implementation:

  o  MUST handle the client-side request as per HTTP v1.1
  o  MUST include the CDNI Logging File identified by the re= quest URI
     inside the body of the HTTP response

  o  MUST support exchange of uncompressed CDNI Logging File= s (i.e.
     using "identity" content-coding as = defined in [RFC2616])

  o  SHOULD support exchange of gzip compressed CDNI Logging= Files
     (i.e. using "gzip" content-coding a= s defined in [RFC2616]

  Content negotiation approaches defined in [RFC2616] (e.g. using=
  Accept-Encoding request-header field or Content-Encoding entity= -
  header field) MAY be used by the client-side and server-side   implementations to establish the content-coding to be used for = a
  particular exchange of a CDNI Logging File.
"

Cheers,

--
Mark Nottingham   http://www.mno= t.net/




--_000_FC236DA6F2DA77449EF2D02DF4471A8D04BF97DCxmbrcdx10ciscoc_--