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