[arin-ppml] Micro-allocation policy proposal draft

[Martin Hannigan]

If I were going to change anything with micro allocations I would change:

- Make RIRs singular as in ARIN, not all of them.
- Remove the policy term and make it permanent

 IXP growth has changed dramatically since the policy was written.

I'm not sure I understand the desire to change to a /26? Where in ARIN
policy does it say that the prefix can't be routed? I also checked
Open-IX OIX-1 and there's nothing there about routing or not routing
an IXP prefix. I agree, this is the de-facto standard though and it
may be worth asking the actual affected community what they think.

I'm opposed to changing any of 4.4 with the exception of the two items above.


Best,

-M<


On Mon, Sep 22, 2014 at 7:56 PM, Andrew Dul <andrew.dul at quark.net> wrote:
> Hello,
>
> At the Chicago meeting there was some discussion around the micro-allocation
> policy (section 4.4) of the NRPM.  I committed to the AC to produce a draft
> update to this section based upon feedback that I heard from the community.
> Below you will find a draft update.
>
> This has not yet been submitted to the policy process.  I wanted the
> community to validate that they still would like these type of changes to be
> considered before formal work on this section started.
>
> I have also attached a PDF redline so that you can easily see the changes
> from the current text.
>
> Thanks for your feedback,
> Andrew
>
> -----------------
>
> 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. Multiple allocations may be granted when operational need can
> be documented..
>
> ARIN will place an equivalent of a /16 of IPv4 address space in a reserve
> for micro-allocations.
>
> 4.4.1 Internet Exchange Points
> ARIN will place an additional equivalent of a /16 of IPv4 address space in a
> reserve for exchange point allocations under section 4.4.1.  (ARIN may
> reserve a block within the last /10 (section 4.10) or from IANA returned
> address space (section 10.5) if no other suitable block is available at the
> time of policy implementation.)
>
> 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.
>
> These allocations will be no smaller than a /26.
>
> 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 which is not defined in other sub-sections of
> section 4.4, may receive allocations from ARIN, when operational need can be
> demonstrated.  These allocations will be no smaller than a /24.
>
>
> _______________________________________________
> PPML
> 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:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.