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

[Owen DeLong]

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