matthew halsey wrote:
> I would propose that if a 'grey' mechanism results in a
> modified, but clearly
> identified, TCP stream, it may be included. If the result
> is clearly NOT
> TCP (and I would include UDP here) then it shouldn't be
> included.
>
Matt-
You've presented an interesting relevance test for the
draft. I agree with it in principle but not in how you've
applied it to spoofing. The goal of the working group and
the drafts has been mainly one of education and information
dissemination. For this reason, I tend to err on the side of
inclusion. This is especially true in the case of the
research issues draft where we've lowered the bar for
inclusion such that all you have to do is write it down and
we'll include it.
There are two communities that we are trying to bring
together here: the satellite community and the IETF. In my
experience the satellite community, with the exception of
the frequent posters to this list (you know who you are), is
relatively ignorant of the IETF process and the TCP/IP
protocol. I am continually correct people about how TCP is
not a Go Back N protocol and hasn't been in about a decade.
This community needs, IMHO, a roadmap laying out what people
are doing with TCP that might benefit them and some
thumbnail estimate of the value of that work. (In the
process of preparing this summary, I think the IETF
community has become more aware the issues and concerns of
the satellite community.)
> Some spoofing terminates TCP at gateways and uses a more link-sensitive
> protocol between them. This is clearly not TCP and shouldn't be included -
> in my opinion.
>
Getting back to your point, from the perspective of the
relatively unsophisticated TCP networking engineers in the
satellite community (& while I apologize to the scores of
lurkers on this list who are insulted by this, please note
that I count myself among them) the TCP service begins at a
users desktop and ends at the server they are trying to
reach. Should something be inserted in the middle of the
connection *that is not TCP* and improves their network
utilization and/or individual connection performance, that
is a mitigation that they would be interested in. Should it
turn out that someone is developing this type of thing and
it's thought to be a really bad idea by people on this list,
it is our charter to get information to them because we (the
list) are supposed to know better. Or if no one can make a
good argument why it should not be used (either from the
user, service provider, or Internet community perspective)
then that is also valuable information that should go into
this document, again because we are supposed to know better.
Comments? Arrows?
-aaron--Aaron Falk (310) 814-4932
TRW, Inc Space & Electronics Group
One Space Park Redondo Beach, CA 90278
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:37 EST