[ppml] Policy Proposal 2008-2: IPv4 Transfer Policy Proposal
Cliff Bedore
cliffb at cjbsys.bdb.com
Tue Mar 4 14:04:12 EST 2008
Scott Leibrand wrote:
> Jim Weyand wrote (in a message not posted to PPML):
>
>
>> My real concern is that the community has not considered the costs
>> associated with the proposed constraints. I can dream up a number of
>> scenarios that may occur.
>>
>>
>>
>> Scenario 1
>>
>> An ISP has a /16 but determines they really only need a much smaller
>> block - maybe a /20. They look at the market price for a /16 and
>> determine that it is a high enough price to put up with the pain of
>> moving all of their addresses to new space. In an unrestricted market a
>> /16 is probably worth more than an equivalent number of /20s so the ISP
>> would be motivated to transfer out the whole /16 and transfer in a /20.
>>
>>
>>
>> The problem is, under “Policy Proposal 2008-2: IPv4 Transfer Policy
>> Proposal”, our ISP cannot acquire new addresses. So, to make the sale,
>> the /16 gets broken up into pieces and all parties are net losers. The
>> seller was unable to maximize their profit, the original buyer was
>> unable to participate in this transaction (because they are prequalified
>> for a /16) and the routing table is increased.
>>
Perhaps the wording should be changed to allow a three-way (n-way?)
trade where several transactions can be made at one time and only count
as one transaction.i.e. A sells the /16 to B and buys the /20 from C.
Like data base changes, it would be an atomic action and would be
considered either all completed or nothing completed. Kind of like some
of the sports team trades you read about
>>
>>
>> Scenario 2
>>
>> Our ISP with the /16 thinks they only need a /17. They look at the
>> market rate for the remaining /17 and think, “hmmm… that’s pretty
>> good”. The ISP reasons that they can get cash now and, if they really
>> need it, they can go buy more addresses later.
>>
>>
>>
>> The ISP is pretty excited about this idea and investigates what is
>> involved with transferring out IP Address space under ARIN’s new rules.
>> They read the rules and realize, down in the fine print, that they can’t
>> get any more IP Address space for another two years. The risk is too
>> great and the ISP decides not to transfer out any addresses and the
>> market price of a /17 is artificially inflated.
>>
>>
>>
>> The constraints will have real costs – probably not the kind of costs
>> that will make the front page of the Wall Street Journal but nonetheless
>> real costs that will affect ISPs.
>>
This seems to me to be in the area of business decisions and I'm not
sure if ARIN should be responsible for someone's bad business
decisions. The sale is being made for a profit and the risks and
benefits of that sale should be weighed by the company before they make
that sale.
Having said that, maybe the benefits to ARIN of letting sales take place
more often outweigh the problems. Perhaps there could be higher fees
for excess transactions to cut down on trading too often. Like broker
fees tend to keep most people from trading all the time. I.e. One
transaction per 24 (x?) months is free, the second one is $xxxx, the
third is 2 * $xxxx and so on. This would put a damper on churning of
addresses while allowing those who really need to get more within a 24
month (or other) period to do so at some increased cost.
And of course there may not be enough trading to make this worth
worrying about. :-) But I guess better safe than sorry.
Cliff
>
> I agree completely. Perhaps one way to address your concerns would be
> to look to NRPM section 4.6 Amnesty Requests
> (http://www.arin.net/policy/nrpm.html#four6), and include text in the
> transfer policy to accomplish similar objectives.
>
> But the more I look at it, the more I wonder if the same objective could
> be accomplished more simply by striking the words ", or through this
> Simple Transfer policy" from the condition that "The transferor may not
> request any IPv4 allocations or assignments from ARIN (through ordinary
> allocations or assignments, or through this Simple Transfer policy)
> within the subsequent 24 months." Under the standard transferee
> conditions, any subsequent requests to receive IPv4 addresses through
> this Simple Transfer policy would have to be justified and
> pre-qualified, just as with any other potential transferee.
>
> The only thing this doesn't address is the desire to allow someone to
> get and renumber into a smaller block (say /20) and then transfer their
> larger block (say /16). Under the current proposed policy, such an
> organization would be able to keep the first or last /20 out of their
> /16, and transfer the remaining /17, /18, /19, and /20. While I could
> see a renumbering being slightly better, I think the existing policy is
> adequate, so I'm not sure if we need to allow people to renumber into a
> completely different block, and deal with all the complexities of timing
> that entails.
>
>
>
>
>> I have struggled to fully understand the latter part of Scott’s second
>> paragraph:
>>
>>
>>
>>
>>> 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.
>>>
>>
>>
>> As I understand this if we make it too difficult to split a block we could:
>>
>> 1) Artificially raise the price of smaller blocks since there may be
>> demand for smaller blocks that cannot be met while there are larger
>> blocks that sit unused.
>>
>
> Yes, that is my main concern.
>
>
>> 2) Unintentionally decrease the supply of larger blocks because a
>> buyer will look at the lower price of the larger blocks and lobby for an
>> exemption to the pre-qualification requirement.
>>
>
> I hadn't thought of that aspect of it, but yes, that would be another
> negative consequence of not allowing enough deaggregation.
>
>
>> Do I understand this correctly?
>>
>> Assuming I do, isn’t this another argument for not introducing any
>> market constraints other than minimum block size?
>>
>
> Or at least for reducing the number of market constraints. As I
> outlined above, and in a separate proposed modification under discussion
> (to allow ARIN discretion to allow enough deaggregation to ensure
> adequate supply of smaller blocks), I'm open to reconsidering any
> aspects of the policy that might do more harm than good, and either
> eliminating or changing those aspects, or introducing compensatory
> language to deal with the negative side effects.
>
> Do you have any feedback on any of the proposals above, or any other
> suggested improvements? The 30-day cutoff for submissions of revised
> proposals for Denver is fast approaching.
>
> Thanks,
> Scott
>
>
>
>> *From: *"Jim Weyand" <jweyand at computerdata.com
>> <mailto:jweyand at computerdata.com>>
>>
>> *Date: *February 29, 2008 9:14:04 AM PST (CA)
>>
>> *To: *"arin ppml" <ppml at arin.net <mailto:ppml at arin.net>>
>>
>> *Subject: **Re: [ppml] Policy Proposal 2008-2: IPv4 Transfer Policy
>> Proposal*
>>
>>
>>
>> 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.
>>
>> --
>> Leo Bicknell - bicknell at ufp.org <mailto:bicknell at ufp.org> -
>> CCIE 3440
>> PGP keys at http://www.ufp.org/~bicknell/
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to the
>> ARIN Public Policy
>> Mailing List (PPML at arin.net <mailto:PPML at arin.net>).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/ppml
>> Please contact the ARIN Member Services Help Desk at info at arin.net
>> if you experience any issues.
>>
>>
>>
>>
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN Public Policy
> Mailing List (PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
> Please contact the ARIN Member Services Help Desk at info at arin.net if you experience any issues.
>
>
More information about the ARIN-PPML
mailing list