<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    However I was told by ARIN, a small ISP like me they could claw back
    any Legacy resources<br>
    I acquired outside of the ARIN system. The big guys aren't
    intimidated by this but we are.<br>
    The money required to even acquire 1 /24 is now big time. And lack
    of a direct allocation<br>
    of IPv6 for $500 is a major obstruction for small ISP's.<br>
    <br>
    <div class="moz-cite-prefix">On 2/19/2016 3:05 PM, Steven Ryerse
      wrote:<br>
    </div>
    <blockquote
      cite="mid:4c441ed1455143799ad02787e79f9120@eclipse-networks.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"MS Mincho";
        panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"Trebuchet MS";
        panose-1:2 11 6 3 2 2 2 2 2 4;}
@font-face
        {font-family:"\@MS Mincho";
        panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
span.im
        {mso-style-name:im;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">If
            ARIN does not have the resources to allocate because of
            runout, how pray tell can an ARIN policy be used to corner
            the market?  You can’t get blood out of a turnip. There is
            nothing to stop someone from buying a Legacy block
            completely outside of ARIN now if they choose to do that.
             We know that current ARIN policies are not stopping brokers
            from doing this - as there is a brisk business of blocks
            being traded in one way or another.  You are just
            rearranging deck chairs on the Titanic which has already
            sunk and is already at the bottom of the sea.  I wonder if
            the fish down there really care where those chairs are
            arranged?
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D">The
            common sense thing to do would be to modify ARINs policies
            to encourage all transactions to go thru ARIN which would
            lead to more supply for everyone.  This would be in line
            with ARIN’s mission to further the Internet. Unfortunately
            common sense rarely prevails in this community.
            <o:p></o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><i><span
              style="font-size:11.0pt;font-family:"Trebuchet
              MS",sans-serif;color:#1F497D">Steven Ryerse<o:p></o:p></span></i></p>
        <p class="MsoNormal"><i><span
              style="font-size:11.0pt;font-family:"Trebuchet
              MS",sans-serif;color:#1F497D">President<o:p></o:p></span></i></p>
        <p class="MsoNormal"><i><span
              style="font-size:11.0pt;font-family:"Trebuchet
              MS",sans-serif;color:#1F497D">100 Ashford Center
              North, Suite 110, Atlanta, GA  30338<o:p></o:p></span></i></p>
        <p class="MsoNormal"><i><span
              style="font-size:11.0pt;font-family:"Trebuchet
              MS",sans-serif;color:#1F497D">770.656.1460 - Cell<o:p></o:p></span></i></p>
        <p class="MsoNormal"><i><span
              style="font-size:11.0pt;font-family:"Trebuchet
              MS",sans-serif;color:#1F497D">770.399.9099- Office<o:p></o:p></span></i></p>
        <p class="MsoNormal"><span
            style="font-size:10.0pt;font-family:"MS
            Mincho";color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><img
              id="Picture_x0020_1"
              src="cid:part1.05070002.09020509@cameron.net"
              alt="Description: Description: Eclipse Networks
              Logo_small.png" height="37" width="56"></span><span
            style="font-size:10.0pt;font-family:"MS
            Mincho";color:#1F497D">℠</span><span
            style="font-size:14.0pt;font-family:"Trebuchet
            MS",sans-serif;color:#1F497D">
          </span><span
            style="font-size:11.0pt;font-family:"Trebuchet
            MS",sans-serif;color:#1F497D">Eclipse Networks, Inc.</span><span
            style="font-size:14.0pt;font-family:"Trebuchet
            MS",sans-serif;color:#1F497D"><o:p></o:p></span></p>
        <p class="MsoNormal" style="text-indent:.5in"><sup><span
              style="font-size:9.0pt;font-family:"Trebuchet
              MS",sans-serif;color:#1F497D">        Conquering
              Complex Networks</span></sup><sup><span
style="font-size:9.0pt;font-family:"Calibri",sans-serif;color:#1F497D">℠</span></sup><sup><span
              style="font-size:9.0pt;font-family:"Trebuchet
              MS",sans-serif;color:#1F497D"><o:p></o:p></span></sup></p>
        <p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D"><o:p> </o:p></span></p>
        <p class="MsoNormal"><b><span
              style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif">
            <a class="moz-txt-link-abbreviated" href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>
            [<a class="moz-txt-link-freetext" href="mailto:arin-ppml-bounces@arin.net">mailto:arin-ppml-bounces@arin.net</a>]
            <b>On Behalf Of </b>Jason Schiller<br>
            <b>Sent:</b> Friday, February 19, 2016 1:08 PM<br>
            <b>To:</b> Randy Carpenter <a class="moz-txt-link-rfc2396E" href="mailto:rcarpen@network1.net"><rcarpen@network1.net></a><br>
            <b>Cc:</b> ARIN PPML <a class="moz-txt-link-rfc2396E" href="mailto:arin-ppml@arin.net"><arin-ppml@arin.net></a><br>
            <b>Subject:</b> Re: [arin-ppml] Draft Policy ARIN-2015-9:
            Eliminating needs-based evaluation for Section 8.2 and 8.3
            transfers of IPv4 netblocks<o:p></o:p></span></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <p class="MsoNormal">Removing barriers would allow companies
            with enough money to out right buy more than a two year
            supply of IPv4 addresses if they believed their likelihood
            of needing a longer time horizon justifies the cost.  They
            could complete the transaction, transfer the address space
            in whole, and use as they desired over whatever time horizon
            they saw fit.<o:p></o:p></p>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">This is different to a buying a future
              where money is paid to hold IPv4 addresses, and make them
              available for sipping from in two year (or less) sized
              increments under the ARIN transfer policy.  This requires
              demonstrating efficient utilization of currently held
              resources, and then only permits a maximum transfer of two
              year supply, after which a new demonstration of efficient
              utilization of currently held resources, and a new two
              year window can be established.  <o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">This second approach has much risk
              associated.  Risk of the transfer source going bankrupt,
              risk of the transfer source breaching the contract, risk
              of the transfer source finding more favorable terms and
              transferring the remaining future to another party, risk
              of the transfer recipient having underutilization and have
              an inability to get additional resources, risk of
              transferring the resources to the wrong OrgID (realizing a
              new use case under one OrgID evaporates, and a different
              new use case appears under a different OrgID).<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <div>
            <p class="MsoNormal">As such, the inherent risk of a future
              will likely limit the spend.<o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal">Reducing or eliminating this risk will
              encourage the behavior.  <o:p></o:p></p>
          </div>
          <div>
            <p class="MsoNormal"> <o:p></o:p></p>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">This is different than just paying
                money to get unlimited use of IPv4 resources outside of
                ARIN policy, with no transfer, and only a letter of
                authority to route the space, a re-allocate or
                re-assignment SWIP, or a public comment indicating who
                has the right of use.  <o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">This third approach has the risk of
                the source going bankrupt and the risk that the source
                could easily revoke the LOA, SWIP or public comment, and
                ask providers to not route the IP space.  It has the
                added reputation risk that the recipient of the IP space
                is acting below board.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">As such risk is even greater than the
                previous case and will likewise have a greater
                limitation on the spend.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">The final case is renting of IPv4
                space.  This differs from the previous case in that the
                spend is ongoing (e.g. monthly or yearly).<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal">The risk is similar to the previous
                case except if the IPv4 addresses are revoked payment is
                stopped.  While the recipient has not lost their future
                spend, they also may find themselves suddenly out of
                IPv4 space.  With the difficulty of renumbering, they
                may find they are forced to pay predatory pricing from
                some period of time, and double rent new IP space while
                they number out of the old (excessively high cost) IPv4
                space. Furthermore, if IPv4 space is not available for
                rent at a reasonable price, they will be locked in to
                paying an unreasonable price.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Due to the uncertainty and
                possibility of lock in and predatory pricing I would
                argue this arrangement is even more risky than the
                previous arrangement if long term (think more than 2
                years) use of IPv4 is desired.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">   <o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal">___Jason<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal">   <o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"> <o:p></o:p></p>
            </div>
          </div>
        </div>
        <div>
          <p class="MsoNormal"><o:p> </o:p></p>
          <div>
            <p class="MsoNormal">On Thu, Feb 18, 2016 at 11:29 PM, Randy
              Carpenter <<a moz-do-not-send="true"
                href="mailto:rcarpen@network1.net" target="_blank">rcarpen@network1.net</a>>
              wrote:<o:p></o:p></p>
            <blockquote style="border:none;border-left:solid #CCCCCC
              1.0pt;padding:0in 0in 0in
              6.0pt;margin-left:4.8pt;margin-right:0in">
              <p class="MsoNormal"><br>
                Are you arguing that by removing the barriers that it
                would make it more difficult for Google to get more
                addresses? If not, then the point is moot.<br>
                <br>
                <br>
                thanks,<br>
                -Randy<o:p></o:p></p>
              <div>
                <div>
                  <p class="MsoNormal"><br>
                    <br>
                    ----- On Feb 18, 2016, at 10:47 PM, Mueller, Milton
                    L <a moz-do-not-send="true"
                      href="mailto:milton@gatech.edu">
                      milton@gatech.edu</a> wrote:<br>
                    <br>
                    > Really. Am I going to have to be the first to
                    point out the irony of Google<br>
                    > employees complaining that companies with "deep
                    pockets" and "the most<br>
                    > profitable services" will dominate the address
                    market if we make minor<br>
                    > relaxations of need assessments?<br>
                    ><br>
                    ><br>
                    ><br>
                    ><br>
                    > What's wrong with this picture? Think, folks.<br>
                    ><br>
                    ><br>
                    ><br>
                    ><br>
                    > Isn't it obvious that companies like Google are
                    in a very good position to get<br>
                    > the addresses they want - via less than
                    transparent market mechanisms such as<br>
                    > options contracts and acquisitions? And isn't
                    it possible that they might be<br>
                    > trying to prevent smaller companies from
                    participating in the market by<br>
                    > throwing up artificial barriers?<br>
                    ><br>
                    ><br>
                    ><br>
                    ><br>
                    > All this talk of "fairness" overlooks the fact
                    that it's more fair to have<br>
                    > simple, transparent bidding and less
                    bureaucracy. Smaller bidders can easily<br>
                    > afford smaller chunks of numbers, and they
                    benefit from the reduced<br>
                    > administrative burden and delays associated
                    with pointless and restrictive<br>
                    > needs assessments. When I hear smaller ISPs who
                    need addresses making Jason's<br>
                    > arguments, I might take them seriously. Until
                    then, no.<br>
                    ><br>
                    ><br>
                    ><br>
                    ><br>
                    ><br>
                    > --MM<br>
                    ><br>
                    ><br>
                    ><br>
                    ><br>
                    > From: <a moz-do-not-send="true"
                      href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>
                    <<a moz-do-not-send="true"
                      href="mailto:arin-ppml-bounces@arin.net">arin-ppml-bounces@arin.net</a>>
                    on behalf of Jason<br>
                    > Schiller <<a moz-do-not-send="true"
                      href="mailto:jschiller@google.com">jschiller@google.com</a>><br>
                    > Sent: Thursday, February 18, 2016 3:11 PM<br>
                    > To: Vaughn Thurman - Swift Systems<br>
                    > Cc: ARIN PPML<br>
                    > Subject: Re: [arin-ppml] Draft Policy
                    ARIN-2015-9: Eliminating needs-based<br>
                    > evaluation for Section 8.2 and 8.3 transfers of
                    IPv4 netblocks<br>
                    > +1 to what MCTim, Owen, and Vaughn said.<br>
                    ><br>
                    > In general I oppose transfers with no need.<br>
                    ><br>
                    > If there are "networks in need of additional
                    IPv4 addresses", surely they should<br>
                    > be able to show this, in accord with long
                    standing practice.<br>
                    ><br>
                    > I'd rather us not move to a situation which
                    enables/encourages speculation and<br>
                    > profit taking (or rent-seeking if you will) in
                    re: IP resource distribution.<br>
                    ><br>
                    > I'd also rather not encourage one competitor in
                    a business segment to be able to<br>
                    > better stockpile addresses and for that to
                    become a competitive advantage<br>
                    > against other providers in the space.
                    Additionally if this is done in a wide<br>
                    > enough scale it can sufficiently lengthen wide
                    spread IPv6 adoption.<br>
                    ><br>
                    > This policy would also allow for companies with
                    the deepest pockets and the most<br>
                    > profitable services to concentrate IPv4 space.
                    I'm not sure that is more "fair"<br>
                    > than the pre-existing framework for "fair".<br>
                    ><br>
                    > __Jason<br>
                    ><br>
                    ><br>
                    ><br>
                    > On Thu, Feb 18, 2016 at 2:32 PM, Vaughn Thurman
                    - Swift Systems <<br>
                    > <a moz-do-not-send="true"
                      href="mailto:vaughn@swiftsystems.com">vaughn@swiftsystems.com</a>
                    > wrote:<br>
                    ><br>
                    ><br>
                    ><br>
                    > +1<br>
                    ><br>
                    > Sent from my mobile device, please forgive
                    brevity and typos.<br>
                    ><br>
                    > On Feb 18, 2016, at 2:16 PM, Owen DeLong < <a
                      moz-do-not-send="true"
                      href="mailto:owen@delong.com"><a class="moz-txt-link-abbreviated" href="mailto:owen@delong.com">owen@delong.com</a></a>
                    > wrote:<br>
                    ><br>
                    ><br>
                    ><br>
                    ><br>
                    > +1 — McTim said it very well.<br>
                    ><br>
                    > Owen<br>
                    ><br>
                    ><br>
                    ><br>
                    ><br>
                    > On Feb 18, 2016, at 10:34 , McTim < <a
                      moz-do-not-send="true"
                      href="mailto:dogwallah@gmail.com"><a class="moz-txt-link-abbreviated" href="mailto:dogwallah@gmail.com">dogwallah@gmail.com</a></a>
                    > wrote:<br>
                    ><br>
                    > I am opposed.<br>
                    ><br>
                    > If there are " networks in need of additional
                    IPv4 addresses", surely they<br>
                    > should be able to show this, in accord with
                    long standing practice.<br>
                    ><br>
                    > I'd rather us not move to a situation which
                    enables/encourages speculation and<br>
                    > profit taking (or rent-seeking if you will) in
                    re: IP resource distribution.<br>
                    ><br>
                    > Regards,<br>
                    ><br>
                    > McTim<br>
                    ><br>
                    ><br>
                    > On Tue, Feb 16, 2016 at 7:12 PM, Leif Sawyer
                    < <a moz-do-not-send="true"
                      href="mailto:lsawyer@gci.com">
                      lsawyer@gci.com</a> > wrote:<br>
                    ><br>
                    ><br>
                    > Good afternoon -<br>
                    ><br>
                    > Based on feedback from Montreal as well as
                    internal discussions, I've reworked<br>
                    > this policy.<br>
                    > AC members and ARIN staff are looking for
                    additional feedback, as well as your<br>
                    > position in terms<br>
                    > of supporting or opposing this draft policy.<br>
                    ><br>
                    > We'll be discussing this policy, as well as any
                    feedback provided on this week's<br>
                    > AC teleconference,<br>
                    > so I'm very appreciative of your input.<br>
                    ><br>
                    > Thanks,<br>
                    ><br>
                    > Leif Sawyer<br>
                    > Shepherd - ARIN-2015-9<br>
                    ><br>
                    > NRPM section 8: <a moz-do-not-send="true"
                      href="https://www.arin.net/policy/nrpm.html#eight"
                      target="_blank">
                      https://www.arin.net/policy/nrpm.html#eight</a><br>
                    ><br>
                    > Most current draft policy text follows:<br>
                    > --<br>
                    ><br>
                    > Draft Policy ARIN-2015-9<br>
                    > Eliminating needs-based evaluation for Section
                    8.2 and 8.3 transfers of IPv4<br>
                    > netblocks<br>
                    > Original Date: 23 September 2015<br>
                    > Updated: 16 February, 2016<br>
                    ><br>
                    > Problem statement:<br>
                    > The current needs-based evaluation language in
                    NRPM sections 8.2 and 8.3,<br>
                    > regarding transfer of IPv4<br>
                    > netblocks from one organization to another, may
                    cause a recipient organization<br>
                    > to bypass the ARIN<br>
                    > registry entirely in order to secure the needed
                    IPv4 netblocks in a more timely<br>
                    > fashion directly from the<br>
                    > current holder. The result is that the data
                    visible in ARIN registry may become<br>
                    > more inaccurate over<br>
                    > time.<br>
                    ><br>
                    > Policy statement:<br>
                    > This proposal eliminates all needs-based
                    evaluation language for sections 8.2<br>
                    > and 8.3, allowing<br>
                    > transfers to be reflected in the database as
                    they occur following an agreement<br>
                    > of transfer from the<br>
                    > resource provider to the recipient.<br>
                    ><br>
                    > Section 8.1 Principles:<br>
                    > - Strike the fragment from the 3rd paragraph
                    which reads<br>
                    > ", based on justified need, "<br>
                    > so the resulting text reads<br>
                    > "Number resources are issued to organizations,
                    not to individuals representing<br>
                    > those organizations."<br>
                    > Section 8.2 Mergers and Acquisitions:<br>
                    > - Change the 4th bullet from:<br>
                    > "The resources to be transferred will be
                    subject to ARIN policies."<br>
                    > to:<br>
                    > "The resources to be transferred will be
                    subject to ARIN policies, excluding any<br>
                    > policies related to needs-based justification."<br>
                    ><br>
                    > - Strike the final paragraph which begins "In
                    the event that number resources of<br>
                    > the combined organizations are no longer
                    justified under ARIN policy ..."<br>
                    ><br>
                    > Section 8.3 Transfers between Specified
                    Recipients within the ARIN Region:<br>
                    > - Change the first bullet under "Conditions on
                    recipient of the transfer" from:<br>
                    > "The recipient must demonstrate the need for up
                    to a 24-month supply of IP<br>
                    > address resources under current ARIN policies
                    and sign an RSA."<br>
                    > to:<br>
                    > "The recipient must sign an RSA."<br>
                    ><br>
                    > - Change the 2nd bullet under "Conditions on
                    recipient of the transfer" from:<br>
                    > "The resources to be transferred will be
                    subject to ARIN policies."<br>
                    > to:<br>
                    > "The resources to be transferred will be
                    subject to ARIN policies, excluding any<br>
                    > policies related to needs-based justification."<br>
                    ><br>
                    > Comments:<br>
                    > a. Timetable for implementation: Immediate<br>
                    > b. Anything else<br>
                    > As the "free pool" for 4 of the 5 world's RIR's
                    (APNIC, RIPE, LACNIC, and ARIN)<br>
                    > have now been<br>
                    > exhausted, networks in need of additional IPv4
                    addresses have shifted away from<br>
                    > the practice of<br>
                    > receiving them from the RIR's resource pool.
                    Instead, networks in need are<br>
                    > seeking out current holders<br>
                    > of IPv4 resources who are willing to transfer
                    them in order to fulfill that<br>
                    > need. Accordingly, the RIR's<br>
                    > primary responsibility vis-à-vis IPv4 netblock
                    governance has shifted from<br>
                    > "allocation" to ensuring an<br>
                    > accurate registry database.<br>
                    ><br>
                    > The RIPE registry can be used as a reference of
                    one which has evolved over the<br>
                    > past couple years to<br>
                    > shift their focus away from
                    conservation/allocation and towards database<br>
                    > accuracy. IPv4 netblock<br>
                    > transfers within that RIR consist merely of
                    validating authenticity of the<br>
                    > parties requesting a transfer.<br>
                    > Provided the organizations meet the basic
                    requirement of RIR membership, and<br>
                    > that the transferring<br>
                    > organization has the valid authority to request
                    the transfer, the transaction<br>
                    > completes without any<br>
                    > "needs-based" review.<br>
                    ><br>
                    > _______________________________________________<br>
                    > PPML<br>
                    > You are receiving this message because you are
                    subscribed to<br>
                    > the ARIN Public Policy Mailing List ( <a
                      moz-do-not-send="true"
                      href="mailto:ARIN-PPML@arin.net"><a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a></a>
                    ).<br>
                    > Unsubscribe or manage your mailing list
                    subscription at:<br>
                    > <a moz-do-not-send="true"
                      href="http://lists.arin.net/mailman/listinfo/arin-ppml"
                      target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
                    > Please contact <a moz-do-not-send="true"
                      href="mailto:info@arin.net">info@arin.net</a> if
                    you experience any issues.<br>
                    ><br>
                    ><br>
                    ><br>
                    > --<br>
                    > Cheers,<br>
                    ><br>
                    > McTim<br>
                    > "A name indicates what we seek. An address
                    indicates where it is. A route<br>
                    > indicates how we get there." Jon Postel<br>
                    > _______________________________________________<br>
                    > PPML<br>
                    > You are receiving this message because you are
                    subscribed to<br>
                    > the ARIN Public Policy Mailing List ( <a
                      moz-do-not-send="true"
                      href="mailto:ARIN-PPML@arin.net"><a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a></a>
                    ).<br>
                    > Unsubscribe or manage your mailing list
                    subscription at:<br>
                    > <a moz-do-not-send="true"
                      href="http://lists.arin.net/mailman/listinfo/arin-ppml"
                      target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
                    > Please contact <a moz-do-not-send="true"
                      href="mailto:info@arin.net">info@arin.net</a> if
                    you experience any issues.<br>
                    ><br>
                    ><br>
                    ><br>
                    ><br>
                    > _______________________________________________<br>
                    > PPML<br>
                    > You are receiving this message because you are
                    subscribed to<br>
                    > the ARIN Public Policy Mailing List ( <a
                      moz-do-not-send="true"
                      href="mailto:ARIN-PPML@arin.net"><a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a></a>
                    ).<br>
                    > Unsubscribe or manage your mailing list
                    subscription at:<br>
                    > <a moz-do-not-send="true"
                      href="http://lists.arin.net/mailman/listinfo/arin-ppml"
                      target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
                    > Please contact <a moz-do-not-send="true"
                      href="mailto:info@arin.net">info@arin.net</a> if
                    you experience any issues.<br>
                    ><br>
                    > _______________________________________________<br>
                    > PPML<br>
                    > You are receiving this message because you are
                    subscribed to<br>
                    > the ARIN Public Policy Mailing List ( <a
                      moz-do-not-send="true"
                      href="mailto:ARIN-PPML@arin.net"><a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a></a>
                    ).<o:p></o:p></p>
                </div>
              </div>
              <p class="MsoNormal"><span class="im">> Unsubscribe or
                  manage your mailing list subscription at:</span><br>
                <span class="im">> <a moz-do-not-send="true"
                    href="http://lists.arin.net/mailman/listinfo/arin-ppml"
                    target="_blank">
                    http://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br>
                <span class="im">> Please contact <a
                    moz-do-not-send="true" href="mailto:info@arin.net"><a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a></a>
                  if you experience any issues.</span><br>
                <span class="im">></span><br>
                <span class="im">></span><br>
                <span class="im">></span><br>
                <span class="im">> --</span><br>
                <span class="im">>
                  _______________________________________________________</span><br>
                <span class="im">> Jason Schiller|NetOps| <a
                    moz-do-not-send="true"
                    href="mailto:jschiller@google.com"><a class="moz-txt-link-abbreviated" href="mailto:jschiller@google.com">jschiller@google.com</a></a>
                  |<a moz-do-not-send="true" href="tel:571-266-0006">571-266-0006</a></span><br>
                <span class="im">></span><br>
                <span class="im">></span><o:p></o:p></p>
              <div>
                <div>
                  <p class="MsoNormal">>
                    _______________________________________________<br>
                    > PPML<br>
                    > You are receiving this message because you are
                    subscribed to<br>
                    > the ARIN Public Policy Mailing List (<a
                      moz-do-not-send="true"
                      href="mailto:ARIN-PPML@arin.net"><a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a></a>).<br>
                    > Unsubscribe or manage your mailing list
                    subscription at:<br>
                    > <a moz-do-not-send="true"
                      href="http://lists.arin.net/mailman/listinfo/arin-ppml"
                      target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
                    > Please contact <a moz-do-not-send="true"
                      href="mailto:info@arin.net">info@arin.net</a> if
                    you experience any issues.<br>
                    _______________________________________________<br>
                    PPML<br>
                    You are receiving this message because you are
                    subscribed to<br>
                    the ARIN Public Policy Mailing List (<a
                      moz-do-not-send="true"
                      href="mailto:ARIN-PPML@arin.net"><a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a></a>).<br>
                    Unsubscribe or manage your mailing list subscription
                    at:<br>
                    <a moz-do-not-send="true"
                      href="http://lists.arin.net/mailman/listinfo/arin-ppml"
                      target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
                    Please contact <a moz-do-not-send="true"
                      href="mailto:info@arin.net">info@arin.net</a> if
                    you experience any issues.<o:p></o:p></p>
                </div>
              </div>
            </blockquote>
          </div>
          <p class="MsoNormal"><br>
            <br clear="all">
            <o:p></o:p></p>
          <div>
            <p class="MsoNormal"><o:p> </o:p></p>
          </div>
          <p class="MsoNormal">-- <o:p></o:p></p>
          <div>
            <div>
              <p class="MsoNormal"><span
                  style="font-family:"Courier
                  New";color:#555555">_______________________________________________________</span><span
style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
              <div>
                <p class="MsoNormal"><span
                    style="font-family:"Courier
                    New";color:black">Jason Schiller|NetOps|<a
                      moz-do-not-send="true"
                      href="mailto:jschiller@google.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:jschiller@google.com">jschiller@google.com</a></a>|571-266-0006</span><span
style="font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
              </div>
              <div>
                <p class="MsoNormal"><span
                    style="font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></p>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</pre>
    </blockquote>
    <br>
  </body>
</html>