<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple style='word-wrap: break-word;
-webkit-nbsp-mode: space;-webkit-line-break: after-white-space'>
<div class=WordSection1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>I'll try and make this one of the last questions.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Are there key functionalities that make a transitional
technology "acceptable" for most? Would the policy become more
flexible if it were written around this functionality, rather than trying to maintain
a list the technologies directly? <o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>-Dan<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<div>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Owen DeLong
[mailto:owen@delong.com] <br>
<b>Sent:</b> Monday, August 02, 2010 11:16 PM<br>
<b>To:</b> Alexander, Daniel<br>
<b>Cc:</b> arin-ppml@arin.net<br>
<b>Subject:</b> Re: [arin-ppml] Do people see a middle ground?<o:p></o:p></span></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>4.10 currently does nothing to define what is a
"transitional technology".<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Arguably, addresses for dual-homed hosts could be called a
"transitional technology".<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>NAT64/IVI/etc. gateways serving a single residential
customer could arguably be called a<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>"transitional technology".<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>The reality is that if we allow such uses, there's no
set-aside because these "uses" are<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>essentially identical to the current "business as
usual" (residential customers generally<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>get a single IPv4 address today, for example).<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Staff has stated that 4.10 is too vague to implement
effectively.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>When 4.10 was adopted, I recall the discussion both on PPML
and at the microphones<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>expressly including an expectation that clarifying language
for how to use the /10 would<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>be generated as we got closer to need. Atlanta may well be
the last public policy meeting<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>prior to need. As such, I think it is important that we at
least bring something to the floor<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal>for discussion there.<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>Owen<o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class=MsoNormal>On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote:<o:p></o:p></p>
</div>
<p class=MsoNormal><br>
<br>
<o:p></o:p></p>
<div>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><br>
Can we get some examples of how 4.10 can be circumvented. That might help the discussion
about how to close any loopholes. <br>
<br>
<br>
On 8/2/10 6:22 PM, "Owen DeLong" <<a
href="x-msg://2052/owen@delong.com">owen@delong.com</a>> wrote:<br>
<br>
<br>
</span><o:p></o:p></p>
<p class=MsoNormal style='margin-bottom:12.0pt'><span style='font-size:11.0pt;
font-family:"Calibri","sans-serif"'>So far, proposal 116 does not establish a
review panel and I remain<br>
unconvinced that doing so is the correct approach vs. leaving it to<br>
staff judgment guided by the BoT.<br>
<br>
I'm open to any suggestions on a better way to limit abuse, but, it was<br>
made obvious to by a number of people that 4.10 can be easily perverted<br>
into pretty much business-as-usual by the creative leaving no IPv4 addresses<br>
available for true cases of need in order to deploy IPv6. I would hate to see<br>
us end up in that kind of dead-lock because we failed to address and<br>
close a loophole in a policy that was passed with a general community<br>
understanding of "This is a good placeholder, we'll make it more specific<br>
when the time comes and we better understand the implications."<br>
<br>
While you could well argue that we still don't understand the implications<br>
significantly better than when 4.10 was enacted, I do not think it is possible<br>
to argue that the time has not come. Atlanta may well be the last public<br>
policy meeting prior to IANA runout. In fact, I will be very surprised if it is<br>
not.<br>
<br>
As such, I think it is very important to get something on the agenda for
Atlanta<br>
with the possibility of becoming policy, even if we need to tweak it<br>
in last call.<br>
<br>
Owen<br>
<br>
On Aug 2, 2010, at 2:22 PM, Alexander, Daniel wrote:<br>
<br>
> Thank you Chris and Owen for the replies. I think you articulated the<br>
> point better than I did. If we were talking about simply stretching out<br>
> the last pieces of IPv4 space, both rationing or the technical<br>
> requirements could probably be tweaked to accomplish the same thing. The<br>
> difference is the attempt to leverage the last pieces of IPv4 to<br>
> facilitate IPv6 deployments.<br>
><br>
> What I question is whether technology requirements are the proper knob<br>
> to try and turn. Will adding things like review panels and acceptable<br>
> lists of transition technologies actually achieve the objective of<br>
> getting IPv6 deployed, or will it just distract people to debate what<br>
> are acceptable methods in how to get there?<br>
><br>
> I am trying to understand the policy gap we are trying to fill here. How<br>
> will the current policy be abused that staff cannot manage? And will the<br>
> gains achieved in preventing this abuse really be offset by the addition<br>
> of review panels on what everyone deems "acceptable" transition<br>
> technologies.<br>
><br>
> Just adding my $.02 to your $.02. Soon we will be rich. :)<br>
> -Dan<br>
><br>
><br>
> -----Original Message-----<br>
> From: Chris Grundemann [<a href="mailto:cgrundemann@gmail.com">mailto:cgrundemann@gmail.com</a>]<br>
> Sent: Monday, August 02, 2010 10:27 AM<br>
> To: Alexander, Daniel<br>
> Cc: <a href="x-msg://2052/arin-ppml@arin.net">arin-ppml@arin.net</a><br>
> Subject: Re: [arin-ppml] Do people see a middle ground?<br>
><br>
> On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel<br>
> <<a href="x-msg://2052/Daniel_Alexander@cable.comcast.com">Daniel_Alexander@cable.comcast.com</a>>
wrote:<br>
>><br>
>> Not too long ago there were policy discussions about rationing the<br>
> last of<br>
>> the IP resources allocated to ARIN. Many were opposed to this. The<br>
> general<br>
>> opinion was that organizations should not be denied needed resources<br>
> now,<br>
>> for something that may be needed later. Then some found a compromise<br>
> in<br>
>> section4.10.<br>
>><br>
>> Then there are proposals that suggest parking resources for the future<br>
>> because we cannot be sure what the situation will be two years from<br>
> now.<br>
>> These topics were met with opposition against denying known, current<br>
> needs<br>
>> for unknown circumstances in the future.<br>
>><br>
>> Finally, there are the discussions about rationing the last bits of<br>
> IPv4<br>
>> space by defining what technologies are worthy of receiving the last<br>
> of the<br>
>> unallocated IPv4 resources.<br>
>><br>
>> So a couple questions come to mind.<br>
>><br>
>> Of all the methods being discussed, aren't they just rationing in one<br>
> form<br>
>> or another? If so, they why don't we simplify the conversation and<br>
> ration<br>
>> the last of the IP space by size and timeframe without all the<br>
> requirements<br>
>> on an organization that add to the overhead of ARIN staff? Wouldn't<br>
> the end<br>
>> result be the same?<br>
><br>
> I don't think it would be the same. They key difference in the<br>
> proposals currently on the table and pure rationing (with no technical<br>
> requirements) is the focus on transitioning to IPv6.<br>
><br>
>> Should ARIN be defining topologies or technologies for an<br>
> organization? Many<br>
>> argued strongly in the past against this direction. How much will<br>
> really be<br>
>> accomplished fine tuning the use of the last 0.4% of the IPv4 space<br>
> compared<br>
>> to how the other 99.996% is being used?<br>
><br>
> ARIN should not define topologies or technologies, no. But... If ARIN<br>
> is going to restrict a block of addresses to "transitional<br>
> technologies" than it probably makes sense to define or at least<br>
> explain through example what is meant by "transitional
technology."<br>
> Defining a term is not quite the same as defining the specific<br>
> technology or topology to be used. Also - the fight against ARIN<br>
> getting involved in operational matters is a valid one but not one<br>
> that we can take to either extreme. As has also been discussed many<br>
> times before, minimum and maximum allocations and assignments define<br>
> operational practices to some extent, as does efficient utilization<br>
> requirements, needs based justification, etc. There is a balance that<br>
> must be maintained, not an absolute law to be followed. Internet<br>
> stewardship should be the guiding beacon, and sometimes that means<br>
> dipping our toes into issues that have effects on operational<br>
> practice.<br>
><br>
> To your second point; I would reverse the question: How much will we<br>
> gain by allowing the last 0.4% of the IPv4 space be used just like the<br>
> other 99.996%? Once we level set, then we can ask how much can we gain<br>
> by tweaking the use of that same space. In that context, I think it is<br>
> clear that the bigger win is in tuning the use, rather than taking our<br>
> hands off the wheel.<br>
><br>
>> Are some forms of rationing more acceptable than others? I'm curious<br>
> if<br>
>> there are some who are opposed to outright rationing but find putting<br>
>> requirements on technologies as an acceptable middle ground? What do<br>
> they<br>
>> feel is the difference or the compromise?<br>
><br>
> The goal is not to slow the usage of the last piece of unallocated<br>
> IPv4 space (rationing), the focus is on leveraging that last piece to<br>
> accelerate the adoption of IPv6 and the (re)homogenization of the<br>
> Internet (technical restrictions).<br>
><br>
> $0.02<br>
> ~Chris<br>
><br>
>> Please let me know your thoughts.<br>
>> Dan Alexander<br>
>> ARIN AC<br>
>> _______________________________________________<br>
>> PPML<br>
>> You are receiving this message because you are subscribed to<br>
>> the ARIN Public Policy Mailing List (<a
href="x-msg://2052/ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
>> Unsubscribe or manage your mailing list subscription at:<br>
>> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
>> Please contact <a href="x-msg://2052/info@arin.net">info@arin.net</a>
if you experience any issues.<br>
>><br>
><br>
> --<br>
> @ChrisGrundemann<br>
> <a href="http://weblog.chrisgrundemann.com">weblog.chrisgrundemann.com</a><br>
> <a href="http://www.burningwiththebush.com">www.burningwiththebush.com</a><br>
> <a href="http://www.coisoc.org">www.coisoc.org</a><br>
> _______________________________________________<br>
> PPML<br>
> You are receiving this message because you are subscribed to<br>
> the ARIN Public Policy Mailing List (<a
href="x-msg://2052/ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
> Unsubscribe or manage your mailing list subscription at:<br>
> <a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
> Please contact <a href="x-msg://2052/info@arin.net">info@arin.net</a> if
you experience any issues.<br>
<br>
</span><o:p></o:p></p>
</div>
</div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</body>
</html>