From internet-drafts@ietf.org Mon Jul 1 09:19:50 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA72C11E81BE; Mon, 1 Jul 2013 09:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GftriQZWsX12; Mon, 1 Jul 2013 09:19:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08EBC11E80E2; Mon, 1 Jul 2013 09:19:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130701161949.7690.95204.idtracker@ietfa.amsl.com> Date: Mon, 01 Jul 2013 09:19:49 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-09.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:19:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : Content Distribution Network Interconnection (CDNI) Requ= irements Author(s) : Kent Leung Yiu Lee Filename : draft-ietf-cdni-requirements-09.txt Pages : 24 Date : 2013-07-01 Abstract: Content Delivery Networks (CDNs) are frequently used for content delivery. As a result of significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure. Many Network Service Providers and Enterprise Service Providers are also deploying their own CDNs. To deliver contents from the Content Service Protect (CSP) to end users, the contents may traverse across multiple CDNs. This creates a need for interconnecting (previously) standalone CDNs so that they can collectively act as a single delivery platform from the CSP to the end users. The goal of the present document is to outline the requirements for the solution and interfaces to be specified by the CDNI working group. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-requirements-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-requirements-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From flefauch@cisco.com Thu Jul 4 02:04:03 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1550621F9F45 for ; Thu, 4 Jul 2013 02:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.998 X-Spam-Level: X-Spam-Status: No, score=-8.998 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F41vUh39xJhs for ; Thu, 4 Jul 2013 02:03:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 7869521F9F33 for ; Thu, 4 Jul 2013 02:03:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4509; q=dns/txt; s=iport; t=1372928637; x=1374138237; h=from:to:subject:date:message-id:references:mime-version; bh=oaCHEyyGPNMwCCgmaWdz9i4BpsfHXa9KXZsoUcwfkUs=; b=CEMQv0Rb5O1ZgG2Xa9+Mu1XcjlsLbDCIwDwD6tgjsQVXyBkQF3vecQB/ vmT1qqmZP9XSz+Z1XPwtzSL05vthVKg/38g09o8ZNF5LVuZGfunkVWMrz k2MwK9V18RVN/LRZfs6NlHbG9Tct1IBW4ahzATZz7IgwUw4iimTOHprfb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FACs51VGtJV2a/2dsb2JhbABagwl7wD6BBBZ0giMBAQEEbhcEAgEMDQMBAgsdBzIUBwIIAgQTCIgHuXSPOiAegn5pA6kOgxGCKA X-IronPort-AV: E=Sophos;i="4.87,993,1363132800"; d="scan'208,217";a="230899715" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 04 Jul 2013 09:03:57 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6493uQm018289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 4 Jul 2013 09:03:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 4 Jul 2013 04:03:56 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Draft submission deadlines change Thread-Index: AQHOd/67eeY7nZVLI02cPnhMaVRhhQ== Date: Thu, 4 Jul 2013 09:03:55 +0000 Message-ID: References: <51D43DAF.4030503@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D68B523xmbrcdx10ciscocom_" MIME-Version: 1.0 Subject: [CDNi] Fwd: Draft submission deadlines change X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 09:04:03 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D68B523xmbrcdx10ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable See IETF announcement below. (basically, you have one extra week for -00 Internet-Drafts). Francois -------- Original Message -------- Subject: Draft submission deadlines change Date: Tue, 02 Jul 2013 22:17:01 -0700 From: IETF Chair Reply-To: ietf@ietf.org To: IETF Announcement List Please note that for IETF 87, there is only one deadline for draft submissi= on: Monday 15th July. Previously, there had been two different deadlines, o= ne for -00 and another one for other versions. The IESG has decided to expe= riment with just one deadline for now to simplify the set of deadlines and = enable easier submission of new drafts. While we realise that the change co= mes near the deadline, we hope that you find the extra time useful. But please do note that working group chairs will continue to make smart de= cisions about what topics are worthwhile for discussing in a session in the= upcoming meeting, and will also set their agendas in a timely manner and c= reate deadlines for their working groups that must be adhered to. The earli= er new drafts are submitted, the more time there is to talk about them on t= he mailing lists and consider them for the session agendas. This is particu= larly important for BoFs. Jari Arkko for the IESG --_000_FC236DA6F2DA77449EF2D02DF4471A8D68B523xmbrcdx10ciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <81000DB314C0CC4D8BE66A0ADC48CA62@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
See IETF announcement below.
(basically, you have one extra week for -00 Internet-Drafts).

Francois


-------- Original Message --------
Subject: Draft submission deadlines change
Date: Tue, 02 Jul 2013 22:17:01 -0700
From: IETF Chair <chair@ietf.org>
Reply-To: iet= f@ietf.org
To: IETF Announcement List <ietf-announce@ietf.org> 


Please note that for IETF 87, there is only one deadline for draft sub=
mission: Monday 15th July. Previously, there had been two different deadlin=
es, one for -00 and another one for other versions. The IESG has decided to=
 experiment with just one deadline for now to simplify the set of deadlines=
 and enable easier submission of new drafts. While we realise that the chan=
ge comes near the deadline, we hope that you find the extra time useful.

But please do note that working group chairs will continue to make smart de=
cisions about what topics are worthwhile for discussing in a session in the=
 upcoming meeting, and will also set their agendas in a timely manner and c=
reate deadlines for their working groups that must be adhered to. The earli=
er new drafts are submitted, the more time there is to talk about them on t=
he mailing lists and consider them for the session agendas. This is particu=
larly important for BoFs.

Jari Arkko for the IESG



--_000_FC236DA6F2DA77449EF2D02DF4471A8D68B523xmbrcdx10ciscocom_-- From flefauch@cisco.com Mon Jul 8 07:09:47 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB9221F9D09 for ; Mon, 8 Jul 2013 07:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dz0eGdWZEShD for ; Mon, 8 Jul 2013 07:09:42 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 6958B21F9C6E for ; Mon, 8 Jul 2013 07:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=438; q=dns/txt; s=iport; t=1373292582; x=1374502182; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=090OrRSGNV71Ux+DfV6uI+Iq29lWCIChr3/E/auGujo=; b=Zy1s7s0v2TLGtQ+9AAAZem1yaSUyGgFEuiR+cPL6HQLcgNzZOdZwQCIi mHGMZoBDFi9NQVJQuMjR3k/zC4s+8pYJax3RVXuid4DZMSYfgZ8/QH5Ju Zf/eOV3ZHfjBVQaagNkm1hOnca+GqsjQqGVRY8MLQDihrm9xyCniUlV9G s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmgFAOLG2lGtJXHA/2dsb2JhbABagwkyTYJBviCBDxZ0giUBBDpRASoUQicEG4gHDJgzn28EjzozgwxpA6kbgxGCKA X-IronPort-AV: E=Sophos;i="4.87,1020,1363132800"; d="scan'208";a="232188388" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 08 Jul 2013 14:09:40 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r68E9eET005086 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Jul 2013 14:09:40 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 09:09:40 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI Working Group sessions at IETF 87 Thread-Index: AQHOe+TILOKD/lujaUq7sE8hX4/xrg== Date: Mon, 8 Jul 2013 14:09:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI Working Group sessions at IETF 87 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:09:47 -0000 Folks, Please note the CDNI WG sessions in Berlin: cdni Session 1 Tuesday, Afternoon Session II 1520-1650 Room Name: Potsdam 3 --------------------------------------------- cdni Session 2 Thursday, Afternoon Session III 1700-1830 Room Name: Potsdam 2 --------------------------------------------- For complete agenda see: https://datatracker.ietf.org/meeting/87/agenda.html Francois & Daryl From flefauch@cisco.com Mon Jul 8 07:11:41 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3192421F9A51 for ; Mon, 8 Jul 2013 07:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id il7ofzJYRGkq for ; Mon, 8 Jul 2013 07:11:35 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 292BE21F9A3C for ; Mon, 8 Jul 2013 07:11:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=157; q=dns/txt; s=iport; t=1373292691; x=1374502291; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ZWcRh6oGeIHvbiRPzk8OxsXq5VMMgI5hAFGYdSzBsFo=; b=kKWeGBJwngyAaCZICB/jnAPkN/UOVGwbGeWHfay2W0HRqgO0HYRxDZuH M3cEN3HlPB+Z8xMjd+IIKRZjZfwQlsgZBlcTzdHkPaf+gq1NNQhA+UlbW VWVPUj7E5LHblDR3zajoOJuTjkqJIc6f41hbPqiwJ4K7myoBldlKBWrEw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsKAGPH2lGtJV2b/2dsb2JhbABagwl/wFkEAwGBDxZ0giUBBDpRASoUQicEG4gHmD+fc486gz9pA6kbgxGCKA X-IronPort-AV: E=Sophos;i="4.87,1020,1363132800"; d="scan'208";a="232094272" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 08 Jul 2013 14:11:30 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r68EBUum021775 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 8 Jul 2013 14:11:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 8 Jul 2013 09:11:30 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI Slot Requests for IETF-87 Thread-Index: AQHOe+UKavfDyHmh0U6jCZsuNkaCzQ== Date: Mon, 8 Jul 2013 14:11:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="us-ascii" Content-ID: <2A5FFE0BF2D7EC45BBBF56BC26C8538B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI Slot Requests for IETF-87 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 14:11:41 -0000 Folks, We will publish the draft CDNI WG agenda by 19 Jul, so please send your slo= t requests to Daryl and I by 17 Jul. Cheers Francois & Daryl= From ietf-ipr@ietf.org Tue Jul 9 14:15:06 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D35221F9E83; Tue, 9 Jul 2013 14:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.16 X-Spam-Level: X-Spam-Status: No, score=-102.16 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-xnsDfzvWO2; Tue, 9 Jul 2013 14:15:06 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D9C21F9E7B; Tue, 9 Jul 2013 14:15:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: kleung@cisco.com,yiu_lee@cable.comcast.com X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130709211505.7576.21720.idtracker@ietfa.amsl.com> Date: Tue, 09 Jul 2013 14:15:06 -0700 Cc: cdni@ietf.org, ipr-announce@ietf.org Subject: [CDNi] =?utf-8?q?IPR_Disclosure=3A_Cisco=E2=80=99s_Statement_of_I?= =?utf-8?q?PR_Related_to_draft-ietf-cdni-requirements-09?= X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 21:15:06 -0000 Dear Kent Leung, Yiu Lee: An IPR disclosure that pertains to your Internet-Draft entitled "Content Distribution Network Interconnection (CDNI) Requirements" (draft-ietf-cdni- requirements) was submitted to the IETF Secretariat on 2013-07-09 and has b= een posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2124/). The title of the IPR disclosure is "Cisco=E2=80=99s Statement of IPR Related to draft-ietf-cdni-requirements-0= 9.""); The IETF Secretariat From Jan.Seedorf@neclab.eu Thu Jul 11 02:14:18 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1BA21F9D80 for ; Thu, 11 Jul 2013 02:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.349 X-Spam-Level: X-Spam-Status: No, score=-103.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O3ouLeCvxs0V for ; Thu, 11 Jul 2013 02:14:14 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 7E49921F9AA9 for ; Thu, 11 Jul 2013 02:14:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id A54B0104A4F; Thu, 11 Jul 2013 11:13:39 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKKln9f1FMUM; Thu, 11 Jul 2013 11:13:39 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 86D17104A43; Thu, 11 Jul 2013 11:13:29 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 11 Jul 2013 11:12:16 +0200 From: Jan Seedorf To: Scott Wainner Thread-Topic: Questions and comments on draft-spp-cdni-rr-foot-cap-semantics-04 Thread-Index: Ac5+FuaXkU2R2fxUQCGJO+AWQUB1/g== Date: Thu, 11 Jul 2013 09:12:16 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE555844F0@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.5.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: [CDNi] Questions and comments on draft-spp-cdni-rr-foot-cap-semantics-04 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 09:14:18 -0000 Dear Scott, Many thanks for your comments. Please let me comment below only on the ones= where I have questions or where I would like to get opinions from the WG. = Your other comments (i.e. the ones that are clear to me) are already incorp= orated into the -00 version of the WG item document which we will submit ne= xt Monday. WG: I would appreciate other comments on the issues raised by Scott. Especi= ally on the open issues (Section 7 of the draft) any opinion / discussion i= s appreciated.=20 > | o The uCDN has received footprint and/or capability advertisements from= a > set of dCDNs. Footprint advertisement and capability advertisement need > not use the same underlying protocol. >=20 > I think we want to use the same protocol in order to avoid having another > layer of referencing between a footprint associated with a capability. I= think > we concluded that capability would be fairly static (e.g. HTTP) and the > footprint is more likely to change. They are intrinsically coupled even = if they > are coupled implicitly. JAN: I agree to a certain extent. It is indeed one thing that we have worke= d out and that has always come up: footprint and capabilities are tied toge= ther. Thus, it makes sense to use the same protocol to convey them, so that= they can be linked easily. However, this document is not about defining so= lutions, but only about the semantics and guidelines for solutions. So even= though in practice I agree with you, I am not sure the semantics document = should put the constraint on solutions of having only a single protocol for= footprint advertisement and capability advertisement. Any other opinions? > ... I would replace this whole section with a motivation for advertising= limited > coverage. JAN: Actually, I like the text in Section 3.1. because it gives a good intr= oduction into the problem space and what needs to be considered. Your text = describes how dCDNs may not want to advertise footprints where they cannot = guarantee good delivery quality, but the actual problem in my view is how t= o make sure that the dCDNs are consistent in where they draw the line on wh= at "good enough quality" is, or rather how the uCDN can distinguish that am= ong several dCDNs. Therefore I like your last paragraph "The quality of 'co= verage' and 'reach' may be somewhat subjective. It is incumbent upon the u= CDN to assess the relative quality of a dCDN; therefore, a dCDN should adve= rtise a footprint that is contextually consistent with the advertisements o= f any other dCDN." I suggest to add that text towards the end of Section 3.= 1. Any other opinions? > | 5. Towards Semantics for Footprint Advertisement >=20 > Two types of footprint may be advertised - topological and geographical. = A > topological advertisement describes the dCDN's footprint relative to it's > connectivity to the Internet using the BGP ASN attributes. A geographica= l > advertisement describes the dCDN's footprint relative to its coverage of = a > define location. >=20 > We might consider two models: >=20 > a. Topological Footprint (ASN) scoped by a geographical boundary (think o= f a > global ASN where CDN coverage is limited to a particular continent) >=20 > ASN <#>: FR, GE, UK, BE, ... >=20 > b. Geographical Footprint scoped by a set of topological boundaries (thin= k of > a continent where CDN coverage includes a set of ASN) >=20 > US: ASN <#1>, ASN <#2>, ... >=20 > If the FCI is intended to provide the temporary state of the negotiated > contract, either of the above could change over time. A dCDN that covers= an > ASN (by contract) could be expanded to include new countries. Likewise, = a > dCDN that covers a region (by contract) could be expanded to include new > ASN. >=20 > Should the FCI support one or the other of the above models? JAN: Sorry, but I am not sure I fully understand these models. Are they alt= ernatives or yet another dimension with respect to the models we have alrea= dy in the text ("coverage/reachability" vs. "resources"). Also, what is the= purpose of adding the connectivity dimension? To add something like a "sco= re" (see Section 3.1) for a geographical footprint? > | 6. Towards Semantics for Capabilities Advertisement >=20 > My experience has highlighted the fact that most of the base capabilities > must be configured (according to a negotiated contract) to facilitate > redirection. What seems relevant to me is where the footprint of a given > capability changes. Let's say uCDN has negotiated with dCDN to delivery > both HTTP and RTMP. At the time of service initialization, the RTMP foot= print > is smaller than the HTTP footprint; therefore, the capability should be > advertised and scoped according to a footprint. The default case might b= e > that HTTP and RTMP are configured (no capability advertisement required), > but that assumes both capabilities have global footprint. Not sure that = is > always the case. JAN: I fully agree with you. In fact, the main use case we are considering = (provided by Anne/Emile) is exactly about this case where a capability is n= ot globally available in a dCDN, and where (i.e. in which partial footprint= ) it is available may change over time.=20 > That is why I'm inclined to include a capability update which is scoped b= y a > footprint. I am not sure what you mean by that. The semantics draft is outlining what = capabilities are mandatory, but leaves it to solution proposals on how capa= bilities and footprint may be tied together. The section now contains the f= ollowing text on this: "For example, the dCDN might in general offer RTMP b= ut not in some specific areas, either for maintenance reasons or because th= e caches covering this particular area cannot deliver this type of service.= Hence, in certain cases footprint and capabilities are tied together and = cannot be interpreted independently from each other. In such cases, i.e. w= here capabilities must be expressed on a per footprint basis, it may be ben= eficial to combine footprint and capabilities advertisement." Is this text = not enough? > | 7. Open Issues and Questions >=20 > | o What is the service model of this interface:... > I'm inclined to say the dCDN advertises its capability and footprint to t= he > uCDN and periodically refreshes that advertisement. JAN: so you are saying "dCDN push to uCDN"? =20 > | o In addition to "reachability" types of footprint, ... >=20 > Not clear that a dCDN will want to advertise resource availability ... ju= st > service availability. JAN: this issue is actually solved. We agreed in Orlando to allow for optio= nal footprint types, while the mandatory one will be "coverage/reachability= " types of footprint. >=20 > | o Does a footprint need to explicitly include the "transitive" ... >=20 > I would think that the transitive dCDN MAY aggregate and represent a > concatenated footprint. =20 JAN: I agree. So no explicit information for the uCDN about transitive dCDN= s. Any other opinions? > | o How exactly can a give dCDN derive its footprint? >=20 > I would expect this to be configured. A dCDN might have a large footprin= t, > but only want to advertise to a uCDN a portion of its footprint in accord= ance > to a contract. JAN: So you are saying manual configuration, and manual re-configuration wh= en the footprint changes? >=20 > | o Should the footprint/capabilities advertisement interface only ... >=20 > I think the capability advertisement should be mandatory (e.g. HTTP | RTM= P > | RTSP) and it should conform to the contract. It SHOULD be scoped by > geography and/or topology where the absence of both footprint means > global coverage. JAN: the discussions we had are rather about signaling the whole dCDN state= each time, or just signaling what has changed since the last dCDN advertis= ement (delta). There are obvious pros and cons (e.g. signaling the full sta= te each time means larger messages, but provides better fault tolerance aga= inst lost messages). In my memory, we did not conclude on this issue. Opini= ons? Again, Many thanks for your comments, Scott! - Jan > -----Original Message----- > From: Scott Wainner [mailto:swainner@cisco.com] > Sent: Monday, April 29, 2013 5:50 PM > To: Jan Seedorf > Cc: cdni@ietf.org > Subject: Re: [CDNi] New Version Notification for draft-spp-cdni-rr-foot-c= ap- > semantics-04 >=20 > | 1. Introduction and scope >=20 > | o The uCDN has received footprint and/or capability advertisements from= a > set of dCDNs. Footprint advertisement and capability advertisement need > not use the same underlying protocol. >=20 > I think we want to use the same protocol in order to avoid having another > layer of referencing between a footprint associated with a capability. I= think > we concluded that capability would be fairly static (e.g. HTTP) and the > footprint is more likely to change. They are intrinsically coupled even = if they > are coupled implicitly. >=20 > | 2. CDNI FCI in existing CDNI Documents >=20 > | In the following section, the existing descriptions of the CDNI FCI int= erface > in existing documents will be examined. After this, the apparent common > understanding of what this interface is intended to offer and accomplishe= d > will be carved out. >=20 > Descriptions of the CDNI FCI interface are highlighted in the CDNI Proble= m > Statement [RFC6707], CDNI Use Cases [RFC6770], the CDNI draft > requirements [I-D. ietf-cdni-requirements], and the CDNI framework draft > [I-D ietf-cdni-framework]. An assessment of these descriptions is > highlighted in the subsequent sections where the ambiguity associated wit= h > footprint and capabilities is highlighted. The objective of this documen= t is to > clarify the meaning of footprint and capability and define the semantics = and > method for which these attributes are exchanged between two cooperating > CDN's. >=20 > | 3.1 >=20 > ... I would replace this whole section with a motivation for advertising= limited > coverage. >=20 > CDN's are built to minimize the cost of transport and optimize the > performance of content delivery across that transport. >=20 > A dCDN operator may elect to advertise only the footprint for which the C= DN > is optimized. While a dCDN might feasibly 'reach' a much larger footprin= t, the > operator of the dCDN has elected to narrow the scope of footprint to insu= re > that the CDN is only used for media delivery when clients are topological= ly or > geographically close. >=20 > A uCDN may have global coverage enabling media delivery anywhere on the > Internet; however, the uCDN may recognize that a specific dCDN has been > optimized for media delivery in a specific topological footprint or a spe= cific > geographic region. >=20 > The quality of 'coverage' and 'reach' may be somewhat subjective. It is > incumbent upon the uCDN to assess the relative quality of a dCDN; > therefore, a dCDN should advertise a footprint that is contextually consi= stent > with the advertisements of any other dCDN. >=20 > | 5. Towards Semantics for Footprint Advertisement >=20 > Two types of footprint may be advertised - topological and geographical. = A > topological advertisement describes the dCDN's footprint relative to it's > connectivity to the Internet using the BGP ASN attributes. A geographica= l > advertisement describes the dCDN's footprint relative to its coverage of = a > define location. >=20 > We might consider two models: >=20 > a. Topological Footprint (ASN) scoped by a geographical boundary (think o= f a > global ASN where CDN coverage is limited to a particular continent) >=20 > ASN <#>: FR, GE, UK, BE, ... >=20 > b. Geographical Footprint scoped by a set of topological boundaries (thin= k of > a continent where CDN coverage includes a set of ASN) >=20 > US: ASN <#1>, ASN <#2>, ... >=20 > If the FCI is intended to provide the temporary state of the negotiated > contract, either of the above could change over time. A dCDN that covers= an > ASN (by contract) could be expanded to include new countries. Likewise, = a > dCDN that covers a region (by contract) could be expanded to include new > ASN. >=20 > Should the FCI support one or the other of the above models? >=20 > | 6. Towards Semantics for Capabilities Advertisement >=20 > My experience has highlighted the fact that most of the base capabilities > must be configured (according to a negotiated contract) to facilitate > redirection. What seems relevant to me is where the footprint of a given > capability changes. Let's say uCDN has negotiated with dCDN to delivery > both HTTP and RTMP. At the time of service initialization, the RTMP foot= print > is smaller than the HTTP footprint; therefore, the capability should be > advertised and scoped according to a footprint. The default case might b= e > that HTTP and RTMP are configured (no capability advertisement required), > but that assumes both capabilities have global footprint. Not sure that = is > always the case. >=20 > That is why I'm inclined to include a capability update which is scoped b= y a > footprint. >=20 > | 7. Open Issues and Questions >=20 > | o What is the service model of this interface:... >=20 > I'm inclined to say the dCDN advertises its capability and footprint to t= he > uCDN and periodically refreshes that advertisement. >=20 > | o In addition to "reachability" types of footprint, ... >=20 > Not clear that a dCDN will want to advertise resource availability ... ju= st > service availability. >=20 > | o Does a footprint need to explicitly include the "transitive" ... >=20 > I would think that the transitive dCDN MAY aggregate and represent a > concatenated footprint. Alternatively, the dCDN MAY advertise a subset o= f > footprint to conform to a contract between the uCDN and the transitive CD= N. >=20 > | o How exactly can a give dCDN derive its footprint? >=20 > I would expect this to be configured. A dCDN might have a large footprin= t, > but only want to advertise to a uCDN a portion of its footprint in accord= ance > to a contract. >=20 > | o Should the footprint/capabilities advertisement interface only ... >=20 > I think the capability advertisement should be mandatory (e.g. HTTP | RTM= P > | RTSP) and it should conform to the contract. It SHOULD be scoped by > geography and/or topology where the absence of both footprint means > global coverage. >=20 >=20 > On 2/26/13 5:27 AM, Jan Seedorf wrote: >=20 >=20 > Dear all, >=20 > We have submitted a new version of the footprint/capabilities > semantics draft. We revised in particular the sections on what a footprin= t and > capabilities should actually look like, so that the document now reflects= the > latest agreements in the design team. Thanks to Kevin and Ray for their h= elp > with the revision. >=20 > Small note: we submitted yesterday the -03 version and shortly after > the -04 version, which only fixed minor things in the author's affiliatio= ns > compared to the -03 version. Just for people who were wondering how we > got from -02 to -04. >=20 > If you are interested in this, please join the phone call this afternoon= . > We also intend to update the WG during the CDNI sessions at the upcoming > IETF-86 in Orlando. >=20 > - Jan >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, February 25, 2013 5:13 PM > To: Jan Seedorf > Cc: kevin.ma@azukisystems.com; sprevidi@cisco.com; > jon.peterson@neustar.biz; ray.vanbrandenburg@tno.nl > Subject: New Version Notification for draft-spp-cdni-rr-foot-cap- > semantics-04.txt >=20 >=20 > A new version of I-D, draft-spp-cdni-rr-foot-cap-semantics-04.txt > has been successfully submitted by Jan Seedorf and posted to the > IETF repository. >=20 > Filename: draft-spp-cdni-rr-foot-cap-semantics > Revision: 04 > Title: CDNI Request Routing: Footprint and Capabilities > Semantics > Creation date: 2013-02-25 > Group: Individual Submission > Number of pages: 22 > URL: http://www.ietf.org/internet-drafts/draft-spp-cdni-rr- > foot-cap-semantics-04.txt > Status: http://datatracker.ietf.org/doc/draft-spp-cdni-rr-foot- > cap-semantics > Htmlized: http://tools.ietf.org/html/draft-spp-cdni-rr-foot-cap- > semantics-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-spp-cdni-rr-fo= ot- > cap-semantics-04 >=20 > Abstract: > This document tries to capture the semantics of the "Footprint and > Capabilities Advertisement" part of the CDNI Request Routing > interface, i.e. the desired meaning and what "Footprint and > Capabilities Advertisement" is expected to offer within CDNI. The > discussion in this document has the goal to facilitate the choosing > of one or more suitable protocols for "Footprint and Capabilities > Advertisement" within CDNI Request Routing. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > . >=20 >=20 From flefauch@cisco.com Thu Jul 11 03:28:35 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC8A21F9F5C for ; Thu, 11 Jul 2013 03:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XbzVI-9QPjK for ; Thu, 11 Jul 2013 03:28:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 17A0B21F9F59 for ; Thu, 11 Jul 2013 03:28:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=939; q=dns/txt; s=iport; t=1373538510; x=1374748110; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=et4zZDb7IMIzLsDXhM4cZDVjR+fcyhjjI+6Lex35iUM=; b=fY4jPgSf7EePYi9G3ZqgE4xvgWPVaWRqosLWGIo+/5J5PoBCldR1Ipq6 aHl6Rd0q8duS8pIOE5tAypbLNs7nt394KpfDoykmKbDkn90AsO3Ng9c0i c1E5vxmaA6n1n1mdhD4PvwHyxvo7MTDzG+ujDBcaSv15xWY2iI1n24A3B U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAIKI3lGtJV2c/2dsb2JhbABagwl/wVCBBhZ0giUBBDpRASoUQicEG4gHlnugO48wg0FsA6kkgxGCKA X-IronPort-AV: E=Sophos;i="4.87,1043,1363132800"; d="scan'208";a="233299560" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 11 Jul 2013 10:28:14 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6BASEln032059 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 11 Jul 2013 10:28:14 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Thu, 11 Jul 2013 05:28:14 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Consistent CDNI interface names Thread-Index: AQHOfiFZMFfZm5vuckOS3IAJyM7vgA== Date: Thu, 11 Jul 2013 10:28:13 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.201] Content-Type: text/plain; charset="us-ascii" Content-ID: <64BCE931AB6D414B91192DDF69D2D667@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Consistent CDNI interface names X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:28:36 -0000 Folks, There are slight variations across CDNI documents with respect to how they = refer to our CDNI interfaces (e.g. "interface" vs "Interface", "Capabilitie= s" vs "Capability", "and" vs "&" etc). As some of these documents are now = progressing through the publication process, we need to converge on exact n= ames. We propose that all documents use : * CDNI Control interface (CI) * CDNI Metadata interface (MI) * CDNI Logging interface (LI) * CDNI Request Routing Redirection interface (RI) * CDNI Footprint & Capabilities Advertisement interface (FCI) These are the names defined in RFC 6707, with one very minor correction, wh= ich is to use "Advertisement" instead of "advertisement" for consistent use= of capitalisation. Please let us know asap if you have comments on this. Once we have finalised the names, we will get all documents aligned to thes= e names. Cheers Francois & Daryl= From internet-drafts@ietf.org Fri Jul 12 04:47:07 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC53821F9F2B; Fri, 12 Jul 2013 04:47:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKISMMhq1crr; Fri, 12 Jul 2013 04:47:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B11221F9DC7; Fri, 12 Jul 2013 04:47:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130712114707.2936.83778.idtracker@ietfa.amsl.com> Date: Fri, 12 Jul 2013 04:47:07 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 11:47:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Logging Interface Author(s) : Francois Le Faucheur Gilles Bertrand Iuniana Oprescu Roy Peterkofsky Filename : draft-ietf-cdni-logging-05.txt Pages : 44 Date : 2013-07-12 Abstract: This memo specifies the Logging interface between a downstream CDN (dCDN) and an upstream CDN (uCDN) that are interconnected as per the CDN Interconnection (CDNI) framework. First, it describes a reference model for CDNI logging. Then, it specifies the CDNI Logging File format and the actual protocol for exchange of CDNI Logging Files. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-logging There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-logging-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Jan.Seedorf@neclab.eu Fri Jul 12 05:01:21 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC2721F9A18 for ; Fri, 12 Jul 2013 05:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.385 X-Spam-Level: X-Spam-Status: No, score=-103.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejvVgPKV6CJj for ; Fri, 12 Jul 2013 05:01:17 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 4A35821F9635 for ; Fri, 12 Jul 2013 05:01:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 74817104AD8; Fri, 12 Jul 2013 14:00:39 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESjpbpVRGPlH; Fri, 12 Jul 2013 14:00:39 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 553C6104ADC; Fri, 12 Jul 2013 14:00:24 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Fri, 12 Jul 2013 14:00:58 +0200 From: Jan Seedorf To: "Francois Le Faucheur (flefauch)" , "Daryl Malas (D.Malas@cablelabs.com)" Thread-Topic: CDNI Slot Requests for IETF-87 Thread-Index: AQHOe+UKavfDyHmh0U6jCZsuNkaCzZlg8wpw Date: Fri, 12 Jul 2013 11:59:20 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55589C41@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.5.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] CDNI Slot Requests for IETF-87 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 12:01:21 -0000 Dear Francois and Daryl, I have two slot requests: -- footprint/capabilities semantics (draft-ietf-cdni-footprint-capabilities= -semantics-00, was draft-spp-cdni-rr-foot-cap-semantics-04): we will post t= he -00 version of the now WG document on Monday. There are a few open issue= s, which I do not consider major, but some agenda time for WG discussion on= these issues would be appreciated so that we can come closer to finalizing= this document (suggestion: 20 minutes) -- ALTO for footprint/capabilities advertisement (draft-seedorf-cdni-reques= t-routing-alto-04, to be posted on Monday): the new version of the draft wi= ll revisit how ALTO could work as a solution for footprint/capabilities adv= ertisement in light of the latest conclusions from the footprint/capabiliti= es semantics design team which are outlined in the latest version of the se= mantics draft (suggestion: 10 minutes) - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Francois Le Faucheur (flefauch) > Sent: Monday, July 08, 2013 4:11 PM > To: cdni@ietf.org > Subject: [CDNi] CDNI Slot Requests for IETF-87 >=20 > Folks, >=20 > We will publish the draft CDNI WG agenda by 19 Jul, so please send your s= lot > requests to Daryl and I by 17 Jul. >=20 > Cheers >=20 > Francois & Daryl > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From internet-drafts@ietf.org Mon Jul 15 14:12:55 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E6B11E8205; Mon, 15 Jul 2013 14:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1XHjD18eeJN1; Mon, 15 Jul 2013 14:12:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA5211E815E; Mon, 15 Jul 2013 14:12:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130715211254.20113.85966.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 14:12:54 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-metadata-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 21:12:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDN Interconnect Metadata Author(s) : Ben Niven-Jenkins Rob Murray Grant Watson Matt Caulfield Kent Leung Kevin J. Ma Filename : draft-ietf-cdni-metadata-02.txt Pages : 43 Date : 2013-07-15 Abstract: The CDNI Metadata Interface enables interconnected CDNs to exchange content distribution metadata in order to enable content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN. This document describes both the core set of CDNI metadata and the protocol for exchanging that metadata. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-metadata There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-metadata-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-metadata-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Jan.Seedorf@neclab.eu Tue Jul 16 01:43:06 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C88F21F8BB7 for ; Tue, 16 Jul 2013 01:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3xbO2ZLPwkqX for ; Tue, 16 Jul 2013 01:43:02 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 08F3B21F88DB for ; Tue, 16 Jul 2013 01:43:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 4B91A104B51 for ; Tue, 16 Jul 2013 10:42:24 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hWw4cdAzk6i for ; Tue, 16 Jul 2013 10:42:24 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 2C81A1049D8 for ; Tue, 16 Jul 2013 10:42:19 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Tue, 16 Jul 2013 10:42:34 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-seedorf-cdni-request-routing-alto-04.txt Thread-Index: AQHOgW+vt3M78QCcnkmPIl6tv5IaMZlm/Wow Date: Tue, 16 Jul 2013 08:41:24 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5558D028@DAPHNIS.office.hd> References: <20130715152620.5664.97237.idtracker@ietfa.amsl.com> In-Reply-To: <20130715152620.5664.97237.idtracker@ietfa.amsl.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.5.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-04.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 08:43:06 -0000 SGkgYWxsLA0KDQpJIGhhdmUgc3VibWl0dGVkIGEgcmV2aXNpb24gb2YgdGhlIGRyYWZ0IHRoYXQg b3V0bGluZXMgaG93IEFMVE8gY2FuIGJlIGEgc29sdXRpb24gcHJvdG9jb2wgZm9yIHRoZSBDRE5J IEZDSS4gVGhlIGxhdGVzdCB2ZXJzaW9uIGhhcyBiZWVuIGNoYW5nZWQgcXVpdGUgYSBiaXQ7IGl0 IHJlLXZpc2l0cyB0aGUgbGF0ZXN0IGNvbmNsdXNpb25zIGluIHRoZSBGQ0kgZGVzaWduIHRlYW0s IGFuZCBkZXNjcmliZXMgaG93IEFMVE8gY291bGQgYmUgdXNlZCB0byBhZHZlcnRpc2UgdGhlIHR5 cGVzIG9mIGZvb3RwcmludCBhbmQgY2FwYWJpbGl0aWVzIHRoYXQgYXJlIGNvbnNpZGVyZWQgYXMg bWFuZGF0b3J5IGJ5IHRoZSBkZXNpZ24gdGVhbS4NCg0KIC0gSmFuDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdWx5IDE1LCAyMDEzIDU6MjYg UE0NClRvOiBKYW4gU2VlZG9yZg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1zZWVkb3JmLWNkbmktcmVxdWVzdC1yb3V0aW5nLWFsdG8tMDQudHh0DQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LXNlZWRvcmYtY2RuaS1yZXF1ZXN0LXJvdXRpbmctYWx0 by0wNC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSmFuIFNlZWRvcmYg YW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1z ZWVkb3JmLWNkbmktcmVxdWVzdC1yb3V0aW5nLWFsdG8NClJldmlzaW9uOgkgMDQNClRpdGxlOgkJ IENETkkgUmVxdWVzdCBSb3V0aW5nIHdpdGggQUxUTw0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDct MTUNCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNQ0K VVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1zZWVkb3JmLWNkbmktcmVxdWVzdC1yb3V0aW5nLWFsdG8tMDQudHh0DQpTdGF0dXM6ICAgICAg ICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc2VlZG9yZi1jZG5pLXJl cXVlc3Qtcm91dGluZy1hbHRvDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNlZWRvcmYtY2RuaS1yZXF1ZXN0LXJvdXRpbmctYWx0by0wNA0KRGlmZjog ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1zZWVkb3Jm LWNkbmktcmVxdWVzdC1yb3V0aW5nLWFsdG8tMDQNCg0KQWJzdHJhY3Q6DQogICBOZXR3b3JrIFNl cnZpY2UgUHJvdmlkZXJzIChOU1BzKSBhcmUgY3VycmVudGx5IGNvbnNpZGVyaW5nIHRvIGRlcGxv eQ0KICAgQ29udGVudCBEZWxpdmVyeSBOZXR3b3JrcyAoQ0ROcykgd2l0aGluIHRoZWlyIG5ldHdv cmtzLiAgQXMgYQ0KICAgY29uc2VxdWVuY2Ugb2YgdGhpcyBkZXZlbG9wbWVudCwgdGhlcmUgaXMg YSBuZWVkIGZvciBpbnRlcmNvbm5lY3RpbmcNCiAgIHRoZXNlIGxvY2FsIENETnMuICBUaGUgbmVj ZXNzYXJ5IGludGVyZmFjZXMgZm9yIGludGVyLWNvbm5lY3RpbmcgQ0ROcw0KICAgYXJlIGN1cnJl bnRseSBiZWluZyBkZWZpbmVkIGluIHRoZSBDb250ZW50IERlbGl2ZXJ5IE5ldHdvcmtzDQogICBJ bnRlcmNvbm5lY3Rpb24gKENETkkpIFdHLiAgVGhpcyBkb2N1bWVudCBmb2N1c2VzIG9uIHRoZSBD RE5JDQogICBGb290cHJpbnQgJiBDYXBhYmlsaXRpZXMgQWR2ZXJ0aXNlbWVudCBpbnRlcmZhY2Ug KEZDSSkuDQogICBTcGVjaWZpY2FsbHksIHRoaXMgZG9jdW1lbnQgb3V0bGluZXMgaG93IHRoZSBz b2x1dGlvbnMgY3VycmVudGx5DQogICBiZWluZyBkZWZpbmVkIGluIHRoZSBBcHBsaWNhdGlvbiBM YXllciBUcmFmZmljIE9wdGltaXphdGlvbiAoQUxUTykgV0cNCiAgIGNhbiBmYWNpbGl0YXRlIEZv b3RwcmludCAmIENhcGFiaWxpdGllcyBBZHZlcnRpc2VtZW50IGluIGEgQ0ROSQ0KICAgY29udGV4 dCwgaS5lLiBob3cgdGhlIENETkkgRkNJIGNhbiBiZSByZWFsaXNlZCB3aXRoIHRoZSBBTFRPDQog ICBwcm90b2NvbC4gIENvbmNyZXRlIGV4YW1wbGVzIG9mIGhvdyBBTFRPIGNhbiBiZSBpbnRlZ3Jh dGVkIHdpdGhpbg0KICAgQ0ROSSByZXF1ZXN0IHJvdXRpbmcgYW5kIGluIHBhcnRpY3VsYXIgaW4g dGhlIHByb2Nlc3Mgb2Ygc2VsZWN0aW5nIGENCiAgIGRvd25zdHJlYW0gQ0ROIGFyZSBnaXZlbi4g IFRoZSBleGFtcGxlcyBpbiB0aGlzIGRvY3VtZW50IGFyZSBiYXNlZCBvbg0KICAgdGhlIHVzZSBj YXNlcyBhbmQgZXhhbXBsZXMgY3VycmVudGx5IGJlaW5nIGRpc2N1c3NlZCBpbiB0aGUgQ0ROSSBX Ry4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0 DQoNCg== From georgios@net.t-labs.tu-berlin.de Tue Jul 16 01:54:55 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD89D11E826D for ; Tue, 16 Jul 2013 01:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zc7DCOrNtOiT for ; Tue, 16 Jul 2013 01:54:55 -0700 (PDT) Received: from mail.net.t-labs.tu-berlin.de (mail.net.t-labs.tu-berlin.de [IPv6:2001:470:96b9:4:130:149:220:252]) by ietfa.amsl.com (Postfix) with ESMTP id 0019511E826B for ; Tue, 16 Jul 2013 01:54:54 -0700 (PDT) Received: from [2001:470:96b9:1:6064:9770:b25c:dd90] (unknown [IPv6:2001:470:96b9:1:6064:9770:b25c:dd90]) by mail.net.t-labs.tu-berlin.de (Postfix) with ESMTPSA id 6CDA14C64E4 for ; Tue, 16 Jul 2013 10:54:53 +0200 (CEST) Date: Tue, 16 Jul 2013 10:54:51 +0200 (CEST) From: Georgios Smaragdakis To: cdni@ietf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [CDNi] Enabling CDN-ISP Collaboration X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 08:54:55 -0000 Dear all, - In T-Labs/TU Berlin we maintain a website with all our research activities on CDN-ISP collaboration that are very related to CDNi working group objectives: http://www.smaragdakis.net/research/Collaboration - For the most recent document on CDN-ISP collaboration and Network Function Virtualization please see our paper that appears in ACM SIGCOMM CCR July 2013 issue: "Pushing CDN-ISP Collaboration to the Limit" http://www.smaragdakis.net/publications/CCR-NetPaaS best regards, --George ---------------------------------- Georgios Smaragdakis, Senior Researcher Deutsche Telekom Laboratories Technical University of Berlin http://www.smaragdakis.net From swainner@cisco.com Tue Jul 16 11:31:07 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C2711E80F1 for ; Tue, 16 Jul 2013 11:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uE643lMKlBN for ; Tue, 16 Jul 2013 11:31:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 68E5A11E80ED for ; Tue, 16 Jul 2013 11:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6181; q=dns/txt; s=iport; t=1373999460; x=1375209060; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=vdVD5/T7idISR6w3p9/6PgCb1lvfMg3BtWdth6uDrKE=; b=dhhvIvmqXqAfn0XedDiq/kQkLn+XLVEdXmorDWfqcRlKeg3hKdkkBJ6C WB6xj7ex0vNQBBTzK2D+BTgXQ4hm9Gja1+Rqwt/0/4lB4EsybQ062DXgx dL/rnRLIIAGstOTCKQY198ibm8CdHXeccoDr/Yz1tvnWvg1HQuvyuJiMn A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAIKQ5VGtJXHA/2dsb2JhbABagwY0ScF6gREWdIIjAQEBBAEBATU2CQENBAsRBAEBAQkWCAcJAwIBAgEVHwgBCBMGAgEBBYgHBwW1d49mBoNzA5dcgSmQJIMuIIEuJA X-IronPort-AV: E=Sophos;i="4.89,678,1367971200"; d="scan'208";a="232561797" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 16 Jul 2013 18:30:59 +0000 Received: from rtp-swainner-8919.cisco.com (rtp-swainner-8919.cisco.com [10.116.109.202]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6GIUxii005584 for ; Tue, 16 Jul 2013 18:30:59 GMT Message-ID: <51E59162.2030909@cisco.com> Date: Tue, 16 Jul 2013 14:30:58 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cdni@ietf.org References: <20130531152617.26809.88399.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 18:31:07 -0000 Kent, Some comments and thoughts ... Scott 2. Signed URI Format o Enforcement Attributes: Attributes that are used to enforce a distribution policy defined by the CSP. Examples of enforcement attributes are IP address of the UA and time window. sw> We need to clarify if this is the IP address assigned to the client (often a 192.168.0.x address) or the public IP address presented to the system (i.e. post NAT'd). I presume the latter. 2.1 Enforcement Attributes o Client IP (CIP) [optional] - IP address of the client for which this signed URI is generated. This is represented in dotted decimal format for IPv4 or canonical text representation for IPv6 address [RFC5952] . The request is rejected if sourced from a client with a different IP address. sw> We need to clarify if this is the IP address assigned to the client or the IP address representing the client's public appearance on the Internet. I presume the latter; the CSP will see the public IP address. 2.2. Signature Computation Attributes o Hash Function (HF) [optional] - A string used for identifying the hash function to compute the URI signature (e.g. "MD5", "SHA1") with HMAC. sw> Should we not define a mandatory set of methods? MD5, SHA-1, SHA-256? 3. Signing a URI 9. Depending on the type of key used to sign the URI, compute the message digest or digital signature for symmetric key or asymmetric keys, respectively. A. For symmetric key, HMAC is used. j. Append the string for the message digest (e.g. ":// example.com/ content.mov?VER=1&ET=1209422976&CIP=10.0.0.1& KID=example:keys:123&HF=SHA-1& MD=4fb1c1adf1588fbe11cc6a04c6e69f35"). sw> This example assumes there were no previously defined query string parameters. We need to specify exactly what is provided as input into the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do we include previously define query string parameters that existing on the URL or only the path. I find that clients may need to include query strings to facilitate CDN selection or bias decisions. If the client inserts a query string and that portion is validated by the HMAC, then the client will invalidate the signature. Perhaps this is motivation for using the tokenized method. The client can insert query strings in front of the token query parameter without invalidating the URL. 4. Validating a URI Signature 4. Extract the value from "CIP" attribute if the attribute exists. Validate that the request came from the same IP address as indicated in the "CIP" attribute. If the IP address is incorrect, then the request is denied. sw> Sounds like we're using the IP address presented by the client and not the IP address assigned to the client. 4. Validating a URI Signature 8. If neither "MD" or "DS" attribute is in the URI, then no URI sw> This implies that URL Signing is required. Presumably, we can configure the system such that we know if incoming URL's should or should not be signed. What is the criteria and how do we determine if the criteria is met? 5.3. CDNI Metadata Interface o Content access control indication. sw> Is the access control defined on a per object request (manifest / segment) or class of service request? A class of service request (e.g. http://service_path/media_path/media?foo) might indicate ALL media objects associated with the "://service_path/" require access control. How do we define the scope of access control for URL signing? o Encoding format to override the "UST" attribute. (Editor Note: Is this needed in CDNI Metadata or defined in a new CDNI attribute?) sw> What is implied by the statement 'override'. Presumably, the UST can be transparently passed from surrogate to surrogate even while the domain, path, and query parameters (outside of the UST) are changed. That is because the UST contains the validated attributes. On 5/31/13 11:35 AM, Kent Leung (kleung) wrote: > Hi folks. We've made some updates based on the WG feedback and internal discussions. Comments are welcome. Thanks. > > Kent > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, May 31, 2013 8:26 AM > To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung); Francois Le Faucheur (flefauch); Bill Downey > Subject: New Version Notification for draft-leung-cdni-uri-signing-02.txt > > > A new version of I-D, draft-leung-cdni-uri-signing-02.txt > has been successfully submitted by Kent Leung and posted to the IETF repository. > > Filename: draft-leung-cdni-uri-signing > Revision: 02 > Title: URI Signing for CDN Interconnection (CDNI) > Creation date: 2013-05-31 > Group: Individual Submission > Number of pages: 29 > URL: http://www.ietf.org/internet-drafts/draft-leung-cdni-uri-signing-02.txt > Status: http://datatracker.ietf.org/doc/draft-leung-cdni-uri-signing > Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri-signing-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-leung-cdni-uri-signing-02 > > Abstract: > This document describes how the concept of URI signing supports the > content access control requirements of CDNI and proposes a candidate > 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 request for the content referenced by the URI. Some > of the information may be accessed by the CDN via configuration or > CDNI metadata. > > > > > The IETF Secretariat > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > From kleung@cisco.com Tue Jul 16 20:29:13 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCB6121F9951 for ; Tue, 16 Jul 2013 20:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sa2kShWb884 for ; Tue, 16 Jul 2013 20:29:08 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5B321F98AD for ; Tue, 16 Jul 2013 20:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8398; q=dns/txt; s=iport; t=1374031748; x=1375241348; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xGwoBgU3MDGXQ2F8WeUetv24qiGa7zrwEiNgSHgkp6Q=; b=Nyl2M5xgLRgq/5d0jdmOodz7k4NslGCaLa/3HzGGN5+14Jk8xt12A542 C4QtJvfebRtG2deQOzmxVhwKRX/KKZS2Me9jNWJeuU10VefipQzZDWAeG +3gxkh4j3p8OzQ28DRHIjVww6AYwAu5bFiYL/iNLDfTRE1YvKwkEB0ss1 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAHoO5lGtJXG9/2dsb2JhbABagwY0SQbCK4ENFnSCIwEBAQQBAQE3NAkOBAIBCBEEAQEBChQJBycLFAgBCAIEARIIAYgHBwW1UY89OAaDBm4DmQWQJIMSgWokGg X-IronPort-AV: E=Sophos;i="4.89,682,1367971200"; d="scan'208";a="235717179" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 17 Jul 2013 03:29:07 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6H3T7Rh016921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Jul 2013 03:29:07 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Tue, 16 Jul 2013 22:29:07 -0500 From: "Kent Leung (kleung)" To: "Scott Wainner (swainner)" , "cdni@ietf.org" Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt Thread-Index: AQHOglKtSpQ+c/DHq0CQax3bMEcDKJloK3IA Date: Wed, 17 Jul 2013 03:29:06 +0000 Message-ID: References: <20130531152617.26809.88399.idtracker@ietfa.amsl.com> <51E59162.2030909@cisco.com> In-Reply-To: <51E59162.2030909@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 03:29:14 -0000 Hi Scott. Thanks for the feedback. See my comments below. -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of Sco= tt Wainner (swainner) Sent: Tuesday, July 16, 2013 11:31 AM To: cdni@ietf.org Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-s= igning-02.txt Kent, Some comments and thoughts ... Scott 2. Signed URI Format o Enforcement Attributes: Attributes that are used to enforce a distribution policy defined by the CSP. Examples of enforcement attributes are IP address of the UA and time window. sw> We need to clarify if this is the IP address assigned to the client (often a 192.168.0.x address) or the public IP address presented to the sys= tem (i.e. post NAT'd). I presume the latter. KL> The IP address is the IP address in the IP header of the HTTP request m= essage as seen by the CDN. We can add some clarification if needed. 2.1 Enforcement Attributes o Client IP (CIP) [optional] - IP address of the client for which this signed URI is generated. This is represented in dotted decimal format for IPv4 or canonical text representation for IPv6 address [RFC5952] . The request is rejected if sourced from a client with a different IP address. sw> We need to clarify if this is the IP address assigned to the client=20 or the IP address representing the client's public appearance on the=20 Internet. I presume the latter; the CSP will see the public IP address. KL> See previous comment. 2.2. Signature Computation Attributes o Hash Function (HF) [optional] - A string used for identifying the hash function to compute the URI signature (e.g. "MD5", "SHA1") with HMAC. sw> Should we not define a mandatory set of methods? MD5, SHA-1, SHA-256? KL> I'm open to suggestions. We need to consider current deployments. One = reason for being optional is that the hash function may be obtained via CDN= I metadata. As for the mandatory hash functions that need to be supported, = I think MD5 and SHA1 can be good candidates. 3. Signing a URI 9. Depending on the type of key used to sign the URI, compute the message digest or digital signature for symmetric key or asymmetric keys, respectively. A. For symmetric key, HMAC is used. j. Append the string for the message digest (e.g. ":// example.com/ content.mov?VER=3D1&ET=3D1209422976&CIP=3D10.0.0.1& KID=3Dexample:keys:123&HF=3DSHA-1& MD=3D4fb1c1adf1588fbe11cc6a04c6e69f35"). sw> This example assumes there were no previously defined query string=20 parameters. We need to specify exactly what is provided as input into=20 the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do we=20 include previously define query string parameters that existing on the=20 URL or only the path. I find that clients may need to include query=20 strings to facilitate CDN selection or bias decisions. If the client=20 inserts a query string and that portion is validated by the HMAC, then=20 the client will invalidate the signature. Perhaps this is motivation=20 for using the tokenized method. The client can insert query strings in=20 front of the token query parameter without invalidating the URL. KL> This is an example, which is used to keep it simple. Step #2 covers the= procedure to include existing query string. Does that answer your question= ? 4. Validating a URI Signature 4. Extract the value from "CIP" attribute if the attribute exists. Validate that the request came from the same IP address as indicated in the "CIP" attribute. If the IP address is incorrect, then the request is denied. sw> Sounds like we're using the IP address presented by the client and=20 not the IP address assigned to the client. KL> Yes, as mentioned in previous comment. 4. Validating a URI Signature 8. If neither "MD" or "DS" attribute is in the URI, then no URI sw> This implies that URL Signing is required. Presumably, we can=20 configure the system such that we know if incoming URL's should or=20 should not be signed. What is the criteria and how do we determine if=20 the criteria is met? KL> When URL Signing is configured to be validated, then these attributes n= eed to be in the URI. Yes, it's possible that URI Signing is configured. = I had put this under the CDNI Metadata Interface. See below o Type of access control. Specifically, access to content is subject to URI Signing. URI Signing required indication means Downstream CDN ensures URI must be signed and validated before content delivery. Otherwise, Downstream CDN does not perform validation regardless if URI is signed or not. I guess we can say that this can be "set by configuration or CDNI metadata"= as noted in other areas.=20 5.3. CDNI Metadata Interface o Content access control indication. sw> Is the access control defined on a per object request (manifest /=20 segment) or class of service request? A class of service request (e.g.=20 http://service_path/media_path/media?foo) might indicate ALL media=20 objects associated with the "://service_path/" require access control. =20 How do we define the scope of access control for URL signing? KL> I assume that the access control scope is based on the scope of the met= adata. So it can be for a specific content or a group of content.=20 o Encoding format to override the "UST" attribute. (Editor Note: Is this needed in CDNI Metadata or defined in a new CDNI attribute?) sw> What is implied by the statement 'override'. Presumably, the UST=20 can be transparently passed from surrogate to surrogate even while the=20 domain, path, and query parameters (outside of the UST) are changed. =20 That is because the UST contains the validated attributes. KL> The override is meant to use another attribute name instead of "UST" to= carry the URI Signing token value. Just a method to provide flexibility on= the attribute name. Kent On 5/31/13 11:35 AM, Kent Leung (kleung) wrote: > Hi folks. We've made some updates based on the WG feedback and internal = discussions. Comments are welcome. Thanks. > > Kent > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, May 31, 2013 8:26 AM > To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung); Francois Le= Faucheur (flefauch); Bill Downey > Subject: New Version Notification for draft-leung-cdni-uri-signing-02.txt > > > A new version of I-D, draft-leung-cdni-uri-signing-02.txt > has been successfully submitted by Kent Leung and posted to the IETF repo= sitory. > > Filename: draft-leung-cdni-uri-signing > Revision: 02 > Title: URI Signing for CDN Interconnection (CDNI) > Creation date: 2013-05-31 > Group: Individual Submission > Number of pages: 29 > URL: http://www.ietf.org/internet-drafts/draft-leung-cdni-uri= -signing-02.txt > Status: http://datatracker.ietf.org/doc/draft-leung-cdni-uri-sig= ning > Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri-signing-= 02 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni-uri-= signing-02 > > Abstract: > This document describes how the concept of URI signing supports the > content access control requirements of CDNI and proposes a candidate > 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 request for the content referenced by the URI. Some > of the information may be accessed by the CDN via configuration or > CDNI metadata. > > = =20 > > > The IETF Secretariat > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From internet-drafts@ietf.org Wed Jul 17 11:58:06 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0701E21F9E89; Wed, 17 Jul 2013 11:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40v7dEPEqb6x; Wed, 17 Jul 2013 11:58:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 06BAD21F9A8E; Wed, 17 Jul 2013 11:58:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.53 Message-ID: <20130717185803.8253.90561.idtracker@ietfa.amsl.com> Date: Wed, 17 Jul 2013 11:58:03 -0700 Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:58:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Request Routing: Footprint and Capabilities Semanti= cs Author(s) : Jan Seedorf Jon Peterson Stefano Previdi Ray van Brandenburg Kevin J. Ma Filename : draft-ietf-cdni-footprint-capabilities-semantics-00.txt Pages : 18 Date : 2013-07-15 Abstract: This document tries to capture the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e. the desired meaning and what "Footprint and Capabilities Advertisement" is expected to offer within CDNI. The discussion in this document has the goal to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisement" within CDNI Request Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-sem= antics There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics= -00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From choits@etri.re.kr Wed Jul 17 18:29:58 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D960B21F8BB7 for ; Wed, 17 Jul 2013 18:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.9 X-Spam-Level: X-Spam-Status: No, score=-100.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_RAND_LETTRS4=0.799, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zENTLVOcJD3M for ; Wed, 17 Jul 2013 18:29:53 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 60DD921F95EF for ; Wed, 17 Jul 2013 18:29:49 -0700 (PDT) Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 18 Jul 2013 10:29:46 +0900 Received: from SMTP1.etri.info ([169.254.1.31]) by SMTP2.etri.info ([169.254.2.217]) with mapi id 14.01.0355.002; Thu, 18 Jul 2013 10:29:43 +0900 From: =?utf-8?B?7LWc7YOc7IOB?= To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-choi-cdni-req-intf-00.txt Thread-Index: AQHOf88YoIPj6ZDwK0yGDjM2eSg5Eplpqulw Date: Thu, 18 Jul 2013 01:29:43 +0000 Message-ID: References: <20130713134425.25968.39260.idtracker@ietfa.amsl.com> In-Reply-To: <20130713134425.25968.39260.idtracker@ietfa.amsl.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.0.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-choi-cdni-req-intf-00.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 01:29:58 -0000 SGkgYWxsLA0KDQpJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRoYXQgcHJvcG9zZXMgYSBu ZXcgQ0ROaSBpbnRlcmZhY2UsIGNhbGxlZCAiUmVxdWVzdCBJbnRlcmZhY2UiLiAgRHVyaW5nIGxh c3QgODZ0aCBJRVRGIG1lZXRpbmcsIHdlIGRpc2N1c3NlZCBicmllZmx5IGFib3V0IHRoZSBwb3Rl bnRpYWwgbmVjZXNzaXR5KGFsdGhvdWdoIGl0IGlzIG91dCBvZiBzY29wZSBpbiB0aGUgY3VycmVu dCBjaGFydGVyKSBvZiBzdWNoIGFuIGludGVyZmFjZSBiZXR3ZWVuIGFuIGVuZC11c2VyIGFuZCBh IENETiBwcm92aWRlciAoZWl0aGVyIHVDRE4gb3IgZENETil0byBzdXBwb3J0IGl0ZXJhdGl2ZSBy ZXF1ZXN0IHJvdXRpbmcgcmVkaXJlY3Rpb24gYW5kIFVSSSBzaWduaW5nLiAgVGhlIGRyYWZ0IG91 dGxpbmVzIHN1Y2ggYW4gaW50ZXJmYWNlIHdpdGggYSBmZXcgdXNlIGNhc2VzLiAgSW4gYWRkaXRp b24sIGl0IGFsc28gcHJvcG9zZXMgYSBuZXcgbWVjaGFuaXNtIHRvIGVuaGFuY2UgYXZhaWxhYmls aXR5IG9mIENETiBzZXJ2aWNlcyBieSBpbnRyb2R1Y2luZyBtdXRsaS1sb2NhdGlvbiByZXR1cm4g Zm9yIHJlZGlyZWN0aW9uIGNhbmRpZGF0ZXMuICBBbnkgY29tbWVudHMgYXJlIGFwcHJlY2lhdGVk Lg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU2F0dXJk YXksIEp1bHkgMTMsIDIwMTMgMTA6NDQgUE0NClRvOiBKb2huIERvbmdobyBTaGlubjsgSm9uZ21p biBMZWU7IFlvdW5nLUlMIFNlbzsgWW91bmctSWwgU2VvOyBKYS1SeWVvbmcgS29vOyBEb25nLUp1 IEtpbTsg7LWc7YOc7IOBOyBLVCBOZXR3b3JrIFImRCBMYWJvcmF0b3J5OyBKdW5lLWtvbyBSaGVl DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWNob2ktY2RuaS1y ZXEtaW50Zi0wMC50eHQNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jaG9pLWNk bmktcmVxLWludGYtMDAudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGFl c2FuZyBDaG9pIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC1jaG9pLWNkbmktcmVxLWludGYNClJldmlzaW9uOgkgMDANClRpdGxlOgkJIFJlcXVl c3QgSW50ZXJmYWNlIGZvciBDRE4gSW50ZXJjb25uZWN0aW9uDQpDcmVhdGlvbiBkYXRlOgkgMjAx My0wNy0xMw0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6 IDE4DQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz L2RyYWZ0LWNob2ktY2RuaS1yZXEtaW50Zi0wMC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1jaG9pLWNkbmktcmVxLWludGYNCkh0bWxp emVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hvaS1jZG5pLXJl cS1pbnRmLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0aGUg cmVxdWVzdCBpbnRlcmZhY2UgYmV0d2VlbiBhIENETiBlbmQtdXNlcg0KICAgYW5kIGFuIHVwc3Ry ZWFtIENETiBvciBkb3duc3RyZWFtIENETiB0byByZXF1ZXN0IENETiByZXF1ZXN0IHJvdXRpbmcN CiAgIHJlZGlyZWN0aW9uIG9yIFVSSSBzaWduaW5nLiAgSXQgc3BlY2lmaWVzIHRoZSBDRE5JIFJl cXVlc3QgSW50ZXJmYWNlDQogICBpbmZvcm1hdGlvbiBlbGVtZW50cyBhbmQgdGhlIGFjdHVhbCBw cm90b2NvbCBmb3IgZXhjaGFuZ2luZyB0aGVtLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg DQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From choits@etri.re.kr Wed Jul 17 18:42:59 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A03821F8947 for ; Wed, 17 Jul 2013 18:42:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.6 X-Spam-Level: X-Spam-Status: No, score=-101.6 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5+-Jck48vd+K for ; Wed, 17 Jul 2013 18:42:54 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg2.etri.re.kr [129.254.27.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD5121F92C2 for ; Wed, 17 Jul 2013 18:42:48 -0700 (PDT) Received: from SMTP2.etri.info (129.254.28.72) by SMTPEG2.etri.info (129.254.27.142) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 18 Jul 2013 10:42:47 +0900 Received: from SMTP1.etri.info ([169.254.1.31]) by SMTP2.etri.info ([169.254.2.217]) with mapi id 14.01.0355.002; Thu, 18 Jul 2013 10:42:45 +0900 From: =?utf-8?B?7LWc7YOc7IOB?= To: "cdni@ietf.org" Thread-Topic: New Version Notification for draft-choi-cdni-control-init-bootstrapping-01.txt Thread-Index: AQHOgW2dwcm3b4FwgEqEETPVMx9waZlpqcvg Date: Thu, 18 Jul 2013 01:42:44 +0000 Message-ID: References: <20130715151132.5677.99226.idtracker@ietfa.amsl.com> In-Reply-To: <20130715151132.5677.99226.idtracker@ietfa.amsl.com> Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.0.137] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [CDNi] FW: New Version Notification for draft-choi-cdni-control-init-bootstrapping-01.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 01:42:59 -0000 RGVhciBhbGwsDQoNCkkgaGF2ZSBzdWJtaXR0ZWQgYSByZXZpc2lvbiBvZiB0aGUgYm9vdHN0cmFw cGluZyBjb250cm9sIGludGVyZmFjZSBkcmFmdC4gSW4gdGhpcyByZXZpc2lvbiwgd2UgYWRkZWQg YSBmZXcgbW9yZSBhY3Rpb25zIHN1Y2ggYXMgImRpc2NvdmVyIiwgYW5kICJuZWdvdGlhdGUiLiAg V2UgYWxzbyBhZGRlZCBleGFtcGxlIHByb2NlZHVyZXMgZm9yIHRoZSBhZGRlZCBhY3Rpb25zLiBB bnkgY29tbWVudHMgd2lsbCBiZSBhcHByZWNpYXRlZC4NCg0KQmVzdCByZWdhcmRzLA0KDQpUYWVz YW5nDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNlbnQ6IFR1 ZXNkYXksIEp1bHkgMTYsIDIwMTMgMTI6MTIgQU0NClRvOiBKb2huIERvbmdobyBTaGlubjsgSm9u Z21pbiBMZWU7IFlvdW5nLUlsIFNlbzsgWW91bmctSUwgU2VvOyBKYS1SeWVvbmcgS29vOyDstZzt g5zsg4ENClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtY2hvaS1j ZG5pLWNvbnRyb2wtaW5pdC1ib290c3RyYXBwaW5nLTAxLnR4dA0KDQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWNob2ktY2RuaS1jb250cm9sLWluaXQtYm9vdHN0cmFwcGluZy0wMS50 eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVGFlc2FuZyBDaG9pIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1jaG9pLWNk bmktY29udHJvbC1pbml0LWJvb3RzdHJhcHBpbmcNClJldmlzaW9uOgkgMDENClRpdGxlOgkJIENE TmkgQ29udHJvbCAtIEluaXRpYWxpemF0aW9uIGFuZCBCb290c3RyYXBwaW5nDQpDcmVhdGlvbiBk YXRlOgkgMjAxMy0wNy0xNQ0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpOdW1iZXIg b2YgcGFnZXM6IDIwDQpVUkw6ICAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWNob2ktY2RuaS1jb250cm9sLWluaXQtYm9vdHN0cmFwcGluZy0wMS50 eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1jaG9pLWNkbmktY29udHJvbC1pbml0LWJvb3RzdHJhcHBpbmcNCkh0bWxpemVkOiAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2hvaS1jZG5pLWNvbnRyb2wtaW5pdC1i b290c3RyYXBwaW5nLTAxDQpEaWZmOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWNob2ktY2RuaS1jb250cm9sLWluaXQtYm9vdHN0cmFwcGluZy0wMQ0K DQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvcG9zZXMgYSBtZWNoYW5pc20gZm9yIGEg Q0ROIHRvIGluaXRpYXRlIHRoZQ0KICAgaW50ZXJjb25uZWN0aW9uIGFjcm9zcyBDRE5zIGFuZCBi b290c3RyYXAgdGhlIG90aGVyIENETmkgaW50ZXJmYWNlcy4NCg0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From flefauch@cisco.com Thu Jul 18 06:23:59 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02D021F89C3 for ; Thu, 18 Jul 2013 06:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLgQSq+Seyhj for ; Thu, 18 Jul 2013 06:23:55 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 59A4D21E80F1 for ; Thu, 18 Jul 2013 06:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1691; q=dns/txt; s=iport; t=1374153835; x=1375363435; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=QWCrhCZS0jl3dAl3bgPcZvHm9ywzG/PsmGDIPhngXLs=; b=kf/GmX/C4feD2KSTfdAx7tX6tKvMGEcEFqTjrF4dSliJJgja+pPq0jeu uP74qKqTEj5dFR6W/tlB2k1auBp6fTKi16hnt/nQEsKmTJn7xmrw/4Iqp MlkMiviFvMQ2EVYCo+JaI5ZaHAyIHrs/ZxhM7XlR+ASKsBmTNnJSyq8FY A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFvq51GtJV2b/2dsb2JhbABagwY1UMBDgQwWdIIkAQEBAQIBAQEBNzQQCwIBCCIUECcLJQIEEwiIAgYMtkcEj1wCOIMObgOpKoMSgio X-IronPort-AV: E=Sophos;i="4.89,693,1367971200"; d="scan'208";a="236433556" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jul 2013 13:23:53 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6IDNqUU003785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 18 Jul 2013 13:23:52 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Thu, 18 Jul 2013 08:23:52 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Consistent CDNI interface names Thread-Index: AQHOfiFZMFfZm5vuckOS3IAJyM7vgJlqy6SA Date: Thu, 18 Jul 2013 13:23:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.194] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Consistent CDNI interface names X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 13:24:00 -0000 Folks, Noone has expressed any concerns with the interface names listed below, so = we'll go with that, All CDNI document co-authors, Please ensure you align the interface naming in your documents to the final= interface names: * CDNI Control interface (CI) * CDNI Metadata interface (MI) * CDNI Logging interface (LI) * CDNI Request Routing Redirection interface (RI) * CDNI Footprint & Capabilities Advertisement interface (FCI) Francois & Daryl On 11 Jul 2013, at 12:28, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > There are slight variations across CDNI documents with respect to how the= y refer to our CDNI interfaces (e.g. "interface" vs "Interface", "Capabilit= ies" vs "Capability", "and" vs "&" etc). As some of these documents are no= w progressing through the publication process, we need to converge on exact= names. >=20 > We propose that all documents use : > * CDNI Control interface (CI) > * CDNI Metadata interface (MI) > * CDNI Logging interface (LI) > * CDNI Request Routing Redirection interface (RI) > * CDNI Footprint & Capabilities Advertisement interface (FCI) >=20 > These are the names defined in RFC 6707, with one very minor correction, = which is to use "Advertisement" instead of "advertisement" for consistent u= se of capitalisation. >=20 > Please let us know asap if you have comments on this. >=20 > Once we have finalised the names, we will get all documents aligned to th= ese names. >=20 > Cheers >=20 > Francois & Daryl > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Thu Jul 18 08:04:51 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8833B11E8185 for ; Thu, 18 Jul 2013 08:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.449 X-Spam-Level: X-Spam-Status: No, score=-103.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4Pg8WwBa9Lq for ; Thu, 18 Jul 2013 08:04:47 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 96FF621F8415 for ; Thu, 18 Jul 2013 08:03:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id CF2DA104BE0 for ; Thu, 18 Jul 2013 17:02:51 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1xdQOtd-faT for ; Thu, 18 Jul 2013 17:02:51 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id B569C104BDF for ; Thu, 18 Jul 2013 17:02:46 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Thu, 18 Jul 2013 17:01:11 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: New version of the footprint/capabilities semantics draft (now draft-ietf-cdni-footprint-capabilities-semantics-00) Thread-Index: Ac6Dxyv2iLs2zuL6T/am5ite2witeg== Date: Thu, 18 Jul 2013 15:01:10 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55590147@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.5.89] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] New version of the footprint/capabilities semantics draft (now draft-ietf-cdni-footprint-capabilities-semantics-00) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 15:04:51 -0000 Dear all, The new version of the semantics draft captures the decisions of the design= team we made in Orlando which capture quite clear what we regard as a foot= print and as capabilities at this stage (and what not), including a concret= e list of mandatory types of footprints and capabilities that solution prot= ocols must support. Further, it addresses several comments received on this= list from Scott (thanks), and probably most importantly it has an updated = section of still open issues. Especially since this is a WG document now, we would appreciate comments on= the open issues (see Section 7 of the draft). We will try to make progress= on these outstanding issues with the design team in Berlin. I will set up = a doodle for a side meeting during the IETF-87 week exactly for that (i.e. = discussing the open issues). Personally, I regard none of the open issues a= s major nor controversial, but I may be wrong. - Jan -----Original Message----- From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Wednesday, July 17, 2013 8:58 PM To: i-d-announce@ietf.org Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantic= s-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Content Delivery Networks Interconnection= Working Group of the IETF. Title : CDNI Request Routing: Footprint and Capabilities Semanti= cs Author(s) : Jan Seedorf Jon Peterson Stefano Previdi Ray van Brandenburg Kevin J. Ma Filename : draft-ietf-cdni-footprint-capabilities-semantics-00.txt Pages : 18 Date : 2013-07-15 Abstract: This document tries to capture the semantics of the "Footprint and Capabilities Advertisement" part of the CDNI Request Routing interface, i.e. the desired meaning and what "Footprint and Capabilities Advertisement" is expected to offer within CDNI. The discussion in this document has the goal to facilitate the choosing of one or more suitable protocols for "Footprint and Capabilities Advertisement" within CDNI Request Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-sem= antics There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics= -00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni From yang.r.yang@gmail.com Thu Jul 18 12:12:15 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26EBC11E81E1; Thu, 18 Jul 2013 12:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zck8bPl-vs6F; Thu, 18 Jul 2013 12:12:13 -0700 (PDT) Received: from mail-pd0-x22b.google.com (mail-pd0-x22b.google.com [IPv6:2607:f8b0:400e:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id D18B011E81DE; Thu, 18 Jul 2013 12:12:13 -0700 (PDT) Received: by mail-pd0-f171.google.com with SMTP id y14so3383038pdi.30 for ; Thu, 18 Jul 2013 12:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=wJUbby5dEnxw6E6EoHfIVdFAcA/ZwX0N/xLp9ojQCxs=; b=DNka/rQUzdsWIGgfDNczlLQiE67rIRYVMzxKus2mhKzhxnhbzfQq/gy3lckUtE+BBN 94PG/LS4kaj/byRHG7m1TC9Fken//fTen8S4aoU++ix82lKIku/KLAqAMigKUhIVV4p/ HeCK/qZFQTlTrQ9DB/6UbJSw3MPJQCF3j44ok34J7BByTjsyfCw2DEdrK2T/HF9QXm82 Z22DwVH2e3k5WlGQTHkEsZ0LXaQ8VQnfiiGDqKS7WCz8BO62CAUr3WnX6WBzwPT9Gx1W vLI9xkfzrX2BuWtUn1XJbuvCPPO28cWXSReV4DLNUVKihcOT7xCcgG2lJ1DAf0ZZ8I/U DjCA== MIME-Version: 1.0 X-Received: by 10.66.142.5 with SMTP id rs5mr14735345pab.168.1374174733491; Thu, 18 Jul 2013 12:12:13 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.68.43.99 with HTTP; Thu, 18 Jul 2013 12:12:13 -0700 (PDT) Date: Thu, 18 Jul 2013 15:12:13 -0400 X-Google-Sender-Auth: ASh5Pvb4Ju3mAqZW7FhK_MGS-Jc Message-ID: From: "Y. Richard Yang" To: Jan Seedorf , IETF ALTO Content-Type: multipart/alternative; boundary=001a11330f2ad969ee04e1cdfcc1 Cc: "cdni@ietf.org" Subject: Re: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-04.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:12:15 -0000 --001a11330f2ad969ee04e1cdfcc1 Content-Type: text/plain; charset=ISO-8859-1 Hi Jan, A very good document. Here are come comments: Section 4. This is a key technical section. I feel that the description style is slightly informal. Such a style may be intended, for now. When/if it is time to go formal, I would recommend that it starts with a precise spec of the IRD that a dCDN should announce: a list of required and optional Network Maps, a list of required and optional Cost Maps, Endhost lookup capabilities (e.g., to map from an end user IP address to if it can be served, the delivery protocol, ...). This can give the reader a top-down overview. Section 4.1/4.2: Footprint/Capability Advertisement using Network Map These are very interesting/useful sections. I feel that it can be helpful to go some more in details, i.e., specifies the exact Network Maps that a dCDN should be provided. Here is a list that I tried to extract from your doc and some of our projects: - DeliveryProtocolMap, which specifies, for each delivery protocol name (e.g., https, rmtp, Adobe10.1), as a pid, to the set of end users that the protocol can be delivered; This is from your current spec. Here, you may need to derive a new type, from PIDName as the type of DeliveryProtocol PIDs, to add some syntax checking, for the hash map defined in the current ALTO protocol. - ChargingRegionMap, which specifies, from each charging region (e.g., EU, US, Pacific), as a pid, to the set of end users. This is from a need from our SIGCOMM'12 content multihoming optimization paper ( http://conferences.sigcomm.org/sigcomm/2012/paper/sigcomm/p371.pdf); for example, for Amazon CloudFront, we could not read the contract agreement to figure out which region will serve a given user, and it will be ideal if the CDN (CloudFront) could have provided it. Some technical details/semantics issues that you may then encounter include: T1. Should the union of all end user addresses appear in one map equal to that of another map? For example, the union of all addresses in the DeliveryProtocolMap may contain fewer IP addresses than that in ChargingRegionMap. What does it mean? T2. One value that you motivated about the FCI interface is to provide dynamic information. For this purpose, I feel that it is important to quickly finish the incremental update/subscription interface of ALTO. T3. Do you need to introduce "intermediate" variables to reduce redundancy in your design. For example, DeliveryProtocolMap and ChargingRegionMap may both list a large number of addresses from the same region. Is it important to introduce such "intermediate" variables as shorthands. The ongoing discussion of multiple topology references in ALTO can be quite helpful. In particular, I feel that it can increase modularity to define a slightly fine-grained network map (say a few hundred cities or regions), which can be used by other network maps, as well as the cost maps. One may call this map an AtomMap, to denote that they provide building blocks (units) for other maps to compose on, but each atom can still be much larger than single IP addresses/prefixes. Such atoms can be the unit of updates to reduce update load as well. Section 4.3: Conveying additional information with ALTO Cost Maps I agree that the Cost Maps can provide finer grained information. The current draft defines only n-to-1 or 1-to-n cost matrices. One possibility that n-k cases may arise is that the dCDN provides multiple classes, i.e., each one of the k denote a logical cluster of a given class of surrogate dCDN servers. Do you need a section on how to leverage the endhost property lookup service? This can be a simple way to allow a uCDN to ask a dCDN is a given endhost can be served.... Just some initial comments. Thanks. Richard On Tue, Jul 16, 2013 at 4:41 AM, Jan Seedorf wrote: > Hi all, > > I have submitted a revision of the draft that outlines how ALTO can be a > solution protocol for the CDNI FCI. The latest version has been changed > quite a bit; it re-visits the latest conclusions in the FCI design team, > and describes how ALTO could be used to advertise the types of footprint > and capabilities that are considered as mandatory by the design team. > > - Jan > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 15, 2013 5:26 PM > To: Jan Seedorf > Subject: New Version Notification for > draft-seedorf-cdni-request-routing-alto-04.txt > > > A new version of I-D, draft-seedorf-cdni-request-routing-alto-04.txt > has been successfully submitted by Jan Seedorf and posted to the > IETF repository. > > Filename: draft-seedorf-cdni-request-routing-alto > Revision: 04 > Title: CDNI Request Routing with ALTO > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 15 > URL: > http://www.ietf.org/internet-drafts/draft-seedorf-cdni-request-routing-alto-04.txt > Status: > http://datatracker.ietf.org/doc/draft-seedorf-cdni-request-routing-alto > Htmlized: > http://tools.ietf.org/html/draft-seedorf-cdni-request-routing-alto-04 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-seedorf-cdni-request-routing-alto-04 > > Abstract: > Network Service Providers (NSPs) are currently considering to deploy > Content Delivery Networks (CDNs) within their networks. As a > consequence of this development, there is a need for interconnecting > these local CDNs. The necessary interfaces for inter-connecting CDNs > are currently being defined in the Content Delivery Networks > Interconnection (CDNI) WG. This document focuses on the CDNI > Footprint & Capabilities Advertisement interface (FCI). > Specifically, this document outlines how the solutions currently > being defined in the Application Layer Traffic Optimization (ALTO) WG > can facilitate Footprint & Capabilities Advertisement in a CDNI > context, i.e. how the CDNI FCI can be realised with the ALTO > protocol. Concrete examples of how ALTO can be integrated within > CDNI request routing and in particular in the process of selecting a > downstream CDN are given. The examples in this document are based on > the use cases and examples currently being discussed in the CDNI WG. > > > > > The IETF Secretariat > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --001a11330f2ad969ee04e1cdfcc1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jan,

A very good document. Here are = come comments:

Section 4. This is a key technical = section. I feel that the description style is slightly informal. Such a sty= le may be intended, for now. When/if it is time to go formal, I would recom= mend that it starts with a precise spec of the IRD that a dCDN should annou= nce: a list of required and optional Network Maps, a list of required and o= ptional Cost Maps, Endhost lookup capabilities (e.g., to map from an end us= er IP address to if it can be served, the delivery protocol, ...). This can= give the reader a top-down overview.

Section 4.1/4.2: Footprint/Capability Advertisement usi= ng Network Map

These are very interesting/useful s= ections. I feel that it can be helpful to go some more in details, i.e., sp= ecifies the exact Network Maps that a dCDN should be provided. Here is a li= st that I tried to extract from your doc and some of our projects:

- DeliveryProtocolMap, which specifies, for each delive= ry protocol name (e.g., https, rmtp, Adobe10.1), as a pid, to the set of en= d users that the protocol can be delivered; This is from your current spec.=

Here, you may need to derive a new type, from PIDName a= s the type of DeliveryProtocol PIDs, to add some syntax checking, for the h= ash map defined in the current ALTO protocol.

- ChargingRegionMap, which specifies, from each charging region (e.g., EU, = US, Pacific), as a pid, to the set of end users. This is from a need from o= ur SIGCOMM'12 content multihoming optimization paper (http://confer= ences.sigcomm.org/sigcomm/2012/paper/sigcomm/p371.pdf); for example, fo= r Amazon CloudFront, we could not read the contract agreement to figure out= which region will serve a given user, and it will be ideal if the CDN (Clo= udFront) could have provided it.

Some technical details/semantics issues that you may th= en encounter include:

T1. Should the union of all = end user addresses appear in one map equal to that of another map? For exam= ple, the union of all addresses in the DeliveryProtocolMap may contain fewe= r IP addresses than that in ChargingRegionMap. What does it mean?

T2. One value that you motivated about the FCI interfac= e is to provide dynamic information. For this purpose, I feel that it is im= portant to quickly finish the incremental update/subscription interface of = ALTO.

T3. Do you need to introduce "intermediate" v= ariables to reduce redundancy in your design. For example, DeliveryProtocol= Map and ChargingRegionMap may both list a large number of addresses from th= e same region. Is it important to introduce such "intermediate" v= ariables as shorthands. The ongoing discussion of multiple topology referen= ces in ALTO can be quite helpful.

In particular, I feel that it can increase modularity t= o define a slightly fine-grained network map (say a few hundred cities or r= egions), which can be used by other network maps, as well as the cost maps.= One may call this map an AtomMap, to denote that they provide building blo= cks (units) for other maps to compose on, but each atom can still be much l= arger than single IP addresses/prefixes. Such atoms can be the unit of upda= tes to reduce update load as well.

Section 4.3: Conveying additional information wit= h ALTO Cost Maps

I agree that the Cost Maps can pr= ovide finer grained information. The current draft defines only n-to-1 or 1= -to-n cost matrices. One possibility that n-k cases may arise is that the d= CDN provides multiple classes, i.e., each one of the k denote a logical clu= ster of a given class of surrogate dCDN servers.

Do you need a section on how to leverage the endhost pr= operty lookup service? This can be a simple way to allow a uCDN to ask a dC= DN is a given endhost can be served....

Just some = initial comments.

Thanks.

Richard

=



On Tue, Jul 16, 2013 at 4:41 AM, Jan Seedorf <= Jan.Seedorf@necl= ab.eu> wrote:
Hi all,

I have submitted a revision of the draft that outlines how ALTO can be a so= lution protocol for the CDNI FCI. The latest version has been changed quite= a bit; it re-visits the latest conclusions in the FCI design team, and des= cribes how ALTO could be used to advertise the types of footprint and capab= ilities that are considered as mandatory by the design team.

=A0- Jan

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, July 15, 2013 5:26 PM
To: Jan Seedorf
Subject: New Version Notification for draft-seedorf-cdni-request-routing-al= to-04.txt


A new version of I-D, draft-seedorf-cdni-request-routing-alto-04.txt
has been successfully submitted by Jan Seedorf and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-seedorf-cdni-request-routing-alto
Revision: =A0 =A0 =A0 =A004
Title: =A0 =A0 =A0 =A0 =A0 CDNI Request Routing with ALTO
Creation date: =A0 2013-07-15
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 15
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://w= ww.ietf.org/internet-drafts/draft-seedorf-cdni-request-routing-alto-04.txt<= /a>
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ie= tf.org/doc/draft-seedorf-cdni-request-routing-alto
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/htm= l/draft-seedorf-cdni-request-routing-alto-04
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ie= tf.org/rfcdiff?url2=3Ddraft-seedorf-cdni-request-routing-alto-04

Abstract:
=A0 =A0Network Service Providers (NSPs) are currently considering to deploy=
=A0 =A0Content Delivery Networks (CDNs) within their networks. =A0As a
=A0 =A0consequence of this development, there is a need for interconnecting=
=A0 =A0these local CDNs. =A0The necessary interfaces for inter-connecting C= DNs
=A0 =A0are currently being defined in the Content Delivery Networks
=A0 =A0Interconnection (CDNI) WG. =A0This document focuses on the CDNI
=A0 =A0Footprint & Capabilities Advertisement interface (FCI).
=A0 =A0Specifically, this document outlines how the solutions currently
=A0 =A0being defined in the Application Layer Traffic Optimization (ALTO) W= G
=A0 =A0can facilitate Footprint & Capabilities Advertisement in a CDNI<= br> =A0 =A0context, i.e. how the CDNI FCI can be realised with the ALTO
=A0 =A0protocol. =A0Concrete examples of how ALTO can be integrated within<= br> =A0 =A0CDNI request routing and in particular in the process of selecting a=
=A0 =A0downstream CDN are given. =A0The examples in this document are based= on
=A0 =A0the use cases and examples currently being discussed in the CDNI WG.=




The IETF Secretariat

_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni

--001a11330f2ad969ee04e1cdfcc1-- From swainner@cisco.com Thu Jul 18 12:23:08 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F8011E81E8 for ; Thu, 18 Jul 2013 12:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5TZBkUD0AjR for ; Thu, 18 Jul 2013 12:22:59 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 43A9811E81F2 for ; Thu, 18 Jul 2013 12:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7653; q=dns/txt; s=iport; t=1374175333; x=1375384933; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=yiElZMmvq+/PP4j8lkovbOMacZML+iq71jnnx843xOw=; b=N6v+b6VdXYgDuBB356IUDoee16Xrn5Iuv8/M/870S9asuw+LxuUWoqP9 rLeiW1nvb0YmN7rc5nTaGcDTjQCAPJLfNpjza410YySfjnDcu8zeFKVFI uNunhmetcPB8FQe82KR8HvQ+LTIm5/tih3SMf9k96AsalsjjdJX6z6lwH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFALQ/6FGtJXG8/2dsb2JhbABagwY1wRSBExZ0giQBAQEBAwEBATUuCAYEDQQLEQQBAQEJFgQEBwkDAgECARUfCQgTBgIBAReHdQymZo8+kBYGg3YDl12BKZAkgVmBVSA X-IronPort-AV: E=Sophos;i="4.89,695,1367971200"; d="scan'208";a="236603666" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 18 Jul 2013 19:22:12 +0000 Received: from rtp-swainner-8919.cisco.com (rtp-swainner-8919.cisco.com [10.116.109.202]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6IJMBOw002286 for ; Thu, 18 Jul 2013 19:22:11 GMT Message-ID: <51E84063.3060007@cisco.com> Date: Thu, 18 Jul 2013 15:22:11 -0400 From: Scott Wainner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cdni@ietf.org References: <2779C9F0771F974CAD742BAE6D9904FE55590147@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE55590147@DAPHNIS.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CDNi] New version of the footprint/capabilities semantics draft (now draft-ietf-cdni-footprint-capabilities-semantics-00) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:23:08 -0000 Jan, The draft seems to cover a lot of background / motivations for why we would settle on a set of mandatory footprint and capability semantics. I suspect we will need to get down to some concise recommendations for defining the semantics. Footprint --------- I think we need to define two classes of footprint for each IP protocol capability with one or more types: a. Geo-Physical - ISO Country Codes (mandatory) - Others? (optional) b. Topological - ASN (mandatory) - IP Prefix (mandatory) My experience with commercial CDN's is they are reluctant to indicate WHERE their caches are located (topologically or physically); hence, our definition of footprint is likely relegated to where the CDN purportedly provides service (able and willing to serve). Most global CDN's will avoid narrowing the scope of their coverage; their goal is to attract any traffic. We might assume the default case is that all CDN's provide global coverage unless specified otherwise. So we need an FCI interface that the dCDN initializes with the uCDN that indicates a default global footprint exists (at a minimum). Example: IPv4 Topological_Footprint: IPv4=NULL or 0.0.0.0/0 (mandatory type) GeographicalFootprint: CC=* (mandatory type) IPv6 Topological_Footprint: IPv6=NULL or ::/0 (mandatory type) Geographical_Footprint: CC=* (mandatory type) We might argue that a global CDN COULD advertise a global footprint while advertising an exception (i.e. everywhere except this CC or everywhere except this ASN). I suspect that CDN's would NOT want to filter their default coverage; they would service requests from their next-best CDN location. I don't see a lot of value in advertising exceptions; its too complicated and mess for a uCDN to analyze and evaluate. If the dCDN includes a narrowly defined footprint coverage, I suggest the dCDN is asserting that it ONLY wants to provide coverage for that footprint (the global default is taken off the table). There are very real reasons why a topologically bound CDN might want to do this; they don't have peering links to serve other ISP's customers. Therefore, an advertisement from a dCDN means exactly what it intends. The CDN only provides coverage for this footprint: IPv4 Topological_Footprint: IPv4=0.0.0.0/0 ASN=y GeographicalFootprint: CC= MX, US, CA I would propose that the footprint representation be a BOOLEAN AND function of all footprint representations. In the example above, the dCDN only provides coverage in the geographical region of Mexico, United States, and Canada and only for those locations covered by ASN=y and only for IPv4 prefixes. It is not mandatory for the dCDN to advertise multiple types within a class. For example, a dCDN might only offer one type (the mandatory default) within a class: IPv4 Topological_Footprint: IPv4=0.0.0.0/0 GeographicalFootprint: CC= * The proposed footprint attributes (e.g. ISO CC, ASN, PREFIX) seem like well defined semantics that are meaningful and useful. Capabilities ------------ There is no point advertising a footprint of a dCDN that doesn't have the capabilities of servicing the type of requests required of the uCDN. Therefore, I propose we use the "capabilities with footprint" restrictions. Either the CDN offers HTTP Redirection or it doesn't. The CDN footprint coverage is irrelevant if it is not capable of servicing the request. In fact, many CDN will offer global coverage; therefore, capabilities becomes more relevant. The document proposes the following capabilities: Delivery Protocol: HTTP, RTMP Acquisition Protocol: undefined Redirection Mode: DNS or HTTP CDNI Logging CDNI Metadata Again, I think we will need to define a BOOLEAN capability set where all criteria are met with the AND function: Capability (Delivery=HTTP & Acquisition=HTTP & Redirection=HTTP, ...) Footprint (as defined above) ... Capability (Delivery=HTTP & Acquisition=HTTP & Redirection=DNS, ...) Footprint (as defined above) ... Scott On 7/18/13 11:01 AM, Jan Seedorf wrote: > Dear all, > > The new version of the semantics draft captures the decisions of the design team we made in Orlando which capture quite clear what we regard as a footprint and as capabilities at this stage (and what not), including a concrete list of mandatory types of footprints and capabilities that solution protocols must support. Further, it addresses several comments received on this list from Scott (thanks), and probably most importantly it has an updated section of still open issues. > > Especially since this is a WG document now, we would appreciate comments on the open issues (see Section 7 of the draft). We will try to make progress on these outstanding issues with the design team in Berlin. I will set up a doodle for a side meeting during the IETF-87 week exactly for that (i.e. discussing the open issues). Personally, I regard none of the open issues as major nor controversial, but I may be wrong. > > - Jan > > > > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Wednesday, July 17, 2013 8:58 PM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-footprint-capabilities-semantics-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF. > > Title : CDNI Request Routing: Footprint and Capabilities Semantics > Author(s) : Jan Seedorf > Jon Peterson > Stefano Previdi > Ray van Brandenburg > Kevin J. Ma > Filename : draft-ietf-cdni-footprint-capabilities-semantics-00.txt > Pages : 18 > Date : 2013-07-15 > > Abstract: > This document tries to capture the semantics of the "Footprint and > Capabilities Advertisement" part of the CDNI Request Routing > interface, i.e. the desired meaning and what "Footprint and > Capabilities Advertisement" is expected to offer within CDNI. The > discussion in this document has the goal to facilitate the choosing > of one or more suitable protocols for "Footprint and Capabilities > Advertisement" within CDNI Request Routing. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-footprint-capabilities-semantics > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-footprint-capabilities-semantics-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > . > From flefauch@cisco.com Fri Jul 19 03:17:46 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 591F711E80F6 for ; Fri, 19 Jul 2013 03:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDuaSiJTwCbl for ; Fri, 19 Jul 2013 03:17:40 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DFE4A11E80F3 for ; Fri, 19 Jul 2013 03:17:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=170; q=dns/txt; s=iport; t=1374229060; x=1375438660; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=QDVNkKd+ss+fRjJGG2Wi5C6F2oZV73/uaRmdxQDBI30=; b=I7qc+Kha0nsAWucFuJxpLBNFW7A8KRuyhIAdH6qIeRekMrqXxRpW1WyI G304avfWsRGQGDQMvymwcWM3Oiuss+8gCsj8Tb535DHW2YDj0b6erF8Jo csZDfq+iGEF07hp2WjRdgjdohUAy3PWMImUmCmGEteYnKVmDeAi0JkGC9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsJALoR6VGtJXG+/2dsb2JhbABagwY1UII/vgEEAYEQFnSCJgEEOlEBKhRCJwQbAYgHDJVqoE2OfWGDRm4DqSqDEoIq X-IronPort-AV: E=Sophos;i="4.89,700,1367971200"; d="scan'208";a="236868289" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 19 Jul 2013 10:17:39 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6JAHdNx020578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Jul 2013 10:17:39 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 05:17:38 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Draft CDNI agenda for Berlin available Thread-Index: AQHOhGkxhlK6ThP8dkm4x9y1QHd5eA== Date: Fri, 19 Jul 2013 10:17:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.194] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Draft CDNI agenda for Berlin available X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 10:17:46 -0000 Folks, We've uploaded a draft agenda: http://www.ietf.org/proceedings/87/agenda/agenda-87-cdni Please review and comment if needed. Cheers Francois & Daryl From flefauch@cisco.com Fri Jul 19 06:50:52 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640AD21E80BC for ; Fri, 19 Jul 2013 06:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.279 X-Spam-Level: X-Spam-Status: No, score=-10.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xiKkPQvmI3AP for ; Fri, 19 Jul 2013 06:50:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C825F21E80AB for ; Fri, 19 Jul 2013 06:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=177; q=dns/txt; s=iport; t=1374241846; x=1375451446; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ydIxtNVftYY/pRjaRlon87RtYsumWxydKPwp7RPn/Zk=; b=XnnYuegsyV1XXG6XPXvxUCqhzOLk0jQ4tBRHk7wv7RjHo2eavoLo531q Svaz3Oj1ZosSNLxYDXBQ6Scjr5GaqBACWYsRrZMTddcz19TWy8o+iFQaV uDahfiP7DvdtuWGHkK4sOX0zcxh+PS1Te6XQjwUBvJOw32U5kwREfll1r c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABNE6VGtJXHB/2dsb2JhbABbgwaBBcBGgQ8WdIImAQQ6UQEqFEInBBuICJZMoEWPXoNIbgOpKoMSgio X-IronPort-AV: E=Sophos;i="4.89,701,1367971200"; d="scan'208";a="233937503" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 19 Jul 2013 13:50:31 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6JDoU4M017815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Jul 2013 13:50:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 08:50:30 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Presentation Slides for Berlin Thread-Index: AQHOhIbuqn6KdFSoiEWxIMV8VkxePw== Date: Fri, 19 Jul 2013 13:50:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.194] Content-Type: text/plain; charset="us-ascii" Content-ID: <65C1D68C65E9D34783A396E5A036F42C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Presentation Slides for Berlin X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 13:50:52 -0000 To all presenters in Berlin, Please send Daryl and I your slides by the end of Wednesday 24 July (ie nex= t Wed) so we can upload and review. Cheers Francois & Daryl From D.Malas@cablelabs.com Tue Jul 23 13:45:58 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFD911E82AB for ; Tue, 23 Jul 2013 13:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.462 X-Spam-Level: X-Spam-Status: No, score=-100.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KS1lTxk+YsuK for ; Tue, 23 Jul 2013 13:45:54 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id E6F9811E8135 for ; Tue, 23 Jul 2013 13:45:53 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r6NKjoow006601; Tue, 23 Jul 2013 14:45:50 -0600 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 23 Jul 2013 14:45:50 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.03.0146.000; Tue, 23 Jul 2013 14:45:50 -0600 From: Daryl Malas To: "cdni@ietf.org" Thread-Topic: [CDNi] Reminder: IPR Disclosures Thread-Index: AQHOh+WdV18iss+dF0yQtr3sRG9nwg== Date: Tue, 23 Jul 2013 20:45:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_CE14479CF175dmalascablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [CDNi] Reminder: IPR Disclosures X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 20:45:58 -0000 --_000_CE14479CF175dmalascablelabscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable All, We have recently had two situations (i.e., Use Cases and Requirements) wher= e IPR disclosures were submitted late into the draft process. Most recentl= y, this has occurred with the Requirements draft. Unfortunately, I do not = think it was made clear to everyone that they needed to disclose any IPR on= these specific drafts, even though they are intended as informational. Fo= r clarification, according to RFC 3979 here is a brief on the "who," "what"= and "when": Who - "Any Contributor who reasonably and personally knows of IPR=85owned d= irectly or indirectly, by the individual or his/her employer or sponsor" Se= ction 6.1.1/Section 6.6 What - "=85includes Contributions that are made by any means=85" Section 6.= 1.1 When - "=85as soon as reasonably possible after the Contribution is publish= ed in an Internet Draft=85" Section 6.2.1 Disclosing IPR early "is important because [it allows us] to have as much i= nformation as [we] can while [we] are evaluating alternative solutions." Se= ction 6.2 If anyone has concerns with the disclosed IPR in the Requirements draft, pl= ease raise these ASAP. We can discuss any concerns either on the mailing l= ist or in the working group session in Berlin. Of course, I strongly encourage everyone to read through RFC 3979 (http://t= ools.ietf.org/html/rfc3979). Let us know if you have any questions. Regards, Daryl (CDNI Co-chair) --_000_CE14479CF175dmalascablelabscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0988EFCD8BBB5948AF949E337A2EBD58@cablelabs.com> Content-Transfer-Encoding: quoted-printable
All,

We have recently had two situations (i.e., Use Cases and Requirements)= where IPR disclosures were submitted late into the draft process.  Mo= st recently, this has occurred with the Requirements draft.  Unfortuna= tely, I do not think it was made clear to everyone that they needed to disclose any IPR on these specific drafts, ev= en though they are intended as informational.  For clarification, acco= rding to RFC 3979 here is a brief on the "who," "what" = and "when":

Who - "Any Contributor who reasonably and personally knows of IPR= =85owned directly or indirectly, by the individual or his/her employer= or sponsor" Section 6.1.1/Section 6.6
What - "=85includes Contributions that are made by any means= =85" Section 6.1.1
When - "=85as soon as reasonably possible after the Contribu= tion is published in an Internet Draft=85" Section 6.2.1

Disclosing IPR early "is important because [it allows us] to=  have as much information as [we] can while [we] are evaluating a= lternative solutions." Section 6.2

If anyone has concerns with the disclosed IPR in the Requirements draf= t, please raise these ASAP.  We can discuss any concerns either on the= mailing list or in the working group session in Berlin.

Of course, I strongly encourage everyone to read through RFC 3979 (http://tools.ietf.org/html/rfc3= 979).

Let us know if you have any questions.

Regards,

Daryl (CDNI Co-chair)


--_000_CE14479CF175dmalascablelabscom_-- From Jan.Seedorf@neclab.eu Wed Jul 24 03:15:46 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C146C11E83AF for ; Wed, 24 Jul 2013 03:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.185 X-Spam-Level: X-Spam-Status: No, score=-101.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWZK5kkC-60e for ; Wed, 24 Jul 2013 03:15:41 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 45EAD11E8103 for ; Wed, 24 Jul 2013 03:15:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DE731104C88 for ; Wed, 24 Jul 2013 12:14:50 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pUD3qof-BVT for ; Wed, 24 Jul 2013 12:14:50 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id C6172104C73 for ; Wed, 24 Jul 2013 12:14:45 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 24 Jul 2013 12:13:41 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: Doodle for CDNI Footprint/Capabilities Design Team Side Meeting @IETF87 Thread-Index: Ac6IVqC0aZin27T0SxGyD2tOqcnV4A== Date: Wed, 24 Jul 2013 10:13:40 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55592595@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.5.89] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Doodle for CDNI Footprint/Capabilities Design Team Side Meeting @IETF87 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 10:15:46 -0000 http://doodle.com/zv6b5gfbf22m9hk7 Please fill in latest by Sunday - Jan =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Jan Seedorf Senior Researcher NEC Europe Ltd., NEC Laboratories Europe, Network Division=A0=A0=A0=A0=A0 Kurfuerstenanlage 36, D-69115 Heidelberg Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 e-mail:=A0 jan.seedorf@neclab.eu =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West End = Road, London, HA4 6QE, GB, Registered in England 2832014 From flefauch@cisco.com Wed Jul 24 04:50:30 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EA911E81D0 for ; Wed, 24 Jul 2013 04:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GG2qZstq9Gil for ; Wed, 24 Jul 2013 04:50:25 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE8011E80E0 for ; Wed, 24 Jul 2013 04:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6527; q=dns/txt; s=iport; t=1374666625; x=1375876225; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kIEIs64benqfnA9qoJ9AGKO3DUiHz6ZCAtsTXaVBkec=; b=bQ2zhxa7RecblnNdFmdfF2OdrXFgMxkgXpm/w3ANKSp8Ygf0RAVlvISt pQienVOLsxze4LRjAkAVZ/IftQ/fFJQxU6eQ5b9vwdozbCK8qLd6kSjqW q3SGsSRB2KjhycabXCcM+GgPl9KYQxC2ERQFxuwqJ3+vYZJL96kHA3CHL A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAIO+71GtJV2a/2dsb2JhbABbgkJENVC4P4hBgRYWdIIlAQEEAQEBawsQAgEIDhQdBycLFBECBA4FCBOHdQy5I49JMQcCgxBuA5kIkCSDFIIq X-IronPort-AV: E=Sophos;i="4.89,735,1367971200"; d="scan'208,217";a="238749833" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 24 Jul 2013 11:50:25 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6OBoPqM024538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 24 Jul 2013 11:50:25 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Wed, 24 Jul 2013 06:50:24 -0500 From: "Francois Le Faucheur (flefauch)" To: Daryl Malas Thread-Topic: [CDNi] Reminder: IPR Disclosures Thread-Index: AQHOh+WdV18iss+dF0yQtr3sRG9nwpl0C/uA Date: Wed, 24 Jul 2013 11:50:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.194] Content-Type: multipart/alternative; boundary="_000_FC236DA6F2DA77449EF2D02DF4471A8D6C9B30xmbrcdx10ciscocom_" MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] Reminder: IPR Disclosures X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 11:50:30 -0000 --_000_FC236DA6F2DA77449EF2D02DF4471A8D6C9B30xmbrcdx10ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Daryl and all, On 23 Jul 2013, at 22:45, Daryl Malas > wrote: All, We have recently had two situations (i.e., Use Cases and Requirements) wher= e IPR disclosures were submitted late into the draft process. Most recentl= y, this has occurred with the Requirements draft. Unfortunately, I do not = think it was made clear to everyone that they needed to disclose any IPR on= these specific drafts, even though they are intended as informational. Fo= r clarification, according to RFC 3979 here is a brief on the "who," "what"= and "when": Yes, I believe this is a very useful clarification. Indeed, this was not clear to me at the time I was an active editor of cdni= -requirements (ie before Kent and Yiu took over editorship). Also, I'd like to clarify that the IPR on cdni-requirements only relates to= a single requirement (SEC-3) and is not required to meet that requirement,= but rather might potentially be used in a hypothetical solution to meet th= at requirement. In any case, I'd like to apologise for not realising the IPR relevance earl= ier and thus declaring it late in the process. Cheers Francois Who - "Any Contributor who reasonably and personally knows of IPR=85owned d= irectly or indirectly, by the individual or his/her employer or sponsor" Se= ction 6.1.1/Section 6.6 What - "=85includes Contributions that are made by any means=85" Section 6.= 1.1 When - "=85as soon as reasonably possible after the Contribution is publish= ed in an Internet Draft=85" Section 6.2.1 Disclosing IPR early "is important because [it allows us] to have as much i= nformation as [we] can while [we] are evaluating alternative solutions." Se= ction 6.2 If anyone has concerns with the disclosed IPR in the Requirements draft, pl= ease raise these ASAP. We can discuss any concerns either on the mailing l= ist or in the working group session in Berlin. Of course, I strongly encourage everyone to read through RFC 3979 (http://t= ools.ietf.org/html/rfc3979). Let us know if you have any questions. Regards, Daryl (CDNI Co-chair) _______________________________________________ CDNi mailing list CDNi@ietf.org https://www.ietf.org/mailman/listinfo/cdni --_000_FC236DA6F2DA77449EF2D02DF4471A8D6C9B30xmbrcdx10ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Daryl and all,

On 23 Jul 2013, at 22:45, Daryl Malas <D.Malas@cablelabs.com> wrote:

All,

We have recently had two situations (i.e., Use Cases and Requirements)= where IPR disclosures were submitted late into the draft process.  Mo= st recently, this has occurred with the Requirements draft.  Unfortuna= tely, I do not think it was made clear to everyone that they needed to disclose any IPR on these specific drafts, ev= en though they are intended as informational.  For clarification, acco= rding to RFC 3979 here is a brief on the "who," "what" = and "when":

Yes, I believe this is a very useful clarification.
Indeed, this was not clear to me at the time I was an active editor of= cdni-requirements (ie before Kent and Yiu took over editorship).

Also, I'd like to clarify that the IPR on cdni-requirements only relat= es to a single requirement (SEC-3) and is not required to meet that require= ment, but rather might potentially be used in a hypothetical solution to me= et that requirement.

In any case, I'd like to apologise for not realising the IPR relevance= earlier and thus declaring it late in the process.

Cheers

Francois


Who - "Any Contributor who reasonably and personally knows of IPR= =85owned directly or indirectly, by the individual or his/her employer= or sponsor" Section 6.1.1/Section 6.6
What - "=85includes Contributions that are made by any means= =85" Section 6.1.1
When - "=85as soon as reasonably possible after the Contribu= tion is published in an Internet Draft=85" Section 6.2.1

Disclosing IPR early "is important because [it allows us] to=  have as much information as [we] can while [we] are evaluating a= lternative solutions." Section 6.2

If anyone has concerns with the disclosed IPR in the Requirements draf= t, please raise these ASAP.  We can discuss any concerns either on the= mailing list or in the working group session in Berlin.

Of course, I strongly encourage everyone to read through RFC 3979 (http://tools.ietf.org/html/rfc3= 979).

Let us know if you have any questions.

Regards,

Daryl (CDNI Co-chair)


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

--_000_FC236DA6F2DA77449EF2D02DF4471A8D6C9B30xmbrcdx10ciscocom_-- From flefauch@cisco.com Thu Jul 25 05:30:01 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C63E21F9966 for ; Thu, 25 Jul 2013 05:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiLsVIoLE1Iz for ; Thu, 25 Jul 2013 05:29:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 70E8921F994B for ; Thu, 25 Jul 2013 05:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=544; q=dns/txt; s=iport; t=1374755396; x=1375964996; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7FtF5hszIwu+teynUi0GqtBKCQ19awTJi80D6zvFWl8=; b=Vrs2A0nFOSQ4TYsYtPDSpLqbGYhTzvRWXV9qlS8wt91oga9sxp8uY2y+ 1FhRcFAUzHgvnkTSqxRMb/uoToHBQXj/8Y4vh2mnRKdTUrAehPsL9F2J0 mvT3tFoEVirKQc3AXmLWRX8oPjSHYTSFCpChq3TArPR6mCRUnOEzmn8SM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFADEZ8VGtJXHA/2dsb2JhbABagwY1UIJFuxiBGBZ0giQBAQEDAQEBATc0EAsCASoUECcLJQIEEwgBiAEGDLkdj0w4gxJuA6ksgxSCKg X-IronPort-AV: E=Sophos;i="4.89,743,1367971200"; d="scan'208";a="239339461" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-8.cisco.com with ESMTP; 25 Jul 2013 12:29:56 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6PCTtxG029063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 25 Jul 2013 12:29:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Thu, 25 Jul 2013 07:29:55 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: [CDNi] Final CDNI agenda for Berlin available Thread-Index: AQHOiTKrzn2qH7sjn02Wolw91InDOA== Date: Thu, 25 Jul 2013 12:29:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.194] Content-Type: text/plain; charset="us-ascii" Content-ID: <529F948761340F4E9537531365B058E5@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Final CDNI agenda for Berlin available X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 12:30:01 -0000 We have not received any request for change on the draft agenda, so we'll c= onsider it final. Francois & Daryl On 19 Jul 2013, at 12:17, Francois Le Faucheur (flefauch) wrote: > Folks, >=20 > We've uploaded a draft agenda: > http://www.ietf.org/proceedings/87/agenda/agenda-87-cdni >=20 > Please review and comment if needed. >=20 > Cheers >=20 > Francois & Daryl > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From hannu.flinck@nsn.com Fri Jul 26 02:30:18 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3859421F8A50 for ; Fri, 26 Jul 2013 02:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6j8kdkxePt+3 for ; Fri, 26 Jul 2013 02:30:13 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id D397321F8C72 for ; Fri, 26 Jul 2013 02:30:12 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r6Q9UB4L017031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 26 Jul 2013 11:30:11 +0200 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r6Q9U8SV027764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 26 Jul 2013 11:30:10 +0200 Received: from DEMUHTC017.nsn-intra.net (10.159.42.48) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 26 Jul 2013 11:30:08 +0200 Received: from DEMUMBX011.nsn-intra.net ([169.254.11.211]) by DEMUHTC017.nsn-intra.net ([10.159.42.48]) with mapi id 14.03.0123.003; Fri, 26 Jul 2013 11:30:08 +0200 From: "Flinck, Hannu (NSN - FI/Espoo)" To: "cdni@ietf.org" Thread-Topic: Comments to Redirection Interface dart Thread-Index: Ac6J4rdq0nPLUpQkQWWOYRO4qmPKAQ== Date: Fri, 26 Jul 2013 09:30:07 +0000 Message-ID: <29264E37AFF9384FAEBBC9C6CD326434097531@DEMUMBX011.nsn-intra.net> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: multipart/alternative; boundary="_000_29264E37AFF9384FAEBBC9C6CD326434097531DEMUMBX011nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2038 X-purgate-ID: 151667::1374831011-000017BA-81E0F550/0-0/0-0 Subject: [CDNi] Comments to Redirection Interface dart X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 09:30:18 -0000 --_000_29264E37AFF9384FAEBBC9C6CD326434097531DEMUMBX011nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I read the draft-ietf-cdni-redirection-00.txt with great interest. Thank yo= u for the draft. Here are some observations from my reading: section 4.3.2 DNS Redirection responses Use of rcode not explained section 4.4.1 HTTP Redirection requests The example contains cdn-paths and max-hop which are not relevant for this = section nor explained. Instead of those the use of cs(Method) would clarify= the use of redirection requests Best regards Hannu --_000_29264E37AFF9384FAEBBC9C6CD326434097531DEMUMBX011nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I read the draft-ietf-cdni-redirection-00.txt with great interest. Tha= nk you for the draft.
 
Here are some observations from my reading:
 
section 4.3.2 DNS Redirection responses
 
Use of rcode  not explained
 
section 4.4.1 HTTP Redirection requests
 
The example contains cdn-paths and max-hop which are not relevant for = this section nor explained. Instead of those the use of cs(Method) would cl= arify the use of redirection requests
 
 
Best regards
Hannu
 
 
 
 --_000_29264E37AFF9384FAEBBC9C6CD326434097531DEMUMBX011nsnintr_-- From flefauch@cisco.com Fri Jul 26 02:58:58 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDD121F8C0C for ; Fri, 26 Jul 2013 02:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUa6Yow9LnDH for ; Fri, 26 Jul 2013 02:58:53 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 480A821F8756 for ; Fri, 26 Jul 2013 02:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=308; q=dns/txt; s=iport; t=1374832733; x=1376042333; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=mpv/AwP2rzwJJHMTD+IswqsXcU6j5UxitBLCWIve1hQ=; b=ci028InnNP13F+UBJGpye1z94I8tgW/UACk0R0t2vvzWT8hFl0NHeW55 7BmygGJ0ozAQ/d5+geKn3B9Yk5/p2o5Kg6sq7vDSKXSeiTeeorTb04MHV FEFuy+ZTWCB7/bZ5Mfd1azhWiVFnWmD8SARpReSZ8JfQX+jHil8xZ3CLw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFALFH8lGtJXG//2dsb2JhbABagwaBBb1GgRYWdIImAQQ6UQEqFEInBBuICJgooFWPTINKbgOpLIMUgio X-IronPort-AV: E=Sophos;i="4.89,750,1367971200"; d="scan'208";a="239784342" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 26 Jul 2013 09:58:52 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6Q9wpoS032346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 26 Jul 2013 09:58:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.35]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Fri, 26 Jul 2013 04:58:51 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: CDNI Logging Informal Meeting Monday 29 Jul @1:00pm meet at registration desk Thread-Index: AQHOiea6Ed1c2vuV/UShOwx3h5/rYQ== Date: Fri, 26 Jul 2013 09:58:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.161.194] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] CDNI Logging Informal Meeting Monday 29 Jul @1:00pm meet at registration desk X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 09:58:58 -0000 Folks, We'll be holding an informal meeting on cdni-loggin: Monday 29 Jul=20 1:00pm to 2:30pm Meet at registration desk In particular, we'll discuss: * details of CDNI Logging Feed * non-repudiation * open items * whatever comments you may have on -05 cheers Francoi, Iuniana, Roy From Jan.Seedorf@neclab.eu Sun Jul 28 01:21:26 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A2021F9D53 for ; Sun, 28 Jul 2013 01:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.297 X-Spam-Level: X-Spam-Status: No, score=-103.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWmQRfpWtGqg for ; Sun, 28 Jul 2013 01:21:21 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id C1D0321F9D98 for ; Sun, 28 Jul 2013 01:21:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 307A3104D26 for ; Sun, 28 Jul 2013 10:20:14 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yO5jLhg7iGlA for ; Sun, 28 Jul 2013 10:20:14 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 13C51104D25 for ; Sun, 28 Jul 2013 10:20:09 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Sun, 28 Jul 2013 10:20:31 +0200 From: Jan Seedorf To: "cdni@ietf.org" Thread-Topic: Timeslot for CDNI Footprint/Capabilities Side Meeting @IETF87 Thread-Index: Ac6Lajr6huuFn5SlSnOjNL1d9xbo5Q== Date: Sun, 28 Jul 2013 08:20:30 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE55595DCD@DAPHNIS.office.hd> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.213] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting @IETF87 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 08:21:26 -0000 Dear all, According to the doodle, the best timeslot where actually everybody can mak= e it is: *** THU, 13:00-15:00 *** So let's meet at 13:00 at the IETF registration desk, find a room, and then= go through the open issues case-by-case. - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Jan Seedorf > Sent: Wednesday, July 24, 2013 12:14 PM > To: cdni@ietf.org > Subject: [CDNi] Doodle for CDNI Footprint/Capabilities Design Team Side > Meeting @IETF87 >=20 > http://doodle.com/zv6b5gfbf22m9hk7 >=20 > Please fill in latest by Sunday >=20 > - Jan >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > Jan Seedorf > Senior Researcher > NEC Europe Ltd., NEC Laboratories Europe, Network Division > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel.=A0=A0=A0=A0 +49 (0)6221 4342-221 > Fax:=A0=A0=A0=A0 +49 (0)6221 4342-155 > e-mail:=A0 jan.seedorf@neclab.eu > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D > NEC Europe Ltd, Registered Office: Athene, Odyssey Business Park, West En= d > Road, London, HA4 6QE, GB, Registered in England 2832014 >=20 >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From david@mandelberg.org Sun Jul 28 12:34:05 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC48A21F9D62 for ; Sun, 28 Jul 2013 12:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.022 X-Spam-Level: ** X-Spam-Status: No, score=2.022 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_44=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCVmrbXs3I4J for ; Sun, 28 Jul 2013 12:34:01 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id D674521F9D28 for ; Sun, 28 Jul 2013 12:33:54 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id 5v0N1m0061swQuc58vZugX; Sun, 28 Jul 2013 19:33:54 +0000 Received: from uriel.mandelberg.org ([67.189.168.202]) by omta15.westchester.pa.mail.comcast.net with comcast id 5vZt1m0114NM02B3bvZudU; Sun, 28 Jul 2013 19:33:54 +0000 Received: from secure.mandelberg.org (unknown [10.1.2.3]) by uriel.mandelberg.org (Postfix) with ESMTP id 27B471C6095 for ; Sun, 28 Jul 2013 15:35:08 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 28 Jul 2013 21:35:08 +0200 From: David Mandelberg To: Message-ID: <1de580de4d7046fbffaf6339f1671462@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375040034; bh=14BnogE2DDIhWHEB0rc068QryHrjbcormr2a7sH3N38=; h=Received:Received:Received:MIME-Version:Content-Type:Date:From:To: Subject:Message-ID; b=Ocej1efrc1VydN/3t49rmH1EBJWuqxBwRc/UqwSkR17FVtltEc+D94b+xiSgJD+tb YGFuKJqFW/mFMn+y/bQgpGf/PWYgTo4IkZnnyIYx82+RpCvmC7wO8DjMB01tKSlLsF MU9Xb94uE1QBmzEsj8KZq7cwJjp4bUlaca2VUXX8KKMZ/OVIAmlkjW6QAnVm1D0Xd2 K7CpA6Pyc71UGYoNbnDTAD6gLfu6pSEkP+LasFcRbV+LyR9x0NQ7toPgQpmNLtQGy8 qVbM9kYyT3RrIjhidW9fyL7SoUcg31g/zMuaUaA8a0qtIEl4ptZ+Z6ZC8udXIydlmZ UJ7G7gf+vHuAw== Subject: [CDNi] placement of logging non-repudiation attributes X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 19:34:06 -0000 Hi, At one of the informal meetings, we decided to put the data needed for non-repudiation in the log feed instead of in individual log files. I've looked around a bit, but I didn't find any way to add arbitrary key-value pairs to an ATOM feed in a way that existing ATOM parsers can use. This leads me to two questions: 1. Can somebody point me to a mechanism to add the data to the ATOM feed? 2. If not, how do people feel about adding an additional atom:link attribute and putting the non-repudiation data in a separate (small) file for each log file? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From kevin.ma@azukisystems.com Sun Jul 28 15:44:47 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A35421F9929 for ; Sun, 28 Jul 2013 15:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27k36y6R1Zs1 for ; Sun, 28 Jul 2013 15:44:43 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2342C21F95DC for ; Sun, 28 Jul 2013 15:44:42 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 6C89B8BEA09; Sun, 28 Jul 2013 18:39:42 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB024.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id B080B8BE8DD; Sun, 28 Jul 2013 18:39:41 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB024.mail.lan ([10.110.17.24]) with mapi; Sun, 28 Jul 2013 18:43:41 -0400 From: Kevin J Ma To: "Kent Leung (kleung)" , "Scott Wainner (swainner)" , "cdni@ietf.org" Date: Sun, 28 Jul 2013 18:44:34 -0400 Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt Thread-Index: AQHOglKtSpQ+c/DHq0CQax3bMEcDKJloK3IAgBKLZzA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6665133C116@MAILR002.mail.lan> References: <20130531152617.26809.88399.idtracker@ietfa.amsl.com> <51E59162.2030909@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 22:44:47 -0000 Hi Kent, I finally got around to reading the draft and had a couple comments: - I'd like to reiterate the point scott made about the query string: > sw> This example assumes there were no previously defined query string > parameters. We need to specify exactly what is provided as input into > the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do we > include previously define query string parameters that existing on the > URL or only the path. I find that clients may need to include query > strings to facilitate CDN selection or bias decisions. If the client > inserts a query string and that portion is validated by the HMAC, then > the client will invalidate the signature. Perhaps this is motivation > for using the tokenized method. The client can insert query strings in > front of the token query parameter without invalidating the URL. > > KL> This is an example, which is used to keep it simple. Step #2 covers > the procedure to include existing query string. Does that answer your > question? Step #2 seems to assume that no downstream entity is going to insert anything else into the query string, which is probably not a safe assumpt= ion. Cache busting and tracking parameters get appended all the time? And theres nothing that prevents duplicate parameter names from being inserte= d either downstream, or even by the CSP. We need to be able to uniquely identify the parts of the original URI that are being validated. There is also a UST requirement in 2.4: "The attribute MUST be the last attribute in the query string of the UR= I." This can be enforced at the time of signing, but at the time of verificat= ion we need to be able to reconstruct the exact URI that was signed. That te= xt probably needs to be more precise. And in section 4, the second step 1 for validating the URI says: "Copy the Original URI" But, it is not clear how to we know what the original URI was? - "Key ID (KID) [optiona]" -> Key ID (KID) [optional]" - Is there a reason to separate MD and SD? Is it just to be semantically explicit? (Is it not implicit in the KID?) - In section 3, step 9.A.i says: "Convert the message digest to its equivalent human readable value." We should probably explicity define the format? hex? base64? - In section 3, steps 9.B.c and 9.B.i, do we need to be concerned about the use of reserved characters? And if those characters have to be escaped, is the signature performed before or after escaping? - In step 2 of the tokenizing procedure: ") Note:" -> "). Note:" I found this sentance to be a little bit confusing, because it talks abou= t the signature, but then it gives an example of the message the signature is being calculated over, and then has a note about the signature, but the signature is never shown. I think the example of the message is confusing within the context of the signature. thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Kent Leung (kleung) > Sent: Tuesday, July 16, 2013 11:29 PM > To: Scott Wainner (swainner); cdni@ietf.org > Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri= - > signing-02.txt >=20 > Hi Scott. Thanks for the feedback. See my comments below. >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Scott Wainner (swainner) > Sent: Tuesday, July 16, 2013 11:31 AM > To: cdni@ietf.org > Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri= - > signing-02.txt >=20 > Kent, >=20 > Some comments and thoughts ... >=20 > Scott >=20 > 2. Signed URI Format >=20 > o Enforcement Attributes: Attributes that are used to enforce a > distribution policy defined by the CSP. Examples of enforcement > attributes are IP address of the UA and time window. >=20 > sw> We need to clarify if this is the IP address assigned to the client > (often a 192.168.0.x address) or the public IP address presented to the > system (i.e. post NAT'd). I presume the latter. >=20 > KL> The IP address is the IP address in the IP header of the HTTP request > message as seen by the CDN. We can add some clarification if needed. >=20 > 2.1 Enforcement Attributes >=20 > o Client IP (CIP) [optional] - IP address of the client for which > this signed URI is generated. This is represented in dotted > decimal format for IPv4 or canonical text representation for IPv6 > address [RFC5952] . The request is rejected if sourced from a > client with a different IP address. >=20 > sw> We need to clarify if this is the IP address assigned to the client > or the IP address representing the client's public appearance on the > Internet. I presume the latter; the CSP will see the public IP address. >=20 > KL> See previous comment. >=20 > 2.2. Signature Computation Attributes >=20 > o Hash Function (HF) [optional] - A string used for identifying the > hash function to compute the URI signature (e.g. "MD5", "SHA1") > with HMAC. >=20 > sw> Should we not define a mandatory set of methods? MD5, SHA-1, SHA-256? >=20 > KL> I'm open to suggestions. We need to consider current deployments. On= e > reason for being optional is that the hash function may be obtained via > CDNI metadata. As for the mandatory hash functions that need to be > supported, I think MD5 and SHA1 can be good candidates. >=20 > 3. Signing a URI > 9. Depending on the type of key used to sign the URI, compute the > message digest or digital signature for symmetric key or > asymmetric keys, respectively. >=20 > A. For symmetric key, HMAC is used. > j. Append the string for the message digest (e.g. ":// > example.com/ > content.mov?VER=3D1&ET=3D1209422976&CIP=3D10.0.0.1& > KID=3Dexample:keys:123&HF=3DSHA-1& > MD=3D4fb1c1adf1588fbe11cc6a04c6e69f35"). >=20 > sw> This example assumes there were no previously defined query string > parameters. We need to specify exactly what is provided as input into > the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do we > include previously define query string parameters that existing on the > URL or only the path. I find that clients may need to include query > strings to facilitate CDN selection or bias decisions. If the client > inserts a query string and that portion is validated by the HMAC, then > the client will invalidate the signature. Perhaps this is motivation > for using the tokenized method. The client can insert query strings in > front of the token query parameter without invalidating the URL. >=20 > KL> This is an example, which is used to keep it simple. Step #2 covers > the procedure to include existing query string. Does that answer your > question? >=20 > 4. Validating a URI Signature >=20 > 4. Extract the value from "CIP" attribute if the attribute exists. > Validate that the request came from the same IP address as > indicated in the "CIP" attribute. If the IP address is > incorrect, then the request is denied. >=20 > sw> Sounds like we're using the IP address presented by the client and > not the IP address assigned to the client. >=20 > KL> Yes, as mentioned in previous comment. >=20 > 4. Validating a URI Signature >=20 > 8. If neither "MD" or "DS" attribute is in the URI, then no URI >=20 > sw> This implies that URL Signing is required. Presumably, we can > configure the system such that we know if incoming URL's should or > should not be signed. What is the criteria and how do we determine if > the criteria is met? >=20 > KL> When URL Signing is configured to be validated, then these attributes > need to be in the URI. Yes, it's possible that URI Signing is > configured. I had put this under the CDNI Metadata Interface. See below >=20 > o Type of access control. Specifically, access to content is > subject to URI Signing. URI Signing required indication means > Downstream CDN ensures URI must be signed and validated before > content delivery. Otherwise, Downstream CDN does not perform > validation regardless if URI is signed or not. >=20 > I guess we can say that this can be "set by configuration or CDNI > metadata" as noted in other areas. >=20 >=20 > 5.3. CDNI Metadata Interface >=20 > o Content access control indication. >=20 > sw> Is the access control defined on a per object request (manifest / > segment) or class of service request? A class of service request (e.g. > http://service_path/media_path/media?foo) might indicate ALL media > objects associated with the "://service_path/" require access control. > How do we define the scope of access control for URL signing? >=20 > KL> I assume that the access control scope is based on the scope of the > metadata. So it can be for a specific content or a group of content. >=20 > o Encoding format to override the "UST" attribute. (Editor Note: Is > this needed in CDNI Metadata or defined in a new CDNI attribute?) >=20 > sw> What is implied by the statement 'override'. Presumably, the UST > can be transparently passed from surrogate to surrogate even while the > domain, path, and query parameters (outside of the UST) are changed. > That is because the UST contains the validated attributes. >=20 > KL> The override is meant to use another attribute name instead of "UST" > to carry the URI Signing token value. Just a method to provide flexibilit= y > on the attribute name. >=20 > Kent >=20 >=20 > On 5/31/13 11:35 AM, Kent Leung (kleung) wrote: > > Hi folks. We've made some updates based on the WG feedback and interna= l > discussions. Comments are welcome. Thanks. > > > > Kent > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, May 31, 2013 8:26 AM > > To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung); Francois > Le Faucheur (flefauch); Bill Downey > > Subject: New Version Notification for draft-leung-cdni-uri-signing- > 02.txt > > > > > > A new version of I-D, draft-leung-cdni-uri-signing-02.txt > > has been successfully submitted by Kent Leung and posted to the IETF > repository. > > > > Filename: draft-leung-cdni-uri-signing > > Revision: 02 > > Title: URI Signing for CDN Interconnection (CDNI) > > Creation date: 2013-05-31 > > Group: Individual Submission > > Number of pages: 29 > > URL: http://www.ietf.org/internet-drafts/draft-leung-cdni- > uri-signing-02.txt > > Status: http://datatracker.ietf.org/doc/draft-leung-cdni-uri- > signing > > Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri- > signing-02 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni-ur= i- > signing-02 > > > > Abstract: > > This document describes how the concept of URI signing supports the > > content access control requirements of CDNI and proposes a candidat= e > > 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 request for the content referenced by the URI. Som= e > > of the information may be accessed by the CDN via configuration or > > CDNI metadata. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > 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 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From sleibrand@llnw.com Sun Jul 28 18:46:55 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A4321F9EDD for ; Sun, 28 Jul 2013 18:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.603 X-Spam-Level: X-Spam-Status: No, score=-0.603 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVaa3UEEVp+N for ; Sun, 28 Jul 2013 18:46:51 -0700 (PDT) Received: from exprod5og118.obsmtp.com (exprod5og118.obsmtp.com [64.18.0.160]) by ietfa.amsl.com (Postfix) with ESMTP id 0FEAF21F9EDA for ; Sun, 28 Jul 2013 18:46:50 -0700 (PDT) Received: from mail-oa0-f50.google.com ([209.85.219.50]) (using TLSv1) by exprod5ob118.postini.com ([64.18.4.12]) with SMTP ID DSNKUfXJiQnwH7l1t3tPwqsM7Xfsc34+OSUC@postini.com; Sun, 28 Jul 2013 18:46:51 PDT Received: by mail-oa0-f50.google.com with SMTP id k7so11735588oag.37 for ; Sun, 28 Jul 2013 18:46:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to :x-gm-message-state; bh=3o36RI6KMBVRMzZ7TaBMkbKnKeIC3nJAfqx2p/5EEIY=; b=fXWT9nGDuG9QEGFQt5d7u4GfMdpPxaPEB5h7gLdT3FJ8mCS4pMMJ8NZGiiY7DB7Oye Cy8fUqBw2bVenhwGRpTiXHqWi/ZUm9aXVP2DRoUzJhtIy/1kHGMoeMKflf2oLY8BS+jX g6PrfVanTQwSnV+HB6f7+rx400dHHBf9tToUJSFTK511GlJZo2Q4kwi/MDs4M5Q379+N WX+kfn9oYacICZjcoB8lvrqaNOjgzbQJRIZkvRuw13AFV696O9XxDTpMKhwUFL50uUZb sdnfSzfqBiAF/I+360ftZKTVuiQ4xbpI8rDfqmYb7VkkG20+LwFjfTFiIfSViTyrV8Ap jOGA== X-Received: by 10.182.34.136 with SMTP id z8mr48276080obi.43.1375062408713; Sun, 28 Jul 2013 18:46:48 -0700 (PDT) X-Received: by 10.182.34.136 with SMTP id z8mr48276072obi.43.1375062408599; Sun, 28 Jul 2013 18:46:48 -0700 (PDT) Received: from [10.118.158.212] (mobile-166-147-081-065.mycingular.net. [166.147.81.65]) by mx.google.com with ESMTPSA id y6sm879670oej.4.2013.07.28.18.46.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Jul 2013 18:46:47 -0700 (PDT) References: <20130531152617.26809.88399.idtracker@ietfa.amsl.com> <51E59162.2030909@cisco.com> <291CC3F9E50E7641901A54E85D0977C6665133C116@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6665133C116@MAILR002.mail.lan> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6C4BD917-6058-40DB-864D-2F2481250D46@llnw.com> X-Mailer: iPhone Mail (10B350) From: Scott Leibrand Date: Sun, 28 Jul 2013 18:46:44 -0700 To: Kevin J Ma X-Gm-Message-State: ALoCoQmAorrZ8P759WjgpvJqCs2jiLYnvyD9NWGkV4eVc7aM2s3oieFkTp3FGPIIGREWD3rem0HD5sAQ2k8YR+Avs3X5kD2MfbN0sOhTmaAAyns2RmHS3XZPPhBBZAFG23wsIJD7LzmK Cc: "cdni@ietf.org" Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 01:46:55 -0000 In our implementation, anything to the left of the hash (h=3D for us) is use= d to generate the signature, and can't be changed by the client without caus= ing the signature validation to fail. This prevents the client from changing= the expire time or IP, for example. But anything to the right of the hash i= s not included, so the client can append other query terms without affecting= the signature.=20 Scott On Jul 28, 2013, at 3:44 PM, Kevin J Ma wrote: > Hi Kent, >=20 > I finally got around to reading the draft and had a couple comments: >=20 > - I'd like to reiterate the point scott made about the query string: >=20 >> sw> This example assumes there were no previously defined query string >> parameters. We need to specify exactly what is provided as input into >> the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do we >> include previously define query string parameters that existing on the >> URL or only the path. I find that clients may need to include query >> strings to facilitate CDN selection or bias decisions. If the client >> inserts a query string and that portion is validated by the HMAC, then >> the client will invalidate the signature. Perhaps this is motivation >> for using the tokenized method. The client can insert query strings in >> front of the token query parameter without invalidating the URL. >>=20 >> KL> This is an example, which is used to keep it simple. Step #2 covers >> the procedure to include existing query string. Does that answer your >> question? >=20 > Step #2 seems to assume that no downstream entity is going to insert > anything else into the query string, which is probably not a safe assumpt= ion. > Cache busting and tracking parameters get appended all the time? And > theres nothing that prevents duplicate parameter names from being inserte= d > either downstream, or even by the CSP. We need to be able to uniquely > identify the parts of the original URI that are being validated. >=20 > There is also a UST requirement in 2.4: >=20 > "The attribute MUST be the last attribute in the query string of the UR= I." >=20 > This can be enforced at the time of signing, but at the time of verificat= ion > we need to be able to reconstruct the exact URI that was signed. That te= xt > probably needs to be more precise. >=20 > And in section 4, the second step 1 for validating the URI says: >=20 > "Copy the Original URI" >=20 > But, it is not clear how to we know what the original URI was? >=20 > - "Key ID (KID) [optiona]" -> Key ID (KID) [optional]" >=20 > - Is there a reason to separate MD and SD? Is it just to be semantically > explicit? (Is it not implicit in the KID?) >=20 > - In section 3, step 9.A.i says: >=20 > "Convert the message digest to its equivalent human readable value." >=20 > We should probably explicity define the format? hex? base64? >=20 > - In section 3, steps 9.B.c and 9.B.i, do we need to be concerned about > the use of reserved characters? And if those characters have to be > escaped, is the signature performed before or after escaping? >=20 > - In step 2 of the tokenizing procedure: ") Note:" -> "). Note:" >=20 > I found this sentance to be a little bit confusing, because it talks abou= t > the signature, but then it gives an example of the message the signature > is being calculated over, and then has a note about the signature, but > the signature is never shown. I think the example of the message is > confusing within the context of the signature. >=20 > thanx. >=20 > -- Kevin J. Ma >=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> Kent Leung (kleung) >> Sent: Tuesday, July 16, 2013 11:29 PM >> To: Scott Wainner (swainner); cdni@ietf.org >> Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri= - >> signing-02.txt >>=20 >> Hi Scott. Thanks for the feedback. See my comments below. >>=20 >> -----Original Message----- >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of >> Scott Wainner (swainner) >> Sent: Tuesday, July 16, 2013 11:31 AM >> To: cdni@ietf.org >> Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri= - >> signing-02.txt >>=20 >> Kent, >>=20 >> Some comments and thoughts ... >>=20 >> Scott >>=20 >> 2. Signed URI Format >>=20 >> o Enforcement Attributes: Attributes that are used to enforce a >> distribution policy defined by the CSP. Examples of enforcement >> attributes are IP address of the UA and time window. >>=20 >> sw> We need to clarify if this is the IP address assigned to the client >> (often a 192.168.0.x address) or the public IP address presented to the >> system (i.e. post NAT'd). I presume the latter. >>=20 >> KL> The IP address is the IP address in the IP header of the HTTP request= >> message as seen by the CDN. We can add some clarification if needed. >>=20 >> 2.1 Enforcement Attributes >>=20 >> o Client IP (CIP) [optional] - IP address of the client for which >> this signed URI is generated. This is represented in dotted >> decimal format for IPv4 or canonical text representation for IPv6 >> address [RFC5952] . The request is rejected if sourced from a >> client with a different IP address. >>=20 >> sw> We need to clarify if this is the IP address assigned to the client >> or the IP address representing the client's public appearance on the >> Internet. I presume the latter; the CSP will see the public IP address. >>=20 >> KL> See previous comment. >>=20 >> 2.2. Signature Computation Attributes >>=20 >> o Hash Function (HF) [optional] - A string used for identifying the >> hash function to compute the URI signature (e.g. "MD5", "SHA1") >> with HMAC. >>=20 >> sw> Should we not define a mandatory set of methods? MD5, SHA-1, SHA-256?= >>=20 >> KL> I'm open to suggestions. We need to consider current deployments. On= e >> reason for being optional is that the hash function may be obtained via >> CDNI metadata. As for the mandatory hash functions that need to be >> supported, I think MD5 and SHA1 can be good candidates. >>=20 >> 3. Signing a URI >> 9. Depending on the type of key used to sign the URI, compute the >> message digest or digital signature for symmetric key or >> asymmetric keys, respectively. >>=20 >> A. For symmetric key, HMAC is used. >> j. Append the string for the message digest (e.g. ":// >> example.com/ >> content.mov?VER=3D1&ET=3D1209422976&CIP=3D10.0.0.1& >> KID=3Dexample:keys:123&HF=3DSHA-1& >> MD=3D4fb1c1adf1588fbe11cc6a04c6e69f35"). >>=20 >> sw> This example assumes there were no previously defined query string >> parameters. We need to specify exactly what is provided as input into >> the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do we >> include previously define query string parameters that existing on the >> URL or only the path. I find that clients may need to include query >> strings to facilitate CDN selection or bias decisions. If the client >> inserts a query string and that portion is validated by the HMAC, then >> the client will invalidate the signature. Perhaps this is motivation >> for using the tokenized method. The client can insert query strings in >> front of the token query parameter without invalidating the URL. >>=20 >> KL> This is an example, which is used to keep it simple. Step #2 covers >> the procedure to include existing query string. Does that answer your >> question? >>=20 >> 4. Validating a URI Signature >>=20 >> 4. Extract the value from "CIP" attribute if the attribute exists. >> Validate that the request came from the same IP address as >> indicated in the "CIP" attribute. If the IP address is >> incorrect, then the request is denied. >>=20 >> sw> Sounds like we're using the IP address presented by the client and >> not the IP address assigned to the client. >>=20 >> KL> Yes, as mentioned in previous comment. >>=20 >> 4. Validating a URI Signature >>=20 >> 8. If neither "MD" or "DS" attribute is in the URI, then no URI >>=20 >> sw> This implies that URL Signing is required. Presumably, we can >> configure the system such that we know if incoming URL's should or >> should not be signed. What is the criteria and how do we determine if >> the criteria is met? >>=20 >> KL> When URL Signing is configured to be validated, then these attributes= >> need to be in the URI. Yes, it's possible that URI Signing is >> configured. I had put this under the CDNI Metadata Interface. See below >>=20 >> o Type of access control. Specifically, access to content is >> subject to URI Signing. URI Signing required indication means >> Downstream CDN ensures URI must be signed and validated before >> content delivery. Otherwise, Downstream CDN does not perform >> validation regardless if URI is signed or not. >>=20 >> I guess we can say that this can be "set by configuration or CDNI >> metadata" as noted in other areas. >>=20 >>=20 >> 5.3. CDNI Metadata Interface >>=20 >> o Content access control indication. >>=20 >> sw> Is the access control defined on a per object request (manifest / >> segment) or class of service request? A class of service request (e.g. >> http://service_path/media_path/media?foo) might indicate ALL media >> objects associated with the "://service_path/" require access control. >> How do we define the scope of access control for URL signing? >>=20 >> KL> I assume that the access control scope is based on the scope of the >> metadata. So it can be for a specific content or a group of content. >>=20 >> o Encoding format to override the "UST" attribute. (Editor Note: Is >> this needed in CDNI Metadata or defined in a new CDNI attribute?) >>=20 >> sw> What is implied by the statement 'override'. Presumably, the UST >> can be transparently passed from surrogate to surrogate even while the >> domain, path, and query parameters (outside of the UST) are changed. >> That is because the UST contains the validated attributes. >>=20 >> KL> The override is meant to use another attribute name instead of "UST" >> to carry the URI Signing token value. Just a method to provide flexibilit= y >> on the attribute name. >>=20 >> Kent >>=20 >>=20 >> On 5/31/13 11:35 AM, Kent Leung (kleung) wrote: >>> Hi folks. We've made some updates based on the WG feedback and internal= >> discussions. Comments are welcome. Thanks. >>>=20 >>> Kent >>>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Friday, May 31, 2013 8:26 AM >>> To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung); Francois >> Le Faucheur (flefauch); Bill Downey >>> Subject: New Version Notification for draft-leung-cdni-uri-signing- >> 02.txt >>>=20 >>>=20 >>> A new version of I-D, draft-leung-cdni-uri-signing-02.txt >>> has been successfully submitted by Kent Leung and posted to the IETF >> repository. >>>=20 >>> Filename: draft-leung-cdni-uri-signing >>> Revision: 02 >>> Title: URI Signing for CDN Interconnection (CDNI) >>> Creation date: 2013-05-31 >>> Group: Individual Submission >>> Number of pages: 29 >>> URL: http://www.ietf.org/internet-drafts/draft-leung-cdni- >> uri-signing-02.txt >>> Status: http://datatracker.ietf.org/doc/draft-leung-cdni-uri- >> signing >>> Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri- >> signing-02 >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni-uri= - >> signing-02 >>>=20 >>> Abstract: >>> This document describes how the concept of URI signing supports the >>> content access control requirements of CDNI and proposes a candidate >>> URI signing scheme. >>>=20 >>> 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 request for the content referenced by the URI. Some >>> of the information may be accessed by the CDN via configuration or >>> CDNI metadata. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=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 >> _______________________________________________ >> CDNi mailing list >> CDNi@ietf.org >> https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Mon Jul 29 00:10:44 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6BE21F99BA for ; Mon, 29 Jul 2013 00:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpFKOtYO6+NA for ; Mon, 29 Jul 2013 00:10:39 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id DD20A21F99AF for ; Mon, 29 Jul 2013 00:10:29 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9BA997AB612; Mon, 29 Jul 2013 03:05:08 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id BBBDF7AB61C; Mon, 29 Jul 2013 03:05:07 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Mon, 29 Jul 2013 03:09:31 -0400 From: Kevin J Ma To: Scott Leibrand Date: Mon, 29 Jul 2013 03:10:24 -0400 Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt Thread-Index: Ac6L/XqUCbggJQ7NR6qoOgEyUmJ86wAKw9Xg Message-ID: <291CC3F9E50E7641901A54E85D0977C6665133C138@MAILR002.mail.lan> References: <20130531152617.26809.88399.idtracker@ietfa.amsl.com> <51E59162.2030909@cisco.com> <291CC3F9E50E7641901A54E85D0977C6665133C116@MAILR002.mail.lan> <6C4BD917-6058-40DB-864D-2F2481250D46@llnw.com> In-Reply-To: <6C4BD917-6058-40DB-864D-2F2481250D46@llnw.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 07:10:44 -0000 Hi Scott, If thats ok with everyone else, it's ok with me, but I think we need to b= e more precise in how we specify it, e.g., extract the right most ET value which appears before the right most MD/DS, and any duplicate parameter na= mes or rearranging of parameters is explicitly prohibited, so if the CSP has = an existing extra terestrial variable ET, it must appear to the left of the expiration time ET variable, which must appear to the left of the MD/DS, = and if the client inserts an element tracking variable ET, it must appear to = the right of the MD/DS, and reordering of the query string is not allowed. thanx. -- Kevin J. Ma > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand@llnw.com] > Sent: Sunday, July 28, 2013 9:47 PM > To: Kevin J Ma > Cc: Kent Leung (kleung); Scott Wainner (swainner); cdni@ietf.org > Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri= - > signing-02.txt >=20 > In our implementation, anything to the left of the hash (h=3D for us) is > used to generate the signature, and can't be changed by the client withou= t > causing the signature validation to fail. This prevents the client from > changing the expire time or IP, for example. But anything to the right of > the hash is not included, so the client can append other query terms > without affecting the signature. >=20 > Scott >=20 > On Jul 28, 2013, at 3:44 PM, Kevin J Ma wrote= : >=20 > > Hi Kent, > > > > I finally got around to reading the draft and had a couple comments: > > > > - I'd like to reiterate the point scott made about the query string: > > > >> sw> This example assumes there were no previously defined query string > >> parameters. We need to specify exactly what is provided as input into > >> the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do w= e > >> include previously define query string parameters that existing on the > >> URL or only the path. I find that clients may need to include query > >> strings to facilitate CDN selection or bias decisions. If the client > >> inserts a query string and that portion is validated by the HMAC, then > >> the client will invalidate the signature. Perhaps this is motivation > >> for using the tokenized method. The client can insert query strings i= n > >> front of the token query parameter without invalidating the URL. > >> > >> KL> This is an example, which is used to keep it simple. Step #2 cover= s > >> the procedure to include existing query string. Does that answer your > >> question? > > > > Step #2 seems to assume that no downstream entity is going to insert > > anything else into the query string, which is probably not a safe > assumption. > > Cache busting and tracking parameters get appended all the time? And > > theres nothing that prevents duplicate parameter names from being > inserted > > either downstream, or even by the CSP. We need to be able to uniquely > > identify the parts of the original URI that are being validated. > > > > There is also a UST requirement in 2.4: > > > > "The attribute MUST be the last attribute in the query string of the > URI." > > > > This can be enforced at the time of signing, but at the time of > verification > > we need to be able to reconstruct the exact URI that was signed. That > text > > probably needs to be more precise. > > > > And in section 4, the second step 1 for validating the URI says: > > > > "Copy the Original URI" > > > > But, it is not clear how to we know what the original URI was? > > > > - "Key ID (KID) [optiona]" -> Key ID (KID) [optional]" > > > > - Is there a reason to separate MD and SD? Is it just to be > semantically > > explicit? (Is it not implicit in the KID?) > > > > - In section 3, step 9.A.i says: > > > > "Convert the message digest to its equivalent human readable value." > > > > We should probably explicity define the format? hex? base64? > > > > - In section 3, steps 9.B.c and 9.B.i, do we need to be concerned about > > the use of reserved characters? And if those characters have to be > > escaped, is the signature performed before or after escaping? > > > > - In step 2 of the tokenizing procedure: ") Note:" -> "). Note:" > > > > I found this sentance to be a little bit confusing, because it talks > about > > the signature, but then it gives an example of the message the > signature > > is being calculated over, and then has a note about the signature, but > > the signature is never shown. I think the example of the message is > > confusing within the context of the signature. > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > >> Kent Leung (kleung) > >> Sent: Tuesday, July 16, 2013 11:29 PM > >> To: Scott Wainner (swainner); cdni@ietf.org > >> Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni- > uri- > >> signing-02.txt > >> > >> Hi Scott. Thanks for the feedback. See my comments below. > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf O= f > >> Scott Wainner (swainner) > >> Sent: Tuesday, July 16, 2013 11:31 AM > >> To: cdni@ietf.org > >> Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni- > uri- > >> signing-02.txt > >> > >> Kent, > >> > >> Some comments and thoughts ... > >> > >> Scott > >> > >> 2. Signed URI Format > >> > >> o Enforcement Attributes: Attributes that are used to enforce a > >> distribution policy defined by the CSP. Examples of enforcement > >> attributes are IP address of the UA and time window. > >> > >> sw> We need to clarify if this is the IP address assigned to the clien= t > >> (often a 192.168.0.x address) or the public IP address presented to th= e > >> system (i.e. post NAT'd). I presume the latter. > >> > >> KL> The IP address is the IP address in the IP header of the HTTP > request > >> message as seen by the CDN. We can add some clarification if needed. > >> > >> 2.1 Enforcement Attributes > >> > >> o Client IP (CIP) [optional] - IP address of the client for which > >> this signed URI is generated. This is represented in dotted > >> decimal format for IPv4 or canonical text representation for IPv= 6 > >> address [RFC5952] . The request is rejected if sourced from a > >> client with a different IP address. > >> > >> sw> We need to clarify if this is the IP address assigned to the clien= t > >> or the IP address representing the client's public appearance on the > >> Internet. I presume the latter; the CSP will see the public IP > address. > >> > >> KL> See previous comment. > >> > >> 2.2. Signature Computation Attributes > >> > >> o Hash Function (HF) [optional] - A string used for identifying th= e > >> hash function to compute the URI signature (e.g. "MD5", "SHA1") > >> with HMAC. > >> > >> sw> Should we not define a mandatory set of methods? MD5, SHA-1, SHA- > 256? > >> > >> KL> I'm open to suggestions. We need to consider current deployments. > One > >> reason for being optional is that the hash function may be obtained vi= a > >> CDNI metadata. As for the mandatory hash functions that need to be > >> supported, I think MD5 and SHA1 can be good candidates. > >> > >> 3. Signing a URI > >> 9. Depending on the type of key used to sign the URI, compute the > >> message digest or digital signature for symmetric key or > >> asymmetric keys, respectively. > >> > >> A. For symmetric key, HMAC is used. > >> j. Append the string for the message digest (e.g. ":// > >> example.com/ > >> content.mov?VER=3D1&ET=3D1209422976&CIP=3D10.0.0.1& > >> KID=3Dexample:keys:123&HF=3DSHA-1& > >> MD=3D4fb1c1adf1588fbe11cc6a04c6e69f35"). > >> > >> sw> This example assumes there were no previously defined query string > >> parameters. We need to specify exactly what is provided as input into > >> the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do w= e > >> include previously define query string parameters that existing on the > >> URL or only the path. I find that clients may need to include query > >> strings to facilitate CDN selection or bias decisions. If the client > >> inserts a query string and that portion is validated by the HMAC, then > >> the client will invalidate the signature. Perhaps this is motivation > >> for using the tokenized method. The client can insert query strings i= n > >> front of the token query parameter without invalidating the URL. > >> > >> KL> This is an example, which is used to keep it simple. Step #2 cover= s > >> the procedure to include existing query string. Does that answer your > >> question? > >> > >> 4. Validating a URI Signature > >> > >> 4. Extract the value from "CIP" attribute if the attribute exists. > >> Validate that the request came from the same IP address as > >> indicated in the "CIP" attribute. If the IP address is > >> incorrect, then the request is denied. > >> > >> sw> Sounds like we're using the IP address presented by the client and > >> not the IP address assigned to the client. > >> > >> KL> Yes, as mentioned in previous comment. > >> > >> 4. Validating a URI Signature > >> > >> 8. If neither "MD" or "DS" attribute is in the URI, then no URI > >> > >> sw> This implies that URL Signing is required. Presumably, we can > >> configure the system such that we know if incoming URL's should or > >> should not be signed. What is the criteria and how do we determine if > >> the criteria is met? > >> > >> KL> When URL Signing is configured to be validated, then these > attributes > >> need to be in the URI. Yes, it's possible that URI Signing is > >> configured. I had put this under the CDNI Metadata Interface. See belo= w > >> > >> o Type of access control. Specifically, access to content is > >> subject to URI Signing. URI Signing required indication means > >> Downstream CDN ensures URI must be signed and validated before > >> content delivery. Otherwise, Downstream CDN does not perform > >> validation regardless if URI is signed or not. > >> > >> I guess we can say that this can be "set by configuration or CDNI > >> metadata" as noted in other areas. > >> > >> > >> 5.3. CDNI Metadata Interface > >> > >> o Content access control indication. > >> > >> sw> Is the access control defined on a per object request (manifest / > >> segment) or class of service request? A class of service request (e.g= . > >> http://service_path/media_path/media?foo) might indicate ALL media > >> objects associated with the "://service_path/" require access control. > >> How do we define the scope of access control for URL signing? > >> > >> KL> I assume that the access control scope is based on the scope of th= e > >> metadata. So it can be for a specific content or a group of content. > >> > >> o Encoding format to override the "UST" attribute. (Editor Note: > Is > >> this needed in CDNI Metadata or defined in a new CDNI attribute?= ) > >> > >> sw> What is implied by the statement 'override'. Presumably, the UST > >> can be transparently passed from surrogate to surrogate even while the > >> domain, path, and query parameters (outside of the UST) are changed. > >> That is because the UST contains the validated attributes. > >> > >> KL> The override is meant to use another attribute name instead of > "UST" > >> to carry the URI Signing token value. Just a method to provide > flexibility > >> on the attribute name. > >> > >> Kent > >> > >> > >> On 5/31/13 11:35 AM, Kent Leung (kleung) wrote: > >>> Hi folks. We've made some updates based on the WG feedback and > internal > >> discussions. Comments are welcome. Thanks. > >>> > >>> Kent > >>> > >>> -----Original Message----- > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>> Sent: Friday, May 31, 2013 8:26 AM > >>> To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung); Francoi= s > >> Le Faucheur (flefauch); Bill Downey > >>> Subject: New Version Notification for draft-leung-cdni-uri-signing- > >> 02.txt > >>> > >>> > >>> A new version of I-D, draft-leung-cdni-uri-signing-02.txt > >>> has been successfully submitted by Kent Leung and posted to the IETF > >> repository. > >>> > >>> Filename: draft-leung-cdni-uri-signing > >>> Revision: 02 > >>> Title: URI Signing for CDN Interconnection (CDNI) > >>> Creation date: 2013-05-31 > >>> Group: Individual Submission > >>> Number of pages: 29 > >>> URL: http://www.ietf.org/internet-drafts/draft-leung-cdni= - > >> uri-signing-02.txt > >>> Status: http://datatracker.ietf.org/doc/draft-leung-cdni-uri= - > >> signing > >>> Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri- > >> signing-02 > >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni- > uri- > >> signing-02 > >>> > >>> Abstract: > >>> This document describes how the concept of URI signing supports th= e > >>> content access control requirements of CDNI and proposes a > candidate > >>> URI signing scheme. > >>> > >>> The proposed URI signing method specifies the information needed t= o > >>> be included in the URI and the algorithm used to authorize and to > >>> validate access request for the content referenced by the URI. > Some > >>> of the information may be accessed by the CDN via configuration or > >>> CDNI metadata. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >>> > >>> _______________________________________________ > >>> CDNi mailing list > >>> CDNi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cdni > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Mon Jul 29 00:38:51 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3722A21F9223 for ; Mon, 29 Jul 2013 00:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOAe+ZQtSdbL for ; Mon, 29 Jul 2013 00:38:47 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8B04521F8C93 for ; Mon, 29 Jul 2013 00:38:45 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id E4BBF416831; Mon, 29 Jul 2013 03:36:45 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 47F8C416894; Mon, 29 Jul 2013 03:36:45 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Mon, 29 Jul 2013 03:36:35 -0400 From: Kevin J Ma To: David Mandelberg , "cdni@ietf.org" Date: Mon, 29 Jul 2013 03:38:42 -0400 Thread-Topic: [CDNi] placement of logging non-repudiation attributes Thread-Index: Ac6LyXYjwDu6ueMTSZOuLZWy1LkRpAAZNe3g Message-ID: <291CC3F9E50E7641901A54E85D0977C6665133C139@MAILR002.mail.lan> References: <1de580de4d7046fbffaf6339f1671462@mail.mandelberg.org> In-Reply-To: <1de580de4d7046fbffaf6339f1671462@mail.mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] placement of logging non-repudiation attributes X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 07:38:51 -0000 > 2. If not, how do people feel about adding an additional atom:link > attribute and putting the non-repudiation data in a separate (small) > file for each log file? separate file, or new api (which could be implemented as a file)? > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > David Mandelberg > Sent: Sunday, July 28, 2013 3:35 PM > To: cdni@ietf.org > Subject: [CDNi] placement of logging non-repudiation attributes >=20 > Hi, >=20 > At one of the informal meetings, we decided to put the data needed for > non-repudiation in the log feed instead of in individual log files. I've > looked around a bit, but I didn't find any way to add arbitrary > key-value pairs to an ATOM feed in a way that existing ATOM parsers can > use. This leads me to two questions: >=20 > 1. Can somebody point me to a mechanism to add the data to the ATOM > feed? > 2. If not, how do people feel about adding an additional atom:link > attribute and putting the non-repudiation data in a separate (small) > file for each log file? >=20 > -- > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Mon Jul 29 01:50:57 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F8721F8D73 for ; Mon, 29 Jul 2013 01:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7QllYef9lY6 for ; Mon, 29 Jul 2013 01:50:52 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB7421F918F for ; Mon, 29 Jul 2013 01:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13369; q=dns/txt; s=iport; t=1375087823; x=1376297423; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=n85RanutbE0Yr1XElzQLoItT2p0jWDhj3+E7nieWpOI=; b=KEsSr+JTW+/g97mvLzy20hjupF8ZBZBjsbiV8OhJf5ZifKWpssI8JLHX vewozIHbFqa3IO5mERJPgmIlAv0qZA9dX0WpcfF9I26Jcpc+46XQYbT4I +O+7KYSDc9GpI+loRuWqnFBM15lXif4ibeWXaNhK9y0rYqfIa+FpRhv29 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAKIr9lGtJXHA/2dsb2JhbABRCoMGNUoGvVaBFRZ0giQBAQEDAQEBASQTNAkHBwQCAQgRBAEBAQoUCQcnCxQIAQgCBAESCAGIAQYHBbdLjkSBCDgGgxJvA5kIkCODFIFqJBw X-IronPort-AV: E=Sophos;i="4.89,768,1367971200"; d="scan'208";a="240692470" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2013 08:50:13 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6T8oCWW016388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 08:50:12 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.140]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 03:50:12 -0500 From: "Kent Leung (kleung)" To: Kevin J Ma , "Scott Wainner (swainner)" , "cdni@ietf.org" Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt Thread-Index: AQHOjDiiWrvNnPl3bUWE7wNjj+WDQA== Date: Mon, 29 Jul 2013 08:50:11 +0000 Message-ID: References: <20130531152617.26809.88399.idtracker@ietfa.amsl.com> <51E59162.2030909@cisco.com> <291CC3F9E50E7641901A54E85D0977C6665133C116@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6665133C116@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:50:57 -0000 Hi Kevin. Thanks for the review comments. My comments below. -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Sunday, July 28, 2013 3:45 PM To: Kent Leung (kleung); Scott Wainner (swainner); cdni@ietf.org Subject: RE: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-s= igning-02.txt Hi Kent, I finally got around to reading the draft and had a couple comments: - I'd like to reiterate the point scott made about the query string: > sw> This example assumes there were no previously defined query string > parameters. We need to specify exactly what is provided as input into > the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do we > include previously define query string parameters that existing on the > URL or only the path. I find that clients may need to include query > strings to facilitate CDN selection or bias decisions. If the client > inserts a query string and that portion is validated by the HMAC, then > the client will invalidate the signature. Perhaps this is motivation > for using the tokenized method. The client can insert query strings in > front of the token query parameter without invalidating the URL. > > KL> This is an example, which is used to keep it simple. Step #2 covers > the procedure to include existing query string. Does that answer your > question? Step #2 seems to assume that no downstream entity is going to insert anything else into the query string, which is probably not a safe assumpt= ion. Cache busting and tracking parameters get appended all the time? And theres nothing that prevents duplicate parameter names from being inserte= d either downstream, or even by the CSP. We need to be able to uniquely identify the parts of the original URI that are being validated. There is also a UST requirement in 2.4: "The attribute MUST be the last attribute in the query string of the UR= I." This can be enforced at the time of signing, but at the time of verificat= ion we need to be able to reconstruct the exact URI that was signed. That te= xt probably needs to be more precise. And in section 4, the second step 1 for validating the URI says: "Copy the Original URI" But, it is not clear how to we know what the original URI was? KL> OK. I agree that we need more precise text here. - "Key ID (KID) [optiona]" -> Key ID (KID) [optional]" - Is there a reason to separate MD and SD? Is it just to be semantically explicit? (Is it not implicit in the KID?) KL> Yes, it is to be semantically explicit. The KID is used to reference th= e keying material and not to be overloaded semantically. - In section 3, step 9.A.i says: "Convert the message digest to its equivalent human readable value." We should probably explicity define the format? hex? base64? KL> Agree. The text should be precise. - In section 3, steps 9.B.c and 9.B.i, do we need to be concerned about the use of reserved characters? And if those characters have to be escaped, is the signature performed before or after escaping? KL> Agree this needs to be captured in the text. - In step 2 of the tokenizing procedure: ") Note:" -> "). Note:" KL> OK. I found this sentance to be a little bit confusing, because it talks abou= t the signature, but then it gives an example of the message the signature is being calculated over, and then has a note about the signature, but the signature is never shown. I think the example of the message is confusing within the context of the signature. KL> I see the confusion. The procedure is only for computing the URI Signin= g token. It does not produce the Signed URI which was mistakenly claimed. = The section needs to be worked back into steps 9.A.g and 9.B.e which contai= n the message to be signed. Good catch. Appreciate the thorough review. Kent thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 > Of Kent Leung (kleung) > Sent: Tuesday, July 16, 2013 11:29 PM > To: Scott Wainner (swainner); cdni@ietf.org > Subject: Re: [CDNi] FW: New Version Notification for=20 > draft-leung-cdni-uri- signing-02.txt >=20 > Hi Scott. Thanks for the feedback. See my comments below. >=20 > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf=20 > Of Scott Wainner (swainner) > Sent: Tuesday, July 16, 2013 11:31 AM > To: cdni@ietf.org > Subject: Re: [CDNi] FW: New Version Notification for=20 > draft-leung-cdni-uri- signing-02.txt >=20 > Kent, >=20 > Some comments and thoughts ... >=20 > Scott >=20 > 2. Signed URI Format >=20 > o Enforcement Attributes: Attributes that are used to enforce a > distribution policy defined by the CSP. Examples of enforcement > attributes are IP address of the UA and time window. >=20 > sw> We need to clarify if this is the IP address assigned to the=20 > sw> client > (often a 192.168.0.x address) or the public IP address presented to=20 > the system (i.e. post NAT'd). I presume the latter. >=20 > KL> The IP address is the IP address in the IP header of the HTTP=20 > KL> request > message as seen by the CDN. We can add some clarification if needed. >=20 > 2.1 Enforcement Attributes >=20 > o Client IP (CIP) [optional] - IP address of the client for which > this signed URI is generated. This is represented in dotted > decimal format for IPv4 or canonical text representation for IPv6 > address [RFC5952] . The request is rejected if sourced from a > client with a different IP address. >=20 > sw> We need to clarify if this is the IP address assigned to the=20 > sw> client > or the IP address representing the client's public appearance on the=20 > Internet. I presume the latter; the CSP will see the public IP address. >=20 > KL> See previous comment. >=20 > 2.2. Signature Computation Attributes >=20 > o Hash Function (HF) [optional] - A string used for identifying the > hash function to compute the URI signature (e.g. "MD5", "SHA1") > with HMAC. >=20 > sw> Should we not define a mandatory set of methods? MD5, SHA-1, SHA-256? >=20 > KL> I'm open to suggestions. We need to consider current deployments. =20 > KL> One > reason for being optional is that the hash function may be obtained=20 > via CDNI metadata. As for the mandatory hash functions that need to be=20 > supported, I think MD5 and SHA1 can be good candidates. >=20 > 3. Signing a URI > 9. Depending on the type of key used to sign the URI, compute the > message digest or digital signature for symmetric key or > asymmetric keys, respectively. >=20 > A. For symmetric key, HMAC is used. > j. Append the string for the message digest (e.g. ":// > example.com/ > content.mov?VER=3D1&ET=3D1209422976&CIP=3D10.0.0.1& > KID=3Dexample:keys:123&HF=3DSHA-1& > MD=3D4fb1c1adf1588fbe11cc6a04c6e69f35"). >=20 > sw> This example assumes there were no previously defined query string > parameters. We need to specify exactly what is provided as input into=20 > the HMAC function (PATH ? QUERY_PARAMTERS & SIGNING_PARAMETERS). Do=20 > we include previously define query string parameters that existing on=20 > the URL or only the path. I find that clients may need to include=20 > query strings to facilitate CDN selection or bias decisions. If the=20 > client inserts a query string and that portion is validated by the=20 > HMAC, then the client will invalidate the signature. Perhaps this is=20 > motivation for using the tokenized method. The client can insert=20 > query strings in front of the token query parameter without invalidating = the URL. >=20 > KL> This is an example, which is used to keep it simple. Step #2=20 > KL> covers > the procedure to include existing query string. Does that answer your=20 > question? >=20 > 4. Validating a URI Signature >=20 > 4. Extract the value from "CIP" attribute if the attribute exists. > Validate that the request came from the same IP address as > indicated in the "CIP" attribute. If the IP address is > incorrect, then the request is denied. >=20 > sw> Sounds like we're using the IP address presented by the client and > not the IP address assigned to the client. >=20 > KL> Yes, as mentioned in previous comment. >=20 > 4. Validating a URI Signature >=20 > 8. If neither "MD" or "DS" attribute is in the URI, then no URI >=20 > sw> This implies that URL Signing is required. Presumably, we can > configure the system such that we know if incoming URL's should or=20 > should not be signed. What is the criteria and how do we determine if=20 > the criteria is met? >=20 > KL> When URL Signing is configured to be validated, then these=20 > KL> attributes > need to be in the URI. Yes, it's possible that URI Signing is=20 > configured. I had put this under the CDNI Metadata Interface. See=20 > below >=20 > o Type of access control. Specifically, access to content is > subject to URI Signing. URI Signing required indication means > Downstream CDN ensures URI must be signed and validated before > content delivery. Otherwise, Downstream CDN does not perform > validation regardless if URI is signed or not. >=20 > I guess we can say that this can be "set by configuration or CDNI=20 > metadata" as noted in other areas. >=20 >=20 > 5.3. CDNI Metadata Interface >=20 > o Content access control indication. >=20 > sw> Is the access control defined on a per object request (manifest / > segment) or class of service request? A class of service request (e.g. > http://service_path/media_path/media?foo) might indicate ALL media=20 > objects associated with the "://service_path/" require access control. > How do we define the scope of access control for URL signing? >=20 > KL> I assume that the access control scope is based on the scope of=20 > KL> the > metadata. So it can be for a specific content or a group of content. >=20 > o Encoding format to override the "UST" attribute. (Editor Note: Is > this needed in CDNI Metadata or defined in a new CDNI=20 > attribute?) >=20 > sw> What is implied by the statement 'override'. Presumably, the UST > can be transparently passed from surrogate to surrogate even while the=20 > domain, path, and query parameters (outside of the UST) are changed. > That is because the UST contains the validated attributes. >=20 > KL> The override is meant to use another attribute name instead of "UST" > to carry the URI Signing token value. Just a method to provide=20 > flexibility on the attribute name. >=20 > Kent >=20 >=20 > On 5/31/13 11:35 AM, Kent Leung (kleung) wrote: > > Hi folks. We've made some updates based on the WG feedback and=20 > > internal > discussions. Comments are welcome. Thanks. > > > > Kent > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Friday, May 31, 2013 8:26 AM > > To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung);=20 > > Francois > Le Faucheur (flefauch); Bill Downey > > Subject: New Version Notification for draft-leung-cdni-uri-signing- > 02.txt > > > > > > A new version of I-D, draft-leung-cdni-uri-signing-02.txt > > has been successfully submitted by Kent Leung and posted to the IETF > repository. > > > > Filename: draft-leung-cdni-uri-signing > > Revision: 02 > > Title: URI Signing for CDN Interconnection (CDNI) > > Creation date: 2013-05-31 > > Group: Individual Submission > > Number of pages: 29 > > URL: http://www.ietf.org/internet-drafts/draft-leung-cdni- > uri-signing-02.txt > > Status: http://datatracker.ietf.org/doc/draft-leung-cdni-uri- > signing > > Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri- > signing-02 > > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni-ur= i- > signing-02 > > > > Abstract: > > This document describes how the concept of URI signing supports the > > content access control requirements of CDNI and proposes a candidat= e > > 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 request for the content referenced by the URI. Som= e > > of the information may be accessed by the CDN via configuration or > > CDNI metadata. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > 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 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Mon Jul 29 01:52:17 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93B621F90FD for ; Mon, 29 Jul 2013 01:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqjbOxhMrBu6 for ; Mon, 29 Jul 2013 01:52:12 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 05D4E11E80A2 for ; Mon, 29 Jul 2013 01:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15378; q=dns/txt; s=iport; t=1375087928; x=1376297528; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=N7+NDMkfC2Y4KtQ0aDTKxU2XDz0pqnOa7LSnTZU6USU=; b=eo5h0bHAJ3d56H8NdtfWc92Jij/fFD2dsvh+bOJr7ML8D9rWIbOuoVfq 5+I82BTTI/g/r1PCVtRDedXMjCD3dlo9t5DDWjeeegNBQGguexsBmh1F2 YmqIDQTtfnuvl4NrJEE/r5OHma6jNRQ1mSdZahsDOhz0W7Y10N7Gr0PA6 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAP8s9lGtJXG9/2dsb2JhbABRCoMGNUoGvVaBFRZ0giQBAQEDAQEBASQTNAkCDAQCAQgRBAEBAQoUCQcnCxQIAQgCBAENBQgBiAEGBwW3PY5EgQgxBwaDEm8DmQiQI4MUgWokHA X-IronPort-AV: E=Sophos;i="4.89,768,1367971200"; d="scan'208";a="240693194" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2013 08:52:01 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6T8q1A4009021 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Jul 2013 08:52:01 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.140]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 03:52:00 -0500 From: "Kent Leung (kleung)" To: Kevin J Ma , Scott Leibrand Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt Thread-Index: AQHOjDjj6d0Yqhbnw06JhJVikQp63w== Date: Mon, 29 Jul 2013 08:51:59 +0000 Message-ID: References: <20130531152617.26809.88399.idtracker@ietfa.amsl.com> <51E59162.2030909@cisco.com> <291CC3F9E50E7641901A54E85D0977C6665133C116@MAILR002.mail.lan> <6C4BD917-6058-40DB-864D-2F2481250D46@llnw.com> <291CC3F9E50E7641901A54E85D0977C6665133C138@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6665133C138@MAILR002.mail.lan> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "cdni@ietf.org" Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:52:17 -0000 I agree that the text needs more clarifications on the sequencing of attrib= utes. Thanks. Kent -----Original Message----- From: Kevin J Ma [mailto:kevin.ma@azukisystems.com]=20 Sent: Monday, July 29, 2013 12:10 AM To: Scott Leibrand Cc: Kent Leung (kleung); Scott Wainner (swainner); cdni@ietf.org Subject: RE: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-s= igning-02.txt Hi Scott, If thats ok with everyone else, it's ok with me, but I think we need to b= e more precise in how we specify it, e.g., extract the right most ET value which appears before the right most MD/DS, and any duplicate parameter na= mes or rearranging of parameters is explicitly prohibited, so if the CSP has = an existing extra terestrial variable ET, it must appear to the left of the expiration time ET variable, which must appear to the left of the MD/DS, = and if the client inserts an element tracking variable ET, it must appear to = the right of the MD/DS, and reordering of the query string is not allowed. thanx. -- Kevin J. Ma > -----Original Message----- > From: Scott Leibrand [mailto:sleibrand@llnw.com] > Sent: Sunday, July 28, 2013 9:47 PM > To: Kevin J Ma > Cc: Kent Leung (kleung); Scott Wainner (swainner); cdni@ietf.org > Subject: Re: [CDNi] FW: New Version Notification for=20 > draft-leung-cdni-uri- signing-02.txt >=20 > In our implementation, anything to the left of the hash (h=3D for us) is= =20 > used to generate the signature, and can't be changed by the client=20 > without causing the signature validation to fail. This prevents the=20 > client from changing the expire time or IP, for example. But anything=20 > to the right of the hash is not included, so the client can append=20 > other query terms without affecting the signature. >=20 > Scott >=20 > On Jul 28, 2013, at 3:44 PM, Kevin J Ma wrote= : >=20 > > Hi Kent, > > > > I finally got around to reading the draft and had a couple comments: > > > > - I'd like to reiterate the point scott made about the query string: > > > >> sw> This example assumes there were no previously defined query=20 > >> sw> string > >> parameters. We need to specify exactly what is provided as input=20 > >> into the HMAC function (PATH ? QUERY_PARAMTERS &=20 > >> SIGNING_PARAMETERS). Do we include previously define query string=20 > >> parameters that existing on the URL or only the path. I find that=20 > >> clients may need to include query strings to facilitate CDN=20 > >> selection or bias decisions. If the client inserts a query string=20 > >> and that portion is validated by the HMAC, then the client will=20 > >> invalidate the signature. Perhaps this is motivation for using the=20 > >> tokenized method. The client can insert query strings in front of the= token query parameter without invalidating the URL. > >> > >> KL> This is an example, which is used to keep it simple. Step #2=20 > >> KL> covers > >> the procedure to include existing query string. Does that answer=20 > >> your question? > > > > Step #2 seems to assume that no downstream entity is going to=20 > > insert anything else into the query string, which is probably not a=20 > > safe > assumption. > > Cache busting and tracking parameters get appended all the time? =20 > > And theres nothing that prevents duplicate parameter names from=20 > > being > inserted > > either downstream, or even by the CSP. We need to be able to=20 > > uniquely identify the parts of the original URI that are being validat= ed. > > > > There is also a UST requirement in 2.4: > > > > "The attribute MUST be the last attribute in the query string of=20 > > the > URI." > > > > This can be enforced at the time of signing, but at the time of > verification > > we need to be able to reconstruct the exact URI that was signed. =20 > > That > text > > probably needs to be more precise. > > > > And in section 4, the second step 1 for validating the URI says: > > > > "Copy the Original URI" > > > > But, it is not clear how to we know what the original URI was? > > > > - "Key ID (KID) [optiona]" -> Key ID (KID) [optional]" > > > > - Is there a reason to separate MD and SD? Is it just to be > semantically > > explicit? (Is it not implicit in the KID?) > > > > - In section 3, step 9.A.i says: > > > > "Convert the message digest to its equivalent human readable value." > > > > We should probably explicity define the format? hex? base64? > > > > - In section 3, steps 9.B.c and 9.B.i, do we need to be concerned=20 > > about the use of reserved characters? And if those characters have=20 > > to be escaped, is the signature performed before or after escaping? > > > > - In step 2 of the tokenizing procedure: ") Note:" -> "). Note:" > > > > I found this sentance to be a little bit confusing, because it=20 > > talks > about > > the signature, but then it gives an example of the message the > signature > > is being calculated over, and then has a note about the signature,=20 > > but the signature is never shown. I think the example of the=20 > > message is confusing within the context of the signature. > > > > thanx. > > > > -- Kevin J. Ma > > > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 > >> Behalf Of Kent Leung (kleung) > >> Sent: Tuesday, July 16, 2013 11:29 PM > >> To: Scott Wainner (swainner); cdni@ietf.org > >> Subject: Re: [CDNi] FW: New Version Notification for=20 > >> draft-leung-cdni- > uri- > >> signing-02.txt > >> > >> Hi Scott. Thanks for the feedback. See my comments below. > >> > >> -----Original Message----- > >> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On=20 > >> Behalf Of Scott Wainner (swainner) > >> Sent: Tuesday, July 16, 2013 11:31 AM > >> To: cdni@ietf.org > >> Subject: Re: [CDNi] FW: New Version Notification for=20 > >> draft-leung-cdni- > uri- > >> signing-02.txt > >> > >> Kent, > >> > >> Some comments and thoughts ... > >> > >> Scott > >> > >> 2. Signed URI Format > >> > >> o Enforcement Attributes: Attributes that are used to enforce a > >> distribution policy defined by the CSP. Examples of enforcement > >> attributes are IP address of the UA and time window. > >> > >> sw> We need to clarify if this is the IP address assigned to the=20 > >> sw> client > >> (often a 192.168.0.x address) or the public IP address presented to=20 > >> the system (i.e. post NAT'd). I presume the latter. > >> > >> KL> The IP address is the IP address in the IP header of the HTTP > request > >> message as seen by the CDN. We can add some clarification if needed. > >> > >> 2.1 Enforcement Attributes > >> > >> o Client IP (CIP) [optional] - IP address of the client for which > >> this signed URI is generated. This is represented in dotted > >> decimal format for IPv4 or canonical text representation for IPv= 6 > >> address [RFC5952] . The request is rejected if sourced from a > >> client with a different IP address. > >> > >> sw> We need to clarify if this is the IP address assigned to the=20 > >> sw> client > >> or the IP address representing the client's public appearance on=20 > >> the Internet. I presume the latter; the CSP will see the public IP > address. > >> > >> KL> See previous comment. > >> > >> 2.2. Signature Computation Attributes > >> > >> o Hash Function (HF) [optional] - A string used for identifying th= e > >> hash function to compute the URI signature (e.g. "MD5", "SHA1") > >> with HMAC. > >> > >> sw> Should we not define a mandatory set of methods? MD5, SHA-1,=20 > >> sw> SHA- > 256? > >> > >> KL> I'm open to suggestions. We need to consider current deployments. > One > >> reason for being optional is that the hash function may be obtained=20 > >> via CDNI metadata. As for the mandatory hash functions that need to=20 > >> be supported, I think MD5 and SHA1 can be good candidates. > >> > >> 3. Signing a URI > >> 9. Depending on the type of key used to sign the URI, compute the > >> message digest or digital signature for symmetric key or > >> asymmetric keys, respectively. > >> > >> A. For symmetric key, HMAC is used. > >> j. Append the string for the message digest (e.g. ":// > >> example.com/ > >> content.mov?VER=3D1&ET=3D1209422976&CIP=3D10.0.0.1& > >> KID=3Dexample:keys:123&HF=3DSHA-1& > >> MD=3D4fb1c1adf1588fbe11cc6a04c6e69f35"). > >> > >> sw> This example assumes there were no previously defined query=20 > >> sw> string > >> parameters. We need to specify exactly what is provided as input=20 > >> into the HMAC function (PATH ? QUERY_PARAMTERS &=20 > >> SIGNING_PARAMETERS). Do we include previously define query string=20 > >> parameters that existing on the URL or only the path. I find that=20 > >> clients may need to include query strings to facilitate CDN=20 > >> selection or bias decisions. If the client inserts a query string=20 > >> and that portion is validated by the HMAC, then the client will=20 > >> invalidate the signature. Perhaps this is motivation for using the=20 > >> tokenized method. The client can insert query strings in front of the= token query parameter without invalidating the URL. > >> > >> KL> This is an example, which is used to keep it simple. Step #2=20 > >> KL> covers > >> the procedure to include existing query string. Does that answer=20 > >> your question? > >> > >> 4. Validating a URI Signature > >> > >> 4. Extract the value from "CIP" attribute if the attribute exists. > >> Validate that the request came from the same IP address as > >> indicated in the "CIP" attribute. If the IP address is > >> incorrect, then the request is denied. > >> > >> sw> Sounds like we're using the IP address presented by the client=20 > >> sw> and > >> not the IP address assigned to the client. > >> > >> KL> Yes, as mentioned in previous comment. > >> > >> 4. Validating a URI Signature > >> > >> 8. If neither "MD" or "DS" attribute is in the URI, then no URI > >> > >> sw> This implies that URL Signing is required. Presumably, we can > >> configure the system such that we know if incoming URL's should or=20 > >> should not be signed. What is the criteria and how do we determine=20 > >> if the criteria is met? > >> > >> KL> When URL Signing is configured to be validated, then these > attributes > >> need to be in the URI. Yes, it's possible that URI Signing is=20 > >> configured. I had put this under the CDNI Metadata Interface. See=20 > >> below > >> > >> o Type of access control. Specifically, access to content is > >> subject to URI Signing. URI Signing required indication means > >> Downstream CDN ensures URI must be signed and validated before > >> content delivery. Otherwise, Downstream CDN does not perform > >> validation regardless if URI is signed or not. > >> > >> I guess we can say that this can be "set by configuration or CDNI=20 > >> metadata" as noted in other areas. > >> > >> > >> 5.3. CDNI Metadata Interface > >> > >> o Content access control indication. > >> > >> sw> Is the access control defined on a per object request=20 > >> sw> (manifest / > >> segment) or class of service request? A class of service request (e.g= . > >> http://service_path/media_path/media?foo) might indicate ALL media=20 > >> objects associated with the "://service_path/" require access control. > >> How do we define the scope of access control for URL signing? > >> > >> KL> I assume that the access control scope is based on the scope of=20 > >> KL> the > >> metadata. So it can be for a specific content or a group of content. > >> > >> o Encoding format to override the "UST" attribute. (Editor Note: > Is > >> this needed in CDNI Metadata or defined in a new CDNI=20 > >> attribute?) > >> > >> sw> What is implied by the statement 'override'. Presumably, the=20 > >> sw> UST > >> can be transparently passed from surrogate to surrogate even while=20 > >> the domain, path, and query parameters (outside of the UST) are change= d. > >> That is because the UST contains the validated attributes. > >> > >> KL> The override is meant to use another attribute name instead of > "UST" > >> to carry the URI Signing token value. Just a method to provide > flexibility > >> on the attribute name. > >> > >> Kent > >> > >> > >> On 5/31/13 11:35 AM, Kent Leung (kleung) wrote: > >>> Hi folks. We've made some updates based on the WG feedback and > internal > >> discussions. Comments are welcome. Thanks. > >>> > >>> Kent > >>> > >>> -----Original Message----- > >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > >>> Sent: Friday, May 31, 2013 8:26 AM > >>> To: Ray van Brandenburg; Scott Leibrand; Kent Leung (kleung);=20 > >>> Francois > >> Le Faucheur (flefauch); Bill Downey > >>> Subject: New Version Notification for=20 > >>> draft-leung-cdni-uri-signing- > >> 02.txt > >>> > >>> > >>> A new version of I-D, draft-leung-cdni-uri-signing-02.txt > >>> has been successfully submitted by Kent Leung and posted to the=20 > >>> IETF > >> repository. > >>> > >>> Filename: draft-leung-cdni-uri-signing > >>> Revision: 02 > >>> Title: URI Signing for CDN Interconnection (CDNI) > >>> Creation date: 2013-05-31 > >>> Group: Individual Submission > >>> Number of pages: 29 > >>> URL: http://www.ietf.org/internet-drafts/draft-leung-cdni= - > >> uri-signing-02.txt > >>> Status: http://datatracker.ietf.org/doc/draft-leung-cdni-uri= - > >> signing > >>> Htmlized: http://tools.ietf.org/html/draft-leung-cdni-uri- > >> signing-02 > >>> Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-leung-cdni- > uri- > >> signing-02 > >>> > >>> Abstract: > >>> This document describes how the concept of URI signing supports th= e > >>> content access control requirements of CDNI and proposes a > candidate > >>> URI signing scheme. > >>> > >>> The proposed URI signing method specifies the information needed t= o > >>> be included in the URI and the algorithm used to authorize and to > >>> validate access request for the content referenced by the URI. > Some > >>> of the information may be accessed by the CDN via configuration or > >>> CDNI metadata. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >>> > >>> _______________________________________________ > >>> CDNi mailing list > >>> CDNi@ietf.org > >>> https://www.ietf.org/mailman/listinfo/cdni > >> > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > >> _______________________________________________ > >> CDNi mailing list > >> CDNi@ietf.org > >> https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Mon Jul 29 02:18:49 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B605421F9E46 for ; Mon, 29 Jul 2013 02:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-0.336, BAYES_00=-2.599, FRT_BEFORE=1.272] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8V3pBif3xwW for ; Mon, 29 Jul 2013 02:18:45 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id A2D3B21F9A16 for ; Mon, 29 Jul 2013 02:18:42 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 80DAD416978 for ; Mon, 29 Jul 2013 05:16:43 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB013.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id F00CD416970 for ; Mon, 29 Jul 2013 05:16:42 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB013.mail.lan ([10.110.17.13]) with mapi; Mon, 29 Jul 2013 05:16:34 -0400 From: Kevin J Ma To: "cdni@ietf.org" Date: Mon, 29 Jul 2013 05:18:35 -0400 Thread-Topic: [CDNi] I-D Action: draft-ietf-cdni-logging-05.txt Thread-Index: Ac5+9TyHh+xLkBAATBCo7TxjcXe9hgNRqSOA Message-ID: <291CC3F9E50E7641901A54E85D0977C6665133C13C@MAILR002.mail.lan> References: <20130712114707.2936.83778.idtracker@ietfa.amsl.com> In-Reply-To: <20130712114707.2936.83778.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-05.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 09:18:49 -0000 Hi all, some comments on the logging draft: section 2.1: "benefit form" -> "benefit from" section 2.2.: "is obviously only indicative" -> "is obviously only an examp= le" section 2.2.5.1: wrt CDNI, are we saying that logging should enable the uCDN to debug the performance issues in the dCDN? section 3.3: in general, should occurance be more precise? e.g.: UUID: "there MUST be one and only one instance of this directive." should specify "per CDNI Logging File" Fields: "The first instance of this directive for a given Record-Type MUST precede any CDNI Logging Record for this Record-Type." should specify before the next Fields directive. i.e., it is not required to group all the records for a given Fields directive into a single block in the log file? section 3.3: for Verified-Origin, when would this be propogated? Is the use case a transit CDN forwarding a log verbatim from dCDN to uCDN? section 3.3: for Integrity-Hash, it states that the hash is computed "by the entity that transmits the CDNI Logging File." though it is possible that the entity that generated the log file is not the same entity that (re)transmits it. does the integrity hash need to be recalculated? section 3.3: the protocol, sc-status, and sc-total-bytes fields are all mandatory, and HTTP-specific. In the case of non-HTTP delivery, are these fields just left blank? Or do we only support HTTP delivery (not that theres anything wrong with that)? sc-entity-bytes, cs(header), and sc(header) are also HTTP-specific, but not required, section 3.3: the s-cached flag is for: "whether the Surrogate could serve the request using content already stored on its local cache"=20 Should it be fore whether the Surrogate "did serve the request from content already stored in its local cache"? in section 3: "agreements) ." -> "agreements)." thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Friday, July 12, 2013 7:47 AM > To: i-d-announce@ietf.org > Cc: cdni@ietf.org > Subject: [CDNi] I-D Action: draft-ietf-cdni-logging-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Content Delivery Networks > Interconnection Working Group of the IETF. >=20 > Title : CDNI Logging Interface > Author(s) : Francois Le Faucheur > Gilles Bertrand > Iuniana Oprescu > Roy Peterkofsky > Filename : draft-ietf-cdni-logging-05.txt > Pages : 44 > Date : 2013-07-12 >=20 > Abstract: > This memo specifies the Logging interface between a downstream CDN > (dCDN) and an upstream CDN (uCDN) that are interconnected as per the > CDN Interconnection (CDNI) framework. First, it describes a > reference model for CDNI logging. Then, it specifies the CDNI > Logging File format and the actual protocol for exchange of CDNI > Logging Files. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-cdni-logging >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-cdni-logging-05 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cdni-logging-05 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kleung@cisco.com Mon Jul 29 20:50:29 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD6711E81B3 for ; Mon, 29 Jul 2013 20:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMpx12CkLADE for ; Mon, 29 Jul 2013 20:50:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DE0DC11E81B0 for ; Mon, 29 Jul 2013 20:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2593; q=dns/txt; s=iport; t=1375156207; x=1376365807; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cnw0YwfBqLMWIlb9C9BK97L5vPKG2ZZ2Rw2yMDM76jA=; b=PpaFLBUnwS+DSdxo6we8gLGa6Yn13PocrCJDj7qQU0f6xTent9r8+G3j W1OQjlabQ7ytIb02R7hXJwYYvTfMSvjpBui81NMVFs5QLkYgk9BsKPUno tJFndFWXBa1j61R9at+/gfrbCmUHyoEXfjy+6QIQNV3XbyRlB5fRjmXgA A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAII391GtJXG9/2dsb2JhbABbgwY1UL4LgR8WdIIkAQEBBDo9EgIBCCIUEDIcCQIEARqICLkKj004gxhvA5kIkCODFIIq X-IronPort-AV: E=Sophos;i="4.89,774,1367971200"; d="scan'208";a="240902428" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 30 Jul 2013 03:50:05 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6U3o5vQ022616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 03:50:05 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.140]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 29 Jul 2013 22:50:05 -0500 From: "Kent Leung (kleung)" To: Kevin J Ma , "Scott Wainner (swainner)" , "cdni@ietf.org" Thread-Topic: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt Thread-Index: AQHOjNfgoShQAp65REGh8eX1I9H4Xg== Date: Tue, 30 Jul 2013 03:50:04 +0000 Message-ID: References: <20130531152617.26809.88399.idtracker@ietfa.amsl.com> <51E59162.2030909@cisco.com> <291CC3F9E50E7641901A54E85D0977C6665133C116@MAILR002.mail.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.114.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-leung-cdni-uri-signing-02.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 03:50:30 -0000 Follow up on one issue that you brought up.=20 I realized that I confused myself when reading your comments. :) Actually, = the steps are right but probably not clear. It does generate the Signed URI= as the result. In step 1, the URI signature is shown in the example ("MD= =3D..."). The point is to highlight that the URI signature is part of the m= essage that is tokenized. Basically, all the CDNI attributes that are added= to the original URI are encoded into the URI Signing token. The "message" = here is for generating the token and appending it to the Original URI to cr= eate the Signed URI. It is not related to the "message" used in earlier pro= cedures to compute the URI signature. So step 6 should say "Note: this is t= he completed Signed URI when URI Signing token is used". And in step 10 in = prior procedure, it should say "Note: this is the completed Signed URI when= URI Signing token is not used". Would that help to clarify the issue? Changes to steps 10 and 6: 10. When tokenizing the URI Signing attributes is not necessary, generate the Signed URI by prepending the "scheme name" part to the message (e.g. http://example.com/ content.mov?VER=3D1&ET=3D1209422976&CIP=3D10.0.0.1&KID=3Dhttp:// example.com/public/keys/123&DS=3Dr: CFB03EDB33810AB6C79EE3C47FBD86D227D702F25F66C01CF03F59F1E005668D :s: 57ED0E8DF7E786C87E39177DD3398A7FB010E6A4C0DC8AA71331A929A29EA24E " ). Note: this is the completed Signed URI when URI Signing token is not used. 6. Append the URI Signing token to the message (e.g. "http:// example.com/ content.mov?UST=3DVkVSPTEmRVQ9MTIwOTQyMjk3NiZDSVA9MTAuMC4wLjEmS0lEP WZvb2JhcjprZXlzOjEyMyZIRj1TSEEtMSZNRD00ZmIxYzFhZGYxNTg4ZmJlMTFjYz ZhMDRjNmU2OWYzNQ=3D=3D"). Note: this is the completed Signed URI when URI Signing token is used. Kent I found this sentance to be a little bit confusing, because it talks abou= t the signature, but then it gives an example of the message the signature is being calculated over, and then has a note about the signature, but the signature is never shown. I think the example of the message is confusing within the context of the signature. KL> I see the confusion. The procedure is only for computing the URI Signin= g token. It does not produce the Signed URI which was mistakenly claimed. = The section needs to be worked back into steps 9.A.g and 9.B.e which contai= n the message to be signed. Good catch. From ray.vanbrandenburg@tno.nl Tue Jul 30 04:11:21 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A2F11E81DA for ; Tue, 30 Jul 2013 04:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.796 X-Spam-Level: X-Spam-Status: No, score=0.796 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Kub+AmnGKUl for ; Tue, 30 Jul 2013 04:11:16 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 55BE911E81DE for ; Tue, 30 Jul 2013 04:11:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,777,1367964000"; d="scan'208,217";a="11915229" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 30 Jul 2013 13:11:14 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.163]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 13:11:14 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: CDNI-HAS published as RFC Thread-Index: Ac6NFYDGNOhroSNpR4u33DAwd/FSIA== Date: Tue, 30 Jul 2013 11:11:13 +0000 Message-ID: <7FE8705A-BDE0-4343-8B76-50F3071099E0@tno.nl> Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_7FE8705ABDE043438B7650F3071099E0tnonl_" MIME-Version: 1.0 Subject: [CDNi] CDNI-HAS published as RFC X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:11:21 -0000 --_000_7FE8705ABDE043438B7650F3071099E0tnonl_ Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpGb3IgeW91ciBpbmZvcm1hdGlvbjogZHJhZnQtYnJhbmRlbmJ1cmctY2RuaS1o YXMsIHdoaWNoIGRpc2N1c3NlcyB0aGUgaW1wYWN0IG9mIEhUVFAgQWRhcHRpdmUgU3RyZWFtaW5n IG9uIHRoZSBDRE5JIGludGVyZmFjZXMsIGhhcyBqdXN0IGJlZW4gcHVibGlzaGVkIGFzIGFuIGlu ZGVwZW5kZW50IGluZm9ybWF0aW9uYWwgUkZDIChSRkM2OTgzKS4NCg0KWW91IGNhbiBmaW5kIGl0 IGF0OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2OTgzDQoNClRoYW5rcyB0byBhbGwg b2YgeW91IHdobyBwYXJ0aWNpcGF0ZWQgaW4gdGhlIGRpc2N1c3Npb25zIGFuZCBjb250cmlidXRl ZCB0byB0aGUgZHJhZnQhDQoNCkJlc3QgcmVnYXJkcywNCg0KUmF5DQpUaGlzIGUtbWFpbCBhbmQg aXRzIGNvbnRlbnRzIGFyZSBzdWJqZWN0IHRvIHRoZSBESVNDTEFJTUVSIGF0IGh0dHA6Ly93d3cu dG5vLm5sL2VtYWlsZGlzY2xhaW1lcgo= --_000_7FE8705ABDE043438B7650F3071099E0tnonl_ Content-Type: text/html; charset="utf-8" Content-ID: <229DDF18B4743D4C938C31D88E165668@tno.nl> MIME-Version: 1.0 Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI aSBhbGwsDQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Gb3IgeW91ciBpbmZvcm1hdGlvbjogZHJh ZnQtYnJhbmRlbmJ1cmctY2RuaS1oYXMsIHdoaWNoIGRpc2N1c3NlcyB0aGUgaW1wYWN0IG9mIEhU VFAgQWRhcHRpdmUgU3RyZWFtaW5nIG9uIHRoZSBDRE5JIGludGVyZmFjZXMsIGhhcyBqdXN0IGJl ZW4gcHVibGlzaGVkIGFzIGFuIGluZGVwZW5kZW50IGluZm9ybWF0aW9uYWwgUkZDIChSRkM2OTgz KS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllvdSBjYW4gZmluZCBpdCBh dDombmJzcDs8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICcuSGVsdmV0aWNhTmV1ZVVJJzsgZm9u dC1zaXplOiAxNXB4OyBsaW5lLWhlaWdodDogMTlweDsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgLXdl YmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjkyOTY5KTsgLXdl YmtpdC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5 KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAu MjMwNDY5KTsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBub25lOyAiPjxhIGhyZWY9Imh0dHA6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY5ODMiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzY5ODM8L2E+PC9zcGFuPjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtz IHRvIGFsbCBvZiB5b3Ugd2hvIHBhcnRpY2lwYXRlZCBpbiB0aGUgZGlzY3Vzc2lvbnMgYW5kIGNv bnRyaWJ1dGVkIHRvIHRoZSBkcmFmdCE8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJl c3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJheTwvZGl2Pg0KPHA+ VGhpcyBlLW1haWwgYW5kIGl0cyBjb250ZW50cyBhcmUgc3ViamVjdCB0byB0aGUgRElTQ0xBSU1F UiBhdCBodHRwOi8vd3d3LnRuby5ubC9lbWFpbGRpc2NsYWltZXI8L3A+PC9ib2R5Pg0KPC9odG1s Pg0K --_000_7FE8705ABDE043438B7650F3071099E0tnonl_-- From ray.vanbrandenburg@tno.nl Tue Jul 30 04:27:08 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF6F11E814F for ; Tue, 30 Jul 2013 04:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.535 X-Spam-Level: X-Spam-Status: No, score=0.535 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1xPxYlMN+eB for ; Tue, 30 Jul 2013 04:27:03 -0700 (PDT) Received: from fromintouta.tno.nl (fromintouta.tno.nl [134.221.1.26]) by ietfa.amsl.com (Postfix) with ESMTP id 75F9B21F9EE5 for ; Tue, 30 Jul 2013 04:27:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.89,777,1367964000"; d="scan'208";a="11916126" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1a.tno.nl with ESMTP; 30 Jul 2013 13:27:01 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.163]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 13:27:01 +0200 From: "Brandenburg, R. (Ray) van" To: "cdni@ietf.org" Thread-Topic: CDNI and byte-range requests Thread-Index: Ac6NF7WBCrwwUsXoTkKL13I1urBVJw== Date: Tue, 30 Jul 2013 11:27:00 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <90405EE1156A7B4187B56D6A678E1DDB@tno.nl> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: [CDNi] CDNI and byte-range requests X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:27:08 -0000 Hi all, As I'm not sure whether this should be part of the Redirection Interface do= cument or the Framework document, let me just post this as a general questi= on to the list: To my knowledge, the current CDNI documents do not explicitly address the c= ase of HTTP Byte-range requests. Although in most cases byte-range requests= will function just as any other requests, I think there are some cases whe= re byte-range requests warrant further attention. An example is the Redirec= tion interface. If a uCDN asks a dCDN to deliver a particular user request = (containing a byte range), and the dCDN answers positively, can the uCDN as= sume that the dCDN accepts any future requests for the same file with a dif= ferent byte range? And if that is the case, is this default behavior or do = we need an explicit flag in the inter-CDN redirection request to indicate t= he uCDN/dCDN's preference? = To be clear: I don't think we need any new functionality to handle byte-ran= ge requests, but a few sentences in either the Framework or the RI document= might clear up any future uncertainty. = Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer From kevin.ma@azukisystems.com Tue Jul 30 05:10:58 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1521F9F96 for ; Tue, 30 Jul 2013 05:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RDkeNudy+e8a for ; Tue, 30 Jul 2013 05:10:53 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 57BD521F8653 for ; Tue, 30 Jul 2013 05:10:32 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 7AEFC4169A9; Tue, 30 Jul 2013 08:10:29 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB012.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 030E841690A; Tue, 30 Jul 2013 08:10:29 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB012.mail.lan ([10.110.17.12]) with mapi; Tue, 30 Jul 2013 08:08:23 -0400 From: Kevin J Ma To: Jan Seedorf , "cdni@ietf.org" Date: Tue, 30 Jul 2013 08:10:27 -0400 Thread-Topic: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-04.txt Thread-Index: AQHOgW+vt3M78QCcnkmPIl6tv5IaMZlm/WowgBY6ZfA= Message-ID: <291CC3F9E50E7641901A54E85D0977C6665133C62F@MAILR002.mail.lan> References: <20130715152620.5664.97237.idtracker@ietfa.amsl.com> <2779C9F0771F974CAD742BAE6D9904FE5558D028@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE5558D028@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-04.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:10:58 -0000 Hi Jan, I read through the updated draft and had a couple questions: section 4.2: "where each PID name has a certain 'capability' semantic." Does each capability need its own PID? or can capabilities be grouped if they currently have the same footprint, and then later ungrouped if a given capability's footprint changes= ? section 5: "dowmstream" -> "downstream" In figure 2 of the framework document there is an "[Async FCI Push]". Without the Web Socket extension, would an ALTO-based FCI required the uCDN to poll the dCDN? I think we would want asynchronous push from dCDN to uCDN, or at least a triggered pull? wrt content and resource availability, are there existing extensions (not cited), or are those just future thoughts? section 6: the cited section 8.2.2 of the alto draft does not discuss authentication signatures. There is no section 8.2.2. I did see section 14 discusses HTTP digest auth over TLS? and section 3.2 states that: "Additional protocol mechanisms (e.g., expiration times and digi= tal signatures for returned ALTO information) are left for future investigation." thanx. -- Kevin J. Ma > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Jan Seedorf > Sent: Tuesday, July 16, 2013 4:41 AM > To: cdni@ietf.org > Subject: [CDNi] FW: New Version Notification for draft-seedorf-cdni- > request-routing-alto-04.txt >=20 > Hi all, >=20 > I have submitted a revision of the draft that outlines how ALTO can be a > solution protocol for the CDNI FCI. The latest version has been changed > quite a bit; it re-visits the latest conclusions in the FCI design team, > and describes how ALTO could be used to advertise the types of footprint > and capabilities that are considered as mandatory by the design team. >=20 > - Jan >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 15, 2013 5:26 PM > To: Jan Seedorf > Subject: New Version Notification for draft-seedorf-cdni-request-routing- > alto-04.txt >=20 >=20 > A new version of I-D, draft-seedorf-cdni-request-routing-alto-04.txt > has been successfully submitted by Jan Seedorf and posted to the > IETF repository. >=20 > Filename: draft-seedorf-cdni-request-routing-alto > Revision: 04 > Title: CDNI Request Routing with ALTO > Creation date: 2013-07-15 > Group: Individual Submission > Number of pages: 15 > URL: http://www.ietf.org/internet-drafts/draft-seedorf-cdni- > request-routing-alto-04.txt > Status: http://datatracker.ietf.org/doc/draft-seedorf-cdni- > request-routing-alto > Htmlized: http://tools.ietf.org/html/draft-seedorf-cdni-request- > routing-alto-04 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-seedorf-cdni- > request-routing-alto-04 >=20 > Abstract: > Network Service Providers (NSPs) are currently considering to deploy > Content Delivery Networks (CDNs) within their networks. As a > consequence of this development, there is a need for interconnecting > these local CDNs. The necessary interfaces for inter-connecting CDNs > are currently being defined in the Content Delivery Networks > Interconnection (CDNI) WG. This document focuses on the CDNI > Footprint & Capabilities Advertisement interface (FCI). > Specifically, this document outlines how the solutions currently > being defined in the Application Layer Traffic Optimization (ALTO) WG > can facilitate Footprint & Capabilities Advertisement in a CDNI > context, i.e. how the CDNI FCI can be realised with the ALTO > protocol. Concrete examples of how ALTO can be integrated within > CDNI request routing and in particular in the process of selecting a > downstream CDN are given. The examples in this document are based on > the use cases and examples currently being discussed in the CDNI WG. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From flefauch@cisco.com Tue Jul 30 05:27:32 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445A721E80D8 for ; Tue, 30 Jul 2013 05:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSOclqgFJAEl for ; Tue, 30 Jul 2013 05:27:25 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFF011E81CB for ; Tue, 30 Jul 2013 05:26:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=370; q=dns/txt; s=iport; t=1375187220; x=1376396820; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=6ACVSjdAp/JBnp8jUnKmJ/5Sz2tCKttoSz3yU3N3g1Q=; b=EHW3jBAFsEmD9JGgFdjTPi3Nkoqzy3duvTo0+qo+yVl6VVrMDjfv7X5Y 2yAX+oBcDJvv+2pbVf/yAxqL5u0CquRGNCHMVDiQecUuY64n/ZyDTygXJ JOi9BhwYWXmMNL/2FU/VCT/fjxsvs+zXOwMoUUXA5yYMSmdwMmT/Z6k3m I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAP+v91GtJV2Z/2dsb2JhbABbgwaBBb4OgR4WdIIlAQEEOk8CASoUEDIlAgQbiAi5EI9NOIMYbwOpK4FbgTmCKg X-IronPort-AV: E=Sophos;i="4.89,778,1367971200"; d="scan'208";a="238252534" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jul 2013 12:26:56 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6UCQul9015360 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Jul 2013 12:26:56 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 07:26:56 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: 2nd CDNI Logging Informal Meeting in Berlin : Wed 31 Jul @1:00pm meet at registration desk Thread-Index: AQHOjSAUWWJGzzcfYU+fUCPn7R+VYQ== Date: Tue, 30 Jul 2013 12:26:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.142] Content-Type: text/plain; charset="us-ascii" Content-ID: <8654B9B709216B4286C109116FC26C54@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] 2nd CDNI Logging Informal Meeting in Berlin : Wed 31 Jul @1:00pm meet at registration desk X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 12:27:32 -0000 Hi, We'll be holding a 2nd informal meeting on cdni-logging in Berlin: Wed 31 Jul=20 1:00pm to 2:30pm Meet at IETF registration desk In particular, we'll discuss: * non-repudiation * consistent direction for "Implementation requirements" and for "Deployme= nt requirements" * whatever comments you may have on -05 Cheers Francois, Iuniana, Roy From flefauch@cisco.com Tue Jul 30 06:08:48 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF28F11E81FD for ; Tue, 30 Jul 2013 06:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I11jmgOqJLg6 for ; Tue, 30 Jul 2013 06:08:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9375111E81CB for ; Tue, 30 Jul 2013 06:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58; q=dns/txt; s=iport; t=1375189723; x=1376399323; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=5oHzJuq/DpTJhJTYXPIlbWZ2pcqAWxSZjBELWxkIJG8=; b=D5xP9G7Wwx/9Eeo8WuwIYpv0I+ACk4/85G/082WUXsXmIiDuHtDbKIEQ eBOZ0w7UXTnsTMX93KmjZOZaYr9pVuCIv7yOlrJrOdgoCRqOlqjXnWAVC jOGj6uTb3T47pf39sfLFi/dEwg6RUu1z5RuT40QiRbpNsrCxtvUj1cG0v I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8LAF+591GtJXG//2dsb2JhbABbgwY1UIJJu0UBAwGBHhZ0giYBBDpRASoUQicEGwGIBwyYM6BmjlwzPjODHXEDqSuDFIIq X-IronPort-AV: E=Sophos;i="4.89,778,1367971200"; d="scan'208";a="241259211" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jul 2013 13:08:41 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6UD8fFm003930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Jul 2013 13:08:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 08:08:41 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: For remote participation to the IETF CDNI sessions see ... Thread-Index: AQHOjSXoKY2tWGyqEEeXFPuqc1zkCQ== Date: Tue, 30 Jul 2013 13:08:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.97.224] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] For remote participation to the IETF CDNI sessions see ... X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:08:48 -0000 http://www.ietf.org/meeting/87/remote-participation.html From spencerdawkins.ietf@gmail.com Tue Jul 30 06:31:35 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292BF21F9F01 for ; Tue, 30 Jul 2013 06:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv6d+AOi0y0J for ; Tue, 30 Jul 2013 06:31:34 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 2364821F9E5E for ; Tue, 30 Jul 2013 06:31:34 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id jt11so326172pbb.38 for ; Tue, 30 Jul 2013 06:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=jmqJQHsA3GaYbs2aAmzzB+Ki4w1YClkR63qhPc0m+nA=; b=0sQB9ENm7nEKEP7WgIHsoiXBxjN7ra4E+SncNMiY9Uzi+FulyIWJNb7RVMSCZYovUU hiQ5WJHPUt1qG1l405L4ayLrCEuE/Yyc8DPNbNm/jtIAgBjFjC2xaTZWS4E9zAgcpnmv WA9W1upoTIFgxZC5soaUjDtLDQrTB2JQrOQ1UvAS/Y+w8nidRxL1iP/fHe7GADD9VKsA 9GPIjZsWA3jZGM7aqJse++hwHhmwuTpmwCYctb56R0Ms3pdiGR/3Zu5K7CzuCEiofNuS QTiVMGX2MtoXDDc/BEAI9EIBemlcLIXwiDlxLY/jnsrbwt+ViSbT77iKF80ivcxveZTb WIQA== X-Received: by 10.66.179.78 with SMTP id de14mr29173495pac.18.1375191093878; Tue, 30 Jul 2013 06:31:33 -0700 (PDT) Received: from ?IPv6:2001:df8:0:64:a46c:251d:2d6a:c9b4? ([2001:df8:0:64:a46c:251d:2d6a:c9b4]) by mx.google.com with ESMTPSA id iu7sm36377058pbc.8.2013.07.30.06.31.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Jul 2013 06:31:32 -0700 (PDT) Message-ID: <51F7C030.4000508@gmail.com> Date: Tue, 30 Jul 2013 08:31:28 -0500 From: Spencer Dawkins User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: cdni@ietf.org References: <2779C9F0771F974CAD742BAE6D9904FE55595DCD@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE55595DCD@DAPHNIS.office.hd> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting @IETF87 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 13:31:35 -0000 On 7/28/2013 3:20 AM, Jan Seedorf wrote: > Dear all, > > According to the doodle, the best timeslot where actually everybody can make it is: > > *** THU, 13:00-15:00 *** > > So let's meet at 13:00 at the IETF registration desk, find a room, and then go through the open issues case-by-case. > > - Jan If it's helpful, I have penciled you in for the IESG breakout room (Chess, upstairs). If you think you're good without using that room, please let me know, so I can free it up for other side meetings. Thanks, Spencer From Jan.Seedorf@neclab.eu Tue Jul 30 07:02:31 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589F221F9AED for ; Tue, 30 Jul 2013 07:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.358 X-Spam-Level: X-Spam-Status: No, score=-103.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDfA46DCDNNC for ; Tue, 30 Jul 2013 07:02:27 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 0BDC711E81E4 for ; Tue, 30 Jul 2013 07:02:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id C17A8104F47; Tue, 30 Jul 2013 16:01:35 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5IZgEgm2dfG; Tue, 30 Jul 2013 16:01:35 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id A6237104F49; Tue, 30 Jul 2013 16:01:25 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 30 Jul 2013 16:02:10 +0200 From: Jan Seedorf To: Spencer Dawkins , "cdni@ietf.org" Thread-Topic: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting @IETF87 Thread-Index: Ac6Lajr6huuFn5SlSnOjNL1d9xbo5QBrhm0AAAU78SA= Date: Tue, 30 Jul 2013 14:02:10 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE555972C0@DAPHNIS.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE55595DCD@DAPHNIS.office.hd> <51F7C030.4000508@gmail.com> In-Reply-To: <51F7C030.4000508@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.214] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting @IETF87 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:02:31 -0000 Hi Spencer, That is indeed helpful and much appreciated. Let's use that room. Thanks a lot, - Jan > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Spencer Dawkins > Sent: Tuesday, July 30, 2013 3:31 PM > To: cdni@ietf.org > Subject: Re: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting > @IETF87 >=20 > On 7/28/2013 3:20 AM, Jan Seedorf wrote: > > Dear all, > > > > According to the doodle, the best timeslot where actually everybody can > make it is: > > > > *** THU, 13:00-15:00 *** > > > > So let's meet at 13:00 at the IETF registration desk, find a room, and = then go > through the open issues case-by-case. > > > > - Jan >=20 > If it's helpful, I have penciled you in for the IESG breakout room > (Chess, upstairs). If you think you're good without using that room, > please let me know, so I can free it up for other side meetings. >=20 > Thanks, >=20 > Spencer > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From kevin.ma@azukisystems.com Tue Jul 30 07:06:38 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E787711E8205 for ; Tue, 30 Jul 2013 07:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-CUjPw0pfFK for ; Tue, 30 Jul 2013 07:06:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id 62BB421F9BF0 for ; Tue, 30 Jul 2013 07:06:33 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id AB5DE556C79; Tue, 30 Jul 2013 10:03:45 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 318C6556C30; Tue, 30 Jul 2013 10:03:45 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Tue, 30 Jul 2013 10:03:31 -0400 From: Kevin J Ma To: Jan Seedorf , Spencer Dawkins , "cdni@ietf.org" Date: Tue, 30 Jul 2013 10:05:37 -0400 Thread-Topic: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting @IETF87 Thread-Index: Ac6Lajr6huuFn5SlSnOjNL1d9xbo5QBrhm0AAAU78SAAACQuQA== Message-ID: <291CC3F9E50E7641901A54E85D0977C6665133C6FE@MAILR002.mail.lan> References: <2779C9F0771F974CAD742BAE6D9904FE55595DCD@DAPHNIS.office.hd> <51F7C030.4000508@gmail.com> <2779C9F0771F974CAD742BAE6D9904FE555972C0@DAPHNIS.office.hd> In-Reply-To: <2779C9F0771F974CAD742BAE6D9904FE555972C0@DAPHNIS.office.hd> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting @IETF87 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:06:38 -0000 Do we still meet at the registration desk, or go straight to the room? > -----Original Message----- > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > Jan Seedorf > Sent: Tuesday, July 30, 2013 10:02 AM > To: Spencer Dawkins; cdni@ietf.org > Subject: Re: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting > @IETF87 >=20 > Hi Spencer, >=20 > That is indeed helpful and much appreciated. Let's use that room. >=20 > Thanks a lot, >=20 > - Jan >=20 > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Spencer Dawkins > > Sent: Tuesday, July 30, 2013 3:31 PM > > To: cdni@ietf.org > > Subject: Re: [CDNi] Timeslot for CDNI Footprint/Capabilities Side > Meeting > > @IETF87 > > > > On 7/28/2013 3:20 AM, Jan Seedorf wrote: > > > Dear all, > > > > > > According to the doodle, the best timeslot where actually everybody > can > > make it is: > > > > > > *** THU, 13:00-15:00 *** > > > > > > So let's meet at 13:00 at the IETF registration desk, find a room, an= d > then go > > through the open issues case-by-case. > > > > > > - Jan > > > > If it's helpful, I have penciled you in for the IESG breakout room > > (Chess, upstairs). If you think you're good without using that room, > > please let me know, so I can free it up for other side meetings. > > > > Thanks, > > > > Spencer > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From Jan.Seedorf@neclab.eu Tue Jul 30 07:23:36 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D0C21F9CE2 for ; Tue, 30 Jul 2013 07:23:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.398 X-Spam-Level: X-Spam-Status: No, score=-103.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G9SEvDdxdVv for ; Tue, 30 Jul 2013 07:23:31 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id B90D021F9D3A for ; Tue, 30 Jul 2013 07:23:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 7CCF9104F45; Tue, 30 Jul 2013 16:22:18 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocAQAlfK63aa; Tue, 30 Jul 2013 16:22:18 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 60259103B71; Tue, 30 Jul 2013 16:22:03 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Tue, 30 Jul 2013 16:22:48 +0200 From: Jan Seedorf To: Kevin J Ma , Spencer Dawkins , "cdni@ietf.org" Thread-Topic: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting @IETF87 Thread-Index: Ac6Lajr6huuFn5SlSnOjNL1d9xbo5QBrhm0AAAU78SAAACQuQAAAlwow Date: Tue, 30 Jul 2013 14:22:48 +0000 Message-ID: <2779C9F0771F974CAD742BAE6D9904FE5559739D@DAPHNIS.office.hd> References: <2779C9F0771F974CAD742BAE6D9904FE55595DCD@DAPHNIS.office.hd> <51F7C030.4000508@gmail.com> <2779C9F0771F974CAD742BAE6D9904FE555972C0@DAPHNIS.office.hd> <291CC3F9E50E7641901A54E85D0977C6665133C6FE@MAILR002.mail.lan> In-Reply-To: <291CC3F9E50E7641901A54E85D0977C6665133C6FE@MAILR002.mail.lan> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting @IETF87 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:23:37 -0000 Good point: let's meet directly at the room - Jan > -----Original Message----- > From: Kevin J Ma [mailto:kevin.ma@azukisystems.com] > Sent: Tuesday, July 30, 2013 4:06 PM > To: Jan Seedorf; Spencer Dawkins; cdni@ietf.org > Subject: RE: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeting > @IETF87 >=20 > Do we still meet at the registration desk, or go straight to the room? >=20 > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Jan Seedorf > > Sent: Tuesday, July 30, 2013 10:02 AM > > To: Spencer Dawkins; cdni@ietf.org > > Subject: Re: [CDNi] Timeslot for CDNI Footprint/Capabilities Side Meeti= ng > > @IETF87 > > > > Hi Spencer, > > > > That is indeed helpful and much appreciated. Let's use that room. > > > > Thanks a lot, > > > > - Jan > > > > > -----Original Message----- > > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf > Of > > > Spencer Dawkins > > > Sent: Tuesday, July 30, 2013 3:31 PM > > > To: cdni@ietf.org > > > Subject: Re: [CDNi] Timeslot for CDNI Footprint/Capabilities Side > > Meeting > > > @IETF87 > > > > > > On 7/28/2013 3:20 AM, Jan Seedorf wrote: > > > > Dear all, > > > > > > > > According to the doodle, the best timeslot where actually everybody > > can > > > make it is: > > > > > > > > *** THU, 13:00-15:00 *** > > > > > > > > So let's meet at 13:00 at the IETF registration desk, find a room, = and > > then go > > > through the open issues case-by-case. > > > > > > > > - Jan > > > > > > If it's helpful, I have penciled you in for the IESG breakout room > > > (Chess, upstairs). If you think you're good without using that room, > > > please let me know, so I can free it up for other side meetings. > > > > > > Thanks, > > > > > > Spencer > > > _______________________________________________ > > > CDNi mailing list > > > CDNi@ietf.org > > > https://www.ietf.org/mailman/listinfo/cdni > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni From david@mandelberg.org Tue Jul 30 07:49:39 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D02321F8201 for ; Tue, 30 Jul 2013 07:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.763 X-Spam-Level: X-Spam-Status: No, score=0.763 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_44=0.6, J_CHICKENPOX_45=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwMknqiVbI9X for ; Tue, 30 Jul 2013 07:49:35 -0700 (PDT) Received: from qmta02.emeryville.ca.mail.comcast.net (qmta02.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:24]) by ietfa.amsl.com (Postfix) with ESMTP id 50F6A21F853A for ; Tue, 30 Jul 2013 07:49:33 -0700 (PDT) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta02.emeryville.ca.mail.comcast.net with comcast id 6dzi1m00B0S2fkCA2epZff; Tue, 30 Jul 2013 14:49:33 +0000 Received: from uriel.mandelberg.org ([IPv6:2001:4830:11a7:2:216:3eff:fe0e:b38c]) by omta09.emeryville.ca.mail.comcast.net with comcast id 6epW1m00C1djk4J8VepYSP; Tue, 30 Jul 2013 14:49:32 +0000 Received: from secure.mandelberg.org (unknown [10.1.2.3]) by uriel.mandelberg.org (Postfix) with ESMTP id 5A5AB1C6060 for ; Tue, 30 Jul 2013 10:51:00 -0400 (EDT) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_31ee1876d779328709bc25a4325ab09d" Date: Tue, 30 Jul 2013 16:51:00 +0200 From: David Mandelberg To: Message-ID: <61c081f757d55b0f0e57c7ab5252fc9b@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1375195773; bh=yVa1PFlDCs7TB1QqMACM1geYFlUjg1hLbrwncGd0SGo=; h=Received:Received:Received:MIME-Version:Content-Type:Date:From:To: Subject:Message-ID; b=Y2ABtxF56JvuIKde5QOegwzNAgaipOXJMkpqF4C4qlGd83bo0gBXAAr1U+PFzvwAE rMLddnc+60dWFuwTA+bX8+Kt70/X1e0WF4FI7lxnPcePY0aBGf1hyBe/Uq+Z24drHm OnpWLBSa2MzBlY7eXSqPH8M643OGqSzeURwTq0ojNrDrFbi7O1t+dF+nz0nDrBbHnh fccXzvpY2N539+pV23csX+L+dvC0EPK/dnejFFThrR/TcMXo0XLb7QwAd9qDhc7Ow/ gvuxtRblidZw0YUxZ+GXYwcoEYu+/1OizusRY3gRASytyBsEeYcthDZpPY2hdW/LHw 7IpI/B5HWcvXQ== Subject: [CDNi] logging non-repudiation proposed text v2 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:49:39 -0000 --=_31ee1876d779328709bc25a4325ab09d Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8; format=flowed Here's the next version of my proposed text for non-repudiation of logging data. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ --=_31ee1876d779328709bc25a4325ab09d Content-Transfer-Encoding: base64 Content-Type: text/plain; name=draft-ietf-cdni-logging-05-non-repudiation-suggestions-00.txt Content-Disposition: attachment; filename=draft-ietf-cdni-logging-05-non-repudiation-suggestions-00.txt Mi4zLiBOb24tUmVwdWRpYXRpb24KCiAgIFRoaXMgc2VjdGlvbiBkaXNjdXNzZXMgbm9uLXJlcHVk aWF0aW9uIHdpdGggcHJvb2Ygb2Ygb3JpZ2luIGZvciBsb2dnaW5nIGluZm9ybWF0aW9uLiBUaGUg dGVybSAibm9uLXJlcHVkaWF0aW9uIHdpdGggcHJvb2Ygb2Ygb3JpZ2luIiBpcyBkZWZpbmVkIGlu IFtSRkM0OTQ5XS4gRm9yIGJyZXZpdHksIHRoZSB0ZXJtICJub24tcmVwdWRpYXRpb24iIHdpbGwg YmUgdXNlZCB0byBtZWFuICJub24tcmVwdWRpYXRpb24gd2l0aCBwcm9vZiBvZiBvcmlnaW4iIGlu IHRoaXMgZG9jdW1lbnQuIEltcGxlbWVudGF0aW9ucyBvZiB0aGUgQ0ROSSBMb2dnaW5nIGludGVy ZmFjZSBTSE9VTEQgc3VwcG9ydCBub24tcmVwdWRpYXRpb24uIEhvd2V2ZXIsIGltcGxlbWVudGF0 aW9ucyB0aGF0IHN1cHBvcnQgbm9uLXJlcHVkaWF0aW9uIFNIT1VMRCBOT1QgbWFuZGF0ZSB0aGUg dXNlIG9mIG5vbi1yZXB1ZGlhdGlvbi4gSW4gdGhlIENETkkgTG9nZ2luZyBpbnRlcmZhY2UsIG5v bi1yZXB1ZGlhdGlvbiBjYW4gYmUgdXNlZCB0bzoKCiAgIDEuIHByb3RlY3QgdGhlIGF1dGhlbnRp Y2l0eSBvZiBsb2dnaW5nIGluZm9ybWF0aW9uIGZyb20gbW9ua2V5LWluLXRoZS1taWRkbGUgYXR0 YWNrcy4KICAgMi4gcHJvdGVjdCBhIHVDRE4gcmVjZWl2aW5nIGxvZ2dpbmcgaW5mb3JtYXRpb24g ZnJvbSBhIGNoZWF0aW5nIGRDRE4uCiAgIDMuIGRpc3N1YWRlIGRDRE5zIGZyb20gY2hlYXRpbmcg dUNETnMuCgogICBGb3IgZXhhbXBsZSwgYSBjaGVhdGluZyBkQ0ROIGNvdWxkIGNsYWltIHRvIGhh dmUgc2VydmVkIG1vcmUgdHJhZmZpYyB0aGFuIGl0IGFjdHVhbGx5IGRpZC4gV2hlbiB0aGUgdUNE TiBjb25kdWN0cyBhbiBhdWRpdCBhbmQgZGlzY292ZXJzIHRoZSBmYWxzZSBjbGFpbSwgbm9uLXJl cHVkaWF0aW9uIHByZXZlbnRzIHRoZSBkQ0ROIGZyb20gY2xhaW1pbmcgdGhhdCB0aGUgaW5mb3Jt YXRpb24gd2FzIG1vZGlmaWVkIGluIHRyYW5zaXQgKDEpIG9yIHRoYXQgdGhlIHVDRE4gZmFsc2lm aWVkIHRoZSBpbmZvcm1hdGlvbiAoMikuIEFkZGl0aW9uYWxseSwgdGhlIGRDRE4ncyBrbm93bGVk Z2UgdGhhdCB0aGV5IGNvdWxkIGJlIGNhdWdodCBtYXkgZGlzc3VhZGUgdGhlbSBmcm9tIGNoZWF0 aW5nIGluIHRoZSBmaXJzdCBwbGFjZSAoMykuCgogICBUaGUgc2NvcGUgb2Ygbm9uLXJlcHVkaWF0 aW9uIGlzIGxvZ2dpbmcgZmVlZHMuIEVhY2ggbG9nZ2luZyBmZWVkIG1heSBvciBtYXkgbm90IHVz ZSBub24tcmVwdWRpYXRpb24sIGJ1dCBhIHNpbmdsZSBsb2dnaW5nIGZlZWQgTVVTVCBOT1QgdXNl IG5vbi1yZXB1ZGlhdGlvbiBmb3Igc29tZSBsb2cgZmlsZXMgYW5kIG5vdCBmb3Igb3RoZXJzLiBJ ZiBhIGxvZyBmaWxlIGFwcGVhcnMgaW4gbXVsdGlwbGUgZmVlZHMsIGl0IGlzIHRyZWF0ZWQgYXMg bXVsdGlwbGUgKGlkZW50aWNhbCkgZmlsZXMgZm9yIHRoZSBwdXJwb3NlIG9mIG5vbi1yZXB1ZGlh dGlvbi4KCiAgIEludGVncml0eSBhbmQgYXV0aGVudGljaXR5IGFyZSBwcm92aWRlZCBieSBub24t cmVwdWRpYXRpb24sIGJ1dCBjb25maWRlbnRpYWxpdHkgaXMgZXhwbGljaXRseSBub3QgcHJvdmlk ZWQgYnkgdGhpcyBub24tcmVwdWRpYXRpb24gbWVjaGFuaXNtLgoKMi4zLjEuIE5vbi1SZXB1ZGlh dGlvbiBQcm9jZXNzCgogICBOb24tcmVwdWRpYXRpb24gaXMgcGVyZm9ybWVkIHVzaW5nIGVwaGVt ZXJhbCBhc3ltbWV0cmljIGtleXMgYW5kIGRpZ2l0YWwgc2lnbmF0dXJlcy4gVGhlIHVzZSBvZiBl cGhlbWVyYWwga2V5cyBtaW5pbWl6ZXMgdGhlIGJ1cmRlbiBvbiBwcml2YXRlIGtleSBob2xkZXJz IHRvIHByb3RlY3QgdGhlaXIgcHJpdmF0ZSBrZXlzLiBBZGRpdGlvbmFsbHksIHRoZSBtZXRob2Qg b2Ygc3dpdGNoaW5nIGZyb20gb25lIGVwaGVtZXJhbCBrZXkgdG8gdGhlIG5leHQgcHJvdmlkZXMg bm9uLXJlcHVkaWF0aW9uIG9mIHRoZSAiZ2FwcyIgYmV0d2VlbiBsb2cgZmlsZSBlbnRyaWVzIGlu IGEgbG9nIGZlZWQuIFRoYXQgaXMsIG9uY2UgYSBkQ0ROJ3MgbG9nIGZlZWQgbGlzdHMgdHdvIGxv ZyBmaWxlcyBpbiBzZXF1ZW5jZSwgdGhlIGZhY3QgdGhhdCBubyB0aGlyZCBsb2cgZmlsZSBjYW1l IGJldHdlZW4gdGhvc2UgdHdvIGlzIGNyeXB0b2dyYXBoaWNhbGx5IGNsYWltZWQgYnkgdGhlIGRD RE4gYW5kIGNhbiBiZSB2ZXJpZmllZCBieSB0aGUgdUNETi4gSWYgYSBkQ0ROIGhhcyBtdWx0aXBs ZSBsb2cgZmVlZHMsIGVhY2ggZmVlZCBpcyBwcm90ZWN0ZWQgYnkgYSBzZXBhcmF0ZSBjaGFpbiBv ZiBlcGhlbWVyYWwga2V5cy4KCiAgIFRoZSBpbmZvcm1hdGlvbiBuZWVkZWQgZm9yIG5vbi1yZXB1 ZGlhdGlvbiBhc3NvY2lhdGVkIHdpdGggZWFjaCBsb2cgZmlsZSBlbnRyeSBpcyBzdG9yZWQgaW4g YSBzZXBhcmF0ZSBmaWxlIHRoYXQgaXMgcG90ZW50aWFsbHkgbXVjaCBzbWFsbGVyIHRoYW4gdGhl IGxvZyBmaWxlLiBUaGlzIHNlcGFyYXRlIGZpbGUgaXMgY2FsbGVkIGEgTm9uLXJlcHVkaWF0aW9u IEluZm9ybWF0aW9uIGZvciBhIExvZyAoTklMKSBmaWxlLiBGb3IgZWFjaCBsb2cgZmlsZSBlbnRy eSBpbiBhIG5vbi1yZXB1ZGlhdGVkIGxvZ2dpbmcgZmVlZCwgYW4gYXRvbTpsaW5rIHRhZyBwcm92 aWRlcyB0aGUgbG9jYXRpb24gb2YgdGhlIGFzc29jaWF0ZWQgTklMIGZpbGUuCgogICBUaGUgcmVz dCBvZiB0aGlzIHNlY3Rpb24gcHJvdmlkZXMgYW4gb3ZlcnZpZXcgb2YgdGhlIHByb2Nlc3MgdXNl ZCB0byBwcm92aWRlIG5vbi1yZXB1ZGlhdGlvbiBmb3IgYSBzaW5nbGUgbG9nZ2luZyBmZWVkLiBU aGUgdGVybSAib3JpZ2luYXRvciIgbWVhbnMgdGhlIGVudGl0eSAoZENETikgdGhhdCBpcyBzZW5k aW5nIGxvZyBmaWxlczsgInJlY2VpdmVyIiBtZWFucyB0aGUgZW50aXRpeSAodUNETikgcmVjZWl2 aW5nIGxvZyBmaWxlcy4gVGhlIGtleSBnZW5lcmF0aW9uIHN0ZXBzIE1VU1QgYmUgcGVyZm9ybWVk IHdpdGggYSBzdWl0YWJseSByYW5kb20gbnVtYmVyIGdlbmVyYXRvci4KCiAgIDEuIFRoZSBvcmln aW5hdG9yIGdlbmVyYXRlcyBhbiBpbml0aWFsIGtleSBwYWlyLgoKICAgMi4gVGhlIG9yaWdpbmF0 b3IgdGFrZXMgdGhlIGhhc2ggb2YgdGhlIHB1YmxpYyBrZXkgYW5kIHByb3ZpZGVzIGl0IHRvIHRo ZSByZWNlaXZlciB2aWEgYSBjaGFubmVsIHRoYXQgcHJvdGVjdHMgaW50ZWdyaXR5IGFuZCBhdXRo ZW50aWNpdHkuIEZvciBleGFtcGxlLCB0aGUgaGFzaCBvZiB0aGUgcHVibGljIGtleSBjb3VsZCBi ZSBleGNoYW5nZWQgaW4gcGVyc29uIHdoZW4gYSBjb250cmFjdCBpcyBzaWduZWQuIEhvd2V2ZXIs IHRoZSBleGFjdCBjaGFubmVsIHVzZWQgaXMgb3V0IG9mIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQu IAoKICAgMy4gRm9yIGVhY2ggbG9nIGZpbGUgZW50cnk6CgogICAgICAxLiBUaGUgb3JpZ2luYXRv ciBnZW5lcmF0ZXMgYSBuZXcga2V5IHBhaXIuCgogICAgICAyLiBUaGUgb3JpZ2luYXRvciBpbmNs dWRlcyB0aGUgaGFzaCBvZiB0aGUgbmV3IHB1YmxpYyBrZXksIHRoZSBlbnRpcmUgY3VycmVudCBw dWJsaWMga2V5LCBhbmQgdGhlIGhhc2ggb2YgdGhlIGxvZyBmaWxlIGluIHRoZSBOSUwgZmlsZS4g VGhlIG9yaWdpbmF0b3IgdGhlbiB1c2VzIHRoZSBjdXJyZW50IHByaXZhdGUga2V5IHRvIHNpZ24g dGhlIE5JTCBmaWxlLgoKICAgICAgMy4gVGhlIG9yaWdpbmF0b3Igc2VjdXJlbHkgZGVsZXRlcyB0 aGUgY3VycmVudCBwcml2YXRlIGtleSwgdGhlbiBjb25zaWRlcnMgdGhlIG5ldyBrZXkgcGFpciB0 byBiZSB0aGUgY3VycmVudCBrZXkgcGFpci4KCiAgICAgIDQuIE9uIHJlY2VpcHQgb2YgdGhlIGxv ZyBmaWxlIGVudHJ5LCB0aGUgcmVjZWl2ZXIgZG93bmxvYWRzIHRoZSBOSUwgZmlsZSBhbmQgdGhl IGxvZyBmaWxlLiBUaGUgcmVjZWl2ZXIgdmVyaWZpZXMgdGhhdCB0aGUgcHVibGljIGtleSBpbiB0 aGUgTklMIGZpbGUgbWF0Y2hlcyB0aGUgbmV4dC1rZXkgaGFzaCBpbiB0aGUgcHJldmlvdXMgTklM IGZpbGUgKG9yIHRoZSBpbml0aWFsIGhhc2ggaWYgdGhpcyBpcyB0aGUgZmlyc3QgZW50cnkpLCB0 aGF0IHRoZSBoYXNoIG9mIHRoZSBsb2cgZmlsZSBtYXRjaGVzIHRoZSBoYXNoIGNsYWltZWQgYnkg dGhlIE5JTCBmaWxlLCBhbmQgdGhhdCB0aGUgc2lnbmF0dXJlIGlzIHZhbGlkLiBJZiB0aGUgcmVj ZWl2ZXIgZG9lcyBub3QgY2FyZSBhYm91dCB0aGUgY29udGVudHMgb2YgdGhlIGxvZyBmaWxlLCB0 aGV5IE1BWSBza2lwIGRvd25sb2FkaW5nIHRoZSBsb2cgZmlsZSBhbmQgY2hlY2tpbmcgaXRzIGhh c2gsIGJ1dCBub24tcmVwdWRpYXRpb24gb2YgdGhlIGxvZyBmaWxlIGlzIG5vdCBwcm92aWRlZCBp biB0aGlzIGNhc2UuCgogICBCb3RoIHRoZSBvcmlnaW5hdG9yIGFuZCB0aGUgcmVjZWl2ZXIgTVVT VCByZXRhaW4gdGhlIGluaXRpYWwgcHVibGljIGtleSBoYXNoIGFuZCB0aGUgY29udGVudHMgb2Yg YWxsIE5JTCBmaWxlcyB1bnRpbCBub24tcmVwdWRpYXRpb24gb2YgdGhlIGxvZ2dpbmcgZmVlZCBp cyBubyBsb25nZXIgZGVzaXJlZC4gQWRkaXRpb25hbGx5LCB0aGUgcmVjZWl2ZXIgTVVTVCB2ZXJp ZnkgdGhhdCB0aGUgcHVibGljIGtleXMgaW4gTklMIGZpbGVzIGFyZSBuZXZlciByZXVzZWQuIElm IGEgbmV3IE5JTCBmaWxlIGlzIHJlY2VpdmVkIHRoYXQgY29udGFpbnMgYSBrZXkgdGhhdCB3YXMg YWxyZWFkeSB1c2VkIGJ5IGEgcHJldmlvdXMgTklMIGZpbGUsIHRoZSByZWNlaXZlciBzaG91bGQg YXNzdW1lIHRoYXQgdGhlIHJldXNlZCBrZXkgd2FzIGNvbXByb21pc2VkLgoKICAgSWYgdGhlIG9y aWdpbmF0b3IgZGlzY292ZXJzIHRoYXQgdGhlaXIgY3VycmVudCBwcml2YXRlIGtleSBoYXMgYmVl biBjb21wcm9taXNlZCwgdGhleSBNVVNUIE5PVCB1c2UgdGhlIHByaXZhdGUga2V5IGFuZCB0aGV5 IE1VU1QgaW5mb3JtIHRoZSByZWNlaXZlciB0aGF0IHRoZSBrZXkgaGFzIGJlZW4gY29tcHJvbWlz ZWQuIFRoZXkgTUFZIHRoZW4gc3RhcnQgdGhlIHByb2Nlc3MgYWdhaW4gZnJvbSBzdGVwIDEuIElm IHRoZSBvcmlnaW5hdG9yIGRpc2NvdmVycyB0aGF0IGEgcHJldmlvdXMgcHJpdmF0ZSBrZXkgd2Fz IGNvbXByb21pc2VkLCB0aGV5IE1VU1QgZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIHJlY2VpdmVyIHN0 aWxsIHRydXN0cyB0aGF0IGtleS4gSWYgdGhlIHJlY2VpdmVyIGhhcyBtb3ZlZCBvbiBhbmQgbm93 IHRydXN0cyBhIG5ld2VyIChub24tY29tcHJvbWlzZWQpIGtleSwgbm8gZnVydGhlciBhY3Rpb24g aXMgbmVjZXNzYXJ5IGJlY2F1c2UgdGhlIHJlY2VpdmVyIHdpbGwgb25seSB0cnVzdCBrZXlzIHNp Z25lZCBieSB0aGUgbmV3ZXIgKG5vbi1jb21wcm9taXNlZCkga2V5LiBJZiB0aGUgcmVjZWl2ZXIg c3RpbGwgdHJ1c3RzIHRoZSBjb21wcm9taXNlZCBrZXksIHRoZW4gdGhlIG9yaWdpbmF0b3IgTVVT VCBpbmZvcm0gdGhlIHJlY2VpdmVyIHRoYXQgdGhlIGtleSBoYXMgYmVlbiBjb21wcm9taXNlZCBh bmQgdGhleSBNQVkgc3RhcnQgdGhlIHByb2Nlc3MgYWdhaW4gZnJvbSB0aGUgc3RhcnQuIEhvdyB0 aGUgb3JpZ2luYXRvciBkZXRlcm1pbmVzIHdoaWNoIGtleSBpcyB0cnVzdGVkIGJ5IHRoZSByZWNl aXZlciBhbmQgaW5mb3JtcyB0aGUgcmVjZWl2ZXIgb2YgYSBjb21wcm9taXNlIGFyZSBvdXQgb2Yg c2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCiAgIFRvIG1pbmltaXplIHRoZSByaXNrIGZyb20gYSBr ZXkgY29tcHJvbWlzZSwgdGhlIGVwaGVtZXJhbCBrZXlzIE1VU1QgYmUgcm90YXRlZCBubyBsZXNz IGZyZXF1ZW50bHkgdGhhbiBvbmNlIHBlciAyNCBob3VycyBieSBwZXJmb3JtaW5nIHN0ZXAgMyBh Ym92ZS4gSWYgdGhlIG9yaWdpbmF0b3IgZG9lcyBub3QgaGF2ZSBhbnkgbG9nZ2luZyBpbmZvcm1h dGlvbiByZWFkeSwgdGhlIGxvZyBmaWxlIHVzZWQgTUFZIGNvbnRhaW4gemVybyBMb2dnaW5nIFJl Y29yZHMuCgoyLjMuMi4gTm9uLVJlcHVkaWF0aW9uIEFsZ29yaXRobXMKCiAgIEEga2V5IHBhaXIg dXNlZCBmb3Igbm9uLXJlcHVkaWF0aW9uIE1VU1QgYmUgUlNBIHdpdGggYSAyMDQ4LWJpdCBtb2R1 bHVzIGFuZCBhIHB1YmxpYyBleHBvbmVudCAoZSkgb2YgNjUsNTM3LiBQdWJsaWMga2V5cyB0cmFu c21pdHRlZCBieSB0aGUgTG9nZ2luZyBJbnRlcmZhY2UgTVVTVCBiZSBlbmNvZGVkIGFzIHRoZSBC YXNlNjQgW1JGQzQ2NDhdIGVuY29kaW5nIG9mIHRoZSBERVIgW1guNjkwXSBlbmNvZGluZyBvZiBS U0FQdWJsaWNLZXkgW1JGQzQwNTVdLiBIYXNoZXMgb2YgcHVibGljIGtleXMgTVVTVCB1c2UgdGhl IERFUiBlbmNvZGluZyBvZiBSU0FQdWJsaWNLZXkuCgogICBBbGwgaGFzaGVzIHVzZWQgZm9yIG5v bi1yZXB1ZGlhdGlvbiBNVVNUIGJlIFNIQS0yNTYgW1NIU10uIEhhc2hlcyB0cmFuc21pdHRlZCBi eSB0aGUgTG9nZ2luZyBJbnRlcmZhY2UgTVVTVCBiZSBlbmNvZGVkIGFzIGhleGFkZWNpbWFsLgoK ICAgVGhlIHNpZ25hdHVyZSBhbGdvcml0aG0gdXNlZCBmb3Igbm9uLXJlcHVkaWF0aW9uIE1VU1Qg YmUgUlNBIFB1YmxpYy1LZXkgQ3J5cHRvZ3JhcGh5IFN0YW5kYXJkcyAoUEtDUykgIzEgVmVyc2lv biAxLjUgZnJvbSBTZWN0aW9uIDUgb2YgW1JGQzQwNTVdIGNvbWJpbmVkIHdpdGggdGhlIGFib3Zl IGhhc2ggYWxnb3JpdGhtLCBSU0EgUEtDUyMxIHYxLjUgd2l0aCBTSEEtMjU2LiBTaWduYXR1cmVz IHRyYW5zbWl0dGVkIGJ5IHRoZSBMb2dnaW5nIEludGVyZmFjZSBNVVNUIGJlIGVuY29kZWQgYXMg QmFzZTY0LgoKCjMuMS4gQ0ROSSBMb2dnaW5nIEZpbGUgRGlyZWN0aXZlcwoKW1RPRE86IGNoYW5n ZSB0ZXh0IGZvciBWZXJpZmllZC1PcmlnaW4gYW5kIEludGVncml0eS1IYXNoIHNvIHRoYXQgdGhl eSBNVVNUIE5PVCBiZSBtb2RpZmllZCBieSB0aGUgdUNETiBpZiBub24tcmVwdWRpYXRpb24gaXMg YmVpbmcgdXNlZF0KCgpYLiBDRE5JIE5vbi1yZXB1ZGlhdGlvbiBJbmZvcm1hdGlvbiBmb3IgYSBM b2cgKE5JTCkgRmlsZSBbWCA9IG5ldyBzZWN0aW9uIGJldHdlZW4gMyBhbmQgNF0KCiAgIE5vbi1y ZXB1ZGlhdGlvbiBJbmZvcm1hdGlvbiBmb3IgYSBMb2cgKE5JTCkgZmlsZXMgcHJvdmlkZSBhZGRp dGlvbmFsIGluZm9ybWF0aW9uIGZvciBub24tcmVwdWRpYXRpb24gb2YgbG9nIGZpbGUgZW50cmll cyBpbiBhIGxvZ2dpbmcgZmVlZC4gTklMIGZpbGVzIGFyZSBmb3JtYXR0ZWQgYXMgc3RydWN0dXJl ZCBwbGFpbiB0ZXh0IGZpbGVzLCB3aXRoIGVhY2ggbGluZSBjb250YWluaW5nIGEga2V5LXZhbHVl IHBhaXIuIEhvd2V2ZXIsIHRoZSBrZXlzIGFyZSByZWZlcnJlZCB0byBhcyAidGFncyIgdG8gYXZv aWQgY29uZnVzaW9uIHdpdGggY3J5cHRvZ3JhcGhpYyBrZXlzLiBUaGUgZm9ybWF0IG9mIE5JTCBm aWxlcyBpcyBzcGVjaWZpZWQgdXNpbmcgdGhlIEF1Z21lbnRlZCBCYWNrdXMtTmF1ciBGb3JtIChB Qk5GKSBub3RhdGlvbiBhbmQgY29yZSBydWxlcyBvZiBbUkZDNTIzNF06CgogICAgICBOSUxGSUxF ID0gKkxJTkUKCiAgICAgIExJTkUgPSBUQUcgU1AgVkFMVUUgQ1JMRgoKICAgICAgVEFHID0gMSoo QUxQSEEgLyAiLSIpCgogICAgICBWQUxVRSA9IDEqKEFMUEhBIC8gRElHSVQgLyAiKyIgLyAiLyIg LyAiPSIpCgogICBBbGwgb2YgdGhlIGJlbG93IHRhZ3MgTVVTVCBiZSBwcmVzZW50IGFuZCBhbGwg b3RoZXIgdGFncyBNVVNUIE5PVCBiZSBwcmVzZW50LiBFYWNoIHRhZyBNVVNUIE5PVCBhcHBlYXIg bW9yZSB0aGFuIG9uY2UgaW4gYSBOSUwgZmlsZS4KCiAgICogIE5vbi1SZXB1ZGlhdGlvbi1WZXJz aW9uOgoKICAgICAgVGhlIHZlcnNpb24gb2YgdGhlIE5JTCBmaWxlLiBJdCBNVVNUIGJlIGV4YWN0 bHkgIjAiLiBJdCBNVVNUIGJlIHRoZSBmaXJzdCBsaW5lIGluIHRoZSBOSUwgZmlsZS4KCiAgICog IE5vbi1SZXB1ZGlhdGlvbi1IYXNoLUFsZ29yaXRobToKCiAgICAgIFRoZSBoYXNoIGFsZ29yaXRo bSB1c2VkIGZvciBub24tcmVwdWRpYXRpb24uIEl0IE1VU1QgYmUgZXhhY3RseSAic2hhMjU2Ii4K CiAgICogIE5vbi1SZXB1ZGlhdGlvbi1TaWduYXR1cmUtQWxnb3JpdGhtOgoKICAgICAgVGhlIHNp Z25hdHVyZSBhbGdvcml0aG0gdXNlZCBmb3Igbm9uLXJlcHVkaWF0aW9uLiBJdCBNVVNUIGJlIGV4 YWN0bHkgInNoYTI1NndpdGhSU0FFbmNyeXB0aW9uIi4KCiAgICogIE5vbi1SZXB1ZGlhdGlvbi1Q dWJsaWMtS2V5OgoKICAgICAgVGhlIHB1YmxpYyBrZXkgdXNlZCB0byBzaWduIHRoaXMgZmlsZS4g VGhlIGZvcm1hdCBpcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjMuMi4KCiAgICogIE5vbi1SZXB1 ZGlhdGlvbi1QdWJsaWMtS2V5LUhhc2g6CgogICAgICBUaGUgaGFzaCBvZiB0aGUgcHVibGljIGtl eSBpbiBOb24tUmVwdWRpYXRpb24tUHVibGljLUtleS4gTG9nIHJlY2VpdmVycyBNVVNUIHZlcmlm eSB0aGF0IHRoaXMgaXMgdGhlIGNvcnJlY3QgaGFzaCB2YWx1ZSBmb3IgdGhlIGdpdmVuIGtleS4g VGhlIGZvcm1hdCBpcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjMuMi4gSWYgdGhpcyBOSUwgZmls ZSBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIGZpcnN0IGVudHJ5IGluIGEgbG9nZ2luZyBmZWVkLCB0 aGlzIGhhc2ggTVVTVCBiZSBlcXVhbCB0byB0aGUgaGFzaCBmcm9tIHN0ZXAgMiBvZiBTZWN0aW9u IDIuMy4xLiBPdGhlcndpc2UsIHRoaXMgaGFzaCBNVVNUIGJlIGVxdWFsIHRvIHRoZSB2YWx1ZSBv ZiBOb24tUmVwdWRpYXRpb24tTmV4dC1QdWJsaWMtS2V5LUhhc2ggaW4gdGhlIHByZXZpb3VzIE5J TCBmaWxlIGluIHRoZSBzZXF1ZW5jZS4KCiAgICogIE5vbi1SZXB1ZGlhdGlvbi1OZXh0LVB1Ymxp Yy1LZXktSGFzaDoKCiAgICAgIFRoZSBoYXNoIG9mIHRoZSBwdWJsaWMga2V5IHRoYXQgd2lsbCBi ZSB1c2VkIGluIHRoZSBuZXh0IE5JTCBmaWxlLiBJZiB0aGlzIE5JTCBmaWxlIGlzIHRoZSBsYXN0 IGluIGEgc2VxdWVuY2UgKGUuZy4sIGlmIHRoZSBkQ0ROIGFuZCB1Q0ROIGhhdmUgdGVybWluYXRl ZCB0aGVpciBidXNpbmVzcyByZWxhdGlvbnNoaXAgb3IgZGVjaWRlZCB0byBzdG9wIHVzaW5nIG5v bi1yZXB1ZGlhdGlvbiksIHRoaXMgZmllbGQgTVVTVCBiZSBzZXQgdG8gdGhlIHplcm8taGFzaCwg IjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAiLgoKICAgKiAgTm9uLVJlcHVkaWF0aW9uLURhdGEtSGFzaDoKCiAgICAgIFRoZSBo YXNoIG9mIHRoZSBhc3NvY2lhdGVkIGxvZyBmaWxlLiBUaGUgZm9ybWF0IGlzIHNwZWNpZmllZCBp biBTZWN0aW9uIDIuMy4yLgoKICAgKiAgTm9uLVJlcHVkaWF0aW9uLVNpZ25hdHVyZToKCiAgICAg IFRoZSBkaWdpdGFsIHNpZ25hdHVyZSBvZiBldmVyeXRoaW5nIGVsc2UgaW4gdGhpcyBOSUwgZmls ZS4gVGhlIGZvcm1hdCBpcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiAyLjMuMi4gSXQgTVVTVCBiZSB0 aGUgbGFzdCBsaW5lIGluIHRoZSBOSUwgZmlsZS4gVGhlIHNpZ25hdHVyZSBjb3ZlcnMgYWxsIHBy ZXZpb3VzIGxpbmVzIGluIG9yZGVyIChpbmNsdWRpbmcgZWFjaCBsaW5lJ3MgQ1JMRiksIGFuZCBp cyBtYWRlIHdpdGggdGhlIHByaXZhdGUga2V5IGNvcnJlc3BvbmRpbmcgdG8gTm9uLVJlcHVkaWF0 aW9uLVB1YmxpYy1LZXkgYW5kIHZlcmlmaWVkIHdpdGggdGhlIHB1YmxpYyBrZXkgaW4gTm9uLVJl cHVkaWF0aW9uLVB1YmxpYy1LZXkuCgoKW1RPRE86IEFkZCBkZXNjcmlwdGlvbiBvZiBhdG9tOmxp bmsgdG8gTklMIGZpbGVzIGluIGF0b206ZW50cnkgaW4gU2VjdGlvbiA0LiBTcGVjaWZ5IHRoYXQg dUNETnMgTVVTVCBmZXRjaCBhbmQgdmVyaWZ5IGFsbCBOSUwgZmlsZXMgaWYgdGhleSBjYXJlIGFi b3V0IG5vbi1yZXB1ZGlhdGlvbi5dCgoKNy4yLiBOb24gUmVwdWRpYXRpb24KCiAgIE5vbi1yZXB1 ZGlhdGlvbiB3aXRoIHByb29mIG9mIG9yaWdpbiBvZiBsb2dnaW5nIGluZm9ybWF0aW9uIGlzIGRl c2NyaWJlZCBpbiBTZWN0aW9ucyAyLjMgYW5kIFNlY3Rpb24gWC4gVGhlIG5vbi1yZXB1ZGlhdGlv biBjb3ZlcnMgYm90aCBpbmRpdmlkdWFsIGxvZyBmaWxlcyBhbmQgc2VxdWVuY2VzIG9mIGxvZyBm aWxlIGVudHJpZXMgaW4gYSBmZWVkLgoKICAgVGhlIG1lY2hhbmlzbSBmb3Igbm9uLXJlcHVkaWF0 aW9uIGRlcGVuZHMgb24gdGhlIGF1dGhlbnRpY2l0eSBvZiB0aGUgaW5pdGlhbCBwdWJsaWMga2V5 IGhhc2ggaW4gU3RlcCAyIG9mIFNlY3Rpb24gMi4zLjEuIFRoZXJlZm9yZSwgd2hlbiB1c2luZyBu b24tcmVwdWRpYXRpb24gaXQgaXMgaW1wZXJhdGl2ZSB0byBhZGVxdWF0ZWx5IHByb3RlY3QgdGhl IGV4Y2hhbmdlIG9mIHRoZSBpbml0aWFsIHB1YmxpYyBrZXkgaGFzaC4KCiAgIFRoZSBwcml2YXRl IGtleXMgdXNlZCBmb3Igbm9uLXJlcHVkaWF0aW9uIE1VU1QgTk9UIGJlIHJldXNlZCBmb3IgYW55 IHB1cnBvc2UuIFJldXNlIG9mIGEga2V5IGZvciBsb2cgZmlsZSBub24tcmVwdWRpYXRpb24gd291 bGQgY29tcHJvbWlzZSB0aGUgcHJvdGVjdGlvbiBvZiB0aGUgc2VxdWVuY2Ugb2YgbG9nIGZpbGVz LiBSZXVzZSBvZiBhIGtleSB0byBwZXJmb3JtIGEgZGlnaXRhbCBzaWduYXR1cmUgZm9yIGFueSBv dGhlciBwdXJwb3NlIGNvdWxkIGNvbXByb21pc2UgdGhlIG5vbi1yZXB1ZGlhdGlvbiBvZiBsb2dn aW5nIGluZm9ybWF0aW9uIGlmIHRoZSBrZXkgaXMgdXNlZCB0byBzaWduIGFueXRoaW5nIHRoYXQg cGFyc2VzIGFzIGEgTklMIGZpbGUuCgogICBTZWN0aW9uIDIuMy4yIGRlc2NyaWJlcyB0aGUgYWxn b3JpdGhtcyB1c2VkIGZvciBub24tcmVwdWRpYXRpb24uIElmIGV4cGxvaXRhYmxlIHZ1bG5lcmFi aWxpdGllcyBpbiBhbnkgb2YgdGhlc2UgYWxnb3JpdGhtcyBhcmUgbGF0ZXIgZGlzY292ZXJlZCwg YSBzdWJzZXF1ZW50IGRvY3VtZW50IHdpbGwgaGF2ZSB0byBzZWxlY3QgbW9yZSBzZWN1cmUgYWxn b3JpdGhtcyBhbmQgZGVzY3JpYmUgYSB0cmFuc2l0aW9uIG1lY2hhbmlzbSBmcm9tIHRoZSBvbGQg YWxnb3JpdGhtcyB0byB0aGUgbmV3IG9uZXMuIFRoZSBOb24tUmVwdWRpYXRpb24tSGFzaC1BbGdv cml0aG0gYW5kIE5vbi1SZXB1ZGlhdGlvbi1TaWduYXR1cmUtQWxnb3JpdGhtIHRhZ3MgaW4gU2Vj dGlvbiBYIGFyZSBwcm92aWRlZCBpbiB0aGlzIGRvY3VtZW50IHRvIGFpZCB0aGUgaHlwb3RoZXRp Y2FsIHN1YnNlcXVlbnQgZG9jdW1lbnQgaW4gcHJvdmlkaW5nIGEgdHJhbnNpdGlvbiBtZWNoYW5p c20uCg== --=_31ee1876d779328709bc25a4325ab09d-- From yang.r.yang@gmail.com Tue Jul 30 15:10:55 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1D511E8214 for ; Tue, 30 Jul 2013 15:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIYasNM9agTx for ; Tue, 30 Jul 2013 15:10:51 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 68C0A11E81D4 for ; Tue, 30 Jul 2013 15:10:50 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz10so78241pad.30 for ; Tue, 30 Jul 2013 15:10:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=HtaC/Y9/ZXz0dTgJ4DixpdoJV72I2CUWtDUwYDbE/g0=; b=z4flV6hrkbwLweq/AspQk1Xo7z9Jcb2B0rM37eB96ThXFagCAjx/JSGEKoMw972pG7 KWMtvldUgpXPG3ktFC9gjJcUdCRIkDcr/MDbN6iFI+W4PhkT2B/aqWoCLpRwxt32atqf kjpQHO0wq00UeEexd1iyQv/1hRJNVC5jOF3l7txCIinsp6aECgVJpEYvqwmzrqerebpy fPpafGqbA+fhXLHU5WUf9xAxyyGWlEGavLGzNI+m6qJVBRFGmZa3USNfPBOtEIM7bvKy Sxkp1XIM7QCafUo26m/ttAinUpeSFhelI3+D/xUYJm+C2ID1vYIZKislwOTGxq/74f1i 0ffg== MIME-Version: 1.0 X-Received: by 10.66.162.195 with SMTP id yc3mr30555374pab.64.1375222249833; Tue, 30 Jul 2013 15:10:49 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.68.238.166 with HTTP; Tue, 30 Jul 2013 15:10:49 -0700 (PDT) In-Reply-To: References: <20130715152620.5664.97237.idtracker@ietfa.amsl.com> <2779C9F0771F974CAD742BAE6D9904FE5558D028@DAPHNIS.office.hd> <2779C9F0771F974CAD742BAE6D9904FE555973DE@DAPHNIS.office.hd> Date: Tue, 30 Jul 2013 18:10:49 -0400 X-Google-Sender-Auth: vI0eCEc-8aRsTzymF8svM-5AzI0 Message-ID: From: "Y. Richard Yang" To: Kevin J Ma Content-Type: multipart/alternative; boundary=047d7b6dc1a8b0e53704e2c1e100 Cc: "cdni@ietf.org" Subject: [CDNi] FW: New Version Notification for draft-seedorf-cdni-request-routing-alto-04.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 22:10:55 -0000 --047d7b6dc1a8b0e53704e2c1e100 Content-Type: text/plain; charset=ISO-8859-1 Hi Kevin, Not in a position to answer the questions for Jan. But some of your questions are quite interesting to me, and hence the reply. On Tue, Jul 30, 2013 at 8:10 AM, Kevin J Ma wrote: > Hi Jan, > > I read through the updated draft and had a couple questions: > > section 4.2: "where each PID name has a certain 'capability' semantic." > Does each capability need its own PID? or can capabilities > be grouped if they currently have the same footprint, and > then later ungrouped if a given capability's footprint > changes? > > I have not seen Jan's detailed encoding yet. If I read your question correctly, you are looking into the coding efficiency problem, which is excellent thinking ahead. I see the following encoding approaches: 1. Simple: each PID denotes one and only one capability: "http" : { "ipv4" : [ "0.0.0.0/0", ], "ipv6":[ "::/0" ] }, "https" : { ... }, "rmtp" : { ... } 2. Slight more complex: each PID can denote a subset of capabilities (and even disabilities). A straightforward approach is to build a binary decision tree, with left support and right not. Each PID denotes a node in the decision tree: "http" : { // set of IP addresses }, "!http+https" : { // } 3. Even more complex: introduce coupled network maps, such as country/locode (http://www.unece.org/cefact/locode/service/location.html), and then express capabilities on top of these PIDs: network map 1: "us/ne" : { // IP prefixes } "de" : { // IP prefixes } network map 2, which uses network map 1: Using either 1 or 2 above, but based on network map 1, i.e., using PIDs defined in network map 1 as "atoms": "http" : {"us/ne", "de"}, "https" : {"de"} I am sure others can propose additional schemes. Which scheme is more efficient will depend on the correlation patterns. Assume K capabilities. Consider a given d-CDN that will have M IP prefixes to announce. What one may look into is the correlation patterns (clustering, in particular) of the K* P items and then decide the most effective "compression", both for typical cases and for updates (delete/addition). I do not see fundamental issues in expressing them using network maps but as you pointed out, the right schema, based on app knowledge on correlation, can lead to better compressions than using generic compression algorithms. > section 5: "dowmstream" -> "downstream" > > In figure 2 of the framework document there is an > "[Async FCI Push]". Without the Web Socket extension, > would an ALTO-based FCI required the uCDN to poll the dCDN? > I think we would want asynchronous push from dCDN to uCDN, > or at least a triggered pull? > > wrt content and resource availability, are there existing > extensions (not cited), or are those just future thoughts? > > There are proposals on incremental updates and push in ALTO. It is an item that the WG will fix the details quickly. > section 6: the cited section 8.2.2 of the alto draft does not discuss > authentication signatures. There is no section 8.2.2. I > did see section 14 discusses HTTP digest auth over TLS? > > Sorry, the ALTO protocol is going through some major restructures lately. We are targeting a mid-August date as the date to finalize the base protocol. Thanks! Richard > and section 3.2 states that: > "Additional protocol mechanisms (e.g., expiration times and > digital > signatures for returned ALTO information) are left for future > investigation." > > thanx. > > -- Kevin J. Ma > > > -----Original Message----- > > From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of > > Jan Seedorf > > Sent: Tuesday, July 16, 2013 4:41 AM > > To: cdni@ietf.org > > Subject: [CDNi] FW: New Version Notification for draft-seedorf-cdni- > > request-routing-alto-04.txt > > > > Hi all, > > > > I have submitted a revision of the draft that outlines how ALTO can be a > > solution protocol for the CDNI FCI. The latest version has been changed > > quite a bit; it re-visits the latest conclusions in the FCI design team, > > and describes how ALTO could be used to advertise the types of footprint > > and capabilities that are considered as mandatory by the design team. > > > > - Jan > > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, July 15, 2013 5:26 PM > > To: Jan Seedorf > > Subject: New Version Notification for draft-seedorf-cdni-request-routing- > > alto-04.txt > > > > > > A new version of I-D, draft-seedorf-cdni-request-routing-alto-04.txt > > has been successfully submitted by Jan Seedorf and posted to the > > IETF repository. > > > > Filename: draft-seedorf-cdni-request-routing-alto > > Revision: 04 > > Title: CDNI Request Routing with ALTO > > Creation date: 2013-07-15 > > Group: Individual Submission > > Number of pages: 15 > > URL: http://www.ietf.org/internet-drafts/draft-seedorf-cdni- > > request-routing-alto-04.txt > > Status: http://datatracker.ietf.org/doc/draft-seedorf-cdni- > > request-routing-alto > > Htmlized: http://tools.ietf.org/html/draft-seedorf-cdni-request- > > routing-alto-04 > > Diff: http://www.ietf.org/rfcdiff?url2=draft-seedorf-cdni- > > request-routing-alto-04 > > > > Abstract: > > Network Service Providers (NSPs) are currently considering to deploy > > Content Delivery Networks (CDNs) within their networks. As a > > consequence of this development, there is a need for interconnecting > > these local CDNs. The necessary interfaces for inter-connecting CDNs > > are currently being defined in the Content Delivery Networks > > Interconnection (CDNI) WG. This document focuses on the CDNI > > Footprint & Capabilities Advertisement interface (FCI). > > Specifically, this document outlines how the solutions currently > > being defined in the Application Layer Traffic Optimization (ALTO) WG > > can facilitate Footprint & Capabilities Advertisement in a CDNI > > context, i.e. how the CDNI FCI can be realised with the ALTO > > protocol. Concrete examples of how ALTO can be integrated within > > CDNI request routing and in particular in the process of selecting a > > downstream CDN are given. The examples in this document are based on > > the use cases and examples currently being discussed in the CDNI WG. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > CDNi mailing list > > CDNi@ietf.org > > https://www.ietf.org/mailman/listinfo/cdni > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni > --047d7b6dc1a8b0e53704e2c1e100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Kevin,

Not in a position to answer t= he=A0questions for Jan. But some of your questions are quite interesting to= me, and hence the reply.


On Tue, Jul 30, 2013 at 8:10 AM, Kevin J Ma <kevin.= ma@azukisystems.com> wrote:
Hi Jan,

=A0 I read through the updated draft and had a couple questions:

section 4.2: "where each PID name has a certain 'capability' s= emantic."
=A0 =A0 =A0 =A0 =A0 =A0 =A0Does each capability need its own PID? =A0or can= capabilities
=A0 =A0 =A0 =A0 =A0 =A0 =A0be grouped if they currently have the same footp= rint, and
=A0 =A0 =A0 =A0 =A0 =A0 =A0then later ungrouped if a given capability's= footprint changes?


I have not seen= Jan's detailed encoding yet. If I read your question correctly, you ar= e looking into the coding efficiency problem, which is excellent thinking a= head. I see the following encoding approaches:

1. Simple: each PID denotes one and only one capability= :

"http" : {  "i=
pv4" : [
             "0.0.0.0/0",
            ],
            "ipv6":[
             "::/0"
            ]
 },
 "https" : {
   ...
 },
 "rmtp" :  {
   ...
}


2. Slight mor= e complex: each PID can denote a subset of capabilities (and even disabilit= ies). A straightforward approach is to build a binary decision tree, with l= eft support and right not. Each PID denotes a node in the decision tree:

"http" : { // set of IP addresses },
"!http+https" : { // }

3. E= ven more complex: introduce coupled network maps, such as country/locode (<= a href=3D"http://www.unece.org/cefact/locode/service/location.html">http://= www.unece.org/cefact/locode/service/location.html), and then express ca= pabilities on top of these PIDs:

network map 1:

"us/ne&quo= t; : =A0{ // IP prefixes }
"de" : { // IP prefixes }

network map 2, which uses network map 1:
Using either 1 or 2 above, but based on network map 1, i.e., using PIDs def= ined in network map 1 as "atoms":

"= http" : {"us/ne", "de"},
"https&quo= t; : {"de"}

I am sure others can propose additional schemes. Which = scheme is more efficient will depend on the correlation patterns. Assume K = capabilities. Consider a given d-CDN that will have M IP prefixes to announ= ce. What one may look into is the correlation patterns (clustering, in part= icular) of the K* P items and then decide the most effective "compress= ion", both for typical cases and for updates (delete/addition). I do n= ot see fundamental issues in expressing them using network maps but as you = pointed out, the right schema, based on app knowledge on correlation, can l= ead to better compressions than using generic compression algorithms.=A0


section 5: "dowmstream" -> "downstream"

=A0 =A0 =A0 =A0 =A0 =A0In figure 2 of the framework document there is an =A0 =A0 =A0 =A0 =A0 =A0"[Async FCI Push]". =A0Without the Web Soc= ket extension,
=A0 =A0 =A0 =A0 =A0 =A0would an ALTO-based FCI required the uCDN to poll th= e dCDN?
=A0 =A0 =A0 =A0 =A0 =A0I think we would want asynchronous push from dCDN to= uCDN,
=A0 =A0 =A0 =A0 =A0 =A0or at least a triggered pull?

=A0 =A0 =A0 =A0 =A0 =A0wrt content and resource availability, are there exi= sting
=A0 =A0 =A0 =A0 =A0 =A0extensions (not cited), or are those just future tho= ughts?


There are proposals on incremental upd= ates and push in ALTO. It is an item that the WG will fix the details quick= ly.
=A0
=A0
section 6: the cited section 8.2.2 of the alto draft does not discuss
=A0 =A0 =A0 =A0 =A0 =A0authentication signatures. =A0There is no section 8.= 2.2. =A0I
=A0 =A0 =A0 =A0 =A0 =A0did see section 14 discusses HTTP digest auth over T= LS?


Sorry, the ALTO protocol is going thro= ugh some major restructures lately. We are targeting a mid-August date as t= he date to finalize the base protocol.

Thanks!

Richard
=A0
=A0 =A0 =A0 =A0 =A0 =A0and section 3.2 states that:
=A0 =A0 =A0 =A0 =A0 =A0"Additional protocol mechanisms (e.g., expirati= on times and digital
=A0 =A0 =A0 =A0 =A0 =A0 signatures for returned ALTO information) are left = for future
=A0 =A0 =A0 =A0 =A0 =A0 investigation."

thanx.

-- =A0Kevin J. Ma

> -----Original Message-----
> From: cdni-bounces@ietf.org [mailto:cdni-bounces@ietf.org] On Behalf Of
> Jan Seedorf
> Sent: Tuesday, July 16, 2013 4:41 AM
> To: cdni@ietf.org
> Subject: [CDNi] FW: New Version Notification for draft-seedorf-cdni- > request-routing-alto-04.txt
>
> Hi all,
>
> I have submitted a revision of the draft that outlines how ALTO can be= a
> solution protocol for the CDNI FCI. The latest version has been change= d
> quite a bit; it re-visits the latest conclusions in the FCI design tea= m,
> and describes how ALTO could be used to advertise the types of footpri= nt
> and capabilities that are considered as mandatory by the design team.<= br> >
> =A0- Jan
>
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.= org]
> Sent: Monday, July 15, 2013 5:26 PM
> To: Jan Seedorf
> Subject: New Version Notification for draft-seedorf-cdni-request-routi= ng-
> alto-04.txt
>
>
> A new version of I-D, draft-seedorf-cdni-request-routing-alto-04.txt > has been successfully submitted by Jan Seedorf and posted to the
> IETF repository.
>
> Filename: =A0 =A0 =A0draft-seedorf-cdni-request-routing-alto
> Revision: =A0 =A0 =A004
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 CDNI Request Routing with ALTO<= br> > Creation date: =A0 =A0 =A0 =A0 2013-07-15
> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 15
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-d= rafts/draft-seedorf-cdni-
> request-routing-alto-04.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draf= t-seedorf-cdni-
> request-routing-alto
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-se= edorf-cdni-request-
> routing-alto-04
> Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff?url= 2=3Ddraft-seedorf-cdni-
> request-routing-alto-04
>
> Abstract:
> =A0 =A0Network Service Providers (NSPs) are currently considering to d= eploy
> =A0 =A0Content Delivery Networks (CDNs) within their networks. =A0As a=
> =A0 =A0consequence of this development, there is a need for interconne= cting
> =A0 =A0these local CDNs. =A0The necessary interfaces for inter-connect= ing CDNs
> =A0 =A0are currently being defined in the Content Delivery Networks > =A0 =A0Interconnection (CDNI) WG. =A0This document focuses on the CDNI=
> =A0 =A0Footprint & Capabilities Advertisement interface (FCI).
> =A0 =A0Specifically, this document outlines how the solutions currentl= y
> =A0 =A0being defined in the Application Layer Traffic Optimization (AL= TO) WG
> =A0 =A0can facilitate Footprint & Capabilities Advertisement in a = CDNI
> =A0 =A0context, i.e. how the CDNI FCI can be realised with the ALTO > =A0 =A0protocol. =A0Concrete examples of how ALTO can be integrated wi= thin
> =A0 =A0CDNI request routing and in particular in the process of select= ing a
> =A0 =A0downstream CDN are given. =A0The examples in this document are = based on
> =A0 =A0the use cases and examples currently being discussed in the CDN= I WG.
>
>
>
>
> The IETF Secretariat
>
> _______________________________________________
> CDNi mailing list
> CDNi@ietf.org
> https://www.ietf.org/mailman/listinfo/cdni
_______________________________________________
CDNi mailing list
CDNi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cdni
=A0

=A0

--047d7b6dc1a8b0e53704e2c1e100-- From kevin.ma@azukisystems.com Wed Jul 31 01:49:20 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45D0A21F9EC9 for ; Wed, 31 Jul 2013 01:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vkgfyq4s7tQ for ; Wed, 31 Jul 2013 01:49:15 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.243]) by ietfa.amsl.com (Postfix) with ESMTP id ED2E121E8130 for ; Wed, 31 Jul 2013 01:45:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 4937A8BF4ED; Wed, 31 Jul 2013 04:40:02 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB015.mail.lan (unknown [10.110.2.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mxout.myoutlookonline.com (Postfix) with ESMTPS id D55068BF3FB; Wed, 31 Jul 2013 04:40:01 -0400 (EDT) Received: from MAILR002.mail.lan ([10.110.18.16]) by HUB015.mail.lan ([10.110.17.15]) with mapi; Wed, 31 Jul 2013 04:44:54 -0400 From: Kevin J Ma To: David Mandelberg , "cdni@ietf.org" Date: Wed, 31 Jul 2013 04:44:53 -0400 Thread-Topic: [CDNi] logging non-repudiation proposed text v2 Thread-Index: Ac6NNAQr3QUzG/EkTf+Ql5PLCrHG+wAkZsJA Message-ID: <291CC3F9E50E7641901A54E85D0977C6665143293A@MAILR002.mail.lan> References: <61c081f757d55b0f0e57c7ab5252fc9b@mail.mandelberg.org> In-Reply-To: <61c081f757d55b0f0e57c7ab5252fc9b@mail.mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [CDNi] logging non-repudiation proposed text v2 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 08:49:20 -0000 SGkgRGF2aWQsDQoNCiAgSSByZWFkIHRocm91Z2ggdGhlIHRleHQgYW5kIGhhZCBhIGNvdXBsZSBv ZiBxdWVzdGlvbnM6DQoNCiAgLSBJbiBzZWN0aW9uIDIuMy4xLCB3cnQgcmFuZG9tIG51bWJlcnM6 DQoNCiAgICAgICJUaGUga2V5IGdlbmVyYXRpb24gc3RlcHMgTVVTVCBiZSBwZXJmb3JtZWQgd2l0 aCBhIHN1aXRhYmx5IHJhbmRvbQ0KICAgICAgIG51bWJlciBnZW5lcmF0b3IuIiANCg0KICAgIFNo b3VsZCB0aGVyZSBiZSBhIHJlZmVyZW5jZSB0byBSRkM0MDg2L0JDUDEwNiBvciBzb21lIG90aGVy DQogICAgZG9jdW1lbnQgb24gc3Ryb25nIHJhbmRvbSBudW1iZXIgZ2VuZXJhdGlvbiBmb3Iga2V5 cz8NCg0KICAtIEluIHNlY3Rpb24gMi4zLjEsIHdydCBzdGVwIDIgb2YgdGhlIGxvZyBmaWxlIHBy b2Nlc3Npbmc6DQoNCiAgICAgICIyLiBUaGUgb3JpZ2luYXRvciBpbmNsdWRlcyB0aGUgaGFzaCBv ZiB0aGUgbmV3IHB1YmxpYyBrZXksIHRoZQ0KICAgICAgIGVudGlyZSBjdXJyZW50IHB1YmxpYyBr ZXksIGFuZCB0aGUgaGFzaCBvZiB0aGUgbG9nIGZpbGUgaW4gdGhlDQogICAgICAgTklMIGZpbGUu IFRoZSBvcmlnaW5hdG9yIHRoZW4gdXNlcyB0aGUgY3VycmVudCBwcml2YXRlIGtleSB0bw0KICAg ICAgIHNpZ24gdGhlIE5JTCBmaWxlLiIgDQogICANCiAgICBNaWdodCB3YW50IHRvIGNsYXJpZnkg dGhlIHRleHQgdG8gbWVudGlvbiB0aGF0IG90aGVyIHRoaW5ncyBhcmUNCiAgICBhbHNvIGluY2x1 ZGVkIGluIHRoZSBOSUwgZmlsZSBhbmQgdGhlIGFsZ29yaXRobSBpcyBkZXNjcmliZWQgYmVsb3cN CiAgICBpbiBTZWN0aW9uIFgsIGFzLCBzdGVwIDQgb2YgdGhlIGxvZyBmaWxlIHByb2Nlc3Npbmcg Z29lcyBvbiB0byBzYXk6DQoNCiAgICAgICJUaGUgcmVjZWl2ZXIgdmVyaWZpZXMgdGhhdCB0aGUg cHVibGljIGtleSBpbiB0aGUgTklMIGZpbGUNCiAgICAgICBtYXRjaGVzIHRoZSBuZXh0LWtleSBo YXNoIGluIHRoZSBwcmV2aW91cyBOSUwgZmlsZSAob3IgdGhlDQogICAgICAgaW5pdGlhbCBoYXNo IGlmIHRoaXMgaXMgdGhlIGZpcnN0IGVudHJ5KSINCg0KICAgIHdoaWNoIHdhcyBhIGxpdHRsZSBj b25mdXNpbmcsIHNpbmNlIGl0IHdhcyBub3QgZXhwbGljaXQgaW4gc3RlcCAyDQogICAgdGhhdCB0 aGUgaGFzaCBvZiB0aGUgcHVibGljIGtleSBhbmQgdGhlIHNpZ25hdHVyZSBhcmUgYm90aCBhbHNv DQogICAgaW5jbHVkZWQgaW4gdGhlIE5JTCBmaWxlLg0KDQogICAgU2hvdWxkIHRoZSByZWNlaXZl ciB1c2UgdGhlIE5vbi1SZXB1ZGlhdGlvbi1QdWJsaWMtS2V5LUhhc2ggZnJvbQ0KICAgIHRoZSBj dXJyZW50IE5JTCBmaWxlIHRvIGRvIHRoZSBtYXRjaGluZyBpbiBzdGVwIDQsIG9yIG1hbnVhbGx5 DQogICAgcmVoYXNoIE5vbi1SZXB1ZGlhdGlvbi1QdWJsaWMtS2V5IGFuZCB2ZXJpZnkgdGhhdCBp dCBtYXRjaGVzIGJvdGgNCiAgICB0aGUgY3VycmVudCBOSUwgZmlsZSBOb24tUmVwdWRpYXRpb24t UHVibGljLUtleS1IYXNoIGFuZCB0aGUNCiAgICBwcmV2aW91cyBOSUwgZmlsZSBOb24tUmVwdWRp YXRpb24tTmV4dC1QdWJsaWMtS2V5LUhhc2g/DQoNCnRoYW54Lg0KDQotLSAgS2V2aW4gSi4gTWEN Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjZG5pLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpjZG5pLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBEYXZp ZCBNYW5kZWxiZXJnDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMzAsIDIwMTMgMTA6NTEgQU0NCj4g VG86IGNkbmlAaWV0Zi5vcmcNCj4gU3ViamVjdDogW0NETmldIGxvZ2dpbmcgbm9uLXJlcHVkaWF0 aW9uIHByb3Bvc2VkIHRleHQgdjINCj4gDQo+IEhlcmUncyB0aGUgbmV4dCB2ZXJzaW9uIG9mIG15 IHByb3Bvc2VkIHRleHQgZm9yIG5vbi1yZXB1ZGlhdGlvbiBvZg0KPiBsb2dnaW5nIGRhdGEuDQo+ IA0KPiAtLQ0KPiBEYXZpZCBFcmljIE1hbmRlbGJlcmcgLyBkc2VvbW4NCj4gaHR0cDovL2Rhdmlk Lm1hbmRlbGJlcmcub3JnLw0K From flefauch@cisco.com Wed Jul 31 07:48:27 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BE611E819A for ; Wed, 31 Jul 2013 07:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8x1OndO-whE for ; Wed, 31 Jul 2013 07:48:17 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C6D0711E8167 for ; Wed, 31 Jul 2013 07:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1435; q=dns/txt; s=iport; t=1375282096; x=1376491696; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=j/q7g3GtQgf4UWhZ3dDiYe+3DkwFW2hpvCN6We0xP8E=; b=IRwuuZBX81+MH/t82WdiC19Aom3u5e4uXod7wEZaUvU6ljIym9tQv7eq JHtar4nebLBeGU3hyB35poYEasyfl4zsXCMbWlLcYWA831kYuZrT9Cp69 omSRyrsbPGxYUApvZPro1kUYTGAtzaty/HDxCvXKyIPKA6YN2ECq6EK+U Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFAHsi+VGtJXHA/2dsb2JhbABRCoMGgQW+HYEYFnSCJgEEOjEFBBcBKhRCJwQbE4d1mCugTY5FgRGDUHMDqSyDFIIq X-IronPort-AV: E=Sophos;i="4.89,787,1367971200"; d="scan'208";a="241765460" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 31 Jul 2013 14:48:16 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6VEmGRN017269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Jul 2013 14:48:16 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.159]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 09:48:16 -0500 From: "Francois Le Faucheur (flefauch)" To: "cdni@ietf.org" Thread-Topic: Moving "non-repudiation" out of cdni-logging Thread-Index: AQHOjfz8dMovVujiKECFIuYMtllGJg== Date: Wed, 31 Jul 2013 14:48:15 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.98.205] Content-Type: text/plain; charset="us-ascii" Content-ID: <57D0D3A09F5A98428DF2CEA5BDA9AF72@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CDNi] Moving "non-repudiation" out of cdni-logging X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 14:48:27 -0000 Hi everyone, As part of the side discussions on cdni-logging, it became clear that: * the detailed objectives/requirements and draft solution specification ar= ound non-repudiation are not as mature as the rest of the cdni-logging mate= rial, and=20 * we need to better understand if/what other IETF work around non-repudiat= ion maybe leveraged and how to best organise the work across CDNI WG and ot= her IETF working groups/areas.=20 Based on that observation, as well as the fact that it corresponds to a req= uirement with (only) [MED] priority, we reached a tentative agreement to: * take non-repudiation out of the cdni-logging document so we can don't ge= t delayed in finalising cdni-logging * establish on the list the detailed objectives/requirements around CDNI L= ogging non-repudiation. This is to be lead by Iuniana. * have the WG Chairs investigate relevant other works and identify expert = contacts in IETF that can help us move forward If you have comments on this tentative agreement, please raise them. Francois=20 For memory: " o "Medium Priority" indicates requirements that are to be supported by the CDNI interfaces unless the WG realizes at a later stage that attempting to meet this requirement does not achieve the goal of a deployable solution in a short timeframe (18-24 months) as needed by the industry. This is tagged as "[MED]". "= From mcaulfie@cisco.com Wed Jul 31 23:30:49 2013 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9969221F9D31 for ; Wed, 31 Jul 2013 23:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sFUBzNqH48U for ; Wed, 31 Jul 2013 23:30:43 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id BFEF321F9D22 for ; Wed, 31 Jul 2013 23:30:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3790; q=dns/txt; s=iport; t=1375338644; x=1376548244; h=from:to:subject:date:message-id:mime-version; bh=SZ2BnAMJYzAP0eV1hMlUVXYtk4wPnf3tX0ULKVaV4yM=; b=mdIK9/91aUp10ASpi/1YoPfrS7a/FL5UFqT4f0wDjRozjf+RhtLIaTJG BjE4qjE4xddA0IXuCkRwvbfF0QCuEj8lH1Nw8vAtG8GJap4RGRYud+nIY NqtReSkkCtUKrRgQRuDB0C4Paye0i34sCm1aJv0MtWHbsHH2ze53YtKZs M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAAkA+lGtJV2c/2dsb2JhbABbgkJENVC+PoEfFnSCJgEELV4BDB5WJgEEG4gImH+gVI9Wg1BzA6ksgxSCKg X-IronPort-AV: E=Sophos;i="4.89,791,1367971200"; d="scan'208,217";a="242187208" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 01 Aug 2013 06:30:32 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r716UWc9006180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Aug 2013 06:30:32 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.140]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 1 Aug 2013 01:30:32 -0500 From: "Matt Caulfield (mcaulfie)" To: "cdni@ietf.org" Thread-Topic: Informal Metadata Meeting Thread-Index: Ac6OgJrwM6FGWEC5TWGieCAtw8AMZA== Date: Thu, 1 Aug 2013 06:30:31 +0000 Message-ID: <166EBB70C264A9479E459B01B1BA6C92104BA87F@xmb-aln-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.13] Content-Type: multipart/alternative; boundary="_000_166EBB70C264A9479E459B01B1BA6C92104BA87Fxmbalnx03ciscoc_" MIME-Version: 1.0 Subject: [CDNi] Informal Metadata Meeting X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 06:30:49 -0000 --_000_166EBB70C264A9479E459B01B1BA6C92104BA87Fxmbalnx03ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We will be holding an informal metadata-focused meeting today (Thursday) at= 15:30. Meet at the IETF Registration Desk. Thanks, sorry for the short notice, Matt --_000_166EBB70C264A9479E459B01B1BA6C92104BA87Fxmbalnx03ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We will be holding an informal metadata-f= ocused meeting today (Thursday) at 15:30.

 

Meet at the IETF Registration Desk.<= /o:p>

 

Thanks, sorry for the short notice,<= /o:p>

Matt

 

 

--_000_166EBB70C264A9479E459B01B1BA6C92104BA87Fxmbalnx03ciscoc_--