<html><body bgcolor="#FFFFFF"><div>Ask ARIN and/or Microsoft?<br><br>Matthew Kaufman<div><br>(Sent from my iPhone)</div></div><div><br>On May 9, 2011, at 1:04 PM, Rudolph Daniel <<a href="mailto:rudi.daniel@gmail.com">rudi.daniel@gmail.com</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div><br>I may have missed something here, but why is it not possible to dump LSRA and have all transfers..whether LSRA, RSA. or neither...become a mandatory RSA signing on transfer ? with a note to the effect: <span class="Apple-style-span" style="border-collapse: collapse; color: rgb(72, 72, 72); font-family: 'Lucida Grande', Verdana, sans-serif; font-size: 12px; line-height: 18px; ">"Note that ARIN will not reclaim unutilized v4 address space from legacy holders. </span><div>
<br></div><div>RD<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Date: Mon, 9 May 2011 15:15:06 -0400<br>
From: "Mike Burns" <<a href="mailto:mike@nationwideinc.com"><a href="mailto:mike@nationwideinc.com">mike@nationwideinc.com</a></a>><br><br>
Hello,<br>
<br>
Upon feedback to my first draft proposal whose intent is to lift needs requirements for all IPv4 transfers, I have made some changes to my draft proposal.<br>
<br>
One of the issues was the idea that if I made no changes to section 12, that ARIN could do a resource review of the transferree and if they determined the addresses were not being used, could request them to be returned.<br>
<br>
I have read section 12 of the NRPM, and could find no language that gives ARIN that right. Basically section 12 is about fraud and about compliance with existing policy, but there is no existing policy that I could find requiring anything like efficient utilization of allocations, except in reference to a new or subsequent allocation. But once an allocation is made, I could find no policy requiring efficient utilization of that block if no further allocation request is made.<br>
<br>
On the other hand, the current RSA has clear language in section 8 that allows ARIN to review previous allocations and allows ARIN to determine if their use is consistent with the intended purpose as presented on the application at the time of the allocation request:<br>
<br>
8. REVIEW OF APPLICANT'S NUMBER RESOURCES<br>
ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement.<br>
<br>
(To my reading, if you got an allocation in 2001 for web hosting purposes, and now you are using the addresses to provide DSL service, ARIN could revoke them for not being used for purposes consistent with the Applicant's application unless you notify them and get approval. But let's leave that aside.)<br>
<br>
Since my overarching purpose is to bring as much supply into the market as possible, I don't want any old allocations to stay unused on the shelf because the holder is afraid of a recovery action.<br>
<br>
But if section 12 does not allow ARIN to make a resource finding requesting return of addresses merely for underutilization, and if we remove the language in the RSA allowing ARIN to recover based on compliance with intended use, then an entity could totally fake a justification and get a new allocation today, and turn around tomorrow and list the addreses for sale, and ARIN wouldn't have any teeth with which to revoke the addresses. (Unless of course they could show the justification part of the application was fraudulent.)<br>
<br>
In order to preclude that, I have added a new source requirement to the source entity for transfers, that they may not have received an ARIN allocation for at least 12 months prior to the transfer.<br>
<br>
In addition, in my new draft proposal I retained the 8.2 transfer mechanism, which can still be used for ASN and IPv6 transfers via mergers and acquisitions.<br>
<br>
I also added language forcing no downgrading of current agreement status which covers the transferred addresses, i.e. RSA to RSA, LRSA to LRSA or RSA, no agreement to no agreement or LRSA.<br>
<br>
In my rationale, I have limited myself to the benefits of whois accuracy which will inure from the greater likelihood that all past and future transfers will be registered.<br>
<br>
>From the discussion, you know that I believe that stewardship demands that we make policy to ensure whois reliablity in the face of a new paradigm for IPv4 distribution. IPv4 addresses will change hands in a variety of transaction types. If those who engage in these transactions do not choose to have ARIN update whois to reflect them, we run the risk of whois irrelevance and provide the vacuum in to which competitive registries will step, with or without global community authority. If transactors find little cost in having ARIN update whois to reflect the transfer, they are more likely to request that ARIN make the update. If the transaction cost is high, fewer will make that request, leading to a less and less reliable whois, which could degrade to the point where network operators choose a more reliable registry. This kind of chaos in the core of the Internet would be an indictment of ARIN stewardship.<br>
<br>
We will run out of free pool addresses shortly. At that point we will not be stewards of those addresses anymore. We will, however, retain our stewardship role towards maintaining whois as an authoritative source for routing authority. Prior to exhaust, it was possible to ignore whois, as conflicts over address control were unlikely when "free" addresses were available. In the post-exahaust world, where address control conflict is likely to increase, it is all the more important that whois be a trusted and accurate information source.<br>
<br>
Now it could be that I have misread section 12, I know I heard from more than one person that ARIN could revoke for underutilization. If you can point me to what I am missing, then maybe I will have to monkey with section 12. My hope is that by simply changing 8.3 and the RSA I can avoid that.<br>
<br>
I agree with John Curran's posting this week about simplifying transfer requirements, and have retained the /24 minimum for the reasons he mentioned.<br>
<br>
Regards,<br>
<br>
Mike Burns<br>
<br>
1. Policy Proposal Name: New IPv4 Transfer policy<br>
<br>
2. Proposal Originator:<br>
a. Name: Mike Burns<br>
b. Email: <a href="mailto:mike@sum.net"><a href="mailto:mike@sum.net">mike@sum.net</a></a><br>
c. Phone: <a href="tel:1-863-494-7692" value="+18634947692">1-863-494-7692</a> x105<br>
d. Organization: Nationwide Computer Systems<br>
<br>
3. Proposal Version: 1<br>
<br>
4. Date: May 9th, 2011<br>
<br>
5. Proposal type: modify<br>
<br>
6. Policy term: permanent<br>
<br>
7. Policy statement:<br>
<br>
Replace Section 8.3 with<br>
<br>
8.3 ARIN will process and record IPv4 address transfer requests.<br>
<br>
Conditions on the IPv4 address block:<br>
<br>
- The minimum transfer size is a /24<br>
<br>
- The address block must be in the range of addresses administered<br>
by ARIN<br>
<br>
Conditions on source of the transfer:<br>
<br>
- The source entity must be the current rights holder of the<br>
IPv4 address resources, and not be involved in any dispute as to<br>
the status of those resources.<br>
<br>
- The source entity will be ineligible to receive any further IPv4<br>
address allocations or assignments from ARIN for a period of 12<br>
months after the transfer, or until the exhaustion of ARIN's<br>
IPv4 space, whichever occurs first.<br>
<br>
- The source entity must not have received an allocation from ARIN for the 12 months prior to the transfer.<br>
<br>
<br>
Conditions on recipient of the transfer:<br>
<br>
- The recipient entity must be a current ARIN account holder.<br>
If the addresses being transferred are under RSA, the recipient must sign an RSA with ARIN.<br>
If the addresses being transferred are under LRSA, the recipient must sign an LRSA or an RSA with ARIN.<br>
If the addresses being transferred are legacy addresses under no form of RSA, recipient may choose to sign an LRSA, but will not be required to do so.<br>
<br>
- The recipient entity of the transferred resources will be subject<br>
to current ARIN policies. In particular, in any subsequent ARIN<br>
IPv4 address allocation request, the recipient will be required<br>
to account for the efficient utilization of all IPv4 address<br>
space held, including all transferred resources.<br>
<br>
<br>
and modify section 12.8 of the current RSA to remove references to "intended purposes."<br>
<br>
Replace<br>
ARIN may review, at any time, Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies and is using the Services for their intended purposes. Without limiting the foregoing, if Applicant is a holder of a direct allocation or assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with its application and this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement, the Policies, or the purposes for which they are intended, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement.<br>
<br>
with<br>
<br>
ARIN may review, at any time, any Applicant's use of previously allocated or assigned number resources or Services received from ARIN to determine if Applicant is complying with this Agreement and the Policies. Without limiting the foregoing, if Applicant is a holder of a direct allocation or direct assignment from ARIN, Applicant agrees that it will use the number resources solely for uses consistent with this Agreement, including, for example, its internal infrastructure or to provide Internet access to its customer base. If ARIN determines that the number resources or any other Services are not being used in compliance with this Agreement or the Policies, ARIN may: (i) revoke the number resources; (ii) cease providing the Services to Applicant; and/or (iii) terminate this Agreement.<br>
<br>
<br>
<br>
<br>
<br>
8. Rationale:<br>
<br>
Current ARIN policies relating to the registration of transfer of<br>
address holdings limit the eligibility of registration of transfers to<br>
those relating to mergers and acquisitions of entities that are<br>
administering an operational network, or to those who agree to<br>
sign either an RSA or LRSA with ARIN and subject the buyer<br>
to needs analysis and the seller to a potential ARIN review under RSA section 8.<br>
<br>
It is currently anticipated that the IPv4 unallocated address pool<br>
will be exhausted within a couple of years at ARIN, and earlier<br>
than that in other regions, and the transition to IPv6-based service delivery<br>
is likely to take longer than the remaining period of unallocated<br>
address availability. Accordingly, it is likely that demand for IPv4<br>
addresses will continue beyond the time of unallocated address pool<br>
exhaustion, leading to a period of movement of IPv4 address blocks<br>
between address holders to meet such continuing demand for IPv4<br>
address blocks.<br>
<br>
The underlying proposition behind this policy proposal is that the<br>
registry of IPv4 addresses operated by ARIN is of general utility and<br>
value only while it accurately describes the current state of address<br>
distribution. If a class of address movement transactions are excluded<br>
from being entered in the registry, then the registry will have<br>
decreasing value to the broader community, and the integrity of the<br>
network itself is thereby compromised. This proposal's central aim is<br>
to ensure the continuing utility and value of the ARIN address<br>
registry by allowing the registry to record transactions where IPv4<br>
addresses are transfered between ARIN account holders.<br>
<br>
It proposes that ARIN will recognise and register a transfer of<br>
addresses where the parties to the transfer are 'known' to ARIN and<br>
that the address block being transferred is part of ARIN's current address set.<br>
<br>
The proposal does not prescribe how such transfers may occur, nor<br>
impose any further constraints on the transfer or on the parties<br>
involved other than those described in this proposal.<br>
<br>
9. Timetable for implementation: immediate.<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20110509/021902b0/attachment.html" target="_blank"><a href="http://lists.arin.net/pipermail/arin-ppml/attachments/20110509/021902b0/attachment.html">http://lists.arin.net/pipermail/arin-ppml/attachments/20110509/021902b0/attachment.html</a></a>><br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
ARIN-PPML mailing list<br>
<a href="mailto:ARIN-PPML@arin.net"><a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a></a><br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank"><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></a><br>
<br>
End of ARIN-PPML Digest, Vol 71, Issue 99<br>
*****************************************<br>
</blockquote></div><div><div><div><font class="Apple-style-span" size="4"><br></font></div></div></div>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>PPML</span><br><span>You are receiving this message because you are subscribed to</span><br><span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).</span><br><span>Unsubscribe or manage your mailing list subscription at:</span><br><span><a href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br><span>Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</span></div></blockquote></body></html>