[CDNi] Logging: draft-finkelman-cdni-sva-extensions-00.txt

Ben Niven-Jenkins <ben@niven-jenkins.co.uk> Tue, 28 November 2017 14:27 UTC

Return-Path: <ben@niven-jenkins.co.uk>
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 9F33E127A90 for <cdni@ietfa.amsl.com>; Tue, 28 Nov 2017 06:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.918
X-Spam-Level:
X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] 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 CzD9q6-K-LlP for <cdni@ietfa.amsl.com>; Tue, 28 Nov 2017 06:27:37 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E26127011 for <cdni@ietf.org>; Tue, 28 Nov 2017 06:27:37 -0800 (PST)
Received: from cpc93788-hari17-2-0-cust3332.20-2.cable.virginm.net ([82.39.109.5] helo=[192.168.0.13]) by smtp04.mailcore.me with esmtpa (Exim 4.89) (envelope-from <ben@niven-jenkins.co.uk>) id 1eJgqp-0004k2-FK; Tue, 28 Nov 2017 14:27:35 +0000
From: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B040B9A4-E57F-4773-AE8F-2B62775636A3"
Message-Id: <D67B4693-21BF-4B65-A8E7-9F607FA71527@niven-jenkins.co.uk>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Date: Tue, 28 Nov 2017 14:27:05 +0000
References: <150937917932.7823.7624674920223255542.idtracker@ietfa.amsl.com> <CAMb9nTv8RPoi9-z9kPTrrMmT3L-0-iUD6bVj=n_EdsG8q5t+ow@mail.gmail.com> <CAMrHYE2i48Gf7+3LZ_D651nTZwAQc=rLHGnoP6_oS8avjJjqEg@mail.gmail.com> <CAMrHYE1zMjUbmV-h4QOxfckW9vaU0k2QjKCUdA5dPSrpnKNmKw@mail.gmail.com> <7d56eab1a06c49e88f751b25bc01405d@OMZP1LUMXCA08.uswin.ad.vzwcorp.com>
To: sanjay.mishra@verizon.com, Ori Finkelman <orif@qwilt.com>, "cdni@ietf.org" <cdni@ietf.org>
In-Reply-To: <7d56eab1a06c49e88f751b25bc01405d@OMZP1LUMXCA08.uswin.ad.vzwcorp.com>
X-Mailer: Apple Mail (2.2098)
X-Mailcore-Auth: 9600544
X-Mailcore-Domain: 172912
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, license restriction
X-KLMS-AntiPhishing: not scanned, license restriction
X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2017/11/28 07:07:00 #11127478
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/Gm0G6Sxam-cZfC4ZJkI636WqLPg>
Subject: [CDNi] Logging: draft-finkelman-cdni-sva-extensions-00.txt
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 28 Nov 2017 14:27:39 -0000

Sanjay, Ori, Colleagues,

> On 17 Nov 2017, at 02:57, sanjay.mishra@verizon.com wrote:
> 
> Kevin Ma wrote:
> >For Logging, it would be unfortunate if the logging interface we specified had to be >completely bypassed.  If there is a need, then we should address it, but I would be interested in >hearing from vendors on this.
> Primary motivators for specifying logging requirements in draft-finkelman-cdni-sva-extensions is largely because of CDNs already have and use Squid based logging and would rather not add a separate process to receive and process logging information sent by the dCDN (ISP’s open caching nodes).

I do not find this argument particularly persuasive. Our purpose at IETF is to specify interoperability and introducing a new format works against that goal IMO. Not all CDNs produce squid-format logs, so squid-format is not a magic bullet, people are always going to have to support some kind of transformation if they want CDNs that use different logging formats to interoperate.

The working group standardised on the format specified in RFC7937. Introduction of a second format just to satisfy a subset of CDNs that use a different format doesn’t solve the problem it just moves it around and places the burden of transformation on another party, it doesn’t solve it.

The example cited in the draft of logging the hit/miss status of the request is already supported by RFC7937 through the s-cached field. It only logs hit vs miss although could be extended to support additional granularity rather than introducing a new log format along which would bring with it the interoperability concerns having another format raises.

Regards
Ben