Chiming in here -

Eric, you made this as a suggestion at the mic at ARIN56 as well (adding 
language that stated most space had to be used in region.)

As the shepherd at the time with Gerry, we heard your suggestion and evaluated 
its viability to add to the policy but found it to have too many significant 
secondary implications. Tom’s response accurately captures the same 
understanding we came to.

It may not have been clear looking at the AC minutes (I just checked) that we 
heard and reviewed what you had brought forward, so I apologize for a gap in 
that information flow on our part.

Hope that helps -


Doug

--
Douglas J. Camin
Vice Chair, Advisory Council
[email protected]
From: ARIN-PPML <[email protected]> on behalf of Tom Fantacone via 
ARIN-PPML <[email protected]>
Date: Wednesday, March 18, 2026 at 1:53 PM
To: Eric C. Landgraf <[email protected]>
Cc: arin-ppml <[email protected]>
Subject: Re: [arin-ppml] Request for Comment & Feedback: Draft Policy 
ARIN-2025-3: Change Section 9 Out Of Region Use Minimum Criteria

On Mar 18 13:08, [email protected]<mailto:[email protected]> 
wrote:
Date: Wed, 18 Mar 2026 13:08:20 -0400
From: Eric C. Landgraf <[email protected]<mailto:[email protected]>>

>Should we rewrite the policy to allow any amount of out-of-region use so
>long as it is less than or equal to in-region use? (Obviously the usual
>needs-based rules also apply). In practice, this means if you use a /24
>in-region you can use up to a /24 out-of-region; for v6 that would
>probably be a /48 in and out-of-region. Personally, I don't even care
>what the limits are: if you want to use a directly-allocated /32 of v4
>space out-of-region instead of going through an LIR, that is up to you
>(provided your transit provider will accept the route and all).
>
>Using more addresses/prefixes in-region than out-of-region seems like
>sufficient evidence of "real and substantial connection with the ARIN
>region" and is far better than arbitrary length-based rules.

Eric,

The concept of restricting out-of-region use so that it's less than or equal to 
in-region use is interesting, and I suspect (but don't know) that this kind of 
scheme was considered during the initial drafting of the existing out-of-region 
use policy.

It does open a can of worms, however, in that for most organizations it's a far 
more restrictive policy than the active one, while the proposed policy is 
slightly less restrictive than the active one.  That doesn't mean we shouldn't 
consider it, but we should be aware of the ramifications.

Under current policy, as long as an organization has a /22 of ARIN space used 
in-region, they could have multiple large ARIN blocks used out-of-region.  The 
rewrite you're inquiring about would force those organizations to do some 
severe restructuring, and would most likely involve them having to join the 
other RIRs and transfer the space there.  There are large, multi-national 
organizations with a "real and substantial connection with the ARIN region" 
(i.e. headquartered here) but with large overseas data centers that require a 
lot more resources outside the ARIN region.  I think it's OK that these 
organizations get their resources from ARIN, pay their dues to ARIN, but use 
much of those resources wherever they need to.

Even under the current policy, it would be financially advantageous for these 
organizations to move all their space to RIPE, due to its flat-fee structure, 
but they choose not to because ARIN is their "home base".

I do like the proposed policy in that it has a very "light touch" and just 
addresses the issue of the discrimination against very small organizations 
under current policy without changing policy for everyone else.

Regards,
Tom Fantacone


_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to