> > - Packet and request hijacking is A Really Evil Thing.
>
> ...in the opinion of Internet Engineers. There were days when NATs were ARET.
Hey! You know what (who's) religion I was brought up with in my early
research days. But I speak for myself, thank's very much.
NATD is a temporary solution with a limited number of border conditions.
It is temporary because IPv6 and IPSEC should render it unnecessary in
the long run. No, I don't think it's a solution in theory, but in fact
it solves a particular problem.
That's my point wrt client autodiscovery protocols: Let's view transparent
caching as Evil (it deserves a perjorative!) and temporary. Let's propose
a solution so that administrators might get an extra 15 minutes of sleep
per night. :-)
> If we want to break the end-to-end functionality, we should at least know
> what we do. A good place to do hijacking is a leafnode, not a backbone.
> Maybe we should document this, point out why and how.
Sounds like a section in the architecture document to me. Doesn't sound
like part of a charter.
> Given that caches do interoperate, is there a need for standardization of
> inter-cache communication protocols? Are the competing protocols a problem?
Does the Inktomi product interop with Squid? You can treat the Inktomi
TF as a root node? That's news to me...
I guess my weakly articulated point was that you have these different
cache systems out there. Is there a need to define a protocol or mechanism
to exchange metadata between these systems, in essence to extend the
global aggregate size of a caching system? Possibly, we're talking about
an application level internetwork routing protocol based on HTCP. It's
a thought...
> God created lawyers to deal with such things. Please, let us solve the
> technical issues and leave the law (immature law is politics, where we as
> private persons are entitled to meddle) to the lawyers at this stage?
Yeah, but we at least need to say "It ain't our problem" somewhere.
Saying nothing is like sitting on our hands waiting for someone to
make it our problem.
> It is unclear to me if you propose to cover
> - client to proxy configuration
yes.
> - interproxy communication
not as such. we have ICP for this today (such as it is :-)
inter-cache system communication.
> - transparent caching and Evil
yes. architecture.
> - cache system architecture
not really -- architecture of intermediate infrastructure
between the client and the origin server.
> or if you want to focus on the first issue.
first issue? as in architecture?
-scooter
> ** Scott Michel wrote: **
> > points I was trying to pose as the goals of this proto-WG:
> >
> > - There are clients. There are origin servers. There may exist
> > structure between clients and origin servers. Clients shouldn't
> > be manually configured to use this intermediate structure,
> > otherwise, things like packet hijacking and request hijacking
> > become the norm.
>
> Comments from the developers on this one (since there is real work in this
> area)?
>
> > - Packet and request hijacking is A Really Evil Thing.
>
> ...in the opinion of Internet Engineers. There were days when NATs were ARET.
>
> If we want to break the end-to-end functionality, we should at least know what
> we do. A good place to do hijacking is a leafnode, not a backbone. Maybe we
> should document this, point out why and how.
>
> > - There are a lot of caching systems out there, the dominant one
> > appears to be Squid (and Harvest). There will be others as well
> > (successful PhD research notwithstanding). What kind of metadata
> > could or should these caching systems exchange with each other?
> > Do we even want caching structures to interoperate with each other?
>
> Given that caches do interoperate, is there a need for standardization of
> inter-cache communication protocols? Are the competing protocols a problem?
>
> > - Structure requires some kind of architecture and requirements doc to
> > describe the various entities and their interactions.
>
> This is in my opinion the first point of the agenda (possibly after a scenario
> document, if we need one).
>
> > - One thing I tried to stay away from is the copyright issue.
>
> God created lawyers to deal with such things. Please, let us solve the
> technical issues and leave the law (immature law is politics, where we as
> private persons are entitled to meddle) to the lawyers at this stage?
>
> > I don't think we want the scope of wrec (for lack of a better name) to
> > have too large a scope. If we can at least come up with a few approaches
> > and possible standards-track RFC for client<>"structure" autodiscovery
> > I think we'd be able to declare the WG a success on that point alone.
>
> It is unclear to me if you propose to cover
> - client to proxy configuration
> - interproxy communication
> - transparent caching and Evil
> - cache system architecture
> or if you want to focus on the first issue.
>
>
> Ingrid
>
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:25 MST