[arin-ppml] Draft Policy ARIN-2014-21: Modification to CI Pool Size per Section 4.4
hannigan at gmail.com
Mon Dec 29 22:10:55 EST 2014
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.
What would be the usefulness of going from a simple "increase the pool
size" to the below be?
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.
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.
On Fri, Dec 26, 2014 at 12:43 PM, Andrew Dul <andrew.dul at quark.net> wrote:
> 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.
> *4.4. Micro-allocation*
> 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.
> These allocations will be no smaller than a /24. Multiple allocations may
> be granted when operational need can be documented.
> 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.
> *4.4.1 Internet Exchange Points*
> 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.
> 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.
> *4.4.2 gTLD Allocations*
> 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.
> *4.4.3 Other Critical Infrastructure*
> 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.
> On 12/22/2014 2:48 PM, David Farmer wrote:
> So far there has been very little discussion on this policy.
> 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;
> - 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?
> - 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.
> 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?
> - 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?
> - 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?
> 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?
> On 11/25/14, 14:35 , ARIN wrote:
> On 20 November 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-213 Modification to CI Pool Size per Section 4.4" as a Draft
> Draft Policy ARIN-2014-21 is below and can be found at:
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-21 on the Public Policy Mailing List.
> The AC will evaluate the discussion in order to assess the conformance
> of this draft policy with ARIN's Principles of Internet Number Resource
> Policy as stated in the PDP. Specifically, these principles are:
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
> The ARIN Policy Development Process (PDP) can be found at:
> Draft Policies and Proposals under discussion can be found at:
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> ## * ##
> Draft Policy ARIN-2014-21
> Modification to CI Pool Size per Section 4.4
> Date: 25 November 2014
> Problem Statement:
> At the time that this section of policy was written, IXP growth in North
> America was stagnant. Efforts of late have increased significantly
> within the IXP standards and other communities to improve critical
> infrastructure in North America. This effort is paying dividends and we
> project that a /16 will not be enough to continue to improve global
> interconnect conditions and support needed IXP CI infrastructure.
> Policy statement:
> Change to text in section 4.4 Micro Allocations:
> Current text:
> ARIN will place an equivalent of a /16 of IPv4 address space in a
> reserve for Critical Infrastructure, as defined in section 4.4. If at
> the end of the policy term there is unused address space remaining in
> this pool, ARIN staff is authorized to utilize this space in a manner
> consistent with community expectations.
> Proposed text to replace current text entirely:
> ARIN will place an equivalent of a /15 of IPv4 address space in a
> reserve for Critical Infrastructure, as defined in section 4.4.
> Timetable for implementation: Immediate
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML