Why doesn't someone just ask Russ what he meant and be done with it? -Nick > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Michael Thomas > Sent: Friday, August 12, 2005 7:24 AM > To: Harald Tveit Alvestrand > Cc: Michael Thomas; ietf@xxxxxxxx > Subject: Re: what is a threat analysis? > > Harald Tveit Alvestrand wrote: > > One small point..... > > > > --On 11. august 2005 07:52 -0700 Michael Thomas > <thomasm@xxxxxxxxx> wrote: > > > >> 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. > > > > > > I did not hear at any stage Russ claiming that asking for a threat > > analysis was "invoking process". He was asking for information that > > would allow him to make up his mind about whether or not to > support DKIM > > becoming a WG. > > Then maybe we can call it a "process gate", or something else > entirely. My main point still remains: if you're going to > impose conditions, it seems only fair that the conditions > be understandable by all concerned, and most especially if > multiple people are calling for the same process gate that > they actually _agree_ on what constitutes at least the form > of fulfillment. This conversation here has thus far not > relieved any of my unease that there really is any such > agreement across all those who think this is a good process > gate. > > > As far as I know, there is no formal process called "ask > for a threat > > analysis". Some people would argue that there should be, > and if that > > argument were to be adopted, it should certainly have > guidance attached > > to it. > > My feeling is that it's probably a good thing for requirements > drafts to talk about. In the case of a security protocol, it > seems very reasonable that requirements are derived at least in > part from the threats they are intended to address. Non-security > protocols would probably do very well to consider up front what > the security requirements are in any solution space. > > Mike > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf