[ietf-dkim] Review of draft-fenton-dkim-threats-01

[Dave Crocker]

> 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.