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

From: Claudio Allocchio <[email-masked]>
Date: Fri, 9 Dec 2011 17:29:02 +0100 (CET)

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          [email-masked]
                         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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Dec 2011 10:41:57 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Claudio Allocchio
> Sent: Friday, December 09, 2011 8:29 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [apps-discuss] Apps Dir review for: draft-kucherawy-dkim-atps-11

Hi Claudio, thanks for your review.

> 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.
> 

Thanks for that suggestion.  Since as you say Section 9.3 already gives this a reasonable treatment, I've instead extended Section 7 to draw specific attention to what 9.3 says, and asked that participants in the experiment pay close attention to how the added DNS work might cause MTA latency.  Is that sufficient?

>   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".

I've changed it to simply "Roles and Scope".

> "The actors involved into the implementation of this (experimental)

Someone else already suggested changing it to "The context of this protocol involves the following roles", so I'll just leave that as-is.

>    "A Verifier implements this protocol if it..."

Done and done.

> conformant to that discussion, too.

I've used the "are imported from" numerous times before without any resistance or concern.  But anyway, I've changed it to "are defined in".

> 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.

I've changed the first sentence so that it starts with: "For each DKIM signature that verifies, ..."  Is that sufficient?

> also to section 4.2, bullet point 5, where the convertion of the domain

I'd prefer to add a forward reference from 4.2 to 9.1 rather than copying text.  That's done now in the working copy.

Thanks again,
-MSK

---

From: Claudio Allocchio <[email-masked]>
Date: Fri, 9 Dec 2011 23:08:25 +0100 (CET)

> Thanks for that suggestion.  Since as you say Section 9.3 already gives 
> this a reasonable treatment, I've instead extended Section 7 to draw 
> specific attention to what 9.3 says, and asked that participants in the 
> experiment pay close attention to how the added DNS work might cause MTA 
> latency.  Is that sufficient?

I have not read it yet, but I think so!

> I've changed it to simply "Roles and Scope".

ok.

> Someone else already suggested changing it to "The context of this 
> protocol involves the following roles", so I'll just leave that as-is.

ok.

>>    "A Verifier implements this protocol if it..."

ok.

> I've used the "are imported from" numerous times before without any 
resistance or concern.  But anyway, I've changed it to "are defined in".

ok.

> I've changed the first sentence so that it starts with: "For each DKIM 
signature that verifies, ..."  Is that sufficient?

yes.

> I'd prefer to add a forward reference from 4.2 to 9.1 rather than 
> copying text.  That's done now in the working copy.

that's ok. too.

all the best!

;-)

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 9 Dec 2011 14:40:41 -0800

> From: Claudio Allocchio [mailto:[email-masked]]
> Sent: Friday, December 09, 2011 2:08 PM
> To: Murray S. Kucherawy
> Cc: Claudio Allocchio; [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [apps-discuss] Apps Dir review for: draft-kucherawy-dkim-atps-11
> 
> > Thanks for that suggestion.  Since as you say Section 9.3 already
> > gives this a reasonable treatment, I've instead extended Section 7 to
> > draw specific attention to what 9.3 says, and asked that participants
> > in the experiment pay close attention to how the added DNS work might
> > cause MTA latency.  Is that sufficient?
> 

Trust me, it looks fantastic.  :-)

-MSK