[arin-ppml] IPv4 Transfer Policy Change to Keep Whois Accurate

[Blake Dunlap]

On Thu, May 19, 2011 at 17:28, Matthew Kaufman <matthew at matthew.at> wrote:

>  Price stability does not require a middle man to hold assets, they only
> need to be listed, but I will give you liquidity for *sellers* absolutely.
>
> Do we really need such liquidity for *sellers* in IPv4? Is there even use
> for such?
>
>  Sure. If you need space in 6 months, but not now, wouldn't it be nice to
> get it from someone who'd worked with a middleman today to start a 5-month
> project to free up space and transfer it to the middleman... rather than
> having to wait those 5 months yourself?
>
> That's just one of many examples that popped into my head.
>
> Matthew Kaufman
>

I'm trying to understand what you just said, but I am having a hard time.
Can you try and rephrase?

Also, assuming I am reading the above correctly, as a response, can you
explain why locking out IPs for your future use (of an undetermined time
period, lets try not to get pendatic) is of benefit to the community now,
when there are probably a significant number of parties wanting space now,
as these policies only even matter if there is resource contention?

One thing to note, and I hesitate to even mention this, is that needs based
justification does *not* preclude a party reserving space for you, depending
on how the other policies end up being shaped as to IP space sales listings
/ transfers especially in regards to seller needs justification. It only
currently affects you when the transfer is to take place.

Hmmm, you make a good point in that regard. After thinking about what you
just said, and what I just said, I do think we need to redo some of the IPv4
policy in regards to transfer, sales, and needs justification, since as it
stands, there is some basic conflict in the different policies, at least on
the side of sellers.

-Blake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110519/d5373824/attachment.htm>