Hi Pasi,
The authors have pushed out a new version of ADSP. [1]
I've just had a look at the diffs [2] between that and
the previous one, and they seem to have covered your
AD comments fairly well, so hopefully you'll be ok with
starting IETF LC after you've had a chance to check
their changes.
Regards,
Stephen.
[1] http://tools.ietf.org/html/draft-ietf-dkim-ssp
[2]
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-dkim-ssp-06.txt&url2=http://tools.ietf.org/id/draft-ietf-dkim-ssp-07.txt
Pasi(_dot_)Eronen(_at_)nokia(_dot_)com wrote:
Hi,
I've done my AD review for draft-ietf-dkim-ssp-06, and I was happy
to see that the document is in good shape.
I do have couple of suggestions, though. Basically all of these are of
"the WG members probably understand what this text means, but if you
could add couple of more words, future readers would be thankful"
type; that is, suggestions for improving the clarity especially to
folks who didn't read the WG discussions about the topic.
Stephen, could you as the document shepherd take the lead in
discussing these and getting agreement on appropriate edits?
(in some cases, I've suggested a possible wording, but that's
just one starting point)
Best regards,
Pasi
------
- Section 3.1: to some folks, "domain" means just a single DNS name
"example.com"; to others, it might mean everything under
"example.com". I think it'd be useful to give a concrete example
here, saying e.g. that an ADSP record for "example.com" (stored in
_adsp._domainkey.example.com) does *not* apply to emails from
e.g. somebody(_at_)www(_dot_)example(_dot_)com ; to cover that, you'd need
_adsp._domainkey.www.example.com etc. (IMHO this is quite important
detail that isn't currently isn't very obvious from the document.)
- Section 3.3, 1st bullet would be clearer if it said
"...no ADSP record is found"
- Section 3.3, 3rd bullet: this would be easier to understand if you
copied the text from 4.2.1 definition of "discardable" here, too.
- Section 3.3, 4th bullet: this would be easier to understand it
said "because it does not exist in DNS", "this is the case if
the domain does not exist in DNS", or something
- Section 3.3, should mention the 5th possibility of the procedure in
4.3: algorithm terminates without producing a result, indicating a
temporary failure.
- Section 4.1 says the "Tag=Value List" syntax from RFC 4871 is used,
but it seems there's a difference: 4871 uses "[FWS]" around the "="
sign, while this document uses *WSP. This is probably an intentional
difference (right?), but should be explicitly pointed out.
- Section 4.2.1: Since the signing practice list is extensible, the
text should say how an unknown value should be treated -- probably
same as "unknown"?
- Section 4.3, "Check Domain Scope" step: it'd be useful to explicitly
say something "NODATA" (rcode=0 with ANCOUNT=0), as if I recall right,
even some WG members were confused at some point...
- Section 4.3, "Fetch Named ADSP Record" step: it'd be useful to say
here that if the result is NXDOMAIN, or NOERROR with zero records, or
NOERROR with records that aren't valid ADSP records, the result is
"unknown" (is that right, BTW?)
- Section 4.3, "does not exist for mail" would benefit from
rephrasing somehow (perhaps "is not a valid email domain for
[2821]", or something?)
- Section 4.3: would this be easier to read if you included a concrete
example (e.g. email message with a From line, and all the DNS lookups
done)? Or perhaps couple of examples?
- Section 6.1, last paragraph: to me it seems the amount of DNS
traffic would be less than amount of SMTP traffic, so this wouldn't
be a very good traffic multiplication attack? (with multiplier < 1)
If that's the case, perhaps would be useful to mention?
Nits:
- Title: Expand acronym DKIM
- References: update RFC 2821 to 5321, and 2822 to 5322
- Section 4.1, "the_adsp._domainkey" -> "the _adsp._domainkey"
------
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html