[ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal

Scott Leibrand sleibrand at internap.com
Fri Feb 29 12:31:53 EST 2008


Jim,

Yes, Ben has been monitoring this list.  I haven't heard him express 
concerns with that particular clause, because the proposed policy allows 
a party with a larger block than they need to keep one contiguous 
portion of it and transfer the rest: there's no need to trade it in for 
a smaller block.

Ben has expressed concerns about the restrictions that limit 
deaggregation on the transferor side.  If I understand his position 
correctly, he believes that requiring transferees to fill their entire 
request with one transfer is good and necessary to prevent 
deaggregation, but that further restricting transferors from 
deaggregating to meet legitimate demand from pre-qualified transferees 
will have a negative effect of increasing the price of small blocks 
while decreasing the price (and supply) of larger blocks.

There are a few different ways to deal with this, in addition to the 
proposed transfer policy's conditions or a transferee-restrictions-only 
system.  For example, we might ask ARIN to monitor market prices, and 
allow as many bits of deaggregation (on transferor pre-qualifications) 
as needed to keep supply and demand in balance across the range of 
address sizes...

-Scott

Jim Weyand wrote:
> Does our economist monitor this list?  There is a lot of language in the
> rationale section that says that many of the restrictions on trade are
> designed to limit speculation.  Is speculation worse than living with
> the restrictions imposed by this proposal?
> 
> For example one restriction is that if you transfer address space to
> another party you may not receive address space for another 24 months.
> This means that if you have a nice large block you are prevented from
> transferring the entire block to another party and getting a more
> suitable block in return.
> 
> This restriction will also artificially increase the "market price" of a
> block of addresses since I will only take the risk of running out of
> addresses in next 24 months if it is very rewarding.
> 
> I'd like to hear our economist's (Ben?) comments on the cost to the
> community of the restrictions v. speculation.
> 
> Even with these restrictions I can support this policy, however I think
> it is worthwhile to consider the "hidden" costs associated with these
> restrictions.
> 
> -Jim Weyand
> 
> -----Original Message-----
> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On Behalf Of
> Leo Bicknell
> Sent: Friday, February 29, 2008 10:50 AM
> To: arin ppml
> Subject: Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
> Proposal
> 
> In a message written on Fri, Feb 29, 2008 at 10:27:02AM -0500, Cliff
> Bedore wrote:
>> I think we need to make sure the ARIN attorneys look at this from the
>> standpoint of "How can I beat the system".  I expect they are
> honorable and
>> above board and that's probably a disadvantage when trying to ensure
> all the
>> i's are dotted and the t's are crossed and the vultures are kept at
> bay.
> 
> The ARIN AC has worked closely with both Steve Ryan, ARIN Council
> and Ben Edelman, who many saw at the last meeting for his Economics
> background, but in addition to his PhD in economics also has a J.D.
> from Harvard Law and is admitted to the Massachusetts Bar.  They
> both provided significant input that the AC used to better craft
> the policy language to strengthen ARIN's legal position were this
> policy to be adopted.
> 
> That's not to say they don't have some concerns.  Nothing is 100%
> in law, particularly when there is limited case law on the subject.
> I believe both will be at the Denver meeting able to answer questions
> about legal risk.  As with all policies, ARIN Council will generate
> a legal review of the policy prior to the meeting which should both
> be posted to PPML and reviewed at the meeting.
> 
> I strongly urge anyone with legal concerns to either come to Denver,
> or participate remotely.
> 



More information about the ARIN-PPML mailing list