On Jan 03, 2014, at 14:22, Ted Lemon <ted.lemon@xxxxxxxxxxx> wrote: > On Jan 3, 2014, at 12:33 PM, Eric Rosen <erosen@xxxxxxxxx> wrote: >> Ted> The point of the IETF stating a position on this is not to give ADs >> Ted> another thing they can hassle document authors about. >> One has to look at the likely impact of the draft, not merely at the >> intentions of the authors. > > I'm sorry, I know that there have been some really painful incidents in the past, and that people are sensitized to the potential for a repeat, but I'd like to think that the IETF has learned from those experiences. > > You say that we are edging into politics here, but I don't think that's true. I think that it's entirely appropriate for us to document pervasive monitoring as an attack, because it is one. If you disagree with that, that's fine, I'd like to hear your explanation. If you agree that it's an attack, but think the IETF doesn't need to address it, I'd like to hear about that. But it seems to me that you are doing neither of those things. > > I think one likely impact of this draft is that authors and working groups will take pervasive monitoring more seriously as a threat when they are designing their protocols. It's also possible that ADs will use this document as a bludgeon. I don't think anyone on the current IESG wants to see that happen. If you completely disagree that authors and working groups ought to be thinking about this, then I can see why you would argue for simply scrapping the document. But if you are solely trying to address the concern that the IESG will go mad with power, then let's talk about how to tweak the document to address that concern. Ted’s one likely impact is pretty much exactly why I agreed to sponsor this draft; I also hoped that the end result coupled with RFC 6973 would be akin to the two punch combo of BCP 61 & 72. I guess I’m not shocked and a little amused that we ended up discussing process impacts especially wrt to this draft knowing Stephen and how much he absolutely loves process. But, I guess that’s because everybody wants to know how publication of this draft will affect their standard’s experience (or that we “engineer" everything). But, the word reasonable in Tim’s message jogged my memory about another conversation I had: > From: Tim Bray <tbray@xxxxxxxxxxxxxx> > > There are very few (any?) absolutes in any of the protocols we build, just a wealth of often-conflicting design criteria, which force us to trade off and make judgment calls. draft-perpass-attack says that mitigation of pervasive surveillance should be seen as one of the design criteria, and it’s not OK to ignore it. A reasonable take is that a specification could be held up if there are plausible arguments that this criterion has not been given appropriate consideration, and I see nothing wrong with that. Similar hold-ups regularly occur when there are concerns that there hasn’t been appropriate consideration for efficiency or error-handling or, well, lots of other criteria. When I read this draft for the first time, I wondered among other things: Could publishing this draft make the Internet work better? Some consider better to be more secure/private so sure I can see that it could and in fact support that thinking. Could publishing this draft harm the Internet? (I guess I’m probably not supposed to be sarcastic here but I can’t help myself) I couldn’t think of a reason, but I guess I’m not paranoid enough to have thought about the DoS attack that the IESG can levy against authors ;) More seriously, there’s plenty of checks on abuse of power in the IETF (appeals, recalls, negative re-up comments). What you might not know (or believe) is that the IESG does also self-regulate itself somewhat - if an AD is going off the deep end they’re going to hear about it from another AD. Is the draft requesting anything unreasonable or overly burdensome? In my mind, no on both accounts. In fact, there are already protocols/directorates that require this; thank you MIB Doctors for requiring of MIBs that sensitive information or information that raise significant privacy concerns be explicitly listed by name and the reasons for the sensitivity/privacy concerns MUST be explained (see RFC 4181). Is there an out? Yes. If you’ve got a reason to “monitor”, then you just need to explain why, which is not unlike other “outs”: confidentiality not always required if you explain why (BCP61), AKM unless … (BCP 107), we also give outs to experimental protocols (lisp and mptcp comes to mind), etc. Is there unnecessary process being introduced? I thought not. Is BCP appropriate? Sure! We’ve published BCPs that document what we want done as a best practice and what is a best current practice. I’ve tilted at this windmill both ways and no longer tilt. Is it all figured out? No, but that is just fine in my book. There’s some wicked smart people that participate in the IETF and we’ll figure the process/impacts either now or as we go along. So we can: 1) Publish now, learn as we go, and then publish the normative bits later. 2) Study for [insert timeframe] and then publish the normative bits later way we know how later. Possibly naively, I think that publishing now and dealing with the growing pains of learning as we go option is a bit more in spirit of what the IETF is supposed to be about. The latter option to me sounds a lot like what people complain about wrt the IETF process taking too long and having the bar be too high for the proposed standard level. spt