<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>John you were not the "sole network operator" on the
directorate.[1] And I'm not saying that there weren't arguments,
but I am saying that nobody said, “wait for something better.”
Rather, everyone was arguing for their preferred approach out of
the ones I mentioned.<br>
</p>
<p>Eliot<br>
</p>
<p>[1] <a class="moz-txt-link-freetext" href="https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94">https://www.sobco.com/ipng/directorate.minutes/bigten.5.19.94</a><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 16.09.21 14:10, John Curran wrote:<br>
</div>
<blockquote type="cite"
cite="mid:9927DE9C-3CE0-48A6-95C2-071544B870A6@istaff.org">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
On 16 Sep 2021, at 5:46 AM, Eliot Lear <<a
href="mailto:lear@ofcourseimright.com" class=""
moz-do-not-send="true">lear@ofcourseimright.com</a>> wrote:<br
class="">
<div>
<blockquote type="cite" class="">It's hard to argue that there
was no transition plan. There were in fact at least three
transition plans for the selected approach (dual stack, 6to4,
and tunneling) some of which have been discarded along the
way; while others came to be based on operational experience.
Moreover, the only way to really know that a transition
mechanism is really going to work is to let it out of the
lab. And ALL of the proposals would have suffered the very
same transition pains, because just as Jeroen has pointed out,
the pain stretched all the way to the application.<br class="">
</blockquote>
<div><br class="">
</div>
Eliot -</div>
<div><br class="">
</div>
<div>The requirement was not for the assertion of multiple
“transition plans”, but rather "The protocol must have a
straightforward transition plan from the current IPv4.”</div>
<div><br class="">
</div>
<div>"A straightforward plan” – singular. If you have a link to
that plan, please provide it, but until such time I’ll stay with
my understanding of events (that being that we completely
dropped the ball with regard to providing the operator community
with a meaningful transition plan.) <br class="">
<blockquote type="cite" class="">
<div class="">
<div class="content-isolator__container">
<div class="">
<p class="">I don't think it's reasonable to argue that
we should have waited for some other mythical better
proposal to come along. I don't recall anyone arguing
for that at the time, and there's no reason to believe
that such a mythical proposal would have ever come to
be in any foreseeable time frame. In fact Erik Fair,
Dave Crocker, Tom Kessler and I argued the very
opposite, that we were digging ourselves a hole with
NAT. Your argument at the time (Interop '95, Vegas)
was that the IETF didn't have the right to dictate
address usage to deployments. True enough, but then
people shouldn't hang their woes on the IETF.<br
class="">
</p>
</div>
</div>
</div>
</blockquote>
<div>Sorry, I was on the IPng Directorate, and there were indeed
arguments that we lacked meaningful transition strategy, and
that the fig leaf of shipping the responsibility off to
“to-be-defined” working groups was irresponsible. </div>
<blockquote type="cite" class="">
<div class="">
<div class="content-isolator__container">
<div class="">
<p class=""> </p>
<p class="">As I mentioned earlier, the fundamental
issue was that there were no ng proposals that were in
fact substitutable resources for v4, and NAT was.
From there, economics has ruled, arguments be damned.</p>
</div>
</div>
</div>
</blockquote>
<div class="">
<div class="content-isolator__container">
<div class="">
<div class="">As predicted - "As currently envisioned,
IPng may not be ambitious enough in the delivery of new
capabilities to compete against IPv4 and the inevitable
arrival of network address translation devices. In
order to meet the requirement for “viability in the
marketplace', IPng needs to deliver clearly improved
functionality over IPv4 while offering some form
transparent access between the IPv4 and IPng communities
once IPv4 address depletion has occurred.”</div>
<div class=""><br class="">
</div>
</div>
</div>
</div>
<div class="">
<div class="content-isolator__container">
<div class="">Sorry, but a<font class="" color="#000000">s
the sole “network operator” on the IPng Directorate who
lived through thru convenient papering over of the
transition requirement firsthand, I’ll</font> have to
concur with Randy Bush’s take on this one - </div>
<div class=""><br class="">
</div>
<blockquote type="cite" class="">
<blockquote type="cite" class="">
<div class="">"real compatibility with ipv4 was
disdained. the transition plan was dual stack and v4
would go away in a handful of years. the 93
transition mechanisms were desperate add-ons when v4
did not go away. and dual stack does not scale, as it
requires v4 space proportional to deployed v6 space."</div>
<br class="">
we are left to make the mess work for the users, while
being excoriated for not doing it quickly or well
enough, and for trying to make ends meet financially.”</blockquote>
</blockquote>
<br class="">
</div>
</div>
<div class="content-isolator__container">Anyone who wants to
argue that IPng had a viable transition plan best put a hard
link to the documented plan in their reply - trying to argue
the point without actually citing the alleged
“straightforward plan" is just embarrassing. </div>
<div class="content-isolator__container"><br class="">
</div>
<div class="content-isolator__container">Thanks,</div>
<div class="content-isolator__container">/John</div>
<div class="content-isolator__container"><br class="">
</div>
<div class="content-isolator__container">p.s. Disclaimer: my
views alone (although likely shared by many operators upon
hearing silence in response to the question: “Okay, how is
this transition really supposed to work?”) </div>
<div class="content-isolator__container"><br class="">
</div>
<div class="content-isolator__container"><br class="">
</div>
</div>
</blockquote>
</body>
</html>