RE: ocean: do not boil

["Bound, Jim" <Jim.Bound@hp.com>]

Tony,

Also add the commerical Intranets deploying IPv6.  They will not have the same needs and in some cases far different needs than ISPs.  If that is out of scope we need to support that elswhere than v6ops for transition.  If that is the case we should declare that now.  That would mean we don't care about the Enterprise too.  Important assumptions and view points to bring up.  Thanks for doing that.

/jim

> -----Original Message-----
> From: Tony Hain [mailto:alh-ietf@tndh.net]
> Sent: Tuesday, September 24, 2002 7:20 PM
> To: 'Randy Bush'
> Cc: v6ops@ops.ietf.org
> Subject: RE: ocean: do not boil
> 
> 
> Randy Bush wrote:
> > > So all content sites are held hostage until their ISP gets 
> > around to 
> > > providing IPv6 service...
> > 
> > nice hyperventilation.  but if you'll look at the beginning 
> > of this thread, the basic idea is that we should not try to 
> > provide v4<->v6 access to *all* services.  in fact, i listed 
> > the service(s) which _must_ be interoperable.
> > 
> 
> So we should provide application proxies for the services that we know
> work through IPv4 NAT. More to the point though, the *only* 
> services we
> should be worried about are the ones that are important to ISPs. If it
> is useful to an end site, but not to an ISP it doesn't matter. 
> 
> > >> a content site is not a 'consumer'.  they are provdng a
> > >> servce.  if they want to provide the service, they need 
> > >> things like mains power, the appropriate ip service(s), etc.
> > > This model precludes any consumer from providing content. 
> > Specifically 
> > > it precludes any peer-to-peer applications. I realize that 
> > many ISPs 
> > > currently don't like the idea of a consumer hosting 
> personal web or 
> > > mail services, but their business practice should not have 
> > any impact 
> > > on the range of technology standards we are developing.
> > 
> > no, but nice emotional appeal.  those evil isps just won't 
> > let good red-blooded amurikans do anything.  we should put 
> > them in jail.
> > 
> > it merely says that when you decide to provide a service you 
> > must have the tools to provide it.  if you want to provide 
> > email service, you need smtp, not http.  if you want folk to 
> > access your server over tv, you need to put it on a tv 
> > service.  if you want it on v4, you need to put it on v4.  
> > same for v6.
> 
> So now I am confused. Is the tool set we defined for providing IPv6
> service, even when intermediate ISPs do not, in scope or out? How does
> the end node know when the IPv6 service it sees is based on a real
> underlying ISP service, or is simply a translated service? Outside of
> NAT application issues, why should it know if the service is live or
> translated?
> 
> > 
> > > I can understand the desire to sort and prioritize to 
> > manage resource 
> > > constraints, but at the moment I see an abundance of people 
> > willing to 
> > > work on the problems.
> > 
> > there is an abundance of people willing to make careers at 
> > making a complex world to try to put marketing whitewash on 
> > the fact that it is still hard to have a merged v4/v6 
> > infrastructure because
> >   o few vendors make the hardware
> >   o there is no motivation to move to v6
> > 
> > it's like the failing sales force going back to engineering 
> > for an endless list of features which they hope will sell the 
> > product. a good recipe for turning a failing sales force into 
> > a failing company.  
> > 
> > but this is the engineering department, and our task is to do 
> > our job prudently and properly.  we need to make sure that 
> > the *basic* and *critical* things needed to operate v6 in a 
> > v4 world can be done, and done reliably and scalably.
> 
> Fine, but this didn't answer where the constrained resource is, and
> there appear to be different viewpoints on what the scope of the IPv4
> world is. If the scope of the working group is restricted to 
> only those
> things that are critical for an ISP to deploy service, we 
> will be seeing
> a much longer transition period, and possibly an outright 
> failure to get
> IPv6 deployed. If on the other hand the IPv4 world includes the edge
> sites, we have a much larger set of tools that are basic and critical.
> In particular for those sites who have had requests for public IPv4
> address space turned down so they decide to go straight to 
> IPv6 to avoid
> a messy 1918/nat deployment & transition, are they restricted 
> to web and
> mail proxies? 
> 
> Tony 
> 
> 
> 
> > 
> > randy
> > 
> 
> 
>