Hi Eliot, Great that -03 works better for you too. I'd have no problem with your additional change. (I'll let Jari tell me what he wants wrt that when the LC's done, but have noted it in my working copy.) S. On 01/07/2014 07:00 AM, Eliot Lear wrote: > Stephen, > > Speaking only for myself, of course, with two caveats I support the > publication of this draft. The first is that I would prefer still that > it be informational. There just isn't sufficient elaboration in this > work to support BCP, nor could we get that elaboration if we want this > draft to go out soon. I also propose a one word change below. > > On 1/4/14 5:01 PM, Stephen Farrell wrote: >> >> On 01/03/2014 08:36 PM, Stewart Bryant (stbryant) wrote: >>> I have been wondering whether a simple update to "A Guide to Writing >>> A Security Considerations Section" is all that is needed to address >>> the problem in hand? >> After a bit of offlist mail with Stewart, it turns out I had >> misinterpreted the above. >> >> I now believe (haven't quite confirmed, but its a fine idea >> anyway so worth raising here) that what Stewart meant was >> not to open up 3552 and add this text, (which'd take years) but >> rather to make the RFC resulting from this draft be just another >> part of BCP72 (aka RFC 3552). >> >> (In case folks don't know, BCPs can be made up of multiple RFCs, >> e.g. BCP 10 [1] is like that.) >> >> I think that's quite an interesting idea, and would probably only >> require adding a sentence or two to relate this text to that in 3552 >> (which is currently all of BCP72). I'd certainly have no problem >> were that the outcome. >> >> I guess that just might help folks with concerns that as a new BCP >> this might be over zealously applied. >> >> But I'm not sure - would that in fact help anyone with such concerns? >> > > There is an impedance mismatch between RFC-3552, which contains > substantially more specific guidance – with examples – on how to deal > with security considerations after a long and trying period of > establishing that procedure, and the new requirements we see in this > document, which are of a very general nature, and where the threat is > not yet well understood. > > As Stewart wrote, -03 is considerably better than previous versions. > You've laid out a test in -03, which I believe is the key to the draft: > >> Those developing IETF specifications need to be able to describe how >> they have considered pervasive monitoring, and, if the attack is >> relevant to the work to be published, be able to justify related >> design decisions. This does not mean a new "pervasive monitoring >> considerations" section is needed in IETF documentation. It means >> that, if asked, there needs to be a good answer to the question "is >> pervasive monitoring relevant to this work and if so how has it been >> addressed?" > > The first sentence is perfectly clear. The 2nd sentence is perfectly > clear. I would prefer that the question in the 3rd sentence read "how > has this been considered?" This is consistent with the 1st sentence > with regard to justifications, and also gives us time to more properly > evaluate the threat model. I hope the IAB and W3C workshop will further > advance our understanding so that more guidance is available. > > If this change is made, then the BCP is what I would class "good > enough", even though my preference would be for Informational. > > Eliot > > >