[ietf-dkim] subdomain strawpoll

Stephen Farrell stephen.farrell at cs.tcd.ie
Thu May 22 02:07:16 PDT 2008


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
> 


More information about the ietf-dkim mailing list