> OK, I've got to jump in here and stomp on some these assumptions.
> Assumptions that do not belong in a WG Charter.
Assumptions belong in a WG charter as the basis for identifying
a problem. Personal invective doesn't belong in a charter, and I
may well be guilty of that.
Nonetheless, I assume a problem exists to which this WG will be
a solution.
> Not true. IPv6 and IPSEC will not eliminate key functions of NAT.
> Particularly for security and network flexibility. NAT is a technology that
> will be around for a very long time because is serves a purpose in a overall
> network implementation.
Agreed. But it's not the *only* solution to a problem. I can pull
off the same things that NAT does with different technology. It
depends on other nontechnical factors, such as cost. Installing a
NAT on a Linux box is more cost effective than deploying FireWall
One. That shouldn't drive a religious war that NAT is the only
solution to the problem.
That's not to say the NAT isn't an expedient solution to something.
The fact remains that there are alternative to NAT.
> This is your personal view. It should not be reflected in the WG Charter.
> Policy Based Routing was created from operational requirements! WWW Client
> transparency in it's various shapes and form have evolved over time based on
> operational EXPERIENCE!
Yes, it's my personal view. I think transparent caching is a problem,
not a solution. It has no alternatives, other than manual configuration.
Therefore, it is my personal view that client autodiscovery should be
addressed as an alternative to someone else's operational experience.
See Paul Vixie's post. I've seen other examples where transparency
only buys one grief -- look at ATM LANE as another example of so-called
transparency.
I disagree with your assertion, that transparency evolved as the result
of operational experience. It came about because there exists a vaccuum,
where one makes a binary decision: manual conf or transparent caches.
> What your doing with this charter discussion is drive you personal view
> points against the trends in the WWW Caching Community.
>
> Lets define the charter in a way that pulls in existing work and experience.
> Not make assumptions that contradicts the experience of people who've
> implemented WWW Caching as a critical component of their network
> infrastructure.
I'm not driving the drafts, which you're more than welcome to submit
one or contribute toward. I'm attempting to define some consensus on
a charter with well defined scope and goals. I perceive certain problems
which can be addressed. If anything, I'm guilty of raising the level
of invective.
Transparent caching belongs in an architecture or requirements doc.
I take it you just volunteered to write that section?
-scooter
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:21:25 MST