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

[Tony Hain]

David Farmer wrote:
> >> ...
> >> Is that what you are saying?
> >
> > Yes. The point is that everyone has to meet current ARIN policies when
> > making a new request.
> >
> > Where past resources were acquired, or where they are deployed
> > globally are irrelevant, as long as the requestor is doing 'proper
> > stewardship'; where 'proper' is defined by current criterion
> > established at the RIR they are asking to provide more. To me, this is
> > the only way to avoid policy conflicts, and deal with pre-RIR
> > resources fairly. If the RIR system had not been created, this is
> > exactly what they would have to do at IANA, so why should the RIR
> mechanism be any different?
> 
> OK, I think I get what your saying now, thanks for your patience in
helping me
> work through it.
> 
> I believe, that essentially says you can only have your global future
demand
> or allocation window from one RIR at a time and you can't get anything
from
> another RIR until you have used up you current allocation window to the
> extent required by the next RIR you decide to get
> resources from.   That works for fine for IPv6 with the single global
> aggregate model that X.2 is going after.
> 
> However, there are others that wish to get IPv6 resources and receive an
> allocation window from each RIR to aggregated regionally to those RIRs, or
> have regionalized allocation windows.  Should that model be allowed?
>   Would it be OK with this model to restrict their forward looking demand
or
> allocation window that can be received from a particular RIR, base on the
> resources used within the region, but received from which ever RIR?
> Basically, don't restrict how they are actually use, but restrict the
scope of
> past use can be used to justify the additional of resources to your
allocation
> window from an individual RIR.
> 
> Said another way;  You can have a single global allocation window from one
> RIR (or only one RIR at a time at least).  Otherwise, you can have
multiple
> allocation windows, one from each RIR.  In such a case, each allocation
> window is only based on future needs within each RIR's region and
justified
> only by previous usage within the region.  If, you use previous resources
> outside the region they don't count toward justifying your future in
region
> need in this model.  That doesn't say you can't use them out of region but
if
> you do, the out of region use detracts from the size of your next
allocation
> window.
> 
> Could something like that work conceptually?  Or, are you saying that we
> shouldn't allow regionalized allocation windows at all?

I don't see how it works in practice, because there is no way to police it.
I understand the desire to have regionalized resources, and how that can
make many deployments simpler. What I don't see is how an RIR is in a
position to police where a resource gets deployed. The justification
documents can show in-region use, but the separation between assignment and
operations allows the recipient to move the resources anywhere at any time. 

If you can figure out some language that allows staff to make consistent
judgments about regionalized deployments, I can live with that, but I am
skeptical. If someone came in with deployments A,B,C,D,&E, stating that A
has resources from RIR-A meeting policy V, B has resources from RIR-B
meeting policy W ... now requesting resources for E from RIR-E meeting
policy Z, (and there was a background check process in place to verify that
what is claimed is what was used at the other RIRs) that would be easy
enough for staff to deal with and create a document trail about why an
action was taken. Where it breaks down is that the pace of change is faster
than processes can deal with, so in real deployment it is never as clean as
the documented justification. I am not suggesting people are intentionally
bypassing policy, just that the best intentions are rarely the outcome. 

Once you get into the messy real-world, it is very difficult to weed out
those who are intentionally bypassing policy from those that are simply
victims of process delays. Developing a policy that can't be enforced may
put a feel-good feather in someone's cap, but it does nothing but create an
impossible situation for staff. At the end of the day it would appear to be
cleaner to have every RIR evaluate global deployed resources against local
policy every time. Once resources are assigned you can't reasonably police
where they are used, so don't even pretend to try.

Tony


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