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

[David Farmer]

On 3/24/14, 13:08 , Owen DeLong wrote:
>
> On Mar 21, 2014, at 15:51 , David Farmer <farmer at umn.edu> wrote:
>
>> On 3/21/14, 09:10 , Gary Buhrmaster wrote:
>>> <soapbox>
>>>
>>> Any M&A, or organization changes, have a cost
>>> regarding business records, and it is incumbent
>>> on the organization to be prepared to pay that cost
>>> for changes.  Updating ARIN records (and the cost
>>> of doing so) is no different, and should not have a
>>> special "out" just because it can be take time or
>>> the people involved did/do not want to invest that
>>> effort.  The days of informal handshake number
>>> deals are (or should be) long over.  Get over it, and
>>> do the (boring, painful, but necessary) work.
>>>
>>> </soapbox>
>>
>> I very much agree, there is and almost certainly should be work involved.
>>
>> So, yes with any M&A, or other organization change, you should have to the "Business Office" part of documenting business records associated with the change.  The rationale for this "Business Office" part is clear.  Its necessary to prevent fraudulent changes to resources, and ARIN has a clear fiduciary responsibility to ensure this happens correctly.
>>
>> However, I do think it is a reasonable question to ask, should you also have to do the "technical" documentation that the paragraph in question requires as well?  Frequently, such an organizational change implies little to no technical change.  So, what is the rational for doing this "technical" reporting?  Let me be clear, I'm not saying there isn't a valid rationale, but I personally can't articulate it.  So, I'd appreciate it if someone would articulate a valid rationale for this "technical" reporting.
>
> 1.	To raise the visibility when an 8.3 transfer is being attempted through structures designed to disguise it as an 8.2 transfer.
> 2.	For consideration in cases where the 8.2 transfer is a transfer of underutilized resources which would not otherwise get reviewed.
> 	While the RSA protects the current resource holder from reclamation due to underutilization, during an 8.2 transfer, I see no
> 	reason that the amount transferred should not at the time be right-sized to fit the infrastructure also being transferred. The policy
> 	as written is generous about allowing staff to find ways to work with the new resource holder to accommodate that process and
> 	provides ample time and great flexibility on extensions to that time, if needed.
> 3.	Related to point 1, to prevent 8.2 from becoming a target vehicle for end-runs to the needs-basis tests in 8.3.
>
> Owen

I believe #2 to be punitive to those that are properly updating their 
records as a result of a legitimate transaction.  Policy should 
encourage proper updates to records, this seems to discourage it, or at 
least provide a disincentive.

I think #1 and #3 are legitimate issues of concern.  But I think these 
concerns can be addresses in other ways without creating a disincentive 
for legitimate updates to records created by requiring a resource review 
to complete a 8.2 transfer.

Basically, 8.2 transfers should only apply if other asset of value are 
involved in a transaction and the Internet number resources are not the 
primary asset of value involved in the transaction.  If these are not 
true then 8.3 should apply.

I would support removal of the paragraph as suggested by this policy, if 
language like above were included to prevent creative contracting to 
make what should be a 8.3 transfer look like a 8.2 transfer.

Without some kind of language to prevent an end run around 8.3, I would 
only support removing the words "reclaim" and "aggregate" from the 
current text.

Thanks.

-- 
================================================
David Farmer               Email: farmer at umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================