[ietf-dkim] Comments on draft-ietf-dkim-ssp-requirements-03

[Jim Fenton]

Replies inline...

Michael Thomas wrote:
> No comment means I'll roll it in somehow...
>
> Jim Fenton wrote:
>> 3.1
>>
>> Paragraph 2, "what their expectations are for unsigned mail." sounds 
>> like a question about that this domain does with their incoming mail, 
>> not what their practices are with respect to signing.
>
> How about "what their expectations are for unsigned mail purportedly
> originating from their domain". It's not strictly a practice per se,
> it's what their expectations are wrt the ultimate survivability which
> is not something that they control (= practice).

Good; that makes it clear you're talking about outgoing mail.
>>
>> Step 4, "looks somewhat more suspicious" sounds like a UI issue, and 
>> conflicts with the definition of Suspicious that we're likely to be 
>> using in the SSP draft itself
>
> First it doesn't have to have anything to do with a UI, and second
> I'd say that you have it cart before horse here about suspicious:
> if there's a problem, you need to tell me what it is, not that it
> conflicts with the ssp draft.

It was the word "looks" that bothered me.  How about, "...such that it 
treats the message with additional caution."  That avoids the s-word 
entirely (although in fact it probably doesn't matter).
> .
>>
>> 3.2
>>
>> Paragraph 1 first sentence is worded as though a particular class of 
>> mail is the target; the domain is actually the target.
>
> I'd say that's debatable. It is transactional mail that is the prime
> problem, not the day-to-day conversational mail. Whether those two
> coincide is largely a question of how you lay out your namespace.

Fair enough; you're focusing on the class, which is legitimate, and I 
was focusing on the messages themselves.

>> Paragraph 3 Informative Note:  Isn't this whole document informative? 
>> (Applies to other informative notes too)
>
> No, the document still lays out normative behavior for the protocol.
> PS, etc are for actual protocols. Also: plenty of informational rfc's
> have normative language.

But this is a requirements document, not a protocol specification itself.
>
>>
>> 4.2
>>
>>
>> The 4844.From address isn't a "trust basis" but rather a key (in the 
>> database sense, not the crypto sense) to the policy.
>
> I'm not groking this.

"Trust" is such an overused word that I would prefer the wording, 
"...will be used as the reference point from which to fetch the 
published information."

>>
>> 4.5
>>
>> I'm not sure "transport scenarios" fits that well with the content of 
>> this section.
>
> Suggest away...

How about "Caching Considerations"?
>
>>
>> 4.6 through 4.9
>>
>> Are these really deployment scenarios?  They don't read that way to me.
>
> If you can think of another bucket to put them under... I mainly didn't
> want to get too elaborate on the taxonomy.

I would just have them in the Requirements section; I don't think 
everything that is a requirement needs to be traceable to a scenario.  
Security, for example, isn't a scenario because you always need it; it 
isn't independent  of the other scenarios.
>
>> Item 6 should also mention the ability of the domain holder to 
>> delegate individual keys by registering them.  Isn't there something 
>> else we can reference that describes the way to do this delegation?
>
> Registering them?

Sorry, bad choice of words on my part.  I mean that the domain holder 
can publish a key record corresponding to a key under control of someone 
else (an email service provider, for example).