[arin-ppml] Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements

[Martin Hannigan]

ARIN also can't reclaim legacy resources. No op.

Agreed, another Internet cat video.

Best,

-M<

On Wednesday, July 23, 2014, Andrew Dul <andrew.dul at quark.net> wrote:

>  On 7/23/2014 3:00 PM, Scott Leibrand wrote:
>
>  On Wed, Jul 23, 2014 at 2:45 PM, Andrew Dul <andrew.dul at quark.net
> <javascript:_e(%7B%7D,'cvml','andrew.dul at quark.net');>> wrote:
>
>>
>> > On 7/23/14, 10:27 , ARIN wrote:
>> > ...
>> >> Recommended Draft Policy ARIN-2014-9
>> >> Resolve Conflict Between RSA and 8.2 Utilization Requirements
>> >>
>> >> Date: 23 July 2014
>> >>
>> >> AC's assessment of conformance with the Principles of Internet Number
>> >> Resource Policy:
>> >>
>> >> "This proposal enables fair and impartial number resource
>> administration
>> >> by eliminating conflicting language in the NRPM with the RSA. This
>> >> proposal is technically sound. The NRPM should not contain language
>> that
>> >> conflicts with the RSA. This proposal is supported by the community.
>> >> This proposal reflects current practice."
>> >>
>> >> Problem Statement:
>> >>
>> >> 8.2 transfer policy has utilization requirements at the time of the
>> >> review of the transfer request.
>> >>
>> >> The RSA section 6 expressly forbids ARIN from de-registering blocks (in
>> >> whole or in part) due to under-utilization or no-justification during
>> >> transfer requests.
>> >>
>> >> This is a direct conflict.
>> >>
>> >> Policy statement:
>> >>
>> >> Remove the words "aggregate" and "reclaim" from 8.2, so it reads:
>> >>
>> >> "In the event that number resources of the combined organizations are
>> no
>> >> longer justified under ARIN policy at the time ARIN becomes aware of
>> the
>> >> transaction, through a transfer request or otherwise, ARIN will work
>> >> with the resource holder(s) to return or transfer resources as needed
>> to
>> >> restore compliance via the processes outlined in current ARIN policy."
>> >
>>
>>  I do not support this draft policy as written.
>>
>> This current draft does not do anything substantive to fix the conflict
>> in the NRPM which exists because the RSA contractually obligates ARIN
>> not to reclaim address space for underutilization.
>
>
>  You are correct that the RSA contractually obligates ARIN not to reclaim
> address space.  That is why ARIN-2014-9 removes that word ("reclaim").
> Given that, I'm not sure why you say that this "doesn't do anything
> substantive to fix the conflict".
>
>
> ARIN today can't reclaim the space nor force an organization it to
> aggregate because of the RSA terms, so those two words being in the NRPM
> don't do anything.  So removing them doesn't do anything either, in my
> opinion.  The real issue is in the utilization requirement on 8.2 transfers.
>
>
>
>> The current 8.2
>> policy and this proposed draft change will still result in orphan blocks
>> with incorrect stale registry information even when legitimate network
>> mergers and acquisitions occur.
>>
>
>  Why do you say that?  Do you feel that when organizations acquire space
> via M&A, they will be afraid of ARIN working with them to voluntarily
> return or transfer unneeded resources, and will instead fail to tell ARIN
> about the transaction?  I understand that fear based on the current
> language (which threatens reclamation), but I'm having trouble
> understanding how that would remain a concern once all ARIN is directed to
> do is work with the resource holder to do something voluntary.
>
>
> Org A purchases Org B (and its network).  Org A asks ARIN to update Org
> B's records to show that Org A now owns Org B.  Org B's address space is
> vastly underutilized and Org A+B's combined growth doesn't meet current
> policy utilization requirements for Org B's netblocks.   The current 8.2
> policy prevents ARIN from updating Org B's netblocks to show that Org A now
> is the legitimate rights holder for Org B's netblocks because it doesn't
> meet the utilization requirements in 8.2.  Org A estimates it would take $x
> million dollars to migrate all the services currently scattered in Org B's
> netblocks into other blocks so that some blocks could be transferred or
> returned.  Org A gives up on the 8.2 transfer request, and thus we end up
> with Org B's records being orphaned with incorrect registration
> information.   Someone from Org A continues to pay the maintenance or
> membership fees for Org B (if its not legacy non-LRSA) and the registry
> records continue to _not_  show Org A as the legitimate rights holder for
> Org B's netblocks.
>
>
>
>>
>> The RSA is the controlling document between an organization and ARIN,
>> and the NRPM should not have policy which directly contradicts the
>> contractual limitations or obligations of the RSA.
>>
>
>  I do not see how the remaining language ("In the event that number
> resources of the combined organizations are no longer justified under ARIN
> policy at the time ARIN becomes aware of the transaction, through a
> transfer request or otherwise, ARIN will work with the resource holder(s)
> to return or transfer resources as needed to restore compliance via the
> processes outlined in current ARIN policy.") directly (or indirectly)
> contradicts the contractual limitations or obligations of the RSA.  Perhaps
> you could provide more details on why you think it does?
>
>
> If an organization voluntarily wants to return or transfer address space
> that is fine.  However, if the blocks aren't utilized to today's
> utilization policies, an org may choose not to update their records because
> that is easier and in their best interest.  I postulate that it is better
> to let legitimate M&A activities show the actual rights older of the
> address blocks, rather than previous holders even if that allows transfers
> to occur for underutilized netblocks.  The hypothetical above shows how an
> organization even with the best intentions to keep their registry data
> up-to-date will make a business decision to just continue like the transfer
> never occurred from a registry data perspective.
>
> Andrew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20140723/77479b96/attachment.htm>