Brian E Carpenter wrote:
Michael, you've had some quite concrete responses which I hope
have clarified things, but I really want to say that making
Internet protocols secure isn't a hoop jumping exercise; it's
more like a survival requirement, and has been for ten years
at least.
Where did I say that? 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.
And to answer your question, no it hasn't been answered
because I've yet to hear from the people -- and there were
many on both the IESG and IAB -- who were asking for it.
Do you seriously think you could write a "threat analysis"
given the definition in 2828?
Mike
Brian
Michael Thomas wrote:
Having a "threat analysis" was brought up at the plenary by Steve
Bellovin as being a Good Thing(tm). At the MASS/DKIM BOF we are
being required to produce such a thing as a prerequisite to even
getting chartered as a working group. The problem that I have (and
Dave Crocker at the plenary) is that there doesn't seem to be
any definition of what a "threat analysis" is. Contrary to what
it seems many people demanding such a thing suppose, the term
isn't self evident. Maybe I've missed it but I'm not sure that
I've ever seen one. Worse, I'm not very sure that the people who
were telling us that we needed one could easily be able to come to
consensus on what constitutes a threat analysis.
So, if this is going to be yet another hoop that the IESG and IAB
sends working groups through like problem statements, requirements
documents and the like, I think it ought to be incumbent on
those people demanding such things to actually both agree and
document what it is that they are demanding. This is not just
annoyance at yet more process on my part, but a real desire to
not have people waste a lot of time producing documents that
fail to meet a definition that is otherwise only determined by
multiple iterations of "that's not what we want". This is, in
fact, what happened this time around, and has happened in the
past with the SIP wg.
Mike
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf