ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] subdomain strawpoll

2008-05-22 03:09:14

So, by my count that was 16 for removal and 6 for keeping.

That looks to me like sufficient consensus to remove the feature
from the next rev of the I-D and putting in some text in the
security considerations. I assume the editors of the draft can
craft some text for that based on recent list discussion.

Stephen.

Stephen Farrell wrote:
Folks,

We don't seem to be converging on this on the list, though I
also think that the recent (and quite good) debate should
mean that a lot of folks can express informed opinions.

So Barry & I would like to do a strawpoll to see if there is
in fact rough consensus one way or the other.

Your question for this week is therefore:

Should we keep or remove text below?

(from 4.2.2 of draft-ietf-dkim-ssp-03, but please be sure you
check the context before expressing an opinion)

    3.  _Try Parent Domain._ The host MUST query DNS for a TXT record for
        the immediate parent domain, prefixed with "_asp._domainkey."  If
        the result of this query is anything other than a "NOERROR"
        response with a valid ASP record, the algorithm terminates with a
        result indicating that no ASP record was present.  If the ASP "t"
        tag exists in the response and any of the flags is "s"
        (indicating it does not apply to a subdomain), the algorithm also
        terminates without finding an ASP record.  Otherwise, use that
        record.

Please just answer "keep" or "remove" in this thread, and use a
different subject line for any discussion. I'll summarise results
back to the list in one week from today (after May 8th).

Since 5016 section 4.2 does (though admittedly somewhat vaguely)
call for inclusion of the feature, we think a close call should
come down in favour of keeping it in.

If the consensus is for removal, then we can separately discuss what,
if anything, should go into the security considerations section that
covers the issue. Actually, even keeping it in, we should probably
add some new sec. cons. text derived from the recent discussion, but
let's see if we've consensus first.

Thanks,
Stephen & Barry.




_______________________________________________
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

<Prev in Thread] Current Thread [Next in Thread>