Hi Doug,
On 2026-09-25 14:41, Douglas Camin wrote:
I think there may be some confusion about what exactly that proposed
language is bringing about.
In the example you have built, you said that the change forbids you
from getting any space for out of region use. I don’t believe that
interpretation is correct. The language in this proposal only applies
to what resources you can use to count towards the required
justifications to receive the space under 4.1.8, 4.4, or 4.10. There
is no explicit prohibition on where to use that space (though,
separately Recommended Draft policy 2025-8 will modify 4.10 to
explicitly state it is to be used in the ARIN region.)
Since you are the vice chair of the ARIN Advisory Council, I assume your
understanding of the intention of what the policy is meant to accomplish
is correct. However, that intention differs from the way I understood
the policy.
Since I was able to come to a different interpretation of the policy
text, then it suggests that the policy text is poorly worded. After all,
if I can interpret it in such a way as to reject any request of IPv4
space for out-of-region use, then ARIN staff may interpret it
incorrectly down the line, which is a result that no one wants.
Now, let's look through your explanation of the practical changes:
For each section, here is the practical change as I can discern it:
4.1.8 Waitlist - As currently written, if you have a /20 or more of
space already, you would not be able to access the waitlist anyhow.
But, if you have less than that you are subject to the clause in
4.1.8.3 about other applicable policies, which takes you to 4.2.4.1
Utilization percentage (80%.) Currently, that /21 or below can be in
any region and still qualify for justification to get on the waitlist.
The new restriction will limit the justification to get on the
waitlist to being able to demonstrate an entity is using 80% of their
current allocations in the ARIN region (as opposed to their total
global allocation.)
Assuming that the section 9 changes are meant to specifically restrict
the 80% utilization percentage in 4.2.4.1 to count only the allocation
used in region, this makes sense. However, section 4.2.4.1 states, in
its entirety:
ISPs must have efficiently utilized all allocations, in aggregate, to
at least 80% and *at least 50% of every allocation* in order to
receive additional space. This includes all space reassigned or
reallocated to their customers.
It is not clear how that "at least 50% of every allocation" part isn't
restricted by the proposed language in section 9. If it is restricted,
then it becomes impossible to request additional space under the waiting
list as long as you have used any space out-of-region, which doesn't
seem like the intention. This is another source of confusion.
Furthermore, is this the only impact on the ability to use the waiting
list?
4.4 Micro-allocation - There is currently no written space-based
qualification criteria in 4.4 that is evaluated, the justification is
whether or not an entity is critical infrastructure, regardless of
their space usage and where it is located. The new restriction does
not explicitly appear to change the materiality of how to qualify and
would not currently impact this section.
Why is section 4.4 explicitly named in the policy text if it doesn't
have any material effect? It just adds to the confusion.
4.10 v4 -> v6 Deployment - 4.10 has criteria outlining who qualifies
but the only time a usage justification comes up is if you get less
than a /22 initially and wanted the remainder to be allocated later.
Bullet 3 says if you received smaller than a /22 (ie, /24) and wanted
more (ie, another /24) you have to demonstrate 80% usage of what you
have - so the new language would require that usage to be in the ARIN
region. That is a nominal change, because its unclear you could use
the initial /24 outside the region and obtain the next /24 anyhow. So
the new restriction does not explicitly appear to materially change
the initial qualification, but it could have a marginal impact on the
second step in an corner case scenario.
I agree that if the policy change only restricts subsequent allocations
for section 4.10, then this is unlikely to have any effect. In which
case, I also question the need to enumerate section 4.10 in the policy text.
To summarize all of the above (hopefully) succinctly: The language of
this policy proposal is speaking only to the criteria to justify
qualifying for sections 4.1.8, 4.4, and 4.10. This language will not
add restrictions to how you can utilize the space. The language will
have an impact on how entities can qualify for 4.1.8, and will not
have an impact on how they qualify for 4.4 or 4.10 space. The
additional language was added based on input from the community
requesting those clauses be added, and has been in line with the trend
in recent years to explicitly clarify that any remaining allocations
of v4 space from ARIN are expected to be used in the ARIN region.
These changes do not impact the ability of an entity to get space from
the transfer market and use it as they see fit.
Now that I fully understand your intentions behind the policy and
examples of how it should apply, I think this would be a clearer way of
framing the policy:
Modify the following text in Section 9:
FROM:
IPv4: At least a /22 used in region.
TO:
IPv4: At least a /24 used in region.
Modify the following text in Section 4.2.4.1:
FROM:
ISPs must have efficiently utilized all allocations, in aggregate, to
at least 80% and at least 50% of every allocation in order to receive
additional space.
TO:
ISPs must have efficiently utilized all allocations, in aggregate, to
at least 80% *inside the ARIN service region* and at least 50% of
every allocation in order to receive additional space. *Any requests
made when different rules were in effect remain valid.*
Per your analysis, this is the actual impact of the policy change, so we
might as well make the change where it matters, and not rely on spooky
action at a distance inside section 9.
Is this alternative version of the policy text materially the same per
your understanding? If so, I believe it to be a lot clearer than the
current policy and we should use this version instead.
Best regards,
Quantum
_______________________________________________
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.
