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

Martin Millnert millnert at gmail.com
Wed May 11 22:11:20 EDT 2011


Hi Mike,

FWIW, I share your perception of reality in many ways.

John's position is perfectly fine; that a transfer inside the registry
will only happen following the policies of the community.

When a transfers occur outside the RIR's scope and reach, and the
involved parties either:
 a) think involving the RIR is too much work/unnecessary or they are
simply unaware of it, or,
 b) they fail to meet the requirements, or
 c) they do not think the benefits of involving the RIR outweighs the drawbacks,

then, either:

 1) policies (eventually) change to adjust more towards reality (if a
party can get working internet w/o involving the RIR, by an ISPs free
will choice to accept the addresses as legitimate theirs, they have no
real reason to involve the RIR )
 2) the RIR's whois loses accuracy,
 3) the RIR corrupts its practices of the community policies to avoid
2, lacking 1.

This is pretty darn logical and simple IMHO.

I accept that it is up to the community to discern what it wants in
some kind of democratic fashion and I'm perfectly fine with the
outcome of that procedure, but it is very useful for this process to
have sufficient data, so to speak.

Cheers,
Martin

On Wed, May 11, 2011 at 9:03 PM, Mike Burns <mike at nationwideinc.com> wrote:
> Hi Owen,
>
>> When you assert other such transactions, are you referring to the 10 for
>> which John Curran provided anonymized
>> data, or, are you asserting that there are others which have occurred
>> outside of ARIN? If so, can you cite examples
>> or provide any documentary proof of such a claim?
>
> I have personally seen many asset sale agreements which included legacy IP
> addresses which were completed without notifying ARIN, as there is still no
> requirement for legacy holders to do that. I have seen asset sale agreements
> which include ARIN accounts and passwords among the listed assets. The
> addresses change control, but whois still shows the original registrant.
> When it comes time to route the addresses, if the network operator questions
> the situation, I have seen them accept the asset sales agreements as
> acceptable proof of routing authority. And the addresses allocated to entity
> A are now in control of entity B, with bogus whois data. This is the kind of
> eventuality which I believe motivated the APNIC community to place the
> stewardship role of uniqueness above the stewardship role of needs-based
> transfers. Obviously I am asserting these things without documentary proof.
>
>> While I don't think that's the entire argument or even a particularly
>> accurate framing of that portion of the
>> argument, I would say that the history of free markets does give one
>> plenty to fear. Especially when you
>> consider that history in situations of truly finite (even for a short
>> time) resources. (Tulips anyone?)
>
> Of course we will disagree, but I see the Internet as a crucible of
> lassez-faire, and its manifest success resulted from those policies based in
> freedom and private choice.
> You seem to consider that needs-based allocations were some kind of social
> agreement preventing malfeasance of the wealthy and protecting the little
> guy.
> In reality, it was the least  rulemaking possible in an era of free-pool
> allocations.
> There really was no other way to distribute scarce resources with no price
> unless the allocations were limited by need.
> And nobody really debates that, even an outlier like me.
> That cause goes away with the free pool, and the imperative against more
> rules than necessary dictates we lift those needs-based transfer rules.
>
> We have to understand the cause of needs requirements. It wasn't some
> egalitarian ethos, it was an obvious and fair mechanism for placing some
> limit on address allocations from a free pool of limited size. We didn't
> impose max limits per allocant, we didn't impose progressive fees that made
> larger blocks proportionally more expensive, we didn't create rules to favor
> corporate diversity, we didn't limit distributions per country, we didn't
> require an income statement of recipients so that we could judge whom to
> allocate to. We chose the most limited mechanism to ensure that the
> addresses were not wasted. If we understand that, and we understand that
> stewards make only the minimum rules necessary for order, it is easier to
> drop the emotional attachment to needs requirements in the face of free pool
> exhaust. You will note that despite my free-market inclinations, I have
> never argued to drop needs requirements for new allocations of IPv4 or for
> IPv6.
>
> I have searched long and hard for a historical analog to this situation. The
> best I could find was a policy of the US after the Revolutionary War, which
> allocated property to veterans of that war for free. You had to qualify by
> being a veteran, the total property available for allocation was limited in
> size, and the property had value. All the same as our IPv4 situation.  In
> the historical case, there were no limits on resale of the allocated land,
> there were aggregators, there were speculators, and things progressed
> normally during the allocation time period, and the time period after the
> land was fully allocated. Some people intended to live and farm the land,
> others intended to sell their allocations. And American law allowed a free
> market in which these men could decide.
>
> Rather than judge the benefits of free markets by exceptions like manias and
> successful market cornering, both rare and shortlived events, why don't we
> judge free markets like our American ancestors did, even if we're Canadian,
> eh!
>
> Regards,
> Mike
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>



More information about the ARIN-PPML mailing list