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

[Andrew Dul]

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
> <mailto: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/12dadc8d/attachment.htm>