<!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>
<DIV><FONT size=4 face=Fixedsys>Hello,</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>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:</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>8. REVIEW OF APPLICANT’S NUMBER RESOURCES </DIV>
<DIV>
<P>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. </P></FONT></DIV>
<DIV><FONT size=2 face=Fixedsys>(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.)</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>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.)</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>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. </FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>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.</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>I agree with John Curran's posting this week 
about simplifying transfer requirements, and have retained the /24 minimum 
for the reasons he mentioned.</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>Regards,</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>Mike Burns</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>1. Policy Proposal Name: New IPv4 Transfer 
policy</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>2. Proposal Originator:</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys>      a. Name: Mike 
Burns</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys>      b. Email: 
</FONT><A href="mailto:mike@sum.net"><FONT size=4 
face=Fixedsys>mike@sum.net</FONT></A></DIV>
<DIV><FONT size=4 face=Fixedsys>      c. Phone: 
1-863-494-7692 x105</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys>      d. Organization: 
Nationwide Computer Systems</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>3. Proposal Version: 1</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>4. Date: May 9th, 2011</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>5. Proposal type: modify</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>6. Policy term: permanent</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>7. Policy statement:</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>Replace Section 8.3 with </FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>8.3 ARIN will process and record IPv4 address 
transfer requests.</FONT></DIV>
<DIV><BR><FONT size=4 face=Fixedsys>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</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys></FONT> </DIV>
<DIV><FONT size=4 face=Fixedsys>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.</FONT></DIV><FONT size=4 face=Fixedsys></FONT></DIV>
<DIV><FONT size=4 face=Fixedsys>
<DIV><FONT size=2 face=Arial></FONT> </DIV>
<DIV><FONT size=2 face=Arial>      <FONT 
face=Fixedsys> - The source entity must not have received an 
allocation from ARIN for the 12 months prior to the 
transfer.</FONT></FONT></DIV>
<DIV><FONT size=2 face=Arial></FONT><BR><BR>  Conditions on recipient 
of the transfer:<BR><BR>    - The recipient entity must be a 
current ARIN account holder.</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys>      If the addresses 
being transferred are under RSA, the recipient must sign an RSA with 
ARIN.</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys>      If the 
addresses being transferred are under LRSA, the recipient must sign an LRSA or 
an RSA with ARIN.</FONT></DIV>
<DIV><FONT size=4 face=Fixedsys>      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</FONT></DIV>
<DIV><FONT face=Fixedsys><FONT size=4>      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></FONT></FONT></DIV>
<DIV><FONT size=4></FONT> </DIV>
<DIV><FONT size=4><FONT size=2 face=Fixedsys>and modify section 12.8 of the 
current RSA to remove references to "intended purposes."</FONT></FONT></DIV>
<DIV><FONT size=4><FONT size=2 face=Fixedsys>  </FONT></FONT></DIV>
<DIV><FONT size=4><FONT size=2 face=Fixedsys>Replace</FONT></FONT></DIV>
<DIV><FONT size=4><FONT size=2>
<P><FONT face=Fixedsys>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. 
</FONT></P>
<P><FONT face=Fixedsys>with</FONT></P><FONT size=2 face=Fixedsys>
<P><FONT face=Fixedsys>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.</FONT></P>
<P><FONT face=Fixedsys></FONT> </P></FONT></FONT></FONT><FONT 
face=Fixedsys><FONT size=4></FONT></FONT></DIV></DIV>
<DIV><FONT face=Fixedsys><FONT size=4><FONT size=2 
face=Arial></FONT> </DIV>
<DIV><BR></FONT><FONT size=2>8. Rationale: </FONT></DIV>
<DIV></FONT> </DIV>
<DIV><FONT face=Fixedsys>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 
</FONT></DIV>
<DIV><FONT face=Fixedsys>sign either an RSA or LRSA with ARIN and subject the 
buyer</FONT></DIV>
<DIV><FONT face=Fixedsys>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 </FONT></DIV>
<DIV><FONT face=Fixedsys>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.</FONT></DIV>
<DIV><FONT face=Fixedsys></FONT> </DIV>
<DIV><FONT size=2 face=Fixedsys>9. Timetable for implementation: 
immediate.</FONT></DIV>
<DIV><FONT size=2 face=Fixedsys></FONT> </DIV></BODY></HTML>