> -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Andrew Dul > Sent: Monday, September 22, 2014 12:56 > To: [email protected] > 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 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
