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