[arin-ppml] ARIN-prop-172 Additional definition for NRPM Section 2 - Legacy Resources

Astrodog astrodog at gmx.com
Thu Jun 7 14:24:41 EDT 2012


On 6/7/2012 9:28 AM, Martin Hannigan wrote:
> On Wed, Jun 6, 2012 at 10:58 PM, Astrodog <astrodog at gmx.com> wrote:
>> On 6/6/2012 4:13 PM, Owen DeLong wrote:
> [ clip ]
>
>> Not to beat a dead horse, but the community consensus seems to very
>> clearly be that number resources are not property, and service is not
>> guaranteed for those organizations which do not have an agreement with
>> the relevant RIR. The service is, instead, provided on a best effort
>> basis in the interests of making life easier for everyone involved.
>
> I'm pretty sure that consensus against is not representative. We have
> a vocal few who repeatedly bang on the drum, and an extremely large
> and silent minority. We know this by the volume of transfer that ARIN
> sees, the strong interest by the APNIC folks and their members, the
> bankruptcy activity and the fact that we've had at least four
> companies create an industry around specifically dealing with IPv4
> transfer and markets. At the end of the day, consensus is extremely
> difficult to judge on this topic and I think that most understand
> this.
>
>
I think the more notable bit here is that, even assuming allocations
from ARIN *are* property or an asset, in the case of legacy holders ARIN
is not legally bound to support them, nor am I aware of anything that
would legally preclude the re-issuance of those addresses. ARIN simply
doesn't have any legal obligations to the legacy holder, and the legacy
holder doesn't have any legal obligations to ARIN. By definition (both
yours, and my suggested simple one) legacy holders do not have an
agreement with ARIN.

Instead, the situation we have now is one where ARIN has elected to,
largely, support legacy allocations as a matter of convenience, and
legacy holders update PoC information and the like with ARIN for the
same reason. Having that information available is clearly in the
interests of both the community and the legacy resource holder. Neither
party is actually obligated to participate in that interaction, and in
the case of abandoned legacy blocks, neither party does.

As someone who supported the proposal to remove needs requirements on
8.3 transfers, and who actively participated in how that discussion
played out last time, I think it's very clear that the ARIN community is
opposed to the idea of allocations as property. If there is a... silent
majority that believes otherwise, but elects not to participate in the
process, then they are doing themselves and ARIN a great disservice.

My only significant opposition to 172 itself, though relates to section
2's requirement that an allocation must have been relinquished by a
written agreement, not just going forward, but in the past as well. From
John's comments, it appears that this requirement is incompatible with
the actual state of affairs, and that legacy holders have relinquished
address space in a number of ways, ranging from written agreements, to
phone calls. Presumably, those returned resources have been or can be
re-allocated as well. Under your proposed definition, this creates a
situation where the new user of this space is, technically, a legacy
address holder, as the space was issued prior to Dec. 22, 1997 *and* the
original legacy holder has not relinquished its registration with a
written agreement.

A question that arises for John is what this situation would mean for
ARIN legally? Do you have any estimates as to how many allocations it
would apply to, and if those allocations have been re-issued? What about
present holders of this space, would this definition override their
interests in the allocation? Also, presumably, this would require ARIN
to go back to these organizations and attempt to obtain a written
agreement. Is that even possible in all cases? (If the entity went
bankrupt and returned the allocation 10 years ago... who would ARIN even
go to in an attempt to obtain written consent?)

Still opposed as written, though mainly due to that retroactive requirement.

--- Harrison



More information about the ARIN-PPML mailing list