
<HTML>

<HEAD>

<TITLE>Re: [arin-ppml] Do people see a middle ground?</TITLE>

</HEAD>

<BODY>

<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="owen@delong.com">owen@delong.com</a>> wrote:<BR>

<BR>

</SPAN></FONT><BLOCKQUOTE><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="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="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="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="info@arin.net">info@arin.net</a> if you experience any issues.<BR>

>><BR>

><BR>

> --<BR>

> @ChrisGrundemann<BR>

> weblog.chrisgrundemann.com<BR>

> www.burningwiththebush.com<BR>

> www.coisoc.org<BR>

> _______________________________________________<BR>

> PPML<BR>

> You are receiving this message because you are subscribed to<BR>

> the ARIN Public Policy Mailing List (<a href="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="info@arin.net">info@arin.net</a> if you experience any issues.<BR>

<BR>

<BR>

</SPAN></FONT></BLOCKQUOTE>

</BODY>

</HTML>