I finally skimmed over the drafts that are in the revised charter and read Dave's comments about the motivation draft which I largely agree with. What seems plain to me is that the motivation draft has *way* too many hidden assumptions in it that frankly I don't understand, and that the draft doesn't explain. The charter says the overview should have a proposed mechanism, but that's probably a mistake because it just it encourages working on the fun part -- working on the protocol -- and discourages working on the boring part -- describing what the problems are in sufficient detail that we can agree with the scope of any changes needed. The motivation draft states that it introduces incompatible changes to DKIM but it's pretty much bald assertion which I can't make sense of. If there are incompatible changes, we should all be able to agree that they are... incompatible. Also: one of the goals in the motivation draft as stated, after all, was to minimize the cryptographic operations... one backward compatible DKIM signature is pretty hard to beat.
The current motivation draft seems to stray far afield from the charter's goals too which are "replay" and "mutations". Given how long the thread on mutations was, at the very least any overview needs to explain why that's useful at the very least. The same is true of replay. Dave brings up a good point about "Procrustean" with the motivation draft and that is the feeling I get too. Positing widespread changes to email architecture seems like a non-starter to me, especially since the people who want this (senders) are not going to be the people tasked with dealing with it (receivers).
So my overall question is what this working group deliverable for an overview should look like? What is its goal? For me, I would like to be able to understand at the very least why it can't be backward compatible, but it needs to be much more than that, imo. If this wg is not going to flame out like the last attempt, the document needs to generate consensus of the a) the problems detailed in depth and b) the possible mitigations without going into low level protocol level detail.
Mike _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
