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

Mike Burns mike at nationwideinc.com
Fri May 20 23:08:55 EDT 2011


Hi Owen,

>No, this is not accurate. It provides no incentive. It does reduce 
>disincentive to register transactions
>that the community might not look upon favorably. It does not create 
>incentives.

OK, it's intention is to remove disincentives to register transactions.

>> 2. Provides an incentive for legacy space to be brought under RSA

>I don't see this in any way shape or form. Can you please explain how, 
>exactly, removal of needs
>basis influences this in any way?

Because legacy addresses can be bought and sold without a needs requirement, 
per the finding of "exclusive right to transfer" in the MS case, and the 
Plzak declaration as the head of ARIN, that ARIN has no authority over 
legacy addresses. You may disagree, but the Plzak declaration is very clear.
Given this, legal legacy transfers can occur where the purchased amount may 
not meet ARIN's need requirement.
If the buyer cannot meet the requirement, he will not register the 
addresses, although I have argued he will likely want the addresses 
registered to reflect his ownership of their rights.
But if there is no needs requirement, the disincentive is removed, the 
registration takes place, and the buyer signs an RSA.
My proposal also reduces the disincentive to sign the RSA, as it removes the 
utilization requirement and frees the buyer to resell the addresses to 
anybody, with or without need. (Unless that buyer already has transferred a 
/12 equivalent).
So I believe the net effect of the proposal is to make the RSA more 
attractive, and reduce the disincentive for registration of legacy transfers 
which do not meet the needs test.

Remember, these are the intentions of the proposal, although I know you 
disagree with my legal interpretation, and thus the effect.


> 3. Provides for explicit protections against review audits for RSA holders 
> after one year, bringing RSA rights more in accord with LRSA rights.

>Uh, yeah, I don't see that as a good thing. Quite the opposite. However, I 
>do agree that it is an intended
>consequence of the proposal.

>> 4. Reduces transaction costs for transferers

>I believe it will actually increase them.

The intent of the proposal is that transactional costs related to the needs 
analysis can be avoided. These may be large or small. I suppose you mean the 
prices will be higher due to speculation, though.

>> 5. Reduces ARIN costs for needs analyses

>Agreed, but, not necessarily something I see as a beneficial aspect.


>> 6. Aligns ARIN policy with most possible interpretations of the legal 
>> rights of legacy holders

>No, aligns ARIN policy with one possible interpretation of the legal rights 
>of legacy holders.
>IMHO, not even the most probable one.

See "exclusive right to transfer" and the Plzak declaration that ARIN has no 
authority over legacy addresses.
Would it be fair to say "Aligns ARIN policy with legal interpretation most 
friendly to legacy holders?"
My point being this alignment presents the lowest risk toARIN of being sued 
for tortious interference in a contract.

>> 7. Imposes a yearly limit on needs-free transactions intended to prevent 
>> cornering.

>Yes, but, this limit is effectively a no-op because anyone can create 
>multiple entities needed
>to accomplish enough /12 transfers to meet their desires.

I trust ARIN staff to detect these with the same diligence applied to needs 
tests and section 12 reviews.

>
>> And likewise we have fairly addressed these issues.
>

>To some extent.

>> Without considering (any more) the merits of those prior discussions, I 
>> would like to invite the consideration of any other potential benefits or 
>> consequences which we have not discussed.
>> I am cognizant that this is proposal is a significant departure, and that 
>> the discussion of similar policy in APNIC consumed several years.

>As it did here prior to being rejected here and accepted there.

I didn't know there had also been prior discussion here about this (or 
fairly similar) policy. Do you rember about when so I can search the 
archives?

>> I think we have covered pretty much all the bases in our relatively short 
>> but active discussion period, but I agree with Tom that we really should 
>> stretch our minds to consider all the potential pitfalls.
>> So did we miss anything, or is there anything left to be said on the 
>> topics arrayed above? Any large loopholes or gotchas? Risks or threats we 
>> haven't considered?

>One I think worth exploring is that given the recent staff interpretation 
>of the term RSA in policy,
>the requirement for RSA in the proposal may be insufficiently specific to 
>express community
>intent.

I agree, though my intention was that it was the RSA, not an LRSA, but the 
RSA modified by my proposal.

>> Maybe the increased/decreased exposure of ARIN to lawsuits?

>I think this would not significantly impact the legal exposure. We are as 
>likely to get sued
>by someone unable to obtain resources in the market on the basis that we 
>failed to properly
>regulate need in the market as we are to get sued by someone opposed to our 
>attempts
>to regulate need, IMHO.

I can't see any legal right to sue ARIN if the community decides to drop the 
needs policy, but I am not a lawyer.
I wonder if anybody has sued APNIC on that basis?
Maybe the ARIN legal staff can comment on that.
But I can sure see somebody suing ARIN if ARIN re-issues their address to 
another allocant.
If ARIN's legal interpretation is that they can revoke legacy addresses if 
they are not utilized, for example, that leads to their reissuance, and 
legal trouble.
If ARIN's legal interpretation is that legacy addresses are outside its 
authority, that risk is minimalized.

>
>> (I will admit to enjoying reading my own words. But as they are growing 
>> tiresome to me, they must be coma-inducing to you by now.)
>

>It's been a good debate, IMHO and I agree we have both well established our 
>positions.

>Owen

Ditto.

Regards,
Mike




More information about the ARIN-PPML mailing list