[arin-ppml] Do people see a middle ground?

[Chris Grundemann]

On Sun, Aug 1, 2010 at 22:06, Alexander, Daniel
<Daniel_Alexander at cable.comcast.com> wrote:
>
> Not too long ago there were policy discussions about rationing the last of
> the IP resources allocated to ARIN. Many were opposed to this. The general
> opinion was that organizations should not be denied needed resources now,
> for something that may be needed later. Then some found a compromise in
> section4.10.
>
> Then there are proposals that suggest parking resources for the future
> because we cannot be sure what the situation will be two years from now.
> These topics were met with opposition against denying known, current needs
> for unknown circumstances in the future.
>
> Finally, there are the discussions about rationing the last bits of IPv4
> space by defining what technologies are worthy of receiving the last of the
> unallocated IPv4 resources.
>
> So a couple questions come to mind.
>
> Of all the methods being discussed, aren’t they just rationing in one form
> or another? If so, they why don’t we simplify the conversation and ration
> the last of the IP space by size and timeframe without all the requirements
> on an organization that add to the overhead of ARIN staff? Wouldn’t the end
> result be the same?

I don't think it would be the same. They key difference in the
proposals currently on the table and pure rationing (with no technical
requirements) is the focus on transitioning to IPv6.

> Should ARIN be defining topologies or technologies for an organization? Many
> argued strongly in the past against this direction. How much will really be
> accomplished fine tuning the use of the last 0.4% of the IPv4 space compared
> to how the other 99.996% is being used?

ARIN should not define topologies or technologies, no. But... If ARIN
is going to restrict a block of addresses to "transitional
technologies" than it probably makes sense to define or at least
explain through example what is meant by "transitional technology."
Defining a term is not quite the same as defining the specific
technology or topology to be used. Also - the fight against ARIN
getting involved in operational matters is a valid one but not one
that we can take to either extreme. As has also been discussed many
times before, minimum and maximum allocations and assignments define
operational practices to some extent, as does efficient utilization
requirements, needs based justification, etc. There is a balance that
must be maintained, not an absolute law to be followed. Internet
stewardship should be the guiding beacon, and sometimes that means
dipping our toes into issues that have effects on operational
practice.

To your second point; I would reverse the question: How much will we
gain by allowing the last 0.4% of the IPv4 space be used just like the
other 99.996%? Once we level set, then we can ask how much can we gain
by tweaking the use of that same space. In that context, I think it is
clear that the bigger win is in tuning the use, rather than taking our
hands off the wheel.

> Are some forms of rationing more acceptable than others? I’m curious if
> there are some who are opposed to outright rationing but find putting
> requirements on technologies as an acceptable middle ground? What do they
> feel is the difference or the compromise?

The goal is not to slow the usage of the last piece of unallocated
IPv4 space (rationing), the focus is on leveraging that last piece to
accelerate the adoption of IPv6 and the (re)homogenization of the
Internet (technical restrictions).

$0.02
~Chris

> Please let me know your thoughts.
> Dan Alexander
> ARIN AC
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org