On 3/24/14, 13:08 , Owen DeLong wrote:
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
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: far...@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
================================================
_______________________________________________
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.
