<div dir="ltr"><div><div><div><div><div><br><br></div>I'm the first one to seize upon an opportunity to peel band-aids off of cuts, but I am not sure I see any band-aids below. more like killing ourselves with a thousand paper cuts.<br><br></div>What would be the usefulness of going from a simple "increase the pool size" to the below be? <br><br></div><div>Regarding the sparse allocation bits in your proposal, I thought I read that staff looked into this and said it wasn't feasible? If that's the case, why would we go down that path again?  Section 4.4 appears to be entirely redundant to three of the four sections already. Your suggestions don't appear to add any clarity to the proposed change at all. <br><br></div><div>On a side note, I'll point out that this type of activity has been a frustration for many proposing needed changes to number policy. When we all put something in that is highly focused on a specific issue, no matter how simple or articulate that change is --- it enteres a meat grinder and comes out unrecognizable at the other end. Food for thought.<br><br></div><br></div>Best,<br><br></div>-M<<br><br><br><div><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 26, 2014 at 12:43 PM, Andrew Dul <span dir="ltr"><<a href="mailto:andrew.dul@quark.net" target="_blank">andrew.dul@quark.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div>David,<br>
      <br>
      I'd like to propose the following rewrite of this section as
      replacement text for ARIN-2014-21.  I believe this rewrite deals
      with the clarity issues that you have noted.  I believe this
      rewrite does not change operational practice (other than the /15
      replacing the current /16), but provides some needed clarity in
      this section from multiple amendments over the years.  <br>
      <br>
      <br>
      ================<br>
      <br>
      
      <p class="MsoNormal" style="line-height:normal"><b><span>4.4.
            Micro-allocation</span></b><span><u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><span>ARIN will make IPv4
          micro-allocations to critical infrastructure providers of the
          Internet,
          including public exchange points, core DNS service providers
          (e.g.
          ICANN-sanctioned root and ccTLD operators) as well as the RIRs
          and IANA.<span>  </span><u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><span>These allocations
          will be no smaller than a /24. Multiple allocations may be
          granted when
          operational need can be documented.<u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><span>ARIN will place an
          equivalent of a /15 of IPv4 address space in a permanent
          reserve for
          micro-allocations and shall use sparse allocations practices
          where applicable.<u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><b><span>4.4.1 Internet
            Exchange Points</span></b><span><u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><span>Exchange point
          allocations MUST be allocated from specific blocks reserved
          only for this
          purpose. All other micro-allocations WILL be allocated out of
          other blocks
          reserved for micro-allocation purposes. ARIN will make a list
          of these blocks
          publicly available.<u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><span>Exchange point
          operators must provide justification for the allocation,
          including: connection
          policy, location, other participants (minimum of three total),
          ASN, and contact
          information. This policy does not preclude exchange point
          operators from
          requesting address space under other policies.<u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><b><span>4.4.2 gTLD Allocations</span></b><span> <u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><span>ICANN-sanctioned gTLD
          operators may justify up to the equivalent of an IPv4 /23
          block for each
          authorized new gTLD, allocated from the free pool or received
          via transfer, but
          not from the blocks reserved in section 4.4. This limit of a
          /23 equivalent per
          gTLD does not apply to gTLD allocations made under previous
          policy.<u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><b><span>4.4.3 Other Critical
            Infrastructure</span></b><span><u></u><u></u></span></p>
      <p class="MsoNormal" style="line-height:normal"><span>Other critical infrastructure,
          such as ICANN-sanctioned root and ccTLD operators, as well as
          the RIRs and
          IANA, may receive allocations from ARIN, when operational need
          can be
          demonstrated.<u></u><u></u></span></p>
      <p class="MsoNormal"><u></u> <br>
        <u></u></p>
      
      
      
      
      
      
      
      
      ================<div><div class="h5"><br>
      <br>
      On 12/22/2014 2:48 PM, David Farmer wrote:<br>
    </div></div></div><div><div class="h5">
    <blockquote type="cite">So far
      there has been very little discussion on this policy.
      <br>
      <br>
      Therefore, as one of the AC shepherds for this policy I would like
      to initiate some discussion of this policy.  Here are a few
      questions for the ARIN community to think about and provide
      feedback on;
      <br>
      <br>
      - The current CI reservation is for all CI not just IXPs, the
      problem statement discusses growth primarily in the IXPs as
      justification to expand the reservation.  Should we split off a
      separate reservation pool for IXPs?  Or, keep the current common
      CI pool?
      <br>
      <br>
      - ARIN-2011-4 the policy that made the original CI reservation had
      a Policy Term of 36 Months following implementation, but this was
      not in the policy text itself and therefore did not get included
      in the NRPM.
      <br>
      <br>
      <a href="https://www.arin.net/policy/proposals/2011_4.html" target="_blank">https://www.arin.net/policy/proposals/2011_4.html</a>
      <br>
      <br>
      If applicable, this would have expired July 2014.  So, should
      there be expiration date included in this policy text?  If there
      should be no expiration date, should we explicitly note the
      removal of any expiration date in the discussion of this policy?
      <br>
      <br>
      - There was discussion of smaller and larger than /24 IXP
      allocations, like /26 on the smaller side and that some very large
      IXPs are starting to need as large as a /22.  Also discussed was,
      sparse allocation for IXPs to allow expansion without
      renumbering.  Should this policy includes any changes along these
      lines?  Why or why not?
      <br>
      <br>
      - Should we try to get this to the PPC at NANOG 63 in San Antonio
      as a Recommended Draft Policy?  Or should it wait go to the PPM at
      ARIN 35 in San Francisco as a Recommended Draft Policy?  What
      about ARIN free pool run-out timing?
      <br>
      <br>
      Do you support the policy as written, if not are there any changes
      that could be made that would allow you to support the policy?
      <br>
      <br>
      Thanks.
      <br>
      <br>
      On 11/25/14, 14:35 , ARIN wrote:
      <br>
      <blockquote type="cite">On 20 November 2014 the ARIN Advisory
        Council (AC) accepted
        <br>
        "ARIN-prop-213 Modification to CI Pool Size per Section 4.4" as
        a Draft
        <br>
        Policy.
        <br>
        <br>
        Draft Policy ARIN-2014-21 is below and can be found at:
        <br>
        <a href="https://www.arin.net/policy/proposals/2014_21.html" target="_blank">https://www.arin.net/policy/proposals/2014_21.html</a>
        <br>
        <br>
        You are encouraged to discuss the merits and your concerns of
        Draft
        <br>
        Policy 2014-21 on the Public Policy Mailing List.
        <br>
        <br>
        The AC will evaluate the discussion in order to assess the
        conformance
        <br>
        of this draft policy with ARIN's Principles of Internet Number
        Resource
        <br>
        Policy as stated in the PDP. Specifically, these principles are:
        <br>
        <br>
           * Enabling Fair and Impartial Number Resource Administration
        <br>
           * Technically Sound
        <br>
           * Supported by the Community
        <br>
        <br>
        The ARIN Policy Development Process (PDP) can be found at:
        <br>
        <a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/pdp.html</a>
        <br>
        <br>
        Draft Policies and Proposals under discussion can be found at:
        <br>
        <a href="https://www.arin.net/policy/proposals/index.html" target="_blank">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>
        Draft Policy ARIN-2014-21
        <br>
        Modification to CI Pool Size per Section 4.4
        <br>
        <br>
        Date: 25 November 2014
        <br>
        <br>
        Problem Statement:
        <br>
        <br>
        At the time that this section of policy was written, IXP growth
        in North
        <br>
        America was stagnant. Efforts of late have increased
        significantly
        <br>
        within the IXP standards and other communities to improve
        critical
        <br>
        infrastructure in North America. This effort is paying dividends
        and we
        <br>
        project that a /16 will not be enough to continue to improve
        global
        <br>
        interconnect conditions and support needed IXP CI
        infrastructure.
        <br>
        <br>
        Policy statement:
        <br>
        <br>
        Change to text in section 4.4 Micro Allocations:
        <br>
        <br>
        Current text:
        <br>
        <br>
        ARIN will place an equivalent of a /16 of IPv4 address space in
        a
        <br>
        reserve for Critical Infrastructure, as defined in section 4.4.
        If at
        <br>
        the end of the policy term there is unused address space
        remaining in
        <br>
        this pool, ARIN staff is authorized to utilize this space in a
        manner
        <br>
        consistent with community expectations.
        <br>
        <br>
        Proposed text to replace current text entirely:
        <br>
        <br>
        ARIN will place an equivalent of a /15 of IPv4 address space in
        a
        <br>
        reserve for Critical Infrastructure, as defined in section 4.4.
        <br>
        <br>
        Timetable for implementation: Immediate
        <br>
      </blockquote>
      <br>
      <br>
    </blockquote>
    <br>
  </div></div></div>

<br>_______________________________________________<br>
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">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.<br></blockquote></div><br></div></div><br></div></div></div></div></div></div>