Hi Stephen, On 12/9/13 5:03 PM, Stephen Farrell wrote: > So, nothing in the draft says "ignore everything else" and it'd > be wrong if it did. Please let's not have straw men tossed around. What I wrote was that there was an implication based on omission. > Pervasive monitoring is an attack and like > the draft says: > > The IETF also has consensus to, where possible, work to mitigate the > technical parts of the pervasive monitoring attack, in just the same > way as we continually do for these and any other protocol > vulnerability. > > I think that's quite clear - we handle it the same as for "any > other protocol vulnerability." Well except you go on to write: > This BCP simply records the consensus to design protocols so as to > mitigate the attack, where possible. Nothing about practicality or engineering tradeoffs that need to be addressed (except network management). And the logic is circuitous at best. If we were to apply these same rules to development of a protocol that allows for intercepting/transparent proxies for purposes of data caching, how far would you go to mitigate? I ask because if the effort is Herculean people are just going to route around us. A simple fix would be to change "possible" to "practical", which is what we the IAB wrote in our statement. > >> when in fact I found the opposite: >> since you laid out explicitly only network management considerations, > But the above already says that this is just another threat. > An important one? Sure. Overrides everything else? Of course not. > > But yes we called out one significant area where there's an obvious > tension caused by mitigating this threat but where there's also > an obvious need for some forms of monitoring in order to ensure > that networks can be managed. > So back to our example: would transparent/intercepting proxies be something you bounced back if the working group decided to allow them after due consideration? I ask because that is still a possible outcome. >> the implication is that all other considerations are excluded. > I don't read the draft that way at all fwiw. If everyone did, > that'd be something to fix though, I agree. But it doesn't have to be everyone to be a problem, and what's more, when one person appeared to have read it that way, I had no backing in the document to correct it. > >> The >> purpose of my change is to remove that implied exclusion, and leave this >> to working groups to wrestle with. > Working groups will have to wrestle with this BCP yes. In some > cases that'll be easy. In other cases, hard. > >> I'm happy with Robin's wording as >> well, and I don't mind you proposing other wording further to your >> liking, so long as we recognize that there are other considerations. > As I read it, that's there already in the text quoted above. > I don't think we want to try to list every possible other > consideration, or we'll never get this done. I didn't ask for that, nor does his wording suggest that. > >> If you can show me where in your text it allows for those other >> considerations as I believe I've done in the reverse, I'll be happy to >> stand corrected. > My reluctance to extend a get-out-of-jail card here should be > fairly obvious, but I think its important that we recognise that > there will be people who from time to time will want to work around > the IETF consensus on this topic. What you call a "get-out-of-jail" card may be simple operational reality which is why I keep bringing us back to the case of a bandwidth-constrained network that does transparent/interception caching. I don't see how the new rules would permit the mechanisms that save service providers and their customers huge amounts of bandwidth and delay. Also, not for nothing, but the poll at the IAB meeting was the beginning of a process and not its end. Nobody had an opportunity to explore the ramifications of their decisions, which is what engineers need to do. Eliot