Re: [secdir] review of draft-ietf-cdni-logging.15

"Francois Le Faucheur (flefauch)" <> Thu, 05 March 2015 08:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6A5F51B2A89; Thu, 5 Mar 2015 00:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id finkS4vQnMcp; Thu, 5 Mar 2015 00:36:11 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2AAE81B2A30; Thu, 5 Mar 2015 00:36:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2546; q=dns/txt; s=iport; t=1425544571; x=1426754171; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=u0B5ETFcq/TdzztdbAPNpLAKTeCo5d+d0wXoLKgmGNo=; b=jF48Vmg8VjiMF/1wVdx1HISKeJIJ7DnsYcTMvcBNczsLKrpmEjtcHspr CR/oMCIh73Ft4jxPl5zTH8sUMkn8Lidn6Yk12eYMJatC5qz+btpq6x5MF TJu6uvur5WHTbbQdmCSvUkE4q5bJdUtyrbgmN/8UwYush0VmBl+7hrBqv E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.11,345,1422921600"; d="scan'208";a="397953307"
Received: from ([]) by with ESMTP; 05 Mar 2015 08:36:10 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t258a9bp001508 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Mar 2015 08:36:10 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 5 Mar 2015 02:36:09 -0600
From: "Francois Le Faucheur (flefauch)" <>
To: "Klaas Wierenga (kwiereng)" <>
Thread-Topic: review of draft-ietf-cdni-logging.15
Thread-Index: AQHQVmVv5C9SG+zPj0yqYbUG8Io8tp0MiTEAgAFtdQA=
Date: Thu, 05 Mar 2015 08:36:08 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "Francois Le Faucheur (flefauch)" <>, "" <>, "" <>
Subject: Re: [secdir] review of draft-ietf-cdni-logging.15
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2015 08:36:14 -0000

Hi Klaas,

> On 4 Mar 2015, at 11:48, Klaas Wierenga (kwiereng) <> wrote:
>>> * Paragraph 3.2  CDNI Logging File Structure
>>> You state that you chose a format as close as possible to the W3C ELF Format. I’d like to see a short explanation why you can not use that format, and whether it would be an option to extend that format rather than defining a new format that is slightly different but is essentially a form and could over time be significantly different.
>> The W3C ELF specification, while commonly used, is somewhat underspecified and only a draft document. The document says:
>> “
>> This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress”.
>> “
>> So it does not seem appropriate to simply reuse that spec, or even to use it as a stable base to extend from.
>> Besides, we’ve really started from ELF and diverged where necessary or useful.
>> Several of the directives we needed do not have any equivalent in ELF. Quite a few fields we needed do not have an equivalent in ELF, and/or do not have a totally unambigous description.
>> Also we needed to be able to carry logs for non-HTTP protocols.
> ok, that is a convincing argument. How about including a statement to that extent, something along the lines of: “we took ELF as a starting point and reused where possible and expanded when necessary”

Sounds good. I’ve added:
The W3C Extended Log File Format was used as a starting point, reused where possible and expanded when necessary.

I think we have converged on everything else.