<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">GREAT!  Does prop 208 being accepted
      mean I can re-request my /22 now, or do I have to wait till after
      NANOG 61? <br>
      <div class="moz-signature">
        <meta http-equiv="content-type" content="text/html;
          charset=UTF-8">
        <title></title>
         Best regards,<br>
        <br>
           Derek Calanchini<br>
           Owner<br>
           Creative Network Solutions<br>
           Phone: 916-852-2890<br>
           Fax: 916-852-2899<br>
        <br>
        "Adopt the metric system!"<br>
        <br>
        <img alt="CNS LOGO" src="cid:part1.06080602.03010900@cnets.net"
          height="101" width="240"><br>
      </div>
      On 5/20/2014 5:08 AM, ARIN wrote:<br>
    </div>
    <blockquote cite="mid:537B45AE.4040208@arin.net" type="cite">Recommended
      Draft Policy ARIN-2014-13
      <br>
      Reduce All Minimum Allocation/Assignment Units to /24
      <br>
      <br>
      On 15 May 2014 the ARIN Advisory Council (AC) accepted
      "ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to
      /24" as Draft Policy ARIN 2014-13: Reduce All Minimum
      Allocation/Assignment Units to /24.
      <br>
      <br>
      The AC then recommended ARIN-2014-13 for adoption, making it a
      Recommended Draft Policy.
      <br>
      <br>
      ARIN-2014-13 is below and can be found at:
      <br>
      <a class="moz-txt-link-freetext" href="https://www.arin.net/policy/proposals/2014_13.html">https://www.arin.net/policy/proposals/2014_13.html</a>
      <br>
      <br>
      You are encouraged to discuss Draft Policy 2014-13 on the PPML
      prior to
      <br>
      the upcoming ARIN Public Policy Consultation at NANOG 61. Both the
      discussion on the list and at the meeting will be used by the ARIN
      Advisory Council to determine the community consensus for adopting
      this as policy.
      <br>
      <br>
      The ARIN Policy Development Process can be found at:
      <br>
      <a class="moz-txt-link-freetext" href="https://www.arin.net/policy/pdp.html">https://www.arin.net/policy/pdp.html</a>
      <br>
      <br>
      Draft Policies and Proposals under discussion can be found at:
      <br>
      <a class="moz-txt-link-freetext" href="https://www.arin.net/policy/proposals/index.html">https://www.arin.net/policy/proposals/index.html</a>
      <br>
      <br>
      Regards,
      <br>
      <br>
      Communications and Member Services
      <br>
      American Registry for Internet Numbers (ARIN)
      <br>
      <br>
      <br>
      ## * ##
      <br>
      <br>
      <br>
      Recommended Draft Policy ARIN-2014-13
      <br>
      Reduce All Minimum Allocation/Assignment Units to /24
      <br>
      <br>
      Date: 20 May 2014
      <br>
      <br>
      AC's assessment of conformance with the Principles of Internet
      Number Resource Policy:
      <br>
      <br>
      Draft Policy ARIN-2014-13: Reduce All Minimum
      Allocation/Assignment Units to /24 - This proposal will lower all
      allocation(s) and assignment(s) of IPv4 address in section 4.2 and
      4.3 to a /24 minimum. The policy would also remove section 4.9 as
      the allocation and assignment sizes were now larger than 4.2 and
      4.3. As noted in the staff report it will also remove the maximum
      initial allocation that was used with the examples in 4.2.2.2. The
      changes to the NRPM are fair in that they would treat all resource
      applicants equally. They are technically sound and have received
      support from the community.
      <br>
      <br>
      Problem Statement:
      <br>
      <br>
      As we approach runout, more and more end users and smaller ISPs
      will be unable to obtain space from their upstreams and will be
      seeking space from ARIN. In order to meet these needs to the
      extent possible and to make policy more fair to a broader range of
      the ARIN constituency, we should reduce the minimum assignment and
      allocation units for IPv4 to /24 across the board.
      <br>
      <br>
      Policy statement:
      <br>
      <br>
      Remove all references to minimum allocations /20 and /22 replacing
      them with the term allocation or with /24 when referencing minimum
      size blocks.
      <br>
      <br>
      Change the title of 4.2.2.1 to "ISP Requirements" with revised
      text stating:
      <br>
      <br>
      All ISP organizations must satisfy the following
      requirements...thus eliminating the entire Multi-homed section and
      subsections along with other superfluous example text.
      <br>
      <br>
      Delete the special case allocations/assignments for the Caribbean
      as the new /24 minimums are an improvement.
      <br>
      <br>
      Comments:
      <br>
      a. Timetable for implementation: Immediate b. A red line version
      has been included
      <br>
      <br>
      Full text version of changes for easy reference:
      <br>
      <br>
      4.2.1.5. Minimum allocation
      <br>
      In general, ARIN allocates /24 and larger IP address prefixes to
      ISPs. If allocations smaller than /24 are needed, ISPs should
      request address space from their upstream provider.
      <br>
      <br>
      4.2.2.1 ISP Requirements
      <br>
      All ISP organizations must satisfy the following requirements:
      <br>
      <br>
      4.2.2.1.1 Use of /24
      <br>
      The efficient utilization of an entire previously allocated /24
      from their upstream ISP. This allocation may have been provided by
      an ISP’s upstream provider(s), and does not have to be contiguous
      address space.
      <br>
      <br>
      4.2.2.1.3. Three months
      <br>
      Provide detailed information showing specifically how the
      requested allocation will be utilized within three months.
      <br>
      <br>
      4.2.2.1.4. Renumber and return
      <br>
      ISPs receiving a new allocation may wish to renumber out of their
      previously allocated space. In this case, an ISP must use the new
      allocation to renumber out of that previously allocated block of
      address space and must return the space to its upstream provider.
      <br>
      <br>
      4.2.2.2. [section number retired]
      <br>
      <br>
      4.3.2 Minimum assignment
      <br>
      <br>
      4.3.2.1. [section moved to 4.3.2]
      <br>
      The minimum block of IP address space assigned by ARIN to
      end-users is a /24. If assignments smaller than /24 are needed,
      end-users should contact their upstream provider.
      <br>
      <br>
      4.3.2.2 [section number retired]
      <br>
      <br>
      4.9 [section number retired]
      <br>
      <br>
      ##########
      <br>
      <br>
      ARIN STAFF ASSESSMENT
      <br>
      Assessment of: ARIN-prop-208 Reduce All Minimum
      Allocation/Assignment Units to /24
      <br>
      Date of Assessment: 11 May 2014
      <br>
      <br>
      1. Summary (Staff Understanding)
      <br>
      <br>
      This policy would reduce the minimum allocation/assignment size to
      /24 for all networks, whether end user or ISP and whether single
      or multi-homed. Additionally, it would eliminate the existing
      multi-homed policies.
      <br>
      <br>
      2. Comments
      <br>
      <br>
      A. ARIN Staff Comments
      <br>
      <br>
      1. It is not clear in this proposal what criteria would be used to
      determine any allocation size other than a /24. Current policy
      provides clear criteria for how to qualify for a /22, /21, and a
      /20. Would the same criteria still apply for organizations that
      request more than an initial allocation of a/24?
      <br>
      <br>
      2. Staff uses current criteria defined in 4.2.2.1.1 in conjunction
      with section 4.2.1.4 (slow start) to establish a de facto /20
      maximum initial allocation size for ISPs new to ARIN. Staff would
      recommend that a maximum initial allocation size of a /20 be noted
      in section 4.2.1.5 to codify existing practice and provide
      clarity, and that it be renamed to “Minimum and Maximum
      Allocation”.
      <br>
      <br>
      3. This proposal would benefit smaller ISPs who are unable to
      qualify currently under ARIN IPv4 policies, and particularly would
      be unable to qualify for 8.3 and 8.4 transfers in a post-depletion
      world.
      <br>
      *Note, this was a point raised in the policy experience report in
      Chicago.
      <br>
      <br>
      4. ARIN will likely have many discontiguous /24s as we near
      depletion and fewer and fewer larger prefixes. This policy would
      actually allow more organizations to use these smallest prefixes,
      thus ensuring the efficient run-out of ARIN’s IPv4 address pool.
      <br>
      <br>
      B. ARIN General Counsel - Legal Assessment
      <br>
      <br>
      This proposal does not appear to pose any legal risk.
      <br>
      <br>
      3. Resource Impact
      <br>
      This policy would have minimal resource impact from an
      implementation aspect. It is estimated that implementation would
      occur within 3 months after ratification by the ARIN Board of
      Trustees.
      <br>
      <br>
      The following would be needed in order to implement:
      <br>
      Updated guidelines and internal procedures
      <br>
      Staff training
      <br>
      <br>
      4. Proposal/Draft Policy Text Assessed
      <br>
      ARIN-prop-208 Reduce All Minimum Allocation/Assignment Units to
      /24
      <br>
      <br>
      Problem Statement:
      <br>
      As we approach runout, more and more end users and smaller ISPs
      will be unable to obtain space from their upstreams and will be
      seeking space from ARIN. In order to meet these needs to the
      extent possible and to make policy more fair to a broader range of
      the ARIN constituency, we should reduce the minimum assignment and
      allocation units for IPv4 to /24 across the board.
      <br>
      <br>
      Policy statement:
      <br>
      Remove all references to minimum allocations /20 and /22 replacing
      them with the term allocation or with /24 when referencing minimum
      size blocks.
      <br>
      <br>
      Change the title of 4.2.2.1 to "ISP Requirements" with revised
      text stating:
      <br>
      All ISP organizations must satisfy the following
      requirements...thus eliminating the entire Multi-homed section and
      subsections along with other superfluous example text.
      <br>
      <br>
      Delete the special case allocations/assignments for the Caribbean
      as the new /24 minimums are an improvement.
      <br>
      <br>
      Text assessed:
      <br>
      <br>
      4.2.1.5. Minimum allocation
      <br>
      In general, ARIN allocates /24 and larger IP address prefixes to
      ISPs. If allocations smaller than /24 are needed, ISPs should
      request address space from their upstream provider.
      <br>
      <br>
      4.2.2.1 ISP Requirements
      <br>
      All ISP organizations must satisfy the following requirements:
      <br>
      <br>
      4.2.2.1.1 Use of /24
      <br>
      The efficient utilization of an entire previously allocated /24
      from their upstream ISP. This allocation may have been provided by
      an ISP’s upstream provider(s), and does not have to be contiguous
      address space.
      <br>
      <br>
      4.2.2.1.4. Renumber and return
      <br>
      ISPs receiving a new allocation may wish to renumber out of their
      previously allocated space. In this case, an ISP must use the new
      allocation to renumber out of that previously allocated block of
      address space and must return the space to its upstream provider.
      <br>
      <br>
      4.2.2.2. [section number retired]
      <br>
      <br>
      4.3.2 Minimum assignment
      <br>
      <br>
      4.3.2.1. [section moved to 4.3.2]
      <br>
      The minimum block of IP address space assigned by ARIN to
      end-users is a /24. If assignments smaller than /24 are needed,
      end-users should contact their upstream provider.
      <br>
      <br>
      4.3.2.2 [section number retired]
      <br>
      _______________________________________________
      <br>
      PPML
      <br>
      You are receiving this message because you are subscribed to
      <br>
      the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
      <br>
      Unsubscribe or manage your mailing list subscription at:
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
      <br>
      Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br>
    </blockquote>
    <br>
  
<br /><br />
<hr style='border:none; color:#909090; background-color:#B0B0B0; height: 1px; width: 99%;' />
<table style='border-collapse:collapse;border:none;'>
        <tr>
                <td style='border:none;padding:0px 15px 0px 8px'>
                        <a href="http://www.avast.com/">
                                <img border=0 src="http://static.avast.com/emails/avast-mail-stamp.png" />
                        </a>
                </td>
                <td>
                        <p style='color:#3d4d5a; font-family:"Calibri","Verdana","Arial","Helvetica"; font-size:12pt;'>
                                This email is free from viruses and malware because <a href="http://www.avast.com/">avast! Antivirus</a> protection is active.
                        </p>
                </td>
        </tr>
</table>
<br />
</body>
</html>