<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html;
      charset=windows-1252">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Hello Mike</p>
    <p>What about new entrants ? I firmly see that new entrants and the
      most important to be looked at as having a minimal allocation from
      the RIR is the bare minimal condition for them to exist in the
      Internet in first place and do minimal business, therefore any
      recovered addresses should be prioritized to be given to these new
      entrants. After that in terms of importance comes the 4.10 and 4.4
      sections that are equally important as they apply to Autonomous
      Systems that already exist in the Internet. As mentioned 4.10
      doesn't necessarily apply to all types of ISP or End-users.<br>
      If new entrants are not privileged with any space that ARIN has to
      distribute they become an ASN, receive a IPv6 and must go to
      market to get *any* IPv4 space which would be not only unfair with
      them but also but a quiet big block for them to exist as business.</p>
    <p>Therefore I can only support this draft if it's changed to
      reflect this scenario.</p>
    <p>Best regards<br>
      Fernando Frediani<br>
    </p>
    <div class="moz-cite-prefix">On 29/07/2019 18:32, Mike Burns wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:00df01d54655$228eb540$67ac1fc0$@iptrading.com">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <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:"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:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-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;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.emailquote, li.emailquote, div.emailquote
        {mso-style-name:emailquote;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:1.0pt;
        border:none;
        padding:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.xmsonormal, li.xmsonormal, div.xmsonormal
        {mso-style-name:x_msonormal;
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle22
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;
        font-weight:normal;
        font-style:normal;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@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">Hi Mike,<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">My purpose in authoring this proposal was
          to starve the Waiting list to death by preventing further
          unpredictable influxes of addresses.<o:p></o:p></p>
        <p class="MsoNormal">I would support allocating returned
          addresses to both 4.10 and 4.4 pools, or whichever might need
          them most.<o:p></o:p></p>
        <p class="MsoNormal">I know the 4.10 pool is largely untapped,
          but I’m not sure about the 4.4 pool, so maybe it would be
          better to place returned space there.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Regards,<br>
          Mike<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b>From:</b> ARIN-PPML
              <a class="moz-txt-link-rfc2396E" href="mailto:arin-ppml-bounces@arin.net"><arin-ppml-bounces@arin.net></a> <b>On Behalf Of </b>Mike
              Arbrouet<br>
              <b>Sent:</b> Monday, July 29, 2019 5:03 PM<br>
              <b>To:</b> Fernando Frediani <a class="moz-txt-link-rfc2396E" href="mailto:fhfrediani@gmail.com"><fhfrediani@gmail.com></a>;
              <a class="moz-txt-link-abbreviated" href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a><br>
              <b>Subject:</b> Re: [arin-ppml] Draft Policy ARIN-2019-17:
              Returned Addresses to the 4.10 Reserved Pool<o:p></o:p></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <div id="x_divtagdefaultwrapper">
            <div>
              <p class="MsoNormal"><span
                  style="font-size:12.0pt;color:black">Having read
                  the Problem Statement and understood what is being
                  proposed, I'd kindly advise that this policy should
                  also consider allocating the returned addresses not
                  only to the ARIN 4.10 reserved pool - but also the
                  ARIN 4.4 micro-allocation pool for critical
                  infrastructure providers of the Internet ,
                  specifically public exchange points. Both would help
                  on the improvement of the end-user experience given
                  the actual depletion of IPv4<o:p></o:p></span></p>
            </div>
            <div>
              <p class="MsoNormal"><span
                  style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
            </div>
            <p><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
            <div id="x_Signature">
              <div id="x_divtagdefaultwrapper">
                <div>
                  <div>
                    <p class="xmsonormal"><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black">Mike
                        Arbrouet, CISSP- CISM<o:p></o:p></span></p>
                    <p class="xmsonormal"><span
style="font-size:10.0pt;font-family:"Tahoma",sans-serif;color:black"><o:p> </o:p></span></p>
                  </div>
                </div>
              </div>
            </div>
          </div>
          <div class="MsoNormal" style="text-align:center"
            align="center">
            <hr width="98%" size="3" align="center"></div>
          <div id="x_divRplyFwdMsg">
            <p class="MsoNormal"><b><span style="color:black">From:</span></b><span
                style="color:black"> ARIN-PPML <<a
                  href="mailto:arin-ppml-bounces@arin.net"
                  moz-do-not-send="true">arin-ppml-bounces@arin.net</a>>
                on behalf of Fernando Frediani <<a
                  href="mailto:fhfrediani@gmail.com"
                  moz-do-not-send="true">fhfrediani@gmail.com</a>><br>
                <b>Sent:</b> Monday, July 29, 2019 10:39:32 AM<br>
                <b>To:</b> <a href="mailto:arin-ppml@arin.net"
                  moz-do-not-send="true">arin-ppml@arin.net</a><br>
                <b>Subject:</b> Re: [arin-ppml] Draft Policy
                ARIN-2019-17: Returned Addresses to the 4.10 Reserved
                Pool</span> <o:p></o:p></p>
            <div>
              <p class="MsoNormal"> <o:p></o:p></p>
            </div>
          </div>
        </div>
        <div>
          <p class="MsoNormal"><span style="font-size:10.0pt">I find it
              interesting the idea of privileging the pool dedicated to
              <br>
              facilitate IPv6 Deployment and I also agree with the
              comments below in <br>
              the sense that it's not very beneficial do most ARIN
              members due to max <br>
              size, /22, cannot be holding more than a /20.<br>
              <br>
              However one point I couldn't identify is where the new
              entrants stand in <br>
              this new possible scenario ? Will they only be able to
              apply under the <br>
              4.10 reserved pool ? If so for a access/broadband ISPs may
              be easier to <br>
              fit, but not necessarily for other scenarios and types of
              ISPs. <br>
              Therefore if I didn't miss anything these returned
              addresses should also <br>
              be able to go to new entrants, not only to 4.10 reserved
              pool conditions.<br>
              <br>
              Best regards<br>
              Fernando Frediani<br>
              <br>
              On 25/07/2019 17:32, Tom Fantacone wrote:<br>
              > I found the wording of the Problem Statement on this
              one a bit <br>
              > confusing. However, after deciphering the effect of
              the actual policy <br>
              > change I support it.<br>
              ><br>
              > Essentially, all returned IPv4 space will no longer
              go to the waiting <br>
              > list but will supplement the 4.10 reserved pool used
              to enhance IPv6 <br>
              > deployment.  This essentially kills off the waiting
              list.<br>
              ><br>
              > The recent restrictions placed on the waiting list to
              reduce fraud <br>
              > have hobbled it to the point where it's not very
              beneficial to most <br>
              > ARIN members.  (Max size, /22, cannot be holding more
              than a /20).  <br>
              > It's essentially only useful to new entrants, but
              those that go on it <br>
              > still have to wait many months to receive their small
              allocation.  If <br>
              > they justify need now, but have to wait that long,
              how critical is <br>
              > their need if they're willing to wait that long? 
              Small blocks are not <br>
              > terribly expensive and can be quickly gotten on the
              transfer market.  <br>
              > I can understand waiting that long for a large block
              needed for a <br>
              > longer term project due to prohibitive cost, but I
              don't see a great <br>
              > benefit to the waiting list as it stands.<br>
              ><br>
              > Also, if there's any fraud left on the waiting list,
              this would kill it.<br>
              ><br>
              > I would hope, however, that if implemented, those
              currently on the <br>
              > waiting list would be grandfathered in.  I do think
              some entities with <br>
              > legitimate need got burned on the last change made to
              the waiting list.<br>
              ><br>
              > At 04:05 PM 7/23/2019, ARIN wrote:<br>
              >> On 18 July 2019, the ARIN Advisory Council (AC)
              accepted <br>
              >> "ARIN-prop-276: Returned Addresses to the 4.10
              Reserved Pool" as a <br>
              >> Draft Policy.<br>
              >><br>
              >> Draft Policy ARIN-2019-17 is below and can be
              found at:<br>
              >><br>
              >> <a
                href="https://www.arin.net/participate/policy/drafts/2019_17/"
                moz-do-not-send="true">https://www.arin.net/participate/policy/drafts/2019_17/</a><br>
              >><br>
              >> You are encouraged to discuss all Draft Policies
              on PPML. The AC will <br>
              >> evaluate the discussion in order to assess the
              conformance of this <br>
              >> draft policy with ARIN's Principles of Internet
              number resource <br>
              >> policy as stated in the Policy Development
              Process (PDP). <br>
              >> Specifically, these principles are:<br>
              >><br>
              >> * Enabling Fair and Impartial Number Resource
              Administration<br>
              >> * Technically Sound<br>
              >> * Supported by the Community<br>
              >><br>
              >> The PDP can be found at:<br>
              >> <a
                href="https://www.arin.net/participate/policy/pdp/"
                moz-do-not-send="true">https://www.arin.net/participate/policy/pdp/</a><br>
              >><br>
              >> Draft Policies and Proposals under discussion can
              be found at:<br>
              >> <a
                href="https://www.arin.net/participate/policy/drafts/"
                moz-do-not-send="true">https://www.arin.net/participate/policy/drafts/</a><br>
              >><br>
              >> Regards,<br>
              >><br>
              >> Sean Hopkins<br>
              >> Policy Analyst<br>
              >> American Registry for Internet Numbers (ARIN)<br>
              >><br>
              >> Draft Policy ARIN-2019-17: Returned Addresses to
              the 4.10 Reserved Pool<br>
              >><br>
              >> Problem Statement:<br>
              >><br>
              >> An inconsistent and unpredictable stream of
              address space is an <br>
              >> unsuitable method of populating the waiting list
              (4.1.8.1) and <br>
              >> fulfilling subsequent requests.<br>
              >><br>
              >> Policy statement:<br>
              >><br>
              >> Change "4.10. Dedicated IPv4 Block to Facilitate
              IPv6 Deployment" to <br>
              >> "4.10 Dedicated IPv4 Pool to Facilitate IPv6
              Deployment"<br>
              >><br>
              >> Change" When ARIN receives its last /8 IPv4
              allocation from IANA, a <br>
              >> contiguous /10 IPv4 block will be set aside and
              dedicated to <br>
              >> facilitate IPv6 deployment. Allocations and
              assignments from this <br>
              >> block " to "In addition to the contiguous /10
              IPv4 block set aside <br>
              >> and dedicated to facilitate IPv6 deployment, all
              returns and <br>
              >> revocations of IPv4  blocks will be added to the
              pool of space <br>
              >> dedicated to the facilitation of IPv6 deployment.
              Allocations and <br>
              >> assignments from this pool "<br>
              >><br>
              >> Change "This block will be subject to a minimum
              size allocation of <br>
              >> /28 and a maximum size allocation of /24. ARIN
              should use sparse <br>
              >> allocation when possible within that /10 block."
              to "This pool will <br>
              >> be subject to a minimum size allocation of /28
              and a maximum sized <br>
              >> allocation of /24. ARIN should use sparse
              allocation when possible <br>
              >> within the pool."<br>
              >><br>
              >> Comments:<br>
              >><br>
              >> Timetable for implementation: Immediate<br>
              >> _______________________________________________<br>
              >> ARIN-PPML<br>
              >> You are receiving this message because you are
              subscribed to<br>
              >> the ARIN Public Policy Mailing List (<a
                href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
              >> Unsubscribe or manage your mailing list
              subscription at:<br>
              >> <a
                href="https://lists.arin.net/mailman/listinfo/arin-ppml"
                moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
              >> Please contact <a href="mailto:info@arin.net"
                moz-do-not-send="true">info@arin.net</a> if you
              experience any issues.<br>
              ><br>
              ><br>
              > _______________________________________________<br>
              > ARIN-PPML<br>
              > You are receiving this message because you are
              subscribed to<br>
              > the ARIN Public Policy Mailing List (<a
                href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
              > Unsubscribe or manage your mailing list subscription
              at:<br>
              > <a
                href="https://lists.arin.net/mailman/listinfo/arin-ppml"
                moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
              > Please contact <a href="mailto:info@arin.net"
                moz-do-not-send="true">info@arin.net</a> if you
              experience any issues.<br>
              _______________________________________________<br>
              ARIN-PPML<br>
              You are receiving this message because you are subscribed
              to<br>
              the ARIN Public Policy Mailing List (<a
                href="mailto:ARIN-PPML@arin.net" moz-do-not-send="true">ARIN-PPML@arin.net</a>).<br>
              Unsubscribe or manage your mailing list subscription at:<br>
              <a
                href="https://lists.arin.net/mailman/listinfo/arin-ppml"
                moz-do-not-send="true">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
              Please contact <a href="mailto:info@arin.net"
                moz-do-not-send="true">info@arin.net</a> if you
              experience any issues.<o:p></o:p></span></p>
        </div>
      </div>
    </blockquote>
  </body>
</html>