Michael,
Your view of requirements for IETF process do not match mine and your
assessment of the current situation with the DKIM effort does not match mine.
In fact I do not know what specific behaviors, and by whom, you are
complaining about.
My issue is that if people are going
to invoke process, they should be prepared to define what
the process is. And not just hand waving; concrete pointers
to documents that have been through the rough consensus
mechanism so that all parties can shoot for a common
goal.
The requirement for a threat analysis, prior to chartering a DKIM working
group, was stated by our cognizant area director. He provided concrete,
written guidance, in the form of the 3-point questionnaire that I've cited. It
would be delightful to have a tutorial, but what he gave us is a long way from
hand-waving.
Current IETF rules require a sponsoring AD. Whether to do the sponsoring is
their own decision and, therefore, must satisfy their own professional
criteria. The rest of the IESG also needs to be satisfied, well enough to
pass the working group approval vote.
The process certainly can be subject to whimsy, but it is quite clear that
this is not the case here.
My own comment at the plenary was a very long way from a complaint about the
handling of the DKIM effort. It was, rather, a request for more assistance, in
the form of a) work by the security community to develop better,
community-wide consistency about the term, and b) more tutorial guidance for
completing this thing being called a threat analysis.
It would be great to have rough consensus about all things at all time, but if
you think about that for more than a millisecond you will see that it is a
good way to ensure never doing anything new, and more likely never doing anything.
Steve Bellovin's plenary presentation did quite a good job of explaining the
challenges in the security area. The area has been searching for ways to make
tools with better, more predictable, and longer-lasting efficacy. That
requires exploring planning and design techniques. A threat analysis seems
like a pretty reasonable path to explore, especially since it apparently has
some history in the security community.
So, I am sorry, but I really do not understand what you are complaining about,
that has any application to the DKIM effort.
d/
ps. On the DKIM mailing list, I have twice posted requests for discussion
about some draft text describing the threats to which DKIM responds. As
nearly as I can tell, your own postings, there, have been about an aspect of
the DKIM specification, rather than about the threat analysis. We are,
finally, starting to get some focus on the topic, so I encourage you to help
us try to develop rough consensus on our own threat analysis effort.
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf