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

David Farmer farmer at umn.edu
Sat Jul 14 20:02:31 EDT 2012



On 7/14/12 17:32 CDT, Tony Hain wrote:
> Owen DeLong wrote:
...
>> However, what we want to avoid primarily with this policy is RIR policy
>> shopping and/or efforts by members of the other RIRs to essentially
>> circumvent their policies by effectively transferring space into those
> regions
>> outside of the control of those RIRs.
>
> RIR shopping A) is not a real problem because the result is not as
> disastrous as people speculate;  B) is not going to be stopped by
> unenforceable policies;  C) is an absurd necessity because the RIR
> memberships have forgotten that they are tasked as 'local facilitators' to
> -- distribute the resources --  on behalf of IANA.  The RIRs are not
> resource tsar's, they are stewards. The entire concept of 'outside the
> control' has no place in this conversation.
>
> The only thing the RIRs need to be watching for is duplicate requests to
> fulfill the same deployment. If someone is a member of all 5 RIRs, does not
> acquire excess resource by using the same need in more than one request, and
> conforms to the policy where the request is made, it is not anyone's
> business how that gets deployed.

I'm glad you agree we need to prevent duplicate and/or overlapping 
requests. So, your not asking for the "most liberal regional hierarchy" 
that was described in the Rationale, or at least you seem agree it needs 
some constraints on it at least.

However, there are criteria that I'm told the global Internet community 
wants as well;

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

In addition to;

3. Prevent duplicate and/or overlapping requests to multiple RIRs, in 
other words stewardship (that you identified)

Tony, in your opinion are these all requirements?

So when you combined those, one of the easiest solutions to identify, 
understand, and explain to others, is to regionalize.

If you only receive resources from an RIR for use in that region you 
meet all of those requirements, this is essentially X.1.  There are 
other solutions as well; Getting resource only from the region you are 
HQed in works too, this is essentially X.2. (Actually, ARIN-Prop-178 is 
a hybrid approach of the two, with fuzzy boundaries and some additional 
flexibility created with Incidental Use)

Without some kind of regional hierarchy as a tool to control the 
overlap, wouldn't you need to justify your total global use of resources 
from all RIRs to each RIR every time you want additional resources?  And 
if you do that by which polices does an RIR evaluate that global use its 
own, or the policies of the RIR that the resources were received?  And, 
How do you resolve the conflicts?

Personally, I'm willing to consider something like that and tried for 
several months to come up with language that had any hope to make that 
work, but couldn't.  it always fail at least one of the three 
requirements above.  Honestly, I never really got close either.   Do you 
have ideas?  Are any those requirements invalid?

I'm not ignoring the rest of what you said, but I have to think about it 
more.

But what I think your saying is there is another requirement;

4. No restriction on location of use

And I'm not seeing a solution set for those four requirements.  I 
believe we can have #1 & #2, with #3 or we can have #1 & #2, with #4, 
but I don't see how to have #1 & #2 with both #3 & #4.  Honestly, I 
think splitting IANA up into the RIRs and giving them local policy 
control necessarily creates a requirement for restriction on location of 
use.

Help me think of another way please.

Thanks
-- 
===============================================
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