[arin-ppml] suggested change for ARIN 2008_2:
lear at cisco.com
Mon Sep 29 04:12:37 EDT 2008
The comments below stem from the analysis that Bill Lehr, Tom Vest, and
I performed on ARIN 2008_2. These comments, however, are my own. Scott
has requested of me that discussion occur on the PPML list.
Section 8.3.5 specifies that transferees must pre-qualify in order to
receive an IP address block. This includes satisfaction of need. The
rationale behind this requirement is to reduce speculation and provide
for more immediate use on the Internet. Section 8.3.6 specifies that
ARIN may allow transferors to deaggregate blocks. The inverse is more
the intent, which is to keep routing tables from exploding.
1. Section 8.3.6 is perhaps intentionally vague, so has to provide
flexibility over the management of the market by ARIN staff. However,
the Rationale section of the proposal is more clear: "To discourage
unnecessarily rapid growth of routing tables, an allocation or
assignment may not be arbitrarily deaggregated." However, this
proscription is not actually stated in the proposal. This lack of
clarity may lead to unnecessary litigation.
2. Ignoring (1), the impact of Section 8.3.6 in combination with
Section 8.3.5 is to avoid the circumstance where there is an excess of
supply for large blocks, while demand for smaller blocks goes unmet.
The intent is clearly good as it off sets a concentrative force.
However, there are side effects to this policy as well. Those holders
of large blocks may be tempted to keep them off the market until supply
for smaller blocks has dried up. The only reason this would not occur
is that the sellers may not have visibility to demand. If sales remain
private, visibility will be poor. If sales end up on eBay, visibility
will be high.
In fact it is unclear what visibility ARIN staff will have. ARIN will
see unsatisfied demand through the number of pre-qualified blocks
outstanding. But that's not the same as pricing information. If blocks
are moving but price skyrockets because the resource is viewed as
essential, ARIN will not know to allow disaggregation.
3. ARIN may have no visibility as to who is holding back blocks in
order to disaggregate them.
4. Similarly large block holders have no understanding as to when and
how they can disaggregate their blocks. As such, a buyers market will
still exist for larger blocks.
ARIN having price visibility may provide a solution to both (2) and (3)
above. If buyers and sellers report purchase prices, then ARIN can see
when the price per address of large blocks drops below that of small
blocks, and act accordingly.
Dealing with (4) is more difficult, and goes to seller expectations. A
policy that allows for some disaggregation at a controlled rate may
alleviate problems, but this is sheer conjecture on my part.
Whatever is decided, 8.3.6 should be clarified to reflect that decision.
Please keep in mind that all of these recommendations presume that ARIN
has sufficient regulatory authority and capability to manage such
controls. A reasonable question to ask is whether all of these controls
contravene a more important goal of knowing who is actually using the
block, by encouraging people to skirt the rules. APNIC's prop-50
clearly is written with this concern in mind.
More information about the ARIN-PPML