[arin-ppml] Micro-allocation policy proposal draft

[Koch, Andrew]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Andrew Dul
> Sent: Monday, September 22, 2014 12:56
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Micro-allocation policy proposal draft
> 
> 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 the redline document.  I find it quite useful, especially with the inline comments.


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


I am confused with this plus a similar 4.4.1 statement of placing an additional /16 in reserve.  In total, will all of 4.4 be a single /16 equivalent?  Or is the proposal to add another /16 beyond what is already reserved in the existing 4.4 text.

I could also read this as a /16 is effectively reserved for 4.4.3, as 4.4.2 is exempt from utilizing the reservation and 4.4.1 has its own /16 equivalent. 

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

I am indifferent to making this change.  If we make a policy change, I would support leaving this in.  However, I am not sure that a change is fully necessary.

In regards to Andrew's question in the PDF - "Does the policy need text on how ARIN should determine block size for exchange points?" - I'll come back with another question.  How do staff today make determination on block size under this policy?  I would expect that whatever determination criteria is used today would still be valid with a smaller block size.


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


I do see that this policy breaks separate methods of issuance out, but I don't know that it makes the Micro-allocation policy any clearer.  I am not sure that a policy change is necessary.

Andy