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