From nobody Tue Feb 2 16:46:18 2016 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8482D1A03FF; Tue, 2 Feb 2016 16:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6Z9oDqYwr_n; Tue, 2 Feb 2016 16:46:16 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661BC1ACE89; Tue, 2 Feb 2016 16:46:13 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id g73so37957577ioe.3; Tue, 02 Feb 2016 16:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=04O4RSVLk+jALVUmw0ytz9AKuQYS5F/cNKVCifkU42U=; b=WIYQ7DchOAtT7YEs8uRdIVZO4norGQevVcamNRmZh7WZXZw4LsfTGXpn4C9hSGjhHn w0A084b/Srxr5GEzj8dMzte80yvdE9svjaxp2jYYXUIMmNQp9k1n3xy8/0g+j/9s2YNq P1KPymfIQpzfagHCr9OK1EdmKqS1JVh4NiKsGYttOZmLwZkFEpvGhPnSiTQi03HhtQ05 fqWKADlPAT3/eZ1y48M+fFdPKClqIssRzVMwxvM0L6QbF74evWXauzJp4Mhbnc8b4Vs0 gslknmQtaq67CAc2abWg1Gv3HM0wehKr2Z/CrU/GfF/lS2U8jjIunwVjArkS4Fp2H9K6 I3hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; bh=04O4RSVLk+jALVUmw0ytz9AKuQYS5F/cNKVCifkU42U=; b=QJJLPKe9ba6rU3m7VmG2pn1ZQkqlcVM2pKjGirRalhDxtSfR050KdwSELtNlPWasSU zZ+Z+v9LzkjHTUSffmxrZyBctPW6QK3yyblTwmS8gjxQLMxTnnlayuHpcFK9Rx8wgmSc CodNVL2wznhxGQ//XC29C62O+lSoEyqkLQwWTAO9/s4r2SUFioLyFmvbbzGclwGbvFDg G+lKA0JwmNZXWyx5AaUCV3FBpGzS65Z3DDqgvUK5eUtQ0OUTb3v8Kj/mtkIw6eOYcmCo 1+Cxy5W4AcnNDqcV2plQWGFsxooKRXCrHFJaKauGpgn6idfH5ciWzV+RCuEW56VV+QoP 77Vw== X-Gm-Message-State: AG10YOR72iGGHKUnbMS5r1obGeK+YEK/TeniUhdXIYVBIgldE41NMdjbDu71YKjePYf+mgHHbE0T00d7NuZBow== MIME-Version: 1.0 X-Received: by 10.107.5.209 with SMTP id 200mr581823iof.193.1454460372769; Tue, 02 Feb 2016 16:46:12 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.36.155.198 with HTTP; Tue, 2 Feb 2016 16:46:12 -0800 (PST) Date: Tue, 2 Feb 2016 19:46:12 -0500 X-Google-Sender-Auth: 9vAsFGZi-IYQZFwiG_dpnyctfuo Message-ID: From: Barry Leiba To: draft-ietf-cdni-redirection@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: [CDNi] AD review of draft-ietf-cdni-redirection-16 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 00:46:17 -0000 I've reviewed the publication request for draft-ietf-cdni-redirection-16, and I have two comments, both of which we'll have to resolve before the document goes to last call. (1) References: 2818 is the subject of a MUST (Section 5.1) 6707 has required terminology (Section 2) I think those all need to be normative. 2818 is already in the downref registry, and we can call out 6707 during last call. Discussion? (2) Section 4.2: The following additional rules apply to all keys in RI requests and responses (whether in the top level object or in sub-objects): o Keys MUST always be encoded in lowercase. Requests or responses containing keys that are not all lowercase MUST be considered syntactically invalid. o Unknown keys MUST be ignored but the request or response MUST NOT be considered invalid unless the syntax of the request or response is invalid (i.e., an RI request or response MUST NOT be considered invalid on the basis that it contains unknown keys). I understand what you're trying to do here, but I don't think it works sensibly. Consider that a client and server both understand the keys "apple" and "orange", and then the client is updated to support the new "banana" key (but the server isn't). That server is expected to process "apple" and to reject "Apple" or "APPLE" as syntatically invalid. But, according to the second bullet, the server is expected to ignore "banana" (because it's an unknown key), but to reject "Banana" as syntatically invalid. Is that really reasonable? What you might think you're saying is that the server should be checking that the key doesn't contain any of the characters in "ABCDEFGHIJKLMNOPQRSTUVWXYZ", but realise that's not sufficient: JSON keys can contain any Unicode characters, and there are many uppercase Unicode characters. Should it also be syntax-checking for "=D0=A4=D0=AF=D0= =A7=D0=94=D0=A9" and "=CE=9B=CE=A0=CE=A9=CE=A8=CE=94", and similarly for uppercase Hebrew charac= ters, and so on? What is the value is requiring the syntax check in first bullet? Is it not sufficient just to require that valid keys be in the specified case, and that keys that are invalid be ignored? Is there really extra value in rejecting a request or response that contains a key that has an uppercase character? -- Barry, ART AD From nobody Mon Feb 15 01:30:14 2016 Return-Path: X-Original-To: cdni@ietf.org Delivered-To: cdni@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 580FE1B2E9A; Mon, 15 Feb 2016 01:30:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160215093013.10746.53325.idtracker@ietfa.amsl.com> Date: Mon, 15 Feb 2016 01:30:13 -0800 Archived-At: Cc: cdni@ietf.org Subject: [CDNi] I-D Action: draft-ietf-cdni-redirection-17.txt X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 09:30:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection of the IETF. Title : Request Routing Redirection interface for CDN Interconnection Authors : Ben Niven-Jenkins Ray van Brandenburg Filename : draft-ietf-cdni-redirection-17.txt Pages : 32 Date : 2016-02-15 Abstract: The Request Routing Interface comprises of (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request. This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cdni-redirection/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-cdni-redirection-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-redirection-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 15 01:33:50 2016 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CA41B2DA7; Mon, 15 Feb 2016 01:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1VUOyR_Jx75; Mon, 15 Feb 2016 01:33:46 -0800 (PST) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id BF1511B2DE3; Mon, 15 Feb 2016 01:33:46 -0800 (PST) Received: from bcdff84b.skybroadband.com ([188.223.248.75] helo=[192.168.0.4]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1aVFXN-0007q4-Bx; Mon, 15 Feb 2016 09:33:45 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Ben Niven-Jenkins In-Reply-To: Date: Mon, 15 Feb 2016 09:33:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9C3C10BA-829D-4854-ABA5-2B3EFCF33555@niven-jenkins.co.uk> References: To: Barry Leiba X-Mailer: Apple Mail (2.2098) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: Cc: "" , draft-ietf-cdni-redirection@ietf.org Subject: Re: [CDNi] AD review of draft-ietf-cdni-redirection-16 X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 09:33:49 -0000 Hi Barry, I just published a new version (-17) that should address your comments. I moved RFC2818 & RFC6707 to normative references and replaced the rules = on JSON keys in section 4.2 with the following text: Senders MUST encode all (top level object and sub-object) keys specified in this document in lowercase. Receivers MUST ignore any keys that are unknown or invalid. Ben > On 3 Feb 2016, at 00:46, Barry Leiba wrote: >=20 > I've reviewed the publication request for > draft-ietf-cdni-redirection-16, and I have two comments, both of which > we'll have to resolve before the document goes to last call. >=20 > (1) References: > 2818 is the subject of a MUST (Section 5.1) > 6707 has required terminology (Section 2) >=20 > I think those all need to be normative. 2818 is already in the > downref registry, and we can call out 6707 during last call. > Discussion? >=20 > (2) Section 4.2: >=20 > The following additional rules apply to all keys in RI requests and > responses (whether in the top level object or in sub-objects): >=20 > o Keys MUST always be encoded in lowercase. Requests or responses > containing keys that are not all lowercase MUST be considered > syntactically invalid. >=20 > o Unknown keys MUST be ignored but the request or response MUST NOT > be considered invalid unless the syntax of the request or = response > is invalid (i.e., an RI request or response MUST NOT be = considered > invalid on the basis that it contains unknown keys). >=20 > I understand what you're trying to do here, but I don't think it works > sensibly. Consider that a client and server both understand the keys > "apple" and "orange", and then the client is updated to support the > new "banana" key (but the server isn't). >=20 > That server is expected to process "apple" and to reject "Apple" or > "APPLE" as syntatically invalid. But, according to the second bullet, > the server is expected to ignore "banana" (because it's an unknown > key), but to reject "Banana" as syntatically invalid. Is that really > reasonable? >=20 > What you might think you're saying is that the server should be > checking that the key doesn't contain any of the characters in > "ABCDEFGHIJKLMNOPQRSTUVWXYZ", but realise that's not sufficient: JSON > keys can contain any Unicode characters, and there are many uppercase > Unicode characters. Should it also be syntax-checking for = "=D0=A4=D0=AF=D0=A7=D0=94=D0=A9" and > "=CE=9B=CE=A0=CE=A9=CE=A8=CE=94", and similarly for uppercase Hebrew = characters, and so on? >=20 > What is the value is requiring the syntax check in first bullet? Is > it not sufficient just to require that valid keys be in the specified > case, and that keys that are invalid be ignored? Is there really > extra value in rejecting a request or response that contains a key > that has an uppercase character? >=20 > -- > Barry, ART AD >=20 > _______________________________________________ > CDNi mailing list > CDNi@ietf.org > https://www.ietf.org/mailman/listinfo/cdni From nobody Wed Feb 17 10:07:07 2016 Return-Path: X-Original-To: cdni@ietfa.amsl.com Delivered-To: cdni@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556BF1ACF07; Wed, 17 Feb 2016 10:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MhqyhYum5kIC; Wed, 17 Feb 2016 10:07:01 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8037F1ACED4; Wed, 17 Feb 2016 10:07:01 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id u9so10177680ykd.1; Wed, 17 Feb 2016 10:07:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vdYB5PRBrKlKsrYoCmy2UBEKgCwDVfncPxVHf6fvyms=; b=fuoOOplT4+87gpXfs22tpkv9w7PXwUhjUapSrwAtkAJPO4l+8jpOEG/30AhClLOwPN ob2qOWMxldc0626Vc8ycSie4bFuYJdVEONeGVMmZu6oq6PhtDQ1Vs6904h/0Q/KHFAMV HV7lnirCAXuC7pPAYc752LN/jmuZHRjF126+2XoiZDqVrK/MUQv70l2IiVSKYWouOlN+ WKDbZ/EjKgrrkV3AFdwHnUhVWhYBPIW8L2wZoduV4HNdq+3KsNPhk6MXc4UKMCWeT1mE /uhnwQt0LkvQgxXpeORlBEE6vatugd/RwbaZ8Fa91LJyxxKcrA3MeY79duGkn8Qkoq8b oi6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vdYB5PRBrKlKsrYoCmy2UBEKgCwDVfncPxVHf6fvyms=; b=BmOEgkI3CIoyYM0H5wrcuZwB/a10M5dEaxOVtvKscRjeH+dOMSePSRisik7nm/y+Cn AmXwcjAoXJUbtI/PFHNKcfywoelljUPCMwCTAYMzlJJMoVA4ODAr7KoDrNRskavHZVGo BiOIh9cmL2Pg+SZACisKG5uqQWDvQFcSwX8PDYhSOtFCV0IJ3Wg9l+g6O+awIcUROapQ nc6Xwv/uEyCniIHvDwzJSXLYi5++7q+Phu9NKefZ7yiaFJLUkA2l2ML9Nx8/xAGUq5tQ +yLRCEoZNxUzXOhWxne0nZpZAM/deHdbEnJnzNEJzWsbUz0dwwPIFFae7RDztYndJ8di 1wCQ== X-Gm-Message-State: AG10YOTaAucuNUzG3Ek8/+5/u6G8Pg0NJAE7sFCMGwFf5yMH/B1kZi7lcmVrsBBchLIHmTfz3pHkfH6mh1gwhw== MIME-Version: 1.0 X-Received: by 10.37.29.193 with SMTP id d184mr1719719ybd.111.1455732420718; Wed, 17 Feb 2016 10:07:00 -0800 (PST) Received: by 10.37.99.65 with HTTP; Wed, 17 Feb 2016 10:07:00 -0800 (PST) In-Reply-To: References: <20151109165118.779.25437.idtracker@ietfa.amsl.com> <50381CDF-6A40-4447-846F-217E31934D6A@cisco.com> <56520141.8010806@cs.tcd.ie> Date: Wed, 17 Feb 2016 12:07:00 -0600 Message-ID: From: Spencer Dawkins at IETF To: "Francois Le Faucheur (flefauch)" Content-Type: multipart/alternative; boundary=001a11427890d33d80052bfb1db9 Archived-At: Cc: "draft-ietf-cdni-logging@ietf.org" , "cdni-chairs@ietf.org" , "iesg@ietf.org" , "cdni@ietf.org" , Stephen Farrell Subject: Re: [CDNi] Stephen Farrell's Discuss on draft-ietf-cdni-logging-21: (with DISCUSS and COMMENT) X-BeenThere: cdni@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 18:07:06 -0000 --001a11427890d33d80052bfb1db9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable So, two things ... On Wed, Jan 27, 2016 at 1:48 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Hi, Francois, > > On Jan 27, 2016 10:53, "Francois Le Faucheur (flefauch)" < > flefauch@cisco.com> wrote: > > > > Hello Spencer, > > > > I should be able to work on this next week. > > Thanks for the reminder. > > That works for me. > Just as an update from my side ... This draft has No-Objection positions from ADs who will be leaving the IESG the first week in April, and those positions will expire when the ADs step down. That will require new ADs to cast ballots. It would be great if we didn't have to do that, so getting the document approved in the next month really is what you want to have happen. By the way - Roy's e-mail address has been bouncing. Does anyone have an updated address that could go into the next revision? Thanks, Spencer > Spencer > > > Francois > > > > > >> On 26 Jan 2016, at 04:00, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > >> > >> Hi, Francois, > >> > >> On Sun, Nov 22, 2015 at 11:54 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >>> > >>> > >>> Hiya, > >>> > >>> Sure placing the text wherever makes sense if of course > >>> fine, > >>> > >>> Cheers, > >>> S > >>> > >>> On 22/11/15 16:57, Francois Le Faucheur (flefauch) wrote: > >>> > Hello Stephen. > >>> > > >>> > Thanks for this update to your DISCUSS and COMMENTS. > >>> > It all makes sense. Specific responses/resolution discussed below: > >> > >> > >> If I'm following this correctly, you and Stephen have closed on > resolutions for his DISCUSS and COMMENTS. > >> > >> Could you let me know when I should expect a revised draft? > >> > >> I would love to finish this up. > >> > >> Thanks! > >> > >> Spencer > >> > >>> > >>> > (5) I'm not clear why you need to be able to send HTTP header > >>> > values or session IDs via this i/f. Why is that needed? And > >>> > it seems very dangerous, e.g. "cs(COOKIE)" could be a doosy. > >>> > I would suggest adding new text in section 3.4 to cover all > >>> > of the log content basically saying that you really need to > >>> > know what you're doing or you can break security very easily. > >>> > > >>> > That makes sense. > >>> > > >>> > Some suggested text that could be added to the end of 3.4 > >>> > just before the start of 3.4.1: > >>> > > >>> > Since the text below is specific to HTTP, I would lean for includin= g > it under 3.4.1 ("HTTP Request Logging Record=E2=80=9D) rather than under = 3.4 which > is meant to apply to any log (possibly of other protocols than HTTP). > >>> > > >>> > There is a discussion under 3.4.1 about which fields MUSt be > included and which one MAY. I think right after that would be an ideal > place to add the text below. > >>> > > >>> > Let me know if that does not work. > >>> > > >>> > > >>> > > >>> > "Logging fields > >>> > > >>> > s/Logging fields/Logging some fields/ > >>> > since some fields are not very dangerous. > >>> > > >>> > from HTTP requests and responses can be > >>> > very dangerous. For example, cookies will often contain > >>> > (months) long lived bearer token > >>> > > >>> > This is a bit beyond my expertise, but I wonder if =E2=80=9Cbearer= =E2=80=9D is > needed here: > >>> > s/bearer token/token/ ? > >>> > because I think the discussion here is meant to be generic while > "bearer token" is a specific form of token. > >>> > Or is =E2=80=9Cbearer token=E2=80=9D really the appropriate term in= this generic > sentence? > >>> > > >>> > values that can be used > >>> > to login to a service as the relevant user. Similar values > >>> > may be included in other header fields or within URLs or > >>> > elsewhere in HTTP requests and responses. Centralising > >>> > such values in a log > >>> > > >>> > s/log/CDNI Logging File/ > >>> > > >>> > can therefore represent a significant > >>> > increase in risk both for the user and the web service > >>> > provider, but also for the CDNs involved. Implementations > >>> > ought therefore attempt to lower the probability of such > >>> > bad outcomes e.g. by only allowing a configured set of > >>> > headers to be added to logs > >>> > > >>> > s/logs/CDNI Logging Records/ > >>> > > >>> > , or by not supporting wildcard > >>> > selection of HTTP request/response fields to add. Such > >>> > mechanisms can reduce the probability that security (or > >>> > privacy) sensitive values are centralised in logs.=E2=80=9D > >>> > > >>> > s/logs/CDNI Logging Files/ > >>> > > >>> > I suggest that , in addition to recommendations for implementations= , > we also add recommendations for CDN operators: > >>> > =E2=80=9CSimilarly, when agreeing on which HTTP request/response fi= elds are > to be provided in CDNI Logging Files, the uCDN and dCDN administrators > ought to consider these risks." > >>> > > >>> > > >>> > > >>> > I'm sure that can be improved on, and have no problem with > >>> > any specific better words. > >>> > > >>> > (6) cleared > >>> > > >>> > (7) cleared > >>> > > >>> > > >>> > > ---------------------------------------------------------------------- > >>> > COMMENT: > >>> > > ---------------------------------------------------------------------- > >>> > > >>> > > >>> > - in the description of c-groupid, "the address > >>> > with a shared secret that is pre-synchronised > >>> > and rotated at a predefined time interval" isn't > >>> > very clear. I know what you mean but I don't > >>> > think you state it very clearly. Could be that a > >>> > bit of text earlier in the document that describes > >>> > the basic idea would be better than doing it all > >>> > inline as you have in -21. > >>> > > >>> > Right. > >>> > We need to do some word tweaking on this anyways, so we=E2=80=99ll = try > address that. > >>> > > >>> > > >>> > OLD COMMENTS Below, not updated for -21, I didn't > >>> > check if you took 'em on board, feel free to chat about > >>> > 'em if that's useful - I'm happy to do so anyway. > >>> > > >>> > Those have been addressed in earlier versions. > >>> > > >>> > Here is the message I sent about those back in July in case you wan= t > to check the detailed resolution: > >>> > > >>> > > >>> > From: Francois Le Faucheur flefauch@cisco.com>> > >>> > Subject: Re: Stephen Farrell's Discuss on > draft-ietf-cdni-logging-15: (with DISCUSS and COMMENT) > >>> > Date: 19 July 2015 18:39:38 CEST > >>> > To: Stephen Farrell stephen.farrell@cs.tcd.ie>> > >>> > Cc: Le Faucheur Francois flefauch@cisco.com>>, The IESG >, > cdni-chairs@ietf.org, > draft-ietf-cdni-logging@ietf.org > >>> > > >>> > Hi Stephen, > >>> > > >>> > Responses to the COMMENT part below: > >>> > > >>> > > >>> > > >>> > > ---------------------------------------------------------------------- > >>> > COMMENT: > >>> > > ---------------------------------------------------------------------- > >>> > > >>> > > >>> > - I support Richard's discuss. Isn't it ironic that the dCDN's > >>> > privacy (that of a company) is better supported than that of > >>> > the end user (a person) > >>> > > >>> > With anonymization now being a SHOULD, I thought Richard=E2=80=99s = DISCUSS > was addressed (apart from the potential need to add port anonymization as > discussed separately for your own DISCUSS). > >>> > > >>> > > >>> > - 2.2.1 - why is per-chunk always needed? > >>> > > >>> > Aggregated logs for segmented content is a tricky concept, for whic= h > there is no standard today and many potential ways to do it, and which th= e > Working Group has elected to keep for a next version of the logging spec > (just so that we can come up with a base CDNI logging spec _relatively_ > quickly ). > >>> > So the only sure way to support interoperabilty across CDNs for log= s > of segmented content is to provide per-chunk log, hence the statement tha= t > those always need to be generated. > >>> > > >>> > > >>> > > >>> > - 2.2.5.3: what's "track audience" mean? > >>> > > >>> > This terminology is likely inherited from the TV/Video era, meaning > in particular tracking how big a population watches which movie/video. > >>> > Given the more general applicability here, how about we replace by > something like =E2=80=9Cdevelop statistics on content download=E2=80=9D? > >>> > > >>> > > >>> > - 2.2.5.4: there are more security goals in the universe > >>> > > >>> > Certainly, but this is not a Security Considerations section: > section 2.2.5 discussing Log Consuming applications. And 2.2.5.4 is > discussing one such application which is to detect violation of content > access policy. > >>> > > >>> > > >>> > - 2.2.5.4: seems like the user is the enemy, that's odd > >>> > > >>> > With respect to Content Protection (the subject of 2.2.5.4) > unauthorised user is indeed the enemy, aiming at stealing some content fr= om > the CDNs. > >>> > > >>> > > >>> > - 2.2.5.6.2: there is no "browser type header" that I know of, > >>> > but there is the well-known UA string. Being specific about > >>> > that is better. > >>> > > >>> > This is fixed in -19 which now says: > >>> > "Terminal type (mobile, PC, STB, if this information can be > >>> > acquired from the browser type inferred from the User Agent > >>> > string, for example). > >>> > " > >>> > > >>> > - 3.1: SS.S - does that imply a time granularity of 100ms? If > >>> > so, please say so. > >>> > > >>> > As a result of another IESG review comment, we have replaced our > own definition of time by a reference to RFC3339. > >>> > > >>> > =E2=80=9C > >>> > TIME =3D 2DIGIT ":" 2DIGIT ":" 2DIGIT ["." *DIGIT] > >>> > ; Times are encoded as "partial-time" specified in [RFC3339= ]. > >>> > " > >>> > > >>> > So that point should be fixed already. > >>> > > >>> > > >>> > > >>> > - 3.4.4: cs-uri: please not that these can be privacy > >>> > sensitive, though presumably less so than e.g. logged URIs on > >>> > a search engine. > >>> > > >>> > Is this just for our information or do you recommend that we add a > statement about the fact that cs-uri can be privacy sensitive? > >>> > If IP/ports are anonymised, is cs-uri still privacy sensitive (is > this in case the uri itself contains some information that can be traced > back to a given end-user? > >>> > > >>> > > >>> > > >>> > - 3.4.4: foo-uri: do these contain fragments or not? > >>> > > >>> > In a per-chunk log (which is specified in this document as the > interoperable mechanism to exchange logs for fragmented content), the uri > contains the URI of each specific fragment. > >>> > In an aggregated log for a segmented content delivery (which is not > specified in this document), there are many potential options (URI of fir= st > segment, URI of the playlist, part of the URI common to all segments,=E2= =80=A6.). > This is one of the complexities of specifying aggregated logs for segment= ed > content. > >>> > > >>> > > >>> > > >>> > > >>> > - I support Richard's discuss. Isn't it ironic that the dCDN's > >>> > privacy (that of a company) is better supported than that of > >>> > the end user (a person) > >>> > > >>> > - 2.2.1 - why is per-chunk always needed? > >>> > > >>> > - 2.2.5.3: what's "track audience" mean? > >>> > > >>> > - 2.2.5.4: there are more security goals in the universe > >>> > > >>> > - 2.2.5.4: seems like the user is the enemy, that's odd > >>> > > >>> > - 2.2.5.6.2: there is no "browser type header" that I know of, > >>> > but there is the well-known UA string. Being specific about > >>> > that is better. > >>> > > >>> > - 3.1: SS.S - does that imply a time granularity of 100ms? If > >>> > so, please say so. > >>> > > >>> > - 3.4.4: cs-uri: please not that these can be privacy > >>> > sensitive, though presumably less so than e.g. logged URIs on > >>> > a search engine. > >>> > > >>> > - 3.4.4: foo-uri: do these contain fragments or not? > >>> > > >>> > > >>> > > >>> > >> > > > --001a11427890d33d80052bfb1db9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, two things ...

On Wed, Jan 27, 2016 at 1:48 PM, Spencer Dawkins at IETF = <spencerdawkins.ietf@gmail.com> wrote:

Hi, Francois,

On Jan 27, 2016 10:53, "Francois Le Faucheur (flefauch)= " <flefauch= @cisco.com> wrote:
>
> Hello Spencer,
>
> I should be able to work on this next week.
> Thanks for the reminder.

That works for me.


Just as an update from my side ...

This draft ha= s No-Objection positions from ADs who will be leaving the IESG the first we= ek in April, and those positions will expire when the ADs step down. That w= ill require new ADs to cast ballots. It would be great if we didn't hav= e to do that, so getting the document approved in the next month really is = what you want to have happen.

By the way - Roy'= ;s e-mail address has been bouncing. Does anyone have an updated address th= at could go into the next revision?

Thanks,
<= div>
Spencer
=C2=A0

Spencer

> Francois
>
>
>> On 26 Jan 2016, at 04:00, Spencer Dawkins at IETF <spencerdawkins.ietf@= gmail.com> wrote:
>>
>> Hi, Francois,
>>
>> On Sun, Nov 22, 2015 at 11:54 AM, Stephen Farrell <stephen.farrell@cs.tcd.i= e> wrote:
>>>
>>>
>>> Hiya,
>>>
>>> Sure placing the text wherever makes sense if of course
>>> fine,
>>>
>>> Cheers,
>>> S
>>>
>>> On 22/11/15 16:57, Francois Le Faucheur (flefauch) wrote:
>>> > Hello Stephen.
>>> >
>>> > Thanks for this update to your DISCUSS and COMMENTS.
>>> > It all makes sense. Specific responses/resolution discuss= ed below:
>>
>>
>> If I'm following this correctly, you and Stephen have closed o= n resolutions for his DISCUSS and COMMENTS.=C2=A0
>>
>> Could you let me know when I should expect a revised draft?
>>
>> I would love to finish this up.
>>
>> Thanks!
>>
>> Spencer
>> =C2=A0
>>>
>>> > (5) I'm not clear why you need to be able to send HTT= P header
>>> > values or session IDs via this i/f. Why is that needed? A= nd
>>> > it seems very dangerous, e.g. "cs(COOKIE)" coul= d be a doosy.
>>> > I would suggest adding new text in section 3.4 to cover a= ll
>>> > of the log content basically saying that you really need = to
>>> > know what you're doing or you can break security very= easily.
>>> >
>>> > That makes sense.
>>> >
>>> > Some suggested text that could be added to the end of 3.4=
>>> > just before the start of 3.4.1:
>>> >
>>> > Since the text below is specific to HTTP, I would lean fo= r including it under 3.4.1 ("HTTP Request Logging Record=E2=80=9D) rat= her than under 3.4 which is meant to apply to any log (possibly of other pr= otocols than HTTP).
>>> >
>>> > There is a discussion under 3.4.1 about which fields MUSt= be included and which one MAY. I think right after that would be an ideal = place to add the text below.
>>> >
>>> > Let me know if that does not work.
>>> >
>>> >
>>> >
>>> > "Logging fields
>>> >
>>> > s/Logging fields/Logging some fields/
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0since some fields are not very = dangerous.
>>> >
>>> > from HTTP requests and responses can be
>>> > very dangerous. For example, cookies will often contain >>> > (months) long lived bearer token
>>> >
>>> > This is a bit beyond my expertise, but I wonder if =E2=80= =9Cbearer=E2=80=9D is needed here:
>>> > s/bearer token/token/=C2=A0 ?
>>> > because I think the discussion here is meant to be generi= c while "bearer token" is a specific form of token.
>>> > Or is =E2=80=9Cbearer token=E2=80=9D really the appropria= te term in this generic sentence?
>>> >
>>> > values that can be used
>>> > to login to a service as the relevant user. Similar value= s
>>> > may be included in other header fields or within URLs or<= br> >>> > elsewhere in HTTP requests and responses. Centralising >>> > such values in a log
>>> >
>>> > s/log/CDNI Logging File/
>>> >
>>> > can therefore represent a significant
>>> > increase in risk both for the user and the web service >>> > provider, but also for the CDNs involved. Implementations=
>>> > ought therefore attempt to lower the probability of such<= br> >>> > bad outcomes e.g. by only allowing a configured set of >>> > headers to be added to logs
>>> >
>>> > s/logs/CDNI Logging Records/
>>> >
>>> > , or by not supporting wildcard
>>> > selection of HTTP request/response fields to add. Such >>> > mechanisms can reduce the probability that security (or >>> > privacy) sensitive values are centralised in logs.=E2=80= =9D
>>> >
>>> > s/logs/CDNI Logging Files/
>>> >
>>> > I suggest that , in addition to recommendations for imple= mentations, we also add recommendations for CDN operators:
>>> > =E2=80=9CSimilarly, when agreeing on which HTTP request/r= esponse fields are to be provided in CDNI Logging Files, the uCDN and dCDN = administrators ought to consider these risks."
>>> >
>>> >
>>> >
>>> > I'm sure that can be improved on, and have no problem= with
>>> > any specific better words.
>>> >
>>> > (6) cleared
>>> >
>>> > (7) cleared
>>> >
>>> >
>>> > ---------------------------------------------------------= -------------
>>> > COMMENT:
>>> > ---------------------------------------------------------= -------------
>>> >
>>> >
>>> > - in the description of c-groupid, "the address
>>> > with a shared secret that is pre-synchronised
>>> > and rotated at a predefined time interval" isn't=
>>> > very clear. I know what you mean but I don't
>>> > think you state it very clearly. Could be that a
>>> > bit of text earlier in the document that describes
>>> > the basic idea would be better than doing it all
>>> > inline as you have in -21.
>>> >
>>> > Right.
>>> > We need to do some word tweaking on this anyways, so we= =E2=80=99ll try address that.
>>> >
>>> >
>>> > OLD COMMENTS Below, not updated for -21, I didn't
>>> > check if you took 'em on board, feel free to chat abo= ut
>>> > 'em if that's useful=C2=A0 - I'm happy to do = so anyway.
>>> >
>>> > Those have been addressed in earlier versions.
>>> >
>>> > Here is the message I sent about those back in July in ca= se you want to check the detailed resolution:
>>> >
>>> >
>>> > From: Francois Le Faucheur <flefauch@cisco.com<mailto:flefauch@cisco.com>><= br> >>> > Subject: Re: Stephen Farrell's Discuss on draft-ietf-= cdni-logging-15: (with DISCUSS and COMMENT)
>>> > Date: 19 July 2015 18:39:38 CEST
>>> > To: Stephen Farrell <stephen.farrell@cs.tcd.ie<mailto:stephen.farrell@c= s.tcd.ie>>
>>> > Cc: Le Faucheur Francois <flefauch@cisco.com<mailto:flefauch@cisco.com>>, T= he IESG <iesg@ietf.or= g<mailto:iesg@iet= f.org>>, cdni-chairs@ietf.org<mailto:cdni-chairs@ietf.org>, draft-ietf-cdni-logging@ietf.o= rg<mailto:draft-ietf-cdni-logging@ietf.org>
>>> >
>>> > Hi Stephen,
>>> >
>>> > Responses to the COMMENT part below:
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------= -------------
>>> > COMMENT:
>>> > ---------------------------------------------------------= -------------
>>> >
>>> >
>>> > - I support Richard's discuss. Isn't it ironic th= at the dCDN's
>>> > privacy (that of a company) is better supported than that= of
>>> > the end user (a person)
>>> >
>>> > With anonymization now being a SHOULD, I thought Richard= =E2=80=99s DISCUSS was addressed (apart from the potential need to add port= anonymization as discussed separately for your own DISCUSS).
>>> >
>>> >
>>> > - 2.2.1 - why is per-chunk always needed?
>>> >
>>> > Aggregated logs for segmented content is a tricky concept= , for which there is no standard today and many potential ways to do it, an= d which the Working Group has elected to keep for a next version of the log= ging spec (just so that we can come up with a base CDNI logging spec _relat= ively_ quickly ).
>>> > So the only sure way to support interoperabilty across CD= Ns for logs of segmented content is to provide per-chunk log, hence the sta= tement that those always need to be generated.
>>> >
>>> >
>>> >
>>> > - 2.2.5.3: what's "track audience" mean?
>>> >
>>> > This terminology is likely inherited from the TV/Video er= a, meaning in particular tracking how big a population watches which movie/= video.
>>> > Given the more general applicability here, how about we r= eplace by something like =E2=80=9Cdevelop statistics on content download=E2= =80=9D?
>>> >
>>> >
>>> > - 2.2.5.4: there are more security goals in the universe
>>> >
>>> > Certainly, but this is not a Security Considerations sect= ion: section 2.2.5 discussing Log Consuming applications. And 2.2.5.4 is di= scussing one such application which is to detect violation of content acces= s policy.
>>> >
>>> >
>>> > - 2.2.5.4: seems like the user is the enemy, that's odd
>>> >
>>> > With respect to Content Protection (the subject of 2.2.5.= 4) unauthorised user is indeed the enemy, aiming at stealing some content f= rom the CDNs.
>>> >
>>> >
>>> > - 2.2.5.6.2: there is no "browser type header" = that I know of,
>>> > but there is the well-known UA string. Being specific abo= ut
>>> > that is better.
>>> >
>>> > This is fixed in -19 which now says:
>>> > "Terminal type (mobile, PC, STB, if this information= can be
>>> >=C2=A0 =C2=A0 =C2=A0 acquired from the browser type inferr= ed from the User Agent
>>> >=C2=A0 =C2=A0 =C2=A0 string, for example).
>>> > "
>>> >
>>> > - 3.1: SS.S - does that imply a time granularity of 100ms= ?=C2=A0 If
>>> > so, please say so.
>>> >
>>> > As a result of another IESG review comment, we have repla= ced=C2=A0 our own definition of time by a reference to RFC3339.
>>> >
>>> > =E2=80=9C
>>> > TIME =3D 2DIGIT ":" 2DIGIT ":" 2DIGIT= ["." *DIGIT]
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0; Times are encoded as &= quot;partial-time" specified in [RFC3339].
>>> > "
>>> >
>>> > So that point should be fixed already.
>>> >
>>> >
>>> >
>>> > - 3.4.4: cs-uri: please not that these can be privacy
>>> > sensitive, though presumably less so than e.g.=C2=A0 logg= ed URIs on
>>> > a search engine.
>>> >
>>> > Is this just for our information or do you recommend that= we add a statement about the fact that cs-uri can be privacy sensitive? >>> > If IP/ports are anonymised, is cs-uri still privacy sensi= tive (is this in case the uri itself contains some information that can be = traced back to a given end-user?
>>> >
>>> >
>>> >
>>> > - 3.4.4: foo-uri: do these contain fragments or not?
>>> >
>>> > In a per-chunk log (which is specified in this document a= s the interoperable mechanism to exchange logs for fragmented content), the= uri contains the URI of each specific fragment.
>>> > In an aggregated log for a segmented content delivery (wh= ich is not specified in this document), there are many potential options (U= RI of first segment, URI of the playlist, part of the URI common to all seg= ments,=E2=80=A6.). This is one of the complexities of specifying aggregated= logs for segmented content.
>>> >
>>> >
>>> >
>>> >
>>> > - I support Richard's discuss. Isn't it ironic th= at the dCDN's
>>> > privacy (that of a company) is better supported than that= of
>>> > the end user (a person)
>>> >
>>> > - 2.2.1 - why is per-chunk always needed?
>>> >
>>> > - 2.2.5.3: what's "track audience" mean?
>>> >
>>> > - 2.2.5.4: there are more security goals in the universe
>>> >
>>> > - 2.2.5.4: seems like the user is the enemy, that's odd
>>> >
>>> > - 2.2.5.6.2: there is no "browser type header" = that I know of,
>>> > but there is the well-known UA string. Being specific abo= ut
>>> > that is better.
>>> >
>>> > - 3.1: SS.S - does that imply a time granularity of 100ms= ?=C2=A0 If
>>> > so, please say so.
>>> >
>>> > - 3.4.4: cs-uri: please not that these can be privacy
>>> > sensitive, though presumably less so than e.g.=C2=A0 logg= ed URIs on
>>> > a search engine.
>>> >
>>> > - 3.4.4: foo-uri: do these contain fragments or not?
>>> >
>>> >
>>> >
>>>
>>
>


--001a11427890d33d80052bfb1db9--