[ietf-dkim] Comments on draft-ietf-dkim-ssp-requirements-03
fenton at cisco.com
Fri Apr 6 13:02:13 PDT 2007
Michael Thomas wrote:
> No comment means I'll roll it in somehow...
> Jim Fenton wrote:
>> 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).
>> 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.
>> 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
>> 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).
More information about the ietf-dkim