<!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>