[ietf-dkim] SSP draft suggestions

[Arvel Hathcock]

Just a few small suggestions:

1)  In several places the language "SHOULD be considered non-Suspicious" 
is used.  This seems an awkward way to say it.  Since the term 
"Suspicious" is defined in section 2.8 "SHOULD NOT be considered 
Suspicious" might be a better way?  Also "MUST be considered 
non-Suspicious" -> "MUST NOT be considered Suspicious"?

2)  Section 3 bullet point 3 - "and SHOULD have a Valid Signature from 
this domain" -> "and SHOULD have a valid Originator Signature"

3) "not to be legitimate" -> "to be illegitimate"

4) ", and any verifiable signature is present from some signer other 
than the Originator Address in the message" -> "and the message contains 
a Verifier Acceptable Third-Party Signature"

5) "SHOULD NOT be considered to be Suspicious" -> "SHOULD NOT be 
considered Suspicious"

6) Section 4.1 - perhaps this is a better way of stating the second 
sentence in the NON-NORMATIVE DISCUSSION paragraph:

 "Many DNS server and resolver implementations are incapable of quickly 
and easily supporting new resource record types.  For this reason, 
support of TXT records is required whether a new RR type is defined or 
not."

7)  Section 4.1 states that syntactically incorrect SSP records should 
be considered as NODATA.  This is different from the 4871 approach of 
simply ignoring unknown tag/value combinations.  This also precludes the 
ability to extend an existing SSP record with some future new tag 
(should that need ever arise).  Was this intended?  It seems to 
contradict what's stated later in 4.3 that unknown tags are to be ignored.

8)  "whcih" -> "which"

9)  "Originating Domain" is used as if it was one of the previously 
defined terms but it isn't.

10)  "and its all of its" -> "and all of its"

11)  Personally, I like the suggestion someone else made of changing 
"unknown" to "?" but this isn't particularly important really.

12)  Section 4.4 - "including any where the Alleged Signer is" -> did 
you mean "including anywhere the Alleged Signer or"

13) Algorithm 2 - "to the domain part of the Originator Address" - it 
seems like you'd want to define "Originator Domain" in the definitions 
section and use that in a few places.

14) Algorithm 2 - "with one or more answer which is a 
syntactically-valid SSP response" -> "with one or more syntactically 
valid SSP responses"

15) Algorithm 3 has me a little worried.  It would prevent the use of 
domains unless they explicitly exist in DNS.  So, if I wanted to send a 
message out from message at sms.altn.com I would have to make sure and 
create a DNS A record or something for sms.altn.com first right?  
(sorry, my knowledge of DNS is not so good)

16) Algorithm 4 - "of the domain part of the domain part" -> "of the 
domain part"  this is another case where defining Originator Domain in 
advance might be helpful.

17) Algorithm 4 - "is a top-level domain" how can that be determined in 
practice?  I don't think it can can it? If not, we're giving algorithmic 
instruction here that is impossible to implement.

18) Algorithm 5 - unless we can figure out how to stop queries at 
top-level domains, Algorithm 5 will send lots of queries to the root 
servers right (.co.uk for example)?

19) Algorithm 8 - "and one or more Valid Signatures are present" -> 
Valid Signatures doesn't say enough here.  In this case a valid 
Originator Signature or a valid Verifier Acceptable Third-Party 
Signature" is what you want.

Arvel