Melinda,
Thanks for the clarification. My comments were with respect to midcom. I
look forward to a taxonomy on middleboxes at large as I worked on RFC3040
which did the taxonomy of web caching and replication; which is now at least
a year outdated and doesn't address the bigger picture.
Gary
-----Original Message-----
From: Melinda Shore [mailto:mshore(_at_)cisco(_dot_)com]
Sent: Friday, March 09, 2001 1:55 PM
To: Tomlinson, Gary; Mark Nottingham; midtax(_at_)lists(_dot_)hactrn(_dot_)net;
Michael
W. Condry
Cc: Maciocco, Christian; Yang, Lily L; Condry, Michael W; Bhutani,
Manasi; Erickson, Rob; Menon Rama R; ietf-openproxy(_at_)imc(_dot_)org
Subject: Re: [midtax] Re: Midtax comments
I don't know whether this is a trivial point or
not, but the *midcom* working group is focusing
on network/transport layer stuff, and *midtax* is
a BOF to discuss categorization of middleboxes
with, I think, the intent to clarify thinking and
architecture in new activities (like midcom!) around
middleboxes.
I think there is a much simpler way to distinguish the scopes of Midtax
and
OPES. Midtax is involved with packet networking intermediaries, while
OPES
is involved with content networking intermediaries. The difference lies
in
the end to end nature of each. Packet networking is dealing with the the
end to end delivery of bits through packet network elements. OPES is
dealing with application level semantics, is the end point in the formal
IETF definition from a Midtax point of view, and will make the necessary
application relays (i.e. proxies) as necessary to complete the application
transactions.
We're in the process of trying to clean up some of the
language in our documents around the definitions of
proxies, ALGs, etc. The way you're talking about the
distinction is pretty much what I said earlier, but
I'm not sure that your language would be considered
simpler for the consumer of midcom documents, acknowledging
that it could well be simpler for web proxying-type
folks. There's another issue for somebody to worry
about.
Melinda