[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