RE: ocean: do not boil

["Tony Hain" <alh-ietf@tndh.net>]

Rob Austein wrote:
> Tony, I'm puzzled by your apparent belief that the IETF 
> should be developing solutions to circumvent bad ISPs.  
> Depending on the market environment in which such an ISP 
> operates, this is either a regulatory problem for the ISP's 
> captive market or a case of evolution in action.
> 

I never claimed they were bad ISPs. On the contrary, they are the ones
that are most likely to succeed because the business side of the house
is not going to allow the engineers to arbitrarily swap out equipment
just to get the latest protocol. You might argue that we the IETF know
this protocol is for the greater good, but until it is required by
regulation, or lack of it starts seriously impacting revenue, the
existing box will stay. This is not bad, just a reality to be addressed.

> If there's a problem here that'd be in scope for an IETF 
> working group, please tell me what it is, because it's not 
> obvious to me.
> 

The IETF defined a protocol to move us beyond the addressing constraints
of what we have today. We started down the path to create tools to allow
organizations to move to this protocol at their own pace, with minimal
interdependencies, and the express goal that this would avoid a flag
day. We focused on the approach that would have the biggest payoff
first, recognizing there would need to be additional tools to fill the
holes. Unfortunately now that we have the simple tool, we are being told
that is all we need and the minimal interdependencies goal is absolutely
unimportant. Our only goal now is to make sure we have completely
polished the tools for a core-out approach. Never mind there is no
substantial business driver for that approach to work. 

We are not here to do marketing, but we have to at least understand the
money flow enough to understand which technical approaches are doomed to
fail for non-technical reasons. Since the end site is the origin of the
money, it should follow that approaches that satisfy that need first and
incrementally grow will be viable. If we insist that massive multi-party
infrastructure upgrades have to happen first, where is the income that
justifies the expense? (if someone knows please tell me because a boat
load of customers have asked) Since it will likely lag the buildout
expense by several years, will the ISP chain still be viable businesses
by then?

So to get directly to your question, what is in scope of the v6ops wg?
If it is only the set of tools that an ISP needs to build out today, how
does that fit the reality? If we require sites to subscribe to a
non-existant IPv6 service and refuse to provide standard tunnel or nat
tools, where is the incentive for an app provider to bother with IPv6? 

Basically my point is that we need to finish the scenario descriptions
and agree as a wg that these represent the problems that need to be
solved. Declaring a class of problems out of scope before that happens
is procedurally possible, but will lead to an incomplete set of tools
and possibly failure of the protocol to gain market acceptance.

Tony