[arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements
hannigan at gmail.com
Thu Mar 20 23:35:41 EDT 2014
In my buy-merger-sell experience, most companies don't complete transfers
post M&A because they dont want to deal with ARIN. It's not worth the
difficulty. Accuracy of the registry suffers again.
On Thursday, March 20, 2014, Sweeting, John <john.sweeting at twcable.com>
> Hi David
> I usually do not weigh in on active policy proposals but I did want to
> point out that a lot companies do not complete transfers during M&A
> activities simply because they do not have the resources to do so. The one
> (or half) person they have dealing with IP resources usually cannot even
> keep up with normal workload, let alone the additional workload associated
> with M&A activity. At least that has been my experience over many years and
> more than a few M&A events.
> Sent from my iPhone
> > On Mar 20, 2014, at 4:51 PM, "David Huberman" <
> David.Huberman at microsoft.com> wrote:
> > In contrast to my friend Owen, not only do I believe there is a very
> serious issue, but I believe this
> > proposal is necessary for ARIN to have any hope of being relevant in the
> years to come. I don't
> > mean to use that kind of hyperbole, but the issue is very real from my
> viewpoint. Allow me to
> > explain.
> > There are two different problems which this policy proposal solves.
> > 1. Whois accuracy
> > =============
> > As an ARIN Hostmaster for 10 years, I saw a very high rate of legitimate
> transfers which were
> > abandoned by the requestor. In turn, Whois did not get updated, and in
> most cases, remains
> > out of date today.
> > Think about that for a moment please: legitimate M&A activity occurred,
> but Whois never
> > got updated. That's a failure of the system. Why does it fail?
> > The common scenario is straight forward:
> > 1. Company A buys company B.
> > 2. Company A submits a transfer request to ARIN to have the IP
> address and AS number
> > registrations reflect that Company A is now the registrant.
> > 3. ARIN starts asking questions about the utilization of the
> number resources.
> > 4. Company A walks away from the transfer and never returns.
> > Step 3 is the consistent problem. In many cases, Company A never even
> submits the transfer
> > request because they are scared off by step 3. In some cases, it's
> because they don't KNOW
> > how the IP addresses are being used. In some cases, some IP addresses
> are used, and others
> > are not, and they think that if ARIN finds that out, they are going to
> take the addresses away.
> > In some cases, none of the addresses are used. But Company A is
> expanding their network
> > (or plans to) and wants to use the IP addresses of Company B which they
> now own.
> > Current policy does not work for these common scenarios. I conclude
> that having seen
> > thousands of transfers cross through the ARIN ticket system and talked
> to these requestors
> > over the phone for 10 years.
> > The takeaway from the above is that Whois is not accurate, in part
> because ARIN policy
> > demands justification for addresses which, regardless of whether Whois
> is updated or not,
> > Company A is going to use.
> > In December, the PPML list requested metrics from ARIN staff to show the
> extent of abandoned
> > transfers. The metrics provided were as follows:
> > === 8.2 Transfer Request Stats
> > 2011:
> > 422 8.2 transfers requested
> > 226 8.2 transfers approved (54%)
> > 209 8.2 transfers completed (50%)
> > 2012:
> > 451 8.2 transfers requested
> > 264 8.2 transfers approved (59%)
> > 241 8.2 transfers completed (53%)
> > 2013 YTD:
> > 445 8.2 transfers requested
> > 280 8.2 transfers approved (63%)
> > 269 8.2 transfers completed (60%)
> > If you review the thread in December, these stats generated a lot of
> discussion. I am among
> > the many who believe that a 40% abandonment rate FOR LEGITIMATE M&A
> ACTIVITY belies
> > a shortcoming in ARIN policy. There's a barrier that must be removed,
> and my experience
> > teaches me that it is the utilization requirements of NRPM 8.2.
> > Now to the second problem.
> > 2. Conflict with the RSA:
> > ==================
> > John Curran can give a more accurate and nuanced history, but as best I
> can recall, ARIN
> > tried to bring more legacy registration holders into the registry system
> by offering a
> > Legacy Registration Services Agreement. One of the takeaways from that
> initial effort
> > was that legacy registration holders were unwilling to sign any
> agreement which technically
> > allowed ARIN to de-register address space that they had without their
> > One of the concessions made over time was language in the RSA documents
> > removed that concern; it prohibits ARIN from forcibly taking away space
> when the
> > signer is in compliance with the other terms and conditions of the
> > This new language, however, directly conflicts with the plain language
> of the NRPM 8.2
> > paragraph that this policy proposal seeks to remove.<This E-mail and any
> of its attachments may contain Time Warner Cable proprietary information,
> which is privileged, confidential, or subject to copyright belonging to
> Time Warner Cable. This E-mail is intended solely for the use of the
> individual or entity to which it is addressed. If you are not the intended
> recipient of this E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents of and
> attachments to this E-mail is strictly prohibited and may be unlawful. If
> you have received this E-mail in error, please notify the sender
> immediately and permanently delete the original and any copy of this E-mail
> and any printout.
> You are receiving this message because you are subscribed to
> Unsubscribe or manage your mailing list subscription at:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML