[ietf-dkim] Collecting re-chartering questions
Murray S. Kucherawy
msk at cloudmark.com
Fri Jan 22 09:39:12 PST 2010
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org [mailto:ietf-dkim-
> bounces at mipassoc.org] On Behalf Of Barry Leiba
> Sent: Thursday, January 21, 2010 2:02 PM
> To: IETF DKIM WG
> Subject: [ietf-dkim] Collecting re-chartering questions
>
> 1. Advance DKIM base to Draft Standard
Yea.
> 2. 3rd-party authorization label:
> https://datatracker.ietf.org/doc/draft-otis-dkim-tpa-label/
> If you have not read this draft, please do; we'd like to get a good
> sense of whether to work on this.
Nay until presented with evidence that this is an actual pain point.
> 3. Other 3rd-party signing issues (New protocol? Info doc?)
Yea on the informational document, pending evidence that an actual protocol is needed. (I always support more informational documents, in the constant presence of evidence that the industry as a whole doesn't fully understand all the implications of DKIM and its related work.)
Nay on the protocol until presented with evidence that this is an actual pain point.
> 4. Mailing list cohabitation ("dkim=except-mlist")
Nay until presented with evidence that this is an actual pain point.
> 5. Other mailing list issues (info doc)
Yea.
> 6. Specifying ADSP/forwarder guidelines for re-signing (is this
> different from mailing list issues?)
Yea. (3, 5 and 6 can all be combined into a single document, I would imagine.)
> 7. Collect data on deployment and effectiveness of DKIM base
Yea.
> 8. Collect data on deployment and effectiveness of ADSP, and consider
> future of ADSP
Yea.
> 9. Update overview and deployment/operations documents (info), as new
> data are collected.
Yea.
> 10. Go dormant for a while, and revisit these questions in 8 to 12
> months.
I'd be fine with this if we decide more time has to pass before the above are practical.
More information about the ietf-dkim
mailing list