Subject: RE: "IPv6 transition security" problem statement from a workshop that never happened

From: "Bound, Jim" <[email-masked]>
Date: Fri, 15 Aug 2003 00:19:15 -0400

> > These are well understood in the deployment efforts for IPv6
> 
> great!  where will we find them documented?

You won't its a deployment strategy within a private company and none of
your business.  Your free to work on the problem to but no one is
waiting for your wisdom and briliance in the standards community for
what is a deployment problem today.

> 
> > and will be addressed operationally too.
> 
> as i am a bit familiar with some actual operational v6 
> networks, i really look forward to this.

I am too and you won't see it unless you have a cutomer that is
deployinug IPv6 in the world you live and I bet when you do or if you do
they are not waiting for this list here.  My comment to Rob is that
these are valid deployment statements and they are being seen by
industry too.  I would also argue very normal deployment issues for any
technology. Not show stoppers though.

> 
> > Also key management is not a problem for many users with 
> IPsec if they 
> > own the network and the PKI within their Intranet or Fully-Owned 
> > Internet.
> 
> this will be a great relief to all those folk going through 
> key management hell with ipsec.

Hey life is tough isn't it.  The PKI for the roaming Internet is a
problem.  But that user is minimal compared to the others.  Knowing you
I will say I am not saying that does not make the Internet user not an
important PKI problem to solve.  Just that its not a problem in most
industry scenarios where control is maintained for IPv6 deployment.

> 
> jim, we're from engineering, not marketing.  and so are you.  
> give us a break.

Now that was nasty OK.  Just so you know.  Now I will be nasty.

I deleted what I wanted to say to you but will recall it maybe next time
I see you in person.

I deal with reality not abstractions holding up the evolution of the
Internet planet that is our disconnect always in the IETF on work and my
disconnect with many here. Look I don't care for your view at all nor
you for mine, we are opposed on the most basic principles that lead us
to our technical assumptions and fixes that is just a fact.  The point
is if something is being deployed which is all I was saying we cannot
wait for the IETF time-to-market issues we all know we have here
currently.  But in this case deployment would have happened anyway so
not the IETF's fault in this case.

> 
> these are non-trivial issues.  they need to be actually 
> addressed. they can be.  but not by pretending they're already solved.

Never said they should not be addressed or solved in standard manner
that was your subjective superiority putting your brain on me.  My input
was to Rob and this list that we see this in deployment of IPv6 and it
has to be addressed now in addition to whatever happens here.  I will
present representative solutions I have seen work if this becomes a
technical operational discussion for sure.

You want to be nasty and attack come to my training school your a
neophyte I will give you lessons you have never seen.  You poke my eye I
poke both your eyes.  Just remember that if we  to continue to be nasty.
We can also take it off the list and resolve offline, your call not
mine.

You want to be professional that is great lets get some work done to
adddress this issue, but my view will be to not reinvent the world and
hold up progress or the market and that is what an engineers job is as
opposed to a computer scientist which I am not.

/jim
> randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 14 Aug 2003 21:45:57 -0700

> industry too.  I would also argue very normal deployment issues
> for any technology. Not show stoppers though.

ah, then we are not far from agreement, though a bit violently, at
least for my taste (but i was brought up by an uncle who was a
pacifist in ww2).

like too much of our work, the world is far more complex than it
used to be.  what are "normal deployment" issues today can be a
bit more daunting than those of a few years back, e.g., we used
not to consider security at all.  so what we are trying to do
today is being examined using criteria which are more stringent
than in previous technology deployments.

so i am not as sanguine about how easy it is and will be than you
seem to be.  but the proof will be in the pudding, eh?  so best to
go about making the pudding.

randy