On Mar 21, 2014, at 15:51 , David Farmer <far...@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
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
