<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content="text/html; charset=iso-8859-1" http-equiv=Content-Type>
<META name=GENERATOR content="MSHTML 8.00.6001.19046">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2 face=Arial>Hi Rudolph,</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I considered restricting this proposal to legacy 
transfers, and I think these are the most fraught with trouble for Whois due to 
the uncertain legal rights that legacy holders have to transfer addresses 
without notifying ARIN.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Right now it is not ARIN policy that the seller of 
legacy addresses is required to sign an LRSA, but the purchaser must sign some 
form of RSA.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I decided to try to extend this policy to include 
addresses currently under RSA in an attempt to bring RSA holder rights more in 
alignment with those of legacy holders, by removing the utilization requirement 
for addresses held under RSA for 12 months.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>I just think that overall, it would make for a 
better future if we can end the class schism between legacy and non-legacy 
holders. It seems that ARIN's yearslong efforts to induce legacy holders to sign 
an LRSA have borne little fruit, so I attempted to increase the inducement to 
legacy buyers to sign an RSA, not an LRSA, when they make a purchase. 
</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Since this would give legacy address buyers the 
right to resell their addresses to anybody, and the right to purchase 
needs-free, it was my intention that these buyers would see registration in 
Whois as outweighing any negative effect of signing an RSA.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>But maybe I bit off too much, and I should have 
limited my proposal to recognizing needs-free transfers of legacy holders 
only.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>But I suppose my answer to your question is if we 
allow the legacy buyer to purchase needs-free, but require them to sign an RSA 
which currently gives ARIN the right to revoke for underutilization, the 
needs-free aspect is threatened by an immediate post-purchase revokation by 
ARIN.</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>Regards,</FONT></DIV>
<DIV><FONT size=2 face=Arial>Mike</FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000000 2px solid; PADDING-LEFT: 5px; PADDING-RIGHT: 0px; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px">
  <DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV 
  style="FONT: 10pt arial; BACKGROUND: #e4e4e4; font-color: black"><B>From:</B> 
  <A title=rudi.daniel@gmail.com href="mailto:rudi.daniel@gmail.com">Rudolph 
  Daniel</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>To:</B> <A title=arin-ppml@arin.net 
  href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</A> </DIV>
  <DIV style="FONT: 10pt arial"><B>Sent:</B> Saturday, May 21, 2011 11:24 
  AM</DIV>
  <DIV style="FONT: 10pt arial"><B>Subject:</B> Re: [arin-ppml] IPv4 Transfer 
  Policy Change</DIV>
  <DIV><BR></DIV><BR><BR>
  <DIV>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. </DIV>
  <DIV>rd</DIV>
  <DIV><BR></DIV>
  <DIV><BR>
  <DIV class=gmail_quote>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" 
  class=gmail_quote>No, this is an incorrect understanding of the ruling. The 
    Plzak declaration is also<BR>not the final word on the subject. The 
    exclusive right to transfer means that nobody<BR>else has the right to 
    transfer them. It does not mean that they can be transfered<BR>regardless of 
    policy or that ARIN must recognize a transfer outside of policy in 
    the<BR>ARIN database.<BR><BR>Legacy addresses were issued to a particular 
    party for a particular purpose. Upon the end<BR>of that purpose or that 
    party, they should be returned and are no longer legacy addresses.<BR>In the 
    case of a transfer to a successor in interest through acquisition or merger, 
    in some<BR>cases, the legacy status has been preserved, but, this is rare. 
    In most cases, the receiving<BR>organization has been required to sign an 
    ARIN standard RSA.<BR><BR>It works this way... Legacy status is the 
    intersection of the holder and the resources which<BR>were registered 
    together by a registry preceding the RIR system. Once either of 
    those<BR>conditions ceases, the resources are no longer in legacy status (in 
    most cases).<BR><BR>ARIN has an obligation to continue providing services to 
    records with legacy status so long<BR>as that legacy status remains under 
    the original terms of issue.<BR><BR>ARIN has the right to reclaim addresses 
    from defunct legacy organizations.<BR><BR>> Given this, legal legacy 
    transfers can occur where the purchased amount may not meet ARIN's need 
    requirement.<BR><BR>Not true. At least not if they want to be recognized by 
    ARIN and have the transfer registered<BR>in whois.<BR><BR>> 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.<BR><BR>The unregistered addresses become subject 
    to reclamation since they are no longer in<BR>use by the original 
    organization under the original terms of issue.<BR><BR>> But if there is 
    no needs requirement, the disincentive is removed, the registration takes 
    place, and the buyer signs an RSA.<BR><BR>Ah, so you are once again 
    confusing incentive with removal of disincentive. I can see how, to a 
    limited extent, this<BR>might provide less of a disincentive for the 
    recipient of a transfer from a legacy holder to register the transfer, 
    but,<BR>I don't see how this is anything other than redundant to your point 
    1.<BR><BR>> 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).<BR><BR>Yes, by neutering the RSA, you have 
    removed some disincentives to sign it. However, I don't see neutering the 
    RSA<BR>as a net positive in that regard. The community put section 12 into 
    policy for a reason.<BR><BR>> 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.<BR><BR>There is no such thing as a legacy transfer. There is a 
    transfer of resources from a legacy holder, but, absent an<BR>awkward 
    situation involving litigation these will almost always result in the space 
    being handled as non-legacy<BR>if the transfer is recognized by 
    ARIN.<BR><BR>><BR>> Remember, these are the intentions of the 
    proposal, although I know you disagree with my legal interpretation, and 
    thus the effect.<BR>><BR><BR>Yes... Your legal interpretation being 
    contrary to statements made by ARIN counsel and John Curran, I<BR>am 
    inclined to believe that it is not correct and therefore the effect of your 
    proposal differs from your<BR>claimed effects.<BR><BR>><BR>>> 3. 
    Provides for explicit protections against review audits for RSA holders 
    after one year, bringing RSA rights more in accord with LRSA 
    rights.<BR>><BR>>> Uh, yeah, I don't see that as a good thing. 
    Quite the opposite. However, I do agree that it is an intended<BR>>> 
    consequence of the proposal.<BR>><BR>>>> 4. Reduces transaction 
    costs for transferers<BR>><BR>>> I believe it will actually 
    increase them.<BR>><BR>> 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.<BR>><BR><BR>Yes, I believe that the net price of the 
    transaction will increase substantially. Further, the cost of<BR>needs 
    analysis is built into the ARIN transfer fee which I do not think will 
    change significantly<BR>as a result of this proposal. So, no price reduction 
    and likely price increase. Doesn't look like<BR>a savings to 
    me.<BR><BR>>>> 5. Reduces ARIN costs for needs 
    analyses<BR>><BR>>> Agreed, but, not necessarily something I see as 
    a beneficial aspect.<BR>><BR>><BR>>>> 6. Aligns ARIN policy 
    with most possible interpretations of the legal rights of legacy 
    holders<BR>><BR>>> No, aligns ARIN policy with one possible 
    interpretation of the legal rights of legacy holders.<BR>>> IMHO, not 
    even the most probable one.<BR>><BR>> See "exclusive right to 
    transfer" and the Plzak declaration that ARIN has no authority over legacy 
    addresses.<BR>> Would it be fair to say "Aligns ARIN policy with legal 
    interpretation most friendly to legacy holders?"<BR>> My point being this 
    alignment presents the lowest risk toARIN of being sued for tortious 
    interference in a contract.<BR>><BR><BR>You have already been told 
    multiple times that your interpretation of the words "exclusive right to 
    transfer"<BR>is not correct. The Plzack declaration was substantially 
    modified by later rulings in the Kremen case.<BR><BR>>>> 7. Imposes 
    a yearly limit on needs-free transactions intended to prevent 
    cornering.<BR>><BR>>> Yes, but, this limit is effectively a no-op 
    because anyone can create multiple entities needed<BR>>> to accomplish 
    enough /12 transfers to meet their desires.<BR>><BR>> I trust ARIN 
    staff to detect these with the same diligence applied to needs tests and 
    section 12 reviews.<BR>><BR><BR>It doesn't matter. If they are different 
    organizations, ARIN can't claim that they aren't different 
    organizations<BR>for policy purpose just because it's clear that they were 
    created for the purpose of doing an end-run on<BR>the policy. ARIN must 
    interpret the policy as written, even if that interpretation appears absurd, 
    as in<BR>the case of the single aggregate clause in the transfer 
  policy.<BR></BLOCKQUOTE></DIV></DIV>
  <P>
  <HR>

  <P></P>_______________________________________________<BR>PPML<BR>You are 
  receiving this message because you are subscribed to<BR>the ARIN Public Policy 
  Mailing List (ARIN-PPML@arin.net).<BR>Unsubscribe or manage your mailing list 
  subscription at:<BR>http://lists.arin.net/mailman/listinfo/arin-ppml<BR>Please 
  contact info@arin.net if you experience any issues.</BLOCKQUOTE></BODY></HTML>