Stephen
This is always tricky and the short answer is that we won't know since
there may always be a vulnerability that we didn't think about.
Frankly, given the long history of Bad Actor creativity, I assume that the there
is no issue of "may" but the certitude of "will".
Nonetheless, the threats document must satisfy a "sufficient" set of concerns.
The question is what those are and how will we know when we have satisfied them.
(Just to hammer home my point, I'll give offer an alternate, short, and somewhat
flip response that is nonetheless meant seriously: I was not asking about the
technical competence of the document; I was asking about the process
requirements for completing a milestone...)
However, the IESG did accept our milestones and if we can demonstrate
that we made a good faith and technically competent effort to do the
job, then I think we have as good a defense as you can get in this
case. That's a reason why getting comments on the threats draft is
important. Silence on this produces no evidence (nor btw would simple
acclaim).
The question is whether we are getting comments from the necessary folk?
The Security Area has a long history of being quite good at finding (legitimate)
flaws. So the rest of us might well engage in super-human diligence and still
not satisfy the folks with an effective veto.
How can we be proactive, in this regard?
So, for me, being able to show (via the I-D, issues list and mail
archive) that we've done a good job should be enough. We'll see though.
Well, we already have some history with this document.
It began as a personal requirement to convince an AD to sponsor the working
group. That requirement was satisfied.
Since then, my sense is that the Security Area feedback we have gotten has been
far, far less sanguine with our work.
Good project management requires responding to such a situation with more than
hope. It requires a proactive effort to ensure meeting the deadline.
PS: And in any case, IESG members are smart enough to be able to raise
issues regardless, if that's what they want to do.
Stephen, the problem is that they raise them after our work is done.
Hence we enter the oft-cited cycle of potentially endless guessing and revision,
notably protracting things far beyond the scheduled milestone.
I am seeking to understand how we can avoid this very common scenario,
particularly for a deliverable is of a type that frankly *invites* the problem.
d/
--
Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org