<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">4.10 currently does nothing to define what is a "transitional technology".<div><br></div><div>Arguably, addresses for dual-homed hosts could be called a "transitional technology".</div><div><br></div><div>NAT64/IVI/etc. gateways serving a single residential customer could arguably be called a</div><div>"transitional technology".</div><div><br></div><div>The reality is that if we allow such uses, there's no set-aside because these "uses" are</div><div>essentially identical to the current "business as usual" (residential customers generally</div><div>get a single IPv4 address today, for example).</div><div><br></div><div>Staff has stated that 4.10 is too vague to implement effectively.</div><div><br></div><div>When 4.10 was adopted, I recall the discussion both on PPML and at the microphones</div><div>expressly including an expectation that clarifying language for how to use the /10 would</div><div>be generated as we got closer to need. Atlanta may well be the last public policy meeting</div><div>prior to need. As such, I think it is important that we at least bring something to the floor</div><div>for discussion there.</div><div><br></div><div>Owen</div><div><br></div><div><div><div>On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>
<font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt"><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>
</span></font><blockquote type="cite"><font face="Calibri, Verdana, Helvetica, Arial"><span style="font-size:11pt">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>
<br>
</span></font></blockquote>
</div>
</blockquote></div><br></div></body></html>