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: [email protected] [mailto:[email protected]] On Behalf
Of Owen DeLong
Sent: Thursday, March 20, 2014 1:07 PM
To: Heather Schiller
Cc: [email protected]
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 <[email protected]> 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 <[email protected]> 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 ([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.
_______________________________________________
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.
_______________________________________________
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.
_______________________________________________
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.
