ARIN also can't reclaim legacy resources. No op. Agreed, another Internet cat video.
Best, -M< On Wednesday, July 23, 2014, Andrew Dul <[email protected]> wrote: > On 7/23/2014 3:00 PM, Scott Leibrand wrote: > > On Wed, Jul 23, 2014 at 2:45 PM, Andrew Dul <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> 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 > >
_______________________________________________ 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: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
