Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report

"Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl> Tue, 05 October 2010 14:42 UTC

Return-Path: <ietf-dkim-bounces@mipassoc.org>
X-Original-To: ietfarch-ietf-dkim-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-dkim-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 042AC3A6CAA for <ietfarch-ietf-dkim-archive@core3.amsl.com>; Tue, 5 Oct 2010 07:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.666
X-Spam-Level:
X-Spam-Status: No, score=-5.666 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmwzL-EC3xHM for <ietfarch-ietf-dkim-archive@core3.amsl.com>; Tue, 5 Oct 2010 07:42:44 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id F18403A6F99 for <ietf-dkim-archive@ietf.org>; Tue, 5 Oct 2010 07:42:43 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [127.0.0.1]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o95EZwtM015563; Tue, 5 Oct 2010 07:36:04 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=mipassoc.org; s=k00001; t=1286289365; bh=dgCiY32tMDGBauuwkR2B7Dy/qLM=; h=Message-id:Date: From:MIME-version:To:References:In-reply-to:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=TKOxVnNCTWJdN8QhG HHIPa8ec1vzfmztFCJqZTZsjYRUfMIPk9lbOSUzKPIY7vHjDswhpn9Mwp47bt+/JEAM hoXMWMVgt/V9Xy4o3s4cDxpTVp+oLoyLlnqlwvuuZ8WwsRSh0Fh7gALUB7Z4T2EFc1E U6h3Q4QMpr9PkcI7nOCk=
Received: from lion.sonnection.nl (lion.sonnection.nl [80.127.135.138]) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o95EZpdb015549 for <ietf-dkim@mipassoc.org>; Tue, 5 Oct 2010 07:35:57 -0700
Authentication-Results: sbh17.songbird.com; dkim=pass (1024-bit key) header.i=@sonnection.nl
Received: from [80.127.135.136] (a80-127-135-136.adsl.xs4all.nl [80.127.135.136]) by lion.sonnection.nl (Sun Java(tm) System Messaging Server 7.3-11.01 32bit (built Sep 1 2009)) with ESMTPA id <0L9T0020VN7QUY00@lion.sonnection.nl> for ietf-dkim@mipassoc.org; Tue, 05 Oct 2010 16:35:51 +0200 (CEST)
Message-id: <4CAB37C6.40500@sonnection.nl>
Date: Tue, 05 Oct 2010 16:35:50 +0200
From: "Rolf E. Sonneveld" <R.E.Sonneveld@sonnection.nl>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-version: 1.0
To: "Murray S. Kucherawy" <msk@cloudmark.com>
References: <AANLkTi=ukF2B-UJsooQKSxOfz54-Dsye0RPG_swLpWxn@mail.gmail.com> <4CAB279B.60307@sonnection.nl> <F5833273385BB34F99288B3648C4F06F1340BA36BD@EXCH-C2.corp.cloudmark.com>
In-reply-to: <F5833273385BB34F99288B3648C4F06F1340BA36BD@EXCH-C2.corp.cloudmark.com>
X-DKIM: OpenDKIM Filter v2.1.3 lion.sonnection.nl 0L9T0020VN7QUY00
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [127.0.0.1]); Tue, 05 Oct 2010 07:36:05 -0700 (PDT)
X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.70]); Tue, 05 Oct 2010 07:35:57 -0700 (PDT)
Cc: DKIM Mailing List <ietf-dkim@mipassoc.org>
Subject: Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org

  On 10/05/2010 04:07 PM, Murray S. Kucherawy wrote:
> Hi Rolf,
>
>> -----Original Message-----
>> From: Rolf E. Sonneveld [mailto:R.E.Sonneveld@sonnection.nl]
>> Sent: Tuesday, October 05, 2010 6:27 AM
>> To: Barry Leiba
>> Cc: DKIM Mailing List; Murray S. Kucherawy
>> Subject: Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
>>
>> Chapter 2: as for DKIM specific definitions used in this document, they
>> cannot be found in [EMAIL-ARCH]. Please add [DKIM] here as source of
>> definitions.
> The top of chapter 2 contains "[DKIM]" which is the formal reference to that specification.

Are we looking at the same report? I used 
http://tools.ietf.org/html/draft-ietf-dkim-implementation-report which 
brings me to version 02 of the document. I see [DKIM] mentioned here and 
there, throughout the document, but not in chapter 2? Or do you mean the 
page header, which mentions RFC4871 and of course presents the same 
referral as [DKIM] gives?

> "[EMAIL-ARCH]" is a general tutorial/overview about email architecture, included to help any newcomers to understand the context of the whole work.

I know [EMAIL-ARCH], it's definitely a good choice to refer in your 
document to this architecture RFC.

>> Par. 3.2 - 3.4: these paragraphs are a bit 'vague', due to terms like
>> 'Some implementations [...]', 'Some test cases [...]', 'at least two
>> implementations...'. Presumably this has to do with the fact that the
>> interoperability event took place long time ago?
> The language of that section is just a general description of the participants (the software, specifically) in the interop event and what they brought to the party.  The thrust is actually to show that they were all diverse, i.e. that a number of different parties wrote code per the RFC and then tried to send mail to each other to see what happens.  It would be uninteresting to have 20 parties come together all running different installations of the same package.  Showing diversity in an interoperability report is quite important.
>
> Changing "Some test cases" to "Test cases" seems fine to me.
>
> "At least two implementations" is a specific IETF requirement for an interop report.  I actually am pretty sure all implementations there implemented even all of the optional stuff, except "z=", but I don't have any specific record saying that so I'm making only the weaker of the two statements.

OK.
>> If so, I'd suggest to
>> include a sentence to describe the difficulty to gather all relevant
>> information, three years after the event took place. To make these
>> paragraphs a bit less 'vague' I would like to suggest to include the
>> original set(s) of test messages and the original interoperability test
>> plan(s), if still around somewhere.
> There wasn't a formal plan.  It was basically "send all your tests at all the participants, then work with each of them to figure out what failed and why".  Each participant brought its own corpus of test messages.
>
> Unfortunately very little of the actual test data and results documentation still exist, mainly because of a promise among the participants to keep the results about specific implementations private.

OK, then maybe that's something that needs to be mentioned, to explain 
why that part of the report is less exact than for example the data 
points about OpenDKIM and AOL.

>    The public result, appropriately, was the group's evaluation of the quality of the RFC and the published list of errata.

Apart from these minor remarks, in my view, it's ready to go.

/rolf
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html