[arin-ppml] 2009-1 comment
George, Wes E [NTK]
Wesley.E.George at sprint.com
Thu May 28 12:27:15 EDT 2009
I have a minor issue with A, in that it's overbroad. I can understand limiting transfers between the same two parties to reduce abuses of the policy, but I don't see the value in limiting one party from receiving transfers from several different parties if they have justifiable need for the space and the resources to get it, or limiting one party from transferring blocks to several different parties if that's how they end up becoming available. It's quite possible that some parts of a block can be freed much more easily than others, and will lead to phased transfers. Rate-limiting them simply puts an artificial delay in making more blocks available for use.
Also, while I don't have a problem with a holding period, I completely oppose the language giving general requests precedence over directed transfers in E. It's simply not going to make things any more fair.
The idea behind the directed transfers is to offset the costs incurred by freeing those blocks to be reused. I understand that you're trying to prevent a speculation market and sale of/profiting from IP assets, or this becoming a market for haves vs have nots, but this would essentially eliminate any incentive to complete any but the most basic (i.e. cheap or no cost to complete) efforts to free up unused space in the first place. The standard "good internet citizens don't hoard IPv4 space they're not using" argument isn't going to cause companies to spend real time and money freeing up space instead of simply sitting on it and letting the chips fall where they may. Therefore the result will be less space available for reallocation for the whole community, not more space available for which "the little guy" can now compete fairly (bankrolled by those companies with deeper pockets).
Thanks,
Wes
-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
Sent: Thursday, May 28, 2009 11:17 AM
To: John Curran
Cc: arin ppml
Subject: Re: [arin-ppml] 2009-1 comment
I would suggest the following codicils be added to make the transfer policy
palatable..
A) Limit transfers from or to any party to no more than two in a one year
period, or the rate limit in place for general transfers, whichever is less.
B) Require an RSA or LRSA be in place and active for all blocks currently
allocated to the receiving org and the releasing org. Require RSA for
transferred space.
C) Require reachability of all POC contacts associated with existing blocks
that were /24 or larger for BOTH the "buyer" and the "seller". Verify
email, telephone and mailing addresses.
D) Releasing party is a member in good standing with ARIN. All dues and
fees are paid. Accepting party either has or commits to obtain and maintain
membership in good standing with ARIN.
E) Space to be transferred to be released to ARIN and the IP space be placed
in a holding pool (quarantine?) for 14 days. Effect transfer only if there
are no general requests that would need to draw from that space in the
holding pool in order to be fulfilled. When needed to satisfy general
requests then space in the holding pool should be allocated in a first-in
first-out date order. General allocations from the holding pool are not
subject to the 14 day quarantine. Both releasing and receiving party POCs
to
be notified of a general allocation of the resource in question.
The last amendment (E) is especially important to insure fair competition
for
dwindling resources by the community. What I tried to do with this was to
say
that general requests take priority over directed transfers. This way
everyone will have a chance to compete for the resources. With this added I
would tend to support 2009-1 .
This e-mail may contain Sprint Nextel Company proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
More information about the ARIN-PPML
mailing list