[arin-ppml] Q2: on Address Transfers - Overkill on the freezeperiod?

[Robert E. Seastrom]

"Milton L Mueller" <mueller at syr.edu> writes:

> Note that true speculators are likely to be, indeed must be, first
> recipient and then sources of addresses. 
>
> You can't speculate without first buying and then selling, and the pure
> speculator wants to be able to control the time at which they sell to
> capture the highest price. So a long-term restriction on what the
> recipient does with transferred addresses is much more on target than a
> restriction on the source. 

These two paragraphs are at odds with each other.  I believe the right
place to first raise the restrictions is as close to the source of the
address space as possible, that is, the speculator himself.

> Indeed. So restrictions on the transferor (source) are more likely to
> interfere with the incentive to release address resources in a way that
> undermines the goal of the policy. 

Complete disagreement here.  Restrictions on the transferor and
transferee are different sides of the same coin, but restrictions on
the transferor are closer to the source and more likely to catch
people's attention.

> As Scott noted, the only thing you want to do with the source is make
> sure that they don't sell their assignment and then come back to ARIN
> for more for free. 

Or go back into the market, driving up the prices needlessly.

> The only other reason you have cited to impose a prior 2-year restraint
> on sources is to prevent "fabricated requests" and "creating a run on
> the market." 
>
> This argument shows a rather interesting lack of faith in the vaunted
> "needs-based assessment." Are you suggesting that you don't think ARIN
> staff can distinguish between real and fabricated requests? If it can,
> this is no problem, because unnecessary requests will not be rewarded.
> If it can't, then the run on the bank will occur even if there is no
> transfer policy of any kind. 

I have a huge amount of faith in ARIN's analysts and believe that they
do an exceptionally good job today of making sure that requests that
are blatantly fabricated don't slip through.  I do not make the error
(as you seem to have) of assuming that everything is black and white,
or that every ARIN analyst is as good as his officemate.  If we create
a situation where there is a big uptick in the number of requests that
hit ARIN, we are going to be faced with a situation where an analyst
with a few weeks of experience is going to be called upon to do the
job of someone with a few years of experience.

Creating a climate in which the incentive to fib on one's applications
is increased rather than decreased, is a step away from goodness.  I'm
not for it.

>> I would be
>> an enthusiastic proponent of expanding the timeouts on both sides of
>> the event to three years or whatever the time between "right now" and
>> the best guesstimate of IPv4 ARIN-exhaustion-of-final-block is,
>> whichever is less.
>
> This attitude reveals a lack of awareness of the cost-benefit tradeoffs
> that will define how the policy actually works in practice. If the
> timeouts on sources are too long you undermine the incentives to
> release. So if you recognize the need for a transfer policy, as you seem
> to do, reluctantly, you can't just expand the timeouts indefinitely. 

I didn't suggest expanding the timeouts indefinitely, and I've put
plenty of thought into the cost-benefit tradeoffs involved in how the
policy will actually work in practice.  You're free to believe
otherwise of course, but I don't think any of my colleagues on the AC
will join you in accusing me of being unaware of what's going on here
as you have.

                        ---rob (on the ac, would never dream of speaking for it)