> From: Roland Bless <roland.bless@xxxxxxx>
> we probably need to do something on reducing the number of _broken_
> middleboxes (or their implementations respectively) - I'm not focusing
> on NAT boxes here.
> ...
> I think it's clear that we will not get rid of them, but if I hear
> about boxes that try to do "clever optimization" or "security" by
> re-writing TCP sequence numbers ... bundling segments and so on, I'm
> wondering who actually engineered those boxes; aren't the
> vendors/engineers participating in the IETF? Who buys and deploys such
> boxes
> ...
> What could be IETF efforts to get a better situation for the deployment
> of future innovations or do we simply accept that (a few) broken
> middleboxes dictate the future level of innovation in the Internet?
I hear you, but... this is not a simple problem.
I think we need to start by understanding what drives the creation and
deployment of these devices. I think the answer to that has to be that some
people have needs that aren't being met by the IETF, and so there's an
opportunity for private entities to create and sell 'solutions'.
The IETF doesn't have a police force, or any enforcement mechanism. If we're
going to head off these boxes, the only tool we have to do that is to build
better mousetraps - i.e. design stuff that does what people want, is more
cost-effective, and is better than these local 'point deployment' boxes.
Sadly, the IETF has a long history of being hard-headed about 'my way or the
highway', and not carefully listening to what the 'customers' are telling us
about these various aspects of a successful design.
(The most noteable example of this being NAT - which was going to be ugly
anyway, but as a result of the IETF refusing to create an architected NAT
solution - apparently on the theory that if we stuck our fingers in our ears
and went la-la-la-la loud enough, it would Just Go Away - we now have NAT that
is both ugly _and_ brittle [because it's not part of an architected _system_],
difficult to work with because it [mostly] lacks any external control
interface, etc.)
So, sorry, I don't have a simple solution to what I concede is a real problem.
But it's a complicated problem -> no simple solution.
Noel