(please move this thread to ietf-dkim(_at_)mipassoc(_dot_)org(_dot_) I've
played with the
recipient addresses to facilitate this. /d)
While I am sure that Russ can speak for himself, I would like to just
add something I heard very clearly from him at the beginning at the BoF.
What he said, as I recall, was that the first technology in this space
that gets chartered will raise the bar for all others. The question for
the group was whether DKIM should be that technology,
Thanks for mentioning this. I should have included this point in the summary,
simply because it was such a focused statement. It also explains why the
barrier to chartering is being made so high, even for the first effort in this
arena. (A threat analysis would more typically be a first requirement AFTER
chartering.)
Therefore, I interpret that as the threat analysis consisting of a crisp
problem statement and then some fairly detailed analysis of how DKIM
either solves the problem(s) or is a necessary component to solving the
problem(s).
My strong feeling is that any text that requires DKIM to work with additional
standardized components will cause this components to be required as part of
the
DKIM working group effort. This will bog the effort down. Hence we need
crisp,
clear, legitimate statements of benefit that accrue when using DKIM and
requiring no additional, new, standardized components.
I would expect that a working group would be formed first if it is
demonstrated that the problem is important, second if it is shown that
the DKIM solution either solves the problem or can provide a necessary
component of solving the problem, third that there does not exist a
standard today that could reasonably be adapted to provide the same
function, and fourth that of the proposed solutions in this space, DKIM
is the best one to go forward (for some value of "best").
Good summary, except for the qualifications I keep stating about "component of"
statements.
I would further expect that development of answers to these four would
occur on the newly created dkim list, but now I'm channeling Dave
Crocker and there could be a parity error in there somewhere (Dave can
speak for himself).
You did a fine job. Dave indeed requests moving IETF-related DKIM discussions
to the ietf-dkim(_at_)mipassoc(_dot_)org mailing list. He also suspects it
would be less
confusing if there were no public dkim engineering discussions elsewhere...
d/
---
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim