Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT)
"Ben Campbell" <ben@nostrum.com> Thu, 19 May 2016 00:51 UTC
Return-Path: <ben@nostrum.com>
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 CE9B712D105; Wed, 18 May 2016 17:51:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 LPUHvMRZF0NN; Wed, 18 May 2016 17:51:38 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 8E1EE12B068; Wed, 18 May 2016 17:51:38 -0700 (PDT)
Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4J0pZ8o010041 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 18 May 2016 19:51:36 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18]
From: Ben Campbell <ben@nostrum.com>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Date: Wed, 18 May 2016 19:51:38 -0500
Message-ID: <55925599-3D57-4DFD-BB6E-8142EC6A2199@nostrum.com>
In-Reply-To: <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk>
References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5234)
Archived-At: <http://mailarchive.ietf.org/arch/msg/cdni/kEN_Cu2Tc840uXpvV-Fp_sgBUx4>
Cc: draft-ietf-cdni-logging@ietf.org, The IESG <iesg@ietf.org>, cdni@ietf.org, cdni-chairs@ietf.org
Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT)
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 May 2016 00:51:40 -0000
On 18 May 2016, at 18:38, Ben Niven-Jenkins wrote: > Hi Ben, > > I’ll let the authors respond to most of your comments but I wanted > to respond to one of them, see below. > >> On 18 May 2016, at 23:32, Ben Campbell <ben@nostrum.com> wrote: >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> - 7.3: "Making detailed CDNI logging >> information known to the uCDN does not represent a particular >> privacy >> concern because the uCDN is already exposed at request redirection >> time to most of the information that shows up as CDNI logging >> information (e.g., enduser IP@, URL, HTTP headers - at least when >> HTTP redirection is used between uCDN and dCDN)." >> >> I agree this is mostly true for HTTP redirection. But as you mention, >> the >> assertion seems to fall down for DNS redirection, where the uCDN may >> have >> considerably less information. I think some different guidance for >> that >> case may be needed. > > True, but…making detailed CDNI logging information known to the uCDN > does not expose any more information to the uCDN than if the uCDN had > chosen to perform the content delivery itself. > > Typically when entity A contracts out work to entity B, entity A is > entitled to see all records produced by entity B on entity A’s > behalf. That may be a reasonable argument (I will let the thread from Stephen's comment play out), but that's not the argument the draft makes. If there are arguments that apply to DNS redirection (such as the one you mention), I think they should be included. Thanks, Ben C.
- [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-… Ben Campbell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Stephen Farrell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Stephen Farrell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Campbell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Stephen Farrell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Niven-Jenkins
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Spencer Dawkins at IETF
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Francois Le Faucheur
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Francois Le Faucheur
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Francois Le Faucheur
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Ben Campbell
- Re: [CDNi] Ben Campbell's Discuss on draft-ietf-c… Francois Le Faucheur