<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>
<BR>
I support this petition for Proposal 116.<BR>
<BR>
Martin Hannigan<BR>
OrgID: Akamai<BR>
8 Cambridge Center MS/926-G<BR>
Cambridge, MA 02142<BR>
<a href="marty@akamai.com">marty@akamai.com</a><BR>
<BR>
<BR>
On 8/4/10 12:40 AM, "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'>My intent in 116 was not so much to create a list as to use a list of examples<BR>
as the best tool I had available for defining the functionality and depend on<BR>
staff discretion beyond that. Hence the unfortunately vague choice of terms<BR>
like "etc." and "technologies not envisioned at the time of this proposal".<BR>
<BR>
I certainly would be happy to amend 116 if anyone has better ways to specify<BR>
this.<BR>
<BR>
FWIW, by my count, only 2 more signatures are needed in order for 116 to<BR>
see discussion in Atlanta. There is still time to sign the petition.<BR>
<BR>
Even if you do not feel that 116 as currently written is the best policy we can get,<BR>
discussing 116 in Atlanta is likely the only chance to do something other than<BR>
the current state of 4.10 prior to runout. I am extremely amenable to making<BR>
reasonable changes to 116 in order to gain broader community support.<BR>
<BR>
Owen<BR>
<BR>
On Aug 3, 2010, at 7:33 PM, Alexander, Daniel wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>I'll try and make this one of the last questions.<BR>
<BR>
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?<BR>
<BR>
-Dan<BR>
<BR>
</SPAN></FONT><FONT SIZE="2"><FONT FACE="Tahoma, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:10pt'><B>From:</B> Owen DeLong [<a href="mailto:owen@delong.com">mailto:owen@delong.com</a>] <BR>
<B>Sent:</B> Monday, August 02, 2010 11:16 PM<BR>
<B>To:</B> Alexander, Daniel<BR>
<B>Cc:</B> <FONT COLOR="#0000FF"><a href="arin-ppml@arin.net">arin-ppml@arin.net</a><BR>
</FONT><B>Subject:</B> Re: [arin-ppml] Do people see a middle ground?<BR>
</SPAN></FONT></FONT><FONT FACE="Times New Roman"><SPAN STYLE='font-size:12pt'> <BR>
4.10 currently does nothing to define what is a "transitional technology".<BR>
<BR>
Arguably, addresses for dual-homed hosts could be called a "transitional technology".<BR>
<BR>
NAT64/IVI/etc. gateways serving a single residential customer could arguably be called a<BR>
"transitional technology".<BR>
<BR>
The reality is that if we allow such uses, there's no set-aside because these "uses" are<BR>
essentially identical to the current "business as usual" (residential customers generally<BR>
get a single IPv4 address today, for example).<BR>
<BR>
Staff has stated that 4.10 is too vague to implement effectively.<BR>
<BR>
When 4.10 was adopted, I recall the discussion both on PPML and at the microphones<BR>
expressly including an expectation that clarifying language for how to use the /10 would<BR>
be generated as we got closer to need. Atlanta may well be the last public policy meeting<BR>
prior to need. As such, I think it is important that we at least bring something to the floor<BR>
for discussion there.<BR>
<BR>
Owen<BR>
<BR>
On Aug 2, 2010, at 6:58 PM, Alexander, Daniel wrote:<BR>
<BR>
<BR>
</SPAN></FONT><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" <<FONT COLOR="#0000FF"><a href="owen@delong.com">owen@delong.com</a> <x-msg:<a href="//2052/owen@delong.com">//2052/owen@delong.com</a>> </FONT>> wrote:<BR>
<BR>
<BR>
</SPAN></FONT><FONT FACE="Helvetica, Verdana, Arial"><SPAN STYLE='font-size:12pt'><BR>
</SPAN></FONT><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 [<FONT COLOR="#0000FF"><a href="mailto:cgrundemann@gmail.com">mailto:cgrundemann@gmail.com</a></FONT>]<BR>
> Sent: Monday, August 02, 2010 10:27 AM<BR>
> To: Alexander, Daniel<BR>
> Cc: <FONT COLOR="#0000FF"><a href="arin-ppml@arin.net">arin-ppml@arin.net</a> <x-msg:<a href="//2052/arin-ppml@arin.net">//2052/arin-ppml@arin.net</a>> <BR>
</FONT>> Subject: Re: [arin-ppml] Do people see a middle ground?<BR>
><BR>
> On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel<BR>
> <<FONT COLOR="#0000FF"><a href="Daniel_Alexander@cable.comcast.com">Daniel_Alexander@cable.comcast.com</a> <x-msg:<a href="//2052/Daniel_Alexander@cable.comcast.com">//2052/Daniel_Alexander@cable.comcast.com</a>> </FONT>> 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 (<FONT COLOR="#0000FF"><a href="ARIN-PPML@arin.net">ARIN-PPML@arin.net</a> <x-msg:<a href="//2052/ARIN-PPML@arin.net">//2052/ARIN-PPML@arin.net</a>> </FONT>).<BR>
>> Unsubscribe or manage your mailing list subscription at:<BR>
>> <FONT COLOR="#0000FF"><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><BR>
</FONT>>> Please contact <FONT COLOR="#0000FF"><a href="info@arin.net">info@arin.net</a> <x-msg:<a href="//2052/info@arin.net">//2052/info@arin.net</a>> </FONT> if you experience any issues.<BR>
>><BR>
><BR>
> --<BR>
> @ChrisGrundemann<BR>
> <FONT COLOR="#0000FF">weblog.chrisgrundemann.com <<a href="http://weblog.chrisgrundemann.com/">http://weblog.chrisgrundemann.com/</a>> <BR>
</FONT>> <FONT COLOR="#0000FF">www.burningwiththebush.com <<a href="http://www.burningwiththebush.com/">http://www.burningwiththebush.com/</a>> <BR>
</FONT>> <FONT COLOR="#0000FF">www.coisoc.org <<a href="http://www.coisoc.org/">http://www.coisoc.org/</a>> <BR>
</FONT>> _______________________________________________<BR>
> PPML<BR>
> You are receiving this message because you are subscribed to<BR>
> the ARIN Public Policy Mailing List (<FONT COLOR="#0000FF"><a href="ARIN-PPML@arin.net">ARIN-PPML@arin.net</a> <x-msg:<a href="//2052/ARIN-PPML@arin.net">//2052/ARIN-PPML@arin.net</a>> </FONT>).<BR>
> Unsubscribe or manage your mailing list subscription at:<BR>
> <FONT COLOR="#0000FF"><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a><BR>
</FONT>> Please contact <FONT COLOR="#0000FF"><a href="info@arin.net">info@arin.net</a> <x-msg:<a href="//2052/info@arin.net">//2052/info@arin.net</a>> </FONT> if you experience any issues.<BR>
<BR>
</SPAN></FONT><FONT FACE="Times New Roman"><SPAN STYLE='font-size:12pt'> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>