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

[Claudio Allocchio <[e-mail]>]

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          [e-mail]
                         Senior Technical Officer
tel: [phone]      Italian Academic and       G=Claudio; S=Allocchio;
fax: [phone]        Research Network         P=garr; A=garr; C=it;

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