Jim(s),
Stephen has indicated a preference on having the attacks
described in both places, even if it is repetitive.
I'll let Stephen have his perferences, I don't see the need for full
descriptions everywhere. I want to be able to hand this document to my boss
and say "This is why the effort is important" and too much detail is
determental to this usage.
I think that we should judge on a case-by-case basis really, but
that's much easier if we've got text describing each threat to
start from, hence being keen to see lots of threats described
in this document. If some of that text is judged too detailed
and thereafter moved to base, that's fine.
There's a very fair point that can be made about the level of
abstraction/detail though - clearly we should generally have
more abstract descriptions in the threats document and more
specific ones in base etc.
But I'm happpy to start from the document editor's judgement
on the matter and see where the wg consensus takes us.
As others have pointed out, treating SSP (a WG deliverable
per the proposed charter) and reputation services (out of
scope per the proposed
charter) in the same manner seems inappropriate. My strong
preference is to include SSP in this threat analysis and not
to discuss reputation (or accreditation) services other than
perhaps to mention that they might be users of DKIM.
I am willing to have different items have different amounts of detail here.
I think that SSP is easier to understand (but harder to get correct) than
DKIM is, thus the justification to do it could easily be placed in the SSP
document. I think that the justification for DKIM is more difficult to
understand without the additional items of other way it might be used.
I'd be with Jim F. here - given the timescales we're aiming for
adding additional deliverables might just add delay & might cause
problems when we forward the threats document to the IESG. How
the ssp bits of the threats document should be structured in
editorial terms...again I'm happy to wait and see the next version
and can then comment on that.
But, the same point as made above applies too - the threats document
can try to deal with an abstraction of ssp, and more detailed stuff
can be held over until we're working the ssp deliverable itself (or
not doing so, if all Doug's energy finally pays off:-)
Stephen.
_______________________________________________
ietf-dkim mailing list
http://dkim.org