Re: comment on unmanaged analysis presentation/doc

[Keith Moore <moore@cs.utk.edu>]

> the simple model of where that could happen is
> 
> 1. one side
> 2. the middle
> 3. the other side
> 
> the more interesting model, boiled down to the assymetric tcp case, is:
> 
> a. the initiator
> b. the initiator's upstream
> c. somebody out in the middle
> d. the responder's upstream
> e. the responder
> 
> so far on this list i've seen "a" and "e" ruled out as places to put
> protocol-translation/bridging machinery, though a tunnel from "a" or
> "e" to some kind of "c" seems popular.  every time anybody mentions
> asking "b" or "d" to do this they get shot down, which is too bad,
> since (1) they already have a service provision relationship with a
> party who evidently wants a new service, (2) they tend to have more
> technical know-how than their customers, (3) topologically these
> are the most-bang-for-the-littlest-cost, and finally (4) we can stop
> talking about it since it's just nat or an application layer proxy at
> that point, not in need of any standardization work.

One problem with putting bridging machinery anywhere in the middle
is there's no such thing as generic bridging machinery that will
work for all or even most apps without causing significant problems
for the others.  

That doesn't mean that there aren't corner cases where bridging
machinery in the middle might be useful.  And as long as there is
an identifiable case where such machinery seems useful, and we don't
pretend that they are generic/universal solutions, I see no reason
they shouldn't be worked on.  Whether such work is appropriate for
v6ops or another WG is a different question.  

What we need most now is to understand which cases would benefit 
from machinery in which places, and conversely, which kinds of
machinery are the most useful and deserving of v6ops attention.

Keith