[arin-ppml] IPv4 Transfer Policy Change
rudi.daniel at gmail.com
Sat May 21 11:24:06 EDT 2011
Question: What would be the effect of removing the needs requirement for the
transfer of resources from a legacy holder; and any transfer from the
legacy holder signs an RSA as mandatory requirement and thus remove LRSA.
No, this is an incorrect understanding of the ruling. The Plzak declaration
> is also
> not the final word on the subject. The exclusive right to transfer means
> that nobody
> else has the right to transfer them. It does not mean that they can be
> regardless of policy or that ARIN must recognize a transfer outside of
> policy in the
> ARIN database.
> Legacy addresses were issued to a particular party for a particular
> purpose. Upon the end
> of that purpose or that party, they should be returned and are no longer
> legacy addresses.
> In the case of a transfer to a successor in interest through acquisition or
> merger, in some
> cases, the legacy status has been preserved, but, this is rare. In most
> cases, the receiving
> organization has been required to sign an ARIN standard RSA.
> It works this way... Legacy status is the intersection of the holder and
> the resources which
> were registered together by a registry preceding the RIR system. Once
> either of those
> conditions ceases, the resources are no longer in legacy status (in most
> ARIN has an obligation to continue providing services to records with
> legacy status so long
> as that legacy status remains under the original terms of issue.
> ARIN has the right to reclaim addresses from defunct legacy organizations.
> > Given this, legal legacy transfers can occur where the purchased amount
> may not meet ARIN's need requirement.
> Not true. At least not if they want to be recognized by ARIN and have the
> transfer registered
> in whois.
> > 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.
> The unregistered addresses become subject to reclamation since they are no
> longer in
> use by the original organization under the original terms of issue.
> > But if there is no needs requirement, the disincentive is removed, the
> registration takes place, and the buyer signs an RSA.
> Ah, so you are once again confusing incentive with removal of disincentive.
> I can see how, to a limited extent, this
> might provide less of a disincentive for the recipient of a transfer from a
> legacy holder to register the transfer, but,
> I don't see how this is anything other than redundant to your point 1.
> > 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).
> Yes, by neutering the RSA, you have removed some disincentives to sign it.
> However, I don't see neutering the RSA
> as a net positive in that regard. The community put section 12 into policy
> for a reason.
> > 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.
> There is no such thing as a legacy transfer. There is a transfer of
> resources from a legacy holder, but, absent an
> awkward situation involving litigation these will almost always result in
> the space being handled as non-legacy
> if the transfer is recognized by ARIN.
> > Remember, these are the intentions of the proposal, although I know you
> disagree with my legal interpretation, and thus the effect.
> Yes... Your legal interpretation being contrary to statements made by ARIN
> counsel and John Curran, I
> am inclined to believe that it is not correct and therefore the effect of
> your proposal differs from your
> claimed effects.
> >> 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.
> Yes, I believe that the net price of the transaction will increase
> substantially. Further, the cost of
> needs analysis is built into the ARIN transfer fee which I do not think
> will change significantly
> as a result of this proposal. So, no price reduction and likely price
> increase. Doesn't look like
> a savings to me.
> >>> 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.
> You have already been told multiple times that your interpretation of the
> words "exclusive right to transfer"
> is not correct. The Plzack declaration was substantially modified by later
> rulings in the Kremen case.
> >>> 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.
> It doesn't matter. If they are different organizations, ARIN can't claim
> that they aren't different organizations
> for policy purpose just because it's clear that they were created for the
> purpose of doing an end-run on
> the policy. ARIN must interpret the policy as written, even if that
> interpretation appears absurd, as in
> the case of the single aggregate clause in the transfer policy.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML