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.