No. Sigh. It's actually a good idea to do it. And your level of detail
certainly makes the issues coherent, tangible and addressable. My quibble
is over the timing and the newness of them. Not that such quibbles ever
count for anything.
I think it is considerably more than a quibble. It goes to the heart of
having this effort be productive, because it goes to the heart of the
current requirement. If we are going to be productive, we need to be clear
about each step of work that is to produce output and we need to work
together to deliver it. Eric's suggestions appear to be outside the scope
of the current deliverable.
This has all been said before, but is worth reviewing:
1. The current requirement is to get chartered.
2. Russ has set a pre-condition of a 'threat analysis' document, where HE
defined what that meant. (I think he expanded the definition, after the -00
draft, but that's a separate discussion.)
3. His pre-condition is his personal requirement, to satisfy him to sponsor
the working group. There is no "IETF" requirement for a threat analysis in
any form.
4. As has been obvious since the first DKIM BOF -- and, by the way, obvious
everytime the Security Area wrestles with new paradigms for requirements on
its working groups -- there are many different, valid views of requirements,
problems, etc. Security is a difficult topic and it is understandable that
it continues to wrestle with ways to make security work productive. The
problem is that the confusion among the experts winds up hurting
productivity IETF efforts to produce security-related output. As I say,
this sort of freeze-up from conflicting requirements has struck the Security
Area before.
5. Russ' definition(s) for the TA document are useful for ensuring a good
degree of coherence to the effort. Therefore it is worth more than merely
satisfying his personal requirement, to make him comfortable to sponsor the
working group. No doubt it would be useful to do more than Russ is
requiring, but we need to draw the line somewhere, and targeting his
specific requirement(s) is clearly the most efficient choice.
All of this says that suggestions for additional threat analysis work need
to be at the discretion of the group. My own view is to defer anything and
everything that goes beyond the immediate requirement to get chartered.
d/
ps. This round of discussion highlights the problem I am expecting at the
upcoming BOF, where new or casual participants pepper the meeting with all
sorts of reasonable "requirements" that are, in fact, outside of scope
and/or already dealt with. It is the reason that I think the meeting should
be conducted with a focus on those who have done their homework and are real
participants, rather than casual tourists who need lots of pedagogy.
_______________________________________________
ietf-dkim mailing list
http://dkim.org