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

Fri Mar 21 17:04:27 EDT 2014

As a watcher of this since it's inception I have to jump in here as this 
is getting way off the rails, gosh it is reminding me of the affordable 
health care act no one can afford.

Point one RE:

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?

Please guys, this is simple programming, a 60 to 90 day check to see if 
it was indeed transferred.

Point Two RE:

  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.

This is wrong on every level. One of the only free things ( in the since 
you buy a block of addresses and do what you want to with them) the 
human population has in the world and now it is going to be  divvy up 
like the school yard bully's candy. And then controlled.
This is not even in the ball park of the mission statement.

Rant off,
Christine

On 3/20/2014 1:48 PM, David Huberman 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 consent.
>
> One of the concessions made over time was language in the RSA documents which
> 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 contract.
>
> This new language, however, directly conflicts with the plain language of the NRPM 8.2
> paragraph that this policy proposal seeks to remove.
>
> >From a business standpoint -- from the standpoint of actually running the registry of
> ARIN -- the paragraph I propose to be removed is NON-OPERATIONAL.  It cannot
> be enforced under the terms of the RSA.
>
> The community, therefore, I believe is compelled to address the conflict.
>
> I hope this summary helps.
>
> David R Huberman
> Microsoft Corporation
> Senior IT/OPS Program Manager (GFS)
>
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong
> Sent: Thursday, March 20, 2014 1:07 PM
> To: Heather Schiller
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Draft Policy ARIN-2014-9: Resolve Conflict Between RSA and 8.2 Utilization Requirements
>
>
> On Mar 20, 2014, at 13:01 , Heather Schiller <heather.skanks at gmail.com> wrote:
>
>
> As a shepherd for this proposal, I would like to solicit community feedback on the proposed text.
>
> Aside from the general support/against.. some things to consider:
>
> Do you concur with or have any comment on the problem statement?
>
> I do not concur with the problem statement.
>
>
> If you support the problem statement, do you support removing section 8.2 as the correct path for remediating this conflict?  Do you have other suggestions for how to handle this?
>
> No.
>
>
> If you are opposed, what concerns do you have about implementing this policy?
>
> I have previously stated my concerns. IMHO, this is yet another attempt to bypass the needs-basis and seeks to solve a problem which does not, in fact, exist.
>
> Owen
>
>
>
> Thanks,
> --Heather
>
>
> On Tue, Mar 4, 2014 at 3:12 PM, ARIN <info at arin.net> wrote:
> On 20 February 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-199 Resolve Conflict Between RSA and 8.2 Utilization Requirements" as a Draft Policy.
>
> Draft Policy ARIN-2014-9 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_9.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-9 on the Public Policy Mailing List.
>
> The AC will evaluate the discussion in order to assess the conformance
> of this draft policy with ARIN's Principles of Internet Number Resource
> Policy as stated in the PDP. Specifically, these principles are:
>
>    * Enabling Fair and Impartial Number Resource Administration
>    * Technically Sound
>    * Supported by the Community
>
> The ARIN Policy Development Process (PDP) can be found at:
> https://www.arin.net/policy/pdp.html
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> Draft Policy ARIN-2014-9
> Resolve Conflict Between RSA and 8.2 Utilization Requirements
>
> Date: 4 March 2014
>
> 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.
>
> Return and aggregate are not done in collaboration; they are coerced by policy without the willing consent of the transfer parties.
>
> We should remove all utilization references from 8.2 language to ensure the policy is compliant with the RSA.
>
> Policy statement:
>
> Remove from 8.2:
> "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, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy."
>
> Comments:
> a.Timetable for implementation: Immediate
> b.Anything else:
>
>
>
>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>