[arin-ppml] ARIN-prop-165 Eliminate Needs-Based Justification

Astrodog astrodog at gmail.com
Mon Feb 20 07:45:21 EST 2012


On Mon, Feb 20, 2012 at 6:12 AM, John Curran <jcurran at arin.net> wrote:
> On Feb 20, 2012, at 5:28 AM, Astrodog wrote:
>
>> Personally, I agree with this assessment. However, it isn't how most
>> registrants view things.
>>
>> If the assertion is that IPs are *not* an asset, it seems like ARIN
>> should be reclaiming the space. If someone doesn't need the space
>> anymore (and, thus, starts looking for a buyer under 8.3), this would
>> seem like prima facae evidence that they no longer meet the need
>> requirements anyway.
>
> "IPs" are an ambiguous reference.  If the question is whether Internet
> numbers are freely held personal property, then ARIN's answer is "no".
> Address holders do have certain rights (such as exclusive right to be
> the registrant of the address space within the ARIN registry database,
> as well as the exclusive right to transfer the registration of the space),
> but those rights intersect other rights (e.g. the community's right of
> visibility to the public portion) with respect to the same registrations.
> The policies adopted in the region are the basis by which we will manage
> the registry and hence the intersection of these rights.
>
> Rights can be often be considered an asset of an estate but that does not
> mean that the underlying item is a form of "free and clear" property, only
> that something (often limited in nature) has been transferred.
>
>> Is there community support for the elimination of 8.3 transfers
>> entirely, to be replaced with a more aggressive audit system for need
>> testing, post-registration, so that the space may be reclaimed?
>
> This has been considered over the years, but does not fit well with ARIN's
> formation, wherein ARIN indicated that the existing registrations at the time
> would be maintained per the status quo. Now, it's recognized that you can't
> both form an organization for the management of number resources in the region
> via community developed policy, and simultaneously not ever change policy for
> existing registrations, but we'll actually done a reasonable job of striking
> exactly that balance.
>
> Changes which affect the entire registry (e.g. establishment of policies
> governing visibility and fields within registrations) have been adopted
> without significant issue.  Policies which add new functions (such as the
> specified transfer policy) have also been adopted and effectively expand
> on the options available to all resource holders.  We have worked hard not
> to create policy of undue burden, but will and do change existing policy
> for all number resources holders when it becomes important to do so in
> further of the mission (e.g. addition of abuse POC, POC validation etc.)
>
> The community could consider a policy for audit and reclamation of resource
> holders, however, it would not been in keeping with the expectations set
> for existing resources holders when ARIN was formed, and protection against
> reclamation for lack of utilization was put in the legacy RSA specifically
> to recognize this fact.  Recently, in recognition that a functional market
> provides adequate incentive for getting underutilized resources back into use,
> this same language which precludes reclamation due to lack of utilization was
> put into the standard RSA (thus leaving very few actual differences between
> the terms of the agreements.)
>
> You indicate that "this isn't how most registrants view things", but I would
> disagree; we've seen significant use of the specified transfer policy to date
> (particularly as ARIN still has available IPv4 number resources to issue) and
> nearly every service provider in the region has contractually agreed to the
> number resource policies developed by the community.  I am aware that some
> parties who haven't been receiving new number resources over the proceeding
> years (and hence aren't necessarily under an ARIN RSA of any form) are unhappy
> with the limitations for monetization of their underutilized resources under
> the present specified transfer policy; I universally direct them to this forum
> (the Public Policy Mailing List) to raise their concerns.

I think I may have been unclear. I was referring to registrants
viewing the allocation as an asset, not simply listing in a registry.
(Though, that is what they actually have)

More fundamentally, I believe that needs testing 8.3 transfers, while
having specific language in the RSAs that preclude reclaimation of
unused resources is not consistent. If allocation really is meant to
be driven by need, then reclaimation of unused resources seems to be a
fundamental piece. As it stands now, the combination of policies
rewards a combination of I.T. / Legal savvy, and requesting as much in
the way of resources as one can possibly get away with, regardless of
how those resources will be actually be allocated within an
organization. As IPv4 nears exhaustion, I believe the community is
going to be faced with a difficult choice regarding needs-based
allocation.

"New" organizations will have a more difficult time post-exhaustion
than their competitors who may have entirely unutilized assignments,
merely because their competitors recieved an allocation for an
entirely unrelated, and for the purposes of this hypothetical
eventually non-viable, use. I don't see the purpose in adding yet
another disadvantage for those entities.

If the community consensus is to allocate based on need, then I
believe policy for reclaimation should be adopted. If the community
consensus is to treat IP allocations as an asset, then needs testing
seems to be an undue and potentially anti-competitive burden on those
seeking allocations and something that will result in less
utilization.

I'm not opposed to either set of policies, but the current mix seems
to strongly favor existing users of space. I think the fundamental
question is "Are internet number allocations an asset?".

Sorry for beating what is, I suspect, a very dead horse,

--- Harrison



More information about the ARIN-PPML mailing list