[arin-ppml] Draft Policy 2009-1: Transfer Policy - comments as requested

Kevin Kargel kkargel at polartel.com
Thu May 7 12:14:52 EDT 2009

At special request I will to restate my objections to section 8.3 of both
2008-6 (as adopted) and 2009-1.  With all due respect to the AC and the BoT
and recognition for amazing good works I make these comments.

2008-6 should be nullified because it contradicts itself.  In one sentence
it states that "This policy is not intended to create a 'market'" and then
it goes on to state that "resource holders served by ARIN may designate a
recipient for number resources" which is pretty much the definition of
creating a market.  If the goal is to create a market then let's state that
in the open and avoid the sophistries and strike the contradictory statement
from 2008-6. 

If I say I am not going to do something and then go on immediately to do it
I have done it, whether or not I said I wasn't going to.  

There was a sunset clause built in to 2008-6 by the community as a
protection against untested policy.  The sunset clause was IMO the vehicle
through which what community consensus that did come together was reached.
Without the sunset clause it is unlikely that the community would have
supported 2008-6.  Whether this makes any sense or not it is what the
community wanted.  

I realize that ARIN is not a democracy.  This was appropriately driven home
by Mr. Vixie at the Public Policy meeting.  Even with this being true, I
feel the BoT should respect the wishes of the community.  The sunset clause
for 2008-6 should be reinstated or 2008-6 should be nullified.

Problems I see with 2009-1, in addition to those stated above for 2008-6,
are that there are few protections in it for the community.  If the intent
is truly "not to create a market" but still allow IP addresses to be
exchanged for value (is that contradictory?) at a minimum there should be
some sort of rate limit on exchanges.  If a receiving party could only
accept one or two allocations per year then at least it would make it more
difficult (not impossible) to set up as a brokerage house.  

At a maximum 2009-1 should conform or subscribe to the current rate limits
in place for allocation requests, and should increment the allocation
request count.  In other words, the Transfer Process should not be available
as a means to sidestep policy rate limiting general allocations. 

I would also suggest that 2009-1 would be an appropriate place to insert an
account review, making sure that RSA's are in place for all allocations of
both parties, and that POC's are current and up to date for all allocations
held by both parties before the transfer is effected.  It should also be
required that ARIN fees are current and that both parties are members in
good standing.  It is very reasonable to demand that transfers happen only
between RSA covered ARIN members in good standing.  Requiring ARIN to only
service members in this regard would be a good thing. 

These account tests should be able to be checked with reasonable expense by
ARIN.  If transfers such as this incur expense over and above what exists
with current transfers then ARIN should implement a "Transfer Fee"
sufficient to cover additional operational costs.

Kevin Kargel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090507/6cded9c5/attachment-0001.bin>

More information about the ARIN-PPML mailing list