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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf