RE: ocean: do not boil

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

yes why artificially limit the working set?  

/jim

> -----Original Message-----
> From: Tony Hain [mailto:alh-ietf@tndh.net]
> Sent: Monday, September 23, 2002 9:17 PM
> To: 'Margaret Wasserman'
> Cc: 'Randy Bush'; 'Bob Fink'; 'Jun-ichiro itojun Hagino';
> v6ops@ops.ietf.org
> Subject: RE: ocean: do not boil
> 
> 
> Margaret Wasserman wrote:
> > Hi Tony,
> > 
> > >The most obvious case at the moment is the substantial 
> deployment of 
> > >IPv4-only NAT CPE that for financial reasons *will not be 
> upgraded* 
> > >until the ISP is ready to provide native IPv6 support (in 
> > North America 
> > >that is looking like ~2006, or in the case of docsis devices much 
> > >later). For those end sites that want to move sooner, and 
> > don't have a 
> > >reasonable option for an alternate ISP, just saying we 
> only support 
> > >dual stack is telling them they can't use IPv6 capable apps & 
> > >appliances for at least 5 years.
> > 
> > I'm not sure how this follows from Randy's comments...
> 
> >> if i want my web site seen by both v4 and v6 users, then i can
> connect 
> >> it to v4 and v6 space and run dual stack.  in fact, i do 
> so today.  
> >> as v6 deploys, folk every useful site will do so.
> 
> Asserts that if a content site wants to be seen as IPv6 that it is in
> control and can just advertise that and all IPv6-only nodes 
> will be able
> to reach it. The reality is that a consumer behind an 
> IPv4-only NAT CPE
> will need some form of IPv6-over-foo to get past the CPE. The 
> hidden and
> invalid assumption in Randy's comment is that the IPv6 network is
> contiguous. 
> 
> 
> > 
> > If a node in the end site wants to access an IPv6-only 
> > service, the user would need to install IPv6 on that node (or 
> > buy a new appliance with IPv6 included, etc.).  If the IPv6 
> > infrastructure isn't present to route IPv6 natively, then 
> > they might use one of our several tunneling mechanisms to 
> > tunnel the packet over the IPv4 infrastructure to an IPv6 network.
> 
> This is specifically what Randy's note was asserting, that we 
> don't need
> the complexity that the mechanisms bring to the table. 
> 
> > 
> > >Also, as a meta point, declaring an approach for transition out of 
> > >scope before the scenario documents are done is just a bit short 
> > >sighted.
> > 
> > I actually think that we were discussing some prioritization 
> > of the scenarios, not declaring any of the solutions in or 
> > out of scope.
> 
> >> trying to make pure v4 sites/hosts communicate for 
> arbitrary services
> with pure 
> >> v6 sites/hosts and vice verse is a nice way to make the problem
> vastly more
> >> complicated, the solutions vastly more complex, and the 
> net much less
> reliable.
> >> let's not go there.
> 
> Sounds like precluding a class of transition scenarios to me.
> 
> > 
> > Once we have a full set of scenarios, I think it will make 
> > sense to try to trim down the set of scenarios, based on what 
> > we think is most likely to occur.
> > 
> 
> This is absolutely silly. The whole exercise is designed to refocus on
> the scenarios that are actively being deployed, or currently on the
> drawing board for deployment. Claiming that we can out guess 
> the market
> acceptance of those and whittle that down further presumes access to a
> crystal ball I haven't seen yet. Prioritizing based on relative broad
> applicability would make sense if there were limited resources, but we
> seem to have plenty of interested participants. Developing them in
> parallel doesn't appear to be a problem, so why artificially restrict
> the working set? 
> 
> Tony
> 
> 
> > Margaret
> > 
> > 
> 
> 
>