[apps-discuss] Apps Dir review for: draft-kucherawy-dkim-atps-11

Claudio Allocchio <Claudio.Allocchio@garr.it> Fri, 09 December 2011 16:29 UTC

Return-Path: <Claudio.Allocchio@garr.it>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7678A21F858D; Fri, 9 Dec 2011 08:29:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOXi99L9XuYm; Fri, 9 Dec 2011 08:29:07 -0800 (PST)
Received: from cyrus.dir.garr.it (cyrus.dir.garr.it [IPv6:2001:760:0:158::29]) by ietfa.amsl.com (Postfix) with ESMTP id A1C0221F8558; Fri, 9 Dec 2011 08:29:06 -0800 (PST)
Received: from mac-allocchio3.elettra.trieste.it (mac-allocchio3.elettra.trieste.it [140.105.2.18]) (authenticated bits=0) by cyrus.dir.garr.it (8.14.5/8.14.5) with ESMTP id pB9GT2k0016559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Dec 2011 17:29:03 +0100 (CET)
X-DomainKeys: Sendmail DomainKeys Filter v1.0.2 cyrus.dir.garr.it pB9GT2k0016559
DomainKey-Signature: a=rsa-sha1; s=mail; d=garr.it; c=simple; q=dns; b=WOgo9SXROTmm6PhuP3aIaaUF1jqouMHXgG9Bt7t0mjYMk64xGvRrAVk3awHQURGvB 5snrOGXCme0zxqBK3I/koJ6db2uWHsipTY9SV1MmVvTBMfdzrR4/qQPzd4hEwfrNXag /Oa1XB20K1WCMvZy8PEcLlnnTjGAnvz7a6mRf4s=
Date: Fri, 9 Dec 2011 17:29:02 +0100 (CET)
From: Claudio Allocchio <Claudio.Allocchio@garr.it>
X-X-Sender: claudio@mac-allocchio3.elettra.trieste.it
To: apps-discuss@ietf.org, draft-kucherawy-dkim-atps.all@tools.ietf.org
Message-ID: <alpine.OSX.2.02.1112021220220.15127@mac-allocchio3.elettra.trieste.it>
User-Agent: Alpine 2.02 (OSX 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: iesg@ietf.org
Subject: [apps-discuss] Apps Dir review for: draft-kucherawy-dkim-atps-11
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Dec 2011 16:29:09 -0000

Hello all,

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you 
may receive. Please wait for direction from your document shepherd or AD 
before posting a new version of the draft.

Document: draft-kucherawy-dkim-atps-11
Title: DKIM Authorized Third-Party Signers
Reviewer: Claudio Allocchio
Review Date: 2011-12-09
IETF Last Call Date: ends 2011-12-28
IESG Telechat Date: 2012-01-05

Summary:

This draft is almost ready for publication as Experimental RFC, but needs 
a further small elaboration on the only major issue I list below before it 
can be released.

-------

Major Issues:

The only major issue which I really see in the specification is the impact 
not only on DNS because of the increased number of queries, but on the 
efficiency of the e-mail glogal system in general.

It is true that in 9.3 this topic is correctly described, and a possible 
alternate query mechanism depicted. However the real issue which I see is 
not a load on DNS, but a greatly increased "timout risk" on MTAs. One of 
the "experiment" scope should also be to verify the impact that adding 
this new feature has on the whole messaging system in terms of MTAs 
efficiency and effects of timeouts. We already know well that, one of the 
first very evident effects which happens when DNS "is slow" is a serious 
disruption on MTAs performances. Even if DNS is performing correctly, 
adding more queries might trigger more easily these performance 
disruptions in MTAs.

I this suggest an explicit "guidance" on how to handle the experiment, and 
monitor also this issue, and evaluate its impact. Probably section 9.3 and 
the introduction are the appropriate spots to do this.

This is even more important if the adoption of this specification grows 
significantly because it proves useful.

-------

  Minor Issues:


Section 3. Discussion

The title of the paragraph seems not so clear for the reader. It could be 
better to name it either "Scope of this specification" or "Roles and Scope 
of this specification".

Also some sentences probably need a better phrasing:

"Participation in this protocol is divided into three parties:"

I would suggest:

"The actors involved into the implementation of this (experimental) 
protocol are:"

and below

"An Author participates in this protocol if it..." -->
   "An Author implements this protocol if it..."

"A Verifier participates in this protocol if..." -->
   "A Verifier implements this protocol if it..."

-------

Section 4.1 Extension to DKIM

the sentence:

    "domain-name" and "key-h-tag-alg" are imported from [DKIM].

I guess it means:

    for the definition of "domain-name" and "key-h-tag-alg" see [DKIM]
    (section x.y).

There was long discussion on other WGs about correct handling of ABNF 
cross refereces between RFCs, thus the above change is more clear and 
conformant to that discussion, too.

-------

Section 5. Interpretation

I would add an explicit sentence stating what to do in case the Verifier 
fails in the verification. Just a reference to DKIM procedure for this 
cases, in order not invent further potentially different actions.

-------

Section 9.1 and Section 4.2

I suggest to add explicitly the explanation from section 9.1:

"the hash and encode steps are done merely to convert any third-party 
domain name to a fixed width in the construction of the DNS query."

also to section 4.2, bullet point 5, where the convertion of the domain 
name is specified.

-------


Nits:

None.

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          Claudio.Allocchio@garr.it
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca