[arin-ppml] ARIN-prop-178 Regional Use of Resources

David Farmer farmer at umn.edu
Sun Jul 15 13:32:03 EDT 2012

On 7/14/12 17:32 CDT, Tony Hain wrote:
> Owen DeLong wrote:
>> On Jul 14, 2012, at 10:07 AM, Tony Hain wrote:
>> This proposal applies to ASNs and IPv6 resources as well as IPv4.
> As it should, but there is still no justification for language that attempts
> to restrict where a resource is used. It is the height of hypocrisy to tell
> ARIN members that they cannot claim property rights over the assigned
> resources, yet ARIN has the ability to assert property rights by restricting
> where an asset gets used. The steward role requires ARIN to watch for
> duplicate requests to other RIRs for the same need, but the facilitator role
> requires them to -- actually distribute -- the resources. When the only
> intent of proposed language is to prevent distribution of resource because
> someone outside the ARIN region might benefit, it has to be called out and
> removed as counter to ARINs role as facilitator on behalf of IANA for the
> global resource.
> As long as a member makes a justified request, and is not duplicating that
> to get more from other RIRs, where that resource gets deployed is their
> issue alone. Besides, no matter what policy is put in place it is
> unenforceable because any resource that gets allocated can be moved later
> with a 'change of business requirements', and what justifies attempting
> reclamation? Unless you plan to make every operating network renumber all AS
> & address resources to be compliant with a regional restriction, there is no
> 'need' to do so for new deployments; meaning any such policy would not
> withstand a challenge. The only plausible justification for attempting a
> protectionist region restriction is hoarding to retain what little pool is
> left, in a hypocritical contortion of property rights.
> RIPE will exhaust their remaining IPv4 pool in a couple of  months, so the
> pressure to do something will increase. Unfortunately people will more often
> do the irrational thing under pressure, and this protectionist language is
> already starting down that road. Raising the threat of 'shell companies
> subverting RIR control' only furthers the irrational behavior.

OK, I slept on it and have an idea.

I need to reiterate the four requirements I discussed in my last email;

1. Regional independence and control of policy

2. Only justify the use of resources to the RIR you received them from 
using that RIRs policies

3. Prevent duplicate and/or overlapping requests to multiple RIRs, in 
other words provide stewardship

4. No restriction on location of use

So, I'll float an idea.  What if we allowed the requester to select 
between #2 or #4, allowing #1 and #3 to be meet in all cases.  This way 
regionalization is simply a tool for simplifying justification of need 
and not necessarily a requirement to receive resources in all cases.

This could be done with the following small rewrite of the first paragraph.


X. Regionalized Use of Resources

Requests for number resources must meet the following criteria regarding 
regionalized use of resources for ARIN to only evaluate a request based 
on an organizations ARIN registered resources and according to ARIN 
policies, including any resource specific criteria. Otherwise, ARIN must 
evaluate a request based on an organizations total globally registered 
resources and only according to ARIN policies, including any resource 
specific criteria.


Is this workable?  What do you think Tony?  What does the rest of the 
community think?  Would there need to be additional criteria defining 
how ARIN evaluates a organizations globally registered resource?

Like I said I'm just floating an idea, I'm not even sure I like it yet.

Let me know what you think.

David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952

More information about the ARIN-PPML mailing list