ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] subdomain strawpoll

2008-05-01 10:10:51
Delete


-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org on behalf of MH Michael Hammer 
(5304)
Sent: Thu 5/1/2008 11:59 AM
To: Stephen Farrell; ietf-dkim
Subject: Re: [ietf-dkim] subdomain strawpoll
 
Delete

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Stephen Farrell
Sent: Thursday, May 01, 2008 4:11 AM
To: ietf-dkim
Subject: [ietf-dkim] subdomain strawpoll


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


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html