From nobody Thu Jun 5 01:43:01 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B3E1A0102 for ; Thu, 5 Jun 2014 01:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NVriyStTJwv for ; Thu, 5 Jun 2014 01:42:58 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687931A00F8 for ; Thu, 5 Jun 2014 01:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=200; q=dns/txt; s=iport; t=1401957772; x=1403167372; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=fNOaAC+t18mWM31Rt/GPpzCp+B+U/vRd6ip16MN9BNM=; b=gvqbRpfE6C498/Kz0ejNG5PyBMtXxNYd3g3ByajoIq6WHKAzDnXV8s8+ yiQx3+6mi/nsnPr80PZu2hE05+eLTTPz+kkreFElnzrCcV4T0Ih0LQ7or AlTQwpEG08V0YfkhYDJDykTAFrhYrgY6NSWqimW1OEMBWu7Z9wI9qHyxR s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHEskFOtJA2N/2dsb2JhbABZgweBKsJ7gQ0WdIIseRIBgQAnBA6IR9NBF45SgzKBFQSaE5M5gziCLw X-IronPort-AV: E=Sophos;i="4.98,979,1392163200"; d="scan'208";a="50433087" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP; 05 Jun 2014 08:42:51 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s558gpKP007285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jun 2014 08:42:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 5 Jun 2014 03:42:51 -0500 From: "Francois Le Faucheur (flefauch)" To: "Brandenburg, R. (Ray) van" Thread-Topic: cdni-framework typo in Figure 2? Thread-Index: AQHPgJoi3k7PBUQEDUuUGG9Wckj1tg== Date: Thu, 5 Jun 2014 08:42:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.111.58] Content-Type: text/plain; charset="Windows-1252" Content-ID: <80EE70258C40664C9BB7939EA57BE05A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/Uai9dDLUE0yyKMXPQr8_V0K3AwU Cc: "cdni@ietf.org" Subject: [CDNi] cdni-framework typo in Figure 2? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2014 08:42:59 -0000 Ray and all, I think there is a small mistake in Figure 2: Figure 2: OLD: =93 RI REPLY =93 NEW: =93 CONTENT REQUEST REDIRECTION =93 Or am I missing something? Thanks Francois= From nobody Thu Jun 5 02:29:20 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 833351A0431 for ; Thu, 5 Jun 2014 02:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.443 X-Spam-Level: * X-Spam-Status: No, score=1.443 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kvab4zpZvzhM for ; Thu, 5 Jun 2014 02:29:17 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE751A0436 for ; Thu, 5 Jun 2014 02:29:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.98,980,1392159600"; d="scan'208";a="26588906" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1a.tno.nl with ESMTP; 05 Jun 2014 11:29:04 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB03.tsn.tno.nl ([fe80::6d39:f277:173e:a926%13]) with mapi id 14.03.0174.001; Thu, 5 Jun 2014 11:29:04 +0200 From: "Brandenburg, R. (Ray) van" To: "Francois Le Faucheur (flefauch)" Thread-Topic: cdni-framework typo in Figure 2? Thread-Index: AQHPgJoi3k7PBUQEDUuUGG9Wckj1tptiP03A Date: Thu, 5 Jun 2014 09:29:04 +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: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/uyfgWOalM_72OYawDQ5MTDGjgeI Cc: "cdni@ietf.org" Subject: Re: [CDNi] cdni-framework typo in Figure 2? X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 05 Jun 2014 09:29:18 -0000 Hi Francois, Nice find! It seems the error has been in there since the -02 version. I'll= fix it. Ray -----Original Message----- From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] = Sent: donderdag 5 juni 2014 10:43 To: Brandenburg, R. (Ray) van Cc: cdni@ietf.org Subject: cdni-framework typo in Figure 2? Ray and all, I think there is a small mistake in Figure 2: Figure 2: OLD: " RI REPLY " NEW: " CONTENT REQUEST REDIRECTION " Or am I missing something? Thanks Francois Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. From nobody Fri Jun 6 13:38:26 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46DF41A0025; Fri, 6 Jun 2014 13:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J2xOvYOAXLnN; Fri, 6 Jun 2014 13:38:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42CDC1A0274; Fri, 6 Jun 2014 13:38:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.4.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140606203819.15511.42776.idtracker@ietfa.amsl.com> Date: Fri, 06 Jun 2014 13:38:19 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/gSKGezgFy73ej4qM1-GB8IJi_qQ Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-framework-14.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 20:38:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : Framework for CDN Interconnection Authors : Larry Peterson Bruce Davie Ray van Brandenburg Filename : draft-ietf-cdni-framework-14.txt Pages : 56 Date : 2014-06-06 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 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. This document, in combination with RFC 6707, 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-14 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-framework-14 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 nobody Wed Jun 11 06:13:45 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A785F1A00B2; Wed, 11 Jun 2014 06:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfTyfeEhcsXZ; Wed, 11 Jun 2014 06:13:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E2B131A02A9; Wed, 11 Jun 2014 06:13:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140611131315.22111.20885.idtracker@ietfa.amsl.com> Date: Wed, 11 Jun 2014 06:13:15 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/oe7OdsShHVodfFW0XRSqVP3FXvg Cc: cdni chair , cdni mailing list , RFC Editor Subject: [CDNi] Document Action: 'Framework for CDN Interconnection' to Informational RFC (draft-ietf-cdni-framework-14.txt) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2014 13:13:40 -0000 The IESG has approved the following document: - 'Framework for CDN Interconnection' (draft-ietf-cdni-framework-14.txt) as Informational RFC This document is the product of the Content Delivery Networks Interconnection Working Group. The IESG contact persons are Spencer Dawkins and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-cdni-framework/ Technical Summary 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 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. Working Group Summary No unusual controversy. There was solid consensus on early requests for input on whether or not the document was ready for last call. Later requests for input after reviews and iterations of the document took place resulted is feedback from a fewer number of WG participants. The shepherd feels this was the result of previous consensus and input and relative approval of the minor incremental changes. Document Quality The protocol has been implemented by a couple of vendors as a prototype, including Cisco and Alcatel-Lucent (Velocix). It is in early stages of development. No special reviewers needed. Personnel Daryl Malas (WG Co-chair) is the Document Shepherd. Spencer Dawkins is the Responsible Area Director. From nobody Sun Jun 15 23:40:09 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC6AE1B2C05; Sun, 15 Jun 2014 23:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STt6tlh0Ssqi; Sun, 15 Jun 2014 23:40:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 933771B2BF6; Sun, 15 Jun 2014 23:40:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.5.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140616064006.29255.60940.idtracker@ietfa.amsl.com> Date: Sun, 15 Jun 2014 23:40:06 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/KvndxNKc2MRFifJN16_v-whG8Oo Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-uri-signing-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 06:40:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. Title : URI Signing for CDN Interconnection (CDNI) Authors : Kent Leung Francois Le Faucheur Ray van Brandenburg Bill Downey Michel Fisher Filename : draft-ietf-cdni-uri-signing-00.txt Pages : 35 Date : 2014-06-15 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signing/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-uri-signing-00 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 nobody Sun Jun 15 23:57:27 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2211C1B2C09 for ; Sun, 15 Jun 2014 23:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAA4q0g_d7IR for ; Sun, 15 Jun 2014 23:57:23 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id E9C2A1B2B5C for ; Sun, 15 Jun 2014 23:57:22 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.01,484,1400018400"; d="scan'208,217"; a="27014703" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 16 Jun 2014 08:57:13 +0200 Received: from EXC-MBX03.tsn.tno.nl ([fe80::e969:1300:fb9f:7e12]) by EXC-CASHUB02.tsn.tno.nl ([fe80::8c02:de2a:3094:171%14]) with mapi id 14.03.0174.001; Mon, 16 Jun 2014 08:57:13 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-ietf-cdni-uri-signing-00.txt Thread-Index: AQHPiS3SyiasG05xb0aepX9e4CIB0ZtzTgqP Date: Mon, 16 Jun 2014 06:57:12 +0000 Message-ID: References: <20140616064006.29255.50497.idtracker@ietfa.amsl.com> In-Reply-To: <20140616064006.29255.50497.idtracker@ietfa.amsl.com> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_E691DF8C7AAF44BAAE3F15392B897F27tnonl_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/-CS7g1DFTv5Xmj_HjGwkiDWD4k8 Subject: [CDNi] Fwd: New Version Notification for draft-ietf-cdni-uri-signing-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jun 2014 06:57:26 -0000 --_000_E691DF8C7AAF44BAAE3F15392B897F27tnonl_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi all, As you can see, I've just submitted the post-WGLC version of the URI Signin= g draft as draft-ietf-uri-signing-00. We've addressed the comments received during WGLC from Ben and Iuniana, as = well as minor editorial work. We plan to publish another new revision before the Toronto deadline that wi= ll mostly address the Metadata and IANA considerations sections. Best regards, Ray Begin forwarded message: From: > Date: 16 juni 2014 08:40:06 CEST To: Ray van Brandenburg >, Michel Fisher >, Kent= Leung >, Bill Downey >, Michel Fisher >, Bill Downey >, Kent Leung >, "Francois Le Faucheur" >, Ray van Brandenburg >, Francois Le Faucheur > Subject: New Version Notification for draft-ietf-cdni-uri-signing-00.txt A new version of I-D, draft-ietf-cdni-uri-signing-00.txt has been successfully submitted by Ray van Brandenburg and posted to the IETF repository. Name: draft-ietf-cdni-uri-signing Revision: 00 Title: URI Signing for CDN Interconnection (CDNI) Document date: 2014-06-15 Group: cdni Pages: 35 URL: http://www.ietf.org/internet-drafts/draft-ietf-cdni-uri-sig= ning-00.txt Status: https://datatracker.ietf.org/doc/draft-ietf-cdni-uri-signin= g/ Htmlized: http://tools.ietf.org/html/draft-ietf-cdni-uri-signing-00 Abstract: This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing scheme. The proposed URI signing method specifies the information needed to be included in the URI and the algorithm used to authorize and to validate access requests for the content referenced by the URI. Some of the information may be accessed by the CDN via configuration or CDNI metadata. 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. The IETF Secretariat Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u ni= et de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, = wordt u verzocht dat aan de afzender te melden en het bericht te verwijdere= n. TNO aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de = wijze waarop u deze gebruikt en voor schade, van welke aard ook, die verban= d houdt met risico's verbonden aan het elektronisch verzenden van berichten. = This message may contain information that is not intended for you. If you a= re not the addressee or if this message was sent to you by mistake, you are= requested to inform the sender and delete the message. TNO accepts no liab= ility for the content of this e-mail, for the manner in which you use it an= d for damage of any kind resulting from the risks inherent to the electroni= c transmission of messages. --_000_E691DF8C7AAF44BAAE3F15392B897F27tnonl_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Hi all,

As you can see, I've just submitted the post-WGLC version of the URI S= igning draft as draft-ietf-uri-signing-00. 

We've addressed the comments received during WGLC from Ben and Iuniana= , as well as minor editorial work. 

We plan to publish another new revision before the Toronto deadline th= at will mostly address the Metadata and IANA considerations sections. =

Best regards,

Ray


Begin forwarded message:

From: <internet-= drafts@ietf.org>
Date: 16 juni 2014 08:40:06 CEST
To: Ray van Brandenburg <ray.vanbrandenburg@tno.nl>, Michel Fisher <mfisher@llnw.com>, Kent Leung <kleung@cisco.com>, Bill Downey <william.s.downey@veriz= on.com>, Michel Fisher <mfish= er@llnw.com>, Bill Downey <william.s.downey@verizon.com>, Kent Leung <kleung@cisco.com>, "Fr= ancois Le Faucheur" <flefauch= @cisco.com>, Ray van Brandenburg <ray.vanbrandenburg@tno.nl>, Francois Le Faucheur <flefauch@cisco.com>
Subject: New Version Notification for draft-ietf-cdni-uri-signing= -00.txt


A new version of I-D, draft-ietf-cdni-uri-signing-00.txt
has been successfully submitted by Ray van Brandenburg and posted to = the
IETF repository.

Name:        draft-ietf-cdni-uri-signing Revision:    00
Title:        URI Signing for CDN Interconnection= (CDNI)
Document date:    2014-06-15
Group:        cdni
Pages:        35
URL:           &nbs= p;http://www.ietf.org/internet-drafts/draft-ietf-cdni-uri-signing-0= 0.txt
Status:         https://datatr= acker.ietf.org/doc/draft-ietf-cdni-uri-signing/
Htmlized:       http://tools.ietf.org/html/d= raft-ietf-cdni-uri-signing-00


Abstract:
  This document describes how the concept of URI signing su= pports the
  content access control requirements of CDNI and proposes = a URI
  signing scheme.

  The proposed URI signing method specifies the information= needed to
  be included in the URI and the algorithm used to authoriz= e and to
  validate access requests for the content referenced by th= e URI.  Some
  of the information may be accessed by the CDN via configu= ration or
  CDNI metadata.




Please note that it may take a couple of minutes from the time of sub= mission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




Dit b= ericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de= geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt= u verzocht dat aan de afzender te melden en het bericht te verwijderen. TN= O aanvaardt geen aansprakelijkheid voor de inhoud van deze e-mail, de wijze= waarop u deze gebruikt en voor schade, van welke aard ook, die verband hou= dt met risico's verbonden aan het elektronisch verzenden van berichten.
=

 

This m= essage may contain information that is not intended for you. If you are not= the addressee or if this message was sent to you by mistake, you are reque= sted to inform the sender and delete the message. TNO accepts no liability = for the content of this e-mail, for the manner in which you use it and for = damage of any kind resulting from the risks inherent to the electronic tran= smission of messages.

--_000_E691DF8C7AAF44BAAE3F15392B897F27tnonl_-- From nobody Mon Jun 23 02:45:27 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A641B28DA for ; Mon, 23 Jun 2014 02:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.891 X-Spam-Level: X-Spam-Status: No, score=-14.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TitYKjc7oKhl for ; Mon, 23 Jun 2014 02:45:25 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1388D1B28C5 for ; Mon, 23 Jun 2014 02:45:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1210; q=dns/txt; s=iport; t=1403516725; x=1404726325; h=from:to:subject:date:message-id:mime-version; bh=UzdCeSNGZu/5jqftvuAezFJC3jfrLWJE2nUnQ/yILtA=; b=LYIkooRX0RSKk8AYd68utyxIB6sDxWlCU/r1Yi6LsVgeow8jvZLqL/xW kdpZ4JLAG6mU8kjFC1/QsruozLSUdv/hsP7EYT4jZv3fpbipNP19raMhu oMuXB9Q7y5LokvSjREHlcpXs8hnnWExncQgvjZhFCg4jWuUhYaCYZKZLY U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFAPn1p1OtJV2S/2dsb2JhbABZgkZHUlrDeIEMFnWDehCBCwELAXQnBIhVDZkGrH0TBItagx6DOIEWBJpMk2ODQoIw X-IronPort-AV: E=Sophos; i="5.01,529,1400025600"; d="scan'208,217"; a="55177739" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 23 Jun 2014 09:45:23 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s5N9jNZ8012806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 23 Jun 2014 09:45:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Mon, 23 Jun 2014 04:45:23 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Friendly reminder: I-D cut-off is 4 July 2014 Thread-Index: AQHPjsfaT22A5Px6r02a5pjOFIDPtg== Date: Mon, 23 Jun 2014 09:45:23 +0000 Message-ID: <8CD9BAB0-6FF0-4F97-8EA4-C8173A434DC1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] Content-Type: multipart/alternative; boundary="_000_8CD9BAB06FF04F978EA4C8173A434DC1ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/kL2uKr1Bovhn5iwqZAwKfRTHyyw Subject: [CDNi] Friendly reminder: I-D cut-off is 4 July 2014 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 09:45:26 -0000 --_000_8CD9BAB06FF04F978EA4C8173A434DC1ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable * 2014-07-04 (Friday): Internet Draft submission cut-off (for all draft= s, including -00) by UTC 23:59, upload usingIETF ID Submission Tool. --_000_8CD9BAB06FF04F978EA4C8173A434DC1ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <30796A6A18774C43A8E8A8E29FE186B4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
  • 2014-07-04 (Friday): Internet Draft submission cu= t-off (for all drafts, including -00) by UTC 23:59, upload usingIETF ID Submission Tool.

    • --_000_8CD9BAB06FF04F978EA4C8173A434DC1ciscocom_-- From nobody Tue Jun 24 18:02:08 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB251B29EE for ; Tue, 24 Jun 2014 18:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsfX4gTPp8uH for ; Tue, 24 Jun 2014 18:02:03 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E5AA1B291A for ; Tue, 24 Jun 2014 18:02:03 -0700 (PDT) X-AuditID: c6180641-f79df6d000002de0-9e-53a9cb9382a6 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 53.65.11744.39BC9A35; Tue, 24 Jun 2014 21:03:48 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0174.001; Tue, 24 Jun 2014 21:01:53 -0400 From: Kevin Ma J To: Ben Niven-Jenkins , Francois Le Faucher Thread-Topic: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] Thread-Index: AQHPYsTR4Y8R725o90md4tCkXk59p5uBVtqA Date: Wed, 25 Jun 2014 01:01:52 +0000 Message-ID: References: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPuO6U0yuDDV5t4LJYcG4Cm8XT2X9Y LWZdO85m8W/BaSYHFo8pvzeyeixZ8pPJ4+f1SYweXy5/ZgtgieKySUnNySxLLdK3S+DKWLza qOCTX8XOl6vZGhjv2XYxcnJICJhITDi/gwnCFpO4cG89WxcjF4eQwFFGiX3X3rGCJIQEljNK zOsxBLHZBLQkHn/9C9YgIhAt8eHxd3YQm1mgSuLLq4+MXYwcHMICQRIzvpVBlARLXJl8gA3C NpJ4f7gBrJVFQFViT898sFZeAW+JBzOfgrUKCVRKbF/LARLmFHCX6DwFEubkYAQ67fupNUwQ m8Qlbj2ZD3WygMSSPeeZIWxRiZeP/7FC2EoSc15fY4ao15FYsPsTG4StLbFs4WtmiLWCEidn PmGZwCg2C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCPDTYzAODomwea4g3HBJ8tDjAIcjEo8 vAo+K4OFWBPLiitzDzFKc7AoifNqVs8LFhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cAYsO+1 aenm48v8H89a//Dac53fN/O2/oo+xnJM8m18aIDHkYeMCiZm0lqO7d9bV+70V5DiyVwgyh8V INd+9IBPYH7Lo1VPBDPe6m14IuXyc8+hXnbfjZlhDiIZCpm2mZ9N3QLUv+V8FtE+zPSA6eJT lYJdxqm33qQa1jTMSZxtM9FPaW7N7sNKLMUZiYZazEXFiQDCg0pphAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/gvCuwJ1JnOZUWmnLNvnSHUXxiy4 Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 01:02:06 -0000 Hi Francois, We were looking for clarification wrt to the following comment: > Can you make sure the applicability of the metadata defined in this docum= ents is discussed in terms of what types of deliveries are supported (HTTP/= 1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the text I proposed on t= he list for cdni-logging. I think we intentionally made the metadata delivery protocol agnostic. - LocationACL, TimeWindowACL, and Grouping are all protocol agnostic. - Source and ProtocolACL specify lists of protocols, but are not themselv= es protocol specific. - Cache only deals with query strings, which is scheme agnostic and works= with any URI. - Auth is also protocol agnostic. Though credential auth can be used wit= h HTTP, the specification of username and password is not itself protocol speci= fic. The CDNI logging draft specifies an HTTP specific logging format, and thu= s requires variant considerations for 1.x vs 2.x vs w/ TLS; I don't see metadata requiring t= his distinction. I'm not sure that adding text to discuss HTTP variants is necessary. If = you agree, then we will disregard this portion of the comment? If you still think we nee= d some text, would it be sufficient to simply state that all the defined metadata is p= rotocol agnostic? thanx! -- Kevin J. Ma -----Original Message----- From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Monday, April 28, 2014 5:32 AM To: Francois Le Faucher Cc: draft-ietf-cdni-metadata@tools.ietf.org; cdni@ietf.org Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Bat= ch 4] Francois, I have incorporated the editorial comments from below. Some of your comment= s require some discussions with my co-authors so I've marked them as "Desig= n" below and we'll follow up later with proposed resolutions for them. Ben On 12 Mar 2014, at 13:51, Francois Le Faucheur (flefauch) wrote: > (Note: I stopped detailed review at 4.2.4 even if I have a few comments b= eyond that). >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > General comments: >=20 > *** somewhere (probably towards the beginning of the document): > Can you make sure the applicability of the metadata defined in this docum= ents is discussed in terms of what types of deliveries are supported (HTTP/= 1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the text I proposed on t= he list for cdni-logging. > Also how about adding a summary of features supported by specified=20 > metadata (eg geolocation, time window, multipe acquisitions, ...) Design, will address in a follow-up e-mail. > *** use of MUST: > I think this needs a clean-up: > o there are a number of appropriate MUST statements on detailed things, b= ut I can't see one statement clarifying exhaustively which object is mandat= ory to implement as an uCDN and as a dCDN. Can you make sure this is covere= d , if not already covered? > o there are a few "must" that we may want to replace with alternate=20 > phrases ( "needs to", "has to", ...) o there are MUSTs in the IANA sectio= n (eg 7.1). Based on the conversation we had in teh contaxt of cdni-logging= , I assume these will be edited out. Design, will address in a follow-up e-mail. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Detailed comments: >=20 >=20 > *** section 4.1.3: > "First match applies." > Might be worth turning into a full sentence explaining the context of the= "match" ie when metadata is walked through to find the relevant one for a = piece of content to be processed , every path-pattern is evaluated in the o= rder they appear in paths object and then first match applies.... up to you= . Done. > *** section 4.1.5: > OLD: > " > A PathMetadata object contains the CDNI Metadata properties for > content served with the associated URI path (defined in a PathMatch > object). > " > NEW: > " > A PathMetadata object contains the CDNI Metadata properties for > content served with the associated URI path (defined in a PathMatch > object) and possibly children PathMatch objects . > " Done. > *** section 4.1.5: > OLD: > " > Note that if CDNI metadata is used as an input to CDNI > request routing and DNS-based redirection is employed, then any > metadata at the PathMetadata level or below will be inaccessible at > request routing time. > " > NEW: > " > Note that if DNS-based redirection is employed, then any > metadata at the PathMetadata level or below will be inaccessible at > request routing time because only the content request hostname is avail= able at request routing time. > " Done. > *** section 4.1.6: > "The three literals \ , * and ? should be > escaped as \\, \* and \?. All other characters are treated as > literals." > Why do you need to escape "\"? Addressed already, no change required. > *** section 4.1.7: > " > Property: type > Description: CDNI Metadata property object type. > Type: String > Mandatory-to-Specify: Yes. >=20 > Property: value > Description: CDNI Metadata property object. > Type: matches the type property above " > To me it would be easier to follow if you renamed the properties from "ty= pe" and "value" to something like "generic-metadata-type" and "generic-meta= data-value".=20 > Obviously, you'd need to reflect these changes in other places. Design, will address in a follow-up e-mail. > *** section 4.1.7: > "Type: matches the type property above" > This is an exemple of things that are hard to parse currently. With the p= roposed change above this could read: > "Type: matches the generic-metadata-type of the property above" Depends how we address previous comment, will address in a follow-up e-mail= . > *** section 4.2: > OLD: > " > The property objects defined below are intended to be used in the > GenericMetadata object value field as defined in Section 4.1.7.=20 > " > NEW: > " > The property objects defined below are intended to be used in the > GenericMetadata object generic-metadata-value propery as defined in Sec= tion 4.1.7 and their type used in the generic-metadata-type property as def= ined in section 4.1.7.=20 > " > Let me kow if this is not correct. Depends how we address previous comment, will address in a follow-up e-mail= . > *** section 4.2: > " > All of the objects defined below are considered both mandatory to enforce > and safe to redistribute. > " > is it allowed to distribute them with no-MtE or no-StR? what woudl happen= then? > Would it be appropriate to state that all the objects MUST be distributed= with MtE and StR? can you add a statement about behavior or receipt if rec= eived otherwise? Design, will address in a follow-up e-mail. > *** section 4..2.1: > " > Description: Sources from which the dCDN can acquire content, > listed in priority order." > you may want to use "preference" instead of "priority" (which is an overl= oaded term) and explain what it means i.e. the dCDN is expected to always u= se the first one , unless it does not work? or is dCDN allowed to load bala= nce across multiple sources? should there be a mechanism to control whether= it is single source + backup or multple sources?=20 Design, will address in a follow-up e-mail. > *** section 4.2.1.1: > Is it really useful to allow multiple endpoints within a source, given it= is possible to include multiple sources? > If you keep multiple endpoints within a source, can you also clarify=20 > if there is any expected behavior from dCDN across the multiple=20 > endpoints (single or ) Design, will address in a follow-up e-mail. > *** section 4.2.2: > OLD: > " > Description: Access control list which applies restrictions to > delivery based on client location. > " > NEW: > " > Description: Access control list which allows or blocks > delivery based on client location. > " Done. > ***section 4.2.2.1: > I assume that the rules are discussed somewhere in the document (that I h= ave not got to yet) on usage of the LocationACLMetadata. > For example: > * if I only include one single LocationRule object that allows Footprint= 1, does it mean that a delievery from outside Footprint 1 is allowed or den= ied? > * if I have overlapping footprints, which applies? first one? > If these rules are not made explicit yet, please add them. Design, will address in a follow-up e-mail. > *** section 4.2.3: > OLD: > " > Description: Access control list which applies restrictions to > delivery based on request time. > " > NEW: > " > Description: Access control list which allows or blocks=20 > delivery based on request time. > " Done. > *** section 4.2.3: > OLD: > " > Description: Access control list which applies restrictions to > delivery based on delivery protocol. > " > NEW: > " > Description: Access control list which allows or blocks > delivery based on delivery protocol. > " Done. > *** section 6.2:=20 > "Where a downstream CDN is interconnected with multiple upstream CDNs, > the downstream CDN must decide which upstream CDN's CDNI metadata > should be used to handle a particular User Agent request. > " > s/must decide/needs to determine/ Done. > *** Section 6.4.2.1: > OLD: > " 6.4.2.1. JSON Example" > NEW: > " 6.4.2.1. Encoded CDNI Metadata Example" Done. > *** section 7.1.1.1" > " > DVD Region code (i.e., integer in the range 0-6).=20 > " > add a reference that specifies these values. Design as looking at DVD specs we may need to change the representation, wi= ll address in a follow-up e-mail. Ben _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From nobody Thu Jun 26 01:43:24 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 623C41B2CC4 for ; Thu, 26 Jun 2014 01:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzOdpW2ioZaR for ; Thu, 26 Jun 2014 01:43:18 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F1DE1B2CED for ; Thu, 26 Jun 2014 01:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13046; q=dns/txt; s=iport; t=1403772198; x=1404981798; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=tfzwNda8Q/ivtY9gLy3VTo87zGJwrKvW3ACMYgJOB+E=; b=JOY4Zv+24BIotv18VAhrX54wr0g+rd6146dbuk8hER1GlCWuSjlemOke o3oLS8NB/zipciSN3BxNazEVvld6N2YTQR6qQHPJWSN+Pb/gVFLb1NXmp pEUJZDH6ITkBL2FugX03RmX7O2Jr7AaqR96uyPshQOhdzFqIOot9YWW8N g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAO7cq1OtJV2d/2dsb2JhbABagw1SWrxCh0ABgQkWdYQDAQEBAwEBAQELVwkLBQcEAgEIEQQBAQEYDwcnCxQJCAIECgQFiDoIDcMyEwSOFTgzBwYSgxWBFgWWQ4QVk2+DQmyBRA X-IronPort-AV: E=Sophos;i="5.01,551,1400025600"; d="scan'208";a="56073950" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 26 Jun 2014 08:43:16 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s5Q8hGAP020593 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 08:43:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 03:43:15 -0500 From: "Francois Le Faucheur (flefauch)" To: Ma Kevin Thread-Topic: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] Thread-Index: AQHPYsTR4Y8R725o90md4tCkXk59p5uBVtqAgAJsxgA= Date: Thu, 26 Jun 2014 08:43:15 +0000 Message-ID: <41E29EF5-971B-49C1-98AA-D96A64D4F1F9@cisco.com> References: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3F095E0915E69B4C9B4038FEDC81F416@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/pISCxN-9GcMNzYVow57ze_4g8hQ Cc: "cdni@ietf.org" , "draft-ietf-cdni-metadata@tools.ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 08:43:21 -0000 Hello Kevin, On 25 Jun 2014, at 03:01, Kevin Ma J wrote: > Hi Francois, >=20 > We were looking for clarification wrt to the following comment: >=20 >> Can you make sure the applicability of the metadata defined in this docu= ments is discussed in terms of what types of deliveries are supported (HTTP= /1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the text I proposed on = the list for cdni-logging. >=20 > I think we intentionally made the metadata delivery protocol agnostic. > - LocationACL, TimeWindowACL, and Grouping are all protocol agnostic. > - Source and ProtocolACL specify lists of protocols, but are not themsel= ves protocol specific. > - Cache only deals with query strings, which is scheme agnostic and work= s with any URI. > - Auth is also protocol agnostic. Though credential auth can be used wi= th HTTP, > the specification of username and password is not itself protocol spec= ific. > The CDNI logging draft specifies an HTTP specific logging format, and th= us requires variant > considerations for 1.x vs 2.x vs w/ TLS; I don't see metadata requiring = this distinction. > I'm not sure that adding text to discuss HTTP variants is necessary. If= you agree, then > we will disregard this portion of the comment? If you still think we ne= ed some text, > would it be sufficient to simply state that all the defined metadata is = protocol agnostic? I feel that the reader should be told very explicitely whether he can use t= his version of cdni-metadata (i) for content delivery via HTTP v1.0, HTTPv1= .1, HTTPv2 x with/without TLS and (ii) for content acquisition via HTTPv1.1= , HTTPv2 x with/without TLS. For example, right now, if I look at the =93Protocol Sub-registry=94 (secti= on 7.1.1.2 in cdni-metadata-06), I see: =93 | HTTP| Hypertext Transfer Protocol -- HTTP/1.1 | = | | HTTPS | HTTP Over TLS | RFC2818 =20 =93 I think this means that: * with current version of spec, HTTPv1.1 can be used for acquisition * with current version of spec, HTTPv2 can not be used for acquisition * if/when the IANA =93CDNI Metadata Protocol Sub-Registry" is extended by = some other document to register an entry for =93HTTPv2=94 , then it will be= possible to use HTTPv2 for acquisition * with current version of spec, HTTPv1.0 cannot be used for acquisition * I am not clear if HTTPS means HTTPv1.1 over TLS, HTTPv2 over TLS or both= . (I think this needs some text clarification eg rename the entry as =93HTT= Pv1.1 over TLS" ). * with current version of spec, it is not possible for a dCDN to advertise= in FCI that HTTPv2 is supported by dCDN (ie ProtocolACL) * with current version of spec, it is not possible for a dCDN to advertise= in FCI that HTTPv0 is supported by dCDN (ie ProtocolACL) * if/when the IANA =93CDNI Metadata Protocol Sub-Registry" is extended by = some other document to register an entry for =93HTTPv2=94 , then it will be= possible for a dCDN to advertise in FCI that HTTPv2 is supported by dCDN (= ie ProtocolACL). My recommendation is that the document includes text to: * state that current spec supports HTTPv1.1 and HTTPv1.1 over TLS delivery= and acquisition * state that all it would take to support anorther version of HTTP (eg HTT= Pv2 and HTTPv2 over TLS) is be to allocate the corresponding entries in the= =93CDNI Metadata Protocol Sub-Registry=94 (so these protocols can be adver= tised by dCDN in FCI, and can be identified as acquisition protocols in CDN= I metadata). All the other functionality supported by the CDNI metadata spe= c (eg Time Window, location ACL,..) would just work for these additional pr= otocols because these functions and associated elements are indeed protocol= agnostic.=20 Makes sense? Francois > thanx! >=20 > -- Kevin J. Ma >=20 > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins > Sent: Monday, April 28, 2014 5:32 AM > To: Francois Le Faucher > Cc: draft-ietf-cdni-metadata@tools.ietf.org; cdni@ietf.org > Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [B= atch 4] >=20 > Francois, >=20 > I have incorporated the editorial comments from below. Some of your comme= nts require some discussions with my co-authors so I've marked them as "Des= ign" below and we'll follow up later with proposed resolutions for them. >=20 > Ben >=20 > On 12 Mar 2014, at 13:51, Francois Le Faucheur (flefauch) wrote: >=20 >> (Note: I stopped detailed review at 4.2.4 even if I have a few comments = beyond that). >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> General comments: >>=20 >> *** somewhere (probably towards the beginning of the document): >> Can you make sure the applicability of the metadata defined in this docu= ments is discussed in terms of what types of deliveries are supported (HTTP= /1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the text I proposed on = the list for cdni-logging. >> Also how about adding a summary of features supported by specified=20 >> metadata (eg geolocation, time window, multipe acquisitions, ...) >=20 > Design, will address in a follow-up e-mail. >=20 >> *** use of MUST: >> I think this needs a clean-up: >> o there are a number of appropriate MUST statements on detailed things, = but I can't see one statement clarifying exhaustively which object is manda= tory to implement as an uCDN and as a dCDN. Can you make sure this is cover= ed , if not already covered? >> o there are a few "must" that we may want to replace with alternate=20 >> phrases ( "needs to", "has to", ...) o there are MUSTs in the IANA secti= on (eg 7.1). Based on the conversation we had in teh contaxt of cdni-loggin= g, I assume these will be edited out. >=20 > Design, will address in a follow-up e-mail. >=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Detailed comments: >>=20 >>=20 >> *** section 4.1.3: >> "First match applies." >> Might be worth turning into a full sentence explaining the context of th= e "match" ie when metadata is walked through to find the relevant one for a= piece of content to be processed , every path-pattern is evaluated in the = order they appear in paths object and then first match applies.... up to yo= u. >=20 > Done. >=20 >> *** section 4.1.5: >> OLD: >> " >> A PathMetadata object contains the CDNI Metadata properties for >> content served with the associated URI path (defined in a PathMatch >> object). >> " >> NEW: >> " >> A PathMetadata object contains the CDNI Metadata properties for >> content served with the associated URI path (defined in a PathMatch >> object) and possibly children PathMatch objects . >> " >=20 > Done. >=20 >> *** section 4.1.5: >> OLD: >> " >> Note that if CDNI metadata is used as an input to CDNI >> request routing and DNS-based redirection is employed, then any >> metadata at the PathMetadata level or below will be inaccessible at >> request routing time. >> " >> NEW: >> " >> Note that if DNS-based redirection is employed, then any >> metadata at the PathMetadata level or below will be inaccessible at >> request routing time because only the content request hostname is avail= able at request routing time. >> " >=20 > Done. >=20 >> *** section 4.1.6: >> "The three literals \ , * and ? should be >> escaped as \\, \* and \?. All other characters are treated as >> literals." >> Why do you need to escape "\"? >=20 > Addressed already, no change required. >=20 >> *** section 4.1.7: >> " >> Property: type >> Description: CDNI Metadata property object type. >> Type: String >> Mandatory-to-Specify: Yes. >>=20 >> Property: value >> Description: CDNI Metadata property object. >> Type: matches the type property above " >> To me it would be easier to follow if you renamed the properties from "t= ype" and "value" to something like "generic-metadata-type" and "generic-met= adata-value".=20 >> Obviously, you'd need to reflect these changes in other places. >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4.1.7: >> "Type: matches the type property above" >> This is an exemple of things that are hard to parse currently. With the = proposed change above this could read: >> "Type: matches the generic-metadata-type of the property above" >=20 > Depends how we address previous comment, will address in a follow-up e-ma= il. >=20 >> *** section 4.2: >> OLD: >> " >> The property objects defined below are intended to be used in the >> GenericMetadata object value field as defined in Section 4.1.7.=20 >> " >> NEW: >> " >> The property objects defined below are intended to be used in the >> GenericMetadata object generic-metadata-value propery as defined in Sec= tion 4.1.7 and their type used in the generic-metadata-type property as def= ined in section 4.1.7.=20 >> " >> Let me kow if this is not correct. >=20 > Depends how we address previous comment, will address in a follow-up e-ma= il. >=20 >> *** section 4.2: >> " >> All of the objects defined below are considered both mandatory to enforc= e >> and safe to redistribute. >> " >> is it allowed to distribute them with no-MtE or no-StR? what woudl happe= n then? >> Would it be appropriate to state that all the objects MUST be distribute= d with MtE and StR? can you add a statement about behavior or receipt if re= ceived otherwise? >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4..2.1: >> " >> Description: Sources from which the dCDN can acquire content, >> listed in priority order." >> you may want to use "preference" instead of "priority" (which is an over= loaded term) and explain what it means i.e. the dCDN is expected to always = use the first one , unless it does not work? or is dCDN allowed to load bal= ance across multiple sources? should there be a mechanism to control whethe= r it is single source + backup or multple sources?=20 >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4.2.1.1: >> Is it really useful to allow multiple endpoints within a source, given i= t is possible to include multiple sources? >> If you keep multiple endpoints within a source, can you also clarify=20 >> if there is any expected behavior from dCDN across the multiple=20 >> endpoints (single or ) >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4.2.2: >> OLD: >> " >> Description: Access control list which applies restrictions to >> delivery based on client location. >> " >> NEW: >> " >> Description: Access control list which allows or blocks >> delivery based on client location. >> " >=20 > Done. >=20 >> ***section 4.2.2.1: >> I assume that the rules are discussed somewhere in the document (that I = have not got to yet) on usage of the LocationACLMetadata. >> For example: >> * if I only include one single LocationRule object that allows Footprin= t1, does it mean that a delievery from outside Footprint 1 is allowed or de= nied? >> * if I have overlapping footprints, which applies? first one? >> If these rules are not made explicit yet, please add them. >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4.2.3: >> OLD: >> " >> Description: Access control list which applies restrictions to >> delivery based on request time. >> " >> NEW: >> " >> Description: Access control list which allows or blocks=20 >> delivery based on request time. >> " >=20 > Done. >=20 >> *** section 4.2.3: >> OLD: >> " >> Description: Access control list which applies restrictions to >> delivery based on delivery protocol. >> " >> NEW: >> " >> Description: Access control list which allows or blocks >> delivery based on delivery protocol. >> " >=20 > Done. >=20 >> *** section 6.2:=20 >> "Where a downstream CDN is interconnected with multiple upstream CDNs, >> the downstream CDN must decide which upstream CDN's CDNI metadata >> should be used to handle a particular User Agent request. >> " >> s/must decide/needs to determine/ >=20 > Done. >=20 >> *** Section 6.4.2.1: >> OLD: >> " 6.4.2.1. JSON Example" >> NEW: >> " 6.4.2.1. Encoded CDNI Metadata Example" >=20 > Done. >=20 >> *** section 7.1.1.1" >> " >> DVD Region code (i.e., integer in the range 0-6).=20 >> " >> add a reference that specifies these values. >=20 > Design as looking at DVD specs we may need to change the representation, = will address in a follow-up e-mail. >=20 > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Thu Jun 26 01:48:26 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686CC1B2F3D for ; Thu, 26 Jun 2014 01:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1ICTQsIw_KC for ; Thu, 26 Jun 2014 01:48:24 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101661B2CF5 for ; Thu, 26 Jun 2014 01:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=351; q=dns/txt; s=iport; t=1403772504; x=1404982104; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=p+D8s/EU32CyFLeE0uC/Ssydm9AuUEzPoyRROhMAfBU=; b=FIUS83BI4E+r2o3QeRA+Nx56kH1DzqxwxCmmnYaxRzewOGirOec11eqJ ylix6vBjmZEj6aGflbC3dIv35wKnwGWIG4B3vXKhtl8lPIQ/12JOcTxqV 9fShxyK7lsT9zpr2wk/gEXXzQQUOybwe536PsuBIZs0JV2uIfiom5PI6m A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAGLdq1OtJV2b/2dsb2JhbABagw2BLMQCgQoWdYQKHR0/EgE+QicEDohHwysXjwCDNIEWBZpYk2+DQoIw X-IronPort-AV: E=Sophos;i="5.01,551,1400025600"; d="scan'208";a="56063643" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 26 Jun 2014 08:48:23 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s5Q8mNb4001813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 26 Jun 2014 08:48:23 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 26 Jun 2014 03:48:23 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Call for agenda items at IETF90 CDNI meeting Thread-Index: AQHPkRtiDx49wTQdhES7JiUVFtdNcA== Date: Thu, 26 Jun 2014 08:48:22 +0000 Message-ID: <0285DF59-7135-499A-A798-9508BB5D1D38@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] Content-Type: text/plain; charset="us-ascii" Content-ID: <593DF9AEEC36A146B09661E8621C2620@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/oiweu3cI9kt8elWZyrxNhZatXRM Subject: [CDNi] Call for agenda items at IETF90 CDNI meeting X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 08:48:25 -0000 Hi all, The CDNI WG will be meeting at the Toronto IETF in a two hour slot (tentati= vely scheduled on Thursday Jul 24, at 15:20). We are in the process of setting the agenda, so please send Daryl and I you= r requests for slots detailing: * Name of the draft * Name of presenter * requested slot suration Thanks Francois & Daryl= From nobody Thu Jun 26 07:16:33 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7F11B2D90 for ; Thu, 26 Jun 2014 07:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04BghvYK7F3A for ; Thu, 26 Jun 2014 07:16:24 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7ADD21B306C for ; Thu, 26 Jun 2014 06:48:15 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-8e-53abd30a7d13 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 4E.26.05330.A03DBA35; Thu, 26 Jun 2014 10:00:10 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Thu, 26 Jun 2014 09:48:13 -0400 From: Kevin Ma J To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] Thread-Index: AQHPYsTR4Y8R725o90md4tCkXk59p5uBVtqAgAJsxgCAAAD1kA== Date: Thu, 26 Jun 2014 13:48:12 +0000 Message-ID: References: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> <41E29EF5-971B-49C1-98AA-D96A64D4F1F9@cisco.com> In-Reply-To: <41E29EF5-971B-49C1-98AA-D96A64D4F1F9@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyuXRPrC7X5dXBBlsuqVgsODeBzeLp7D+s FrOuHWez+LfgNJMDi8eU3xtZPZYs+cnk8fP6JEaPL5c/swWwRHHZpKTmZJalFunbJXBl7GtK KvifWXHr2zPGBsY7wV2MnBwSAiYSi3/NYIWwxSQu3FvP1sXIxSEkcJRR4tHUT2AJIYHljBJ3 DsWC2GwCWhKPv/5lArFFBKwkVj9sZgFpYBZYySgxffYt9i5GDg5hgSCJGd/KIGqCJa5MPsAG EhYRcJLY818AxGQRUJV4P9EOxOQV8Jb4/bUUYtE7RomJj9hBbE4BW4mm7knMIDYj0GXfT60B W8osIC5x68l8JoiLBSSW7DnPDGGLSrx8/A/qEyWJOa+vMUPU60gs2P2JDcLWlli28DVYnFdA UOLkzCcsExjFZiEZOwtJyywkLbOQtCxgZFnFyFFanFqWm25ksIkRGEXHJNh0dzDueWl5iFGA g1GJh3fB3FXBQqyJZcWVuYcYpTlYlMR5Z9XOCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA aCPXfONK7XPl+wc3813jvxCXZtftYshjcKPvS2vghdMTf086uUO3uL/6cdzpGRlls5bqi7/O b9zxdrnTlWs/r4vP4frKnLQhJ2M+t+33/Ws3RV3SNJoyn6/4478b72eq+sncZrghrr1y0q+G rhl7uEJilF5krTxwmPPWcXfRbYv2/89/bmbm063EUpyRaKjFXFScCABC20x9gwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/_B2e9hUKaVAsqF5Kt38SgjTtDjg Cc: "cdni@ietf.org" , "draft-ietf-cdni-metadata@tools.ietf.org" Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4] X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 14:16:30 -0000 Hi Francois, Understood. Thanks for the clarification. I think we should be able to add text to address this. thanx! -- Kevin J. Ma -----Original Message----- From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com]=20 Sent: Thursday, June 26, 2014 4:43 AM To: Kevin Ma J Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; draft-ietf-cdni-met= adata@tools.ietf.org; cdni@ietf.org Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Bat= ch 4] Hello Kevin, On 25 Jun 2014, at 03:01, Kevin Ma J wrote: > Hi Francois, >=20 > We were looking for clarification wrt to the following comment: >=20 >> Can you make sure the applicability of the metadata defined in this docu= ments is discussed in terms of what types of deliveries are supported (HTTP= /1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the text I proposed on = the list for cdni-logging. >=20 > I think we intentionally made the metadata delivery protocol agnostic. > - LocationACL, TimeWindowACL, and Grouping are all protocol agnostic. > - Source and ProtocolACL specify lists of protocols, but are not themsel= ves protocol specific. > - Cache only deals with query strings, which is scheme agnostic and work= s with any URI. > - Auth is also protocol agnostic. Though credential auth can be used wi= th HTTP, > the specification of username and password is not itself protocol spec= ific. > The CDNI logging draft specifies an HTTP specific logging format, and=20 > thus requires variant considerations for 1.x vs 2.x vs w/ TLS; I don't s= ee metadata requiring this distinction. > I'm not sure that adding text to discuss HTTP variants is necessary. =20 > If you agree, then we will disregard this portion of the comment? If=20 > you still think we need some text, would it be sufficient to simply stat= e that all the defined metadata is protocol agnostic? I feel that the reader should be told very explicitely whether he can use t= his version of cdni-metadata (i) for content delivery via HTTP v1.0, HTTPv1= .1, HTTPv2 x with/without TLS and (ii) for content acquisition via HTTPv1.1= , HTTPv2 x with/without TLS. For example, right now, if I look at the "Protocol Sub-registry" (section 7= .1.1.2 in cdni-metadata-06), I see: " | HTTP| Hypertext Transfer Protocol -- HTTP/1.1 | = | | HTTPS | HTTP Over TLS | RFC2818 =20 " I think this means that: * with current version of spec, HTTPv1.1 can be used for acquisition * with current version of spec, HTTPv2 can not be used for acquisition * if/when the IANA "CDNI Metadata Protocol Sub-Registry" is extended by so= me other document to register an entry for "HTTPv2" , then it will be possi= ble to use HTTPv2 for acquisition * with current version of spec, HTTPv1.0 cannot be used for acquisition * I am not clear if HTTPS means HTTPv1.1 over TLS, HTTPv2 over TLS or both= . (I think this needs some text clarification eg rename the entry as "HTTPv= 1.1 over TLS" ). * with current version of spec, it is not possible for a dCDN to advertise= in FCI that HTTPv2 is supported by dCDN (ie ProtocolACL) * with current version of spec, it is not possible for a dCDN to advertise= in FCI that HTTPv0 is supported by dCDN (ie ProtocolACL) * if/when the IANA "CDNI Metadata Protocol Sub-Registry" is extended by so= me other document to register an entry for "HTTPv2" , then it will be possi= ble for a dCDN to advertise in FCI that HTTPv2 is supported by dCDN (ie Pro= tocolACL). My recommendation is that the document includes text to: * state that current spec supports HTTPv1.1 and HTTPv1.1 over TLS delivery= and acquisition * state that all it would take to support anorther version of HTTP (eg HTT= Pv2 and HTTPv2 over TLS) is be to allocate the corresponding entries in the= "CDNI Metadata Protocol Sub-Registry" (so these protocols can be advertise= d by dCDN in FCI, and can be identified as acquisition protocols in CDNI me= tadata). All the other functionality supported by the CDNI metadata spec (e= g Time Window, location ACL,..) would just work for these additional protoc= ols because these functions and associated elements are indeed protocol agn= ostic.=20 Makes sense? Francois > thanx! >=20 > -- Kevin J. Ma >=20 > -----Original Message----- > From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Ben=20 > Niven-Jenkins > Sent: Monday, April 28, 2014 5:32 AM > To: Francois Le Faucher > Cc: draft-ietf-cdni-metadata@tools.ietf.org; cdni@ietf.org > Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt=20 > [Batch 4] >=20 > Francois, >=20 > I have incorporated the editorial comments from below. Some of your comme= nts require some discussions with my co-authors so I've marked them as "Des= ign" below and we'll follow up later with proposed resolutions for them. >=20 > Ben >=20 > On 12 Mar 2014, at 13:51, Francois Le Faucheur (flefauch) wrote: >=20 >> (Note: I stopped detailed review at 4.2.4 even if I have a few comments = beyond that). >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> General comments: >>=20 >> *** somewhere (probably towards the beginning of the document): >> Can you make sure the applicability of the metadata defined in this docu= ments is discussed in terms of what types of deliveries are supported (HTTP= /1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the text I proposed on = the list for cdni-logging. >> Also how about adding a summary of features supported by specified=20 >> metadata (eg geolocation, time window, multipe acquisitions, ...) >=20 > Design, will address in a follow-up e-mail. >=20 >> *** use of MUST: >> I think this needs a clean-up: >> o there are a number of appropriate MUST statements on detailed things, = but I can't see one statement clarifying exhaustively which object is manda= tory to implement as an uCDN and as a dCDN. Can you make sure this is cover= ed , if not already covered? >> o there are a few "must" that we may want to replace with alternate=20 >> phrases ( "needs to", "has to", ...) o there are MUSTs in the IANA secti= on (eg 7.1). Based on the conversation we had in teh contaxt of cdni-loggin= g, I assume these will be edited out. >=20 > Design, will address in a follow-up e-mail. >=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> Detailed comments: >>=20 >>=20 >> *** section 4.1.3: >> "First match applies." >> Might be worth turning into a full sentence explaining the context of th= e "match" ie when metadata is walked through to find the relevant one for a= piece of content to be processed , every path-pattern is evaluated in the = order they appear in paths object and then first match applies.... up to yo= u. >=20 > Done. >=20 >> *** section 4.1.5: >> OLD: >> " >> A PathMetadata object contains the CDNI Metadata properties for =20 >> content served with the associated URI path (defined in a PathMatch =20 >> object). >> " >> NEW: >> " >> A PathMetadata object contains the CDNI Metadata properties for =20 >> content served with the associated URI path (defined in a PathMatch >> object) and possibly children PathMatch objects . >> " >=20 > Done. >=20 >> *** section 4.1.5: >> OLD: >> " >> Note that if CDNI metadata is used as an input to CDNI request=20 >> routing and DNS-based redirection is employed, then any metadata at=20 >> the PathMetadata level or below will be inaccessible at request=20 >> routing time. >> " >> NEW: >> " >> Note that if DNS-based redirection is employed, then any metadata at=20 >> the PathMetadata level or below will be inaccessible at request=20 >> routing time because only the content request hostname is available at r= equest routing time. >> " >=20 > Done. >=20 >> *** section 4.1.6: >> "The three literals \ , * and ? should be >> escaped as \\, \* and \?. All other characters are treated as >> literals." >> Why do you need to escape "\"? >=20 > Addressed already, no change required. >=20 >> *** section 4.1.7: >> " >> Property: type >> Description: CDNI Metadata property object type. >> Type: String >> Mandatory-to-Specify: Yes. >>=20 >> Property: value >> Description: CDNI Metadata property object. >> Type: matches the type property above " >> To me it would be easier to follow if you renamed the properties from "t= ype" and "value" to something like "generic-metadata-type" and "generic-met= adata-value".=20 >> Obviously, you'd need to reflect these changes in other places. >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4.1.7: >> "Type: matches the type property above" >> This is an exemple of things that are hard to parse currently. With the = proposed change above this could read: >> "Type: matches the generic-metadata-type of the property above" >=20 > Depends how we address previous comment, will address in a follow-up e-ma= il. >=20 >> *** section 4.2: >> OLD: >> " >> The property objects defined below are intended to be used in the =20 >> GenericMetadata object value field as defined in Section 4.1.7. >> " >> NEW: >> " >> The property objects defined below are intended to be used in the =20 >> GenericMetadata object generic-metadata-value propery as defined in Sect= ion 4.1.7 and their type used in the generic-metadata-type property as defi= ned in section 4.1.7. >> " >> Let me kow if this is not correct. >=20 > Depends how we address previous comment, will address in a follow-up e-ma= il. >=20 >> *** section 4.2: >> " >> All of the objects defined below are considered both mandatory to=20 >> enforce and safe to redistribute. >> " >> is it allowed to distribute them with no-MtE or no-StR? what woudl happe= n then? >> Would it be appropriate to state that all the objects MUST be distribute= d with MtE and StR? can you add a statement about behavior or receipt if re= ceived otherwise? >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4..2.1: >> " >> Description: Sources from which the dCDN can acquire content, >> listed in priority order." >> you may want to use "preference" instead of "priority" (which is an over= loaded term) and explain what it means i.e. the dCDN is expected to always = use the first one , unless it does not work? or is dCDN allowed to load bal= ance across multiple sources? should there be a mechanism to control whethe= r it is single source + backup or multple sources?=20 >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4.2.1.1: >> Is it really useful to allow multiple endpoints within a source, given i= t is possible to include multiple sources? >> If you keep multiple endpoints within a source, can you also clarify=20 >> if there is any expected behavior from dCDN across the multiple=20 >> endpoints (single or ) >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4.2.2: >> OLD: >> " >> Description: Access control list which applies restrictions to >> delivery based on client location. >> " >> NEW: >> " >> Description: Access control list which allows or blocks >> delivery based on client location. >> " >=20 > Done. >=20 >> ***section 4.2.2.1: >> I assume that the rules are discussed somewhere in the document (that I = have not got to yet) on usage of the LocationACLMetadata. >> For example: >> * if I only include one single LocationRule object that allows Footprin= t1, does it mean that a delievery from outside Footprint 1 is allowed or de= nied? >> * if I have overlapping footprints, which applies? first one? >> If these rules are not made explicit yet, please add them. >=20 > Design, will address in a follow-up e-mail. >=20 >> *** section 4.2.3: >> OLD: >> " >> Description: Access control list which applies restrictions to >> delivery based on request time. >> " >> NEW: >> " >> Description: Access control list which allows or blocks=20 >> delivery based on request time. >> " >=20 > Done. >=20 >> *** section 4.2.3: >> OLD: >> " >> Description: Access control list which applies restrictions to >> delivery based on delivery protocol. >> " >> NEW: >> " >> Description: Access control list which allows or blocks >> delivery based on delivery protocol. >> " >=20 > Done. >=20 >> *** section 6.2:=20 >> "Where a downstream CDN is interconnected with multiple upstream=20 >> CDNs, the downstream CDN must decide which upstream CDN's CDNI=20 >> metadata should be used to handle a particular User Agent request. >> " >> s/must decide/needs to determine/ >=20 > Done. >=20 >> *** Section 6.4.2.1: >> OLD: >> " 6.4.2.1. JSON Example" >> NEW: >> " 6.4.2.1. Encoded CDNI Metadata Example" >=20 > Done. >=20 >> *** section 7.1.1.1" >> " >> DVD Region code (i.e., integer in the range 0-6).=20 >> " >> add a reference that specifies these values. >=20 > Design as looking at DVD specs we may need to change the representation, = will address in a follow-up e-mail. >=20 > Ben >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Thu Jun 26 09:30:40 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC37E1B29AE for ; Thu, 26 Jun 2014 09:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84HlYRMgeCDA for ; Thu, 26 Jun 2014 09:30:33 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 5132F1B2F42 for ; Thu, 26 Jun 2014 09:13:52 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=[172.18.0.152]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1X0CJ4-0001Fb-3F; Thu, 26 Jun 2014 17:13:51 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Ben Niven-Jenkins In-Reply-To: <41E29EF5-971B-49C1-98AA-D96A64D4F1F9@cisco.com> Date: Thu, 26 Jun 2014 17:13:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FBAF9F8-8389-431B-95BC-9758273FBDF9@cisco.com> <41E29EF5-971B-49C1-98AA-D96A64D4F1F9@cisco.com> To: Francois Le Faucher X-Mailer: Apple Mail (2.1878.2) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/TSDZOmh8EWYK7jlAn1xQpUeFP1c Cc: "draft-ietf-cdni-metadata@tools.ietf.org" , "cdni@ietf.org" Subject: [CDNi] Delivery/Acquisition protocols & CDNI Metadata X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 16:30:38 -0000 Francois, Colleagues, On 26 Jun 2014, at 09:43, Francois Le Faucheur (flefauch) = wrote: > Hello Kevin, >=20 > On 25 Jun 2014, at 03:01, Kevin Ma J wrote: >=20 >> Hi Francois, >>=20 >> We were looking for clarification wrt to the following comment: >>=20 >>> Can you make sure the applicability of the metadata defined in this = documents is discussed in terms of what types of deliveries are = supported (HTTP/1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the = text I proposed on the list for cdni-logging. >>=20 >> I think we intentionally made the metadata delivery protocol = agnostic. >> - LocationACL, TimeWindowACL, and Grouping are all protocol agnostic. >> - Source and ProtocolACL specify lists of protocols, but are not = themselves protocol specific. >> - Cache only deals with query strings, which is scheme agnostic and = works with any URI. >> - Auth is also protocol agnostic. Though credential auth can be used = with HTTP, >> the specification of username and password is not itself protocol = specific. >> The CDNI logging draft specifies an HTTP specific logging format, and = thus requires variant >> considerations for 1.x vs 2.x vs w/ TLS; I don't see metadata = requiring this distinction. >> I'm not sure that adding text to discuss HTTP variants is necessary. = If you agree, then >> we will disregard this portion of the comment? If you still think we = need some text, >> would it be sufficient to simply state that all the defined metadata = is protocol agnostic? >=20 > I feel that the reader should be told very explicitely whether he can = use this version of cdni-metadata (i) for content delivery via HTTP = v1.0, HTTPv1.1, HTTPv2 x with/without TLS and (ii) for content = acquisition via HTTPv1.1, HTTPv2 x with/without TLS. Which raises the question of =93what do we really mean by content = delivery via HTTP/1.1?=94 (or HTTP/1.0 etc). So far in the WG we have = talked about =93HTTP=94 or =93HTTP/1.1=94 in a fairly loose manner as = though, for example, HTTP/1.1 is a single thing that is well defined. In = reality it consists of a number of optional capabilities/etc. We don=92t = have anything in the draft that allows one to assume any more than =93if = a CDN says it supports HTTP it is able to deliver over HTTP using some = (unknown) subset of HTTP features=94. It would be possible to be more = granular by registering additional entries in the protocol sub-registry = and defining what =93profile=94 of HTTP features they indicate support = for. What we have specified is mostly the minimum necessary to deliver = something, somehow over HTTP/1.1. It=92s a good foundation & framework = on which others can specify additional extensions on top of. > For example, right now, if I look at the =93Protocol Sub-registry=94 = (section 7.1.1.2 in cdni-metadata-06), I see: > =93 > | HTTP| Hypertext Transfer Protocol -- HTTP/1.1 | = | > | HTTPS | HTTP Over TLS | RFC2818 =20 > =93 > I think this means that: > * with current version of spec, HTTPv1.1 can be used for = acquisition > * with current version of spec, HTTPv2 can not be used for = acquisition > * if/when the IANA =93CDNI Metadata Protocol Sub-Registry" is = extended by some other document to register an entry for =93HTTPv2=94 , = then it will be possible to use HTTPv2 for acquisition > * with current version of spec, HTTPv1.0 cannot be used for = acquisition Apart from the protocol sub-registry lacking an entry for HTTP/1.0, if = we=92re happy with continuing with our loose definition of what = delivering over a protocol means, there is nothing in the current = metadata draft that prevents delivery or acquisition over HTTP/1.0. Acquisition is slightly different to delivery when it comes to CDNI = metadata support. Mainly because for some protocols, for example = HTTPS/1.1 over TLS, acquisition generally doesn=92t require additional = metadata objects, whereas in order to support delivery of that protocol = would require additional metadata objects. > * I am not clear if HTTPS means HTTPv1.1 over TLS, HTTPv2 over = TLS or both. (I think this needs some text clarification eg rename the = entry as =93HTTPv1.1 over TLS" ). We should clarify this, but I think HTTPS =3D=3D HTTPS/1.1, i.e. = https:// URIs retrieve over TLS. We may want to give what we call it some thought. Discussion of = opportunistic TLS encryption for http:// URIs has come up in httpbis in = the past so it=92s probably important to make a distinction between = HTTPS/1.1 (https:// URI over TLS) and HTTP/1.1 over TLS (http:// URI = over TLS). > * with current version of spec, it is not possible for a dCDN to = advertise in FCI that HTTPv2 is supported by dCDN (ie ProtocolACL) > * with current version of spec, it is not possible for a dCDN to = advertise in FCI that HTTPv0 is supported by dCDN (ie ProtocolACL) > * if/when the IANA =93CDNI Metadata Protocol Sub-Registry" is = extended by some other document to register an entry for =93HTTPv2=94 , = then it will be possible for a dCDN to advertise in FCI that HTTPv2 is = supported by dCDN (ie ProtocolACL). >=20 > My recommendation is that the document includes text to: > * state that current spec supports HTTPv1.1 and HTTPv1.1 over = TLS delivery and acquisition The current spec would allow support for HTTP/1.1 for delivery and = acquisition or HTTPS/1.1 for acquisition. Additional metadata objects would need to be specified to support = HTTPS/1.1 for content delivery, e.g. certificate & private key to use = and how to distribute those securely (which we=92ve side-stepped so far = by assuming they would be specified in an extension). > * state that all it would take to support anorther version of = HTTP (eg HTTPv2 and HTTPv2 over TLS) is be to allocate the corresponding = entries in the =93CDNI Metadata Protocol Sub-Registry=94 (so these = protocols can be advertised by dCDN in FCI, and can be identified as = acquisition protocols in CDNI metadata). To use them for acquisition, or to use HTTP/2 with http:// URIs, that is = all that is required. To use HTTPS/2 for content delivery would require = the same metadata extensions as for HTTPS/1.1. Ben > All the other functionality supported by the CDNI metadata spec (eg = Time Window, location ACL,..) would just work for these additional = protocols because these functions and associated elements are indeed = protocol agnostic.=20 >=20 > Makes sense? >=20 > Francois >=20 >=20 >> thanx! >>=20 >> -- Kevin J. Ma >>=20 >> -----Original Message----- >> From: CDNi [mailto:cdni-bounces@ietf.org] On Behalf Of Ben = Niven-Jenkins >> Sent: Monday, April 28, 2014 5:32 AM >> To: Francois Le Faucher >> Cc: draft-ietf-cdni-metadata@tools.ietf.org; cdni@ietf.org >> Subject: Re: [CDNi] WG Chair review of = draft-ietf-cdni-metadata-06.txt [Batch 4] >>=20 >> Francois, >>=20 >> I have incorporated the editorial comments from below. Some of your = comments require some discussions with my co-authors so I've marked them = as "Design" below and we'll follow up later with proposed resolutions = for them. >>=20 >> Ben >>=20 >> On 12 Mar 2014, at 13:51, Francois Le Faucheur (flefauch) = wrote: >>=20 >>> (Note: I stopped detailed review at 4.2.4 even if I have a few = comments beyond that). >>>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> General comments: >>>=20 >>> *** somewhere (probably towards the beginning of the document): >>> Can you make sure the applicability of the metadata defined in this = documents is discussed in terms of what types of deliveries are = supported (HTTP/1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the = text I proposed on the list for cdni-logging. >>> Also how about adding a summary of features supported by specified=20= >>> metadata (eg geolocation, time window, multipe acquisitions, ...) >>=20 >> Design, will address in a follow-up e-mail. >>=20 >>> *** use of MUST: >>> I think this needs a clean-up: >>> o there are a number of appropriate MUST statements on detailed = things, but I can't see one statement clarifying exhaustively which = object is mandatory to implement as an uCDN and as a dCDN. Can you make = sure this is covered , if not already covered? >>> o there are a few "must" that we may want to replace with alternate=20= >>> phrases ( "needs to", "has to", ...) o there are MUSTs in the IANA = section (eg 7.1). Based on the conversation we had in teh contaxt of = cdni-logging, I assume these will be edited out. >>=20 >> Design, will address in a follow-up e-mail. >>=20 >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Detailed comments: >>>=20 >>>=20 >>> *** section 4.1.3: >>> "First match applies." >>> Might be worth turning into a full sentence explaining the context = of the "match" ie when metadata is walked through to find the relevant = one for a piece of content to be processed , every path-pattern is = evaluated in the order they appear in paths object and then first match = applies.... up to you. >>=20 >> Done. >>=20 >>> *** section 4.1.5: >>> OLD: >>> " >>> A PathMetadata object contains the CDNI Metadata properties for >>> content served with the associated URI path (defined in a PathMatch >>> object). >>> " >>> NEW: >>> " >>> A PathMetadata object contains the CDNI Metadata properties for >>> content served with the associated URI path (defined in a PathMatch >>> object) and possibly children PathMatch objects . >>> " >>=20 >> Done. >>=20 >>> *** section 4.1.5: >>> OLD: >>> " >>> Note that if CDNI metadata is used as an input to CDNI >>> request routing and DNS-based redirection is employed, then any >>> metadata at the PathMetadata level or below will be inaccessible at >>> request routing time. >>> " >>> NEW: >>> " >>> Note that if DNS-based redirection is employed, then any >>> metadata at the PathMetadata level or below will be inaccessible at >>> request routing time because only the content request hostname is = available at request routing time. >>> " >>=20 >> Done. >>=20 >>> *** section 4.1.6: >>> "The three literals \ , * and ? should be >>> escaped as \\, \* and \?. All other characters are treated as >>> literals." >>> Why do you need to escape "\"? >>=20 >> Addressed already, no change required. >>=20 >>> *** section 4.1.7: >>> " >>> Property: type >>> Description: CDNI Metadata property object type. >>> Type: String >>> Mandatory-to-Specify: Yes. >>>=20 >>> Property: value >>> Description: CDNI Metadata property object. >>> Type: matches the type property above " >>> To me it would be easier to follow if you renamed the properties = from "type" and "value" to something like "generic-metadata-type" and = "generic-metadata-value".=20 >>> Obviously, you'd need to reflect these changes in other places. >>=20 >> Design, will address in a follow-up e-mail. >>=20 >>> *** section 4.1.7: >>> "Type: matches the type property above" >>> This is an exemple of things that are hard to parse currently. With = the proposed change above this could read: >>> "Type: matches the generic-metadata-type of the property above" >>=20 >> Depends how we address previous comment, will address in a follow-up = e-mail. >>=20 >>> *** section 4.2: >>> OLD: >>> " >>> The property objects defined below are intended to be used in the >>> GenericMetadata object value field as defined in Section 4.1.7.=20 >>> " >>> NEW: >>> " >>> The property objects defined below are intended to be used in the >>> GenericMetadata object generic-metadata-value propery as defined in = Section 4.1.7 and their type used in the generic-metadata-type property = as defined in section 4.1.7.=20 >>> " >>> Let me kow if this is not correct. >>=20 >> Depends how we address previous comment, will address in a follow-up = e-mail. >>=20 >>> *** section 4.2: >>> " >>> All of the objects defined below are considered both mandatory to = enforce >>> and safe to redistribute. >>> " >>> is it allowed to distribute them with no-MtE or no-StR? what woudl = happen then? >>> Would it be appropriate to state that all the objects MUST be = distributed with MtE and StR? can you add a statement about behavior or = receipt if received otherwise? >>=20 >> Design, will address in a follow-up e-mail. >>=20 >>> *** section 4..2.1: >>> " >>> Description: Sources from which the dCDN can acquire content, >>> listed in priority order." >>> you may want to use "preference" instead of "priority" (which is an = overloaded term) and explain what it means i.e. the dCDN is expected to = always use the first one , unless it does not work? or is dCDN allowed = to load balance across multiple sources? should there be a mechanism to = control whether it is single source + backup or multple sources?=20 >>=20 >> Design, will address in a follow-up e-mail. >>=20 >>> *** section 4.2.1.1: >>> Is it really useful to allow multiple endpoints within a source, = given it is possible to include multiple sources? >>> If you keep multiple endpoints within a source, can you also clarify=20= >>> if there is any expected behavior from dCDN across the multiple=20 >>> endpoints (single or ) >>=20 >> Design, will address in a follow-up e-mail. >>=20 >>> *** section 4.2.2: >>> OLD: >>> " >>> Description: Access control list which applies restrictions to >>> delivery based on client location. >>> " >>> NEW: >>> " >>> Description: Access control list which allows or blocks >>> delivery based on client location. >>> " >>=20 >> Done. >>=20 >>> ***section 4.2.2.1: >>> I assume that the rules are discussed somewhere in the document = (that I have not got to yet) on usage of the LocationACLMetadata. >>> For example: >>> * if I only include one single LocationRule object that allows = Footprint1, does it mean that a delievery from outside Footprint 1 is = allowed or denied? >>> * if I have overlapping footprints, which applies? first one? >>> If these rules are not made explicit yet, please add them. >>=20 >> Design, will address in a follow-up e-mail. >>=20 >>> *** section 4.2.3: >>> OLD: >>> " >>> Description: Access control list which applies restrictions to >>> delivery based on request time. >>> " >>> NEW: >>> " >>> Description: Access control list which allows or blocks=20 >>> delivery based on request time. >>> " >>=20 >> Done. >>=20 >>> *** section 4.2.3: >>> OLD: >>> " >>> Description: Access control list which applies restrictions to >>> delivery based on delivery protocol. >>> " >>> NEW: >>> " >>> Description: Access control list which allows or blocks >>> delivery based on delivery protocol. >>> " >>=20 >> Done. >>=20 >>> *** section 6.2:=20 >>> "Where a downstream CDN is interconnected with multiple upstream = CDNs, >>> the downstream CDN must decide which upstream CDN's CDNI metadata >>> should be used to handle a particular User Agent request. >>> " >>> s/must decide/needs to determine/ >>=20 >> Done. >>=20 >>> *** Section 6.4.2.1: >>> OLD: >>> " 6.4.2.1. JSON Example" >>> NEW: >>> " 6.4.2.1. Encoded CDNI Metadata Example" >>=20 >> Done. >>=20 >>> *** section 7.1.1.1" >>> " >>> DVD Region code (i.e., integer in the range 0-6).=20 >>> " >>> add a reference that specifies these values. >>=20 >> Design as looking at DVD specs we may need to change the = representation, will address in a follow-up e-mail. >>=20 >> Ben >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni From nobody Fri Jun 27 02:08:21 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6A61B2F39 for ; Fri, 27 Jun 2014 02:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.053 X-Spam-Level: X-Spam-Status: No, score=-12.053 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_31=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3W_1awVEwNv for ; Fri, 27 Jun 2014 02:08:18 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C34121B2F38 for ; Fri, 27 Jun 2014 02:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10513; q=dns/txt; s=iport; t=1403860098; x=1405069698; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=Eo29EFQ8jtS4oZS8hMk17aV+z6mP4RK2y4GmTii9IV4=; b=Ew45ShoitGIMnZVzDzpho6x3SFvIlF7l/huTtGeua/k1UXB1WH+uXNkd fVa83gyOKS0FQmD3iQVmc+uqiv41S1Bxxf3KvojoySbo7fNFuydNG1LA2 6lwsj20aCqHBfZJosBXWNmdQcxf0cRBYZz50lKJqP8ESUTbVawCsJIUjw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJMzrVOtJV2Z/2dsb2JhbABbgw1SWrxqh0CBChZ1hAMBAQEDAQEBAWgDCwULAgEIGC4nCyUCBAEJBAWIOggNwxgTBI5NM4M0gRYFlkSEFZN1g0KCMA X-IronPort-AV: E=Sophos;i="5.01,559,1400025600"; d="scan'208";a="56413299" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP; 27 Jun 2014 09:08:17 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s5R98GOw017150 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 09:08:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 04:08:16 -0500 From: "Francois Le Faucheur (flefauch)" To: Niven-Jenkins Ben , ietfdbh Thread-Topic: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY Thread-Index: AQHPkedUYgbpDuO2jkujcF9CrHRGXA== Date: Fri, 27 Jun 2014 09:08:15 +0000 Message-ID: <22312BC2-73AB-4F68-A569-74E679675E81@cisco.com> References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> <94DAC133-0CA7-4772-AA80-0F6D7D21A39C@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3622D9BC83F69643B5948484952E8C01@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/58cWMhCrFbaPz_YB96M_hcGecWk Cc: "cdni@ietf.org" Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 09:08:20 -0000 All, (as a document editor) The resolution coming in the next revision is discussed below: On 25 Apr 2014, at 18:53, Ben Niven-Jenkins wrote= : > Francois, >=20 > Rob, Grant and I chatted this over, our thoughts are inline below. >=20 > On 18 Apr 2014, at 18:07, Francois Le Faucheur (flefauch) wrote: >=20 >> Folks, >>=20 >> (as a cdni-logging author) >>=20 >> David kindly conducted an early OPSDIR review of cdni-logging (and a ver= y thorough one, I may add).=20 >>=20 >> This message discusses the proposed resolutions that affect MUST/SHOULD/= MAY statements. Please review/comment: >>=20 >> 1) >> Current text: >> " >> The fields names listed in the "Fields" directive MAY be listed in >> the order in which they are listed in Section 3.4.1 or MAY be listed >> in any other order. >> =B3 >> The proposal is to replace by: >> " >> The fields names listed in the "Fields" directive MUST be listed in >> the order in which they are listed in Section 3.4.1. >> =B3 >> This would simplify implementation a bit and facilitates interoperabilit= y. >> Can anyone see a good use case for exchanging fields in a different orde= r? >=20 > We=B9re not convinced such a change does actually simplify implementation= . Each implementation (CDN) will have its own internal log format. In order= to transfer logs across the CDNI logging interface, each CDN may have to t= ransform from its internal format to the CDNI logging interface format. How= ever if a CDN uses a similar log format (e.g. w3c but with fields in a diff= erent order to section 3.4.1) then under the old text it would=B9t have to = transform, whereas the new text would force it to, actually making the impl= ementation harder (and changing from a MAY to a MUST does=B9t make the work= of CDN that have to transform any easier either/simpler either). >=20 > The log format is based on a well known de-facto standard format (w3c), i= nteroperability is achieved by parsing the Fields directives to determine t= he log field ordering. All the change does is allow implementations to be l= azier (rather than parse the fields directive, assume that log fields are i= n a certain order). That may appear to aid interop but we don=B9t think it = does really, as it may cause other issues, e.g. if a dCDN includes optional= log fields and implementations are being lazy, will they fail to properly = parse such valid CDNI log files? If everyone has to parse the fields direct= ive, then initial implementation bugs may be more prevalent but long term i= nteroperability is higher as implementations are less likely to barf when p= resented log files with additional optional log fields. I buy that argument. So I have kept the current wording. >=20 >> 3) >> Current text: >> " >> If it supports redundant CDNI Logging feed, the client-side >> SHOULD use the UUID of the CDNI Logging File, presented in the >> atom:id element of the Atom feed, to avoid unnecessarily pulling and >> storing each CDNI Logging File more than once. >> =B3 >> The proposal is to replace by: >> =B3 >> If it supports redundant CDNI Logging feed, the client-side >> MUST use the UUID of the CDNI Logging File, presented in the >> atom:id element of the Atom feed, to avoid unnecessarily pulling and >> storing each CDNI Logging File more than once. >> " >> This would simplify implementation a bit and facilitates interoperabilit= y. >> Can anyone see a good use case for not using the UUID? >=20 > We don;t see how this simplifies implementation or facilitates interop. W= hat it does is reduce the amount of log download traffic, as a client will = only retrieve a log file once, but that does=B9t make implementation or int= erop simpler/easier. >=20 > Also it seems quite a draconian rule. If a client wants to download a log= twice, why should=B9t it be able to? To me, the intention of the text is not to prevent a client from pulling th= e same file multiple times (if it fancies doing so).=20 In fact we already have a statement saying "Note that a client-side impleme= ntation of the CDNI Logging interface MAY pull a CDNI Logging File that it = has already pulled." Rather, the intention was to say that, in case the client does not want to = pull the same file twice across the two feeds, the client-side can rely on = UUID as a way to establish that the same file is available on both feeds. I now realise that the text is not crystal clear.=20 In fact, I don't think there is any real RFC2119 requirements here. So I ha= ve replaced with: " If it supports redundant CDNI Logging feed, the client-side can use the UUI= D of the CDNI Logging File, presented in the atom:id element of the Atom fe= ed, to avoid unnecessarily pulling and storing a given CDNI Logging File mo= re than once. " >=20 >> 4)=20 >> In section 4.2 , current text >> =B3 >> To do so, the client-side: >> o MUST use HTTP v1.1 [RFC2616]; >> " >> The proposal is to edit the text to say that the client-side MUST implem= ent HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate wh= ich HTTP version is actually used. THis woudl allow to move to HTTP v2 whi= le still complying with the spec. >> The server-side text probably needs the corresponding adjustments. >=20 > Sounds OK. The client-side text has been updated to: =93 o MUST implement HTTP/1.1 [RFC2616], MAY also support other HTTP versions = (e.g., HTTP/2.0 [I-D.ietf-httpbis-http2]) and MAY negotiate which HTTP vers= ion is actually used. This allows operators and implementers to choose to u= se later versions of HTTP to take advantage of new features, while still en= suring interoperability with systems that only support HTTP/1.1. =93 The server-side text has been updated to: =93 o MUST implement HTTP/1.1 to handle the client-side request and MAY also su= pport other HTTP versions (e.g., HTTP/2.0); >=20 >> 5) >> Current text: >> =B3 >> o SHOULD support exchange of CDNI Logging Files with "gzip" content >> encoding (as defined in [RFC2616]) applied to the representation. >> " >> The proposal is to replace by: >> =B3 >> o MUST support exchange of CDNI Logging Files with "gzip" content >> encoding (as defined in [RFC2616]) applied to the representation. >> =B3 >> Given the concern about size of logging file it feel useful to have at l= east one common compression scheme. >=20 > The goal is laudable. However there have recently been various exploits/a= ttacks (e.g. BREACH) where an attacker can utilise information she knows th= at is reflected back in HTTP bodies to probe the compression context when c= ompression is used in combination with encrypted transport such as TLS. The= scenario is slightly different to the CDNI Logging interface but I think a= similar sort of attack could possibly be constructed for CDNI Logging and = folks are starting to take a general approach of not doing =8Cblind=B9 cont= ent compression over secure channels (e.g. over TLS) as there is the risk o= f information leakage that BREACH/CRIME/etc attacks expose. That isn=B9t to= say that compression isn=B9t suitable when using a secure channel, just th= at it needs more thought than applying a single compression context across = the entire content being transferred (e.g. separate compression contexts fo= r sensitive/non-sensitive data). >=20 > I=B9m not expert enough on security/BREACH/etc to say whether CDNI loggin= g would avoid such issues and =8Cblind=B9 compression is =8Csafe=B9 but we = should be cautious about introducing mandatory support for something that c= ould be a security hole. Someone more qualified should probably analyse/com= ment. >=20 > A easy/safe option would be to leave it as a SHOULD rather than change to= a MUST. I think the argument above suggets that we may not want to mandate the use = of gzip. But the requirement at stake here is not doing that. It is only ma= ndating that the implementation MUST support exchange of file with gzip. Ju= st like it already mandates that teh implementation supports exchange of f= ile with no content encoding. I think it is useful to ensure that server si= de and client side have at leats one compression scheme in common. The text= already leaves it open as to whetehr content encoding is used, and when us= ed which scheme is used. So, the client-side and server-side text has been updated to mandate gzip s= upport: =93 o MUST support exchange of CDNI Logging Files with no content encoding appl= ied to the representation; o MUST support exchange of CDNI Logging Files with "gzip" content encoding = (as defined in [RFC2616]) applied to the representation. >=20 >> 6) >> Current text: >> =B3 >> In an environment where any such protection is required, TLS SHOULD >> be used for transport of the CDNI Logging feed and the CDNI Logging >> File pull unless alternate methods are used for ensuring the >> confidentiality of the information in the logging files (such as >> setting up an IPsec tunnel between the two CDNs or using a physically >> secured internal network between two CDNs that are owned by the same >> corporate entity). Both parties of the transaction (uCDN and dCDN) >> SHOULD use mutual authentication. >> =B3 >> The proposal is to update to: >> =B3 >> In an environment where any such protection is required, TLS SHOULD >> be used (including authentication of the remote end) by the server-side = and the client-side of the CDNI Logging feed and of the CDNI Logging pull m= echanism unless alternate methods are used for ensuring the >> confidentiality of the information in the logging files (such as >> setting up an IPsec tunnel between the two CDNs or using a physically >> secured internal network between two CDNs that are owned by the same >> corporate entity). >> =B3 >> This is because it does not really make sense to say that =B3both ends u= se mutual authentication=B2, rather both ends need to authenticate the remo= te end (which collectively achieves mutual authentication). =20 >> Any concern with that? >=20 > No. The change above has been incorporated. Francois > HTH > Ben >=20 >>=20 >> Francois >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni >=20 From nobody Fri Jun 27 06:49:09 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7A1B2BD8 for ; Fri, 27 Jun 2014 06:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqqyKglt10yJ for ; Fri, 27 Jun 2014 06:49:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08FC91B2F2F for ; Fri, 27 Jun 2014 06:49:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6351; q=dns/txt; s=iport; t=1403876942; x=1405086542; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Ni9rTLYBbZULsrXyeEjqeWetHFFXPs90ewEz/SrNC2E=; b=HpivCc9vQcf8kWcLgz45r82kyxENYW4lha15tUHM6cAjqOMS8YHchQGg PJYRCQ4N2tLJfpfAzBlow62Hg7sSFnzQWkVYrw3IBuA5r9KqvRXV1eheW JfhNKJkKJ5I1eDgGRcRhCj594hLZxSaNGZgYGaDKLuzTGRDaky4h/Y14Q 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAON1rVOtJA2M/2dsb2JhbABXA4MNUlq8b4ZtUwGBCRZ1hAMBAQEDAQEBAWsLBQcEAgEIEQQBAQENGgcnCxQJCAIEAQkEBYguAwkIDbx3CIZVF45NIxAHBguDHIEWBYFYmQGBRpIvg0KCMA X-IronPort-AV: E=Sophos;i="5.01,560,1400025600"; d="scan'208";a="335917809" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-1.cisco.com with ESMTP; 27 Jun 2014 13:49:01 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s5RDn1Uf030041 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 27 Jun 2014 13:49:01 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Fri, 27 Jun 2014 08:49:00 -0500 From: "Francois Le Faucheur (flefauch)" To: ietfdbh , Niven-Jenkins Ben Thread-Topic: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY Thread-Index: AQHPkg6MYgbpDuO2jkujcF9CrHRGXA== Date: Fri, 27 Jun 2014 13:49:00 +0000 Message-ID: <1D1A37E5-2C10-46CD-B39E-8B0875BDA30B@cisco.com> References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> <039101cf5b5f$812cc790$838656b0$@comcast.net> <255A728C-3673-4C4F-A4E4-5A936C4FA0AD@niven-jenkins.co.uk> <028901cf60ab$d78eae40$86ac0ac0$@comcast.net> In-Reply-To: <028901cf60ab$d78eae40$86ac0ac0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.197] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/dia51b6Gw3GX4HhRnacxVZw6o08 Cc: "cdni@ietf.org" Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 13:49:08 -0000 All, (as a document editor): Resolution of item 2) below: On 25 Apr 2014, at 19:28, ietfdbh wrote: > Hi, >=20 > So it sounds to me like using HTTP cache control headers should be a SHOU= LD > use, not a MUST use. >=20 > This could be a MUST-implement for baseline interoperability reasons, jus= t > like HTTPv1.1 > "the server-side implementation MUST be able to set ..." would be correct= . >=20 > Then whether to USE the cache headers, or another mechanism, is an > operational runtime decision. > "the server-side implement SHOULD set ..." would be a runtime decision, n= ot > an implementation decision. >=20 > I think your best approach is to clearly separate implementation > requirements from use requirements. Agreed. The text was edited to: =93 The server-side implementation MUST be able to set HTTP cache control heade= rs on the subscription feed to indicate the frequency at which the client-s= ide is to poll for updates. The server-side SHOULD set HTTP cache control h= eaders on the subscription feed to indicate the frequency at which the clie= nt-side is to poll for updates. The client-side MAY use HTTP cache control headers (set by the server-side)= on the subscription feed to determine the frequency at which to poll for u= pdates. The client-side MAY instead, or in addition, use other information = to determine when to poll for updates (e.g., a polling frequency that may h= ave been between the uCDN and dCDN by mechanisms outside the scope of the p= resent document and that is to override the indications provided in the HTT= P cache control headers). " >=20 > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 >=20 >> -----Original Message----- >> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >> Sent: Friday, April 25, 2014 12:59 PM >> To: ietfdbh >> Cc: Francois Le Faucher; cdni@ietf.org >> Subject: Re: [CDNi] cdni-logging : Proposed adjustments on >> MUST/SHOULD/MAY >>=20 >> David, >>=20 >> See inline, >>=20 >> On 19 Apr 2014, at 00:39, ietfdbh wrote: >>=20 >>> Hi, >>>=20 >>> Inline. >>>=20 >>> David Harrington >>> ietfdbh@comcast.net >>> +1-603-828-1401 >>>=20 >>>> -----Original Message----- >>>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >>>> Sent: Friday, April 18, 2014 1:07 PM >>>> To: cdni@ietf.org >>>> Cc: Francois Le Faucheur (flefauch); ietfdbh >>>> Subject: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY >>>>=20 >>>> Folks, >>>>=20 >>>> (as a cdni-logging author) >>>>=20 >>>> David kindly conducted an early OPSDIR review of cdni-logging (and a > very >>>> thorough one, I may add). >>>>=20 >>>> This message discusses the proposed resolutions that affect >>>> MUST/SHOULD/MAY statements. Please review/comment: >>>>=20 >>> [...] >>>>=20 >>>> 2) >>>> Current text: >>>> " >>>> The server-side implementation SHOULD use HTTP cache control headers >>>> on the subscription feed to indicate the frequency at which the >>>> client-side is to poll for updates. >>>> " >>>> The proposal is to replace by: >>>> " >>>> The server-side implementation MUST set HTTP cache control headers >>>> on the subscription feed to indicate the frequency at which the >>>> client-side is to poll for updates. >>>> " >>>> This would simplify implementation a bit and facilitates > interoperability. >>>> Can anyone see a good use case for not setting cache control headers >> (note >>>> that the other side may decide to poll independently of those, but at >>> least it >>>> knowd those are always valid) ? >>>>=20 >>> Forgive me if I should already know this. >>>=20 >>> Section 4 talks about managing the ATOM feed, but only once does it >> mention >>> HTTP, and that is the sentence you are discussing. >>> Is HTTP the only way to control the frequency of polling? Or does it > just >>> make the most sense since this document focuses on HTTP? >>=20 >> Atom specifies no way to control the frequency of polling. Using HTTP > cache >> control headers is the 'de facto'/'best practice' according to various > internet >> sources (e.g. stack overflow) >>=20 >> http://stackoverflow.com/questions/939642/policy-for-polling-rss >>=20 >> I would expect some deployments to control the frequency via out of band >> mechanisms (e.g. agreed configuration between uCDN & dCDN). >>=20 >>> If, for whatever reason, an implementer or operator chose not to suppor= t >>> HTTP cache control headers, >>> Could an implementer/operator choose another protocol to specify the >> polling >>> frequency? >>=20 >> I don't see why not. HTTP cache control headers are only ever a hint > anyway, >> there is nothing in HTTP that mandates a client actually caches somethin= g >> that is marked as cacheable. >>=20 >>=20 >>> Are cache control headers at all controversial, say for security >>> considerations? >>=20 >> I don't think so. They're widely used for content on the web and within >> HTTP-based APIs. I can't think of any additional security considerations >> related to caching the atom feed itself that would't apply to any other >> cacheable content transferred over HTTP. >>=20 >> Regards >> Ben >>=20 >>=20 >>> [...] >>>>=20 >>>> 4) >>>> In section 4.2 , current text >>>> " >>>> To do so, the client-side: >>>> o MUST use HTTP v1.1 [RFC2616]; >>>> " >>>> The proposal is to edit the text to say that the client-side MUST >>> implement >>>> HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate >>>> which HTTP version is actually used. THis woudl allow to move to HTTP > v2 >>>> while still complying with the spec. >>>> The server-side text probably needs the corresponding adjustments. >>>=20 >>> s/ THis woudl allow to move to HTTP v2 while still complying with the >>> spec./This would allow operators and implementers to choose to use late= r >>> versions of HTTP to take advantage of new features, while still ensurin= g >>> interoperability with systems that only support v.1.1./ >>>=20 >>> [...] >>>=20 >>>>=20 >>>> Francois=3D >>>=20 >>> dbh >>>=20 >>> _______________________________________________ >>> CDNi mailing list >>> CDNi@ietf.org >>> https://www.ietf.org/mailman/listinfo/cdni >=20 From nobody Fri Jun 27 10:26:10 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302AD1A037D for ; Fri, 27 Jun 2014 10:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dItBIWMX9O2M for ; Fri, 27 Jun 2014 10:26:04 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94ADC1A0417 for ; Fri, 27 Jun 2014 10:26:04 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-20-53ad5787a4b3 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B7.48.05330.7875DA35; Fri, 27 Jun 2014 13:37:44 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Fri, 27 Jun 2014 13:26:01 -0400 From: Kevin Ma J To: "Francois Le Faucheur (flefauch)" Thread-Topic: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY Thread-Index: AQHPkg6MYgbpDuO2jkujcF9CrHRGXJuFeD8A Date: Fri, 27 Jun 2014 17:26:01 +0000 Message-ID: <533FA6F2-3E2F-4347-8328-FE6D1369F193@ericsson.com> References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> <039101cf5b5f$812cc790$838656b0$@comcast.net> <255A728C-3673-4C4F-A4E4-5A936C4FA0AD@niven-jenkins.co.uk> <028901cf60ab$d78eae40$86ac0ac0$@comcast.net> <1D1A37E5-2C10-46CD-B39E-8B0875BDA30B@cisco.com> In-Reply-To: <1D1A37E5-2C10-46CD-B39E-8B0875BDA30B@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-ID: <0876E18CF7016F4495182C936C023E3A@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyuXSPt25H+Npgg8btshYLzk1gs3g6+w+r xb8Fp5ksbl+KcWDxmPJ7I6vH5MdzGD2WLPnJ5PHz+iTGAJYoLpuU1JzMstQifbsEroxDDx+x FezyqJgy6yRTA+MZty5GTg4JAROJF8vmMUPYYhIX7q1n62Lk4hASOMoosXBhPyuEs5xRomHi JHaQKjYBLYnHX/8ygdgiAlYSqx82s4DYzAKFEidObgGrERbwkljUf4AVosZb4szDi1C2kcTs fYvBalgEVCUefNnFCGLzCthLXDw7iRFiWQ+TxNGjC8EaOAVsJS7tbAYrYgQ67/upNUwQy8Ql bj2ZzwRxtoDEkj3noV4QlXj5+B9QLwdQjabE+l36EOXWEsvfnWOHsBUlpnQ/ZIfYKyhxcuYT lgmMYrOQTJ2F0D0LSfcsJN2zkHQvYGRdxchRWpxalptuZLCJERhjxyTYdHcw7nlpeYhRgINR iYd3gcPaYCHWxLLiytxDjNIcLErivLNq5wULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYOy5 UL6o1XDq9MIHpVXTD1uaSVRc3PLsUqTd9R1Tpry793T7qycpu7VtuKsCdwaeVG/7x/LKfaXc 6/NzMjk75TfMqJzKueHUXZOzir9ylh1Y1ilu7dT36tPE7dtnRVrkKJ6Tyy4PFV45953OjZt2 Hd45n127Q5fN2rV04pVo0yOK33RMhTSild4psRRnJBpqMRcVJwIA6XBc8ZICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/6FD4AA4KSve8XMfhyr83lpnntR4 Cc: "cdni@ietf.org" , ietfdbh Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 17:26:07 -0000 SGkgRnJhbmNvaXMsDQoNCiBvbmUgY29tbWVudDogIm1heSBoYXZlIGJlZW4gYmV0d2VlbiIgLT4g Im1heSBoYXZlIGJlZW4gbmVnb3RpYXRlZCBiZXR3ZWVuIj8NCg0KdGhhbnguDQoNCi0tICBLZXZp biBKLiBNYQ0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCj4gT24gSnVuIDI3LCAyMDE0LCBhdCA1 OjQ5IEFNLCAiRnJhbmNvaXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKSIgPGZsZWZhdWNoQGNpc2Nv LmNvbT4gd3JvdGU6DQo+IA0KPiBBbGwsDQo+IA0KPiAoYXMgYSBkb2N1bWVudCBlZGl0b3IpOg0K PiANCj4gUmVzb2x1dGlvbiBvZiBpdGVtIDIpIGJlbG93Og0KPiANCj4+IE9uIDI1IEFwciAyMDE0 LCBhdCAxOToyOCwgaWV0ZmRiaCA8aWV0ZmRiaEBjb21jYXN0Lm5ldD4gd3JvdGU6DQo+PiANCj4+ IEhpLA0KPj4gDQo+PiBTbyBpdCBzb3VuZHMgdG8gbWUgbGlrZSB1c2luZyBIVFRQIGNhY2hlIGNv bnRyb2wgaGVhZGVycyBzaG91bGQgYmUgYSBTSE9VTEQNCj4+IHVzZSwgbm90IGEgTVVTVCB1c2Uu DQo+PiANCj4+IFRoaXMgY291bGQgYmUgYSBNVVNULWltcGxlbWVudCBmb3IgYmFzZWxpbmUgaW50 ZXJvcGVyYWJpbGl0eSByZWFzb25zLCBqdXN0DQo+PiBsaWtlIEhUVFB2MS4xDQo+PiAidGhlIHNl cnZlci1zaWRlIGltcGxlbWVudGF0aW9uIE1VU1QgYmUgYWJsZSB0byBzZXQgLi4uIiB3b3VsZCBi ZSBjb3JyZWN0Lg0KPj4gDQo+PiBUaGVuIHdoZXRoZXIgdG8gVVNFIHRoZSBjYWNoZSBoZWFkZXJz LCBvciBhbm90aGVyIG1lY2hhbmlzbSwgaXMgYW4NCj4+IG9wZXJhdGlvbmFsIHJ1bnRpbWUgZGVj aXNpb24uDQo+PiAidGhlIHNlcnZlci1zaWRlIGltcGxlbWVudCBTSE9VTEQgc2V0IC4uLiIgd291 bGQgYmUgYSBydW50aW1lIGRlY2lzaW9uLCBub3QNCj4+IGFuIGltcGxlbWVudGF0aW9uIGRlY2lz aW9uLg0KPj4gDQo+PiBJIHRoaW5rIHlvdXIgYmVzdCBhcHByb2FjaCBpcyB0byBjbGVhcmx5IHNl cGFyYXRlIGltcGxlbWVudGF0aW9uDQo+PiByZXF1aXJlbWVudHMgZnJvbSB1c2UgcmVxdWlyZW1l bnRzLg0KPiANCj4gQWdyZWVkLg0KPiANCj4gVGhlIHRleHQgd2FzIGVkaXRlZCB0bzoNCj4g4oCc DQo+IFRoZSBzZXJ2ZXItc2lkZSBpbXBsZW1lbnRhdGlvbiBNVVNUIGJlIGFibGUgdG8gc2V0IEhU VFAgY2FjaGUgY29udHJvbCBoZWFkZXJzIG9uIHRoZSBzdWJzY3JpcHRpb24gZmVlZCB0byBpbmRp Y2F0ZSB0aGUgZnJlcXVlbmN5IGF0IHdoaWNoIHRoZSBjbGllbnQtc2lkZSBpcyB0byBwb2xsIGZv ciB1cGRhdGVzLiBUaGUgc2VydmVyLXNpZGUgU0hPVUxEIHNldCBIVFRQIGNhY2hlIGNvbnRyb2wg aGVhZGVycyBvbiB0aGUgc3Vic2NyaXB0aW9uIGZlZWQgdG8gaW5kaWNhdGUgdGhlIGZyZXF1ZW5j eSBhdCB3aGljaCB0aGUgY2xpZW50LXNpZGUgaXMgdG8gcG9sbCBmb3IgdXBkYXRlcy4NCj4gDQo+ IFRoZSBjbGllbnQtc2lkZSBNQVkgdXNlIEhUVFAgY2FjaGUgY29udHJvbCBoZWFkZXJzIChzZXQg YnkgdGhlIHNlcnZlci1zaWRlKSBvbiB0aGUgc3Vic2NyaXB0aW9uIGZlZWQgdG8gZGV0ZXJtaW5l IHRoZSBmcmVxdWVuY3kgYXQgd2hpY2ggdG8gcG9sbCBmb3IgdXBkYXRlcy4gVGhlIGNsaWVudC1z aWRlIE1BWSBpbnN0ZWFkLCBvciBpbiBhZGRpdGlvbiwgdXNlIG90aGVyIGluZm9ybWF0aW9uIHRv IGRldGVybWluZSB3aGVuIHRvIHBvbGwgZm9yIHVwZGF0ZXMgKGUuZy4sIGEgcG9sbGluZyBmcmVx dWVuY3kgdGhhdCBtYXkgaGF2ZSBiZWVuIGJldHdlZW4gdGhlIHVDRE4gYW5kIGRDRE4gYnkgbWVj aGFuaXNtcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgcHJlc2VudCBkb2N1bWVudCBhbmQgdGhh dCBpcyB0byBvdmVycmlkZSB0aGUgaW5kaWNhdGlvbnMgcHJvdmlkZWQgaW4gdGhlIEhUVFAgY2Fj aGUgY29udHJvbCBoZWFkZXJzKS4NCj4gIg0KPiANCj4gDQo+PiANCj4+IERhdmlkIEhhcnJpbmd0 b24NCj4+IGlldGZkYmhAY29tY2FzdC5uZXQNCj4+ICsxLTYwMy04MjgtMTQwMQ0KPj4gDQo+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBCZW4gTml2ZW4tSmVua2lucyBb bWFpbHRvOmJlbkBuaXZlbi1qZW5raW5zLmNvLnVrXQ0KPj4+IFNlbnQ6IEZyaWRheSwgQXByaWwg MjUsIDIwMTQgMTI6NTkgUE0NCj4+PiBUbzogaWV0ZmRiaA0KPj4+IENjOiBGcmFuY29pcyBMZSBG YXVjaGVyOyBjZG5pQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6IFtDRE5pXSBjZG5pLWxvZ2dp bmcgOiBQcm9wb3NlZCBhZGp1c3RtZW50cyBvbg0KPj4+IE1VU1QvU0hPVUxEL01BWQ0KPj4+IA0K Pj4+IERhdmlkLA0KPj4+IA0KPj4+IFNlZSBpbmxpbmUsDQo+Pj4gDQo+Pj4+IE9uIDE5IEFwciAy MDE0LCBhdCAwMDozOSwgaWV0ZmRiaCA8aWV0ZmRiaEBjb21jYXN0Lm5ldD4gd3JvdGU6DQo+Pj4+ IA0KPj4+PiBIaSwNCj4+Pj4gDQo+Pj4+IElubGluZS4NCj4+Pj4gDQo+Pj4+IERhdmlkIEhhcnJp bmd0b24NCj4+Pj4gaWV0ZmRiaEBjb21jYXN0Lm5ldA0KPj4+PiArMS02MDMtODI4LTE0MDENCj4+ Pj4gDQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogRnJhbmNv aXMgTGUgRmF1Y2hldXIgKGZsZWZhdWNoKSBbbWFpbHRvOmZsZWZhdWNoQGNpc2NvLmNvbV0NCj4+ Pj4+IFNlbnQ6IEZyaWRheSwgQXByaWwgMTgsIDIwMTQgMTowNyBQTQ0KPj4+Pj4gVG86IGNkbmlA aWV0Zi5vcmcNCj4+Pj4+IENjOiBGcmFuY29pcyBMZSBGYXVjaGV1ciAoZmxlZmF1Y2gpOyBpZXRm ZGJoDQo+Pj4+PiBTdWJqZWN0OiBjZG5pLWxvZ2dpbmcgOiBQcm9wb3NlZCBhZGp1c3RtZW50cyBv biBNVVNUL1NIT1VMRC9NQVkNCj4+Pj4+IA0KPj4+Pj4gRm9sa3MsDQo+Pj4+PiANCj4+Pj4+IChh cyBhIGNkbmktbG9nZ2luZyBhdXRob3IpDQo+Pj4+PiANCj4+Pj4+IERhdmlkIGtpbmRseSBjb25k dWN0ZWQgYW4gZWFybHkgT1BTRElSIHJldmlldyBvZiBjZG5pLWxvZ2dpbmcgKGFuZCBhDQo+PiB2 ZXJ5DQo+Pj4+PiB0aG9yb3VnaCBvbmUsIEkgbWF5IGFkZCkuDQo+Pj4+PiANCj4+Pj4+IFRoaXMg bWVzc2FnZSBkaXNjdXNzZXMgdGhlIHByb3Bvc2VkIHJlc29sdXRpb25zIHRoYXQgYWZmZWN0DQo+ Pj4+PiBNVVNUL1NIT1VMRC9NQVkgc3RhdGVtZW50cy4gUGxlYXNlIHJldmlldy9jb21tZW50Og0K Pj4+PiBbLi4uXQ0KPj4+Pj4gDQo+Pj4+PiAyKQ0KPj4+Pj4gQ3VycmVudCB0ZXh0Og0KPj4+Pj4g Ig0KPj4+Pj4gVGhlIHNlcnZlci1zaWRlIGltcGxlbWVudGF0aW9uIFNIT1VMRCB1c2UgSFRUUCBj YWNoZSBjb250cm9sIGhlYWRlcnMNCj4+Pj4+IG9uIHRoZSBzdWJzY3JpcHRpb24gZmVlZCB0byBp bmRpY2F0ZSB0aGUgZnJlcXVlbmN5IGF0IHdoaWNoIHRoZQ0KPj4+Pj4gY2xpZW50LXNpZGUgaXMg dG8gcG9sbCBmb3IgdXBkYXRlcy4NCj4+Pj4+ICINCj4+Pj4+IFRoZSBwcm9wb3NhbCBpcyB0byBy ZXBsYWNlIGJ5Og0KPj4+Pj4gIg0KPj4+Pj4gVGhlIHNlcnZlci1zaWRlIGltcGxlbWVudGF0aW9u IE1VU1Qgc2V0IEhUVFAgY2FjaGUgY29udHJvbCBoZWFkZXJzDQo+Pj4+PiBvbiB0aGUgc3Vic2Ny aXB0aW9uIGZlZWQgdG8gaW5kaWNhdGUgdGhlIGZyZXF1ZW5jeSBhdCB3aGljaCB0aGUNCj4+Pj4+ IGNsaWVudC1zaWRlIGlzIHRvIHBvbGwgZm9yIHVwZGF0ZXMuDQo+Pj4+PiAiDQo+Pj4+PiBUaGlz IHdvdWxkIHNpbXBsaWZ5IGltcGxlbWVudGF0aW9uIGEgYml0IGFuZCBmYWNpbGl0YXRlcw0KPj4g aW50ZXJvcGVyYWJpbGl0eS4NCj4+Pj4+IENhbiBhbnlvbmUgc2VlIGEgZ29vZCB1c2UgY2FzZSBm b3Igbm90IHNldHRpbmcgY2FjaGUgY29udHJvbCBoZWFkZXJzDQo+Pj4gKG5vdGUNCj4+Pj4+IHRo YXQgdGhlIG90aGVyIHNpZGUgbWF5IGRlY2lkZSB0byBwb2xsIGluZGVwZW5kZW50bHkgb2YgdGhv c2UsIGJ1dCBhdA0KPj4+PiBsZWFzdCBpdA0KPj4+Pj4ga25vd2QgdGhvc2UgYXJlIGFsd2F5cyB2 YWxpZCkgPw0KPj4+PiBGb3JnaXZlIG1lIGlmIEkgc2hvdWxkIGFscmVhZHkga25vdyB0aGlzLg0K Pj4+PiANCj4+Pj4gU2VjdGlvbiA0IHRhbGtzIGFib3V0IG1hbmFnaW5nIHRoZSBBVE9NIGZlZWQs IGJ1dCBvbmx5IG9uY2UgZG9lcyBpdA0KPj4+IG1lbnRpb24NCj4+Pj4gSFRUUCwgYW5kIHRoYXQg aXMgdGhlIHNlbnRlbmNlIHlvdSBhcmUgZGlzY3Vzc2luZy4NCj4+Pj4gSXMgSFRUUCB0aGUgb25s eSB3YXkgdG8gY29udHJvbCB0aGUgZnJlcXVlbmN5IG9mIHBvbGxpbmc/IE9yIGRvZXMgaXQNCj4+ IGp1c3QNCj4+Pj4gbWFrZSB0aGUgbW9zdCBzZW5zZSBzaW5jZSB0aGlzIGRvY3VtZW50IGZvY3Vz ZXMgb24gSFRUUD8NCj4+PiANCj4+PiBBdG9tIHNwZWNpZmllcyBubyB3YXkgdG8gY29udHJvbCB0 aGUgZnJlcXVlbmN5IG9mIHBvbGxpbmcuIFVzaW5nIEhUVFANCj4+IGNhY2hlDQo+Pj4gY29udHJv bCBoZWFkZXJzIGlzIHRoZSAnZGUgZmFjdG8nLydiZXN0IHByYWN0aWNlJyBhY2NvcmRpbmcgdG8g dmFyaW91cw0KPj4gaW50ZXJuZXQNCj4+PiBzb3VyY2VzIChlLmcuIHN0YWNrIG92ZXJmbG93KQ0K Pj4+IA0KPj4+IGh0dHA6Ly9zdGFja292ZXJmbG93LmNvbS9xdWVzdGlvbnMvOTM5NjQyL3BvbGlj eS1mb3ItcG9sbGluZy1yc3MNCj4+PiANCj4+PiBJIHdvdWxkIGV4cGVjdCBzb21lIGRlcGxveW1l bnRzIHRvIGNvbnRyb2wgdGhlIGZyZXF1ZW5jeSB2aWEgb3V0IG9mIGJhbmQNCj4+PiBtZWNoYW5p c21zIChlLmcuIGFncmVlZCBjb25maWd1cmF0aW9uIGJldHdlZW4gdUNETiAmIGRDRE4pLg0KPj4+ IA0KPj4+PiBJZiwgZm9yIHdoYXRldmVyIHJlYXNvbiwgYW4gaW1wbGVtZW50ZXIgb3Igb3BlcmF0 b3IgY2hvc2Ugbm90IHRvIHN1cHBvcnQNCj4+Pj4gSFRUUCBjYWNoZSBjb250cm9sIGhlYWRlcnMs DQo+Pj4+IENvdWxkIGFuIGltcGxlbWVudGVyL29wZXJhdG9yIGNob29zZSBhbm90aGVyIHByb3Rv Y29sIHRvIHNwZWNpZnkgdGhlDQo+Pj4gcG9sbGluZw0KPj4+PiBmcmVxdWVuY3k/DQo+Pj4gDQo+ Pj4gSSBkb24ndCBzZWUgd2h5IG5vdC4gSFRUUCBjYWNoZSBjb250cm9sIGhlYWRlcnMgYXJlIG9u bHkgZXZlciBhIGhpbnQNCj4+IGFueXdheSwNCj4+PiB0aGVyZSBpcyBub3RoaW5nIGluIEhUVFAg dGhhdCBtYW5kYXRlcyBhIGNsaWVudCBhY3R1YWxseSBjYWNoZXMgc29tZXRoaW5nDQo+Pj4gdGhh dCBpcyBtYXJrZWQgYXMgY2FjaGVhYmxlLg0KPj4+IA0KPj4+IA0KPj4+PiBBcmUgY2FjaGUgY29u dHJvbCBoZWFkZXJzIGF0IGFsbCBjb250cm92ZXJzaWFsLCBzYXkgZm9yIHNlY3VyaXR5DQo+Pj4+ IGNvbnNpZGVyYXRpb25zPw0KPj4+IA0KPj4+IEkgZG9uJ3QgdGhpbmsgc28uIFRoZXkncmUgd2lk ZWx5IHVzZWQgZm9yIGNvbnRlbnQgb24gdGhlIHdlYiBhbmQgd2l0aGluDQo+Pj4gSFRUUC1iYXNl ZCBBUElzLiBJIGNhbid0IHRoaW5rIG9mIGFueSBhZGRpdGlvbmFsIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zDQo+Pj4gcmVsYXRlZCB0byBjYWNoaW5nIHRoZSBhdG9tIGZlZWQgaXRzZWxmIHRoYXQg d291bGQndCBhcHBseSB0byBhbnkgb3RoZXINCj4+PiBjYWNoZWFibGUgY29udGVudCB0cmFuc2Zl cnJlZCBvdmVyIEhUVFAuDQo+Pj4gDQo+Pj4gUmVnYXJkcw0KPj4+IEJlbg0KPj4+IA0KPj4+IA0K Pj4+PiBbLi4uXQ0KPj4+Pj4gDQo+Pj4+PiA0KQ0KPj4+Pj4gSW4gc2VjdGlvbiA0LjIgLCBjdXJy ZW50IHRleHQNCj4+Pj4+ICINCj4+Pj4+IFRvIGRvIHNvLCB0aGUgY2xpZW50LXNpZGU6DQo+Pj4+ PiBvICBNVVNUIHVzZSBIVFRQIHYxLjEgW1JGQzI2MTZdOw0KPj4+Pj4gIg0KPj4+Pj4gVGhlIHBy b3Bvc2FsIGlzIHRvIGVkaXQgdGhlIHRleHQgdG8gc2F5IHRoYXQgdGhlIGNsaWVudC1zaWRlIE1V U1QNCj4+Pj4gaW1wbGVtZW50DQo+Pj4+PiBIVFRQIHYxLjEgYW5kIE1BWSBhbHNvIHN1cHBvcnQg b3RoZXIgSFRUUCB2ZXJzaW9ucyBhbmQgTUFZIG5lZ290aWF0ZQ0KPj4+Pj4gd2hpY2ggSFRUUCB2 ZXJzaW9uIGlzIGFjdHVhbGx5IHVzZWQuICBUSGlzIHdvdWRsIGFsbG93IHRvIG1vdmUgdG8gSFRU UA0KPj4gdjINCj4+Pj4+IHdoaWxlIHN0aWxsIGNvbXBseWluZyB3aXRoIHRoZSBzcGVjLg0KPj4+ Pj4gVGhlIHNlcnZlci1zaWRlIHRleHQgcHJvYmFibHkgbmVlZHMgdGhlIGNvcnJlc3BvbmRpbmcg YWRqdXN0bWVudHMuDQo+Pj4+IA0KPj4+PiBzLyBUSGlzIHdvdWRsIGFsbG93IHRvIG1vdmUgdG8g SFRUUCB2MiB3aGlsZSBzdGlsbCBjb21wbHlpbmcgd2l0aCB0aGUNCj4+Pj4gc3BlYy4vVGhpcyB3 b3VsZCBhbGxvdyBvcGVyYXRvcnMgYW5kIGltcGxlbWVudGVycyB0byBjaG9vc2UgdG8gdXNlIGxh dGVyDQo+Pj4+IHZlcnNpb25zIG9mIEhUVFAgdG8gdGFrZSBhZHZhbnRhZ2Ugb2YgbmV3IGZlYXR1 cmVzLCB3aGlsZSBzdGlsbCBlbnN1cmluZw0KPj4+PiBpbnRlcm9wZXJhYmlsaXR5IHdpdGggc3lz dGVtcyB0aGF0IG9ubHkgc3VwcG9ydCB2LjEuMS4vDQo+Pj4+IA0KPj4+PiBbLi4uXQ0KPj4+PiAN Cj4+Pj4+IA0KPj4+Pj4gRnJhbmNvaXM9DQo+Pj4+IA0KPj4+PiBkYmgNCj4+Pj4gDQo+Pj4+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IENETmkg bWFpbGluZyBsaXN0DQo+Pj4+IENETmlAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jZG5pDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBDRE5pIG1haWxpbmcgbGlzdA0KPiBDRE5pQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2RuaQ0K From nobody Sun Jun 29 23:58:39 2014 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711031A0180 for ; Sun, 29 Jun 2014 23:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.452 X-Spam-Level: X-Spam-Status: No, score=-12.452 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z81MKmzkdXDp for ; Sun, 29 Jun 2014 23:58:35 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0B21A0179 for ; Sun, 29 Jun 2014 23:58:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7267; q=dns/txt; s=iport; t=1404111515; x=1405321115; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=K/PY255IsSxsamE6H90Hihi5Bi2c68MfyusrOzEc+v0=; b=m78MSl3BvrnRImYeOxJP3QRad6DrJdcra+EqmY+ov9nY9CvbKDZwREyJ ICExu744z4D1yaF07NxpQ0k/7cLcKyNbkwm/ti8lhGNABA5vpTeRl7x7p mRgXmcdzvq/P9G3dbMYfA/NIg/CGDv+LmHZwGagC3dmSW/g4B1RdjWUVl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFANMJsVOtJV2U/2dsb2JhbABXA4MNUlq+F4ZtUwGBDBZ1hAMBAQEDAQEBASRHCwUHBAIBCBEEAQEBDRoHJwsUCQgCBAoEBYguAwkIDb9FCIZXF45UIxAHBguDHIEWBZpegUaSN4NCbIFE X-IronPort-AV: E=Sophos;i="5.01,573,1400025600"; d="scan'208";a="336638785" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jun 2014 06:58:34 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s5U6wYxC022736 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 30 Jun 2014 06:58:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.102]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0123.003; Mon, 30 Jun 2014 01:58:33 -0500 From: "Francois Le Faucheur (flefauch)" To: Ma Kevin Thread-Topic: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY Thread-Index: AQHPkg6MYgbpDuO2jkujcF9CrHRGXJuFeD8AgAQY2IA= Date: Mon, 30 Jun 2014 06:58:33 +0000 Message-ID: <36E76C39-4FD1-4BE4-8DB0-64BB310C0508@cisco.com> References: <7C4FD086-4264-443B-8791-6FE7C48C7FB1@cisco.com> <039101cf5b5f$812cc790$838656b0$@comcast.net> <255A728C-3673-4C4F-A4E4-5A936C4FA0AD@niven-jenkins.co.uk> <028901cf60ab$d78eae40$86ac0ac0$@comcast.net> <1D1A37E5-2C10-46CD-B39E-8B0875BDA30B@cisco.com> <533FA6F2-3E2F-4347-8328-FE6D1369F193@ericsson.com> In-Reply-To: <533FA6F2-3E2F-4347-8328-FE6D1369F193@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.200] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/cdni/OnvL3ZpwjQ0adDLQfrMtRwGfaio Cc: "cdni@ietf.org" , ietfdbh Subject: Re: [CDNi] cdni-logging : Proposed adjustments on MUST/SHOULD/MAY X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 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 Jun 2014 06:58:37 -0000 Thanks Kevin. Fixed now. On 27 Jun 2014, at 19:26, Kevin Ma J wrote: > Hi Francois, >=20 > one comment: "may have been between" -> "may have been negotiated between= "? >=20 > thanx. >=20 > -- Kevin J. Ma >=20 > Sent from my iPhone >=20 >> On Jun 27, 2014, at 5:49 AM, "Francois Le Faucheur (flefauch)" wrote: >>=20 >> All, >>=20 >> (as a document editor): >>=20 >> Resolution of item 2) below: >>=20 >>> On 25 Apr 2014, at 19:28, ietfdbh wrote: >>>=20 >>> Hi, >>>=20 >>> So it sounds to me like using HTTP cache control headers should be a SH= OULD >>> use, not a MUST use. >>>=20 >>> This could be a MUST-implement for baseline interoperability reasons, j= ust >>> like HTTPv1.1 >>> "the server-side implementation MUST be able to set ..." would be corre= ct. >>>=20 >>> Then whether to USE the cache headers, or another mechanism, is an >>> operational runtime decision. >>> "the server-side implement SHOULD set ..." would be a runtime decision,= not >>> an implementation decision. >>>=20 >>> I think your best approach is to clearly separate implementation >>> requirements from use requirements. >>=20 >> Agreed. >>=20 >> The text was edited to: >> =93 >> The server-side implementation MUST be able to set HTTP cache control he= aders on the subscription feed to indicate the frequency at which the clien= t-side is to poll for updates. The server-side SHOULD set HTTP cache contro= l headers on the subscription feed to indicate the frequency at which the c= lient-side is to poll for updates. >>=20 >> The client-side MAY use HTTP cache control headers (set by the server-si= de) on the subscription feed to determine the frequency at which to poll fo= r updates. The client-side MAY instead, or in addition, use other informati= on to determine when to poll for updates (e.g., a polling frequency that ma= y have been between the uCDN and dCDN by mechanisms outside the scope of th= e present document and that is to override the indications provided in the = HTTP cache control headers). >> " >>=20 >>=20 >>>=20 >>> David Harrington >>> ietfdbh@comcast.net >>> +1-603-828-1401 >>>=20 >>>> -----Original Message----- >>>> From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk] >>>> Sent: Friday, April 25, 2014 12:59 PM >>>> To: ietfdbh >>>> Cc: Francois Le Faucher; cdni@ietf.org >>>> Subject: Re: [CDNi] cdni-logging : Proposed adjustments on >>>> MUST/SHOULD/MAY >>>>=20 >>>> David, >>>>=20 >>>> See inline, >>>>=20 >>>>> On 19 Apr 2014, at 00:39, ietfdbh wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> Inline. >>>>>=20 >>>>> David Harrington >>>>> ietfdbh@comcast.net >>>>> +1-603-828-1401 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Francois Le Faucheur (flefauch) [mailto:flefauch@cisco.com] >>>>>> Sent: Friday, April 18, 2014 1:07 PM >>>>>> To: cdni@ietf.org >>>>>> Cc: Francois Le Faucheur (flefauch); ietfdbh >>>>>> Subject: cdni-logging : Proposed adjustments on MUST/SHOULD/MAY >>>>>>=20 >>>>>> Folks, >>>>>>=20 >>>>>> (as a cdni-logging author) >>>>>>=20 >>>>>> David kindly conducted an early OPSDIR review of cdni-logging (and a >>> very >>>>>> thorough one, I may add). >>>>>>=20 >>>>>> This message discusses the proposed resolutions that affect >>>>>> MUST/SHOULD/MAY statements. Please review/comment: >>>>> [...] >>>>>>=20 >>>>>> 2) >>>>>> Current text: >>>>>> " >>>>>> The server-side implementation SHOULD use HTTP cache control headers >>>>>> on the subscription feed to indicate the frequency at which the >>>>>> client-side is to poll for updates. >>>>>> " >>>>>> The proposal is to replace by: >>>>>> " >>>>>> The server-side implementation MUST set HTTP cache control headers >>>>>> on the subscription feed to indicate the frequency at which the >>>>>> client-side is to poll for updates. >>>>>> " >>>>>> This would simplify implementation a bit and facilitates >>> interoperability. >>>>>> Can anyone see a good use case for not setting cache control headers >>>> (note >>>>>> that the other side may decide to poll independently of those, but a= t >>>>> least it >>>>>> knowd those are always valid) ? >>>>> Forgive me if I should already know this. >>>>>=20 >>>>> Section 4 talks about managing the ATOM feed, but only once does it >>>> mention >>>>> HTTP, and that is the sentence you are discussing. >>>>> Is HTTP the only way to control the frequency of polling? Or does it >>> just >>>>> make the most sense since this document focuses on HTTP? >>>>=20 >>>> Atom specifies no way to control the frequency of polling. Using HTTP >>> cache >>>> control headers is the 'de facto'/'best practice' according to various >>> internet >>>> sources (e.g. stack overflow) >>>>=20 >>>> http://stackoverflow.com/questions/939642/policy-for-polling-rss >>>>=20 >>>> I would expect some deployments to control the frequency via out of ba= nd >>>> mechanisms (e.g. agreed configuration between uCDN & dCDN). >>>>=20 >>>>> If, for whatever reason, an implementer or operator chose not to supp= ort >>>>> HTTP cache control headers, >>>>> Could an implementer/operator choose another protocol to specify the >>>> polling >>>>> frequency? >>>>=20 >>>> I don't see why not. HTTP cache control headers are only ever a hint >>> anyway, >>>> there is nothing in HTTP that mandates a client actually caches someth= ing >>>> that is marked as cacheable. >>>>=20 >>>>=20 >>>>> Are cache control headers at all controversial, say for security >>>>> considerations? >>>>=20 >>>> I don't think so. They're widely used for content on the web and withi= n >>>> HTTP-based APIs. I can't think of any additional security consideratio= ns >>>> related to caching the atom feed itself that would't apply to any othe= r >>>> cacheable content transferred over HTTP. >>>>=20 >>>> Regards >>>> Ben >>>>=20 >>>>=20 >>>>> [...] >>>>>>=20 >>>>>> 4) >>>>>> In section 4.2 , current text >>>>>> " >>>>>> To do so, the client-side: >>>>>> o MUST use HTTP v1.1 [RFC2616]; >>>>>> " >>>>>> The proposal is to edit the text to say that the client-side MUST >>>>> implement >>>>>> HTTP v1.1 and MAY also support other HTTP versions and MAY negotiate >>>>>> which HTTP version is actually used. THis woudl allow to move to HT= TP >>> v2 >>>>>> while still complying with the spec. >>>>>> The server-side text probably needs the corresponding adjustments. >>>>>=20 >>>>> s/ THis woudl allow to move to HTTP v2 while still complying with the >>>>> spec./This would allow operators and implementers to choose to use la= ter >>>>> versions of HTTP to take advantage of new features, while still ensur= ing >>>>> interoperability with systems that only support v.1.1./ >>>>>=20 >>>>> [...] >>>>>=20 >>>>>>=20 >>>>>> Francois=3D >>>>>=20 >>>>> dbh >>>>>=20 >>>>> _______________________________________________ >>>>> CDNi mailing list >>>>> CDNi@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cdni >>=20 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni